From igraves at openjdk.java.net Wed Sep 1 00:45:38 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Wed, 1 Sep 2021 00:45:38 GMT Subject: RFR: 8214761: Bug in parallel Kahan summation implementation [v3] In-Reply-To: References: Message-ID: > 8214761: Bug in parallel Kahan summation implementation Ian Graves 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 six additional commits since the last revision: - Changing some comments. - Merge branch 'master' into kahan-summation-bug - Updates with more test coverage - stashing - Stashing - 8214761: Bug in parallel Kahan summation implementation ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4674/files - new: https://git.openjdk.java.net/jdk/pull/4674/files/10b8dcda..905450d8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4674&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4674&range=01-02 Stats: 107423 lines in 2079 files changed: 73519 ins; 22961 del; 10943 mod Patch: https://git.openjdk.java.net/jdk/pull/4674.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4674/head:pull/4674 PR: https://git.openjdk.java.net/jdk/pull/4674 From mchung at openjdk.java.net Wed Sep 1 01:05:32 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 1 Sep 2021 01:05:32 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v8] In-Reply-To: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> Message-ID: <5V0eAcrG9rS-d9RnyC2oJ5kVo6v84IhyBn40M71mYUg=.5d8c17fe-a23b-49a8-bfef-f670c0f013eb@github.com> > This reimplements core reflection with method handles. > > For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. > > The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. > > The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. > > Ran tier1-tier8 tests. > > [1] https://bugs.openjdk.java.net/browse/JDK-8013527 > [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: minor cleanup and more test case. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5027/files - new: https://git.openjdk.java.net/jdk/pull/5027/files/68bb9efe..32e7f340 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5027&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5027&range=06-07 Stats: 56 lines in 8 files changed: 33 ins; 0 del; 23 mod Patch: https://git.openjdk.java.net/jdk/pull/5027.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5027/head:pull/5027 PR: https://git.openjdk.java.net/jdk/pull/5027 From wuyan at openjdk.java.net Wed Sep 1 06:57:12 2021 From: wuyan at openjdk.java.net (Wu Yan) Date: Wed, 1 Sep 2021 06:57:12 GMT Subject: RFR: 8273111: Default timezone should return zone ID if /etc/localtime is valid but not canonicalization on linux Message-ID: <6gmVj3r1hjhG5jvo_dSly3ShNnZZSCn-NIjtnvSySrk=.a88def27-7b80-425b-9ab8-2f94f5004b47@github.com> Hi, Please help me review the change to enhance getting time zone ID from /etc/localtime on linux. We use `realpath` instead of `readlink` to obtain the link name of /etc/localtime, because `readlink` can only read the value of a symbolic of link, not the canonicalized absolute pathname. For example, the value of /etc/localtime is "../usr/share/zoneinfo//Asia/Shanghai", then the linkbuf obtained by `readlink` is "../usr/share/zoneinfo//Asia/Shanghai", and then the call of `getZoneName(linkbuf)` will get "/Asia/Shanghai", not "Asia/Shanghai", which consider as invalid in `ZoneInfoFile.getZoneInfo()`. Using `realpath`, you can get ?/usr/share/zoneinfo/Asia/Shanghai? directly from ?/etc/localtime?. Thanks, wuyan ------------- Commit messages: - 8273111: Default timezone should return zone ID if /etc/localtime is valid but not canonicalization on linux Changes: https://git.openjdk.java.net/jdk/pull/5327/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5327&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273111 Stats: 10 lines in 1 file changed: 2 ins; 1 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/5327.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5327/head:pull/5327 PR: https://git.openjdk.java.net/jdk/pull/5327 From tschatzl at openjdk.java.net Wed Sep 1 08:14:47 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 1 Sep 2021 08:14:47 GMT Subject: RFR: 8273140: Replace usages of Enum.class.getEnumConstants() with Enum.values() where possible [v4] In-Reply-To: References: <4N-BgoVLVgZk_uPkRLoY-427bF-kKKwDr1zRHI7o1PI=.dcdbec6e-f3f8-48e4-94ce-a88d7e494c41@github.com> Message-ID: On Tue, 31 Aug 2021 20:04:23 GMT, ?????? ??????? wrote: >> Just a very tiny clean-up. >> >> There are some places in JDK code base where we call `Enum.class.getEnumConstants()` to get all the values of the referenced `enum`. This is excessive, less-readable and slower than just calling `Enum.values()` as in `getEnumConstants()` we have volatile access: >> >> public T[] getEnumConstants() { >> T[] values = getEnumConstantsShared(); >> return (values != null) ? values.clone() : null; >> } >> >> private transient volatile T[] enumConstants; >> >> T[] getEnumConstantsShared() { >> T[] constants = enumConstants; >> if (constants == null) { /* ... */ } >> return constants; >> } >> >> Calling values() method is slightly faster: >> >> @BenchmarkMode(Mode.AverageTime) >> @OutputTimeUnit(TimeUnit.NANOSECONDS) >> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) >> public class EnumBenchmark { >> >> @Benchmark >> public Enum[] values() { >> return Enum.values(); >> } >> >> @Benchmark >> public Enum[] getEnumConstants() { >> return Enum.class.getEnumConstants(); >> } >> >> private enum Enum { >> A, >> B >> } >> } >> >> >> Benchmark Mode Cnt Score Error Units >> EnumBenchmark.getEnumConstants avgt 15 6,265 ? 0,051 ns/op >> EnumBenchmark.getEnumConstants:?gc.alloc.rate avgt 15 2434,075 ? 19,568 MB/sec >> EnumBenchmark.getEnumConstants:?gc.alloc.rate.norm avgt 15 24,002 ? 0,001 B/op >> EnumBenchmark.getEnumConstants:?gc.churn.G1_Eden_Space avgt 15 2433,709 ? 70,216 MB/sec >> EnumBenchmark.getEnumConstants:?gc.churn.G1_Eden_Space.norm avgt 15 23,998 ? 0,659 B/op >> EnumBenchmark.getEnumConstants:?gc.churn.G1_Survivor_Space avgt 15 0,009 ? 0,003 MB/sec >> EnumBenchmark.getEnumConstants:?gc.churn.G1_Survivor_Space.norm avgt 15 ? 10?? B/op >> EnumBenchmark.getEnumConstants:?gc.count avgt 15 210,000 counts >> EnumBenchmark.getEnumConstants:?gc.time avgt 15 119,000 ms >> >> EnumBenchmark.values avgt 15 4,164 ? 0,134 ns/op >> EnumBenchmark.values:?gc.alloc.rate avgt 15 3665,341 ? 120,721 MB/sec >> EnumBenchmark.values:?gc.alloc.rate.norm avgt 15 24,002 ? 0,001 B/op >> EnumBenchmark.values:?gc.churn.G1_Eden_Space avgt 15 3660,512 ? 137,250 MB/sec >> EnumBenchmark.values:?gc.churn.G1_Eden_Space.norm avgt 15 23,972 ? 0,529 B/op >> EnumBenchmark.values:?gc.churn.G1_Survivor_Space avgt 15 0,017 ? 0,003 MB/sec >> EnumBenchmark.values:?gc.churn.G1_Survivor_Space.norm avgt 15 ? 10?? B/op >> EnumBenchmark.values:?gc.count avgt 15 262,000 counts >> EnumBenchmark.values:?gc.time avgt 15 155,000 ms > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8273140: Fix copyright year Lgtm. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5303 From alanb at openjdk.java.net Wed Sep 1 12:41:46 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 1 Sep 2021 12:41:46 GMT Subject: RFR: 8273111: Default timezone should return zone ID if /etc/localtime is valid but not canonicalization on linux In-Reply-To: <6gmVj3r1hjhG5jvo_dSly3ShNnZZSCn-NIjtnvSySrk=.a88def27-7b80-425b-9ab8-2f94f5004b47@github.com> References: <6gmVj3r1hjhG5jvo_dSly3ShNnZZSCn-NIjtnvSySrk=.a88def27-7b80-425b-9ab8-2f94f5004b47@github.com> Message-ID: On Wed, 1 Sep 2021 06:45:26 GMT, Wu Yan wrote: > Hi, > Please help me review the change to enhance getting time zone ID from /etc/localtime on linux. > > We use `realpath` instead of `readlink` to obtain the link name of /etc/localtime, because `readlink` can only read the value of a symbolic of link, not the canonicalized absolute pathname. > > For example, the value of /etc/localtime is "../usr/share/zoneinfo//Asia/Shanghai", then the linkbuf obtained by `readlink` is "../usr/share/zoneinfo//Asia/Shanghai", and then the call of `getZoneName(linkbuf)` will get "/Asia/Shanghai", not "Asia/Shanghai", which consider as invalid in `ZoneInfoFile.getZoneInfo()`. Using `realpath`, you can get ?/usr/share/zoneinfo/Asia/Shanghai? directly from ?/etc/localtime?. > > Thanks, > wuyan I haven't come across this configuration like but changing it to use realpath seem reasonable. ------------- PR: https://git.openjdk.java.net/jdk/pull/5327 From alanb at openjdk.java.net Wed Sep 1 12:47:50 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 1 Sep 2021 12:47:50 GMT Subject: RFR: 6957241: ClassLoader.getResources() returns only 1 instance when using jar indexing In-Reply-To: References: Message-ID: On Tue, 31 Aug 2021 12:11:46 GMT, wxiang wrote: > Using jarIndex for Hibench, there is an unexpected behavior with the exception "Exception in thread "main" org.apache.hadoop.fs.UnsupportedFileSystemException: No FileSystem for scheme "hdfs"". > > After investigating it, it is related to the usage of ServiceLoader with JarIndex. > The below stack shows the issue with JDK11: > > getResource:1016, URLClassPath$JarLoader (jdk.internal.loader) > getResource:937, URLClassPath$JarLoader (jdk.internal.loader) > findResource:912, URLClassPath$JarLoader (jdk.internal.loader) > next:341, URLClassPath$1 (jdk.internal.loader) > hasMoreElements:351, URLClassPath$1 (jdk.internal.loader) > hasNext:355, BuiltinClassLoader$1 (jdk.internal.loader) > hasMoreElements:363, BuiltinClassLoader$1 (jdk.internal.loader) > next:3032, CompoundEnumeration (java.lang) > hasMoreElements:3041, CompoundEnumeration (java.lang) > nextProviderClass:1203, ServiceLoader$LazyClassPathLookupIterator (java.util) > hasNextService:1221, ServiceLoader$LazyClassPathLookupIterator (java.util) > hasNext:1265, ServiceLoader$LazyClassPathLookupIterator (java.util) > hasNext:1300, ServiceLoader$2 (java.util) > hasNext:1385, ServiceLoader$3 (java.util) > > The below API tries to get all the resources with the same name. > > public Enumeration findResources(final String name, > final boolean check) > ``` > After using JarIndex, URLClassPath.findResources only returns 1 URL. > It is the same as the description in JDK-6957241. > > The issue still exists in JDK18. > > Root cause: > > public Enumeration findResources(final String name, > final boolean check) { > return new Enumeration<>() { > private int index = 0; > private URL url = null; > > private boolean next() { > if (url != null) { > return true; > } else { > Loader loader; > while ((loader = getLoader(index++)) != null) { > url = loader.findResource(name, check); > if (url != null) { > return true; > } > } > return false; > } > } > ... > }; > } > > With the JarIndex, there is only one loader which is corresponding to the jar with the index due to the implementation in JarLoader.getResource(final String name, boolean check, Set visited). > > Loaders corresponding to other jar packages will not appear in this while. > So it only returns 1 instance. > > To solve the issue, I change the implementation "private boolean next()". > If the loader has index, traverse the index and get all the resource from the loader. Thanks for the PR/patch. I think we need a discussion on core-libs-dev as to whether to keep the legacy JAR index support. The original motivation was applets when it was added in JDK 1.3. I don't think findResources has ever worked with the JAR index for cases where the same resource is in more than one JAR files. I'm not opposed to fixing it but it does add complexity and will likely refactoring the UCP implementation for something that will likely go away eventually anyway. ------------- PR: https://git.openjdk.java.net/jdk/pull/5316 From fweimer at openjdk.java.net Wed Sep 1 12:54:46 2021 From: fweimer at openjdk.java.net (Florian Weimer) Date: Wed, 1 Sep 2021 12:54:46 GMT Subject: RFR: 8273111: Default timezone should return zone ID if /etc/localtime is valid but not canonicalization on linux In-Reply-To: <6gmVj3r1hjhG5jvo_dSly3ShNnZZSCn-NIjtnvSySrk=.a88def27-7b80-425b-9ab8-2f94f5004b47@github.com> References: <6gmVj3r1hjhG5jvo_dSly3ShNnZZSCn-NIjtnvSySrk=.a88def27-7b80-425b-9ab8-2f94f5004b47@github.com> Message-ID: <9LFh1-fCalpsuewYw9VrvQklHPSonac2AlSQptUamf8=.1db3137e-84db-47ad-835f-cbc8719f84e0@github.com> On Wed, 1 Sep 2021 06:45:26 GMT, Wu Yan wrote: > Hi, > Please help me review the change to enhance getting time zone ID from /etc/localtime on linux. > > We use `realpath` instead of `readlink` to obtain the link name of /etc/localtime, because `readlink` can only read the value of a symbolic of link, not the canonicalized absolute pathname. > > For example, the value of /etc/localtime is "../usr/share/zoneinfo//Asia/Shanghai", then the linkbuf obtained by `readlink` is "../usr/share/zoneinfo//Asia/Shanghai", and then the call of `getZoneName(linkbuf)` will get "/Asia/Shanghai", not "Asia/Shanghai", which consider as invalid in `ZoneInfoFile.getZoneInfo()`. Using `realpath`, you can get ?/usr/share/zoneinfo/Asia/Shanghai? directly from ?/etc/localtime?. > > Thanks, > wuyan Using `realpath` instead of `readlink` will change results on systems which use symbolic links instead of hard links to de-duplicate the timezone files. For example, on Debian, if `UTC` is configured (`/etc/localtime` points to `/usr/share/zoneinfo/UTC`), I think the result will be `Etc/UTC` instead of `UTC` after this change. But I have not actually tested this. src/java.base/unix/native/libjava/TimeZone_md.c line 292: > 290: /* canonicalize the path */ > 291: char resolvedpath[PATH_MAX + 1]; > 292: char *path = realpath(DEFAULT_ZONEINFO_FILE, resolvedpath); You really should use `realpath` with `NULL` as the second argument, to avoid any risk of buffer overflow. Future C library headers may warn about non-null arguments here. ------------- PR: https://git.openjdk.java.net/jdk/pull/5327 From dfuchs at openjdk.java.net Wed Sep 1 13:00:44 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 1 Sep 2021 13:00:44 GMT Subject: RFR: 6957241: ClassLoader.getResources() returns only 1 instance when using jar indexing In-Reply-To: References: Message-ID: On Tue, 31 Aug 2021 12:11:46 GMT, wxiang wrote: > Using jarIndex for Hibench, there is an unexpected behavior with the exception "Exception in thread "main" org.apache.hadoop.fs.UnsupportedFileSystemException: No FileSystem for scheme "hdfs"". > > After investigating it, it is related to the usage of ServiceLoader with JarIndex. > The below stack shows the issue with JDK11: > > getResource:1016, URLClassPath$JarLoader (jdk.internal.loader) > getResource:937, URLClassPath$JarLoader (jdk.internal.loader) > findResource:912, URLClassPath$JarLoader (jdk.internal.loader) > next:341, URLClassPath$1 (jdk.internal.loader) > hasMoreElements:351, URLClassPath$1 (jdk.internal.loader) > hasNext:355, BuiltinClassLoader$1 (jdk.internal.loader) > hasMoreElements:363, BuiltinClassLoader$1 (jdk.internal.loader) > next:3032, CompoundEnumeration (java.lang) > hasMoreElements:3041, CompoundEnumeration (java.lang) > nextProviderClass:1203, ServiceLoader$LazyClassPathLookupIterator (java.util) > hasNextService:1221, ServiceLoader$LazyClassPathLookupIterator (java.util) > hasNext:1265, ServiceLoader$LazyClassPathLookupIterator (java.util) > hasNext:1300, ServiceLoader$2 (java.util) > hasNext:1385, ServiceLoader$3 (java.util) > > The below API tries to get all the resources with the same name. > > public Enumeration findResources(final String name, > final boolean check) > ``` > After using JarIndex, URLClassPath.findResources only returns 1 URL. > It is the same as the description in JDK-6957241. > > The issue still exists in JDK18. > > Root cause: > > public Enumeration findResources(final String name, > final boolean check) { > return new Enumeration<>() { > private int index = 0; > private URL url = null; > > private boolean next() { > if (url != null) { > return true; > } else { > Loader loader; > while ((loader = getLoader(index++)) != null) { > url = loader.findResource(name, check); > if (url != null) { > return true; > } > } > return false; > } > } > ... > }; > } > > With the JarIndex, there is only one loader which is corresponding to the jar with the index due to the implementation in JarLoader.getResource(final String name, boolean check, Set visited). > > Loaders corresponding to other jar packages will not appear in this while. > So it only returns 1 instance. > > To solve the issue, I change the implementation "private boolean next()". > If the loader has index, traverse the index and get all the resource from the loader. If there is a way to simplify the UCP code by removing the support for legacy JAR index, and if it doesn't cause regressions, I'm all for it. But given the intricacy of that code I suspect it will be quite an undertaking - and reviewing such a change will probably not be trivial. The current PR is not trivial to review and seems to be adding an other layer of complexity though, so I agree that we should have this discussion. ------------- PR: https://git.openjdk.java.net/jdk/pull/5316 From naoto at openjdk.java.net Wed Sep 1 13:42:50 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 1 Sep 2021 13:42:50 GMT Subject: RFR: 8273111: Default timezone should return zone ID if /etc/localtime is valid but not canonicalization on linux In-Reply-To: <6gmVj3r1hjhG5jvo_dSly3ShNnZZSCn-NIjtnvSySrk=.a88def27-7b80-425b-9ab8-2f94f5004b47@github.com> References: <6gmVj3r1hjhG5jvo_dSly3ShNnZZSCn-NIjtnvSySrk=.a88def27-7b80-425b-9ab8-2f94f5004b47@github.com> Message-ID: On Wed, 1 Sep 2021 06:45:26 GMT, Wu Yan wrote: > Hi, > Please help me review the change to enhance getting time zone ID from /etc/localtime on linux. > > We use `realpath` instead of `readlink` to obtain the link name of /etc/localtime, because `readlink` can only read the value of a symbolic of link, not the canonicalized absolute pathname. > > For example, the value of /etc/localtime is "../usr/share/zoneinfo//Asia/Shanghai", then the linkbuf obtained by `readlink` is "../usr/share/zoneinfo//Asia/Shanghai", and then the call of `getZoneName(linkbuf)` will get "/Asia/Shanghai", not "Asia/Shanghai", which consider as invalid in `ZoneInfoFile.getZoneInfo()`. Using `realpath`, you can get ?/usr/share/zoneinfo/Asia/Shanghai? directly from ?/etc/localtime?. > > Thanks, > wuyan The change looks reasonable. Please test your fix with macOS as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/5327 From rriggs at openjdk.java.net Wed Sep 1 15:05:34 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 1 Sep 2021 15:05:34 GMT Subject: RFR: 8272600: (test) Use native "sleep" in Basic.java [v3] In-Reply-To: References: Message-ID: On Tue, 31 Aug 2021 01:26:17 GMT, David Holmes wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Revised to use native /bin/sleep program on Unix* (non-Windows). >> For Windows, a native "BasicSleep" program is used. > > test/jdk/java/lang/ProcessBuilder/Basic.java line 2665: > >> 2663: >> 2664: Path exePath = Path.of(TEST_NATIVEPATH).resolve("BasicSleep.exe"); >> 2665: System.out.println("exePath: " + exePath + ", canExec: " + exePath.toFile().canExecute()); > > What is this for?? Ioi was concerned that the fallback to Java would be used silently and the old intermittent issue would return. ------------- PR: https://git.openjdk.java.net/jdk/pull/5239 From rriggs at openjdk.java.net Wed Sep 1 15:11:49 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 1 Sep 2021 15:11:49 GMT Subject: RFR: 8272600: (test) Use native "sleep" in Basic.java [v3] In-Reply-To: References: Message-ID: On Tue, 31 Aug 2021 01:12:40 GMT, David Holmes wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Revised to use native /bin/sleep program on Unix* (non-Windows). >> For Windows, a native "BasicSleep" program is used. > > test/jdk/java/lang/ProcessBuilder/Basic.java line 2646: > >> 2644: if (exePath.toFile().canExecute()) { >> 2645: return exePath; >> 2646: } > > Not sure why this is so elaborate when elsewhere in the test we just assume `/usr/bin/env` exists? True enough, will simplify. At one point, I was going to name the BasicSleep just "sleep" and put the native path at the end of a search list. Some other executables are not reliably in the same directories in all Unix versions. ------------- PR: https://git.openjdk.java.net/jdk/pull/5239 From rriggs at openjdk.java.net Wed Sep 1 15:15:52 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 1 Sep 2021 15:15:52 GMT Subject: RFR: 8272600: (test) Use native "sleep" in Basic.java [v3] In-Reply-To: References: Message-ID: <5lAYyqoz8qRPN3cWTfbLRfOuDcG7i-BCpPZ0rWgmKsQ=.33820f6f-8d66-42fc-af25-d8bfdd164afa@github.com> On Sat, 28 Aug 2021 02:34:48 GMT, Roger Riggs wrote: >> The intermittent test in java/lang/ProcessBuilder/Basic.java has identified unexpected messages from a child Java VM >> as the cause of the test failure. Attempts to control the output of the child VM have failed, the VM is unrepentant . >> >> There is no functionality in the child except to wait long enough for the test to finish and the child is destroyed. >> The fix is to switch from using a Java child to using a native child; a new executable `sleepmillis`. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Revised to use native /bin/sleep program on Unix* (non-Windows). > For Windows, a native "BasicSleep" program is used. I've had very inconsistent results using the Windows 'timeout' command. There appear to multiple versions. Some give an error message "Type "TIMEOUT /?" for usage.", (Windows 10) others a error message "Try 'timeout --help' for more information." (Windows 2016) And in some cases, it does not appear to wait the entire time requested and one of the test fails. ------------- PR: https://git.openjdk.java.net/jdk/pull/5239 From vlivanov at openjdk.java.net Wed Sep 1 16:16:38 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Wed, 1 Sep 2021 16:16:38 GMT Subject: RFR: 8273000: Remove WeakReference-based class initialisation barrier implementation [v2] In-Reply-To: References: Message-ID: > Get rid of WeakReference-based logic in DirectMethodHandle::checkInitialized() and reimplement it with `Unsafe::ensureClassInitialized()`/`shouldBeInitialized()`. > > The key observation is that `Unsafe::ensureClassInitialized()` does not block the initializing thread. > > Also, removed `Unsafe::shouldBeInitialized()` in `DMH::shouldBeInitialized(MemberName)` to save on calling into the VM. > `Unsafe::ensureClassInitialized()` already has a fast-path check which checks whether the class is fully initialized or not. > > Testing: tier1 - tier6 Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: Improve comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5258/files - new: https://git.openjdk.java.net/jdk/pull/5258/files/9fc92167..64f2de83 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5258&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5258&range=00-01 Stats: 13 lines in 2 files changed: 8 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/5258.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5258/head:pull/5258 PR: https://git.openjdk.java.net/jdk/pull/5258 From vlivanov at openjdk.java.net Wed Sep 1 16:17:02 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Wed, 1 Sep 2021 16:17:02 GMT Subject: RFR: 8273000: Remove WeakReference-based class initialisation barrier implementation [v2] In-Reply-To: References: Message-ID: On Tue, 31 Aug 2021 16:36:58 GMT, Mandy Chung wrote: > May i suggest that we add some JavaDoc to ensureClassInitialized Thanks, Paul. How does the latest version look? ------------- PR: https://git.openjdk.java.net/jdk/pull/5258 From vlivanov at openjdk.java.net Wed Sep 1 16:17:48 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Wed, 1 Sep 2021 16:17:48 GMT Subject: RFR: 8273000: Remove WeakReference-based class initialisation barrier implementation [v2] In-Reply-To: References: Message-ID: <0g2QBkppRd_-j2xM4Cwb0c9X2NPUAAR3vQ36Nla-wzY=.65bbefea-8f51-49c4-9887-20e6239abb3c@github.com> On Thu, 26 Aug 2021 23:49:07 GMT, David Holmes wrote: >> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: >> >> Improve comments > > src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java line 385: > >> 383: Class defc = member.getDeclaringClass(); >> 384: UNSAFE.ensureClassInitialized(defc); // initialization barrier; blocks unless called by the initializing thread >> 385: return !UNSAFE.shouldBeInitialized(defc); // keep the barrier if the initialization is still in progress > > I think some more elaborate commentary about the possibility of this being called while of defc is already on the call stack, would be worthwhile - the existing comments are a little too subtle IMO. > > > UNSAFE.ensureClassInitialized(defc); > // Once we get here either defc was fully initialized by another thread, or > // defc was already being initialized by the current thread. In the latter case > // the barrier must remain. We can detect this simply by checking if initialization > // is still needed. > return !UNSAFE.shouldBeInitialized(defc); Thanks, David. I incorporated your suggestion in the latest version. ------------- PR: https://git.openjdk.java.net/jdk/pull/5258 From vlivanov at openjdk.java.net Wed Sep 1 16:23:46 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Wed, 1 Sep 2021 16:23:46 GMT Subject: RFR: 8078641: MethodHandle.asTypeCache can retain classes from unloading [v2] In-Reply-To: References: Message-ID: > `MethodHandle.asTypeCache` keeps a strong reference to adapted `MethodHandle` and it can introduce a class loader leak through its `MethodType`. > > Proposed fix introduces a 2-level cache (1 element each) where 1st level can only contain `MethodHandle`s which are guaranteed to not introduce any dependencies on new class loaders compared to the original `MethodHandle`. 2nd level is backed by a `SoftReference` and is used as a backup when the result of `MethodHandle.asType()` conversion can't populate the higher level cache. > > The fix is based on [the work](http://cr.openjdk.java.net/~plevart/jdk9-dev/MethodHandle.asTypeCacheLeak/) made by Peter Levart @plevart back in 2015. > > Testing: tier1 - tier6 Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5246/files - new: https://git.openjdk.java.net/jdk/pull/5246/files/87154817..b21111c0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5246&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5246&range=00-01 Stats: 13 lines in 1 file changed: 4 ins; 1 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/5246.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5246/head:pull/5246 PR: https://git.openjdk.java.net/jdk/pull/5246 From vlivanov at openjdk.java.net Wed Sep 1 16:24:04 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Wed, 1 Sep 2021 16:24:04 GMT Subject: RFR: 8078641: MethodHandle.asTypeCache can retain classes from unloading In-Reply-To: References: Message-ID: <5bhEOWBwxus7-vyb0J9ROhKj6qwcxTBn3DQC05mQlEs=.f6bddb9a-05d6-41fe-82c8-2c4e9f033510@github.com> On Wed, 25 Aug 2021 09:31:51 GMT, Vladimir Ivanov wrote: > `MethodHandle.asTypeCache` keeps a strong reference to adapted `MethodHandle` and it can introduce a class loader leak through its `MethodType`. > > Proposed fix introduces a 2-level cache (1 element each) where 1st level can only contain `MethodHandle`s which are guaranteed to not introduce any dependencies on new class loaders compared to the original `MethodHandle`. 2nd level is backed by a `SoftReference` and is used as a backup when the result of `MethodHandle.asType()` conversion can't populate the higher level cache. > > The fix is based on [the work](http://cr.openjdk.java.net/~plevart/jdk9-dev/MethodHandle.asTypeCacheLeak/) made by Peter Levart @plevart back in 2015. > > Testing: tier1 - tier6 Thanks for the reviews, Paul and Mandy. What do you think about the latest version? ------------- PR: https://git.openjdk.java.net/jdk/pull/5246 From rriggs at openjdk.java.net Wed Sep 1 16:42:47 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 1 Sep 2021 16:42:47 GMT Subject: RFR: 8273242: (test) Refactor to use TestNG for RuntimeTests ExecCommand tests Message-ID: The ExecCommand test of Runtime.exec is difficult to maintain; the parallel arrays are hard to keep in sync. This cleanup converts to use TestNG DataProviders and other improvements. ------------- Commit messages: - 8273242: Refactored ExecCommand to use TestNG DataProvider for cases Changes: https://git.openjdk.java.net/jdk/pull/5335/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5335&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273242 Stats: 270 lines in 1 file changed: 137 ins; 97 del; 36 mod Patch: https://git.openjdk.java.net/jdk/pull/5335.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5335/head:pull/5335 PR: https://git.openjdk.java.net/jdk/pull/5335 From github.com+5381337+cc007 at openjdk.java.net Wed Sep 1 17:30:17 2021 From: github.com+5381337+cc007 at openjdk.java.net (CC007) Date: Wed, 1 Sep 2021 17:30:17 GMT Subject: RFR: 8272137: Make Collection and Optional classes streamable In-Reply-To: References: Message-ID: On Mon, 9 Aug 2021 12:28:23 GMT, CC007 wrote: > create Streamable and ParallelStreamable interface and use them in Collection and Optional > _Mailing list message from [Alan Snyder](mailto:javalists at cbfiddle.com) on [core-libs-dev](mailto:core-libs-dev at mail.openjdk.java.net):_ > > Ah, if only one could define a type alias Streamable = Supplier>... If you use that, you'd lose some semantics that the method name would have given you. I feel that @liach 's solution is cleaner, since that preserves this method name. ------------- PR: https://git.openjdk.java.net/jdk/pull/5050 From mchung at openjdk.java.net Wed Sep 1 17:31:12 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 1 Sep 2021 17:31:12 GMT Subject: RFR: 8078641: MethodHandle.asTypeCache can retain classes from unloading [v2] In-Reply-To: References: Message-ID: On Wed, 1 Sep 2021 16:23:46 GMT, Vladimir Ivanov wrote: >> `MethodHandle.asTypeCache` keeps a strong reference to adapted `MethodHandle` and it can introduce a class loader leak through its `MethodType`. >> >> Proposed fix introduces a 2-level cache (1 element each) where 1st level can only contain `MethodHandle`s which are guaranteed to not introduce any dependencies on new class loaders compared to the original `MethodHandle`. 2nd level is backed by a `SoftReference` and is used as a backup when the result of `MethodHandle.asType()` conversion can't populate the higher level cache. >> >> The fix is based on [the work](http://cr.openjdk.java.net/~plevart/jdk9-dev/MethodHandle.asTypeCacheLeak/) made by Peter Levart @plevart back in 2015. >> >> Testing: tier1 - tier6 > > Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments src/java.base/share/classes/java/lang/invoke/MethodHandle.java line 926: > 924: /* Returns true when {@code loader} keeps {@code cls} either directly or indirectly through the loader delegation chain. */ > 925: private static boolean keepsAlive(Class cls, ClassLoader loader) { > 926: return keepsAlive(cls.getClassLoader(), loader); Suggestion: ClassLoader defLoader = cls.getClassLoader(); if (isBuiltinLoader(defLoader)) { return true; // built-in loaders are always reachable } return keepsAlive(defLoader, loader); I think it's clearer to check if `cls` is not defined by any builtin loader here and then check if `loader` keeps `cls` alive. So `keepsAlive(ClassLoader loader1, ClassLoader loader2)` is not needed and replace line 935 and 940 to `keepsAlive(Class, ClassLoader)` instead. ------------- PR: https://git.openjdk.java.net/jdk/pull/5246 From dcubed at openjdk.java.net Wed Sep 1 17:42:28 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 1 Sep 2021 17:42:28 GMT Subject: RFR: 8273248: ProblemList java/lang/instrument/BootClassPath/BootClassPathTest.sh on all configs Message-ID: <8yAn_t7lLh2Gj_GEB7rsCHIji0tbZbIV-SPRJR67HXE=.5a12bad5-c883-4982-bbcd-77fb90e5a5e9@github.com> A trivial fix to ProblemList java/lang/instrument/BootClassPath/BootClassPathTest.sh on all configs. ------------- Commit messages: - 8273248: ProblemList java/lang/instrument/BootClassPath/BootClassPathTest.sh on all configs Changes: https://git.openjdk.java.net/jdk/pull/5337/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5337&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273248 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5337.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5337/head:pull/5337 PR: https://git.openjdk.java.net/jdk/pull/5337 From naoto at openjdk.java.net Wed Sep 1 17:42:29 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 1 Sep 2021 17:42:29 GMT Subject: RFR: 8273248: ProblemList java/lang/instrument/BootClassPath/BootClassPathTest.sh on all configs In-Reply-To: <8yAn_t7lLh2Gj_GEB7rsCHIji0tbZbIV-SPRJR67HXE=.5a12bad5-c883-4982-bbcd-77fb90e5a5e9@github.com> References: <8yAn_t7lLh2Gj_GEB7rsCHIji0tbZbIV-SPRJR67HXE=.5a12bad5-c883-4982-bbcd-77fb90e5a5e9@github.com> Message-ID: On Wed, 1 Sep 2021 17:33:13 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList java/lang/instrument/BootClassPath/BootClassPathTest.sh on all configs. Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5337 From dcubed at openjdk.java.net Wed Sep 1 17:48:33 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 1 Sep 2021 17:48:33 GMT Subject: Integrated: 8273197: ProblemList 2 jtools tests due to JDK-8273187 In-Reply-To: References: Message-ID: On Tue, 31 Aug 2021 20:02:37 GMT, Naoto Sato wrote: >> Trivial fixes to reduce the noise in the JDK18 CI: >> JDK-8273197 ProblemList 2 jtools tests due to JDK-8273187 >> JDK-8273198 ProblemList java/lang/instrument/BootClassPath/BootClassPathTest.sh due to JDK-8273188 >> >> These failures happen in Tier5 so I'm ProblemListing them now to give @naotoj time to >> work on the issues introduced by JDK-8260265 UTF-8 by Default. > > Marked as reviewed by naoto (Reviewer). @naotoj - Thanks for the review! (I forgot to post yesterday) ------------- PR: https://git.openjdk.java.net/jdk/pull/5321 From dcubed at openjdk.java.net Wed Sep 1 17:49:33 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 1 Sep 2021 17:49:33 GMT Subject: RFR: 8273248: ProblemList java/lang/instrument/BootClassPath/BootClassPathTest.sh on all configs In-Reply-To: References: <8yAn_t7lLh2Gj_GEB7rsCHIji0tbZbIV-SPRJR67HXE=.5a12bad5-c883-4982-bbcd-77fb90e5a5e9@github.com> Message-ID: <3WYXAfBSiqZ7xd-6idwuc6Vn_3AD9GdclWawnV6n41g=.81682de0-90f0-4378-aa6a-25c924e782cd@github.com> On Wed, 1 Sep 2021 17:35:12 GMT, Naoto Sato wrote: >> A trivial fix to ProblemList java/lang/instrument/BootClassPath/BootClassPathTest.sh on all configs. > > Marked as reviewed by naoto (Reviewer). @naotoj - Thanks for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/5337 From dcubed at openjdk.java.net Wed Sep 1 17:49:34 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 1 Sep 2021 17:49:34 GMT Subject: Integrated: 8273248: ProblemList java/lang/instrument/BootClassPath/BootClassPathTest.sh on all configs In-Reply-To: <8yAn_t7lLh2Gj_GEB7rsCHIji0tbZbIV-SPRJR67HXE=.5a12bad5-c883-4982-bbcd-77fb90e5a5e9@github.com> References: <8yAn_t7lLh2Gj_GEB7rsCHIji0tbZbIV-SPRJR67HXE=.5a12bad5-c883-4982-bbcd-77fb90e5a5e9@github.com> Message-ID: <70I-zujvEsVJGyVtWwjn5PnAFeflQvGoI50doKfVPq8=.190805d3-c45a-4fca-ab25-e1e04a8ce43b@github.com> On Wed, 1 Sep 2021 17:33:13 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList java/lang/instrument/BootClassPath/BootClassPathTest.sh on all configs. This pull request has now been integrated. Changeset: 4ee0dace Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/4ee0dacecd5afc5876ea839ffbb5df962ff6cd08 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8273248: ProblemList java/lang/instrument/BootClassPath/BootClassPathTest.sh on all configs Reviewed-by: naoto ------------- PR: https://git.openjdk.java.net/jdk/pull/5337 From github.com+70726043+rgiulietti at openjdk.java.net Wed Sep 1 18:20:34 2021 From: github.com+70726043+rgiulietti at openjdk.java.net (Raffaello Giulietti) Date: Wed, 1 Sep 2021 18:20:34 GMT Subject: Withdrawn: 8271602: Add Math.ceilDiv() family parallel to Math.floorDiv() family In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 18:53:23 GMT, Raffaello Giulietti wrote: > Please review this PR to add officially endorsed `ceilDiv()` and `ceilMod()` methods do `j.l.[Strict]Math`. > > Beside adding fresh tests to `test/jdk/java/lang/Math/DivModTests.java`, this PR also corrects small typos in it and exercises tests that were already present but which were never invoked. > Let me know if this is acceptable for a test or if there's a need of a separate issue in the JBS. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/5285 From psandoz at openjdk.java.net Wed Sep 1 18:33:32 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 1 Sep 2021 18:33:32 GMT Subject: RFR: 8273000: Remove WeakReference-based class initialisation barrier implementation [v2] In-Reply-To: References: Message-ID: On Wed, 1 Sep 2021 16:16:38 GMT, Vladimir Ivanov wrote: >> Get rid of WeakReference-based logic in DirectMethodHandle::checkInitialized() and reimplement it with `Unsafe::ensureClassInitialized()`/`shouldBeInitialized()`. >> >> The key observation is that `Unsafe::ensureClassInitialized()` does not block the initializing thread. >> >> Also, removed `Unsafe::shouldBeInitialized()` in `DMH::shouldBeInitialized(MemberName)` to save on calling into the VM. >> `Unsafe::ensureClassInitialized()` already has a fast-path check which checks whether the class is fully initialized or not. >> >> Testing: tier1 - tier6 > > Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > Improve comments Looks good, just a minor suggestion up to you to accept or not. src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 1152: > 1150: * The call returns when either class {@code c} is fully initialized or > 1151: * class {@code c} is being initialized and the call is performed from > 1152: * the initializing thread. Suggestion: * The call returns when either class {@code c} is fully initialized or * class {@code c} is being initialized and the call is performed from * the initializing thread. In the latter case a subsequent call to * {@link #shouldBeInitialized}, from the calling thread of this call, * will return {@code true}. ------------- Marked as reviewed by psandoz (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5258 From lancea at openjdk.java.net Wed Sep 1 19:32:49 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 1 Sep 2021 19:32:49 GMT Subject: RFR: 8273250: Address javadoc issues in Deflater::setDictionationary Message-ID: Hi, Please review this trivial fix to the javadoc which addresses an issue shown via Intellij where the error: "Symbol 'getAdler' is inaccessible from here" is generated for the "@See Inflater#getAlder" references. Best Lance ------------- Commit messages: - Address JDK-8273250 Changes: https://git.openjdk.java.net/jdk/pull/5340/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5340&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273250 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/5340.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5340/head:pull/5340 PR: https://git.openjdk.java.net/jdk/pull/5340 From igraves at openjdk.java.net Wed Sep 1 19:38:52 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Wed, 1 Sep 2021 19:38:52 GMT Subject: RFR: 8214761: Bug in parallel Kahan summation implementation [v4] In-Reply-To: References: Message-ID: > 8214761: Bug in parallel Kahan summation implementation Ian Graves has updated the pull request incrementally with one additional commit since the last revision: Fixing compensation test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4674/files - new: https://git.openjdk.java.net/jdk/pull/4674/files/905450d8..722826fc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4674&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4674&range=02-03 Stats: 13 lines in 1 file changed: 5 ins; 4 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/4674.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4674/head:pull/4674 PR: https://git.openjdk.java.net/jdk/pull/4674 From rriggs at openjdk.java.net Wed Sep 1 19:41:27 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 1 Sep 2021 19:41:27 GMT Subject: RFR: 8273250: Address javadoc issues in Deflater::setDictionationary In-Reply-To: References: Message-ID: On Wed, 1 Sep 2021 19:26:17 GMT, Lance Andersen wrote: > Hi, > > Please review this trivial fix to the javadoc which addresses an issue shown via Intellij where the error: "Symbol 'getAdler' is inaccessible from here" is generated for the "@See Inflater#getAlder" references. > > Best > Lance Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5340 From naoto at openjdk.java.net Wed Sep 1 19:58:28 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 1 Sep 2021 19:58:28 GMT Subject: RFR: 8273250: Address javadoc issues in Deflater::setDictionationary In-Reply-To: References: Message-ID: On Wed, 1 Sep 2021 19:26:17 GMT, Lance Andersen wrote: > Hi, > > Please review this trivial fix to the javadoc which addresses an issue shown via Intellij where the error: "Symbol 'getAdler' is inaccessible from here" is generated for the "@See Inflater#getAlder" references. > > Best > Lance Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5340 From iris at openjdk.java.net Wed Sep 1 20:13:29 2021 From: iris at openjdk.java.net (Iris Clark) Date: Wed, 1 Sep 2021 20:13:29 GMT Subject: RFR: 8273250: Address javadoc issues in Deflater::setDictionationary In-Reply-To: References: Message-ID: On Wed, 1 Sep 2021 19:26:17 GMT, Lance Andersen wrote: > Hi, > > Please review this trivial fix to the javadoc which addresses an issue shown via Intellij where the error: "Symbol 'getAdler' is inaccessible from here" is generated for the "@See Inflater#getAlder" references. > > Best > Lance Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5340 From github.com+70726043+rgiulietti at openjdk.java.net Wed Sep 1 20:21:41 2021 From: github.com+70726043+rgiulietti at openjdk.java.net (Raffaello Giulietti) Date: Wed, 1 Sep 2021 20:21:41 GMT Subject: RFR: 8271602: Add Math.ceilDiv() family parallel to Math.floorDiv() family Message-ID: <2RZKAf-GYIh36SSVTA-22F4qXJ72qNSwO3ZIO9wl9kE=.b08de4f8-34da-4658-9a05-1eec7bce88f4@github.com> This PR ideally continues #5285, which has been closed as a consequence of inadvertently removing the branch on my repo. See there for initial discussion. Sorry for the mess. ------------- Commit messages: - 8271602: Add Math.ceilDiv() family parallel to Math.floorDiv() family Changes: https://git.openjdk.java.net/jdk/pull/5341/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5341&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271602 Stats: 1093 lines in 4 files changed: 1040 ins; 0 del; 53 mod Patch: https://git.openjdk.java.net/jdk/pull/5341.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5341/head:pull/5341 PR: https://git.openjdk.java.net/jdk/pull/5341 From mchung at openjdk.java.net Wed Sep 1 21:07:48 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 1 Sep 2021 21:07:48 GMT Subject: RFR: JDK-8273194: Document the two possible cases when Lookup::ensureInitialized returns Message-ID: Improve the specification to document the cases when `Lookup::ensureInitialized` returns as specified JVMS 5.5 and matches the implementation. Please also review CSR: https://bugs.openjdk.java.net/browse/JDK-8273253 ------------- Commit messages: - JDK-8273194: Document the two possible cases when Lookup::ensureInitialized returns Changes: https://git.openjdk.java.net/jdk/pull/5343/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5343&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273194 Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5343.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5343/head:pull/5343 PR: https://git.openjdk.java.net/jdk/pull/5343 From bpb at openjdk.java.net Wed Sep 1 22:56:29 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 1 Sep 2021 22:56:29 GMT Subject: RFR: 8273250: Address javadoc issues in Deflater::setDictionationary In-Reply-To: References: Message-ID: On Wed, 1 Sep 2021 19:26:17 GMT, Lance Andersen wrote: > Hi, > > Please review this trivial fix to the javadoc which addresses an issue shown via Intellij where the error: "Symbol 'getAdler' is inaccessible from here" is generated for the "@See Inflater#getAlder" references. > > Best > Lance Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5340 From dholmes at openjdk.java.net Thu Sep 2 05:00:42 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 2 Sep 2021 05:00:42 GMT Subject: RFR: 8272600: (test) Use native "sleep" in Basic.java [v3] In-Reply-To: References: Message-ID: On Wed, 1 Sep 2021 15:02:44 GMT, Roger Riggs wrote: >> test/jdk/java/lang/ProcessBuilder/Basic.java line 2665: >> >>> 2663: >>> 2664: Path exePath = Path.of(TEST_NATIVEPATH).resolve("BasicSleep.exe"); >>> 2665: System.out.println("exePath: " + exePath + ", canExec: " + exePath.toFile().canExecute()); >> >> What is this for?? > > Ioi was concerned that the fallback to Java would be used silently and the old intermittent issue would return. Well Ioi asked for a comment explaining why the fallback was necessary, but the println doesn't explain anything. I assume it should say something like "Unable to find ... falling back to Java version"? ------------- PR: https://git.openjdk.java.net/jdk/pull/5239 From dholmes at openjdk.java.net Thu Sep 2 05:07:31 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 2 Sep 2021 05:07:31 GMT Subject: RFR: 8272600: (test) Use native "sleep" in Basic.java [v3] In-Reply-To: <5lAYyqoz8qRPN3cWTfbLRfOuDcG7i-BCpPZ0rWgmKsQ=.33820f6f-8d66-42fc-af25-d8bfdd164afa@github.com> References: <5lAYyqoz8qRPN3cWTfbLRfOuDcG7i-BCpPZ0rWgmKsQ=.33820f6f-8d66-42fc-af25-d8bfdd164afa@github.com> Message-ID: On Wed, 1 Sep 2021 15:12:16 GMT, Roger Riggs wrote: > I've had very inconsistent results using the Windows 'timeout' command. > There appear to multiple versions. Some give an error message "Type "TIMEOUT /?" for usage.", (Windows 10) > others a error message "Try 'timeout --help' for more information." (Windows 2016) > And in some cases, it does not appear to wait the entire time requested and one of the test fails. The `timeout --help` does not appear to be the Windows command, but a bash variant so I'm assuming you were running under Cygwin or some such environment? Note it is completely different to the Windows timeout command and not what you want. ------------- PR: https://git.openjdk.java.net/jdk/pull/5239 From dholmes at openjdk.java.net Thu Sep 2 05:07:31 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 2 Sep 2021 05:07:31 GMT Subject: RFR: 8272600: (test) Use native "sleep" in Basic.java [v3] In-Reply-To: References: Message-ID: <2tAzFZfjyxyJcXNCjHOt_DWTRFoTuSC2yZ8g_7Eol1I=.4b167fb2-66b7-49d6-926e-84d49d376958@github.com> On Sat, 28 Aug 2021 02:34:48 GMT, Roger Riggs wrote: >> The intermittent test in java/lang/ProcessBuilder/Basic.java has identified unexpected messages from a child Java VM >> as the cause of the test failure. Attempts to control the output of the child VM have failed, the VM is unrepentant . >> >> There is no functionality in the child except to wait long enough for the test to finish and the child is destroyed. >> The fix is to switch from using a Java child to using a native child; a new executable `sleepmillis`. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Revised to use native /bin/sleep program on Unix* (non-Windows). > For Windows, a native "BasicSleep" program is used. BTW if running the tests on Windows under Cygwin etc then it should find /usr/bin/sleep anyway. ------------- PR: https://git.openjdk.java.net/jdk/pull/5239 From dholmes at openjdk.java.net Thu Sep 2 05:11:35 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 2 Sep 2021 05:11:35 GMT Subject: RFR: 8273000: Remove WeakReference-based class initialisation barrier implementation [v2] In-Reply-To: References: Message-ID: On Wed, 1 Sep 2021 18:28:30 GMT, Paul Sandoz wrote: >> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: >> >> Improve comments > > src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 1152: > >> 1150: * The call returns when either class {@code c} is fully initialized or >> 1151: * class {@code c} is being initialized and the call is performed from >> 1152: * the initializing thread. > > Suggestion: > > * The call returns when either class {@code c} is fully initialized or > * class {@code c} is being initialized and the call is performed from > * the initializing thread. In the latter case a subsequent call to > * {@link #shouldBeInitialized}, from the calling thread of this call, > * will return {@code true}. Aren't "the calling thread of this call" and "the initializing thread" the same thread in the latter case? ------------- PR: https://git.openjdk.java.net/jdk/pull/5258 From mbaesken at openjdk.java.net Thu Sep 2 06:50:40 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Thu, 2 Sep 2021 06:50:40 GMT Subject: RFR: JDK-8273229: Update OS detection code to recognize Windows Server 2022 Message-ID: Hello, please review this small change. The OS detection code of the JDK/JVM should recognize the new Windows server 2022 : https://docs.microsoft.com/en-us/lifecycle/products/windows-server-2022 https://docs.microsoft.com/en-us/windows-server/get-started/windows-server-release-info The build number of Windows server 2022 according to the documentation in the second link is 20348 . Thanks, Matthias ------------- Commit messages: - JDK-8273229 Changes: https://git.openjdk.java.net/jdk/pull/5347/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5347&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273229 Stats: 11 lines in 2 files changed: 8 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5347.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5347/head:pull/5347 PR: https://git.openjdk.java.net/jdk/pull/5347 From github.com+741251+turbanoff at openjdk.java.net Thu Sep 2 07:07:43 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Thu, 2 Sep 2021 07:07:43 GMT Subject: RFR: 8273261: Replace 'while' cycles with iterator with enhanced-for in java.base Message-ID: <_l91WAZVqQeJUgX-ZH5CIgHap5TPzIZzI6zYVskXBjI=.ac99b92f-3270-4044-b0fe-d6d48be9d726@github.com> There are few places in code where manual while loop is used with Iterator to iterate over Collection. Instead of manual while cycles it's preferred to use enhanced-for cycle instead: it's less verbose, makes code easier to read and it's less error-prone. It doesn't have any performance impact: java compiler generates similar code when compiling enhanced-for cycle. Similar cleanups: * https://bugs.openjdk.java.net/browse/JDK-8258006 * https://bugs.openjdk.java.net/browse/JDK-8257912 ------------- Commit messages: - [PATCH] Replace while cycles with iterator with enhanced-for in java.base Changes: https://git.openjdk.java.net/jdk/pull/5328/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5328&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273261 Stats: 93 lines in 11 files changed: 1 ins; 50 del; 42 mod Patch: https://git.openjdk.java.net/jdk/pull/5328.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5328/head:pull/5328 PR: https://git.openjdk.java.net/jdk/pull/5328 From github.com+741251+turbanoff at openjdk.java.net Thu Sep 2 07:07:43 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Thu, 2 Sep 2021 07:07:43 GMT Subject: RFR: 8273261: Replace 'while' cycles with iterator with enhanced-for in java.base In-Reply-To: <_l91WAZVqQeJUgX-ZH5CIgHap5TPzIZzI6zYVskXBjI=.ac99b92f-3270-4044-b0fe-d6d48be9d726@github.com> References: <_l91WAZVqQeJUgX-ZH5CIgHap5TPzIZzI6zYVskXBjI=.ac99b92f-3270-4044-b0fe-d6d48be9d726@github.com> Message-ID: On Wed, 1 Sep 2021 07:37:53 GMT, Andrey Turbanov wrote: > There are few places in code where manual while loop is used with Iterator to iterate over Collection. > Instead of manual while cycles it's preferred to use enhanced-for cycle instead: it's less verbose, makes code easier to read and it's less error-prone. > It doesn't have any performance impact: java compiler generates similar code when compiling enhanced-for cycle. > > Similar cleanups: > * https://bugs.openjdk.java.net/browse/JDK-8258006 > * https://bugs.openjdk.java.net/browse/JDK-8257912 Tested "tier2" on linux-x86_64-server-fastdebug Ubuntu 21.04 ============================== Test summary ============================== TEST TOTAL PASS FAIL ERROR >> jtreg:test/jdk:tier2 3772 3771 1 0 << jtreg:test/langtools:tier2 11 11 0 0 jtreg:test/jaxp:tier2 452 452 0 0 ============================== TEST FAILURE Only one test `java/nio/file/FileStore/Basic.java` failed, but it fails without my changes too. ----------System.out:(46/2591)---------- ------------- PR: https://git.openjdk.java.net/jdk/pull/5328 From alanb at openjdk.java.net Thu Sep 2 07:49:27 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 2 Sep 2021 07:49:27 GMT Subject: RFR: JDK-8273229: Update OS detection code to recognize Windows Server 2022 In-Reply-To: References: Message-ID: On Thu, 2 Sep 2021 06:43:16 GMT, Matthias Baesken wrote: > Hello, please review this small change. > The OS detection code of the JDK/JVM should recognize the new Windows server 2022 : > > https://docs.microsoft.com/en-us/lifecycle/products/windows-server-2022 > https://docs.microsoft.com/en-us/windows-server/get-started/windows-server-release-info > > The build number of Windows server 2022 according to the documentation in the second link is 20348 . > Thanks, Matthias The link to the "Windows Server release information" page is useful to check the build number - thanks! ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5347 From dholmes at openjdk.java.net Thu Sep 2 07:53:29 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 2 Sep 2021 07:53:29 GMT Subject: RFR: JDK-8273229: Update OS detection code to recognize Windows Server 2022 In-Reply-To: References: Message-ID: On Thu, 2 Sep 2021 06:43:16 GMT, Matthias Baesken wrote: > Hello, please review this small change. > The OS detection code of the JDK/JVM should recognize the new Windows server 2022 : > > https://docs.microsoft.com/en-us/lifecycle/products/windows-server-2022 > https://docs.microsoft.com/en-us/windows-server/get-started/windows-server-release-info > > The build number of Windows server 2022 according to the documentation in the second link is 20348 . > Thanks, Matthias Hi Matthias, Some minor suggestions but okay as-is. Thanks, David src/hotspot/os/windows/os_windows.cpp line 1871: > 1869: // distinguish Windows Server 2016, 2019 and 2022 by build number > 1870: // Windows server 2019 GA 10/2018 build number is 17763 > 1871: // Windows server 2022 build number is 20348 Perhaps to avoid too much future editing: // Distinguish Windows Server by build number: // - 2016 GA 10/2016 build: 14393 // - 2019 GA 11/2018 build: 17763 // - 2022 GA 08/2021 build: 20348 src/java.base/windows/native/libjava/java_props_md.c line 478: > 476: * where (buildNumber > 17762) > 477: * Windows Server 2022 10 0 (!VER_NT_WORKSTATION) > 478: * where (buildNumber > 20347) There is a comment at line 392 that you may want to adjust too - perhaps just say "Windows Server 2016+" to avoid the need to keep updating it. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5347 From github.com+10835776+stsypanov at openjdk.java.net Thu Sep 2 08:13:37 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Thu, 2 Sep 2021 08:13:37 GMT Subject: Integrated: 8273140: Replace usages of Enum.class.getEnumConstants() with Enum.values() where possible In-Reply-To: <4N-BgoVLVgZk_uPkRLoY-427bF-kKKwDr1zRHI7o1PI=.dcdbec6e-f3f8-48e4-94ce-a88d7e494c41@github.com> References: <4N-BgoVLVgZk_uPkRLoY-427bF-kKKwDr1zRHI7o1PI=.dcdbec6e-f3f8-48e4-94ce-a88d7e494c41@github.com> Message-ID: <43jcu3pT9PMTk266WJaSVQ_4Yyv1FV3rhR6efbpxjPA=.5e1cec47-2d47-4b27-a5a6-8e6cd2467b48@github.com> On Mon, 30 Aug 2021 14:26:56 GMT, ?????? ??????? wrote: > Just a very tiny clean-up. > > There are some places in JDK code base where we call `Enum.class.getEnumConstants()` to get all the values of the referenced `enum`. This is excessive, less-readable and slower than just calling `Enum.values()` as in `getEnumConstants()` we have volatile access: > > public T[] getEnumConstants() { > T[] values = getEnumConstantsShared(); > return (values != null) ? values.clone() : null; > } > > private transient volatile T[] enumConstants; > > T[] getEnumConstantsShared() { > T[] constants = enumConstants; > if (constants == null) { /* ... */ } > return constants; > } > > Calling values() method is slightly faster: > > @BenchmarkMode(Mode.AverageTime) > @OutputTimeUnit(TimeUnit.NANOSECONDS) > @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) > public class EnumBenchmark { > > @Benchmark > public Enum[] values() { > return Enum.values(); > } > > @Benchmark > public Enum[] getEnumConstants() { > return Enum.class.getEnumConstants(); > } > > private enum Enum { > A, > B > } > } > > > Benchmark Mode Cnt Score Error Units > EnumBenchmark.getEnumConstants avgt 15 6,265 ? 0,051 ns/op > EnumBenchmark.getEnumConstants:?gc.alloc.rate avgt 15 2434,075 ? 19,568 MB/sec > EnumBenchmark.getEnumConstants:?gc.alloc.rate.norm avgt 15 24,002 ? 0,001 B/op > EnumBenchmark.getEnumConstants:?gc.churn.G1_Eden_Space avgt 15 2433,709 ? 70,216 MB/sec > EnumBenchmark.getEnumConstants:?gc.churn.G1_Eden_Space.norm avgt 15 23,998 ? 0,659 B/op > EnumBenchmark.getEnumConstants:?gc.churn.G1_Survivor_Space avgt 15 0,009 ? 0,003 MB/sec > EnumBenchmark.getEnumConstants:?gc.churn.G1_Survivor_Space.norm avgt 15 ? 10?? B/op > EnumBenchmark.getEnumConstants:?gc.count avgt 15 210,000 counts > EnumBenchmark.getEnumConstants:?gc.time avgt 15 119,000 ms > > EnumBenchmark.values avgt 15 4,164 ? 0,134 ns/op > EnumBenchmark.values:?gc.alloc.rate avgt 15 3665,341 ? 120,721 MB/sec > EnumBenchmark.values:?gc.alloc.rate.norm avgt 15 24,002 ? 0,001 B/op > EnumBenchmark.values:?gc.churn.G1_Eden_Space avgt 15 3660,512 ? 137,250 MB/sec > EnumBenchmark.values:?gc.churn.G1_Eden_Space.norm avgt 15 23,972 ? 0,529 B/op > EnumBenchmark.values:?gc.churn.G1_Survivor_Space avgt 15 0,017 ? 0,003 MB/sec > EnumBenchmark.values:?gc.churn.G1_Survivor_Space.norm avgt 15 ? 10?? B/op > EnumBenchmark.values:?gc.count avgt 15 262,000 counts > EnumBenchmark.values:?gc.time avgt 15 155,000 ms This pull request has now been integrated. Changeset: 152e6692 Author: Sergey Tsypanov Committer: Thomas Schatzl URL: https://git.openjdk.java.net/jdk/commit/152e66923dc36cfd83cdfe18e96631abc06b9199 Stats: 13 lines in 4 files changed: 0 ins; 2 del; 11 mod 8273140: Replace usages of Enum.class.getEnumConstants() with Enum.values() where possible Reviewed-by: tschatzl ------------- PR: https://git.openjdk.java.net/jdk/pull/5303 From mbaesken at openjdk.java.net Thu Sep 2 08:16:52 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Thu, 2 Sep 2021 08:16:52 GMT Subject: RFR: JDK-8273229: Update OS detection code to recognize Windows Server 2022 [v2] In-Reply-To: References: Message-ID: > Hello, please review this small change. > The OS detection code of the JDK/JVM should recognize the new Windows server 2022 : > > https://docs.microsoft.com/en-us/lifecycle/products/windows-server-2022 > https://docs.microsoft.com/en-us/windows-server/get-started/windows-server-release-info > > The build number of Windows server 2022 according to the documentation in the second link is 20348 . > Thanks, Matthias Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Adjust comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5347/files - new: https://git.openjdk.java.net/jdk/pull/5347/files/c7ce4abc..f8952e3e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5347&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5347&range=00-01 Stats: 5 lines in 2 files changed: 1 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/5347.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5347/head:pull/5347 PR: https://git.openjdk.java.net/jdk/pull/5347 From mbaesken at openjdk.java.net Thu Sep 2 08:16:53 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Thu, 2 Sep 2021 08:16:53 GMT Subject: RFR: JDK-8273229: Update OS detection code to recognize Windows Server 2022 [v2] In-Reply-To: References: Message-ID: On Thu, 2 Sep 2021 07:49:55 GMT, David Holmes wrote: >> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: >> >> Adjust comments > > src/hotspot/os/windows/os_windows.cpp line 1871: > >> 1869: // distinguish Windows Server 2016, 2019 and 2022 by build number >> 1870: // Windows server 2019 GA 10/2018 build number is 17763 >> 1871: // Windows server 2022 build number is 20348 > > Perhaps to avoid too much future editing: > > // Distinguish Windows Server by build number: > // - 2016 GA 10/2016 build: 14393 > // - 2019 GA 11/2018 build: 17763 > // - 2022 GA 08/2021 build: 20348 Hi David , thanks for your suggestions. I adjusted the comments. Best regards, Matthias ------------- PR: https://git.openjdk.java.net/jdk/pull/5347 From serb at openjdk.java.net Thu Sep 2 08:20:53 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 2 Sep 2021 08:20:53 GMT Subject: RFR: 8273101: Eliminate the usage of threadgroup sandboxing in the java.util.logging Message-ID: The "java.util.logging.LogManager" class uses the "threadgroup sandboxing" via an AppContext to support "applet logging isolation". The AppContext class became useless since the plugin and webstart are no longer supported and removed in jdk11. This is the request to delete the usage of AppContext in the LogManager and related tests. Tested by tier1/tier2/tier3 and jdk_desktop tests. ------------- Commit messages: - Some tests deleted - Update the RootLevelInConfigFile test - Initial version of JDK-8273101 Changes: https://git.openjdk.java.net/jdk/pull/5326/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5326&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273101 Stats: 1423 lines in 10 files changed: 0 ins; 1418 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/5326.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5326/head:pull/5326 PR: https://git.openjdk.java.net/jdk/pull/5326 From dholmes at openjdk.java.net Thu Sep 2 08:51:28 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 2 Sep 2021 08:51:28 GMT Subject: RFR: JDK-8273229: Update OS detection code to recognize Windows Server 2022 [v2] In-Reply-To: References: Message-ID: On Thu, 2 Sep 2021 08:16:52 GMT, Matthias Baesken wrote: >> Hello, please review this small change. >> The OS detection code of the JDK/JVM should recognize the new Windows server 2022 : >> >> https://docs.microsoft.com/en-us/lifecycle/products/windows-server-2022 >> https://docs.microsoft.com/en-us/windows-server/get-started/windows-server-release-info >> >> The build number of Windows server 2022 according to the documentation in the second link is 20348 . >> Thanks, Matthias > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Adjust comments Thanks for the updates ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5347 From shade at openjdk.java.net Thu Sep 2 09:16:35 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 2 Sep 2021 09:16:35 GMT Subject: RFR: 8247980: Exclusive execution of java/util/stream tests slows down tier1 In-Reply-To: References: Message-ID: On Tue, 24 Aug 2021 13:18:21 GMT, Christoph Langer wrote: > I have added this to our internal testing, let's see how it goes. Notifying @ArnoZeller about this. Any good or bad results? ------------- PR: https://git.openjdk.java.net/jdk/pull/5189 From dfuchs at openjdk.java.net Thu Sep 2 09:41:30 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 2 Sep 2021 09:41:30 GMT Subject: RFR: 8273261: Replace 'while' cycles with iterator with enhanced-for in java.base In-Reply-To: <_l91WAZVqQeJUgX-ZH5CIgHap5TPzIZzI6zYVskXBjI=.ac99b92f-3270-4044-b0fe-d6d48be9d726@github.com> References: <_l91WAZVqQeJUgX-ZH5CIgHap5TPzIZzI6zYVskXBjI=.ac99b92f-3270-4044-b0fe-d6d48be9d726@github.com> Message-ID: On Wed, 1 Sep 2021 07:37:53 GMT, Andrey Turbanov wrote: > There are few places in code where manual while loop is used with Iterator to iterate over Collection. > Instead of manual while cycles it's preferred to use enhanced-for cycle instead: it's less verbose, makes code easier to read and it's less error-prone. > It doesn't have any performance impact: java compiler generates similar code when compiling enhanced-for cycle. > > Similar cleanups: > * https://bugs.openjdk.java.net/browse/JDK-8258006 > * https://bugs.openjdk.java.net/browse/JDK-8257912 Generally this looks like a good improvement as the resulting code becomes more readable. Changes in sun/net or jar index classes look fine. Please obtain approval from maintainers of the other areas before integrating. ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5328 From mbaesken at openjdk.java.net Thu Sep 2 11:26:35 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Thu, 2 Sep 2021 11:26:35 GMT Subject: Integrated: JDK-8273229: Update OS detection code to recognize Windows Server 2022 In-Reply-To: References: Message-ID: On Thu, 2 Sep 2021 06:43:16 GMT, Matthias Baesken wrote: > Hello, please review this small change. > The OS detection code of the JDK/JVM should recognize the new Windows server 2022 : > > https://docs.microsoft.com/en-us/lifecycle/products/windows-server-2022 > https://docs.microsoft.com/en-us/windows-server/get-started/windows-server-release-info > > The build number of Windows server 2022 according to the documentation in the second link is 20348 . > Thanks, Matthias This pull request has now been integrated. Changeset: c2e015c3 Author: Matthias Baesken URL: https://git.openjdk.java.net/jdk/commit/c2e015c3c1a2274112bb8e6671a85bc7fb624fde Stats: 14 lines in 2 files changed: 9 ins; 0 del; 5 mod 8273229: Update OS detection code to recognize Windows Server 2022 Reviewed-by: alanb, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/5347 From vlivanov at openjdk.java.net Thu Sep 2 11:35:52 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Thu, 2 Sep 2021 11:35:52 GMT Subject: RFR: 8078641: MethodHandle.asTypeCache can retain classes from unloading [v3] In-Reply-To: References: Message-ID: > `MethodHandle.asTypeCache` keeps a strong reference to adapted `MethodHandle` and it can introduce a class loader leak through its `MethodType`. > > Proposed fix introduces a 2-level cache (1 element each) where 1st level can only contain `MethodHandle`s which are guaranteed to not introduce any dependencies on new class loaders compared to the original `MethodHandle`. 2nd level is backed by a `SoftReference` and is used as a backup when the result of `MethodHandle.asType()` conversion can't populate the higher level cache. > > The fix is based on [the work](http://cr.openjdk.java.net/~plevart/jdk9-dev/MethodHandle.asTypeCacheLeak/) made by Peter Levart @plevart back in 2015. > > Testing: tier1 - tier6 Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5246/files - new: https://git.openjdk.java.net/jdk/pull/5246/files/b21111c0..7a87aee3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5246&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5246&range=01-02 Stats: 41 lines in 1 file changed: 15 ins; 18 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/5246.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5246/head:pull/5246 PR: https://git.openjdk.java.net/jdk/pull/5246 From vlivanov at openjdk.java.net Thu Sep 2 11:39:29 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Thu, 2 Sep 2021 11:39:29 GMT Subject: RFR: 8078641: MethodHandle.asTypeCache can retain classes from unloading [v2] In-Reply-To: References: Message-ID: On Wed, 1 Sep 2021 17:28:37 GMT, Mandy Chung wrote: >> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review comments > > src/java.base/share/classes/java/lang/invoke/MethodHandle.java line 926: > >> 924: /* Returns true when {@code loader} keeps {@code cls} either directly or indirectly through the loader delegation chain. */ >> 925: private static boolean keepsAlive(Class cls, ClassLoader loader) { >> 926: return keepsAlive(cls.getClassLoader(), loader); > > Suggestion: > > ClassLoader defLoader = cls.getClassLoader(); > if (isBuiltinLoader(defLoader)) { > return true; // built-in loaders are always reachable > } > return keepsAlive(defLoader, loader); > > > I think it's clearer to check if `cls` is not defined by any builtin loader here and then check if `loader` keeps `cls` alive. > > So `keepsAlive(ClassLoader loader1, ClassLoader loader2)` is not needed and replace line 935 and 940 to `keepsAlive(Class, ClassLoader)` instead. Sounds good. Incorporated your suggestions along with some minor refactorings. ------------- PR: https://git.openjdk.java.net/jdk/pull/5246 From vlivanov at openjdk.java.net Thu Sep 2 11:45:01 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Thu, 2 Sep 2021 11:45:01 GMT Subject: RFR: 8273000: Remove WeakReference-based class initialisation barrier implementation [v3] In-Reply-To: References: Message-ID: > Get rid of WeakReference-based logic in DirectMethodHandle::checkInitialized() and reimplement it with `Unsafe::ensureClassInitialized()`/`shouldBeInitialized()`. > > The key observation is that `Unsafe::ensureClassInitialized()` does not block the initializing thread. > > Also, removed `Unsafe::shouldBeInitialized()` in `DMH::shouldBeInitialized(MemberName)` to save on calling into the VM. > `Unsafe::ensureClassInitialized()` already has a fast-path check which checks whether the class is fully initialized or not. > > Testing: tier1 - tier6 Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: Update the comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5258/files - new: https://git.openjdk.java.net/jdk/pull/5258/files/64f2de83..09c36317 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5258&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5258&range=01-02 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5258.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5258/head:pull/5258 PR: https://git.openjdk.java.net/jdk/pull/5258 From vlivanov at openjdk.java.net Thu Sep 2 11:45:04 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Thu, 2 Sep 2021 11:45:04 GMT Subject: RFR: 8273000: Remove WeakReference-based class initialisation barrier implementation [v2] In-Reply-To: References: Message-ID: On Thu, 2 Sep 2021 05:08:38 GMT, David Holmes wrote: >> src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 1152: >> >>> 1150: * The call returns when either class {@code c} is fully initialized or >>> 1151: * class {@code c} is being initialized and the call is performed from >>> 1152: * the initializing thread. >> >> Suggestion: >> >> * The call returns when either class {@code c} is fully initialized or >> * class {@code c} is being initialized and the call is performed from >> * the initializing thread. In the latter case a subsequent call to >> * {@link #shouldBeInitialized}, from the calling thread of this call, >> * will return {@code true}. > > Aren't "the calling thread of this call" and "the initializing thread" the same thread in the latter case? Agree. I dropped "from the calling thread of this call" part and incorporated the rest into the latest version. ------------- PR: https://git.openjdk.java.net/jdk/pull/5258 From alanb at openjdk.java.net Thu Sep 2 11:46:28 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 2 Sep 2021 11:46:28 GMT Subject: RFR: 6957241: ClassLoader.getResources() returns only 1 instance when using jar indexing In-Reply-To: References: Message-ID: On Tue, 31 Aug 2021 12:11:46 GMT, wxiang wrote: > Using jarIndex for Hibench, there is an unexpected behavior with the exception "Exception in thread "main" org.apache.hadoop.fs.UnsupportedFileSystemException: No FileSystem for scheme "hdfs"". > > After investigating it, it is related to the usage of ServiceLoader with JarIndex. > The below stack shows the issue with JDK11: > > getResource:1016, URLClassPath$JarLoader (jdk.internal.loader) > getResource:937, URLClassPath$JarLoader (jdk.internal.loader) > findResource:912, URLClassPath$JarLoader (jdk.internal.loader) > next:341, URLClassPath$1 (jdk.internal.loader) > hasMoreElements:351, URLClassPath$1 (jdk.internal.loader) > hasNext:355, BuiltinClassLoader$1 (jdk.internal.loader) > hasMoreElements:363, BuiltinClassLoader$1 (jdk.internal.loader) > next:3032, CompoundEnumeration (java.lang) > hasMoreElements:3041, CompoundEnumeration (java.lang) > nextProviderClass:1203, ServiceLoader$LazyClassPathLookupIterator (java.util) > hasNextService:1221, ServiceLoader$LazyClassPathLookupIterator (java.util) > hasNext:1265, ServiceLoader$LazyClassPathLookupIterator (java.util) > hasNext:1300, ServiceLoader$2 (java.util) > hasNext:1385, ServiceLoader$3 (java.util) > > The below API tries to get all the resources with the same name. > > public Enumeration findResources(final String name, > final boolean check) > ``` > After using JarIndex, URLClassPath.findResources only returns 1 URL. > It is the same as the description in JDK-6957241. > > The issue still exists in JDK18. > > Root cause: > > public Enumeration findResources(final String name, > final boolean check) { > return new Enumeration<>() { > private int index = 0; > private URL url = null; > > private boolean next() { > if (url != null) { > return true; > } else { > Loader loader; > while ((loader = getLoader(index++)) != null) { > url = loader.findResource(name, check); > if (url != null) { > return true; > } > } > return false; > } > } > ... > }; > } > > With the JarIndex, there is only one loader which is corresponding to the jar with the index due to the implementation in JarLoader.getResource(final String name, boolean check, Set visited). > > Loaders corresponding to other jar packages will not appear in this while. > So it only returns 1 instance. > > To solve the issue, I change the implementation "private boolean next()". > If the loader has index, traverse the index and get all the resource from the loader. @wxiang I think there is at least some support for removing the JAR indexing support rather than trying to fix findResources. The issue of what to do with the legacy JAR index mechanism came up during JDK 9 in the context of modular JARs and also Multi-Release JARs but it was too much to take on at the time. Would you be interested in working out the changes to remove it? ------------- PR: https://git.openjdk.java.net/jdk/pull/5316 From rriggs at openjdk.java.net Thu Sep 2 13:30:29 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 2 Sep 2021 13:30:29 GMT Subject: RFR: 8273261: Replace 'while' cycles with iterator with enhanced-for in java.base In-Reply-To: <_l91WAZVqQeJUgX-ZH5CIgHap5TPzIZzI6zYVskXBjI=.ac99b92f-3270-4044-b0fe-d6d48be9d726@github.com> References: <_l91WAZVqQeJUgX-ZH5CIgHap5TPzIZzI6zYVskXBjI=.ac99b92f-3270-4044-b0fe-d6d48be9d726@github.com> Message-ID: On Wed, 1 Sep 2021 07:37:53 GMT, Andrey Turbanov wrote: > There are few places in code where manual while loop is used with Iterator to iterate over Collection. > Instead of manual while cycles it's preferred to use enhanced-for cycle instead: it's less verbose, makes code easier to read and it's less error-prone. > It doesn't have any performance impact: java compiler generates similar code when compiling enhanced-for cycle. > > Similar cleanups: > * https://bugs.openjdk.java.net/browse/JDK-8258006 > * https://bugs.openjdk.java.net/browse/JDK-8257912 LGTM For the security related code a second reviewer would be good. ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5328 From rriggs at openjdk.java.net Thu Sep 2 13:41:30 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 2 Sep 2021 13:41:30 GMT Subject: RFR: 8272600: (test) Use native "sleep" in Basic.java [v3] In-Reply-To: References: Message-ID: On Sat, 28 Aug 2021 02:34:48 GMT, Roger Riggs wrote: >> The intermittent test in java/lang/ProcessBuilder/Basic.java has identified unexpected messages from a child Java VM >> as the cause of the test failure. Attempts to control the output of the child VM have failed, the VM is unrepentant . >> >> There is no functionality in the child except to wait long enough for the test to finish and the child is destroyed. >> The fix is to switch from using a Java child to using a native child; a new executable `sleepmillis`. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Revised to use native /bin/sleep program on Unix* (non-Windows). > For Windows, a native "BasicSleep" program is used. The `timeout --help` version is from a CI job: Unexpected child output, to: getErrorStream Child args: [cmd.exe, /c, timeout, 60] Try 'timeout --help' for more information. But ...\cygwin\bin is in PATH before Windows\System32 So sleep would be available, but on cygwin it is in /usr/bin. sleep would work everywhere, except a real Windows build. What a tortuous workaround because of a 'feature' of the VM! ------------- PR: https://git.openjdk.java.net/jdk/pull/5239 From wuyan at openjdk.java.net Thu Sep 2 13:58:37 2021 From: wuyan at openjdk.java.net (Wu Yan) Date: Thu, 2 Sep 2021 13:58:37 GMT Subject: RFR: 8273111: Default timezone should return zone ID if /etc/localtime is valid but not canonicalization on linux In-Reply-To: <9LFh1-fCalpsuewYw9VrvQklHPSonac2AlSQptUamf8=.1db3137e-84db-47ad-835f-cbc8719f84e0@github.com> References: <6gmVj3r1hjhG5jvo_dSly3ShNnZZSCn-NIjtnvSySrk=.a88def27-7b80-425b-9ab8-2f94f5004b47@github.com> <9LFh1-fCalpsuewYw9VrvQklHPSonac2AlSQptUamf8=.1db3137e-84db-47ad-835f-cbc8719f84e0@github.com> Message-ID: On Wed, 1 Sep 2021 12:51:15 GMT, Florian Weimer wrote: >> Hi, >> Please help me review the change to enhance getting time zone ID from /etc/localtime on linux. >> >> We use `realpath` instead of `readlink` to obtain the link name of /etc/localtime, because `readlink` can only read the value of a symbolic of link, not the canonicalized absolute pathname. >> >> For example, the value of /etc/localtime is "../usr/share/zoneinfo//Asia/Shanghai", then the linkbuf obtained by `readlink` is "../usr/share/zoneinfo//Asia/Shanghai", and then the call of `getZoneName(linkbuf)` will get "/Asia/Shanghai", not "Asia/Shanghai", which consider as invalid in `ZoneInfoFile.getZoneInfo()`. Using `realpath`, you can get ?/usr/share/zoneinfo/Asia/Shanghai? directly from ?/etc/localtime?. >> >> Thanks, >> wuyan > > src/java.base/unix/native/libjava/TimeZone_md.c line 292: > >> 290: /* canonicalize the path */ >> 291: char resolvedpath[PATH_MAX + 1]; >> 292: char *path = realpath(DEFAULT_ZONEINFO_FILE, resolvedpath); > > You really should use `realpath` with `NULL` as the second argument, to avoid any risk of buffer overflow. Future C library headers may warn about non-null arguments here. Ok, Thanks. I will refer to the implementation of `os::Posix::realpath` to fix it if we still use `realpath`. https://github.com/openjdk/jdk/blob/5245c1cf0260a78ca5f8ab4e7d13107f21faf071/src/hotspot/os/posix/os_posix.cpp#L805 ------------- PR: https://git.openjdk.java.net/jdk/pull/5327 From wuyan at openjdk.java.net Thu Sep 2 13:58:36 2021 From: wuyan at openjdk.java.net (Wu Yan) Date: Thu, 2 Sep 2021 13:58:36 GMT Subject: RFR: 8273111: Default timezone should return zone ID if /etc/localtime is valid but not canonicalization on linux In-Reply-To: References: <6gmVj3r1hjhG5jvo_dSly3ShNnZZSCn-NIjtnvSySrk=.a88def27-7b80-425b-9ab8-2f94f5004b47@github.com> Message-ID: On Wed, 1 Sep 2021 12:38:38 GMT, Alan Bateman wrote: > I haven't come across this configuration like but changing it to use realpath seem reasonable. Thanks, this scenario comes from our customers. > Using `realpath` instead of `readlink` will change results on systems which use symbolic links instead of hard links to de-duplicate the timezone files. For example, on Debian, if `UTC` is configured (`/etc/localtime` points to `/usr/share/zoneinfo/UTC`), I think the result will be `Etc/UTC` instead of `UTC` after this change. But I have not actually tested this. We tested it on ubuntu, it does have this kind of problem, thank you for your reminder. `realpath` doesn't seem to be suitable here, maybe we could directly process the previous `linkbuf` to remove the extra'.' and'/'. > The change looks reasonable. Please test your fix with macOS as well. Thanks, the test on macOS is passed. ------------- PR: https://git.openjdk.java.net/jdk/pull/5327 From alanb at openjdk.java.net Thu Sep 2 14:03:29 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 2 Sep 2021 14:03:29 GMT Subject: RFR: JDK-8273194: Document the two possible cases when Lookup::ensureInitialized returns In-Reply-To: References: Message-ID: On Wed, 1 Sep 2021 20:56:59 GMT, Mandy Chung wrote: > Improve the specification to document the cases when `Lookup::ensureInitialized` returns as specified JVMS 5.5 and matches the implementation. > > Please also review CSR: https://bugs.openjdk.java.net/browse/JDK-8273253 src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 2787: > 2785: * This method returns when {@code targetClass} is fully initialized, or > 2786: * when {@code targetClass} is being initialized if this method is called > 2787: * by the initializing thread. This looks okay but I wonder if it might be a bit clearer to say "when targetClass is being initialized on the current thread". ------------- PR: https://git.openjdk.java.net/jdk/pull/5343 From rriggs at openjdk.java.net Thu Sep 2 14:45:12 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 2 Sep 2021 14:45:12 GMT Subject: RFR: 8272600: (test) Use native "sleep" in Basic.java [v3] In-Reply-To: References: Message-ID: On Sat, 28 Aug 2021 02:34:48 GMT, Roger Riggs wrote: >> The intermittent test in java/lang/ProcessBuilder/Basic.java has identified unexpected messages from a child Java VM >> as the cause of the test failure. Attempts to control the output of the child VM have failed, the VM is unrepentant . >> >> There is no functionality in the child except to wait long enough for the test to finish and the child is destroyed. >> The fix is to switch from using a Java child to using a native child; a new executable `sleepmillis`. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Revised to use native /bin/sleep program on Unix* (non-Windows). > For Windows, a native "BasicSleep" program is used. And also about Timeout on Windows: it can't be used because it requires a working input stream. Child args: [C:\Windows\System32\Timeout.exe, 600] ERROR: Input redirection is not supported, exiting the process immediately. ------------- PR: https://git.openjdk.java.net/jdk/pull/5239 From iris at openjdk.java.net Thu Sep 2 14:57:06 2021 From: iris at openjdk.java.net (Iris Clark) Date: Thu, 2 Sep 2021 14:57:06 GMT Subject: RFR: 8273261: Replace 'while' cycles with iterator with enhanced-for in java.base In-Reply-To: <_l91WAZVqQeJUgX-ZH5CIgHap5TPzIZzI6zYVskXBjI=.ac99b92f-3270-4044-b0fe-d6d48be9d726@github.com> References: <_l91WAZVqQeJUgX-ZH5CIgHap5TPzIZzI6zYVskXBjI=.ac99b92f-3270-4044-b0fe-d6d48be9d726@github.com> Message-ID: <2L0IWm1_kLMzLLdlB6vKuWNAe0qXPQ-2rHnFBkvwe98=.f12300b3-646b-4c67-a17b-f69d55155b21@github.com> On Wed, 1 Sep 2021 07:37:53 GMT, Andrey Turbanov wrote: > There are few places in code where manual while loop is used with Iterator to iterate over Collection. > Instead of manual while cycles it's preferred to use enhanced-for cycle instead: it's less verbose, makes code easier to read and it's less error-prone. > It doesn't have any performance impact: java compiler generates similar code when compiling enhanced-for cycle. > > Similar cleanups: > * https://bugs.openjdk.java.net/browse/JDK-8258006 > * https://bugs.openjdk.java.net/browse/JDK-8257912 Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5328 From lancea at openjdk.java.net Thu Sep 2 16:10:07 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 2 Sep 2021 16:10:07 GMT Subject: Integrated: 8273250: Address javadoc issues in Deflater::setDictionationary In-Reply-To: References: Message-ID: On Wed, 1 Sep 2021 19:26:17 GMT, Lance Andersen wrote: > Hi, > > Please review this trivial fix to the javadoc which addresses an issue shown via Intellij where the error: "Symbol 'getAdler' is inaccessible from here" is generated for the "@See Inflater#getAlder" references. > > Best > Lance This pull request has now been integrated. Changeset: aaa6f696 Author: Lance Andersen URL: https://git.openjdk.java.net/jdk/commit/aaa6f696b06b335f81efccf0966612b086dd2e73 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod 8273250: Address javadoc issues in Deflater::setDictionationary Reviewed-by: rriggs, naoto, iris, bpb ------------- PR: https://git.openjdk.java.net/jdk/pull/5340 From mchung at openjdk.java.net Thu Sep 2 16:23:27 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 2 Sep 2021 16:23:27 GMT Subject: RFR: JDK-8273194: Document the two possible cases when Lookup::ensureInitialized returns [v2] In-Reply-To: References: Message-ID: > Improve the specification to document the cases when `Lookup::ensureInitialized` returns as specified JVMS 5.5 and matches the implementation. > > Please also review CSR: https://bugs.openjdk.java.net/browse/JDK-8273253 Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: review comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5343/files - new: https://git.openjdk.java.net/jdk/pull/5343/files/3a2aa6da..3f7e66b0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5343&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5343&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5343.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5343/head:pull/5343 PR: https://git.openjdk.java.net/jdk/pull/5343 From alanb at openjdk.java.net Thu Sep 2 16:23:33 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 2 Sep 2021 16:23:33 GMT Subject: RFR: JDK-8273194: Document the two possible cases when Lookup::ensureInitialized returns [v2] In-Reply-To: References: Message-ID: On Thu, 2 Sep 2021 16:18:03 GMT, Mandy Chung wrote: >> Improve the specification to document the cases when `Lookup::ensureInitialized` returns as specified JVMS 5.5 and matches the implementation. >> >> Please also review CSR: https://bugs.openjdk.java.net/browse/JDK-8273253 > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > review comment Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5343 From mchung at openjdk.java.net Thu Sep 2 16:23:55 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 2 Sep 2021 16:23:55 GMT Subject: RFR: JDK-8273194: Document the two possible cases when Lookup::ensureInitialized returns [v2] In-Reply-To: References: Message-ID: <-t83IZKL4aJaRrD-aUOurEXB-swi0a60tuS6kxhUSpY=.bc590298-b7d2-40b8-a588-b79b0869f204@github.com> On Thu, 2 Sep 2021 14:00:03 GMT, Alan Bateman wrote: >> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> review comment > > src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 2787: > >> 2785: * This method returns when {@code targetClass} is fully initialized, or >> 2786: * when {@code targetClass} is being initialized if this method is called >> 2787: * by the initializing thread. > > This looks okay but I wonder if it might be a bit clearer to say "when targetClass is being initialized on the current thread". That works for me. Updated. ------------- PR: https://git.openjdk.java.net/jdk/pull/5343 From naoto at openjdk.java.net Thu Sep 2 19:35:42 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 2 Sep 2021 19:35:42 GMT Subject: RFR: 8273259: Character.getName doesn't follow Unicode spec for ideographs Message-ID: <3ZOCioU8lMEPuWdaYlBv8L6oNdIwVjwZpPbKLWwkOjs=.0e8939c8-9cff-4600-a869-9c5f137fd2e5@github.com> Simple spec clarification. A CSR has also been drafted (https://bugs.openjdk.java.net/browse/JDK-8273296). ------------- Commit messages: - 8273259: Character.getName doesn't follow Unicode spec for ideographs Changes: https://git.openjdk.java.net/jdk/pull/5354/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5354&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273259 Stats: 19 lines in 1 file changed: 8 ins; 0 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/5354.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5354/head:pull/5354 PR: https://git.openjdk.java.net/jdk/pull/5354 From bpb at openjdk.java.net Thu Sep 2 19:43:24 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 2 Sep 2021 19:43:24 GMT Subject: RFR: 8273259: Character.getName doesn't follow Unicode spec for ideographs In-Reply-To: <3ZOCioU8lMEPuWdaYlBv8L6oNdIwVjwZpPbKLWwkOjs=.0e8939c8-9cff-4600-a869-9c5f137fd2e5@github.com> References: <3ZOCioU8lMEPuWdaYlBv8L6oNdIwVjwZpPbKLWwkOjs=.0e8939c8-9cff-4600-a869-9c5f137fd2e5@github.com> Message-ID: On Thu, 2 Sep 2021 19:26:12 GMT, Naoto Sato wrote: > Simple spec clarification. A CSR has also been drafted (https://bugs.openjdk.java.net/browse/JDK-8273296). Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5354 From lancea at openjdk.java.net Thu Sep 2 19:43:24 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 2 Sep 2021 19:43:24 GMT Subject: RFR: 8273259: Character.getName doesn't follow Unicode spec for ideographs In-Reply-To: <3ZOCioU8lMEPuWdaYlBv8L6oNdIwVjwZpPbKLWwkOjs=.0e8939c8-9cff-4600-a869-9c5f137fd2e5@github.com> References: <3ZOCioU8lMEPuWdaYlBv8L6oNdIwVjwZpPbKLWwkOjs=.0e8939c8-9cff-4600-a869-9c5f137fd2e5@github.com> Message-ID: On Thu, 2 Sep 2021 19:26:12 GMT, Naoto Sato wrote: > Simple spec clarification. A CSR has also been drafted (https://bugs.openjdk.java.net/browse/JDK-8273296). Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5354 From iris at openjdk.java.net Thu Sep 2 22:24:26 2021 From: iris at openjdk.java.net (Iris Clark) Date: Thu, 2 Sep 2021 22:24:26 GMT Subject: RFR: 8273259: Character.getName doesn't follow Unicode spec for ideographs In-Reply-To: <3ZOCioU8lMEPuWdaYlBv8L6oNdIwVjwZpPbKLWwkOjs=.0e8939c8-9cff-4600-a869-9c5f137fd2e5@github.com> References: <3ZOCioU8lMEPuWdaYlBv8L6oNdIwVjwZpPbKLWwkOjs=.0e8939c8-9cff-4600-a869-9c5f137fd2e5@github.com> Message-ID: On Thu, 2 Sep 2021 19:26:12 GMT, Naoto Sato wrote: > Simple spec clarification. A CSR has also been drafted (https://bugs.openjdk.java.net/browse/JDK-8273296). Associated CSR also "Reviewed". ------------- Marked as reviewed by iris (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5354 From john.r.rose at oracle.com Thu Sep 2 23:35:51 2021 From: john.r.rose at oracle.com (John Rose) Date: Thu, 2 Sep 2021 23:35:51 +0000 Subject: better random numbers Message-ID: <3DC84A6C-DAB3-42CB-ACF6-0CADB5BE19C1@oracle.com> The state of the art for PRNGs (pseudo-random number generators) is much advanced since ju.Random was written. Surely at some point we will refresh our APIs that produce random numbers. In fact, we have added SplittableRandom, but I think the state of the art is farther enough along to consider another refresh. (When we get advanced numerics via Valhalla, I think we will probably want generic algorithms on 128-bit int and vectorized states, as well; that?s just a guess.) I bring this up not for any immediate purpose, but because every so often I google around for information about PRNGs, and I have noticed that a particular reference (since at least 2018) keeps coming to the top of the pile of interesting stuff. I?d like to share it with you all, and talk about making use of it. (FWIW, last weekend I was doing some experiments with perfect hash functions, and I wanted to roll my own PRNG to drive the search for them. A few months ago my problem was test vector generation, and again I rolled my own PRNG after looking at ju.*Random.) The reference I?d like to give here is to Dr. Melissa O?Neill?s website and articles: https://www.pcg-random.org ?Read more here: http://cr.openjdk.java.net/~jrose/jdk/pcg-psa.txt From mchung at openjdk.java.net Fri Sep 3 00:12:28 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 3 Sep 2021 00:12:28 GMT Subject: RFR: 8078641: MethodHandle.asTypeCache can retain classes from unloading [v3] In-Reply-To: References: Message-ID: On Thu, 2 Sep 2021 11:35:52 GMT, Vladimir Ivanov wrote: >> `MethodHandle.asTypeCache` keeps a strong reference to adapted `MethodHandle` and it can introduce a class loader leak through its `MethodType`. >> >> Proposed fix introduces a 2-level cache (1 element each) where 1st level can only contain `MethodHandle`s which are guaranteed to not introduce any dependencies on new class loaders compared to the original `MethodHandle`. 2nd level is backed by a `SoftReference` and is used as a backup when the result of `MethodHandle.asType()` conversion can't populate the higher level cache. >> >> The fix is based on [the work](http://cr.openjdk.java.net/~plevart/jdk9-dev/MethodHandle.asTypeCacheLeak/) made by Peter Levart @plevart back in 2015. >> >> Testing: tier1 - tier6 > > Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments This looks good to me. For the change of `MethodHandle::asType` to a final method, this needs a CSR. Is this spec change intentional? I wonder if `MethodHandle` should be a sealed class instead. In any case, maybe you can consider the spec change as a separate issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/5246 From igraves at openjdk.java.net Fri Sep 3 00:53:45 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Fri, 3 Sep 2021 00:53:45 GMT Subject: Integrated: 8214761: Bug in parallel Kahan summation implementation In-Reply-To: References: Message-ID: On Fri, 2 Jul 2021 20:12:39 GMT, Ian Graves wrote: > 8214761: Bug in parallel Kahan summation implementation This pull request has now been integrated. Changeset: dd871819 Author: Ian Graves URL: https://git.openjdk.java.net/jdk/commit/dd871819a05886ee09fc00c7c778268440ebedb7 Stats: 235 lines in 5 files changed: 225 ins; 0 del; 10 mod 8214761: Bug in parallel Kahan summation implementation Reviewed-by: darcy ------------- PR: https://git.openjdk.java.net/jdk/pull/4674 From john.r.rose at oracle.com Fri Sep 3 01:01:38 2021 From: john.r.rose at oracle.com (John Rose) Date: Fri, 3 Sep 2021 01:01:38 +0000 Subject: better random numbers In-Reply-To: <3DC84A6C-DAB3-42CB-ACF6-0CADB5BE19C1@oracle.com> References: <3DC84A6C-DAB3-42CB-ACF6-0CADB5BE19C1@oracle.com> Message-ID: <2AC0246B-1C2E-4DBD-95E5-0EC6A05C1636@oracle.com> On Sep 2, 2021, at 4:35 PM, John Rose > wrote: The state of the art for PRNGs (pseudo-random number generators) is much advanced since ju.Random was written. Surely at some point we will refresh our APIs that produce random numbers. In fact, we have added SplittableRandom, but I think the state of the art is farther enough along to consider another refresh. Well, I didn?t know about https://openjdk.java.net/jeps/356 when I wrote the previous, so I?m a little late to be as helpful as I hoped to be. Still, Joe and Brian B. (thanks guys for handing me the Missing Clue) lead me to hope we can add options to cover the PCG algorithms, if (as I think) they turn out to be useful. The 128-bit PCG state with the 64-bit multiplier of da942042e4dd58b5 looks especially promising to me. It?s used here: https://github.com/imneme/pcg-cpp/blob/ffd522e7188bef30a00c74dc7eb9de5faff90092/include/pcg_random.hpp#L176 O?Neill says that?s her PRNG of choice for most purposes is pcg64_fast (defined in the file above using that multiplier). It competes better with the xoshiro family performance than the shootout figures provided by the xoshiro developers would seem to indicate. And the state size for pcg64_fast is 128 bits which (I think) is about half the size of a xoshiro state. From david.holmes at oracle.com Fri Sep 3 01:51:05 2021 From: david.holmes at oracle.com (David Holmes) Date: Fri, 3 Sep 2021 11:51:05 +1000 Subject: RFR: 8272600: (test) Use native "sleep" in Basic.java [v3] In-Reply-To: References: Message-ID: <167a6385-2a2e-560d-f856-fb04148a0c37@oracle.com> On 3/09/2021 12:45 am, Roger Riggs wrote: > On Sat, 28 Aug 2021 02:34:48 GMT, Roger Riggs wrote: > >>> The intermittent test in java/lang/ProcessBuilder/Basic.java has identified unexpected messages from a child Java VM >>> as the cause of the test failure. Attempts to control the output of the child VM have failed, the VM is unrepentant . >>> >>> There is no functionality in the child except to wait long enough for the test to finish and the child is destroyed. >>> The fix is to switch from using a Java child to using a native child; a new executable `sleepmillis`. >> >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Revised to use native /bin/sleep program on Unix* (non-Windows). >> For Windows, a native "BasicSleep" program is used. > > And also about Timeout on Windows: it can't be used because it requires a working input stream. > > Child args: [C:\Windows\System32\Timeout.exe, 600] > ERROR: Input redirection is not supported, exiting the process immediately. Did you try with the /NOBREAK flag? David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/5239 > From github.com+53162078+shiyuexw at openjdk.java.net Fri Sep 3 06:55:28 2021 From: github.com+53162078+shiyuexw at openjdk.java.net (wxiang) Date: Fri, 3 Sep 2021 06:55:28 GMT Subject: RFR: 6957241: ClassLoader.getResources() returns only 1 instance when using jar indexing In-Reply-To: References: Message-ID: On Thu, 2 Sep 2021 11:43:46 GMT, Alan Bateman wrote: >> Using jarIndex for Hibench, there is an unexpected behavior with the exception "Exception in thread "main" org.apache.hadoop.fs.UnsupportedFileSystemException: No FileSystem for scheme "hdfs"". >> >> After investigating it, it is related to the usage of ServiceLoader with JarIndex. >> The below stack shows the issue with JDK11: >> >> getResource:1016, URLClassPath$JarLoader (jdk.internal.loader) >> getResource:937, URLClassPath$JarLoader (jdk.internal.loader) >> findResource:912, URLClassPath$JarLoader (jdk.internal.loader) >> next:341, URLClassPath$1 (jdk.internal.loader) >> hasMoreElements:351, URLClassPath$1 (jdk.internal.loader) >> hasNext:355, BuiltinClassLoader$1 (jdk.internal.loader) >> hasMoreElements:363, BuiltinClassLoader$1 (jdk.internal.loader) >> next:3032, CompoundEnumeration (java.lang) >> hasMoreElements:3041, CompoundEnumeration (java.lang) >> nextProviderClass:1203, ServiceLoader$LazyClassPathLookupIterator (java.util) >> hasNextService:1221, ServiceLoader$LazyClassPathLookupIterator (java.util) >> hasNext:1265, ServiceLoader$LazyClassPathLookupIterator (java.util) >> hasNext:1300, ServiceLoader$2 (java.util) >> hasNext:1385, ServiceLoader$3 (java.util) >> >> The below API tries to get all the resources with the same name. >> >> public Enumeration findResources(final String name, >> final boolean check) >> ``` >> After using JarIndex, URLClassPath.findResources only returns 1 URL. >> It is the same as the description in JDK-6957241. >> >> The issue still exists in JDK18. >> >> Root cause: >> >> public Enumeration findResources(final String name, >> final boolean check) { >> return new Enumeration<>() { >> private int index = 0; >> private URL url = null; >> >> private boolean next() { >> if (url != null) { >> return true; >> } else { >> Loader loader; >> while ((loader = getLoader(index++)) != null) { >> url = loader.findResource(name, check); >> if (url != null) { >> return true; >> } >> } >> return false; >> } >> } >> ... >> }; >> } >> >> With the JarIndex, there is only one loader which is corresponding to the jar with the index due to the implementation in JarLoader.getResource(final String name, boolean check, Set visited). >> >> Loaders corresponding to other jar packages will not appear in this while. >> So it only returns 1 instance. >> >> To solve the issue, I change the implementation "private boolean next()". >> If the loader has index, traverse the index and get all the resource from the loader. > > @wxiang I think there is at least some support for removing the JAR indexing support rather than trying to fix findResources. The issue of what to do with the legacy JAR index mechanism came up during JDK 9 in the context of modular JARs and also Multi-Release JARs but it was too much to take on at the time. Would you be interested in working out the changes to remove it? @AlanBateman Sure, I am interested in it. ------------- PR: https://git.openjdk.java.net/jdk/pull/5316 From shade at openjdk.java.net Fri Sep 3 09:17:42 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 3 Sep 2021 09:17:42 GMT Subject: RFR: 8273314: Add tier4 test groups Message-ID: <6rDioD5KZREYHyzOXol72O0erNDqKHUqb-0k1SwhInA=.90a12492-9e2f-4f0c-bf09-8d67d1d6111f@github.com> During the review of JDK-8272914 that added hotspot:tier{2,3} groups, @iignatev suggested to create tier4 groups that capture all tests not in tiers{1,2,3}. I have excluded `vmTestbase` and `hotspot:tier4,` because they take 10+ hours on my highly parallel machine. I have also excluded `applications` from `hotspot:tier4`, because they require test dependencies (e.g. jcstress). Sample run: ============================== Test summary ============================== TEST TOTAL PASS FAIL ERROR >> jtreg:test/hotspot/jtreg:tier4 426 425 1 0 << >> jtreg:test/jdk:tier4 2891 2885 4 2 << jtreg:test/langtools:tier4 0 0 0 0 jtreg:test/jaxp:tier4 0 0 0 0 ============================== real 64m13.994s user 1462m1.213s sys 39m38.032s There are interesting test failures on my machine, which I would address separately. ------------- Commit messages: - Add tier4 test groups Changes: https://git.openjdk.java.net/jdk/pull/5357/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5357&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273314 Stats: 22 lines in 4 files changed: 22 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5357.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5357/head:pull/5357 PR: https://git.openjdk.java.net/jdk/pull/5357 From wuyan at openjdk.java.net Fri Sep 3 09:52:27 2021 From: wuyan at openjdk.java.net (Wu Yan) Date: Fri, 3 Sep 2021 09:52:27 GMT Subject: RFR: 8268231: Aarch64: Use ldp in intrinsics for String.compareTo [v4] In-Reply-To: References: Message-ID: On Wed, 28 Jul 2021 08:51:38 GMT, Andrew Haley wrote: >> I don't think we want to keep two copies of the compareTo intrinsic. If there are no cases where the LDP version is worse than the original version then we should just delete the old one and replace it with this. > >> I don't think we want to keep two copies of the compareTo intrinsic. If there are no cases where the LDP version is worse than the original version then we should just delete the old one and replace it with this. > > I agree. The trouble is, what does "worse" mean? I'm looking at SDEN-1982442, Neoverse N2 errata, 2001293, and I see that LDP has to be slowed down on streaming workloads, which will affect this. (That's just an example: I'm making the point that implementations differ.) > > The trouble with this patch is that it (probably) makes things better for long strings, which are very rare. What we actually need to care about is performance for a large number of typical-sized strings, which are names, identifiers, passwords, and so on: about 10-30 characters. @theRealAph do you have any other questions about this patch? ------------- PR: https://git.openjdk.java.net/jdk/pull/4722 From shade at openjdk.java.net Fri Sep 3 10:01:35 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 3 Sep 2021 10:01:35 GMT Subject: RFR: 8273315: Parallelize and increase timeouts for java/foreign/TestMatrix.java test Message-ID: This test runs a lot of configurations, and spends a lot of time serially. This is especially pronounced when run in prospective tier4 runs (JDK-8273314). There are reports of multi-hour runs (see JDK-8271613). We can parallelize the test configurations for this test to make it hurt less. Also, timeouts need to be increased for `TestUpcall` test configs, because some of them are very slow in fastdebug mode. Sample run: $ time CONF=linux-x86_64-server-fastdebug make run-test TEST=java/foreign/TestMatrix.java | ts -s 00:00:00 Building target 'run-test' in configuration 'linux-x86_64-server-fastdebug' 00:00:03 Test selection 'java/foreign/TestMatrix.java', will run: 00:00:03 * jtreg:test/jdk/java/foreign/TestMatrix.java 00:00:03 00:00:03 Running test 'jtreg:test/jdk/java/foreign/TestMatrix.java' 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TTFT 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FFFF 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FFTF 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TTTT 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FTTT 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FFTT 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FFFT 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TTTF 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FTTF 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TFFT 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TFTF 00:00:32 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TFFF 00:00:32 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FTFF 00:00:35 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TFTT 00:00:35 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TTFF 00:00:38 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FTFT 00:01:50 Passed: java/foreign/TestMatrix.java#Downcall-FF 00:02:27 Passed: java/foreign/TestMatrix.java#Downcall-TF 00:03:03 Passed: java/foreign/TestMatrix.java#Downcall-FT 00:03:47 Passed: java/foreign/TestMatrix.java#Downcall-TT 00:04:17 Passed: java/foreign/TestMatrix.java#Upcall-FTFF 00:04:23 Passed: java/foreign/TestMatrix.java#Upcall-TFFF 00:05:46 Passed: java/foreign/TestMatrix.java#Upcall-TTFF 00:06:03 Passed: java/foreign/TestMatrix.java#Upcall-TFFT 00:06:44 Passed: java/foreign/TestMatrix.java#Upcall-FTFT 00:08:24 Passed: java/foreign/TestMatrix.java#Upcall-TFTF 00:08:39 Passed: java/foreign/TestMatrix.java#Upcall-TTFT 00:09:16 Passed: java/foreign/TestMatrix.java#Upcall-FTTF 00:09:19 Passed: java/foreign/TestMatrix.java#Upcall-TFTT 00:10:01 Passed: java/foreign/TestMatrix.java#Upcall-FTTT 00:10:37 Passed: java/foreign/TestMatrix.java#Upcall-TTTF 00:12:16 Passed: java/foreign/TestMatrix.java#Upcall-TTTT 00:12:17 Test results: passed: 32 00:12:21 00:12:21 ============================== 00:12:21 Test summary 00:12:21 ============================== 00:12:21 TEST TOTAL PASS FAIL ERROR 00:12:21 jtreg:test/jdk/java/foreign/TestMatrix.java 32 32 0 0 00:12:21 ============================== real 12m20.538s user 131m54.043s sys 0m59.944s If we don't parallelize, then those 130 minutes are spent serially. ------------- Commit messages: - Timeouts and cleanups - Parallelize Changes: https://git.openjdk.java.net/jdk/pull/5358/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5358&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273315 Stats: 238 lines in 1 file changed: 195 ins; 14 del; 29 mod Patch: https://git.openjdk.java.net/jdk/pull/5358.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5358/head:pull/5358 PR: https://git.openjdk.java.net/jdk/pull/5358 From alanb at openjdk.java.net Fri Sep 3 10:51:23 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 3 Sep 2021 10:51:23 GMT Subject: RFR: 6957241: ClassLoader.getResources() returns only 1 instance when using jar indexing In-Reply-To: References: Message-ID: On Thu, 2 Sep 2021 11:43:46 GMT, Alan Bateman wrote: >> Using jarIndex for Hibench, there is an unexpected behavior with the exception "Exception in thread "main" org.apache.hadoop.fs.UnsupportedFileSystemException: No FileSystem for scheme "hdfs"". >> >> After investigating it, it is related to the usage of ServiceLoader with JarIndex. >> The below stack shows the issue with JDK11: >> >> getResource:1016, URLClassPath$JarLoader (jdk.internal.loader) >> getResource:937, URLClassPath$JarLoader (jdk.internal.loader) >> findResource:912, URLClassPath$JarLoader (jdk.internal.loader) >> next:341, URLClassPath$1 (jdk.internal.loader) >> hasMoreElements:351, URLClassPath$1 (jdk.internal.loader) >> hasNext:355, BuiltinClassLoader$1 (jdk.internal.loader) >> hasMoreElements:363, BuiltinClassLoader$1 (jdk.internal.loader) >> next:3032, CompoundEnumeration (java.lang) >> hasMoreElements:3041, CompoundEnumeration (java.lang) >> nextProviderClass:1203, ServiceLoader$LazyClassPathLookupIterator (java.util) >> hasNextService:1221, ServiceLoader$LazyClassPathLookupIterator (java.util) >> hasNext:1265, ServiceLoader$LazyClassPathLookupIterator (java.util) >> hasNext:1300, ServiceLoader$2 (java.util) >> hasNext:1385, ServiceLoader$3 (java.util) >> >> The below API tries to get all the resources with the same name. >> >> public Enumeration findResources(final String name, >> final boolean check) >> ``` >> After using JarIndex, URLClassPath.findResources only returns 1 URL. >> It is the same as the description in JDK-6957241. >> >> The issue still exists in JDK18. >> >> Root cause: >> >> public Enumeration findResources(final String name, >> final boolean check) { >> return new Enumeration<>() { >> private int index = 0; >> private URL url = null; >> >> private boolean next() { >> if (url != null) { >> return true; >> } else { >> Loader loader; >> while ((loader = getLoader(index++)) != null) { >> url = loader.findResource(name, check); >> if (url != null) { >> return true; >> } >> } >> return false; >> } >> } >> ... >> }; >> } >> >> With the JarIndex, there is only one loader which is corresponding to the jar with the index due to the implementation in JarLoader.getResource(final String name, boolean check, Set visited). >> >> Loaders corresponding to other jar packages will not appear in this while. >> So it only returns 1 instance. >> >> To solve the issue, I change the implementation "private boolean next()". >> If the loader has index, traverse the index and get all the resource from the loader. > > @wxiang I think there is at least some support for removing the JAR indexing support rather than trying to fix findResources. The issue of what to do with the legacy JAR index mechanism came up during JDK 9 in the context of modular JARs and also Multi-Release JARs but it was too much to take on at the time. Would you be interested in working out the changes to remove it? > @AlanBateman Sure, I am interested in it. Great! I think there are several parts to this. The removal of the JAR index support from the URLClassLoader implementation, the `jar i` option, the JAR file spec, and the jar tool man page. It would be good to create a patch for the removal to see if there are any issues. There will probably need to be some discussion on what to do with the jar tool. I suspect we will need to keep the code that updates the index when updating a JAR file that has an existing index, this means keeping JarIndex and maybe moving it to the jdk.jartool module. We can change `jar i` to print a warning when the tool is called to generate an index. Don't worry about the JAR spec and man page for now. ------------- PR: https://git.openjdk.java.net/jdk/pull/5316 From vlivanov at openjdk.java.net Fri Sep 3 12:04:27 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Fri, 3 Sep 2021 12:04:27 GMT Subject: RFR: 8078641: MethodHandle.asTypeCache can retain classes from unloading [v3] In-Reply-To: References: Message-ID: On Fri, 3 Sep 2021 00:09:17 GMT, Mandy Chung wrote: > For the change of MethodHandle::asType to a final method, this needs a CSR. It is not allowed to extend/subclass `MethodHandle` outside `java.lang.invoke` package. So, the aforementioned change doesn't have any compatibility risks. Do I miss something important? /** * Package-private constructor for the method handle implementation hierarchy. * Method handle inheritance will be contained completely within * the {@code java.lang.invoke} package. */ // @param type type (permanently assigned) of the new method handle /*non-public*/ MethodHandle(MethodType type, LambdaForm form) { ------------- PR: https://git.openjdk.java.net/jdk/pull/5246 From rriggs at openjdk.java.net Fri Sep 3 13:22:28 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 3 Sep 2021 13:22:28 GMT Subject: RFR: 8272600: (test) Use native "sleep" in Basic.java [v3] In-Reply-To: References: Message-ID: On Sat, 28 Aug 2021 02:34:48 GMT, Roger Riggs wrote: >> The intermittent test in java/lang/ProcessBuilder/Basic.java has identified unexpected messages from a child Java VM >> as the cause of the test failure. Attempts to control the output of the child VM have failed, the VM is unrepentant . >> >> There is no functionality in the child except to wait long enough for the test to finish and the child is destroyed. >> The fix is to switch from using a Java child to using a native child; a new executable `sleepmillis`. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Revised to use native /bin/sleep program on Unix* (non-Windows). > For Windows, a native "BasicSleep" program is used. On Windows Timeout, /NOBREAK does not change the behavior, still does not support if input is redirected. ------------- PR: https://git.openjdk.java.net/jdk/pull/5239 From github.com+10835776+stsypanov at openjdk.java.net Fri Sep 3 13:30:47 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Fri, 3 Sep 2021 13:30:47 GMT Subject: RFR: 8273329: Remove redundant null check from String.getBytes(String charsetName) Message-ID: Current implementation looks like this: public byte[] getBytes(String charsetName) throws UnsupportedEncodingException { if (charsetName == null) throw new NullPointerException(); return encode(lookupCharset(charsetName), coder(), value); } Null check seems to be redundant here because the same check of `charsetName` is done within `String.lookupCharset(String)`: private static Charset lookupCharset(String csn) throws UnsupportedEncodingException { Objects.requireNonNull(csn); try { return Charset.forName(csn); } catch (UnsupportedCharsetException | IllegalCharsetNameException x) { throw new UnsupportedEncodingException(csn); } } ------------- Commit messages: - 8273329: Remove redundant null check from String.getBytes(String charsetName) Changes: https://git.openjdk.java.net/jdk/pull/5361/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5361&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273329 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5361.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5361/head:pull/5361 PR: https://git.openjdk.java.net/jdk/pull/5361 From mullan at openjdk.java.net Fri Sep 3 13:38:27 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 3 Sep 2021 13:38:27 GMT Subject: RFR: 8273261: Replace 'while' cycles with iterator with enhanced-for in java.base In-Reply-To: <_l91WAZVqQeJUgX-ZH5CIgHap5TPzIZzI6zYVskXBjI=.ac99b92f-3270-4044-b0fe-d6d48be9d726@github.com> References: <_l91WAZVqQeJUgX-ZH5CIgHap5TPzIZzI6zYVskXBjI=.ac99b92f-3270-4044-b0fe-d6d48be9d726@github.com> Message-ID: On Wed, 1 Sep 2021 07:37:53 GMT, Andrey Turbanov wrote: > There are few places in code where manual while loop is used with Iterator to iterate over Collection. > Instead of manual while cycles it's preferred to use enhanced-for cycle instead: it's less verbose, makes code easier to read and it's less error-prone. > It doesn't have any performance impact: java compiler generates similar code when compiling enhanced-for cycle. > > Similar cleanups: > * https://bugs.openjdk.java.net/browse/JDK-8258006 > * https://bugs.openjdk.java.net/browse/JDK-8257912 The security related changes look fine to me. ------------- Marked as reviewed by mullan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5328 From rriggs at openjdk.java.net Fri Sep 3 14:07:25 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 3 Sep 2021 14:07:25 GMT Subject: RFR: 8273329: Remove redundant null check from String.getBytes(String charsetName) In-Reply-To: References: Message-ID: On Fri, 3 Sep 2021 13:22:54 GMT, ?????? ??????? wrote: > Current implementation looks like this: > > public byte[] getBytes(String charsetName) > throws UnsupportedEncodingException { > if (charsetName == null) throw new NullPointerException(); > return encode(lookupCharset(charsetName), coder(), value); > } > > Null check seems to be redundant here because the same check of `charsetName` is done within `String.lookupCharset(String)`: > > private static Charset lookupCharset(String csn) throws UnsupportedEncodingException { > Objects.requireNonNull(csn); > try { > return Charset.forName(csn); > } catch (UnsupportedCharsetException | IllegalCharsetNameException x) { > throw new UnsupportedEncodingException(csn); > } > } Redundant null checks get collapsed by HotSpot, so not a performance improvement. Having null checks at public entry points also shows a stack trace that is more specific about where the null came from. So not much value in changing this. ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5361 From plevart at openjdk.java.net Fri Sep 3 14:23:28 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Fri, 3 Sep 2021 14:23:28 GMT Subject: RFR: 8078641: MethodHandle.asTypeCache can retain classes from unloading [v3] In-Reply-To: References: Message-ID: On Thu, 2 Sep 2021 11:35:52 GMT, Vladimir Ivanov wrote: >> `MethodHandle.asTypeCache` keeps a strong reference to adapted `MethodHandle` and it can introduce a class loader leak through its `MethodType`. >> >> Proposed fix introduces a 2-level cache (1 element each) where 1st level can only contain `MethodHandle`s which are guaranteed to not introduce any dependencies on new class loaders compared to the original `MethodHandle`. 2nd level is backed by a `SoftReference` and is used as a backup when the result of `MethodHandle.asType()` conversion can't populate the higher level cache. >> >> The fix is based on [the work](http://cr.openjdk.java.net/~plevart/jdk9-dev/MethodHandle.asTypeCacheLeak/) made by Peter Levart @plevart back in 2015. >> >> Testing: tier1 - tier6 > > Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments src/java.base/share/classes/java/lang/invoke/MethodHandle.java line 877: > 875: } > 876: if (asTypeSoftCache != null) { > 877: atc = asTypeSoftCache.get(); NPE is possible here too! asTypeSoftCache is a non-volatile field which is read twice. First time in the if (...) condition, 2nd time in the line that de-references it to call .get(). This is a data-race since concurrent thread may be setting this field from null to non-null. Those two reads may get reordered. 1st read may return non-null while 2nd may return null. This can be avoided if the field is read just once by introducing a local variable to store its value. src/java.base/share/classes/java/lang/invoke/MethodHandle.java line 878: > 876: if (asTypeSoftCache != null) { > 877: atc = asTypeSoftCache.get(); > 878: if (newType == atc.type) { NPE is possible here! act can be null as it is a result of SoftReference::get src/java.base/share/classes/java/lang/invoke/MethodHandle.java line 933: > 931: } > 932: > 933: /* Returns true when {@code loader} keeps {@code mt} either directly or indirectly through the loader delegation chain. */ Well, to be precise, loader can't keep mt alive. It would be better to say "keeps mt components alive" ... src/java.base/share/classes/java/lang/invoke/MethodHandle.java line 948: > 946: if (isBuiltinLoader(defLoader)) { > 947: return true; // built-in loaders are always reachable > 948: } No need for special case here. isAncestorLoaderOf(defLoader, loader) already handles this case. ------------- PR: https://git.openjdk.java.net/jdk/pull/5246 From rriggs at openjdk.java.net Fri Sep 3 14:25:53 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 3 Sep 2021 14:25:53 GMT Subject: RFR: 8272600: (test) Use native "sleep" in Basic.java [v4] In-Reply-To: References: Message-ID: <50LQP1Xo_qEDnTLxBtjuD8cYq9bBjo6qXijtrySii38=.2d879836-de4f-4c8e-904a-9bd7fc859fc1@github.com> > The intermittent test in java/lang/ProcessBuilder/Basic.java has identified unexpected messages from a child Java VM > as the cause of the test failure. Attempts to control the output of the child VM have failed, the VM is unrepentant . > > There is no functionality in the child except to wait long enough for the test to finish and the child is destroyed. > The fix is to switch from using a Java child to using a native child; a new executable `sleepmillis`. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Revert to using BasicSleep on Windows Added diagnostic output for a test that sometimes fails on Linux when using /bin/sleep. Addressed review comments. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5239/files - new: https://git.openjdk.java.net/jdk/pull/5239/files/05d009de..2a9c33fb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5239&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5239&range=02-03 Stats: 23 lines in 2 files changed: 11 ins; 3 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/5239.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5239/head:pull/5239 PR: https://git.openjdk.java.net/jdk/pull/5239 From vlivanov at openjdk.java.net Fri Sep 3 14:41:45 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Fri, 3 Sep 2021 14:41:45 GMT Subject: RFR: 8078641: MethodHandle.asTypeCache can retain classes from unloading [v4] In-Reply-To: References: Message-ID: > `MethodHandle.asTypeCache` keeps a strong reference to adapted `MethodHandle` and it can introduce a class loader leak through its `MethodType`. > > Proposed fix introduces a 2-level cache (1 element each) where 1st level can only contain `MethodHandle`s which are guaranteed to not introduce any dependencies on new class loaders compared to the original `MethodHandle`. 2nd level is backed by a `SoftReference` and is used as a backup when the result of `MethodHandle.asType()` conversion can't populate the higher level cache. > > The fix is based on [the work](http://cr.openjdk.java.net/~plevart/jdk9-dev/MethodHandle.asTypeCacheLeak/) made by Peter Levart @plevart back in 2015. > > Testing: tier1 - tier6 Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5246/files - new: https://git.openjdk.java.net/jdk/pull/5246/files/7a87aee3..365dd454 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5246&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5246&range=02-03 Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/5246.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5246/head:pull/5246 PR: https://git.openjdk.java.net/jdk/pull/5246 From vlivanov at openjdk.java.net Fri Sep 3 14:41:47 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Fri, 3 Sep 2021 14:41:47 GMT Subject: RFR: 8078641: MethodHandle.asTypeCache can retain classes from unloading [v3] In-Reply-To: References: Message-ID: On Fri, 3 Sep 2021 12:51:13 GMT, Peter Levart wrote: >> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review comments > > src/java.base/share/classes/java/lang/invoke/MethodHandle.java line 877: > >> 875: } >> 876: if (asTypeSoftCache != null) { >> 877: atc = asTypeSoftCache.get(); > > NPE is possible here too! asTypeSoftCache is a non-volatile field which is read twice. First time in the if (...) condition, 2nd time in the line that de-references it to call .get(). This is a data-race since concurrent thread may be setting this field from null to non-null. Those two reads may get reordered. 1st read may return non-null while 2nd may return null. This can be avoided if the field is read just once by introducing a local variable to store its value. Fixed. > src/java.base/share/classes/java/lang/invoke/MethodHandle.java line 878: > >> 876: if (asTypeSoftCache != null) { >> 877: atc = asTypeSoftCache.get(); >> 878: if (newType == atc.type) { > > NPE is possible here! act can be null as it is a result of SoftReference::get Good catch! Fixed. > src/java.base/share/classes/java/lang/invoke/MethodHandle.java line 933: > >> 931: } >> 932: >> 933: /* Returns true when {@code loader} keeps {@code mt} either directly or indirectly through the loader delegation chain. */ > > Well, to be precise, loader can't keep mt alive. It would be better to say "keeps mt components alive" ... Fixed. > src/java.base/share/classes/java/lang/invoke/MethodHandle.java line 948: > >> 946: if (isBuiltinLoader(defLoader)) { >> 947: return true; // built-in loaders are always reachable >> 948: } > > No need for special case here. isAncestorLoaderOf(defLoader, loader) already handles this case. Though the check is redundant, I find the current version clearer. ------------- PR: https://git.openjdk.java.net/jdk/pull/5246 From plevart at openjdk.java.net Fri Sep 3 15:32:27 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Fri, 3 Sep 2021 15:32:27 GMT Subject: RFR: 8078641: MethodHandle.asTypeCache can retain classes from unloading [v4] In-Reply-To: References: Message-ID: <9__r-Z3d57tzznR5fU2F9hP8cFibVUodACOwW791Hl0=.92dbef61-9317-4dd2-8f9f-8eadba55cc8b@github.com> On Fri, 3 Sep 2021 14:41:45 GMT, Vladimir Ivanov wrote: >> `MethodHandle.asTypeCache` keeps a strong reference to adapted `MethodHandle` and it can introduce a class loader leak through its `MethodType`. >> >> Proposed fix introduces a 2-level cache (1 element each) where 1st level can only contain `MethodHandle`s which are guaranteed to not introduce any dependencies on new class loaders compared to the original `MethodHandle`. 2nd level is backed by a `SoftReference` and is used as a backup when the result of `MethodHandle.asType()` conversion can't populate the higher level cache. >> >> The fix is based on [the work](http://cr.openjdk.java.net/~plevart/jdk9-dev/MethodHandle.asTypeCacheLeak/) made by Peter Levart @plevart back in 2015. >> >> Testing: tier1 - tier6 > > Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments Marked as reviewed by plevart (Reviewer). This looks good to me now. ------------- PR: https://git.openjdk.java.net/jdk/pull/5246 From prr at openjdk.java.net Fri Sep 3 16:18:24 2021 From: prr at openjdk.java.net (Phil Race) Date: Fri, 3 Sep 2021 16:18:24 GMT Subject: RFR: 8273101: Eliminate the usage of threadgroup sandboxing in the java.util.logging In-Reply-To: References: Message-ID: On Wed, 1 Sep 2021 06:31:16 GMT, Sergey Bylokhov wrote: > The "java.util.logging.LogManager" class uses the "threadgroup sandboxing" via an AppContext to support "applet logging isolation". The AppContext class became useless since the plugin and webstart are no longer supported and removed in jdk11. > > This is the request to delete the usage of AppContext in the LogManager and related tests. > > Tested by tier1/tier2/tier3 and jdk_desktop tests. This fix requires coordinated closed changes so needs an Oracle sponsor. And actually is probably better handled entirely by an Oracle engineer because pushes need to be very co-ordinated. ------------- PR: https://git.openjdk.java.net/jdk/pull/5326 From prr at openjdk.java.net Fri Sep 3 16:53:28 2021 From: prr at openjdk.java.net (Phil Race) Date: Fri, 3 Sep 2021 16:53:28 GMT Subject: RFR: 8273101: Eliminate the usage of threadgroup sandboxing in the java.util.logging In-Reply-To: References: Message-ID: On Wed, 1 Sep 2021 06:31:16 GMT, Sergey Bylokhov wrote: > The "java.util.logging.LogManager" class uses the "threadgroup sandboxing" via an AppContext to support "applet logging isolation". The AppContext class became useless since the plugin and webstart are no longer supported and removed in jdk11. > > This is the request to delete the usage of AppContext in the LogManager and related tests. > > Tested by tier1/tier2/tier3 and jdk_desktop tests. I believe we should have a CSR for this. It removes a long standing capability in the platform that was used by components such as plugin and webstart. ------------- PR: https://git.openjdk.java.net/jdk/pull/5326 From prr at openjdk.java.net Fri Sep 3 17:22:27 2021 From: prr at openjdk.java.net (Phil Race) Date: Fri, 3 Sep 2021 17:22:27 GMT Subject: RFR: 8273101: Eliminate the usage of threadgroup sandboxing in the java.util.logging In-Reply-To: References: Message-ID: On Wed, 1 Sep 2021 06:31:16 GMT, Sergey Bylokhov wrote: > The "java.util.logging.LogManager" class uses the "threadgroup sandboxing" via an AppContext to support "applet logging isolation". The AppContext class became useless since the plugin and webstart are no longer supported and removed in jdk11. > > This is the request to delete the usage of AppContext in the LogManager and related tests. > > Tested by tier1/tier2/tier3 and jdk_desktop tests. Hmm I was under the impression this was removing AppContext itself but it is just removing the backdoor needed by logging Perhaps this isn't the change that requires the CSR but it then leaves an inconsistent state where desktop supports AppContext still but other modules don't ... ------------- PR: https://git.openjdk.java.net/jdk/pull/5326 From prr at openjdk.java.net Fri Sep 3 17:33:24 2021 From: prr at openjdk.java.net (Phil Race) Date: Fri, 3 Sep 2021 17:33:24 GMT Subject: RFR: 8273101: Eliminate the usage of threadgroup sandboxing in the java.util.logging In-Reply-To: References: Message-ID: <6GaYNpoX8_A1olW1Ikfu03HdbhVbK7reFN0BdTnV77w=.1aecd2fc-ace8-4f91-9a2c-a08b05086fc0@github.com> On Wed, 1 Sep 2021 06:31:16 GMT, Sergey Bylokhov wrote: > The "java.util.logging.LogManager" class uses the "threadgroup sandboxing" via an AppContext to support "applet logging isolation". The AppContext class became useless since the plugin and webstart are no longer supported and removed in jdk11. > > This is the request to delete the usage of AppContext in the LogManager and related tests. > > Tested by tier1/tier2/tier3 and jdk_desktop tests. @aivanov-jdk will help make sure the closed changes are pushed at exactly the same time as this gets pushed. ------------- PR: https://git.openjdk.java.net/jdk/pull/5326 From serb at openjdk.java.net Fri Sep 3 17:40:23 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 3 Sep 2021 17:40:23 GMT Subject: RFR: 8273329: Remove redundant null check from String.getBytes(String charsetName) In-Reply-To: References: Message-ID: On Fri, 3 Sep 2021 13:22:54 GMT, ?????? ??????? wrote: > Current implementation looks like this: > > public byte[] getBytes(String charsetName) > throws UnsupportedEncodingException { > if (charsetName == null) throw new NullPointerException(); > return encode(lookupCharset(charsetName), coder(), value); > } > > Null check seems to be redundant here because the same check of `charsetName` is done within `String.lookupCharset(String)`: > > private static Charset lookupCharset(String csn) throws UnsupportedEncodingException { > Objects.requireNonNull(csn); > try { > return Charset.forName(csn); > } catch (UnsupportedCharsetException | IllegalCharsetNameException x) { > throw new UnsupportedEncodingException(csn); > } > } In such cases when the specific exception throwing is removed from the method because it can be produced by some other used method, the test might be useful. So if the code in the method will be changed, or the usage of other method will be removed the exception still be thrown. Probably such test exists already, then just point to it here. ------------- PR: https://git.openjdk.java.net/jdk/pull/5361 From serb at openjdk.java.net Fri Sep 3 17:46:27 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 3 Sep 2021 17:46:27 GMT Subject: RFR: 8273101: Eliminate the usage of threadgroup sandboxing in the java.util.logging In-Reply-To: References: Message-ID: On Fri, 3 Sep 2021 17:19:05 GMT, Phil Race wrote: > Perhaps this isn't the change that requires the CSR but it then leaves an inconsistent state where desktop supports AppContext still but other modules don't ... Even java.desktop does not support it fully, since for a couple of years nobody care about appcontext when write a new code. Note that I mentioned the "threadgroup sandboxing" in the subject, which is not necessary implemented via Appcontext. The JavaBeans and JavaSound use the thread group directly, I plan to remove them as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/5326 From smarks at openjdk.java.net Fri Sep 3 18:24:32 2021 From: smarks at openjdk.java.net (Stuart Marks) Date: Fri, 3 Sep 2021 18:24:32 GMT Subject: RFR: 8078641: MethodHandle.asTypeCache can retain classes from unloading [v4] In-Reply-To: References: Message-ID: On Fri, 3 Sep 2021 14:41:45 GMT, Vladimir Ivanov wrote: >> `MethodHandle.asTypeCache` keeps a strong reference to adapted `MethodHandle` and it can introduce a class loader leak through its `MethodType`. >> >> Proposed fix introduces a 2-level cache (1 element each) where 1st level can only contain `MethodHandle`s which are guaranteed to not introduce any dependencies on new class loaders compared to the original `MethodHandle`. 2nd level is backed by a `SoftReference` and is used as a backup when the result of `MethodHandle.asType()` conversion can't populate the higher level cache. >> >> The fix is based on [the work](http://cr.openjdk.java.net/~plevart/jdk9-dev/MethodHandle.asTypeCacheLeak/) made by Peter Levart @plevart back in 2015. >> >> Testing: tier1 - tier6 > > Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments Did we want this to use a soft reference or a weak reference? The original bug report mentions weak references, and the typical approach for preventing caches from holding onto things unnecessarily is to use weak references. I haven't thought through the implications of using soft instead of weak references. (Sorry if I missed any discussion on this issue.) ------------- PR: https://git.openjdk.java.net/jdk/pull/5246 From iignatyev at openjdk.java.net Fri Sep 3 18:34:40 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Fri, 3 Sep 2021 18:34:40 GMT Subject: RFR: 8273314: Add tier4 test groups In-Reply-To: <6rDioD5KZREYHyzOXol72O0erNDqKHUqb-0k1SwhInA=.90a12492-9e2f-4f0c-bf09-8d67d1d6111f@github.com> References: <6rDioD5KZREYHyzOXol72O0erNDqKHUqb-0k1SwhInA=.90a12492-9e2f-4f0c-bf09-8d67d1d6111f@github.com> Message-ID: On Fri, 3 Sep 2021 09:10:20 GMT, Aleksey Shipilev wrote: > During the review of JDK-8272914 that added hotspot:tier{2,3} groups, @iignatev suggested to create tier4 groups that capture all tests not in tiers{1,2,3}. I have excluded `vmTestbase` and `hotspot:tier4,` because they take 10+ hours on my highly parallel machine. I have also excluded `applications` from `hotspot:tier4`, because they require test dependencies (e.g. jcstress). > > Sample run: > > > ============================== > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR >>> jtreg:test/hotspot/jtreg:tier4 426 425 1 0 << >>> jtreg:test/jdk:tier4 2891 2885 4 2 << > jtreg:test/langtools:tier4 0 0 0 0 > jtreg:test/jaxp:tier4 0 0 0 0 > ============================== > > real 64m13.994s > user 1462m1.213s > sys 39m38.032s > > > There are interesting test failures on my machine, which I would address separately. > <...> I have excluded `vmTestbase` and `hotspot:tier4`<...> I have also excluded `applications` from `hotspot:tier4` <...> assuming the goal of tier4 is to catch the rest of the tests, I don't think we should exclude `vmTestbase`, `applications` or any other tests from tier4. unless you also want to create tier5 for them. -- Igor ------------- PR: https://git.openjdk.java.net/jdk/pull/5357 From smarks at openjdk.java.net Fri Sep 3 18:38:01 2021 From: smarks at openjdk.java.net (Stuart Marks) Date: Fri, 3 Sep 2021 18:38:01 GMT Subject: RFR: 6957241: ClassLoader.getResources() returns only 1 instance when using jar indexing In-Reply-To: References: Message-ID: On Fri, 3 Sep 2021 10:48:01 GMT, Alan Bateman wrote: > There will probably need to be some discussion on what to do with the jar tool. I suspect we will need to keep the code that updates the index when updating a JAR file that has an existing index, this means keeping JarIndex.... Depends on how draconian we're willing to be. At some point I can see the tool _removing_ the index if it's updating a jar file that has one. Suitable warning messages would need to be emitted. ------------- PR: https://git.openjdk.java.net/jdk/pull/5316 From iris at openjdk.java.net Fri Sep 3 18:42:02 2021 From: iris at openjdk.java.net (Iris Clark) Date: Fri, 3 Sep 2021 18:42:02 GMT Subject: RFR: 8273329: Remove redundant null check from String.getBytes(String charsetName) In-Reply-To: References: Message-ID: On Fri, 3 Sep 2021 13:22:54 GMT, ?????? ??????? wrote: > Current implementation looks like this: > > public byte[] getBytes(String charsetName) > throws UnsupportedEncodingException { > if (charsetName == null) throw new NullPointerException(); > return encode(lookupCharset(charsetName), coder(), value); > } > > Null check seems to be redundant here because the same check of `charsetName` is done within `String.lookupCharset(String)`: > > private static Charset lookupCharset(String csn) throws UnsupportedEncodingException { > Objects.requireNonNull(csn); > try { > return Charset.forName(csn); > } catch (UnsupportedCharsetException | IllegalCharsetNameException x) { > throw new UnsupportedEncodingException(csn); > } > } Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5361 From shade at openjdk.java.net Fri Sep 3 18:43:28 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 3 Sep 2021 18:43:28 GMT Subject: RFR: 8273314: Add tier4 test groups In-Reply-To: References: <6rDioD5KZREYHyzOXol72O0erNDqKHUqb-0k1SwhInA=.90a12492-9e2f-4f0c-bf09-8d67d1d6111f@github.com> Message-ID: On Fri, 3 Sep 2021 18:32:21 GMT, Igor Ignatyev wrote: > > <...> I have excluded `vmTestbase` and `hotspot:tier4`<...> I have also excluded `applications` from `hotspot:tier4` <...> > > assuming the goal of tier4 is to catch the rest of the tests, I don't think we should exclude `vmTestbase`, `applications` or any other tests from tier4. unless you also want to create tier5 for them. Apart from practicality of using `tier4`, I think `vmTestbase` and `applications` are separate test suites in their own right. `tier4` is catching all the assorted Hotspot tests that are not part of larger suites. Makes sense? ------------- PR: https://git.openjdk.java.net/jdk/pull/5357 From vlivanov at openjdk.java.net Fri Sep 3 18:54:40 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Fri, 3 Sep 2021 18:54:40 GMT Subject: RFR: 8078641: MethodHandle.asTypeCache can retain classes from unloading [v4] In-Reply-To: References: Message-ID: On Fri, 3 Sep 2021 14:41:45 GMT, Vladimir Ivanov wrote: >> `MethodHandle.asTypeCache` keeps a strong reference to adapted `MethodHandle` and it can introduce a class loader leak through its `MethodType`. >> >> Proposed fix introduces a 2-level cache (1 element each) where 1st level can only contain `MethodHandle`s which are guaranteed to not introduce any dependencies on new class loaders compared to the original `MethodHandle`. 2nd level is backed by a `SoftReference` and is used as a backup when the result of `MethodHandle.asType()` conversion can't populate the higher level cache. >> >> The fix is based on [the work](http://cr.openjdk.java.net/~plevart/jdk9-dev/MethodHandle.asTypeCacheLeak/) made by Peter Levart @plevart back in 2015. >> >> Testing: tier1 - tier6 > > Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments Other MethodHandle/LambdaForm caches in `java.lang.invoke` deliberately rely on `SoftReference`s. ?(Only `MethodType` table uses `WeakReference`, but it is there for interning purposes.) MH adaptations are quite expensive (and may involve class loading), so it's beneficial to keep the result around for an extended period of time when circumstances allow. On the other hand, `MH.asType()` case is special because it can hold user classes around which makes effective memory footprint of cached value much higher. So, `WeakReference` would enable more prompt recycling of heap memory at the expense of higher cache miss rate. Personally, I'm in favor `SoftReference` here since it allows to get most of performance benefits out of the cache while preserving the correctness w.r.t. heap exhaustion. ------------- PR: https://git.openjdk.java.net/jdk/pull/5246 From github.com+10835776+stsypanov at openjdk.java.net Fri Sep 3 19:23:05 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Fri, 3 Sep 2021 19:23:05 GMT Subject: RFR: 8273329: Remove redundant null check from String.getBytes(String charsetName) In-Reply-To: References: Message-ID: <6SK81BnuzDXID36fab3FildM_jXHK10jmc4IviE1x84=.ffce5115-c0a7-4b2d-99eb-2ae36fb6deaf@github.com> On Fri, 3 Sep 2021 17:37:08 GMT, Sergey Bylokhov wrote: >> Current implementation looks like this: >> >> public byte[] getBytes(String charsetName) >> throws UnsupportedEncodingException { >> if (charsetName == null) throw new NullPointerException(); >> return encode(lookupCharset(charsetName), coder(), value); >> } >> >> Null check seems to be redundant here because the same check of `charsetName` is done within `String.lookupCharset(String)`: >> >> private static Charset lookupCharset(String csn) throws UnsupportedEncodingException { >> Objects.requireNonNull(csn); >> try { >> return Charset.forName(csn); >> } catch (UnsupportedCharsetException | IllegalCharsetNameException x) { >> throw new UnsupportedEncodingException(csn); >> } >> } > > In such cases when the specific exception throwing is removed from the method because it can be produced by some other used method, the test might be useful. So if the code in the method will be changed, or the usage of other method will be removed the exception still be thrown. Probably such test exists already, then just point to it here. @mrserb you are right, there's such test, see `/test/jdk/java/lang/String/Exceptions.getBytes()`, line 384. ------------- PR: https://git.openjdk.java.net/jdk/pull/5361 From serb at openjdk.java.net Fri Sep 3 19:28:04 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 3 Sep 2021 19:28:04 GMT Subject: RFR: 8273329: Remove redundant null check from String.getBytes(String charsetName) In-Reply-To: References: Message-ID: <8TkROpBm8OcIEIeWaRmR97VXXEFaddyP0kCtDNjy0Js=.7cee0ff8-cf63-4498-a230-1ae2908403e9@github.com> On Fri, 3 Sep 2021 17:37:08 GMT, Sergey Bylokhov wrote: >> Current implementation looks like this: >> >> public byte[] getBytes(String charsetName) >> throws UnsupportedEncodingException { >> if (charsetName == null) throw new NullPointerException(); >> return encode(lookupCharset(charsetName), coder(), value); >> } >> >> Null check seems to be redundant here because the same check of `charsetName` is done within `String.lookupCharset(String)`: >> >> private static Charset lookupCharset(String csn) throws UnsupportedEncodingException { >> Objects.requireNonNull(csn); >> try { >> return Charset.forName(csn); >> } catch (UnsupportedCharsetException | IllegalCharsetNameException x) { >> throw new UnsupportedEncodingException(csn); >> } >> } > > In such cases when the specific exception throwing is removed from the method because it can be produced by some other used method, the test might be useful. So if the code in the method will be changed, or the usage of other method will be removed the exception still be thrown. Probably such test exists already, then just point to it here. > @mrserb you are right, there's such test, see `/test/jdk/java/lang/String/Exceptions.getBytes()`, line 384. Thank you for confirmation, looks fine. ------------- PR: https://git.openjdk.java.net/jdk/pull/5361 From github.com+10835776+stsypanov at openjdk.java.net Fri Sep 3 19:34:06 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Fri, 3 Sep 2021 19:34:06 GMT Subject: RFR: 8273329: Remove redundant null check from String.getBytes(String charsetName) In-Reply-To: References: Message-ID: On Fri, 3 Sep 2021 14:04:27 GMT, Roger Riggs wrote: > Redundant null checks get collapsed by HotSpot, so not a performance improvement. Hi Roger, indeed, no improvement observed. How did you know it beforehand? I was pretty sure we are going to win a couple of ns on this wide-used method. P.S. This double-check of null seems to be a left-over from https://github.com/openjdk/jdk/pull/2102. Previously there was only one NPE-throwing check there, but after `String.encode(Charset, byte, byte[])` was introduced we have two of them. ------------- PR: https://git.openjdk.java.net/jdk/pull/5361 From dfuchs at openjdk.java.net Fri Sep 3 20:30:12 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 3 Sep 2021 20:30:12 GMT Subject: RFR: 8273101: Eliminate the usage of threadgroup sandboxing in the java.util.logging In-Reply-To: References: Message-ID: <6tT-CF3Huqab-wBF2L_yzvaCw23pML3Oc2jFALEhWew=.306be274-9244-4050-b9be-d12542123c68@github.com> On Wed, 1 Sep 2021 06:31:16 GMT, Sergey Bylokhov wrote: > The "java.util.logging.LogManager" class uses the "threadgroup sandboxing" via an AppContext to support "applet logging isolation". The AppContext class became useless since the plugin and webstart are no longer supported and removed in jdk11. > > This is the request to delete the usage of AppContext in the LogManager and related tests. > > Tested by tier1/tier2/tier3 and jdk_desktop tests. Right. I am also a bit uncomfortable about the inconsistency. That said - if everybody agrees that this should be done I have no objection. The changes to the java.util.logging implementation correspond to my expectation if this were to be carried through. test/jdk/java/util/logging/TestLoggingWithMainAppContext.java line 1: > 1: /* Humm... There's no direct reference to AppContext here. Maybe this test should be preserved? ------------- PR: https://git.openjdk.java.net/jdk/pull/5326 From msheppar at openjdk.java.net Fri Sep 3 20:39:26 2021 From: msheppar at openjdk.java.net (Mark Sheppard) Date: Fri, 3 Sep 2021 20:39:26 GMT Subject: RFR: JDK-8273246 Amend the test java/nio/channels/DatagramChannel/ManySourcesAndTargets.java to execute in othervm mode Message-ID: A number of nio DatagramChannel tests are intermittently failing on macosx-aarch64. In some instances this is a receive call blocking indefinitely waiting on data which has already been sent, and should be available immediately to the receive method call. Other test failure scenarios are problems during the test compilation phase with a SocketException being thrown and the message: "test result: Error. Agent communication error: java.net.SocketException: No buffer space available; check console log for any additional details" The ManySourcesAndTargets and other tests execute in agentvm mode. This results in certain test diagnostic Output being lost during the test failure handling capture process. To mitigate this lost diagnostics, the ManySourcesAndTargets test has been amended to execute in othervm mode. Additionally, to assist in the buffer allocation issue, the netstat command executed by the test failure_handler has an extra argument added to obtain additional details on mbuf usage. The failure handler will now execute with netstat -mm ------------- Commit messages: - JDK-8273246 Amend the test java/nio/channels/DatagramChannel/ManySourcesAndTargets.java to execute in othervm mode Changes: https://git.openjdk.java.net/jdk/pull/5366/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5366&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273246 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5366.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5366/head:pull/5366 PR: https://git.openjdk.java.net/jdk/pull/5366 From serb at openjdk.java.net Fri Sep 3 22:17:56 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 3 Sep 2021 22:17:56 GMT Subject: RFR: 8273101: Eliminate the usage of threadgroup sandboxing in the java.util.logging In-Reply-To: <6tT-CF3Huqab-wBF2L_yzvaCw23pML3Oc2jFALEhWew=.306be274-9244-4050-b9be-d12542123c68@github.com> References: <6tT-CF3Huqab-wBF2L_yzvaCw23pML3Oc2jFALEhWew=.306be274-9244-4050-b9be-d12542123c68@github.com> Message-ID: On Thu, 2 Sep 2021 09:59:51 GMT, Daniel Fuchs wrote: >> The "java.util.logging.LogManager" class uses the "threadgroup sandboxing" via an AppContext to support "applet logging isolation". The AppContext class became useless since the plugin and webstart are no longer supported and removed in jdk11. >> >> This is the request to delete the usage of AppContext in the LogManager and related tests. >> >> Tested by tier1/tier2/tier3 and jdk_desktop tests. > > test/jdk/java/util/logging/TestLoggingWithMainAppContext.java line 1: > >> 1: /* > > Humm... There's no direct reference to AppContext here. Maybe this test should be preserved? It uses it indirectly, the next line under security manager trigger creation of the appcontext: `ImageIO.read(is); // triggers calls to system loggers & creation of main AppContext` but I can preserve/rename it for sure. ------------- PR: https://git.openjdk.java.net/jdk/pull/5326 From bpb at openjdk.java.net Fri Sep 3 22:37:18 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 3 Sep 2021 22:37:18 GMT Subject: RFR: 8255878: FilterInputStream is missing implementations of Java 9 InputStream methods Message-ID: <73JP6cAapkJpM3afNxR0U1m5I3RxshdsRx5oSJgqEJg=.e9f8fc5d-5992-4ead-bfa6-bbfff3728b59@github.com> This request proposes to modify `java.io.FilterInputStream` to override `readAllBytes()`, `readNBytes(int)`, `skipNBytes(long)`, and `transferTo(OutputStream)` in order to leverage any performance advantage that the wrapped stream might have over the `java.io.InputStream` implementations of these methods. ------------- Commit messages: - 8255878: FilterInputStream is missing implementations of Java 9 InputStream methods Changes: https://git.openjdk.java.net/jdk/pull/5367/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5367&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255878 Stats: 41 lines in 1 file changed: 40 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5367.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5367/head:pull/5367 PR: https://git.openjdk.java.net/jdk/pull/5367 From bpb at openjdk.java.net Fri Sep 3 22:37:19 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 3 Sep 2021 22:37:19 GMT Subject: RFR: 8255878: FilterInputStream is missing implementations of Java 9 InputStream methods In-Reply-To: <73JP6cAapkJpM3afNxR0U1m5I3RxshdsRx5oSJgqEJg=.e9f8fc5d-5992-4ead-bfa6-bbfff3728b59@github.com> References: <73JP6cAapkJpM3afNxR0U1m5I3RxshdsRx5oSJgqEJg=.e9f8fc5d-5992-4ead-bfa6-bbfff3728b59@github.com> Message-ID: On Fri, 3 Sep 2021 22:29:19 GMT, Brian Burkhalter wrote: > This request proposes to modify `java.io.FilterInputStream` to override `readAllBytes()`, `readNBytes(int)`, `skipNBytes(long)`, and `transferTo(OutputStream)` in order to leverage any performance advantage that the wrapped stream might have over the `java.io.InputStream` implementations of these methods. A quick and dirty benchmark of `readAllBytes()` and `readNBytes(int)` revealed throughput thrice that of the version without these overrides. The benchmark consisted of calling these methods on a `BufferedInputStream` with a buffer size of 1 MB wrapping a `FileInputStream` opened on a file of size 1 MB. **Before:** Benchmark Mode Cnt Score Error Units ReadNBytes.readAllBytes thrpt 5 2735.935 ? 26.461 ops/s ReadNBytes.readNBytes thrpt 5 2735.949 ? 16.348 ops/s **After:** Benchmark Mode Cnt Score Error Units ReadNBytes.readAllBytes thrpt 5 8245.034 ? 135.084 ops/s ReadNBytes.readNBytes thrpt 5 8320.554 ? 104.707 ops/s ------------- PR: https://git.openjdk.java.net/jdk/pull/5367 From bpb at openjdk.java.net Fri Sep 3 23:19:22 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 3 Sep 2021 23:19:22 GMT Subject: RFR: 8255878: FilterInputStream is missing implementations of Java 9 InputStream methods [v2] In-Reply-To: <73JP6cAapkJpM3afNxR0U1m5I3RxshdsRx5oSJgqEJg=.e9f8fc5d-5992-4ead-bfa6-bbfff3728b59@github.com> References: <73JP6cAapkJpM3afNxR0U1m5I3RxshdsRx5oSJgqEJg=.e9f8fc5d-5992-4ead-bfa6-bbfff3728b59@github.com> Message-ID: <-XW3tJUbBEPFVXK6CuI6UVU_Flg8V70_9gCjwiFedxI=.2b2061b8-738b-48f6-a931-db3ca3e8ffc2@github.com> > This request proposes to modify `java.io.FilterInputStream` to override `readAllBytes()`, `readNBytes(int)`, `skipNBytes(long)`, and `transferTo(OutputStream)` in order to leverage any performance advantage that the wrapped stream might have over the `java.io.InputStream` implementations of these methods. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8255878: Add @implSpec where appropriate ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5367/files - new: https://git.openjdk.java.net/jdk/pull/5367/files/ceed73ac..3064baee Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5367&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5367&range=00-01 Stats: 31 lines in 1 file changed: 13 ins; 3 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/5367.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5367/head:pull/5367 PR: https://git.openjdk.java.net/jdk/pull/5367 From stuart.marks at oracle.com Sat Sep 4 00:32:01 2021 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 3 Sep 2021 17:32:01 -0700 Subject: Possible ClassCastException in java.util.regex.Pattern.BmpCharPredicate#union(java.util.regex.Pattern.CharPredicate...) In-Reply-To: <9920D921-C228-4C4D-BBEB-B536FD9566B0@oracle.com> References: <9920D921-C228-4C4D-BBEB-B536FD9566B0@oracle.com> Message-ID: <770941cc-2f0c-b064-419b-5316f0d8894e@oracle.com> Yeah, not only does this static union() method seem like dead code, it seems wrong as well. Perhaps igraves should take a look at this. The whole area seems suspicious. There doesn't seem to be any semantic difference between BmpCharPredicate and CharPredicate. The and() & union() combinators preserve class: combining BmpCharPredicates gives a BmpCharPredicate, otherwise a CharPredicate. But evaluating one versus the other doesn't seem to make a difference. However, there are a couple instanceof checks that change logic paths in places where they're used... urghhh.... s'marks On 8/27/21 8:37 AM, Pavel Rappo wrote: > Has that method been ever used? If nothing else its name seems strange. To me, a union has OR semantics, not AND. > >> On 27 Aug 2021, at 15:37, Andrey Turbanov wrote: >> >> Hello. >> I found suspicious code in the method >> "java.util.regex.Pattern.BmpCharPredicate#union(java.util.regex.Pattern.CharPredicate...)" >> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/regex/Pattern.java#L5639 >> >> static CharPredicate union(CharPredicate... predicates) { >> CharPredicate cp = ch -> { >> for (CharPredicate p : predicates) { >> if (!p.is(ch)) >> return false; >> } >> return true; >> }; >> for (CharPredicate p : predicates) { >> if (! (p instanceof BmpCharPredicate)) >> return cp; >> } >> return (BmpCharPredicate)cp; >> } >> >> Variable `cp` has type CharPredicate initially. And then it's casted >> to BmpCharPredicate. This cast always fails with ClassCastException >> when reached. >> >> Can reproduced in small sample class: >> >> public static void main(String[] args) { >> CharPredicate result = BmpCharPredicate.union(); >> System.out.println(result); >> } >> >> interface CharPredicate { >> boolean is(int ch); >> } >> >> interface BmpCharPredicate extends CharPredicate { >> static CharPredicate union(CharPredicate... predicates) { >> CharPredicate cp = ch -> true; >> for (CharPredicate p : predicates) { >> if (! (p instanceof BmpCharPredicate)) >> return cp; >> } >> return (BmpCharPredicate)cp; >> } >> } >> >> >> Exception in thread "main" java.lang.ClassCastException: class >> org.RegexpBug$BmpCharPredicate$$Lambda$14/0x0000000800c028f0 cannot be >> cast to class org.RegexpBug$BmpCharPredicate >> (org.RegexpBug$BmpCharPredicate$$Lambda$14/0x0000000800c028f0 and >> org.RegexpBug$BmpCharPredicate are in unnamed module of loader 'app') >> at org.RegexpBug$BmpCharPredicate.union(RegexpBug.java:20) >> at org.RegexpBug.main(RegexpBug.java:5) >> >> As I can see this method is never used. Perhaps it should be removed? >> >> >> Andrey Turbanov > From dfuchs at openjdk.java.net Sat Sep 4 00:42:47 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Sat, 4 Sep 2021 00:42:47 GMT Subject: RFR: 8255878: FilterInputStream is missing implementations of Java 9 InputStream methods [v2] In-Reply-To: <-XW3tJUbBEPFVXK6CuI6UVU_Flg8V70_9gCjwiFedxI=.2b2061b8-738b-48f6-a931-db3ca3e8ffc2@github.com> References: <73JP6cAapkJpM3afNxR0U1m5I3RxshdsRx5oSJgqEJg=.e9f8fc5d-5992-4ead-bfa6-bbfff3728b59@github.com> <-XW3tJUbBEPFVXK6CuI6UVU_Flg8V70_9gCjwiFedxI=.2b2061b8-738b-48f6-a931-db3ca3e8ffc2@github.com> Message-ID: On Fri, 3 Sep 2021 23:19:22 GMT, Brian Burkhalter wrote: >> This request proposes to modify `java.io.FilterInputStream` to override `readAllBytes()`, `readNBytes(int)`, `skipNBytes(long)`, and `transferTo(OutputStream)` in order to leverage any performance advantage that the wrapped stream might have over the `java.io.InputStream` implementations of these methods. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8255878: Add @implSpec where appropriate This will probably break all existing subclasses that assume that they only need to override the single `int read()` method - because overriding this single method will now no longer be sufficient. Did you conduct a survey of existing subclasses of FilterInputStream (recursively), in the JDK and elsewhere, to evaluate the impact of this change? ------------- PR: https://git.openjdk.java.net/jdk/pull/5367 From naoto at openjdk.java.net Sat Sep 4 01:46:46 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Sat, 4 Sep 2021 01:46:46 GMT Subject: RFR: 8273329: Remove redundant null check from String.getBytes(String charsetName) In-Reply-To: References: Message-ID: On Fri, 3 Sep 2021 13:22:54 GMT, ?????? ??????? wrote: > Current implementation looks like this: > > public byte[] getBytes(String charsetName) > throws UnsupportedEncodingException { > if (charsetName == null) throw new NullPointerException(); > return encode(lookupCharset(charsetName), coder(), value); > } > > Null check seems to be redundant here because the same check of `charsetName` is done within `String.lookupCharset(String)`: > > private static Charset lookupCharset(String csn) throws UnsupportedEncodingException { > Objects.requireNonNull(csn); > try { > return Charset.forName(csn); > } catch (UnsupportedCharsetException | IllegalCharsetNameException x) { > throw new UnsupportedEncodingException(csn); > } > } Looks good. Please add some `noreg` keyword to the JIRA issue. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5361 From github.com+53162078+shiyuexw at openjdk.java.net Sat Sep 4 01:56:50 2021 From: github.com+53162078+shiyuexw at openjdk.java.net (wxiang) Date: Sat, 4 Sep 2021 01:56:50 GMT Subject: RFR: 6957241: ClassLoader.getResources() returns only 1 instance when using jar indexing In-Reply-To: References: Message-ID: On Fri, 3 Sep 2021 10:48:01 GMT, Alan Bateman wrote: > > @AlanBateman Sure, I am interested in it. > > Great! I think there are several parts to this. The removal of the JAR index support from the URLClassLoader implementation, the `jar i` option, the JAR file spec, and the jar tool man page. > > It would be good to create a patch for the removal to see if there are any issues. There will probably need to be some discussion on what to do with the jar tool. I suspect we will need to keep the code that updates the index when updating a JAR file that has an existing index, this means keeping JarIndex and maybe moving it to the jdk.jartool module. We can change `jar i` to print a warning when the tool is called to generate an index. Don't worry about the JAR spec and man page for now. I will first create the patch to remove JAR index support from the URLClassLoader implementation, the `jar i` option. ------------- PR: https://git.openjdk.java.net/jdk/pull/5316 From serb at openjdk.java.net Sat Sep 4 02:54:46 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sat, 4 Sep 2021 02:54:46 GMT Subject: RFR: 8273314: Add tier4 test groups In-Reply-To: <6rDioD5KZREYHyzOXol72O0erNDqKHUqb-0k1SwhInA=.90a12492-9e2f-4f0c-bf09-8d67d1d6111f@github.com> References: <6rDioD5KZREYHyzOXol72O0erNDqKHUqb-0k1SwhInA=.90a12492-9e2f-4f0c-bf09-8d67d1d6111f@github.com> Message-ID: <4ZMjEBOeBv6RVtgEhcfQ1sMVUyL8t2v4W4sc3iGY3r0=.d88a0dbc-d8d0-497b-bde7-9d5de283d11f@github.com> On Fri, 3 Sep 2021 09:10:20 GMT, Aleksey Shipilev wrote: > During the review of JDK-8272914 that added hotspot:tier{2,3} groups, @iignatev suggested to create tier4 groups that capture all tests not in tiers{1,2,3}. I have excluded `vmTestbase` and `hotspot:tier4,` because they take 10+ hours on my highly parallel machine. I have also excluded `applications` from `hotspot:tier4`, because they require test dependencies (e.g. jcstress). > > Sample run: > > > ============================== > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR >>> jtreg:test/hotspot/jtreg:tier4 426 425 1 0 << >>> jtreg:test/jdk:tier4 2891 2885 4 2 << > jtreg:test/langtools:tier4 0 0 0 0 > jtreg:test/jaxp:tier4 0 0 0 0 > ============================== > > real 64m13.994s > user 1462m1.213s > sys 39m38.032s > > > There are interesting test failures on my machine, which I would address separately. it looks like the results above do not include the headful tests did you filter them out? >> jtreg:test/jdk:tier4 2891 2885 4 2 << ------------- PR: https://git.openjdk.java.net/jdk/pull/5357 From iignatyev at openjdk.java.net Sat Sep 4 03:16:52 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Sat, 4 Sep 2021 03:16:52 GMT Subject: RFR: 8273314: Add tier4 test groups In-Reply-To: References: <6rDioD5KZREYHyzOXol72O0erNDqKHUqb-0k1SwhInA=.90a12492-9e2f-4f0c-bf09-8d67d1d6111f@github.com> Message-ID: On Fri, 3 Sep 2021 18:40:14 GMT, Aleksey Shipilev wrote: > > > <...> I have excluded `vmTestbase` and `hotspot:tier4`<...> I have also excluded `applications` from `hotspot:tier4` <...> > > > > > > assuming the goal of tier4 is to catch the rest of the tests, I don't think we should exclude `vmTestbase`, `applications` or any other tests from tier4. unless you also want to create tier5 for them. > > Apart from practicality of using `tier4`, I think `vmTestbase` and `applications` are separate test suites in their own right. `tier4` is catching all the assorted Hotspot tests that are not part of larger suites. Makes sense? to some extent. I agree that `applications` tests can/should be seen as a separate test suite, yet I differ on `vmTestbase` as the end goal for `vmTestbase` tests is (and always was) to become just another test within hotspot jtreg test suite, hence I don't think we should treat them any different than other jtreg tests. there is also a plan (which I need to formalize and share w/ a broader audience) to rearrange `vmTestbase` tests so they will be placed within the corresponding component subdirectories, which would bring us closer to the end goal and at the same time make it slightly harder to select all `vmTestbase` tests. -- Igor ------------- PR: https://git.openjdk.java.net/jdk/pull/5357 From alanb at openjdk.java.net Sat Sep 4 06:50:47 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 4 Sep 2021 06:50:47 GMT Subject: RFR: JDK-8273246 Amend the test java/nio/channels/DatagramChannel/ManySourcesAndTargets.java to execute in othervm mode In-Reply-To: References: Message-ID: On Fri, 3 Sep 2021 20:32:20 GMT, Mark Sheppard wrote: > A number of nio DatagramChannel tests are intermittently failing on macosx-aarch64. > In some instances this is a receive call blocking indefinitely waiting on data which has > already been sent, and should be available immediately to the receive method call. > Other test failure scenarios are problems during the test compilation phase with a SocketException being thrown and the message: > "test result: Error. Agent communication error: java.net.SocketException: No buffer space available; check console log for any additional details" > > The ManySourcesAndTargets and other tests execute in agentvm mode. This results in certain test diagnostic > Output being lost during the test failure handling capture process. To mitigate this lost diagnostics, the > ManySourcesAndTargets test has been amended to execute in othervm mode. > > Additionally, to assist in the buffer allocation issue, the netstat command executed by the test > failure_handler has an extra argument added to obtain additional details on mbuf usage. > The failure handler will now execute with netstat -mm Marked as reviewed by alanb (Reviewer). test/jdk/java/nio/channels/DatagramChannel/ManySourcesAndTargets.java line 28: > 26: * @summary Test DatagramChannel send/receive and that receive returns the expected > 27: * sender address > 28: * @run main/othervm ManySourcesAndTargets This change looks okay. Do you mind change L143 to use sender.send rather than reader.send while you are there? That will avoid at least some questions while trying to track down the underlying issue and will ensure that the test is printing out the actual sender address. ------------- PR: https://git.openjdk.java.net/jdk/pull/5366 From alanb at openjdk.java.net Sat Sep 4 06:53:51 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 4 Sep 2021 06:53:51 GMT Subject: RFR: 6957241: ClassLoader.getResources() returns only 1 instance when using jar indexing In-Reply-To: References: Message-ID: On Sat, 4 Sep 2021 01:53:35 GMT, wxiang wrote: > I will first create the patch to remove JAR index support from the URLClassLoader implementation, the `jar i` option. Thank you. We'll probably need a new JBS issue and PR for that but let's see first if any issues come out of the wood work. Stuart is right that another option for the jar tool is to drop the index when updating an existing JAR file that has an index, we don't need to decide that just yet. ------------- PR: https://git.openjdk.java.net/jdk/pull/5316 From alanb at openjdk.java.net Sat Sep 4 07:05:47 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 4 Sep 2021 07:05:47 GMT Subject: RFR: 8255878: FilterInputStream is missing implementations of Java 9 InputStream methods [v2] In-Reply-To: References: <73JP6cAapkJpM3afNxR0U1m5I3RxshdsRx5oSJgqEJg=.e9f8fc5d-5992-4ead-bfa6-bbfff3728b59@github.com> <-XW3tJUbBEPFVXK6CuI6UVU_Flg8V70_9gCjwiFedxI=.2b2061b8-738b-48f6-a931-db3ca3e8ffc2@github.com> Message-ID: On Sat, 4 Sep 2021 00:39:19 GMT, Daniel Fuchs wrote: > This may potentially break any existing subclasses that assume that they only need to override the three > `int read()` and `int read(byte[], int, it)` and `int skip(int)` methods - because overriding only these three methods will now no longer be sufficient. Can you explain this a bit further? InputStream has one abstract method so that's the minimum that has to be implemented. It has base implementations of readAllBytes and readNBytes that would be very inefficient if the 3-arg read is not overridden but I wouldn't expect a correctness issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/5367 From msheppar at openjdk.java.net Sat Sep 4 09:27:47 2021 From: msheppar at openjdk.java.net (Mark Sheppard) Date: Sat, 4 Sep 2021 09:27:47 GMT Subject: RFR: JDK-8273246 Amend the test java/nio/channels/DatagramChannel/ManySourcesAndTargets.java to execute in othervm mode In-Reply-To: References: Message-ID: <_r2peYohEmXneKEiknkrV3GYcwcvg4rkY3M-7vaeDrE=.ae667cdc-3e55-4ad7-84e8-3e6112d11793@github.com> On Sat, 4 Sep 2021 06:47:43 GMT, Alan Bateman wrote: >> A number of nio DatagramChannel tests are intermittently failing on macosx-aarch64. >> In some instances this is a receive call blocking indefinitely waiting on data which has >> already been sent, and should be available immediately to the receive method call. >> Other test failure scenarios are problems during the test compilation phase with a SocketException being thrown and the message: >> "test result: Error. Agent communication error: java.net.SocketException: No buffer space available; check console log for any additional details" >> >> The ManySourcesAndTargets and other tests execute in agentvm mode. This results in certain test diagnostic >> Output being lost during the test failure handling capture process. To mitigate this lost diagnostics, the >> ManySourcesAndTargets test has been amended to execute in othervm mode. >> >> Additionally, to assist in the buffer allocation issue, the netstat command executed by the test >> failure_handler has an extra argument added to obtain additional details on mbuf usage. >> The failure handler will now execute with netstat -mm > > test/jdk/java/nio/channels/DatagramChannel/ManySourcesAndTargets.java line 28: > >> 26: * @summary Test DatagramChannel send/receive and that receive returns the expected >> 27: * sender address >> 28: * @run main/othervm ManySourcesAndTargets > > This change looks okay. Do you mind change L143 to use sender.send rather than reader.send while you are there? That will avoid at least some questions while trying to track down the underlying issue and will ensure that the test is printing out the actual sender address. yes, I can do that ... the suggested change is currently part of a set of changes for JDK-8264385, but no problem to add it here now for this change set ------------- PR: https://git.openjdk.java.net/jdk/pull/5366 From lance.andersen at oracle.com Sat Sep 4 11:12:19 2021 From: lance.andersen at oracle.com (Lance Andersen) Date: Sat, 4 Sep 2021 11:12:19 +0000 Subject: RFR: 6957241: ClassLoader.getResources() returns only 1 instance when using jar indexing In-Reply-To: References: Message-ID: <701D9421-5197-4ED3-9D2B-BE4B5F3B876C@oracle.com> On Sep 4, 2021, at 2:53 AM, Alan Bateman > wrote: On Sat, 4 Sep 2021 01:53:35 GMT, wxiang > wrote: I will first create the patch to remove JAR index support from the URLClassLoader implementation, the `jar i` option. Thank you. We'll probably need a new JBS issue and PR for that but let's see first if any issues come out of the wood work. Stuart is right that another option for the jar tool is to drop the index when updating an existing JAR file that has an index, we don't need to decide that just yet. Perhaps the jar validate option could/should be updated to flag when an index is there? We could add a warning for JDK 18 when main::genIndex is invoked as I assume we would want to at least wait until JDK19 to remove this functionality? Best Lance ------------- PR: https://git.openjdk.java.net/jdk/pull/5316 [cid:E1C4E2F0-ECD0-4C9D-ADB4-B16CA7BCB7FC at home] Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From github.com+44376158+q2q-2q2 at openjdk.java.net Sat Sep 4 12:10:02 2021 From: github.com+44376158+q2q-2q2 at openjdk.java.net (q2q-2q2) Date: Sat, 4 Sep 2021 12:10:02 GMT Subject: RFR: JDK-8272192 Shortcut String equality checks by checking equality of the value array Message-ID: Shortcut String equality checks by checking equality of the value array ------------- Commit messages: - JDK-8272192 Changes: https://git.openjdk.java.net/jdk/pull/5370/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5370&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272192 Stats: 62 lines in 3 files changed: 60 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5370.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5370/head:pull/5370 PR: https://git.openjdk.java.net/jdk/pull/5370 From github.com+7806504+liach at openjdk.java.net Sat Sep 4 12:54:50 2021 From: github.com+7806504+liach at openjdk.java.net (liach) Date: Sat, 4 Sep 2021 12:54:50 GMT Subject: RFR: JDK-8272192 Shortcut String equality checks by checking equality of the value array In-Reply-To: References: Message-ID: On Sat, 4 Sep 2021 11:59:58 GMT, q2q-2q2 wrote: > Shortcut String equality checks by checking equality of the value array src/java.base/share/classes/java/lang/String.java line 1964: > 1962: public boolean equalsIgnoreCase(String anotherString) { > 1963: if (anotherString != null) { > 1964: return false; This one is definitely wrong. ------------- PR: https://git.openjdk.java.net/jdk/pull/5370 From jai.forums2013 at gmail.com Sat Sep 4 15:27:27 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Sat, 4 Sep 2021 20:57:27 +0530 Subject: Proposal: JDK-8231640 - (prop) Canonical property storage In-Reply-To: <9e287e72-42f3-d171-6473-fa3f47435b9f@gmail.com> References: <9b90a43f-defc-5100-3b5a-0a69214a706c@gmail.com> <86a3469a-7107-8c32-3240-28b10b470f87@oracle.com> <2c98d073-5a22-9732-b828-c1a08314d1a0@gmail.com> <6d97bada-0388-cb5c-bbbc-2712764e559b@gmail.com> <983f15b6-96e3-9aeb-c203-baea91dd1b24@oracle.com> <9e287e72-42f3-d171-6473-fa3f47435b9f@gmail.com> Message-ID: <29e73abd-15f6-4464-553f-76f4ed17b5bb@gmail.com> On 29/08/21 6:41 pm, Jaikiran Pai wrote: > > On 28/08/21 8:46 pm, Alan Bateman wrote: >> On 28/08/2021 05:45, Jaikiran Pai wrote: >>> I hadn't considered the system property approach to switch to old >>> behaviour in my proposals, so this is a very good input and I >>> personally think the most logical proposals so far. >> >> Roger may be right that few would care but it would be changing >> behavior that goes back to JDK 1.0. In your list (and thanks for >> writing down the options with pros/cons) then your 1a where >> SOURCE_DATE_EPOCH changes to write the epoch date rather than the >> current date seems to be most consistent with other tools and the >> wider eco system. It seems the least disruptive in that it doesn't >> change existing behavior and would be opt-in when reproducibility is >> required. > > In that case, I will start work along these lines. I've now opened a PR https://github.com/openjdk/jdk/pull/5372 with these proposed changes. -Jaikiran From jpai at openjdk.java.net Sat Sep 4 15:50:17 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Sat, 4 Sep 2021 15:50:17 GMT Subject: RFR: 8231640: (prop) Canonical property storage In-Reply-To: References: Message-ID: On Sat, 4 Sep 2021 15:25:59 GMT, Jaikiran Pai wrote: > The commit in this PR implements the proposal for enhancement that was discussed in the core-libs-dev mailing list recently[1], for https://bugs.openjdk.java.net/browse/JDK-8231640 > > At a high level - the `store()` APIs in `Properties` have been modified to now look for the `SOURCE_DATE_EPOCH` environment variable[2]. If that env variable is set, then instead of writing out the current date time as a date comment, the `store()` APIs instead will use the value set for this env variable to parse it to a `Date` and write out the string form of such a date. The implementation here uses the `d MMM yyyy HH:mm:ss 'GMT'` date format and `Locale.ROOT` to format and write out such a date. This should provide reproducibility whenever the `SOURCE_DATE_EPOCH` is set. Furthermore, intentionally, no changes in the date format of the "current date" have been done. > > These modified `store()` APIs work in the presence of the `SecurityManager` too. The caller is expected to have a read permission on the `SOURCE_DATE_EPOCH` environment variable. If the caller doesn't have that permission, then the implementation of these `store()` APIs will write out the "current date" and will ignore any value that has been set for the `SOURCE_DATE_EPOCH` env variable. This should allow for backward compatibility of existing applications, where, when they run under a `SecurityManager` and perhaps with an existing restrictive policy file, the presence of `SOURCE_DATE_EPOCH` shouldn't impact their calls to the `store()` APIs. > > The modified `store()` APIs will also ignore any value for `SOURCE_DATE_EPOCH` that cannot be parsed to an `long` value. In such cases, the `store()` APIs will write out the "current date" and ignore the value set for this environment variable. No exceptions will be thrown for such invalid values. This is an additional backward compatibility precaution to prevent any rogue value for `SOURCE_DATE_EPOCH` from breaking applications. > > An additional change in the implementation of these `store()` APIs and unrelated to the date comment, is that these APIs will now write out the property keys in a deterministic order. The keys will be written out in the natural ordering as specified by `java.lang.String#compareTo()` API. > > The combination of the ordering of the property keys when written out and the usage of `SOURCE_DATE_EPOCH` environment value to determine the date comment should together allow for reproducibility of the output generated by these `store()` APIs. > > New jtreg test classes have been introduced to verify these changes. The primary focus of `PropertiesStoreTest` is the ordering aspects of the property keys that are written out. On the other hand `StoreReproducibilityTest` focuses on the reproducibility of the output generated by these APIs. The `StoreReproducibilityTest` runs these tests both in the presence and absence of `SecurityManager`. Plus, in the presence of SecurityManager, it tests both the scenarios where the caller is granted the requisite permission and in other case not granted that permission. > > These new tests and existing tests under `test/jdk/java/util/Properties/` pass with these changes. > > [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-August/080758.html > [2] https://reproducible-builds.org/specs/source-date-epoch/ I haven't yet created a CSR for this and will do that next week once the initial reviews and changes are sorted out. ------------- PR: https://git.openjdk.java.net/jdk/pull/5372 From jpai at openjdk.java.net Sat Sep 4 15:50:17 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Sat, 4 Sep 2021 15:50:17 GMT Subject: RFR: 8231640: (prop) Canonical property storage Message-ID: The commit in this PR implements the proposal for enhancement that was discussed in the core-libs-dev mailing list recently[1], for https://bugs.openjdk.java.net/browse/JDK-8231640 At a high level - the `store()` APIs in `Properties` have been modified to now look for the `SOURCE_DATE_EPOCH` environment variable[2]. If that env variable is set, then instead of writing out the current date time as a date comment, the `store()` APIs instead will use the value set for this env variable to parse it to a `Date` and write out the string form of such a date. The implementation here uses the `d MMM yyyy HH:mm:ss 'GMT'` date format and `Locale.ROOT` to format and write out such a date. This should provide reproducibility whenever the `SOURCE_DATE_EPOCH` is set. Furthermore, intentionally, no changes in the date format of the "current date" have been done. These modified `store()` APIs work in the presence of the `SecurityManager` too. The caller is expected to have a read permission on the `SOURCE_DATE_EPOCH` environment variable. If the caller doesn't have that permission, then the implementation of these `store()` APIs will write out the "current date" and will ignore any value that has been set for the `SOURCE_DATE_EPOCH` env variable. This should allow for backward compatibility of existing applications, where, when they run under a `SecurityManager` and perhaps with an existing restrictive policy file, the presence of `SOURCE_DATE_EPOCH` shouldn't impact their calls to the `store()` APIs. The modified `store()` APIs will also ignore any value for `SOURCE_DATE_EPOCH` that cannot be parsed to an `long` value. In such cases, the `store()` APIs will write out the "current date" and ignore the value set for this environment variable. No exceptions will be thrown for such invalid values. This is an additional backward compatibility precaution to prevent any rogue value for `SOURCE_DATE_EPOCH` from breaking applications. An additional change in the implementation of these `store()` APIs and unrelated to the date comment, is that these APIs will now write out the property keys in a deterministic order. The keys will be written out in the natural ordering as specified by `java.lang.String#compareTo()` API. The combination of the ordering of the property keys when written out and the usage of `SOURCE_DATE_EPOCH` environment value to determine the date comment should together allow for reproducibility of the output generated by these `store()` APIs. New jtreg test classes have been introduced to verify these changes. The primary focus of `PropertiesStoreTest` is the ordering aspects of the property keys that are written out. On the other hand `StoreReproducibilityTest` focuses on the reproducibility of the output generated by these APIs. The `StoreReproducibilityTest` runs these tests both in the presence and absence of `SecurityManager`. Plus, in the presence of SecurityManager, it tests both the scenarios where the caller is granted the requisite permission and in other case not granted that permission. These new tests and existing tests under `test/jdk/java/util/Properties/` pass with these changes. [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-August/080758.html [2] https://reproducible-builds.org/specs/source-date-epoch/ ------------- Commit messages: - 8231640: (prop) Canonical property storage Changes: https://git.openjdk.java.net/jdk/pull/5372/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5372&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8231640 Stats: 667 lines in 5 files changed: 663 ins; 1 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5372.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5372/head:pull/5372 PR: https://git.openjdk.java.net/jdk/pull/5372 From github.com+741251+turbanoff at openjdk.java.net Sat Sep 4 18:32:50 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Sat, 4 Sep 2021 18:32:50 GMT Subject: RFR: 8231640: (prop) Canonical property storage In-Reply-To: References: Message-ID: On Sat, 4 Sep 2021 15:25:59 GMT, Jaikiran Pai wrote: > The commit in this PR implements the proposal for enhancement that was discussed in the core-libs-dev mailing list recently[1], for https://bugs.openjdk.java.net/browse/JDK-8231640 > > At a high level - the `store()` APIs in `Properties` have been modified to now look for the `SOURCE_DATE_EPOCH` environment variable[2]. If that env variable is set, then instead of writing out the current date time as a date comment, the `store()` APIs instead will use the value set for this env variable to parse it to a `Date` and write out the string form of such a date. The implementation here uses the `d MMM yyyy HH:mm:ss 'GMT'` date format and `Locale.ROOT` to format and write out such a date. This should provide reproducibility whenever the `SOURCE_DATE_EPOCH` is set. Furthermore, intentionally, no changes in the date format of the "current date" have been done. > > These modified `store()` APIs work in the presence of the `SecurityManager` too. The caller is expected to have a read permission on the `SOURCE_DATE_EPOCH` environment variable. If the caller doesn't have that permission, then the implementation of these `store()` APIs will write out the "current date" and will ignore any value that has been set for the `SOURCE_DATE_EPOCH` env variable. This should allow for backward compatibility of existing applications, where, when they run under a `SecurityManager` and perhaps with an existing restrictive policy file, the presence of `SOURCE_DATE_EPOCH` shouldn't impact their calls to the `store()` APIs. > > The modified `store()` APIs will also ignore any value for `SOURCE_DATE_EPOCH` that cannot be parsed to an `long` value. In such cases, the `store()` APIs will write out the "current date" and ignore the value set for this environment variable. No exceptions will be thrown for such invalid values. This is an additional backward compatibility precaution to prevent any rogue value for `SOURCE_DATE_EPOCH` from breaking applications. > > An additional change in the implementation of these `store()` APIs and unrelated to the date comment, is that these APIs will now write out the property keys in a deterministic order. The keys will be written out in the natural ordering as specified by `java.lang.String#compareTo()` API. > > The combination of the ordering of the property keys when written out and the usage of `SOURCE_DATE_EPOCH` environment value to determine the date comment should together allow for reproducibility of the output generated by these `store()` APIs. > > New jtreg test classes have been introduced to verify these changes. The primary focus of `PropertiesStoreTest` is the ordering aspects of the property keys that are written out. On the other hand `StoreReproducibilityTest` focuses on the reproducibility of the output generated by these APIs. The `StoreReproducibilityTest` runs these tests both in the presence and absence of `SecurityManager`. Plus, in the presence of SecurityManager, it tests both the scenarios where the caller is granted the requisite permission and in other case not granted that permission. > > These new tests and existing tests under `test/jdk/java/util/Properties/` pass with these changes. > > [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-August/080758.html > [2] https://reproducible-builds.org/specs/source-date-epoch/ src/java.base/share/classes/java/util/Properties.java line 924: > 922: writeDateComment(bw); > 923: synchronized (this) { > 924: for (Map.Entry e : new TreeMap<>(map).entrySet()) { Is this sorting intentionally added? It's not clear from issue description or PR description that order of properties should be changed too. Anyway I think copying to array and then sorting should be faster, that creating TreeMap ------------- PR: https://git.openjdk.java.net/jdk/pull/5372 From github.com+10835776+stsypanov at openjdk.java.net Sat Sep 4 19:21:47 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Sat, 4 Sep 2021 19:21:47 GMT Subject: RFR: 8273329: Remove redundant null check from String.getBytes(String charsetName) In-Reply-To: References: Message-ID: On Sat, 4 Sep 2021 01:43:57 GMT, Naoto Sato wrote: >> Current implementation looks like this: >> >> public byte[] getBytes(String charsetName) >> throws UnsupportedEncodingException { >> if (charsetName == null) throw new NullPointerException(); >> return encode(lookupCharset(charsetName), coder(), value); >> } >> >> Null check seems to be redundant here because the same check of `charsetName` is done within `String.lookupCharset(String)`: >> >> private static Charset lookupCharset(String csn) throws UnsupportedEncodingException { >> Objects.requireNonNull(csn); >> try { >> return Charset.forName(csn); >> } catch (UnsupportedCharsetException | IllegalCharsetNameException x) { >> throw new UnsupportedEncodingException(csn); >> } >> } > > Looks good. Please add some `noreg` keyword to the JIRA issue. @naotoj done, added `noreg-cleanup` tag ------------- PR: https://git.openjdk.java.net/jdk/pull/5361 From Alan.Bateman at oracle.com Sun Sep 5 08:16:48 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 5 Sep 2021 09:16:48 +0100 Subject: RFR: 8231640: (prop) Canonical property storage In-Reply-To: References: Message-ID: <0851283f-23f6-a8e6-03c5-d98d29770dbc@oracle.com> On 04/09/2021 16:50, Jaikiran Pai wrote: > The commit in this PR implements the proposal for enhancement that was discussed in the core-libs-dev mailing list recently[1], for https://bugs.openjdk.java.net/browse/JDK-8231640 > > At a high level - the `store()` APIs in `Properties` have been modified to now look for the `SOURCE_DATE_EPOCH` environment variable[2]. If that env variable is set, then instead of writing out the current date time as a date comment, the `store()` APIs instead will use the value set for this env variable to parse it to a `Date` and write out the string form of such a date. The implementation here uses the `d MMM yyyy HH:mm:ss 'GMT'` date format and `Locale.ROOT` to format and write out such a date. This should provide reproducibility whenever the `SOURCE_DATE_EPOCH` is set. Furthermore, intentionally, no changes in the date format of the "current date" have been done. > > These modified `store()` APIs work in the presence of the `SecurityManager` too. The caller is expected to have a read permission on the `SOURCE_DATE_EPOCH` environment variable. If the caller doesn't have that permission, then the implementation of these `store()` APIs will write out the "current date" and will ignore any value that has been set for the `SOURCE_DATE_EPOCH` env variable. This should allow for backward compatibility of existing applications, where, when they run under a `SecurityManager` and perhaps with an existing restrictive policy file, the presence of `SOURCE_DATE_EPOCH` shouldn't impact their calls to the `store()` APIs. > > The modified `store()` APIs will also ignore any value for `SOURCE_DATE_EPOCH` that cannot be parsed to an `long` value. In such cases, the `store()` APIs will write out the "current date" and ignore the value set for this environment variable. No exceptions will be thrown for such invalid values. This is an additional backward compatibility precaution to prevent any rogue value for `SOURCE_DATE_EPOCH` from breaking applications. In the discussion on this option then I think we were talking about changing the specification of the store methods to allow for an implementation specific means to override the date and put the discussion on SOURCE_DATE_EPOCH in an @implNote. The SM case probably needs discussion as I was expecting to see something like this: PrivilegedAction pa = () -> System.getenv("SOURCE_DATE_EPOCH"); String value = AccessController.doPrivileged(pa); as a caller of the store method (in a library for example) is unlikely to have this permission. I assume your concern is that untrusted code would have a way to read this specific env variable without a permission (by way of creating and storing an empty Properties)?? In this case I'm mostly wondering if it's really worth having a behavior difference in this mode. > > An additional change in the implementation of these `store()` APIs and unrelated to the date comment, is that these APIs will now write out the property keys in a deterministic order. The keys will be written out in the natural ordering as specified by `java.lang.String#compareTo()` API. > The store methods are already specified to throw CCE if the properties has non-String keys so this should be okay. -Alan From Alan.Bateman at oracle.com Sun Sep 5 08:23:35 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 5 Sep 2021 09:23:35 +0100 Subject: RFR: 6957241: ClassLoader.getResources() returns only 1 instance when using jar indexing In-Reply-To: <701D9421-5197-4ED3-9D2B-BE4B5F3B876C@oracle.com> References: <701D9421-5197-4ED3-9D2B-BE4B5F3B876C@oracle.com> Message-ID: <3951b69f-984c-8260-83b4-9b1ff3b1ca2f@oracle.com> On 04/09/2021 12:12, Lance Andersen wrote: > > Perhaps the jar validate option could/should be updated to flag when > an index is there? > > We could add a warning for JDK 18 when main::genIndex is invoked as I > assume we would want to at least wait until JDK19 to remove this > functionality? > I'm not sure about jar --validate complaining if META-INF/INDEX.LIST is present. It may be useful if it were to check that the index is correct but it would need the entries listed in the Class-Path attribute to be found. I don't think we really need to do anything to the jar tool in the short term, except just to move JarIndex to the jdk.jartool module. I think the more important part is removing the JAR index support from the runtime. I don't expect any issues with the URLClassLoader implementation but it is possible that something comes out of the wood work with signed JARs (JarVerifier). -Alan From msheppar at openjdk.java.net Sun Sep 5 11:00:27 2021 From: msheppar at openjdk.java.net (Mark Sheppard) Date: Sun, 5 Sep 2021 11:00:27 GMT Subject: RFR: JDK-8273246 Amend the test java/nio/channels/DatagramChannel/ManySourcesAndTargets.java to execute in othervm mode [v2] In-Reply-To: References: Message-ID: > A number of nio DatagramChannel tests are intermittently failing on macosx-aarch64. > In some instances this is a receive call blocking indefinitely waiting on data which has > already been sent, and should be available immediately to the receive method call. > Other test failure scenarios are problems during the test compilation phase with a SocketException being thrown and the message: > "test result: Error. Agent communication error: java.net.SocketException: No buffer space available; check console log for any additional details" > > The ManySourcesAndTargets and other tests execute in agentvm mode. This results in certain test diagnostic > Output being lost during the test failure handling capture process. To mitigate this lost diagnostics, the > ManySourcesAndTargets test has been amended to execute in othervm mode. > > Additionally, to assist in the buffer allocation issue, the netstat command executed by the test > failure_handler has an extra argument added to obtain additional details on mbuf usage. > The failure handler will now execute with netstat -mm Mark Sheppard has updated the pull request incrementally with one additional commit since the last revision: JDK-8273246 fix logic error in testReceive method change reader.send to sender.send ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5366/files - new: https://git.openjdk.java.net/jdk/pull/5366/files/afe29d42..0effbcd4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5366&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5366&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5366.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5366/head:pull/5366 PR: https://git.openjdk.java.net/jdk/pull/5366 From jai.forums2013 at gmail.com Sun Sep 5 12:31:32 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Sun, 5 Sep 2021 18:01:32 +0530 Subject: RFR: 8231640: (prop) Canonical property storage In-Reply-To: <0851283f-23f6-a8e6-03c5-d98d29770dbc@oracle.com> References: <0851283f-23f6-a8e6-03c5-d98d29770dbc@oracle.com> Message-ID: Hello Alan, On 05/09/21 1:46 pm, Alan Bateman wrote: > On 04/09/2021 16:50, Jaikiran Pai wrote: >> The commit in this PR implements the proposal for enhancement that >> was discussed in the core-libs-dev mailing list recently[1], for >> https://bugs.openjdk.java.net/browse/JDK-8231640 >> >> At a high level - the `store()` APIs in `Properties` have been >> modified to now look for the `SOURCE_DATE_EPOCH` environment >> variable[2]. If that env variable is set, then instead of writing out >> the current date time as a date comment, the `store()` APIs instead >> will use the value set for this env variable to parse it to a `Date` >> and write out the string form of such a date. The implementation here >> uses the `d MMM yyyy HH:mm:ss 'GMT'` date format and `Locale.ROOT` to >> format and write out such a date. This should provide reproducibility >> whenever the `SOURCE_DATE_EPOCH` is set. Furthermore, intentionally, >> no changes in the date format of the "current date" have been done. >> >> These? modified `store()` APIs work in the presence of the >> `SecurityManager` too. The caller is expected to have a read >> permission on the `SOURCE_DATE_EPOCH` environment variable. If the >> caller doesn't have that permission, then the implementation of these >> `store()` APIs will write out the "current date" and will ignore any >> value that has been set for the `SOURCE_DATE_EPOCH` env variable. >> This should allow for backward compatibility of existing >> applications, where, when they run under a `SecurityManager` and >> perhaps with an existing restrictive policy file, the presence of >> `SOURCE_DATE_EPOCH` shouldn't impact their calls to the `store()` APIs. >> >> The modified `store()` APIs will also ignore any value for >> `SOURCE_DATE_EPOCH` that? cannot be parsed to an `long` value. In >> such cases, the `store()` APIs will write out the "current date" and >> ignore the value set for this environment variable. No exceptions >> will be thrown for such invalid values. This is an additional >> backward compatibility precaution to prevent any rogue value for >> `SOURCE_DATE_EPOCH` from breaking applications. > In the discussion on this option then I think we were talking about > changing the specification of the store methods to allow for an > implementation specific means to override the date and put the > discussion on SOURCE_DATE_EPOCH in an @implNote. > I will move the updated javadoc to an @implNote then. I guess, the existing part where it explains how the current date comment is written out, should stay where it is currently? > The SM case probably needs discussion as I was expecting to see > something like this: > > PrivilegedAction pa = () -> System.getenv("SOURCE_DATE_EPOCH"); > String value = AccessController.doPrivileged(pa); > > as a caller of the store method (in a library for example) is unlikely > to have this permission. I assume your concern is that untrusted code > would have a way to read this specific env variable without a > permission (by way of creating and storing an empty Properties)?? In > this case I'm mostly wondering if it's really worth having a behavior > difference in this mode. I had initially started off with using a doPrivileged code in this change. However, I soon realized that it might be a security hole, like in the example you state. Unlike other parts of the JDK code where the doPrivileged makes sense, since the "action" part of it does things that are internal implementation details to the JDK, this new piece of code that we are introducing, does a System.getenv(...) in its "action" but will then additionally hand out the value (in a formatted manner of course) of that environment variable to the callers, through the OutputStream/Writer instances that the callers pass in to the store() APIs. Effectively, this means that even when getenv.SOURCE_DATE_EPOCH (or getenv.* for that matter) haven't been granted to the callers, they will _always_ be able to get hold of that environment variable's value through this approach. Like you state, they could just call Properties.store() (which by the way, doesn't necessarily have to be empty) to bypass the security checks that are put in place for the direct System.getenv(...) calls from their code. In such a doPrivelged case, the only way the administrator can prevent this security bypass, would then be to _not_ grant this permission to the JDK code itself, which then effectively means that this enhancement for using SOURCE_DATE_EPOCH will not take effect at all and the date comment will always write out the current date. So the doPriveleged case, IMO, will not allow selective granting of permissions to callers. The alternate approach that's used in this PR, on the other hand allows for selective granting of permissions. I'm not too aware of how things stand with the application server and security manager integration these days, but I would guess that in such use cases where you probably would want to control which deployed applications (within the same JVM) are granted what permissions, this alternate approach of not using the doPriveleged would make it feasible to control these permissions. -Jaikiran From jai.forums2013 at gmail.com Sun Sep 5 12:36:31 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Sun, 5 Sep 2021 18:06:31 +0530 Subject: RFR: 8231640: (prop) Canonical property storage In-Reply-To: References: Message-ID: Hello Andrey, On 05/09/21 12:02 am, Andrey Turbanov wrote: > > src/java.base/share/classes/java/util/Properties.java line 924: > >> 922: writeDateComment(bw); >> 923: synchronized (this) { >> 924: for (Map.Entry e : new TreeMap<>(map).entrySet()) { > Is this sorting intentionally added? It's not clear from issue description or PR description that order of properties should be changed too. > Anyway I think copying to array and then sorting should be faster, that creating TreeMap Yes, the ordering of the properties is intentional as noted in the description of this PR as well as the linked mail discussion thread. As for the usage of TreeMap, I had looked around the JDK code to see if there are more performant ways to order that existing Map, but I couldn't find any. Do you mean that converting the keySet() of an existing Map into an array and then sorting that array and then using that sorted array to iterate and using these keys to do an additional lookup for value against the original Map would be more efficient in this case? I can experiment with it in a simple JMH benchmark with some decent/regular sized Map and see how it performs. -Jaikiran From alanb at openjdk.java.net Sun Sep 5 12:38:52 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 5 Sep 2021 12:38:52 GMT Subject: RFR: JDK-8273246 Amend the test java/nio/channels/DatagramChannel/ManySourcesAndTargets.java to execute in othervm mode [v2] In-Reply-To: References: Message-ID: <9vwG8dx4p0bvGEZu9DRrXZmttjtWm-ACbo26a6-bJdM=.9dd6b4de-b095-4d9c-a9e0-adffb838f16e@github.com> On Sun, 5 Sep 2021 11:00:27 GMT, Mark Sheppard wrote: >> A number of nio DatagramChannel tests are intermittently failing on macosx-aarch64. >> In some instances this is a receive call blocking indefinitely waiting on data which has >> already been sent, and should be available immediately to the receive method call. >> Other test failure scenarios are problems during the test compilation phase with a SocketException being thrown and the message: >> "test result: Error. Agent communication error: java.net.SocketException: No buffer space available; check console log for any additional details" >> >> The ManySourcesAndTargets and other tests execute in agentvm mode. This results in certain test diagnostic >> Output being lost during the test failure handling capture process. To mitigate this lost diagnostics, the >> ManySourcesAndTargets test has been amended to execute in othervm mode. >> >> Additionally, to assist in the buffer allocation issue, the netstat command executed by the test >> failure_handler has an extra argument added to obtain additional details on mbuf usage. >> The failure handler will now execute with netstat -mm > > Mark Sheppard has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8273246 fix logic error in testReceive method change reader.send to sender.send Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5366 From jpai at openjdk.java.net Sun Sep 5 12:59:54 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Sun, 5 Sep 2021 12:59:54 GMT Subject: RFR: 8231640: (prop) Canonical property storage In-Reply-To: References: Message-ID: On Sat, 4 Sep 2021 15:25:59 GMT, Jaikiran Pai wrote: > The commit in this PR implements the proposal for enhancement that was discussed in the core-libs-dev mailing list recently[1], for https://bugs.openjdk.java.net/browse/JDK-8231640 > > At a high level - the `store()` APIs in `Properties` have been modified to now look for the `SOURCE_DATE_EPOCH` environment variable[2]. If that env variable is set, then instead of writing out the current date time as a date comment, the `store()` APIs instead will use the value set for this env variable to parse it to a `Date` and write out the string form of such a date. The implementation here uses the `d MMM yyyy HH:mm:ss 'GMT'` date format and `Locale.ROOT` to format and write out such a date. This should provide reproducibility whenever the `SOURCE_DATE_EPOCH` is set. Furthermore, intentionally, no changes in the date format of the "current date" have been done. > > These modified `store()` APIs work in the presence of the `SecurityManager` too. The caller is expected to have a read permission on the `SOURCE_DATE_EPOCH` environment variable. If the caller doesn't have that permission, then the implementation of these `store()` APIs will write out the "current date" and will ignore any value that has been set for the `SOURCE_DATE_EPOCH` env variable. This should allow for backward compatibility of existing applications, where, when they run under a `SecurityManager` and perhaps with an existing restrictive policy file, the presence of `SOURCE_DATE_EPOCH` shouldn't impact their calls to the `store()` APIs. > > The modified `store()` APIs will also ignore any value for `SOURCE_DATE_EPOCH` that cannot be parsed to an `long` value. In such cases, the `store()` APIs will write out the "current date" and ignore the value set for this environment variable. No exceptions will be thrown for such invalid values. This is an additional backward compatibility precaution to prevent any rogue value for `SOURCE_DATE_EPOCH` from breaking applications. > > An additional change in the implementation of these `store()` APIs and unrelated to the date comment, is that these APIs will now write out the property keys in a deterministic order. The keys will be written out in the natural ordering as specified by `java.lang.String#compareTo()` API. > > The combination of the ordering of the property keys when written out and the usage of `SOURCE_DATE_EPOCH` environment value to determine the date comment should together allow for reproducibility of the output generated by these `store()` APIs. > > New jtreg test classes have been introduced to verify these changes. The primary focus of `PropertiesStoreTest` is the ordering aspects of the property keys that are written out. On the other hand `StoreReproducibilityTest` focuses on the reproducibility of the output generated by these APIs. The `StoreReproducibilityTest` runs these tests both in the presence and absence of `SecurityManager`. Plus, in the presence of SecurityManager, it tests both the scenarios where the caller is granted the requisite permission and in other case not granted that permission. > > These new tests and existing tests under `test/jdk/java/util/Properties/` pass with these changes. > > [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-August/080758.html > [2] https://reproducible-builds.org/specs/source-date-epoch/ Off topic - the `tier1` failures that are being reported in GitHub action jobs seem genuine but unrelated to this change. The failure is consistently in a single test `InfoOptsTest` and it fails with the following error when running the `testUniqueInfoOpts` test case. Looks like a recent issue in some commit. I'll sort that out separately. Here's the error from the logs: 2021-09-04T16:37:24.7528210Z Running test testUniqueInfoOpts 2021-09-04T16:37:24.7630470Z Main [--help, --help] [] 2021-09-04T16:37:24.7635480Z rc:0 2021-09-04T16:37:24.7736940Z javac/DIRECT: 2021-09-04T16:37:24.7762440Z Usage: javac 2021-09-04T16:37:24.7863980Z where possible options include: 2021-09-04T16:37:24.7892480Z @ Read options and filenames from file 2021-09-04T16:37:24.7986700Z -Akey[=value] Options to pass to annotation processors 2021-09-04T16:37:24.8003100Z --add-modules (,)* 2021-09-04T16:37:24.8030720Z Root modules to resolve in addition to the initial modules, or all modules 2021-09-04T16:37:24.8106550Z on the module path if is ALL-MODULE-PATH. 2021-09-04T16:37:24.8108330Z --boot-class-path , -bootclasspath 2021-09-04T16:37:24.8110830Z Override location of bootstrap class files 2021-09-04T16:37:24.8112470Z --class-path , -classpath , -cp 2021-09-04T16:37:24.8113590Z Specify where to find user class files and annotation processors 2021-09-04T16:37:24.8115140Z -d Specify where to place generated class files 2021-09-04T16:37:24.8116530Z -deprecation 2021-09-04T16:37:24.8117490Z Output source locations where deprecated APIs are used 2021-09-04T16:37:24.8118770Z --enable-preview 2021-09-04T16:37:24.8120330Z Enable preview language features. To be used in conjunction with either -source or --release. 2021-09-04T16:37:24.8129810Z -encoding Specify character encoding used by source files 2021-09-04T16:37:24.8136440Z -endorseddirs Override location of endorsed standards path 2021-09-04T16:37:24.8239190Z -extdirs Override location of installed extensions 2021-09-04T16:37:24.8251400Z -g Generate all debugging info 2021-09-04T16:37:24.8290250Z -g:{lines,vars,source} Generate only some debugging info 2021-09-04T16:37:24.8291910Z -g:none Generate no debugging info 2021-09-04T16:37:24.8293200Z -h 2021-09-04T16:37:24.8294170Z Specify where to place generated native header files 2021-09-04T16:37:24.8296270Z --help, -help, -? Print this help message 2021-09-04T16:37:24.8297720Z --help-extra, -X Print help on extra options 2021-09-04T16:37:24.8299160Z -implicit:{none,class} 2021-09-04T16:37:24.8300250Z Specify whether or not to generate class files for implicitly referenced files 2021-09-04T16:37:24.8301820Z -J Pass directly to the runtime system 2021-09-04T16:37:24.8303230Z --limit-modules (,)* 2021-09-04T16:37:24.8304210Z Limit the universe of observable modules 2021-09-04T16:37:24.8305570Z --module (,)*, -m (,)* 2021-09-04T16:37:24.8306630Z Compile only the specified module(s), check timestamps 2021-09-04T16:37:24.8307980Z --module-path , -p 2021-09-04T16:37:24.8309050Z Specify where to find application modules 2021-09-04T16:37:24.8310500Z --module-source-path 2021-09-04T16:37:24.8311660Z Specify where to find input source files for multiple modules 2021-09-04T16:37:24.8313050Z --module-version 2021-09-04T16:37:24.8314040Z Specify version of modules that are being compiled 2021-09-04T16:37:24.8315390Z -nowarn Generate no warnings 2021-09-04T16:37:24.8316640Z -parameters 2021-09-04T16:37:24.8317620Z Generate metadata for reflection on method parameters 2021-09-04T16:37:24.8361300Z -proc:{none,only} 2021-09-04T16:37:24.8362510Z Control whether annotation processing and/or compilation is done. 2021-09-04T16:37:24.8364150Z -processor [,,...] 2021-09-04T16:37:24.8365410Z Names of the annotation processors to run; bypasses default discovery process 2021-09-04T16:37:24.8366910Z --processor-module-path 2021-09-04T16:37:24.8367990Z Specify a module path where to find annotation processors 2021-09-04T16:37:24.8369540Z --processor-path , -processorpath 2021-09-04T16:37:24.8370620Z Specify where to find annotation processors 2021-09-04T16:37:24.8371840Z -profile 2021-09-04T16:37:24.8372800Z Check that API used is available in the specified profile 2021-09-04T16:37:24.8374080Z --release 2021-09-04T16:37:24.8375110Z Compile for the specified Java SE release. Supported releases: 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18 2021-09-04T16:37:24.8377060Z -s Specify where to place generated source files 2021-09-04T16:37:24.8378940Z --source , -source 2021-09-04T16:37:24.8380150Z Provide source compatibility with the specified Java SE release. Supported releases: 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18 2021-09-04T16:37:24.8381690Z --source-path , -sourcepath 2021-09-04T16:37:24.8382670Z Specify where to find input source files 2021-09-04T16:37:24.8383990Z --system |none Override location of system modules 2021-09-04T16:37:24.8385370Z --target , -target 2021-09-04T16:37:24.8386570Z Generate class files suitable for the specified Java SE release. Supported releases: 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18 2021-09-04T16:37:24.8388070Z --upgrade-module-path 2021-09-04T16:37:24.8389040Z Override location of upgradeable modules 2021-09-04T16:37:24.8390480Z -verbose Output messages about what the compiler is doing 2021-09-04T16:37:24.8391930Z --version, -version Version information 2021-09-04T16:37:24.8393380Z -Werror Terminate compilation if warnings occur 2021-09-04T16:37:24.8394150Z 2021-09-04T16:37:24.8395160Z Main [-X, -X] [] 2021-09-04T16:37:24.8395860Z rc:0 2021-09-04T16:37:24.8396520Z javac/DIRECT: 2021-09-04T16:37:24.8397830Z --add-exports /=(,)* 2021-09-04T16:37:24.8399140Z Specify a package to be considered as exported from its defining module 2021-09-04T16:37:24.8400780Z to additional modules, or to all unnamed modules if is ALL-UNNAMED. 2021-09-04T16:37:24.8403050Z --add-reads =(,)* 2021-09-04T16:37:24.8404200Z Specify additional modules to be considered as required by a given module. 2021-09-04T16:37:24.8405750Z may be ALL-UNNAMED to require the unnamed module. 2021-09-04T16:37:24.8407430Z --default-module-for-created-files 2021-09-04T16:37:24.8408890Z Fallback target module for files created by annotation processors, if none specified or inferred. 2021-09-04T16:37:24.8410640Z -Djava.endorsed.dirs= Override location of endorsed standards path 2021-09-04T16:37:24.8412280Z -Djava.ext.dirs= Override location of installed extensions 2021-09-04T16:37:24.8413820Z --help-lint Print the supported keys for -Xlint 2021-09-04T16:37:24.8415200Z --patch-module =(:)* 2021-09-04T16:37:24.8416210Z Override or augment a module with classes and resources 2021-09-04T16:37:24.8417110Z in JAR files or directories 2021-09-04T16:37:24.8418510Z -Xbootclasspath: Override location of bootstrap class files 2021-09-04T16:37:24.8420080Z -Xbootclasspath/a: Append to the bootstrap class path 2021-09-04T16:37:24.8421630Z -Xbootclasspath/p: Prepend to the bootstrap class path 2021-09-04T16:37:24.8423170Z -Xdiags:{compact,verbose} Select a diagnostic mode 2021-09-04T16:37:24.8424430Z -Xdoclint 2021-09-04T16:37:24.8425370Z Enable recommended checks for problems in javadoc comments 2021-09-04T16:37:24.8426730Z -Xdoclint:(all|none|[-])[/] 2021-09-04T16:37:24.8427770Z Enable or disable specific checks for problems in javadoc comments, 2021-09-04T16:37:24.8428920Z where is one of accessibility, html, missing, reference, or syntax, 2021-09-04T16:37:24.8430170Z and is one of public, protected, package, or private. 2021-09-04T16:37:24.8431760Z -Xdoclint/package:[-](,[-])* 2021-09-04T16:37:24.8432880Z Enable or disable checks in specific packages. Each is either the 2021-09-04T16:37:24.8434310Z qualified name of a package or a package name prefix followed by .*, which 2021-09-04T16:37:24.8435940Z expands to all sub-packages of the given package. Each can be prefixed 2021-09-04T16:37:24.8438060Z with - to disable checks for the specified package or packages. 2021-09-04T16:37:24.8439610Z -Xlint Enable recommended warnings 2021-09-04T16:37:24.8440840Z -Xlint:(,)* 2021-09-04T16:37:24.8441750Z Warnings to enable or disable, separated by comma. 2021-09-04T16:37:24.8443150Z Precede a key by - to disable the specified warning. 2021-09-04T16:37:24.8444570Z Use --help-lint to see the supported keys. 2021-09-04T16:37:24.8446010Z -Xmaxerrs Set the maximum number of errors to print 2021-09-04T16:37:24.8447550Z -Xmaxwarns Set the maximum number of warnings to print 2021-09-04T16:37:24.8550380Z -Xpkginfo:{always,legacy,nonempty} 2021-09-04T16:37:24.8636310Z Specify handling of package-info files 2021-09-04T16:37:24.8639600Z -Xplugin:"name args" 2021-09-04T16:37:24.8663470Z Name and optional arguments for a plug-in to be run 2021-09-04T16:37:24.8665480Z -Xprefer:{source,newer} 2021-09-04T16:37:24.8683700Z Specify which file to read when both a source file and class file are found for an implicitly compiled class 2021-09-04T16:37:24.8728280Z -Xprint 2021-09-04T16:37:24.8729520Z Print out a textual representation of specified types 2021-09-04T16:37:24.8730900Z -XprintProcessorInfo 2021-09-04T16:37:24.8731960Z Print information about which annotations a processor is asked to process 2021-09-04T16:37:24.8733270Z -XprintRounds 2021-09-04T16:37:24.8734200Z Print information about rounds of annotation processing 2021-09-04T16:37:24.8736230Z -Xstdout Redirect standard output 2021-09-04T16:37:24.8736940Z 2021-09-04T16:37:24.8737760Z These extra options are subject to change without notice. 2021-09-04T16:37:24.8739170Z Main [--help-lint, --help-lint] [] 2021-09-04T16:37:24.8739960Z rc:0 2021-09-04T16:37:24.8740890Z javac/DIRECT: 2021-09-04T16:37:24.8742040Z The supported keys for -Xlint are: 2021-09-04T16:37:24.8742920Z all Enable all warnings 2021-09-04T16:37:24.8743980Z auxiliaryclass Warn about an auxiliary class that is hidden in a source file, and is used from other files. 2021-09-04T16:37:24.8744800Z cast Warn about use of unnecessary casts. 2021-09-04T16:37:24.8745500Z classfile Warn about issues related to classfile contents. 2021-09-04T16:37:24.8746200Z deprecation Warn about use of deprecated items. 2021-09-04T16:37:24.8747550Z dep-ann Warn about items marked as deprecated in JavaDoc but not using the @Deprecated annotation. 2021-09-04T16:37:24.8748410Z divzero Warn about division by constant integer 0. 2021-09-04T16:37:24.8749030Z empty Warn about empty statement after if. 2021-09-04T16:37:24.8749680Z exports Warn about issues regarding module exports. 2021-09-04T16:37:24.8750470Z fallthrough Warn about falling through from one case of a switch statement to the next. 2021-09-04T16:37:24.8751300Z finally Warn about finally clauses that do not terminate normally. 2021-09-04T16:37:24.8752780Z missing-explicit-ctor Warn about missing explicit constructors in public and protected classes in exported packages. 2021-09-04T16:37:24.8753780Z module Warn about module system related issues. 2021-09-04T16:37:24.8754410Z opens Warn about issues regarding module opens. 2021-09-04T16:37:24.8755110Z options Warn about issues relating to use of command line options. 2021-09-04T16:37:24.8755850Z overloads Warn about issues regarding method overloads. 2021-09-04T16:37:24.8756560Z overrides Warn about issues regarding method overrides. 2021-09-04T16:37:24.8757270Z path Warn about invalid path elements on the command line. 2021-09-04T16:37:24.8758010Z processing Warn about issues regarding annotation processing. 2021-09-04T16:37:24.8759040Z rawtypes Warn about use of raw types. 2021-09-04T16:37:24.8759730Z removal Warn about use of API that has been marked for removal. 2021-09-04T16:37:24.8761030Z requires-automatic Warn about use of automatic modules in the requires clauses. 2021-09-04T16:37:24.8762640Z requires-transitive-automatic Warn about automatic modules in requires transitive. 2021-09-04T16:37:24.8763680Z serial Warn about Serializable classes that do not provide a serial version ID. 2021-09-04T16:37:24.8765050Z Also warn about access to non-public members from a serializable element. 2021-09-04T16:37:24.8765870Z static Warn about accessing a static member using an instance. 2021-09-04T16:37:24.8766610Z strictfp Warn about unnecessary use of the strictfp modifier. 2021-09-04T16:37:24.8767930Z synchronization Warn about synchronization attempts on instances of value-based classes. 2021-09-04T16:37:24.8769460Z text-blocks Warn about inconsistent white space characters in text block indentation. 2021-09-04T16:37:24.8770810Z try Warn about issues relating to use of try blocks (i.e. try-with-resources). 2021-09-04T16:37:24.8771580Z unchecked Warn about unchecked operations. 2021-09-04T16:37:24.8772250Z varargs Warn about potentially unsafe vararg methods. 2021-09-04T16:37:24.8772950Z preview Warn about use of preview language features. 2021-09-04T16:37:24.8773540Z none Disable all warnings 2021-09-04T16:37:24.8774850Z Main [-version, -version] [] 2021-09-04T16:37:24.8775370Z rc:0 2021-09-04T16:37:24.8775690Z javac/DIRECT: 2021-09-04T16:37:24.8776460Z javac 18-internal 2021-09-04T16:37:24.8777290Z Main [-fullversion, -fullversion] [] 2021-09-04T16:37:24.8777740Z rc:0 2021-09-04T16:37:24.8778060Z javac/DIRECT: 2021-09-04T16:37:24.8779450Z javac full version "18-internal+0-jaikiran-85748cf4a8efb69cbe69667851a14321804a51b6" 2021-09-04T16:37:24.8780590Z >>>>> Expected string appears more than once: 18 2021-09-04T16:37:24.8780950Z 2021-09-04T16:37:24.8781400Z java.lang.Exception: 1 errors occurred 2021-09-04T16:37:24.8782230Z at OptionModesTester.runTests(OptionModesTester.java:81) 2021-09-04T16:37:24.8783100Z at InfoOptsTest.main(InfoOptsTest.java:41) 2021-09-04T16:37:24.8784350Z at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 2021-09-04T16:37:24.8786310Z at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) 2021-09-04T16:37:24.8788620Z at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 2021-09-04T16:37:24.8791250Z at java.base/java.lang.reflect.Method.invoke(Method.java:568) 2021-09-04T16:37:24.8792700Z at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312) 2021-09-04T16:37:24.8794000Z at java.base/java.lang.Thread.run(Thread.java:833) 2021-09-04T16:37:24.8794420Z 2021-09-04T16:37:24.8794980Z JavaTest Message: Test threw exception: java.lang.Exception 2021-09-04T16:37:24.8795660Z JavaTest Message: shutting down test 2021-09-04T16:37:24.8795990Z 2021-09-04T16:37:24.8796190Z 2021-09-04T16:37:24.8797640Z TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.Exception: 1 errors occurred ------------- PR: https://git.openjdk.java.net/jdk/pull/5372 From jpai at openjdk.java.net Sun Sep 5 13:15:52 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Sun, 5 Sep 2021 13:15:52 GMT Subject: RFR: 8231640: (prop) Canonical property storage In-Reply-To: References: Message-ID: <1dCc0pQ_QGA7JCPjQoBxiVlihHkY2RU-MbJpdxG0KQU=.aef6ec66-cddb-4f13-a36e-10a2225e4f60@github.com> On Sun, 5 Sep 2021 12:56:46 GMT, Jaikiran Pai wrote: > The failure is consistently in a single test InfoOptsTest and it fails with the following error when running the testUniqueInfoOpts test case. Looks like a recent issue in some commit. I'll sort that out separately. Created https://bugs.openjdk.java.net/browse/JDK-8273361 ------------- PR: https://git.openjdk.java.net/jdk/pull/5372 From aph at openjdk.java.net Sun Sep 5 13:26:48 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Sun, 5 Sep 2021 13:26:48 GMT Subject: RFR: 8268231: Aarch64: Use ldp in intrinsics for String.compareTo [v6] In-Reply-To: References: <_XL6WybKwHeJ54kSQnN_q0_NgvR7ib9BFjNJ4HrkO_g=.f82e6cda-b31f-4eee-9185-3e52ebd6b54d@github.com> Message-ID: On Thu, 26 Aug 2021 09:26:24 GMT, Wu Yan wrote: >> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4871: >> >>> 4869: // exit from large loop when less than 64 bytes left to read or we're about >>> 4870: // to prefetch memory behind array border >>> 4871: int largeLoopExitCondition = MAX(64, SoftwarePrefetchHintDistance)/(isLL ? 1 : 2); >> >> This breaks the Windows AArch64 build: >> >> >> Creating support/modules_libs/java.base/server/jvm.dll from 1051 file(s) >> d:\a\jdk\jdk\jdk\src\hotspot\cpu\aarch64\stubGenerator_aarch64.cpp(4871): error C3861: 'MAX': identifier not found >> make[3]: *** [lib/CompileJvm.gmk:143: /cygdrive/d/a/jdk/jdk/jdk/build/windows-aarch64/hotspot/variant-server/libjvm >> >> >> https://github.com/Wanghuang-Huawei/jdk/runs/3260986937 >> >> Should probably be left as `MAX2`. > > Thanks, I'll fix it. It's fine. I don't think it'll affect any real programs, so it's rather pointless. I don't know if that's any reason not to approve it. ------------- PR: https://git.openjdk.java.net/jdk/pull/4722 From aph-open at littlepinkcloud.com Sun Sep 5 14:43:42 2021 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Sun, 5 Sep 2021 15:43:42 +0100 Subject: better random numbers In-Reply-To: <3DC84A6C-DAB3-42CB-ACF6-0CADB5BE19C1@oracle.com> References: <3DC84A6C-DAB3-42CB-ACF6-0CADB5BE19C1@oracle.com> Message-ID: <45847008-5021-7911-607c-559f8bc4545e@littlepinkcloud.com> On 9/3/21 12:35 AM, John Rose wrote: > The reference I?d like to give here is to Dr. Melissa O?Neill?s > website and articles: I'm quite sceptical. Anyone who says a (non-cryptographic) random- number generator is "hard to predict" is either quite naive or in a state of sin, (;-) and while O?Neill?s argument seems sound, it doesn't seem to have convinced the academic world. Lemire is thoughtful: https://lemire.me/blog/2017/08/15/on-melissa-oneills-pcg-random-number-generator/ I wonder about AES, which can do (on Apple M1) 2 parallel rounds per clock cycle. I'm quite tempted to try a reduced- round AES on the TestU01 statistical tests. Maybe 6 rounds? However, there can be a long latency between FPU and integer CPU, so perhaps it's not such a great idea. Also, you have to load the key registers before you can generate a random number, so it only really works if you want to generate a lot of bits at a time. But it is maybe 128 randomish bits per a few clock cycles. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From john.r.rose at oracle.com Sun Sep 5 22:23:19 2021 From: john.r.rose at oracle.com (John Rose) Date: Sun, 5 Sep 2021 22:23:19 +0000 Subject: better random numbers In-Reply-To: <45847008-5021-7911-607c-559f8bc4545e@littlepinkcloud.com> References: <3DC84A6C-DAB3-42CB-ACF6-0CADB5BE19C1@oracle.com> <45847008-5021-7911-607c-559f8bc4545e@littlepinkcloud.com> Message-ID: <38FEF279-ECE5-4C91-BEE9-5CD70EDE8EB1@oracle.com> On Sep 5, 2021, at 7:44 AM, Andrew Haley wrote: > > ?On 9/3/21 12:35 AM, John Rose wrote: > >> The reference I?d like to give here is to Dr. Melissa O?Neill?s >> website and articles: > > I'm quite sceptical. Anyone who says a (non-cryptographic) random- > number generator is "hard to predict" is either quite naive or in a > state of sin, (;-) and while O?Neill?s argument seems sound, it > doesn't seem to have convinced the academic world. She meets one of these objections on her blog. But IMO there?s not much that can be said here, since ?hard? is hard to define. It?s a practical question to be addressed (tentatively) by practical arguments. > > Lemire is thoughtful: > https://lemire.me/blog/2017/08/15/on-melissa-oneills-pcg-random-number-generator/ That?s a good link thanks. > > I wonder about AES, which can do (on Apple M1) 2 parallel rounds per > clock cycle. I'm quite tempted to try a reduced- round AES on the > TestU01 statistical tests. Maybe 6 rounds? I think I?ve mentioned using aes as a mix step at one or two JVMLS meetings. I think off label low-round use of HW accelerated crypto steps is a good use, to build sub-cryptographic but ?hard? (that word!) prngs and hashes. I expect a 128-bit multiply has a comparable amount of cascading with two aes rounds; probably the aes does a better job since it has no weak lanes. At least it looks that way on paper. So I?d start with 2 rounds and try various ways to replace a big multiply with the aes. To increase throughput use vectors or generate more than one random sample per crank turn. But back to back aes steps are probably always twice the latency of a single wide multiply. So I think there might be some more room for cleverly using single aes rounds, say two in parallel with 1-cycle input transforms. Put simply, engineers and academics approach novelty differently. The data driven ror/lsl is less valuable as an output transform since it doesn?t need to cover a structural problem with the main advance function. Xoro and pcg are drastically linear so they need a nonlinear mix function somewhere. That said, aes probably has its own odd quirks and regularities, at very low round numbers. one reason I like LCG methods is they use very well understood basic components. Which means if they have a flaw (in the low bits) it?s easier to account for and doesn?t require as much original research. So I prefer LCG over XOR networks and AES because it?s been examined more carefully. Perhaps the academic publishing world has an opposite value function: if you are using old research in a new way to solve problems they don?t care as much as if there is a new technique. After all, finding the flaws in something new will fill new journal slots and get more traffic. > However, there can be a > long latency between FPU and integer CPU, so perhaps it's not such a > great idea. That?s why I?d consider batching. > Also, you have to load the key registers before you can > generate a random number, so it only really works if you want to > generate a lot of bits at a time. Yes, that. > But it is maybe 128 randomish bits > per a few clock cycles. That?s the attraction. But you can do similar things with vectorized 64-bit operations. As long as you can clean up the weak low bits you have good mixing of state. Thanks for the comments. > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > From dholmes at openjdk.java.net Sun Sep 5 23:29:50 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Sun, 5 Sep 2021 23:29:50 GMT Subject: RFR: 8273314: Add tier4 test groups In-Reply-To: <6rDioD5KZREYHyzOXol72O0erNDqKHUqb-0k1SwhInA=.90a12492-9e2f-4f0c-bf09-8d67d1d6111f@github.com> References: <6rDioD5KZREYHyzOXol72O0erNDqKHUqb-0k1SwhInA=.90a12492-9e2f-4f0c-bf09-8d67d1d6111f@github.com> Message-ID: On Fri, 3 Sep 2021 09:10:20 GMT, Aleksey Shipilev wrote: > During the review of JDK-8272914 that added hotspot:tier{2,3} groups, @iignatev suggested to create tier4 groups that capture all tests not in tiers{1,2,3}. I have excluded `vmTestbase` and `hotspot:tier4,` because they take 10+ hours on my highly parallel machine. I have also excluded `applications` from `hotspot:tier4`, because they require test dependencies (e.g. jcstress). > > Sample run: > > > ============================== > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR >>> jtreg:test/hotspot/jtreg:tier4 426 425 1 0 << >>> jtreg:test/jdk:tier4 2891 2885 4 2 << > jtreg:test/langtools:tier4 0 0 0 0 > jtreg:test/jaxp:tier4 0 0 0 0 > ============================== > > real 64m13.994s > user 1462m1.213s > sys 39m38.032s > > > There are interesting test failures on my machine, which I would address separately. Hi Aleksey, This seems rather arbitrary and subjective to me. The tier 1-3 groupings were driven by existing tier 1-3 notions. But here the definition of tier 4 as "all the rest except ..." is not really a well-defined meaning for tier 4. I don't see that it adds any value. Perhaps there is a need for a group that is "everything except tier 1, tier 2, tier 3, applications, ..." but I wouldn't call that tier 4. Cheers, David ------------- PR: https://git.openjdk.java.net/jdk/pull/5357 From github.com+44376158+q2q-2q2 at openjdk.java.net Mon Sep 6 06:45:07 2021 From: github.com+44376158+q2q-2q2 at openjdk.java.net (q2q-2q2) Date: Mon, 6 Sep 2021 06:45:07 GMT Subject: RFR: JDK-8272192 Shortcut String equality checks by checking equality of the value array [v2] In-Reply-To: References: Message-ID: > Shortcut String equality checks by checking equality of the value array q2q-2q2 has updated the pull request incrementally with one additional commit since the last revision: JDK-8272192 Shortcut String equality checks by checking equality of the value array ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5370/files - new: https://git.openjdk.java.net/jdk/pull/5370/files/99d1e0f2..4fe9f85e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5370&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5370&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5370.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5370/head:pull/5370 PR: https://git.openjdk.java.net/jdk/pull/5370 From turbanoff at gmail.com Mon Sep 6 07:16:22 2021 From: turbanoff at gmail.com (Andrey Turbanov) Date: Mon, 6 Sep 2021 10:16:22 +0300 Subject: Suspicious duplicate condition in java.util.regex.Grapheme#isExcludedSpacingMark Message-ID: Hello. I found suspicious condition in the method java.util.regex.Grapheme#isExcludedSpacingMark It's detected by IntelliJ IDEA inspection 'Condition is covered by further condition' https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/regex/Grapheme.java#L157 ``` private static boolean isExcludedSpacingMark(int cp) { return cp == 0x102B || cp == 0x102C || cp == 0x1038 || cp >= 0x1062 && cp <= 0x1064 || cp >= 0x1062 && cp <= 0x106D || // <== here is the warning cp == 0x1083 || cp >= 0x1087 && cp <= 0x108C || cp == 0x108F || cp >= 0x109A && cp <= 0x109C || cp == 0x1A61 || cp == 0x1A63 || cp == 0x1A64 || cp == 0xAA7B || cp == 0xAA7D; } ``` There are 2 sub-conditions in this complex condition: cp >= 0x1062 && cp <= 0x1064 || cp >= 0x1062 && cp <= 0x106D || The second condition is _wider_ than the first one. I believe it's a bug. The second condition (according to https://www.compart.com/en/unicode/category/Mc) should look like this: cp >= 0x1067 && cp <= 0x106D || 0x1065, 0x1066 are not from the Spacing_Mark category. Andrey Turbanov From lzang at openjdk.java.net Mon Sep 6 07:20:11 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Mon, 6 Sep 2021 07:20:11 GMT Subject: RFR: 4890732: GZIPOutputStream doesn't support optional GZIP fields [v12] In-Reply-To: References: Message-ID: > 4890732: GZIPOutputStream doesn't support optional GZIP fields Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: - Merge branch 'master' into gzip-field - delete trailing spaces - refine code - Merge branch 'master' into gzip-field - change since version to 18 - Merge branch 'master' into gzip-field - Merge branch 'master' into gzip-field - Add api in GZIPInputStream to get header data - Merge remote-tracking branch 'upstream/master' into gzip-field - remove trailing spaces - ... and 7 more: https://git.openjdk.java.net/jdk/compare/c640fe42...196caedb ------------- Changes: https://git.openjdk.java.net/jdk/pull/3072/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3072&range=11 Stats: 618 lines in 4 files changed: 568 ins; 26 del; 24 mod Patch: https://git.openjdk.java.net/jdk/pull/3072.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3072/head:pull/3072 PR: https://git.openjdk.java.net/jdk/pull/3072 From alanb at openjdk.java.net Mon Sep 6 09:42:47 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 6 Sep 2021 09:42:47 GMT Subject: RFR: 8273101: Eliminate the usage of threadgroup sandboxing in the java.util.logging In-Reply-To: References: Message-ID: On Wed, 1 Sep 2021 06:31:16 GMT, Sergey Bylokhov wrote: > The "java.util.logging.LogManager" class uses the "threadgroup sandboxing" via an AppContext to support "applet logging isolation". The AppContext class became useless since the plugin and webstart are no longer supported and removed in jdk11. > > This is the request to delete the usage of AppContext in the LogManager and related tests. > > Tested by tier1/tier2/tier3 and jdk_desktop tests. No objection to removing this legacy/unused code but I think it would be useful to useful to have the JBS issue or the PR summary provide a bit more context. As I see it, this is just one piece of the overall cleanup and I assume there are more substantive changes to the java.desktop module coming, is that right? ------------- PR: https://git.openjdk.java.net/jdk/pull/5326 From dfuchs at openjdk.java.net Mon Sep 6 09:45:54 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Mon, 6 Sep 2021 09:45:54 GMT Subject: RFR: 8255878: FilterInputStream is missing implementations of Java 9 InputStream methods [v2] In-Reply-To: References: <73JP6cAapkJpM3afNxR0U1m5I3RxshdsRx5oSJgqEJg=.e9f8fc5d-5992-4ead-bfa6-bbfff3728b59@github.com> <-XW3tJUbBEPFVXK6CuI6UVU_Flg8V70_9gCjwiFedxI=.2b2061b8-738b-48f6-a931-db3ca3e8ffc2@github.com> Message-ID: On Sat, 4 Sep 2021 07:02:32 GMT, Alan Bateman wrote: > Can you explain this a bit further? InputStream has one abstract method so that's the minimum that has to be implemented. It has base implementations of readAllBytes and readNBytes that would be very inefficient if the 3-arg read is not overridden but I wouldn't expect a correctness issue. readAllBytes/readNBytes no longer call any variant of `this.read` - so any subclass that implement the two `read` methods to do something more than what `in.read` does might fail in unexpected ways if `readAllBytes` or `readNBytes` are called. I'm especially concerned with subclasses like e.g. `KeepAliveStream` / `MetteredStream` in `sun.net.www.http` ------------- PR: https://git.openjdk.java.net/jdk/pull/5367 From alanb at openjdk.java.net Mon Sep 6 12:05:40 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 6 Sep 2021 12:05:40 GMT Subject: RFR: 8255878: FilterInputStream is missing implementations of Java 9 InputStream methods [v2] In-Reply-To: References: <73JP6cAapkJpM3afNxR0U1m5I3RxshdsRx5oSJgqEJg=.e9f8fc5d-5992-4ead-bfa6-bbfff3728b59@github.com> <-XW3tJUbBEPFVXK6CuI6UVU_Flg8V70_9gCjwiFedxI=.2b2061b8-738b-48f6-a931-db3ca3e8ffc2@github.com> Message-ID: <6Z18cONi4i747kWV96he1UsJQUy88DRC6X9MgTzG1ns=.c07cda5d-9646-4993-aeae-aab093224917@github.com> On Mon, 6 Sep 2021 09:41:54 GMT, Daniel Fuchs wrote: > readAllBytes/readNBytes no longer call any variant of `this.read` - so any subclass that implement the two `read` methods to do something more than what `in.read` does might fail in unexpected ways if `readAllBytes` or `readNBytes` are called. I'm especially concerned with subclasses like e.g. `KeepAliveStream` / `MetteredStream` in `sun.net.www.http` Ah yes, I think you are right. In that case JDK-8255878 can be closed as WNF or else FilterInputStream provides implementations of these methods that don't directly delegate. ------------- PR: https://git.openjdk.java.net/jdk/pull/5367 From shade at openjdk.java.net Mon Sep 6 13:18:06 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 6 Sep 2021 13:18:06 GMT Subject: RFR: 8273314: Add tier4 test groups [v2] In-Reply-To: <6rDioD5KZREYHyzOXol72O0erNDqKHUqb-0k1SwhInA=.90a12492-9e2f-4f0c-bf09-8d67d1d6111f@github.com> References: <6rDioD5KZREYHyzOXol72O0erNDqKHUqb-0k1SwhInA=.90a12492-9e2f-4f0c-bf09-8d67d1d6111f@github.com> Message-ID: > During the review of JDK-8272914 that added hotspot:tier{2,3} groups, @iignatev suggested to create tier4 groups that capture all tests not in tiers{1,2,3}. I have excluded `vmTestbase` and `hotspot:tier4,` because they take 10+ hours on my highly parallel machine. I have also excluded `applications` from `hotspot:tier4`, because they require test dependencies (e.g. jcstress). > > Sample run: > > > ============================== > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR >>> jtreg:test/hotspot/jtreg:tier4 426 425 1 0 << >>> jtreg:test/jdk:tier4 2891 2885 4 2 << > jtreg:test/langtools:tier4 0 0 0 0 > jtreg:test/jaxp:tier4 0 0 0 0 > ============================== > > real 64m13.994s > user 1462m1.213s > sys 39m38.032s > > > There are interesting test failures on my machine, which I would address separately. Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Drop exceptions ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5357/files - new: https://git.openjdk.java.net/jdk/pull/5357/files/a0753adf..afb77062 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5357&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5357&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5357.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5357/head:pull/5357 PR: https://git.openjdk.java.net/jdk/pull/5357 From shade at openjdk.java.net Mon Sep 6 13:22:03 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 6 Sep 2021 13:22:03 GMT Subject: RFR: 8273314: Add tier4 test groups [v3] In-Reply-To: <6rDioD5KZREYHyzOXol72O0erNDqKHUqb-0k1SwhInA=.90a12492-9e2f-4f0c-bf09-8d67d1d6111f@github.com> References: <6rDioD5KZREYHyzOXol72O0erNDqKHUqb-0k1SwhInA=.90a12492-9e2f-4f0c-bf09-8d67d1d6111f@github.com> Message-ID: > During the review of JDK-8272914 that added hotspot:tier{2,3} groups, @iignatev suggested to create tier4 groups that capture all tests not in tiers{1,2,3}. I have excluded `vmTestbase` and `hotspot:tier4,` because they take 10+ hours on my highly parallel machine. I have also excluded `applications` from `hotspot:tier4`, because they require test dependencies (e.g. jcstress). > > Sample run: > > > ============================== > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR >>> jtreg:test/hotspot/jtreg:tier4 426 425 1 0 << >>> jtreg:test/jdk:tier4 2891 2885 4 2 << > jtreg:test/langtools:tier4 0 0 0 0 > jtreg:test/jaxp:tier4 0 0 0 0 > ============================== > > real 64m13.994s > user 1462m1.213s > sys 39m38.032s > > > There are interesting test failures on my machine, which I would address separately. Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Drop applications and fix the comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5357/files - new: https://git.openjdk.java.net/jdk/pull/5357/files/afb77062..160c13c7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5357&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5357&range=01-02 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5357.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5357/head:pull/5357 PR: https://git.openjdk.java.net/jdk/pull/5357 From shade at openjdk.java.net Mon Sep 6 15:17:43 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 6 Sep 2021 15:17:43 GMT Subject: RFR: 8273314: Add tier4 test groups In-Reply-To: References: <6rDioD5KZREYHyzOXol72O0erNDqKHUqb-0k1SwhInA=.90a12492-9e2f-4f0c-bf09-8d67d1d6111f@github.com> Message-ID: On Sat, 4 Sep 2021 03:13:58 GMT, Igor Ignatyev wrote: >>> > <...> I have excluded `vmTestbase` and `hotspot:tier4`<...> I have also excluded `applications` from `hotspot:tier4` <...> >>> >>> assuming the goal of tier4 is to catch the rest of the tests, I don't think we should exclude `vmTestbase`, `applications` or any other tests from tier4. unless you also want to create tier5 for them. >> >> Apart from practicality of using `tier4`, I think `vmTestbase` and `applications` are separate test suites in their own right. `tier4` is catching all the assorted Hotspot tests that are not part of larger suites. Makes sense? > >> > > <...> I have excluded `vmTestbase` and `hotspot:tier4`<...> I have also excluded `applications` from `hotspot:tier4` <...> >> > >> > >> > assuming the goal of tier4 is to catch the rest of the tests, I don't think we should exclude `vmTestbase`, `applications` or any other tests from tier4. unless you also want to create tier5 for them. >> >> Apart from practicality of using `tier4`, I think `vmTestbase` and `applications` are separate test suites in their own right. `tier4` is catching all the assorted Hotspot tests that are not part of larger suites. Makes sense? > > to some extent. I agree that `applications` tests can/should be seen as a separate test suite, yet I differ on `vmTestbase` as the end goal for `vmTestbase` tests is (and always was) to become just another test within hotspot jtreg test suite, hence I don't think we should treat them any different than other jtreg tests. there is also a plan (which I need to formalize and share w/ a broader audience) to rearrange `vmTestbase` tests so they will be placed within the corresponding component subdirectories, which would bring us closer to the end goal and at the same time make it slightly harder to select all `vmTestbase` tests. > > -- Igor @iignatev: OK, I reinstated `vmTestbase` and left `applications` out of `hotspot:tier4`. @dholmes-ora: Generally speaking, all `tierX` definitions are rather arbitrary, as there seem to be nothing intrinsic about the tests to be in a particular tier. In other words, what `tierX` consists of is a matter of agreement. I'd say `hotspot:tier4` is "all assorted Hotspot tests that are not application-specific suites" @mrserb: Yes, I ran this on a headless config, so headful tests were skipped, apparently. I'll try to arrange runs on my desktop. Please see new commit. As `hotspot:tier4` is now much longer, it would take me a while to verify everything works there. ------------- PR: https://git.openjdk.java.net/jdk/pull/5357 From serb at openjdk.java.net Mon Sep 6 20:39:43 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 6 Sep 2021 20:39:43 GMT Subject: RFR: 8273101: Eliminate the usage of threadgroup sandboxing in the java.util.logging In-Reply-To: References: Message-ID: On Mon, 6 Sep 2021 09:39:58 GMT, Alan Bateman wrote: > As I see it, this is just one piece of the overall cleanup and I assume there are more substantive changes to the java.desktop module coming, is that right? Yes, you are right. ------------- PR: https://git.openjdk.java.net/jdk/pull/5326 From serb at openjdk.java.net Mon Sep 6 20:43:36 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 6 Sep 2021 20:43:36 GMT Subject: RFR: 8273314: Add tier4 test groups In-Reply-To: <4ZMjEBOeBv6RVtgEhcfQ1sMVUyL8t2v4W4sc3iGY3r0=.d88a0dbc-d8d0-497b-bde7-9d5de283d11f@github.com> References: <6rDioD5KZREYHyzOXol72O0erNDqKHUqb-0k1SwhInA=.90a12492-9e2f-4f0c-bf09-8d67d1d6111f@github.com> <4ZMjEBOeBv6RVtgEhcfQ1sMVUyL8t2v4W4sc3iGY3r0=.d88a0dbc-d8d0-497b-bde7-9d5de283d11f@github.com> Message-ID: On Sat, 4 Sep 2021 02:51:50 GMT, Sergey Bylokhov wrote: >> During the review of JDK-8272914 that added hotspot:tier{2,3} groups, @iignatev suggested to create tier4 groups that capture all tests not in tiers{1,2,3}. I have excluded `vmTestbase` and `hotspot:tier4,` because they take 10+ hours on my highly parallel machine. I have also excluded `applications` from `hotspot:tier4`, because they require test dependencies (e.g. jcstress). >> >> Sample run: >> >> >> ============================== >> Test summary >> ============================== >> TEST TOTAL PASS FAIL ERROR >>>> jtreg:test/hotspot/jtreg:tier4 426 425 1 0 << >>>> jtreg:test/jdk:tier4 2891 2885 4 2 << >> jtreg:test/langtools:tier4 0 0 0 0 >> jtreg:test/jaxp:tier4 0 0 0 0 >> ============================== >> >> real 64m13.994s >> user 1462m1.213s >> sys 39m38.032s >> >> >> There are interesting test failures on my machine, which I would address separately. > > it looks like the results above do not include the headful tests did you filter them out? >>> jtreg:test/jdk:tier4 2891 2885 4 2 << > @mrserb: Yes, I ran this on a headless config, so headful tests were skipped, apparently. I'll try to arrange runs on my desktop. Then you probably need to skip "printer" tests as well. BTW it will be really good somehow to execute headless tests in tier4 concurrently, and run the headful tests in tier5 sequentially. ------------- PR: https://git.openjdk.java.net/jdk/pull/5357 From john.r.rose at oracle.com Mon Sep 6 21:22:51 2021 From: john.r.rose at oracle.com (John Rose) Date: Mon, 6 Sep 2021 21:22:51 +0000 Subject: better random numbers In-Reply-To: <38FEF279-ECE5-4C91-BEE9-5CD70EDE8EB1@oracle.com> References: <3DC84A6C-DAB3-42CB-ACF6-0CADB5BE19C1@oracle.com> <45847008-5021-7911-607c-559f8bc4545e@littlepinkcloud.com> <38FEF279-ECE5-4C91-BEE9-5CD70EDE8EB1@oracle.com> Message-ID: On Sep 5, 2021, at 3:23 PM, John Rose > wrote: To increase throughput use vectors or generate more than one random sample per crank turn. But back to back aes steps are probably always twice the latency of a single wide multiply. So I think there might be some more room for cleverly using single aes rounds, say two in parallel with 1-cycle input transforms. Put simply, engineers and academics approach novelty differently. (Yikes! I typed the mail on my phone and somehow that last sentence went to the wrong place. It should have been at the end of the PP that speculated about differing motivations surrounding publication and engineering.) From dholmes at openjdk.java.net Mon Sep 6 22:48:40 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 6 Sep 2021 22:48:40 GMT Subject: RFR: JDK-8272192 Shortcut String equality checks by checking equality of the value array [v2] In-Reply-To: <5jETSubSWp7ZGp-1O_lbPh3J3buv95Le-OB1-A8eA4g=.d58f93fc-92f7-4a46-b2f7-fcf79711253a@github.com> References: <5jETSubSWp7ZGp-1O_lbPh3J3buv95Le-OB1-A8eA4g=.d58f93fc-92f7-4a46-b2f7-fcf79711253a@github.com> Message-ID: On Mon, 6 Sep 2021 06:41:38 GMT, q2q-2q2 wrote: >> src/java.base/share/classes/java/lang/String.java line 1964: >> >>> 1962: public boolean equalsIgnoreCase(String anotherString) { >>> 1963: if (anotherString != null) { >>> 1964: return false; >> >> This one is definitely wrong. > > Thank you So that begs the question as to what testing you did for this change? ------------- PR: https://git.openjdk.java.net/jdk/pull/5370 From dholmes at openjdk.java.net Mon Sep 6 22:59:40 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 6 Sep 2021 22:59:40 GMT Subject: RFR: JDK-8272192 Shortcut String equality checks by checking equality of the value array [v2] In-Reply-To: References: Message-ID: On Mon, 6 Sep 2021 06:45:07 GMT, q2q-2q2 wrote: >> Shortcut String equality checks by checking equality of the value array > > q2q-2q2 has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8272192 Shortcut String equality checks by checking equality of the value array It isn't obvious to me that this is necessarily correct - do we only ever share the full array? IIRC at one time substrings also shared the same array but with different a starting index and length. If this is correct then it needs some supporting performance data, but as these methods are also VM intrinsics I doubt you will see much difference as only interpreted code will be affected by your change. But I'll leave it to the performance experts to comment - paging @cl4es :) Oh and as the JBS issue is filed against hotspot as the moment that needs to be cleaned up to, if this is just a Java fix. Cheers, David ------------- PR: https://git.openjdk.java.net/jdk/pull/5370 From david.holmes at oracle.com Mon Sep 6 23:04:24 2021 From: david.holmes at oracle.com (David Holmes) Date: Tue, 7 Sep 2021 09:04:24 +1000 Subject: RFR: 8273314: Add tier4 test groups In-Reply-To: References: <6rDioD5KZREYHyzOXol72O0erNDqKHUqb-0k1SwhInA=.90a12492-9e2f-4f0c-bf09-8d67d1d6111f@github.com> Message-ID: <25b0cf03-689a-93d8-6fca-35a465a8e631@oracle.com> On 7/09/2021 1:17 am, Aleksey Shipilev wrote: > @dholmes-ora: Generally speaking, all `tierX` definitions are rather arbitrary, as there seem to be nothing intrinsic about the tests to be in a particular tier. In other words, what `tierX` consists of is a matter of agreement. I'd say `hotspot:tier4` is "all assorted Hotspot tests that are not application-specific suites" The difference is that your previous work just consolidated the existing subsystem tier 1-3 definitions, but here you are choosing to define "all the rest" as tier 4. I don't think it is actually helpful/useful to anyone - and it bears no resemblance whatsoever to what we call "tier 4", so that will just lead to unnecessary confusion IMO. David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/5357 > From redestad at openjdk.java.net Tue Sep 7 00:07:40 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 7 Sep 2021 00:07:40 GMT Subject: RFR: JDK-8272192 Shortcut String equality checks by checking equality of the value array [v2] In-Reply-To: References: Message-ID: On Mon, 6 Sep 2021 06:45:07 GMT, q2q-2q2 wrote: >> Shortcut String equality checks by checking equality of the value array > > q2q-2q2 has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8272192 Shortcut String equality checks by checking equality of the value array David is right that many of these methods have VM intrinsics that'd have to be fixed to see much benefit of this. I can imagine some of these to be profitable in edge cases with string de-duplication enabled. Otherwise the backing arrays will typically never be shared and the identity test always be false (`""` is an exception to that rule that interestingly is unlikely to see any win from short-cutting). While the gain from a correct shortcut could be really large on a synthetic micro-benchmark, I still suspect the added test might be more costly in aggregate on the fabled "real application". With compact strings it's easy to construct strings with different coders but the same `byte[]`, and string de-duplication could be implemented so that you end up sharing the same array between two semantically different strings (I suspect this is the case, but I might be wrong). This means there's a possible correctness issue in some places where you're shortcutting before checking either length or coder. All things considered I don't think this is worthwhile. src/java.base/share/classes/java/lang/String.java line 1859: > 1857: byte v1[] = value; > 1858: byte v2[] = sb.getValue(); > 1859: if (v1 == v2) { This one is a bit tricky since it's only correct since we've asserted that `len == sb.length()`. It's unlikely to consistently give much of a boost, though, since `sb.getValue()` is very likely to have some unused padding at the end. ------------- PR: https://git.openjdk.java.net/jdk/pull/5370 From ngasson at openjdk.java.net Tue Sep 7 01:40:41 2021 From: ngasson at openjdk.java.net (Nick Gasson) Date: Tue, 7 Sep 2021 01:40:41 GMT Subject: RFR: 8268231: Aarch64: Use ldp in intrinsics for String.compareTo [v7] In-Reply-To: References: Message-ID: On Mon, 30 Aug 2021 06:26:01 GMT, Wang Huang wrote: >> Dear all, >> Can you do me a favor to review this patch. This patch use `ldp` to implement String.compareTo. >> >> * We add a JMH test case >> * Here is the result of this test case >> >> Benchmark |(size)| Mode| Cnt|Score | Error |Units >> ---------------------------------|------|-----|----|------|--------|----- >> StringCompare.compareLL | 64 | avgt| 5 |7.992 | ? 0.005|us/op >> StringCompare.compareLL | 72 | avgt| 5 |15.029| ? 0.006|us/op >> StringCompare.compareLL | 80 | avgt| 5 |14.655| ? 0.011|us/op >> StringCompare.compareLL | 91 | avgt| 5 |16.363| ? 0.12 |us/op >> StringCompare.compareLL | 101 | avgt| 5 |16.966| ? 0.007|us/op >> StringCompare.compareLL | 121 | avgt| 5 |19.276| ? 0.006|us/op >> StringCompare.compareLL | 181 | avgt| 5 |19.002| ? 0.417|us/op >> StringCompare.compareLL | 256 | avgt| 5 |24.707| ? 0.041|us/op >> StringCompare.compareLLWithLdp| 64 | avgt| 5 |8.001 | ? 0.121|us/op >> StringCompare.compareLLWithLdp| 72 | avgt| 5 |11.573| ? 0.003|us/op >> StringCompare.compareLLWithLdp| 80 | avgt| 5 |6.861 | ? 0.004|us/op >> StringCompare.compareLLWithLdp| 91 | avgt| 5 |12.774| ? 0.201|us/op >> StringCompare.compareLLWithLdp| 101 | avgt| 5 |8.691 | ? 0.004|us/op >> StringCompare.compareLLWithLdp| 121 | avgt| 5 |11.091| ? 1.342|us/op >> StringCompare.compareLLWithLdp| 181 | avgt| 5 |14.64 | ? 0.581|us/op >> StringCompare.compareLLWithLdp| 256 | avgt| 5 |25.879| ? 1.775|us/op >> StringCompare.compareUU | 64 | avgt| 5 |13.476| ? 0.01 |us/op >> StringCompare.compareUU | 72 | avgt| 5 |15.078| ? 0.006|us/op >> StringCompare.compareUU | 80 | avgt| 5 |23.512| ? 0.011|us/op >> StringCompare.compareUU | 91 | avgt| 5 |24.284| ? 0.008|us/op >> StringCompare.compareUU | 101 | avgt| 5 |20.707| ? 0.017|us/op >> StringCompare.compareUU | 121 | avgt| 5 |29.302| ? 0.011|us/op >> StringCompare.compareUU | 181 | avgt| 5 |39.31 | ? 0.016|us/op >> StringCompare.compareUU | 256 | avgt| 5 |54.592| ? 0.392|us/op >> StringCompare.compareUUWithLdp| 64 | avgt| 5 |16.389| ? 0.008|us/op >> StringCompare.compareUUWithLdp| 72 | avgt| 5 |10.71 | ? 0.158|us/op >> StringCompare.compareUUWithLdp| 80 | avgt| 5 |11.488| ? 0.024|us/op >> StringCompare.compareUUWithLdp| 91 | avgt| 5 |13.412| ? 0.006|us/op >> StringCompare.compareUUWithLdp| 101 | avgt| 5 |16.245| ? 0.434|us/op >> StringCompare.compareUUWithLdp| 121 | avgt| 5 |16.597| ? 0.016|us/op >> StringCompare.compareUUWithLdp| 181 | avgt| 5 |27.373| ? 0.017|us/op >> StringCompare.compareUUWithLdp| 256 | avgt| 5 |41.74 | ? 3.5 |us/op >> >> From this table, we can see that in most cases, our patch is better than old one. >> >> Thank you for your review. Any suggestions are welcome. > > Wang Huang has updated the pull request incrementally with one additional commit since the last revision: > > fix windows build failed Please check the Windows tier1 failure: https://github.com/Wanghuang-Huawei/jdk/runs/3459332995 Seems unlikely that it's anything to do with this patch so you may just want to re-run it or merge from master. ------------- PR: https://git.openjdk.java.net/jdk/pull/4722 From github.com+53162078+shiyuexw at openjdk.java.net Tue Sep 7 03:39:36 2021 From: github.com+53162078+shiyuexw at openjdk.java.net (wxiang) Date: Tue, 7 Sep 2021 03:39:36 GMT Subject: RFR: 6957241: ClassLoader.getResources() returns only 1 instance when using jar indexing In-Reply-To: References: Message-ID: On Tue, 31 Aug 2021 12:11:46 GMT, wxiang wrote: > Using jarIndex for Hibench, there is an unexpected behavior with the exception "Exception in thread "main" org.apache.hadoop.fs.UnsupportedFileSystemException: No FileSystem for scheme "hdfs"". > > After investigating it, it is related to the usage of ServiceLoader with JarIndex. > The below stack shows the issue with JDK11: > > getResource:1016, URLClassPath$JarLoader (jdk.internal.loader) > getResource:937, URLClassPath$JarLoader (jdk.internal.loader) > findResource:912, URLClassPath$JarLoader (jdk.internal.loader) > next:341, URLClassPath$1 (jdk.internal.loader) > hasMoreElements:351, URLClassPath$1 (jdk.internal.loader) > hasNext:355, BuiltinClassLoader$1 (jdk.internal.loader) > hasMoreElements:363, BuiltinClassLoader$1 (jdk.internal.loader) > next:3032, CompoundEnumeration (java.lang) > hasMoreElements:3041, CompoundEnumeration (java.lang) > nextProviderClass:1203, ServiceLoader$LazyClassPathLookupIterator (java.util) > hasNextService:1221, ServiceLoader$LazyClassPathLookupIterator (java.util) > hasNext:1265, ServiceLoader$LazyClassPathLookupIterator (java.util) > hasNext:1300, ServiceLoader$2 (java.util) > hasNext:1385, ServiceLoader$3 (java.util) > > The below API tries to get all the resources with the same name. > > public Enumeration findResources(final String name, > final boolean check) > ``` > After using JarIndex, URLClassPath.findResources only returns 1 URL. > It is the same as the description in JDK-6957241. > > The issue still exists in JDK18. > > Root cause: > > public Enumeration findResources(final String name, > final boolean check) { > return new Enumeration<>() { > private int index = 0; > private URL url = null; > > private boolean next() { > if (url != null) { > return true; > } else { > Loader loader; > while ((loader = getLoader(index++)) != null) { > url = loader.findResource(name, check); > if (url != null) { > return true; > } > } > return false; > } > } > ... > }; > } > > With the JarIndex, there is only one loader which is corresponding to the jar with the index due to the implementation in JarLoader.getResource(final String name, boolean check, Set visited). > > Loaders corresponding to other jar packages will not appear in this while. > So it only returns 1 instance. > > To solve the issue, I change the implementation "private boolean next()". > If the loader has index, traverse the index and get all the resource from the loader. I created a new JBS https://bugs.openjdk.java.net/browse/JDK-8273401, and PR: https://github.com/openjdk/jdk/pull/5383. The PR is to remove the JarIndex support in URLClassPath and move JarIndex into the jdk.jartool module. ------------- PR: https://git.openjdk.java.net/jdk/pull/5316 From github.com+53162078+shiyuexw at openjdk.java.net Tue Sep 7 03:42:59 2021 From: github.com+53162078+shiyuexw at openjdk.java.net (wxiang) Date: Tue, 7 Sep 2021 03:42:59 GMT Subject: RFR: 8273401: Remove JarIndex support in URLClassPath Message-ID: There is a bug for URLClassPath.findResources with JarIndex. With some discussions about the bug, the current priority is to remove the JAR index support in URLClassPath, and don?t need to do anything to the jar tool in the short term, except just to move JarIndex to the jdk.jartool module. The PR includes: 1. remove the JarIndex support in URLClassPath 2. move JarIndex into jdk.jartool module. ------------- Commit messages: - 8273401: Remove JarIndex support in URLClassPath Changes: https://git.openjdk.java.net/jdk/pull/5383/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5383&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273401 Stats: 1117 lines in 21 files changed: 7 ins; 1098 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/5383.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5383/head:pull/5383 PR: https://git.openjdk.java.net/jdk/pull/5383 From github.com+44313413+jovanstevanovic at openjdk.java.net Tue Sep 7 04:17:49 2021 From: github.com+44313413+jovanstevanovic at openjdk.java.net (Jovan Stevanovic) Date: Tue, 7 Sep 2021 04:17:49 GMT Subject: RFR: 8273278: Support XSLT on GraalVM Native Image--deterministic bytecode generation in XSLT Message-ID: GraalVM Native Image supports loading classes at runtime if they are known during image build (class predefinition). This is achieved by the JVMTI agent that registers dynamically generated classes in a regular HotSpot run. The Native Image build uses these registered classes to embed them into the produced binary so they can be loaded at runtime. Loading at runtime is achieved by matching the unique hash of generated classes. If the generated bytecode is unstable across runs, the generated native image can not match the hash of the runtime-generated bytecode to the pre-defined classes. The execution failure happens here: https://github.com/oracle/graal/blob/master/substratevm/src/com.oracle.svm.core/src/com/oracle/svm/core/hub/PredefinedClassesSupport.java#L127-L131. In XSLT the produced bytecode is unstable for the following reasons: - Methods like ` HashMap#values` and `HashMap#keySet` result in different traversal orders of its elements yielding a different order of methods and fields. - The default `Object#toString` includes the current memory reference of `com.sun.org.apache.xalan.internal.xsltc.compiler.Number` in the generated class. ------------- Commit messages: - 8273278: Improving XSLT support for GraalVM's Native Image. Changes: https://git.openjdk.java.net/jdk/pull/5331/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5331&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273278 Stats: 15 lines in 4 files changed: 5 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/5331.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5331/head:pull/5331 PR: https://git.openjdk.java.net/jdk/pull/5331 From github.com+44313413+jovanstevanovic at openjdk.java.net Tue Sep 7 04:17:49 2021 From: github.com+44313413+jovanstevanovic at openjdk.java.net (Jovan Stevanovic) Date: Tue, 7 Sep 2021 04:17:49 GMT Subject: RFR: 8273278: Support XSLT on GraalVM Native Image--deterministic bytecode generation in XSLT In-Reply-To: References: Message-ID: On Wed, 1 Sep 2021 13:28:34 GMT, Jovan Stevanovic wrote: > GraalVM Native Image supports loading classes at runtime if they are known during image build (class predefinition). This is achieved by the JVMTI agent that registers dynamically generated classes in a regular HotSpot run. The Native Image build uses these registered classes to embed them into the produced binary so they can be loaded at runtime. Loading at runtime is achieved by matching the unique hash of generated classes. > > If the generated bytecode is unstable across runs, the generated native image can not match the hash of the runtime-generated bytecode to the pre-defined classes. The execution failure happens here: > https://github.com/oracle/graal/blob/master/substratevm/src/com.oracle.svm.core/src/com/oracle/svm/core/hub/PredefinedClassesSupport.java#L127-L131. > > In XSLT the produced bytecode is unstable for the following reasons: > > - Methods like ` HashMap#values` and `HashMap#keySet` result in different traversal orders of its elements yielding a different order of methods and fields. > > - The default `Object#toString` includes the current memory reference of `com.sun.org.apache.xalan.internal.xsltc.compiler.Number` in the generated class. `/signed` ------------- PR: https://git.openjdk.java.net/jdk/pull/5331 From iignatyev at openjdk.java.net Tue Sep 7 04:20:38 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Tue, 7 Sep 2021 04:20:38 GMT Subject: RFR: 8273314: Add tier4 test groups [v3] In-Reply-To: References: <6rDioD5KZREYHyzOXol72O0erNDqKHUqb-0k1SwhInA=.90a12492-9e2f-4f0c-bf09-8d67d1d6111f@github.com> Message-ID: On Mon, 6 Sep 2021 13:22:03 GMT, Aleksey Shipilev wrote: >> During the review of JDK-8272914 that added hotspot:tier{2,3} groups, @iignatev suggested to create tier4 groups that capture all tests not in tiers{1,2,3}. I have excluded `vmTestbase` and `hotspot:tier4,` because they take 10+ hours on my highly parallel machine. I have also excluded `applications` from `hotspot:tier4`, because they require test dependencies (e.g. jcstress). >> >> Sample run: >> >> >> ============================== >> Test summary >> ============================== >> TEST TOTAL PASS FAIL ERROR >>>> jtreg:test/hotspot/jtreg:tier4 426 425 1 0 << >>>> jtreg:test/jdk:tier4 2891 2885 4 2 << >> jtreg:test/langtools:tier4 0 0 0 0 >> jtreg:test/jaxp:tier4 0 0 0 0 >> ============================== >> >> real 64m13.994s >> user 1462m1.213s >> sys 39m38.032s >> >> >> There are interesting test failures on my machine, which I would address separately. > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Drop applications and fix the comment > _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [hotspot-dev](mailto:hotspot-dev at mail.openjdk.java.net):_ > > On 7/09/2021 1:17 am, Aleksey Shipilev wrote: > > > @dholmes-ora: Generally speaking, all `tierX` definitions are rather arbitrary, as there seem to be nothing intrinsic about the tests to be in a particular tier. In other words, what `tierX` consists of is a matter of agreement. I'd say `hotspot:tier4` is "all assorted Hotspot tests that are not application-specific suites" > > The difference is that your previous work just consolidated the existing > subsystem tier 1-3 definitions, but here you are choosing to define "all > the rest" as tier 4. I don't think it is actually helpful/useful to > anyone - and it bears no resemblance whatsoever to what we call "tier > 4", so that will just lead to unnecessary confusion IMO. @dholmes-ora , although I fully agree that this might lead to some misunderstanding b/w Oracle and non-Oracle folks, I don't see how it's different from the previous patch, which introduced `hotspot:tier2` and `hotspot:tier3`. even if we reduce `tierN` to just a set of tests, the test groups added by 8272914 bear as much resemblance to the test sets used in Oracle's tier2-3 as the suggested `hotspot:tier4` groups in this patch to the actual `tier4` definition used in Oracle's internal system, e.g. `hotspot:tier2` group has 0 tests from `test/hotspot/jtreg/compiler`, but Oracle's `tier2` does include a number of `test/hotspot/jtreg/compiler` tests (which aren't part of `:tier1`). I believe that this patch actually moves us closer to a convergence point, as the union of `hotspot:tier1` -- `hotspot:tier4` test groups is very close to the test sets used in hotspot parts of Oracle's `tier1` -- `tier4` definitions. Thanks, -- Igor ------------- PR: https://git.openjdk.java.net/jdk/pull/5357 From david.holmes at oracle.com Tue Sep 7 05:05:39 2021 From: david.holmes at oracle.com (David Holmes) Date: Tue, 7 Sep 2021 15:05:39 +1000 Subject: RFR: 8273314: Add tier4 test groups [v3] In-Reply-To: References: <6rDioD5KZREYHyzOXol72O0erNDqKHUqb-0k1SwhInA=.90a12492-9e2f-4f0c-bf09-8d67d1d6111f@github.com> Message-ID: <6000402c-061e-d786-3367-73a8bb934811@oracle.com> On 7/09/2021 2:20 pm, Igor Ignatyev wrote: > On Mon, 6 Sep 2021 13:22:03 GMT, Aleksey Shipilev wrote: > >>> During the review of JDK-8272914 that added hotspot:tier{2,3} groups, @iignatev suggested to create tier4 groups that capture all tests not in tiers{1,2,3}. I have excluded `vmTestbase` and `hotspot:tier4,` because they take 10+ hours on my highly parallel machine. I have also excluded `applications` from `hotspot:tier4`, because they require test dependencies (e.g. jcstress). >>> >>> Sample run: >>> >>> >>> ============================== >>> Test summary >>> ============================== >>> TEST TOTAL PASS FAIL ERROR >>>>> jtreg:test/hotspot/jtreg:tier4 426 425 1 0 << >>>>> jtreg:test/jdk:tier4 2891 2885 4 2 << >>> jtreg:test/langtools:tier4 0 0 0 0 >>> jtreg:test/jaxp:tier4 0 0 0 0 >>> ============================== >>> >>> real 64m13.994s >>> user 1462m1.213s >>> sys 39m38.032s >>> >>> >>> There are interesting test failures on my machine, which I would address separately. >> >> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: >> >> Drop applications and fix the comment > >> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [hotspot-dev](mailto:hotspot-dev at mail.openjdk.java.net):_ >> >> On 7/09/2021 1:17 am, Aleksey Shipilev wrote: >> >>> @dholmes-ora: Generally speaking, all `tierX` definitions are rather arbitrary, as there seem to be nothing intrinsic about the tests to be in a particular tier. In other words, what `tierX` consists of is a matter of agreement. I'd say `hotspot:tier4` is "all assorted Hotspot tests that are not application-specific suites" >> >> The difference is that your previous work just consolidated the existing >> subsystem tier 1-3 definitions, but here you are choosing to define "all >> the rest" as tier 4. I don't think it is actually helpful/useful to >> anyone - and it bears no resemblance whatsoever to what we call "tier >> 4", so that will just lead to unnecessary confusion IMO. > > @dholmes-ora , although I fully agree that this might lead to some misunderstanding b/w Oracle and non-Oracle folks, I don't see how it's different from the previous patch, which introduced `hotspot:tier2` and `hotspot:tier3`. Because hotspot:tier2 and hotspot:tier3 simply grouped existing component definitions for tiers 2 and 3: +tier2 = \ + :hotspot_tier2_runtime \ + :hotspot_tier2_runtime_platform_agnostic \ + :hotspot_tier2_serviceability \ + :tier2_gc_epsilon \ + :tier2_gc_shenandoah + +tier3 = \ + :hotspot_tier3_runtime \ + :tier3_gc_shenandoah but that is not the case for tier4. > even if we reduce `tierN` to just a set of tests, the test groups added by 8272914 bear as much resemblance to the test sets used in Oracle's tier2-3 as the suggested `hotspot:tier4` groups in this patch to the actual `tier4` definition used in Oracle's internal system, e.g. `hotspot:tier2` group has 0 tests from `test/hotspot/jtreg/compiler`, but Oracle's `tier2` does include a number of `test/hotspot/jtreg/compiler` tests (which aren't part of `:tier1`). I believe that this patch actually moves us closer to a convergence point, as the union of `hotspot:tier1` -- `hotspot:tier4` test groups is very close to the test sets used in hotspot parts of Oracle's `tier1` -- `tier4` definitions. We can discuss Oracle's tier definitions privately - I don't see any connection between those and this tier4 however. Thanks, David ----- > Thanks, > -- Igor > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/5357 > From alanb at openjdk.java.net Tue Sep 7 06:47:37 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 7 Sep 2021 06:47:37 GMT Subject: RFR: 8273278: Support XSLT on GraalVM Native Image--deterministic bytecode generation in XSLT In-Reply-To: References: Message-ID: <4nh-bDdoHgWgMAU0i3Zh1AMP3hBxQioWFXqihAYNCyM=.4e5bf9f6-ef93-4a0e-9aab-ef2e06c1eb77@github.com> On Wed, 1 Sep 2021 13:28:34 GMT, Jovan Stevanovic wrote: > GraalVM Native Image supports loading classes at runtime if they are known during image build (class predefinition). This is achieved by the JVMTI agent that registers dynamically generated classes in a regular HotSpot run. The Native Image build uses these registered classes to embed them into the produced binary so they can be loaded at runtime. Loading at runtime is achieved by matching the unique hash of generated classes. > > If the generated bytecode is unstable across runs, the generated native image can not match the hash of the runtime-generated bytecode to the pre-defined classes. The execution failure happens here: > https://github.com/oracle/graal/blob/master/substratevm/src/com.oracle.svm.core/src/com/oracle/svm/core/hub/PredefinedClassesSupport.java#L127-L131. > > In XSLT the produced bytecode is unstable for the following reasons: > > - Methods like ` HashMap#values` and `HashMap#keySet` result in different traversal orders of its elements yielding a different order of methods and fields. > > - The default `Object#toString` includes the current memory reference of `com.sun.org.apache.xalan.internal.xsltc.compiler.Number` in the generated class. I guess a question here will be whether this should be contributed to the upstream Xalan project to keep the changes in the JDK in sync, or maybe the JDK has diverged too much already for this to matter. ------------- PR: https://git.openjdk.java.net/jdk/pull/5331 From alanb at openjdk.java.net Tue Sep 7 07:22:44 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 7 Sep 2021 07:22:44 GMT Subject: RFR: 8273401: Remove JarIndex support in URLClassPath In-Reply-To: References: Message-ID: On Tue, 7 Sep 2021 03:34:27 GMT, wxiang wrote: > There is a bug for URLClassPath.findResources with JarIndex. > With some discussions about the bug, the current priority is to remove the JAR index support in URLClassPath, > and don?t need to do anything to the jar tool in the short term, except just to move JarIndex to the jdk.jartool module. > > The PR includes: > 1. remove the JarIndex support in URLClassPath > 2. move JarIndex into jdk.jartool module. Thanks for taking this on. I've done a pass over the changes and it looks complete, just a few issues. Next step will be to create a CSR for this change. src/java.base/share/classes/java/util/jar/JarFile.java line 220: > 218: * The index file name. > 219: */ > 220: public static final String INDEX_NAME = "META-INF/INDEX.LIST"; Adding this as a public field means it becomes part of the API, so it shouldn't be public here. src/java.base/share/classes/java/util/jar/JarVerifier.java line 147: > 145: > 146: if (uname.equals(JarFile.MANIFEST_NAME) || > 147: uname.equals(JarFile.INDEX_NAME)) { It would be useful if someone from security-libs could comment on this. The interaction between signed JAR and JAR index isn't very clear. The change you have is safe but it might be that we can drop the checking for INDEX.LIST here. test/jdk/sun/misc/JarIndex/JarIndexMergeTest.java line 44: > 42: import sun.tools.jar.JarIndex; > 43: > 44: public class JarIndexMergeTest { Is this the one remaining test in sun/misc/JarIndex? I think it can be moved to test/jdk/java/util/jar. I think we should change the package name in the summary comment too. ------------- PR: https://git.openjdk.java.net/jdk/pull/5383 From shade at openjdk.java.net Tue Sep 7 08:14:37 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 7 Sep 2021 08:14:37 GMT Subject: RFR: 8273314: Add tier4 test groups [v3] In-Reply-To: References: <6rDioD5KZREYHyzOXol72O0erNDqKHUqb-0k1SwhInA=.90a12492-9e2f-4f0c-bf09-8d67d1d6111f@github.com> Message-ID: <4izBbOzjSpoP4EwfJPEILXvLU0fCdI6xy4PTo3mYEtI=.5796ff23-e9f2-4cbe-8c8c-eb825633dd66@github.com> On Mon, 6 Sep 2021 13:22:03 GMT, Aleksey Shipilev wrote: >> During the review of JDK-8272914 that added hotspot:tier{2,3} groups, @iignatev suggested to create tier4 groups that capture all tests not in tiers{1,2,3}. I have excluded `vmTestbase` and `hotspot:tier4,` because they take 10+ hours on my highly parallel machine. I have also excluded `applications` from `hotspot:tier4`, because they require test dependencies (e.g. jcstress). >> >> Sample run: >> >> >> ============================== >> Test summary >> ============================== >> TEST TOTAL PASS FAIL ERROR >>>> jtreg:test/hotspot/jtreg:tier4 426 425 1 0 << >>>> jtreg:test/jdk:tier4 2891 2885 4 2 << >> jtreg:test/langtools:tier4 0 0 0 0 >> jtreg:test/jaxp:tier4 0 0 0 0 >> ============================== >> >> real 64m13.994s >> user 1462m1.213s >> sys 39m38.032s >> >> >> There are interesting test failures on my machine, which I would address separately. > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Drop applications and fix the comment Once again, the disconnect between Oracle and OpenJDK test definitions seems to be the problem for Oracle's side. Rectifying that disconnect might fall under the scope of this PR, but I have to point out that it is a courtesy of upstream open-source project to care about proprietary downstream definitions. More to the point: since `tier4` as "catch-all-the-rest" was Igor's idea, I assumed that would be in agreement with Oracle's test definitions. Following this discussion, it seems I assumed wrong. So it puts me in a weird position to be between two Oracle engineers arguing about proprietary test definitions I cannot really know about, and have no decision power about. For all I care for OpenJDK, we might as well model `tier4` after what Oracle does, as to minimize confusion for Oracle engineers. But then again, I have no idea what Oracle means by `tier4`. So as the alternative, I can postpone this PR until you folks have a coherent view on this, or I can just give up on this PR and re-assign the RFE to Igor, assuming he is willing to work this out. Tell me what you want me to do here. ------------- PR: https://git.openjdk.java.net/jdk/pull/5357 From dfuchs at openjdk.java.net Tue Sep 7 08:47:46 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 7 Sep 2021 08:47:46 GMT Subject: RFR: 8255878: FilterInputStream is missing implementations of Java 9 InputStream methods [v2] In-Reply-To: <6Z18cONi4i747kWV96he1UsJQUy88DRC6X9MgTzG1ns=.c07cda5d-9646-4993-aeae-aab093224917@github.com> References: <73JP6cAapkJpM3afNxR0U1m5I3RxshdsRx5oSJgqEJg=.e9f8fc5d-5992-4ead-bfa6-bbfff3728b59@github.com> <-XW3tJUbBEPFVXK6CuI6UVU_Flg8V70_9gCjwiFedxI=.2b2061b8-738b-48f6-a931-db3ca3e8ffc2@github.com> <6Z18cONi4i747kWV96he1UsJQUy88DRC6X9MgTzG1ns=.c07cda5d-9646-4993-aeae-aab093224917@github.com> Message-ID: <5beUu2eBOogG4uuy5Ci_0wYWu_oqqMYuC0Jo2dR9Tfk=.9c870877-833a-4515-a443-06d879fc1099@github.com> On Mon, 6 Sep 2021 12:02:12 GMT, Alan Bateman wrote: > Ah yes, I think you are right. In that case JDK-8255878 can be closed as WNF or else FilterInputStream provides implementations of these methods that don't directly delegate. We could set a boolean in the constructor if `this.getClass() == FilterInputStream.class` and only delegate in that case. On the other hand - FilterInputStream seems to be intended for subclassing, so maybe that optimization should be done in its subclasses instead, when possible. That said - I see that the class level documentation of FilterInputStream says: > The class FilterInputStream itself simply overrides all methods of InputStream with versions that pass all requests to the contained input stream. which is no longer strictly true - should this sentence be amended to reflect what really happens? ------------- PR: https://git.openjdk.java.net/jdk/pull/5367 From raffaello.giulietti at gmail.com Tue Sep 7 09:53:05 2021 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Tue, 7 Sep 2021 11:53:05 +0200 Subject: better random numbers In-Reply-To: <45847008-5021-7911-607c-559f8bc4545e@littlepinkcloud.com> References: <3DC84A6C-DAB3-42CB-ACF6-0CADB5BE19C1@oracle.com> <45847008-5021-7911-607c-559f8bc4545e@littlepinkcloud.com> Message-ID: <12812f86-8723-27d3-a8b0-09d77aee7baf@gmail.com> Hello, On 2021-09-05 16:43, Andrew Haley wrote: > On 9/3/21 12:35 AM, John Rose wrote: > >> The reference I?d like to give here is to Dr. Melissa O?Neill?s >> website and articles: > > I'm quite sceptical. Anyone who says a (non-cryptographic) random- > number generator is "hard to predict" is either quite naive or in a > state of sin, (;-) and while O?Neill?s argument seems sound, it > doesn't seem to have convinced the academic world. > > Lemire is thoughtful: > https://lemire.me/blog/2017/08/15/on-melissa-oneills-pcg-random-number-generator/ > On this blog entry (year 2017), Lemire is not giving any technical or scientific argument in favor or against PCG. He also refers to, and quotes from, a blog entry (year 2015) of an influential researcher (whose work he respects) suggesting the entry has harsh words about PCG. The fact is, that entry doesn't mention PCG or O'Neill at all and the quotation if not found there. Looking at Lemire's formal papers, they don't seem to be about PRNGs, except for one (curiously written with O'Neill herself in 2019!) about statistical tests of variants of Xorshift and Xoroshiro. I'm not competent on PRNGs at all. Still, I wouldn't rely on Lemire's blog entry when it comes to PCG. I'd rather look for other (rare) re/sources. > I wonder about AES, which can do (on Apple M1) 2 parallel rounds per > clock cycle. I'm quite tempted to try a reduced- round AES on the > TestU01 statistical tests. Maybe 6 rounds? However, there can be a > long latency between FPU and integer CPU, so perhaps it's not such a > great idea. Also, you have to load the key registers before you can > generate a random number, so it only really works if you want to > generate a lot of bits at a time. But it is maybe 128 randomish bits > per a few clock cycles. > From myano at openjdk.java.net Tue Sep 7 11:12:56 2021 From: myano at openjdk.java.net (Masanori Yano) Date: Tue, 7 Sep 2021 11:12:56 GMT Subject: RFR: 8269373: some tests in jdk/tools/launcher/ fails on localized Windows platform [v3] In-Reply-To: References: Message-ID: > Hi all, > > Could you please review the 8269373 bug fixes? > > These tests call java.lang.ProcessBuilder in direct, so not used jtreg command option. To run non-localized tests, -Duser.language=en and -Duser.country=US options should be added in ProcessBuilder. Masanori Yano has updated the pull request incrementally with one additional commit since the last revision: 8269373: some tests in jdk/tools/launcher/ fails on localized Windows platform ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4594/files - new: https://git.openjdk.java.net/jdk/pull/4594/files/99925f72..655f5db0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4594&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4594&range=01-02 Stats: 31 lines in 6 files changed: 16 ins; 9 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/4594.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4594/head:pull/4594 PR: https://git.openjdk.java.net/jdk/pull/4594 From myano at openjdk.java.net Tue Sep 7 11:18:55 2021 From: myano at openjdk.java.net (Masanori Yano) Date: Tue, 7 Sep 2021 11:18:55 GMT Subject: RFR: 8269373: some tests in jdk/tools/launcher/ fails on localized Windows platform [v3] In-Reply-To: References: Message-ID: On Tue, 7 Sep 2021 11:12:56 GMT, Masanori Yano wrote: >> Hi all, >> >> Could you please review the 8269373 bug fixes? >> >> These tests call java.lang.ProcessBuilder in direct, so not used jtreg command option. To run non-localized tests, -Duser.language=en and -Duser.country=US options should be added in ProcessBuilder. > > Masanori Yano has updated the pull request incrementally with one additional commit since the last revision: > > 8269373: some tests in jdk/tools/launcher/ fails on localized Windows platform I fixed it to exit silently in case the locale is not US. Thank you. ------------- PR: https://git.openjdk.java.net/jdk/pull/4594 From myano at openjdk.java.net Tue Sep 7 11:18:54 2021 From: myano at openjdk.java.net (Masanori Yano) Date: Tue, 7 Sep 2021 11:18:54 GMT Subject: RFR: 8269373: some tests in jdk/tools/launcher/ fails on localized Windows platform [v4] In-Reply-To: References: Message-ID: > Hi all, > > Could you please review the 8269373 bug fixes? > > These tests call java.lang.ProcessBuilder in direct, so not used jtreg command option. To run non-localized tests, -Duser.language=en and -Duser.country=US options should be added in ProcessBuilder. Masanori Yano has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - Merge branch 'master' into 8269373 - 8269373: some tests in jdk/tools/launcher/ fails on localized Windows platform - 8269373: use test opts for process arguments - 8269373: some tests in jdk/tools/launcher/ fails on localized Windows platform ------------- Changes: https://git.openjdk.java.net/jdk/pull/4594/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4594&range=03 Stats: 15 lines in 3 files changed: 12 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/4594.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4594/head:pull/4594 PR: https://git.openjdk.java.net/jdk/pull/4594 From myano at openjdk.java.net Tue Sep 7 11:26:01 2021 From: myano at openjdk.java.net (Masanori Yano) Date: Tue, 7 Sep 2021 11:26:01 GMT Subject: RFR: 8269373: some tests in jdk/tools/launcher/ fails on localized Windows platform [v5] In-Reply-To: References: Message-ID: > Hi all, > > Could you please review the 8269373 bug fixes? > > These tests call java.lang.ProcessBuilder in direct, so not used jtreg command option. To run non-localized tests, -Duser.language=en and -Duser.country=US options should be added in ProcessBuilder. Masanori Yano has updated the pull request incrementally with one additional commit since the last revision: 8269373: some tests in jdk/tools/launcher/ fails on localized Windows platform ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4594/files - new: https://git.openjdk.java.net/jdk/pull/4594/files/98e7cfcb..b5a46b4a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4594&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4594&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4594.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4594/head:pull/4594 PR: https://git.openjdk.java.net/jdk/pull/4594 From spliterator at gmail.com Tue Sep 7 11:48:01 2021 From: spliterator at gmail.com (Stefan Zobel) Date: Tue, 7 Sep 2021 13:48:01 +0200 Subject: better random numbers In-Reply-To: <12812f86-8723-27d3-a8b0-09d77aee7baf@gmail.com> References: <3DC84A6C-DAB3-42CB-ACF6-0CADB5BE19C1@oracle.com> <45847008-5021-7911-607c-559f8bc4545e@littlepinkcloud.com> <12812f86-8723-27d3-a8b0-09d77aee7baf@gmail.com> Message-ID: > > On this blog entry (year 2017), Lemire is not giving any technical or > scientific argument in favor or against PCG. > > He also refers to, and quotes from, a blog entry (year 2015) of an > influential researcher (whose work he respects) suggesting the entry has > harsh words about PCG. The fact is, that entry doesn't mention PCG or > O'Neill at all and the quotation if not found there. > That "influential researcher" is probably Sebastiano Vigna who has indeed harsh words on PCG: https://pcg.di.unimi.it/pcg.php From raffaello.giulietti at gmail.com Tue Sep 7 12:13:19 2021 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Tue, 7 Sep 2021 14:13:19 +0200 Subject: better random numbers In-Reply-To: References: <3DC84A6C-DAB3-42CB-ACF6-0CADB5BE19C1@oracle.com> <45847008-5021-7911-607c-559f8bc4545e@littlepinkcloud.com> <12812f86-8723-27d3-a8b0-09d77aee7baf@gmail.com> Message-ID: <71afd13a-2b9e-4788-cb96-13caf90ad121@gmail.com> On 2021-09-07 13:48, Stefan Zobel wrote: >> >> On this blog entry (year 2017), Lemire is not giving any technical or >> scientific argument in favor or against PCG. >> >> He also refers to, and quotes from, a blog entry (year 2015) of an >> influential researcher (whose work he respects) suggesting the entry has >> harsh words about PCG. The fact is, that entry doesn't mention PCG or >> O'Neill at all and the quotation if not found there. >> > > That "influential researcher" is probably Sebastiano Vigna who has indeed > harsh words on PCG: https://pcg.di.unimi.it/pcg.php > Perhaps. But the page you refer to is (unfortunately) not dated, except for a mention of a year 2020 result from INRIA. Lemire's blog post is from 2017. Besides, the quotation on Lemire's blog entry is not found here. Two search engines don't know about the quotation either, except for Lemire's blog. From james.laskey at oracle.com Tue Sep 7 12:29:39 2021 From: james.laskey at oracle.com (Jim Laskey) Date: Tue, 7 Sep 2021 12:29:39 +0000 Subject: Suspicious duplicate condition in java.util.regex.Grapheme#isExcludedSpacingMark In-Reply-To: References: Message-ID: <5117A14D-6BE4-4901-A100-C5C068D5D331@oracle.com> Bug submitted on your behalf. https://bugs.openjdk.java.net/browse/JDK-8273430 > On Sep 6, 2021, at 4:16 AM, Andrey Turbanov wrote: > > Hello. > I found suspicious condition in the method > java.util.regex.Grapheme#isExcludedSpacingMark > It's detected by IntelliJ IDEA inspection 'Condition is covered by > further condition' > https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/regex/Grapheme.java#L157 > > ``` > private static boolean isExcludedSpacingMark(int cp) { > return cp == 0x102B || cp == 0x102C || cp == 0x1038 || > cp >= 0x1062 && cp <= 0x1064 || > cp >= 0x1062 && cp <= 0x106D || // <== here is the warning > cp == 0x1083 || > cp >= 0x1087 && cp <= 0x108C || > cp == 0x108F || > cp >= 0x109A && cp <= 0x109C || > cp == 0x1A61 || cp == 0x1A63 || cp == 0x1A64 || > cp == 0xAA7B || cp == 0xAA7D; > } > ``` > There are 2 sub-conditions in this complex condition: > cp >= 0x1062 && cp <= 0x1064 || > cp >= 0x1062 && cp <= 0x106D || > > The second condition is _wider_ than the first one. > I believe it's a bug. The second condition (according to > https://www.compart.com/en/unicode/category/Mc) should look like this: > > cp >= 0x1067 && cp <= 0x106D || > > 0x1065, 0x1066 are not from the Spacing_Mark category. > > > Andrey Turbanov From github.com+44313413+jovanstevanovic at openjdk.java.net Tue Sep 7 13:33:42 2021 From: github.com+44313413+jovanstevanovic at openjdk.java.net (Jovan Stevanovic) Date: Tue, 7 Sep 2021 13:33:42 GMT Subject: RFR: 8273278: Support XSLT on GraalVM Native Image--deterministic bytecode generation in XSLT In-Reply-To: <4nh-bDdoHgWgMAU0i3Zh1AMP3hBxQioWFXqihAYNCyM=.4e5bf9f6-ef93-4a0e-9aab-ef2e06c1eb77@github.com> References: <4nh-bDdoHgWgMAU0i3Zh1AMP3hBxQioWFXqihAYNCyM=.4e5bf9f6-ef93-4a0e-9aab-ef2e06c1eb77@github.com> Message-ID: On Tue, 7 Sep 2021 06:44:22 GMT, Alan Bateman wrote: > I guess a question here will be whether this should be contributed to the upstream Xalan project to keep the changes in the JDK in sync, or maybe the JDK has diverged too much already for this to matter. It seems that both repositories for Xalan on Apache's GH (https://github.com/apache/xalan-java and https://github.com/apache/xalan-j) are inactive for two and a half years. ------------- PR: https://git.openjdk.java.net/jdk/pull/5331 From alanb at openjdk.java.net Tue Sep 7 13:37:39 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 7 Sep 2021 13:37:39 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v8] In-Reply-To: <5V0eAcrG9rS-d9RnyC2oJ5kVo6v84IhyBn40M71mYUg=.5d8c17fe-a23b-49a8-bfef-f670c0f013eb@github.com> References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> <5V0eAcrG9rS-d9RnyC2oJ5kVo6v84IhyBn40M71mYUg=.5d8c17fe-a23b-49a8-bfef-f670c0f013eb@github.com> Message-ID: On Wed, 1 Sep 2021 01:05:32 GMT, Mandy Chung wrote: >> This reimplements core reflection with method handles. >> >> For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. >> >> The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. >> >> The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. >> >> Ran tier1-tier8 tests. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8013527 >> [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > minor cleanup and more test case. This is great work! There is more specialization than I would have expected but it looks maintainable so I think should be okay to integrate with that and investigate a special spreader later. I think it would be good to get this into JDK 18 early so that there is lots of time to test and identify corner cases with performance. ------------- PR: https://git.openjdk.java.net/jdk/pull/5027 From mcimadamore at openjdk.java.net Tue Sep 7 14:01:35 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 7 Sep 2021 14:01:35 GMT Subject: RFR: 8273315: Parallelize and increase timeouts for java/foreign/TestMatrix.java test In-Reply-To: References: Message-ID: On Fri, 3 Sep 2021 09:53:53 GMT, Aleksey Shipilev wrote: > This test runs a lot of configurations, and spends a lot of time serially. This is especially pronounced when run in prospective tier4 runs (JDK-8273314). There are reports of multi-hour runs (see JDK-8271613). We can parallelize the test configurations for this test to make it hurt less. Also, timeouts need to be increased for `TestUpcall` test configs, because some of them are very slow in fastdebug mode. > > Sample run: > > > $ time CONF=linux-x86_64-server-fastdebug make run-test TEST=java/foreign/TestMatrix.java | ts -s > 00:00:00 Building target 'run-test' in configuration 'linux-x86_64-server-fastdebug' > 00:00:03 Test selection 'java/foreign/TestMatrix.java', will run: > 00:00:03 * jtreg:test/jdk/java/foreign/TestMatrix.java > 00:00:03 > 00:00:03 Running test 'jtreg:test/jdk/java/foreign/TestMatrix.java' > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TTFT > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FFFF > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FFTF > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TTTT > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FTTT > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FFTT > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FFFT > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TTTF > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FTTF > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TFFT > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TFTF > 00:00:32 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TFFF > 00:00:32 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FTFF > 00:00:35 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TFTT > 00:00:35 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TTFF > 00:00:38 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FTFT > 00:01:50 Passed: java/foreign/TestMatrix.java#Downcall-FF > 00:02:27 Passed: java/foreign/TestMatrix.java#Downcall-TF > 00:03:03 Passed: java/foreign/TestMatrix.java#Downcall-FT > 00:03:47 Passed: java/foreign/TestMatrix.java#Downcall-TT > 00:04:17 Passed: java/foreign/TestMatrix.java#Upcall-FTFF > 00:04:23 Passed: java/foreign/TestMatrix.java#Upcall-TFFF > 00:05:46 Passed: java/foreign/TestMatrix.java#Upcall-TTFF > 00:06:03 Passed: java/foreign/TestMatrix.java#Upcall-TFFT > 00:06:44 Passed: java/foreign/TestMatrix.java#Upcall-FTFT > 00:08:24 Passed: java/foreign/TestMatrix.java#Upcall-TFTF > 00:08:39 Passed: java/foreign/TestMatrix.java#Upcall-TTFT > 00:09:16 Passed: java/foreign/TestMatrix.java#Upcall-FTTF > 00:09:19 Passed: java/foreign/TestMatrix.java#Upcall-TFTT > 00:10:01 Passed: java/foreign/TestMatrix.java#Upcall-FTTT > 00:10:37 Passed: java/foreign/TestMatrix.java#Upcall-TTTF > 00:12:16 Passed: java/foreign/TestMatrix.java#Upcall-TTTT > 00:12:17 Test results: passed: 32 > 00:12:21 > 00:12:21 ============================== > 00:12:21 Test summary > 00:12:21 ============================== > 00:12:21 TEST TOTAL PASS FAIL ERROR > 00:12:21 jtreg:test/jdk/java/foreign/TestMatrix.java 32 32 0 0 > 00:12:21 ============================== > > real 12m20.538s > user 131m54.043s > sys 0m59.944s > > > If we don't parallelize, then those 130 minutes are spent serially. How is this test executed? I think when this was added the idea was that this had to be an advanced test which had to be run explicitly by users, but would not be picked up in the various test groups/tiers. I'm defo not seeing it running in the `jdk_foreign` group, so it shouldn't run on tier4. I'm not sure what's happening? ------------- PR: https://git.openjdk.java.net/jdk/pull/5358 From jai.forums2013 at gmail.com Tue Sep 7 14:04:07 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Tue, 7 Sep 2021 19:34:07 +0530 Subject: RFR: 8231640: (prop) Canonical property storage In-Reply-To: References: <0851283f-23f6-a8e6-03c5-d98d29770dbc@oracle.com> Message-ID: On 05/09/21 6:01 pm, Jaikiran Pai wrote: > Hello Alan, > > On 05/09/21 1:46 pm, Alan Bateman wrote: >> On 04/09/2021 16:50, Jaikiran Pai wrote: >>> The commit in this PR implements the proposal for enhancement that >>> was discussed in the core-libs-dev mailing list recently[1], for >>> https://bugs.openjdk.java.net/browse/JDK-8231640 >>> >>> At a high level - the `store()` APIs in `Properties` have been >>> modified to now look for the `SOURCE_DATE_EPOCH` environment >>> variable[2]. If that env variable is set, then instead of writing >>> out the current date time as a date comment, the `store()` APIs >>> instead will use the value set for this env variable to parse it to >>> a `Date` and write out the string form of such a date. The >>> implementation here uses the `d MMM yyyy HH:mm:ss 'GMT'` date format >>> and `Locale.ROOT` to format and write out such a date. This should >>> provide reproducibility whenever the `SOURCE_DATE_EPOCH` is set. >>> Furthermore, intentionally, no changes in the date format of the >>> "current date" have been done. >>> >>> These? modified `store()` APIs work in the presence of the >>> `SecurityManager` too. The caller is expected to have a read >>> permission on the `SOURCE_DATE_EPOCH` environment variable. If the >>> caller doesn't have that permission, then the implementation of >>> these `store()` APIs will write out the "current date" and will >>> ignore any value that has been set for the `SOURCE_DATE_EPOCH` env >>> variable. This should allow for backward compatibility of existing >>> applications, where, when they run under a `SecurityManager` and >>> perhaps with an existing restrictive policy file, the presence of >>> `SOURCE_DATE_EPOCH` shouldn't impact their calls to the `store()` APIs. >>> >>> The modified `store()` APIs will also ignore any value for >>> `SOURCE_DATE_EPOCH` that? cannot be parsed to an `long` value. In >>> such cases, the `store()` APIs will write out the "current date" and >>> ignore the value set for this environment variable. No exceptions >>> will be thrown for such invalid values. This is an additional >>> backward compatibility precaution to prevent any rogue value for >>> `SOURCE_DATE_EPOCH` from breaking applications. >> In the discussion on this option then I think we were talking about >> changing the specification of the store methods to allow for an >> implementation specific means to override the date and put the >> discussion on SOURCE_DATE_EPOCH in an @implNote. >> > I will move the updated javadoc to an @implNote then. I guess, the > existing part where it explains how the current date comment is > written out, should stay where it is currently? I've now updated the PR to move the new text of this javadoc into a @implNote. -Jaikiran From mcimadamore at openjdk.java.net Tue Sep 7 14:08:37 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 7 Sep 2021 14:08:37 GMT Subject: RFR: 8273315: Parallelize and increase timeouts for java/foreign/TestMatrix.java test In-Reply-To: References: Message-ID: On Fri, 3 Sep 2021 09:53:53 GMT, Aleksey Shipilev wrote: > This test runs a lot of configurations, and spends a lot of time serially. This is especially pronounced when run in prospective tier4 runs (JDK-8273314). There are reports of multi-hour runs (see JDK-8271613). We can parallelize the test configurations for this test to make it hurt less. Also, timeouts need to be increased for `TestUpcall` test configs, because some of them are very slow in fastdebug mode. > > Sample run: > > > $ time CONF=linux-x86_64-server-fastdebug make run-test TEST=java/foreign/TestMatrix.java | ts -s > 00:00:00 Building target 'run-test' in configuration 'linux-x86_64-server-fastdebug' > 00:00:03 Test selection 'java/foreign/TestMatrix.java', will run: > 00:00:03 * jtreg:test/jdk/java/foreign/TestMatrix.java > 00:00:03 > 00:00:03 Running test 'jtreg:test/jdk/java/foreign/TestMatrix.java' > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TTFT > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FFFF > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FFTF > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TTTT > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FTTT > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FFTT > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FFFT > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TTTF > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FTTF > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TFFT > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TFTF > 00:00:32 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TFFF > 00:00:32 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FTFF > 00:00:35 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TFTT > 00:00:35 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TTFF > 00:00:38 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FTFT > 00:01:50 Passed: java/foreign/TestMatrix.java#Downcall-FF > 00:02:27 Passed: java/foreign/TestMatrix.java#Downcall-TF > 00:03:03 Passed: java/foreign/TestMatrix.java#Downcall-FT > 00:03:47 Passed: java/foreign/TestMatrix.java#Downcall-TT > 00:04:17 Passed: java/foreign/TestMatrix.java#Upcall-FTFF > 00:04:23 Passed: java/foreign/TestMatrix.java#Upcall-TFFF > 00:05:46 Passed: java/foreign/TestMatrix.java#Upcall-TTFF > 00:06:03 Passed: java/foreign/TestMatrix.java#Upcall-TFFT > 00:06:44 Passed: java/foreign/TestMatrix.java#Upcall-FTFT > 00:08:24 Passed: java/foreign/TestMatrix.java#Upcall-TFTF > 00:08:39 Passed: java/foreign/TestMatrix.java#Upcall-TTFT > 00:09:16 Passed: java/foreign/TestMatrix.java#Upcall-FTTF > 00:09:19 Passed: java/foreign/TestMatrix.java#Upcall-TFTT > 00:10:01 Passed: java/foreign/TestMatrix.java#Upcall-FTTT > 00:10:37 Passed: java/foreign/TestMatrix.java#Upcall-TTTF > 00:12:16 Passed: java/foreign/TestMatrix.java#Upcall-TTTT > 00:12:17 Test results: passed: 32 > 00:12:21 > 00:12:21 ============================== > 00:12:21 Test summary > 00:12:21 ============================== > 00:12:21 TEST TOTAL PASS FAIL ERROR > 00:12:21 jtreg:test/jdk/java/foreign/TestMatrix.java 32 32 0 0 > 00:12:21 ============================== > > real 12m20.538s > user 131m54.043s > sys 0m59.944s > > > If we don't parallelize, then those 130 minutes are spent serially. Ok, I see - there's a new configuration for tier4 which runs all tests excluded from tier1/2/3. To me that seems to be the issue. This particular test was never meant to be executed as part of automated build infra. So I'd suggest we disable the test from tier4 first, and then, if you still want to pursue the improvement, we can do that too. On my machine the test doesn't take 1.5 hours. ------------- PR: https://git.openjdk.java.net/jdk/pull/5358 From shade at openjdk.java.net Tue Sep 7 14:08:36 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 7 Sep 2021 14:08:36 GMT Subject: RFR: 8273315: Parallelize and increase timeouts for java/foreign/TestMatrix.java test In-Reply-To: References: Message-ID: On Tue, 7 Sep 2021 13:58:48 GMT, Maurizio Cimadamore wrote: > How is this test executed? I think when this was added the idea was that this had to be an advanced test which had to be run explicitly by users, but would not be picked up in the various test groups/tiers. I'm defo not seeing it running in the `jdk_foreign` group, so it shouldn't run on tier4. I'm not sure what's happening? As I wrote in PR, "This is especially pronounced when run in prospective tier4 runs (JDK-8273314)." -- that group was supposed to run all tests not caught by other tiers. That work seems to be stalled a bit. See also JDK-8271613 that is submitted by SAP folks who run it as part of all JDK tests, I guess. But nevertheless, I think speeding up the test would be even more useful for those who run this test by hand: waiting for 12 minutes instead of 1.5 hours ;) ------------- PR: https://git.openjdk.java.net/jdk/pull/5358 From jpai at openjdk.java.net Tue Sep 7 14:10:10 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 7 Sep 2021 14:10:10 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v2] In-Reply-To: References: Message-ID: > The commit in this PR implements the proposal for enhancement that was discussed in the core-libs-dev mailing list recently[1], for https://bugs.openjdk.java.net/browse/JDK-8231640 > > At a high level - the `store()` APIs in `Properties` have been modified to now look for the `SOURCE_DATE_EPOCH` environment variable[2]. If that env variable is set, then instead of writing out the current date time as a date comment, the `store()` APIs instead will use the value set for this env variable to parse it to a `Date` and write out the string form of such a date. The implementation here uses the `d MMM yyyy HH:mm:ss 'GMT'` date format and `Locale.ROOT` to format and write out such a date. This should provide reproducibility whenever the `SOURCE_DATE_EPOCH` is set. Furthermore, intentionally, no changes in the date format of the "current date" have been done. > > These modified `store()` APIs work in the presence of the `SecurityManager` too. The caller is expected to have a read permission on the `SOURCE_DATE_EPOCH` environment variable. If the caller doesn't have that permission, then the implementation of these `store()` APIs will write out the "current date" and will ignore any value that has been set for the `SOURCE_DATE_EPOCH` env variable. This should allow for backward compatibility of existing applications, where, when they run under a `SecurityManager` and perhaps with an existing restrictive policy file, the presence of `SOURCE_DATE_EPOCH` shouldn't impact their calls to the `store()` APIs. > > The modified `store()` APIs will also ignore any value for `SOURCE_DATE_EPOCH` that cannot be parsed to an `long` value. In such cases, the `store()` APIs will write out the "current date" and ignore the value set for this environment variable. No exceptions will be thrown for such invalid values. This is an additional backward compatibility precaution to prevent any rogue value for `SOURCE_DATE_EPOCH` from breaking applications. > > An additional change in the implementation of these `store()` APIs and unrelated to the date comment, is that these APIs will now write out the property keys in a deterministic order. The keys will be written out in the natural ordering as specified by `java.lang.String#compareTo()` API. > > The combination of the ordering of the property keys when written out and the usage of `SOURCE_DATE_EPOCH` environment value to determine the date comment should together allow for reproducibility of the output generated by these `store()` APIs. > > New jtreg test classes have been introduced to verify these changes. The primary focus of `PropertiesStoreTest` is the ordering aspects of the property keys that are written out. On the other hand `StoreReproducibilityTest` focuses on the reproducibility of the output generated by these APIs. The `StoreReproducibilityTest` runs these tests both in the presence and absence of `SecurityManager`. Plus, in the presence of SecurityManager, it tests both the scenarios where the caller is granted the requisite permission and in other case not granted that permission. > > These new tests and existing tests under `test/jdk/java/util/Properties/` pass with these changes. > > [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-August/080758.html > [2] https://reproducible-builds.org/specs/source-date-epoch/ Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: use @implNote to explain the use of the environment variable ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5372/files - new: https://git.openjdk.java.net/jdk/pull/5372/files/85748cf4..641864e2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5372&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5372&range=00-01 Stats: 19 lines in 1 file changed: 10 ins; 9 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5372.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5372/head:pull/5372 PR: https://git.openjdk.java.net/jdk/pull/5372 From shade at openjdk.java.net Tue Sep 7 14:14:35 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 7 Sep 2021 14:14:35 GMT Subject: RFR: 8273315: Parallelize and increase timeouts for java/foreign/TestMatrix.java test In-Reply-To: References: Message-ID: On Tue, 7 Sep 2021 14:05:46 GMT, Maurizio Cimadamore wrote: > if you still want to pursue the improvement, we can do that too. Yes, I still want to pursue this test improvement. ------------- PR: https://git.openjdk.java.net/jdk/pull/5358 From github.com+741251+turbanoff at openjdk.java.net Tue Sep 7 14:20:37 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Tue, 7 Sep 2021 14:20:37 GMT Subject: RFR: 8231640: (prop) Canonical property storage In-Reply-To: References: Message-ID: On Sun, 5 Sep 2021 12:38:20 GMT, Jaikiran Pai wrote: > Do you mean that converting the keySet() of an >existing Map into an array and then sorting that array and then using >that sorted array to iterate and using these keys to do an additional >lookup for value against the original Map would be more efficient in >this case? You can convert entrySet() to array. Not a keySet. In this case there is no need to lookup for values. ------------- PR: https://git.openjdk.java.net/jdk/pull/5372 From github.com+10835776+stsypanov at openjdk.java.net Tue Sep 7 14:21:56 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Tue, 7 Sep 2021 14:21:56 GMT Subject: RFR: 8273435: Remove redundant zero-length check in ClassDesc.of In-Reply-To: References: Message-ID: On Wed, 18 Aug 2021 07:28:57 GMT, Andrey Turbanov wrote: > After [JDK-8215510](https://bugs.openjdk.java.net/browse/JDK-8215510) (eed3a536c0) this condition is always `false`. Empty package name is handled separately. > Found by IntelliJ inspection. Marked as reviewed by stsypanov at github.com (no known OpenJDK username). Hi @turbanoff the change looks good and reasonable, I've filed an issue for this: https://bugs.openjdk.java.net/browse/JDK-8273435, so you can integrate now ------------- PR: https://git.openjdk.java.net/jdk/pull/5157 From github.com+741251+turbanoff at openjdk.java.net Tue Sep 7 14:21:55 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Tue, 7 Sep 2021 14:21:55 GMT Subject: RFR: 8273435: Remove redundant zero-length check in ClassDesc.of Message-ID: After [JDK-8215510](https://bugs.openjdk.java.net/browse/JDK-8215510) (eed3a536c0) this condition is always `false`. Empty package name is handled separately. Found by IntelliJ inspection. ------------- Commit messages: - [PATCH] Remove redundant zero-length check in ClassDesc.of Changes: https://git.openjdk.java.net/jdk/pull/5157/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5157&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273435 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5157.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5157/head:pull/5157 PR: https://git.openjdk.java.net/jdk/pull/5157 From mcimadamore at openjdk.java.net Tue Sep 7 14:34:37 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 7 Sep 2021 14:34:37 GMT Subject: RFR: 8273315: Parallelize and increase timeouts for java/foreign/TestMatrix.java test In-Reply-To: References: Message-ID: <1N5hqV0rUqqW9nUrybIvgKXqwhkxF8cdDBazG-hbsaM=.2aef9aa9-755b-47fa-88f7-8bceda08a498@github.com> On Fri, 3 Sep 2021 09:53:53 GMT, Aleksey Shipilev wrote: > This test runs a lot of configurations, and spends a lot of time serially. This is especially pronounced when run in prospective tier4 runs (JDK-8273314). There are reports of multi-hour runs (see JDK-8271613). We can parallelize the test configurations for this test to make it hurt less. Also, timeouts need to be increased for `TestUpcall` test configs, because some of them are very slow in fastdebug mode. > > Sample run: > > > $ time CONF=linux-x86_64-server-fastdebug make run-test TEST=java/foreign/TestMatrix.java | ts -s > 00:00:00 Building target 'run-test' in configuration 'linux-x86_64-server-fastdebug' > 00:00:03 Test selection 'java/foreign/TestMatrix.java', will run: > 00:00:03 * jtreg:test/jdk/java/foreign/TestMatrix.java > 00:00:03 > 00:00:03 Running test 'jtreg:test/jdk/java/foreign/TestMatrix.java' > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TTFT > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FFFF > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FFTF > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TTTT > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FTTT > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FFTT > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FFFT > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TTTF > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FTTF > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TFFT > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TFTF > 00:00:32 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TFFF > 00:00:32 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FTFF > 00:00:35 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TFTT > 00:00:35 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TTFF > 00:00:38 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FTFT > 00:01:50 Passed: java/foreign/TestMatrix.java#Downcall-FF > 00:02:27 Passed: java/foreign/TestMatrix.java#Downcall-TF > 00:03:03 Passed: java/foreign/TestMatrix.java#Downcall-FT > 00:03:47 Passed: java/foreign/TestMatrix.java#Downcall-TT > 00:04:17 Passed: java/foreign/TestMatrix.java#Upcall-FTFF > 00:04:23 Passed: java/foreign/TestMatrix.java#Upcall-TFFF > 00:05:46 Passed: java/foreign/TestMatrix.java#Upcall-TTFF > 00:06:03 Passed: java/foreign/TestMatrix.java#Upcall-TFFT > 00:06:44 Passed: java/foreign/TestMatrix.java#Upcall-FTFT > 00:08:24 Passed: java/foreign/TestMatrix.java#Upcall-TFTF > 00:08:39 Passed: java/foreign/TestMatrix.java#Upcall-TTFT > 00:09:16 Passed: java/foreign/TestMatrix.java#Upcall-FTTF > 00:09:19 Passed: java/foreign/TestMatrix.java#Upcall-TFTT > 00:10:01 Passed: java/foreign/TestMatrix.java#Upcall-FTTT > 00:10:37 Passed: java/foreign/TestMatrix.java#Upcall-TTTF > 00:12:16 Passed: java/foreign/TestMatrix.java#Upcall-TTTT > 00:12:17 Test results: passed: 32 > 00:12:21 > 00:12:21 ============================== > 00:12:21 Test summary > 00:12:21 ============================== > 00:12:21 TEST TOTAL PASS FAIL ERROR > 00:12:21 jtreg:test/jdk/java/foreign/TestMatrix.java 32 32 0 0 > 00:12:21 ============================== > > real 12m20.538s > user 131m54.043s > sys 0m59.944s > > > If we don't parallelize, then those 130 minutes are spent serially. So, what is the policy for defining developers tests that are not meant to be ran on every build infra, but are meant to be run on a more casual basis by developers working in a particular area? When we added TestMatrix we made sure to exclude it from the relevant groups. I suspect other tests might have followed the same approach. But if we have a test that automatically catches all excluded tests, and folks start running this "excluded tests" group by default, what are developers supposed to do? I guess there's a reason why tests might not have been included in a tier. Defining a blanket rule which re-adds all excluded tests seems like a questionable move to me. Surely in the future, keeping this in mind, developers will probably refrain from pushing these tests to OpenJDK altogether, and store them somewhere private - which doesn't seem great. So, I understand you have a fix which parallelize the test execution (great!), but it seems like we're talking past each other a bit, in the sense that you (or any other) should have never picked up this test in an automatic test run in the first place. Also, execution time is part of the picture, albeit the most visible one, since it causes timeouts and failures. But what about CPU cycles? Sure, if we parallelize, we can get better execution time - but you still end up wasting CPU cycles on a test which you are not meant to run in the first place. Is this the right thing to do? I believe that, ultimately, this is a (test) policy issue, which should be discussed accordingly in an OpenJDK mailing list. ------------- PR: https://git.openjdk.java.net/jdk/pull/5358 From rriggs at openjdk.java.net Tue Sep 7 14:50:37 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 7 Sep 2021 14:50:37 GMT Subject: RFR: 8273435: Remove redundant zero-length check in ClassDesc.of In-Reply-To: References: Message-ID: On Wed, 18 Aug 2021 07:28:57 GMT, Andrey Turbanov wrote: > After [JDK-8215510](https://bugs.openjdk.java.net/browse/JDK-8215510) (eed3a536c0) this condition is always `false`. Empty package name is handled separately. > Found by IntelliJ inspection. Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5157 From shade at openjdk.java.net Tue Sep 7 14:54:35 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 7 Sep 2021 14:54:35 GMT Subject: RFR: 8273315: Parallelize and increase timeouts for java/foreign/TestMatrix.java test In-Reply-To: <1N5hqV0rUqqW9nUrybIvgKXqwhkxF8cdDBazG-hbsaM=.2aef9aa9-755b-47fa-88f7-8bceda08a498@github.com> References: <1N5hqV0rUqqW9nUrybIvgKXqwhkxF8cdDBazG-hbsaM=.2aef9aa9-755b-47fa-88f7-8bceda08a498@github.com> Message-ID: On Tue, 7 Sep 2021 14:30:41 GMT, Maurizio Cimadamore wrote: > So, what is the policy for defining developers tests that are not meant to be ran on every build infra, but are meant to be run on a more casual basis by developers working in a particular area? When we added TestMatrix we made sure to exclude it from the relevant groups. Honestly, I don't know. Maybe there is some jtreg keyword that gates the automatic execution? From the jtreg perspective, either automatic system or human invocation must look the same, so it has to be some external input. Personally, I was always under impression that if I add a regression test to the source tree, somebody would eventually run it. Hotspot even has the catch-all `hotspot_all` test group for this. JDK does not have a catch-all test group, but I would not be surprised if such test group existed. > So, I understand you have a fix which parallelize the test execution (great!), but it seems like we're talking past each other a bit, in the sense that you (or any other) should have never picked up this test in an automatic test run in the first place. Right. But I don't think the test execution policy discussion is that relevant for the test improvement in question. Do we want those who *do* run this test manually/occasionally enjoy the improved run time due to better parallelism? If so, please consider this PR on this merit alone. ------------- PR: https://git.openjdk.java.net/jdk/pull/5358 From roger.riggs at oracle.com Tue Sep 7 15:05:27 2021 From: roger.riggs at oracle.com (Roger Riggs) Date: Tue, 7 Sep 2021 11:05:27 -0400 Subject: RFR: 8231640: (prop) Canonical property storage In-Reply-To: References: <0851283f-23f6-a8e6-03c5-d98d29770dbc@oracle.com> Message-ID: Hi, The value of SOURCE_DATE_EPOCH is not so sensitive that it needs the protections you are applying. The doPriv only exposes the value of that specific environment variable and in the usual case, it is undefined. The complexity in the specification and implementation seem unnecessary in this case. Though java.util.Date is used in the current implementation, its use is discouraged in new code in favor of java.time.ZonedDateTime. Consider if java.time.format.DateTimeFormatter.RFC_1123_DATE_TIME can be used to parse and format the time. Thanks, Roger On 9/5/21 8:31 AM, Jaikiran Pai wrote: > Hello Alan, > > On 05/09/21 1:46 pm, Alan Bateman wrote: >> On 04/09/2021 16:50, Jaikiran Pai wrote: >>> The commit in this PR implements the proposal for enhancement that >>> was discussed in the core-libs-dev mailing list recently[1], for >>> https://bugs.openjdk.java.net/browse/JDK-8231640 >>> >>> At a high level - the `store()` APIs in `Properties` have been >>> modified to now look for the `SOURCE_DATE_EPOCH` environment >>> variable[2]. If that env variable is set, then instead of writing >>> out the current date time as a date comment, the `store()` APIs >>> instead will use the value set for this env variable to parse it to >>> a `Date` and write out the string form of such a date. The >>> implementation here uses the `d MMM yyyy HH:mm:ss 'GMT'` date format >>> and `Locale.ROOT` to format and write out such a date. This should >>> provide reproducibility whenever the `SOURCE_DATE_EPOCH` is set. >>> Furthermore, intentionally, no changes in the date format of the >>> "current date" have been done. >>> >>> These? modified `store()` APIs work in the presence of the >>> `SecurityManager` too. The caller is expected to have a read >>> permission on the `SOURCE_DATE_EPOCH` environment variable. If the >>> caller doesn't have that permission, then the implementation of >>> these `store()` APIs will write out the "current date" and will >>> ignore any value that has been set for the `SOURCE_DATE_EPOCH` env >>> variable. This should allow for backward compatibility of existing >>> applications, where, when they run under a `SecurityManager` and >>> perhaps with an existing restrictive policy file, the presence of >>> `SOURCE_DATE_EPOCH` shouldn't impact their calls to the `store()` APIs. >>> >>> The modified `store()` APIs will also ignore any value for >>> `SOURCE_DATE_EPOCH` that? cannot be parsed to an `long` value. In >>> such cases, the `store()` APIs will write out the "current date" and >>> ignore the value set for this environment variable. No exceptions >>> will be thrown for such invalid values. This is an additional >>> backward compatibility precaution to prevent any rogue value for >>> `SOURCE_DATE_EPOCH` from breaking applications. >> In the discussion on this option then I think we were talking about >> changing the specification of the store methods to allow for an >> implementation specific means to override the date and put the >> discussion on SOURCE_DATE_EPOCH in an @implNote. >> > I will move the updated javadoc to an @implNote then. I guess, the > existing part where it explains how the current date comment is > written out, should stay where it is currently? > > >> The SM case probably needs discussion as I was expecting to see >> something like this: >> >> PrivilegedAction pa = () -> System.getenv("SOURCE_DATE_EPOCH"); >> String value = AccessController.doPrivileged(pa); >> >> as a caller of the store method (in a library for example) is >> unlikely to have this permission. I assume your concern is that >> untrusted code would have a way to read this specific env variable >> without a permission (by way of creating and storing an empty >> Properties)?? In this case I'm mostly wondering if it's really worth >> having a behavior difference in this mode. > > I had initially started off with using a doPrivileged code in this > change. However, I soon realized that it might be a security hole, > like in the example you state. Unlike other parts of the JDK code > where the doPrivileged makes sense, since the "action" part of it does > things that are internal implementation details to the JDK, this new > piece of code that we are introducing, does a System.getenv(...) in > its "action" but will then additionally hand out the value (in a > formatted manner of course) of that environment variable to the > callers, through the OutputStream/Writer instances that the callers > pass in to the store() APIs. Effectively, this means that even when > getenv.SOURCE_DATE_EPOCH (or getenv.* for that matter) haven't been > granted to the callers, they will _always_ be able to get hold of that > environment variable's value through this approach. Like you state, > they could just call Properties.store() (which by the way, doesn't > necessarily have to be empty) to bypass the security checks that are > put in place for the direct System.getenv(...) calls from their code. > > In such a doPrivelged case, the only way the administrator can prevent > this security bypass, would then be to _not_ grant this permission to > the JDK code itself, which then effectively means that this > enhancement for using SOURCE_DATE_EPOCH will not take effect at all > and the date comment will always write out the current date. > > So the doPriveleged case, IMO, will not allow selective granting of > permissions to callers. The alternate approach that's used in this PR, > on the other hand allows for selective granting of permissions. I'm > not too aware of how things stand with the application server and > security manager integration these days, but I would guess that in > such use cases where you probably would want to control which deployed > applications (within the same JVM) are granted what permissions, this > alternate approach of not using the doPriveleged would make it > feasible to control these permissions. > > -Jaikiran > From jai.forums2013 at gmail.com Tue Sep 7 15:27:31 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Tue, 7 Sep 2021 20:57:31 +0530 Subject: RFR: 8231640: (prop) Canonical property storage In-Reply-To: References: <0851283f-23f6-a8e6-03c5-d98d29770dbc@oracle.com> Message-ID: <9d26e9cf-f012-564d-7397-445bc2105b92@gmail.com> On 07/09/21 8:35 pm, Roger Riggs wrote: > Hi, > > The value of SOURCE_DATE_EPOCH is not so sensitive that it needs the > protections you are applying. > The doPriv only exposes the value of that specific environment > variable and in the usual case, it is undefined. > > The complexity in the specification and implementation seem > unnecessary in this case. Given the inputs so far, the doPriveleged approach appears to be acceptable. So I'll go ahead and update the PR shortly to change this part. > > Though java.util.Date is used in the current implementation, its use > is discouraged in new code > in favor of java.time.ZonedDateTime. > Consider if java.time.format.DateTimeFormatter.RFC_1123_DATE_TIME can > be used to parse and format the time. Noted. I'll take a look at these and update the PR as necessary. Thank you all for the inputs so far. -Jaikiran From Alan.Bateman at oracle.com Tue Sep 7 15:32:01 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 7 Sep 2021 16:32:01 +0100 Subject: RFR: 8231640: (prop) Canonical property storage In-Reply-To: References: <0851283f-23f6-a8e6-03c5-d98d29770dbc@oracle.com> Message-ID: <1d66a1eb-7ee6-eabf-751d-9940a6ef4a7b@oracle.com> On 07/09/2021 16:05, Roger Riggs wrote: > Hi, > > The value of SOURCE_DATE_EPOCH is not so sensitive that it needs the > protections you are applying. > The doPriv only exposes the value of that specific environment > variable and in the usual case, it is undefined. > > The complexity in the specification and implementation seem > unnecessary in this case. I agree.? Given the complexity then it makes your suggestion/option to just drop the date from the comment somewhat tempting. -Alan From mcimadamore at openjdk.java.net Tue Sep 7 15:31:37 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 7 Sep 2021 15:31:37 GMT Subject: RFR: 8273315: Parallelize and increase timeouts for java/foreign/TestMatrix.java test In-Reply-To: References: Message-ID: <9U46SyO2BMIePSHZiMyqnENK2w_odsV3SR2ZJUFAi-w=.f19f7ab3-4c6a-4cad-bfd0-09baadea95c2@github.com> On Fri, 3 Sep 2021 09:53:53 GMT, Aleksey Shipilev wrote: > This test runs a lot of configurations, and spends a lot of time serially. This is especially pronounced when run in prospective tier4 runs (JDK-8273314). There are reports of multi-hour runs (see JDK-8271613). We can parallelize the test configurations for this test to make it hurt less. Also, timeouts need to be increased for `TestUpcall` test configs, because some of them are very slow in fastdebug mode. > > Sample run: > > > $ time CONF=linux-x86_64-server-fastdebug make run-test TEST=java/foreign/TestMatrix.java | ts -s > 00:00:00 Building target 'run-test' in configuration 'linux-x86_64-server-fastdebug' > 00:00:03 Test selection 'java/foreign/TestMatrix.java', will run: > 00:00:03 * jtreg:test/jdk/java/foreign/TestMatrix.java > 00:00:03 > 00:00:03 Running test 'jtreg:test/jdk/java/foreign/TestMatrix.java' > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TTFT > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FFFF > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FFTF > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TTTT > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FTTT > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FFTT > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FFFT > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TTTF > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FTTF > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TFFT > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TFTF > 00:00:32 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TFFF > 00:00:32 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FTFF > 00:00:35 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TFTT > 00:00:35 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TTFF > 00:00:38 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FTFT > 00:01:50 Passed: java/foreign/TestMatrix.java#Downcall-FF > 00:02:27 Passed: java/foreign/TestMatrix.java#Downcall-TF > 00:03:03 Passed: java/foreign/TestMatrix.java#Downcall-FT > 00:03:47 Passed: java/foreign/TestMatrix.java#Downcall-TT > 00:04:17 Passed: java/foreign/TestMatrix.java#Upcall-FTFF > 00:04:23 Passed: java/foreign/TestMatrix.java#Upcall-TFFF > 00:05:46 Passed: java/foreign/TestMatrix.java#Upcall-TTFF > 00:06:03 Passed: java/foreign/TestMatrix.java#Upcall-TFFT > 00:06:44 Passed: java/foreign/TestMatrix.java#Upcall-FTFT > 00:08:24 Passed: java/foreign/TestMatrix.java#Upcall-TFTF > 00:08:39 Passed: java/foreign/TestMatrix.java#Upcall-TTFT > 00:09:16 Passed: java/foreign/TestMatrix.java#Upcall-FTTF > 00:09:19 Passed: java/foreign/TestMatrix.java#Upcall-TFTT > 00:10:01 Passed: java/foreign/TestMatrix.java#Upcall-FTTT > 00:10:37 Passed: java/foreign/TestMatrix.java#Upcall-TTTF > 00:12:16 Passed: java/foreign/TestMatrix.java#Upcall-TTTT > 00:12:17 Test results: passed: 32 > 00:12:21 > 00:12:21 ============================== > 00:12:21 Test summary > 00:12:21 ============================== > 00:12:21 TEST TOTAL PASS FAIL ERROR > 00:12:21 jtreg:test/jdk/java/foreign/TestMatrix.java 32 32 0 0 > 00:12:21 ============================== > > real 12m20.538s > user 131m54.043s > sys 0m59.944s > > > If we don't parallelize, then those 130 minutes are spent serially. test/jdk/java/foreign/TestMatrix.java line 7: > 5: * @build NativeTestHelper CallGeneratorHelper TestUpcallHighArity > 6: * > 7: * @run testng/othervm/native can you please throw in a `/manual` in here as well - so that this test will be disabled when running tests with jtreg `-a` option (which should be the norm in headless mode). ------------- PR: https://git.openjdk.java.net/jdk/pull/5358 From shade at openjdk.java.net Tue Sep 7 15:56:37 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 7 Sep 2021 15:56:37 GMT Subject: RFR: 8273315: Parallelize and increase timeouts for java/foreign/TestMatrix.java test In-Reply-To: <9U46SyO2BMIePSHZiMyqnENK2w_odsV3SR2ZJUFAi-w=.f19f7ab3-4c6a-4cad-bfd0-09baadea95c2@github.com> References: <9U46SyO2BMIePSHZiMyqnENK2w_odsV3SR2ZJUFAi-w=.f19f7ab3-4c6a-4cad-bfd0-09baadea95c2@github.com> Message-ID: <6Wm9vUTm7_fbT69UFSx8iENWjQe2UZsZBmut8_Ap6yM=.e1bcff98-19f3-4bf2-9d41-27076107aa42@github.com> On Tue, 7 Sep 2021 15:04:31 GMT, Maurizio Cimadamore wrote: >> This test runs a lot of configurations, and spends a lot of time serially. This is especially pronounced when run in prospective tier4 runs (JDK-8273314). There are reports of multi-hour runs (see JDK-8271613). We can parallelize the test configurations for this test to make it hurt less. Also, timeouts need to be increased for `TestUpcall` test configs, because some of them are very slow in fastdebug mode. >> >> Sample run: >> >> >> $ time CONF=linux-x86_64-server-fastdebug make run-test TEST=java/foreign/TestMatrix.java | ts -s >> 00:00:00 Building target 'run-test' in configuration 'linux-x86_64-server-fastdebug' >> 00:00:03 Test selection 'java/foreign/TestMatrix.java', will run: >> 00:00:03 * jtreg:test/jdk/java/foreign/TestMatrix.java >> 00:00:03 >> 00:00:03 Running test 'jtreg:test/jdk/java/foreign/TestMatrix.java' >> 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TTFT >> 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FFFF >> 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FFTF >> 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TTTT >> 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FTTT >> 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FFTT >> 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FFFT >> 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TTTF >> 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FTTF >> 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TFFT >> 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TFTF >> 00:00:32 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TFFF >> 00:00:32 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FTFF >> 00:00:35 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TFTT >> 00:00:35 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TTFF >> 00:00:38 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FTFT >> 00:01:50 Passed: java/foreign/TestMatrix.java#Downcall-FF >> 00:02:27 Passed: java/foreign/TestMatrix.java#Downcall-TF >> 00:03:03 Passed: java/foreign/TestMatrix.java#Downcall-FT >> 00:03:47 Passed: java/foreign/TestMatrix.java#Downcall-TT >> 00:04:17 Passed: java/foreign/TestMatrix.java#Upcall-FTFF >> 00:04:23 Passed: java/foreign/TestMatrix.java#Upcall-TFFF >> 00:05:46 Passed: java/foreign/TestMatrix.java#Upcall-TTFF >> 00:06:03 Passed: java/foreign/TestMatrix.java#Upcall-TFFT >> 00:06:44 Passed: java/foreign/TestMatrix.java#Upcall-FTFT >> 00:08:24 Passed: java/foreign/TestMatrix.java#Upcall-TFTF >> 00:08:39 Passed: java/foreign/TestMatrix.java#Upcall-TTFT >> 00:09:16 Passed: java/foreign/TestMatrix.java#Upcall-FTTF >> 00:09:19 Passed: java/foreign/TestMatrix.java#Upcall-TFTT >> 00:10:01 Passed: java/foreign/TestMatrix.java#Upcall-FTTT >> 00:10:37 Passed: java/foreign/TestMatrix.java#Upcall-TTTF >> 00:12:16 Passed: java/foreign/TestMatrix.java#Upcall-TTTT >> 00:12:17 Test results: passed: 32 >> 00:12:21 >> 00:12:21 ============================== >> 00:12:21 Test summary >> 00:12:21 ============================== >> 00:12:21 TEST TOTAL PASS FAIL ERROR >> 00:12:21 jtreg:test/jdk/java/foreign/TestMatrix.java 32 32 0 0 >> 00:12:21 ============================== >> >> real 12m20.538s >> user 131m54.043s >> sys 0m59.944s >> >> >> If we don't parallelize, then those 130 minutes are spent serially. > > test/jdk/java/foreign/TestMatrix.java line 7: > >> 5: * @build NativeTestHelper CallGeneratorHelper TestUpcallHighArity >> 6: * >> 7: * @run testng/othervm/native > > can you please throw in a `/manual` in here as well - so that this test will be disabled when running tests with jtreg `-a` option (which should be the norm in headless mode). I can, but it seems to me that `/manual` is for marking GUI tests that require user interaction. Let me see if there are keywords we can use. Something like "developer", so that you can pass `jtreg -k:developer` or `JTREG_KEYWORDS=developer make test ...` when you really want to run them. I'll take a closer look tomorrow. ------------- PR: https://git.openjdk.java.net/jdk/pull/5358 From naoto.sato at oracle.com Tue Sep 7 16:15:01 2021 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 7 Sep 2021 09:15:01 -0700 Subject: Suspicious duplicate condition in java.util.regex.Grapheme#isExcludedSpacingMark In-Reply-To: References: Message-ID: <436aac1b-15a1-3f6b-5a66-e213f6c94ce2@oracle.com> It does look incorrect. I will take a look. Naoto On 9/6/21 12:16 AM, Andrey Turbanov wrote: > Hello. > I found suspicious condition in the method > java.util.regex.Grapheme#isExcludedSpacingMark > It's detected by IntelliJ IDEA inspection 'Condition is covered by > further condition' > https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/regex/Grapheme.java#L157 > > ``` > private static boolean isExcludedSpacingMark(int cp) { > return cp == 0x102B || cp == 0x102C || cp == 0x1038 || > cp >= 0x1062 && cp <= 0x1064 || > cp >= 0x1062 && cp <= 0x106D || // <== here is the warning > cp == 0x1083 || > cp >= 0x1087 && cp <= 0x108C || > cp == 0x108F || > cp >= 0x109A && cp <= 0x109C || > cp == 0x1A61 || cp == 0x1A63 || cp == 0x1A64 || > cp == 0xAA7B || cp == 0xAA7D; > } > ``` > There are 2 sub-conditions in this complex condition: > cp >= 0x1062 && cp <= 0x1064 || > cp >= 0x1062 && cp <= 0x106D || > > The second condition is _wider_ than the first one. > I believe it's a bug. The second condition (according to > https://www.compart.com/en/unicode/category/Mc) should look like this: > > cp >= 0x1067 && cp <= 0x106D || > > 0x1065, 0x1066 are not from the Spacing_Mark category. > > > Andrey Turbanov > From naoto at openjdk.java.net Tue Sep 7 16:14:37 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 7 Sep 2021 16:14:37 GMT Subject: RFR: 8269373: some tests in jdk/tools/launcher/ fails on localized Windows platform [v5] In-Reply-To: References: Message-ID: On Tue, 7 Sep 2021 11:26:01 GMT, Masanori Yano wrote: >> Hi all, >> >> Could you please review the 8269373 bug fixes? >> >> These tests call java.lang.ProcessBuilder in direct, so not used jtreg command option. To run non-localized tests, -Duser.language=en and -Duser.country=US options should be added in ProcessBuilder. > > Masanori Yano has updated the pull request incrementally with one additional commit since the last revision: > > 8269373: some tests in jdk/tools/launcher/ fails on localized Windows platform Thanks. Looks good to me. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4594 From lancea at openjdk.java.net Tue Sep 7 16:33:36 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 7 Sep 2021 16:33:36 GMT Subject: RFR: 8273401: Remove JarIndex support in URLClassPath In-Reply-To: References: Message-ID: On Tue, 7 Sep 2021 03:34:27 GMT, wxiang wrote: > There is a bug for URLClassPath.findResources with JarIndex. > With some discussions about the bug, the current priority is to remove the JAR index support in URLClassPath, > and don?t need to do anything to the jar tool in the short term, except just to move JarIndex to the jdk.jartool module. > > The PR includes: > 1. remove the JarIndex support in URLClassPath > 2. move JarIndex into jdk.jartool module. I think this looks good overall. Once you do your next set up updates, I will run it through mach5 for you src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 73: > 71: import static java.util.jar.JarFile.MANIFEST_NAME; > 72: import static java.util.stream.Collectors.joining; > 73: import static java.util.jar.JarFile.INDEX_NAME; Maybe move this above the java.util.streamCollectors.joining import Also, the copyright should probably be updated to 2021 test/jdk/sun/misc/JarIndex/JarIndexMergeTest.java line 25: > 23: > 24: /* > 25: * @test Probably should update the copyright year to include 2021 ------------- PR: https://git.openjdk.java.net/jdk/pull/5383 From lancea at openjdk.java.net Tue Sep 7 16:33:37 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 7 Sep 2021 16:33:37 GMT Subject: RFR: 8273401: Remove JarIndex support in URLClassPath In-Reply-To: References: Message-ID: <10Ivl80m4qzRju-gdlcN6t4CA11U2m-Ngn4U7PnMHnI=.d0d5cd3f-8e52-47a4-9b01-fbfae7c70387@github.com> On Tue, 7 Sep 2021 07:03:20 GMT, Alan Bateman wrote: >> There is a bug for URLClassPath.findResources with JarIndex. >> With some discussions about the bug, the current priority is to remove the JAR index support in URLClassPath, >> and don?t need to do anything to the jar tool in the short term, except just to move JarIndex to the jdk.jartool module. >> >> The PR includes: >> 1. remove the JarIndex support in URLClassPath >> 2. move JarIndex into jdk.jartool module. > > src/java.base/share/classes/java/util/jar/JarFile.java line 220: > >> 218: * The index file name. >> 219: */ >> 220: public static final String INDEX_NAME = "META-INF/INDEX.LIST"; > > Adding this as a public field means it becomes part of the API, so it shouldn't be public here. Agree ------------- PR: https://git.openjdk.java.net/jdk/pull/5383 From mcimadamore at openjdk.java.net Tue Sep 7 16:41:37 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 7 Sep 2021 16:41:37 GMT Subject: RFR: 8273315: Parallelize and increase timeouts for java/foreign/TestMatrix.java test In-Reply-To: <6Wm9vUTm7_fbT69UFSx8iENWjQe2UZsZBmut8_Ap6yM=.e1bcff98-19f3-4bf2-9d41-27076107aa42@github.com> References: <9U46SyO2BMIePSHZiMyqnENK2w_odsV3SR2ZJUFAi-w=.f19f7ab3-4c6a-4cad-bfd0-09baadea95c2@github.com> <6Wm9vUTm7_fbT69UFSx8iENWjQe2UZsZBmut8_Ap6yM=.e1bcff98-19f3-4bf2-9d41-27076107aa42@github.com> Message-ID: <0-qx18WD9qQgjivnYDhCheryPEzDFbyvNjLRMDQTGRQ=.55fcf55f-dbe2-4a22-bf4d-39a3908d25de@github.com> On Tue, 7 Sep 2021 15:53:20 GMT, Aleksey Shipilev wrote: >> test/jdk/java/foreign/TestMatrix.java line 7: >> >>> 5: * @build NativeTestHelper CallGeneratorHelper TestUpcallHighArity >>> 6: * >>> 7: * @run testng/othervm/native >> >> can you please throw in a `/manual` in here as well - so that this test will be disabled when running tests with jtreg `-a` option (which should be the norm in headless mode). > > I can, but it seems to me that `/manual` is for marking GUI tests that require user interaction. Let me see if there are keywords we can use. Something like "developer", so that you can pass `jtreg -k:developer` or `JTREG_KEYWORDS=developer make test ...` when you really want to run them. I'll take a closer look tomorrow. you are right about /manual being for GUI - but @AlanBateman pointed me at few tests with libzip using it for similar reasons (e.g. long running tests). ------------- PR: https://git.openjdk.java.net/jdk/pull/5358 From alanb at openjdk.java.net Tue Sep 7 16:57:36 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 7 Sep 2021 16:57:36 GMT Subject: RFR: 8273315: Parallelize and increase timeouts for java/foreign/TestMatrix.java test In-Reply-To: <0-qx18WD9qQgjivnYDhCheryPEzDFbyvNjLRMDQTGRQ=.55fcf55f-dbe2-4a22-bf4d-39a3908d25de@github.com> References: <9U46SyO2BMIePSHZiMyqnENK2w_odsV3SR2ZJUFAi-w=.f19f7ab3-4c6a-4cad-bfd0-09baadea95c2@github.com> <6Wm9vUTm7_fbT69UFSx8iENWjQe2UZsZBmut8_Ap6yM=.e1bcff98-19f3-4bf2-9d41-27076107aa42@github.com> <0-qx18WD9qQgjivnYDhCheryPEzDFbyvNjLRMDQTGRQ=.55fcf55f-dbe2-4a22-bf4d-39a3908d25de@github.com> Message-ID: On Tue, 7 Sep 2021 16:38:25 GMT, Maurizio Cimadamore wrote: >> I can, but it seems to me that `/manual` is for marking GUI tests that require user interaction. Let me see if there are keywords we can use. Something like "developer", so that you can pass `jtreg -k:developer` or `JTREG_KEYWORDS=developer make test ...` when you really want to run them. I'll take a closer look tomorrow. > > you are right about /manual being for GUI - but @AlanBateman pointed me at few tests with libzip using it for similar reasons (e.g. long running tests). I don't think /manual is strictly UI but its usage is discouraged as manual tests are rarely run. The tests for the SmartCard I/O API come to mind as they need special setup. There is one or two ZIP tests that take a long time and have historically been manual tests as a result. There are also a few tests dotted around that do not have the `@Test` tag, one needs to be working in a specific area to know about these. Introducing a new test group or a keyword for these tests could be an option. In passing, I should mention the jdk_sctp test group. These tests may require kernel or other configuration and are deliberately not in any tier. That may be a comment for the other PR that is proposing a jdk tier4. ------------- PR: https://git.openjdk.java.net/jdk/pull/5358 From mullan at openjdk.java.net Tue Sep 7 17:42:36 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 7 Sep 2021 17:42:36 GMT Subject: RFR: 8273401: Remove JarIndex support in URLClassPath In-Reply-To: References: Message-ID: <7BzvoN6dbVscgZKB3U3epUjjJ_os26_P5pYPH_rysE8=.c1e499b0-dd77-41fd-b044-76942c0f33cb@github.com> On Tue, 7 Sep 2021 07:12:29 GMT, Alan Bateman wrote: >> There is a bug for URLClassPath.findResources with JarIndex. >> With some discussions about the bug, the current priority is to remove the JAR index support in URLClassPath, >> and don?t need to do anything to the jar tool in the short term, except just to move JarIndex to the jdk.jartool module. >> >> The PR includes: >> 1. remove the JarIndex support in URLClassPath >> 2. move JarIndex into jdk.jartool module. > > src/java.base/share/classes/java/util/jar/JarVerifier.java line 147: > >> 145: >> 146: if (uname.equals(JarFile.MANIFEST_NAME) || >> 147: uname.equals(JarFile.INDEX_NAME)) { > > It would be useful if someone from security-libs could comment on this. The interaction between signed JAR and JAR index isn't very clear. The change you have is safe but it might be that we can drop the checking for INDEX.LIST here. I am thinking this line should not be removed for compatibility with existing JARs that have indexes. ------------- PR: https://git.openjdk.java.net/jdk/pull/5383 From github.com+150992+rfscholte at openjdk.java.net Tue Sep 7 17:54:37 2021 From: github.com+150992+rfscholte at openjdk.java.net (Robert Scholte) Date: Tue, 7 Sep 2021 17:54:37 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v2] In-Reply-To: References: Message-ID: On Sat, 4 Sep 2021 18:30:06 GMT, Andrey Turbanov wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> use @implNote to explain the use of the environment variable > > src/java.base/share/classes/java/util/Properties.java line 924: > >> 922: writeDateComment(bw); >> 923: synchronized (this) { >> 924: for (Map.Entry e : new TreeMap<>(map).entrySet()) { > > Is this sorting intentionally added? It's not clear from issue description or PR description that order of properties should be changed too. > Anyway I think copying `entrySet()` to array and then sorting should be faster, than creating a TreeMap In case of reproducibility it should be at least ordered, i.e. keep original input order. ------------- PR: https://git.openjdk.java.net/jdk/pull/5372 From naoto at openjdk.java.net Tue Sep 7 18:26:54 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 7 Sep 2021 18:26:54 GMT Subject: RFR: 8273369: Computing micros between two instants unexpectedly overflows for some cases Message-ID: Please review the fix to the issue. Avoiding overflow by not calling nanosUntil() directly, which will overflow beyond Long.MAX_VALUE difference in nano unit. ------------- Commit messages: - 8273369: Computing micros between two instants unexpectedly overflows for some cases Changes: https://git.openjdk.java.net/jdk/pull/5396/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5396&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273369 Stats: 17 lines in 2 files changed: 15 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5396.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5396/head:pull/5396 PR: https://git.openjdk.java.net/jdk/pull/5396 From lancea at openjdk.java.net Tue Sep 7 18:36:38 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 7 Sep 2021 18:36:38 GMT Subject: RFR: 8273369: Computing micros between two instants unexpectedly overflows for some cases In-Reply-To: References: Message-ID: On Tue, 7 Sep 2021 18:18:49 GMT, Naoto Sato wrote: > Please review the fix to the issue. Avoiding overflow by not calling nanosUntil() directly, which will overflow beyond Long.MAX_VALUE difference in nano unit. Looks OK to me ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5396 From rriggs at openjdk.java.net Tue Sep 7 18:49:42 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 7 Sep 2021 18:49:42 GMT Subject: RFR: 8273369: Computing micros between two instants unexpectedly overflows for some cases In-Reply-To: References: Message-ID: On Tue, 7 Sep 2021 18:18:49 GMT, Naoto Sato wrote: > Please review the fix to the issue. Avoiding overflow by not calling nanosUntil() directly, which will overflow beyond Long.MAX_VALUE difference in nano unit. Marked as reviewed by rriggs (Reviewer). src/java.base/share/classes/java/time/Instant.java line 1170: > 1168: long secsDiff = Math.subtractExact(end.seconds, seconds); > 1169: long totalMicros = Math.multiplyExact(secsDiff, NANOS_PER_SECOND / 1000); > 1170: return Math.addExact(totalMicros, (end.nanos - nanos) / 1000); Can you define NANOS_PER_MICRO, the others conversions use predefined constants. ------------- PR: https://git.openjdk.java.net/jdk/pull/5396 From naoto at openjdk.java.net Tue Sep 7 19:07:02 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 7 Sep 2021 19:07:02 GMT Subject: RFR: 8273369: Computing micros between two instants unexpectedly overflows for some cases [v2] In-Reply-To: References: Message-ID: > Please review the fix to the issue. Avoiding overflow by not calling nanosUntil() directly, which will overflow beyond Long.MAX_VALUE difference in nano unit. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Added a constant for nanos per micro. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5396/files - new: https://git.openjdk.java.net/jdk/pull/5396/files/09d9b257..4b874ff6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5396&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5396&range=00-01 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5396.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5396/head:pull/5396 PR: https://git.openjdk.java.net/jdk/pull/5396 From naoto at openjdk.java.net Tue Sep 7 19:07:03 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 7 Sep 2021 19:07:03 GMT Subject: RFR: 8273369: Computing micros between two instants unexpectedly overflows for some cases [v2] In-Reply-To: References: Message-ID: On Tue, 7 Sep 2021 18:46:56 GMT, Roger Riggs wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Added a constant for nanos per micro. > > src/java.base/share/classes/java/time/Instant.java line 1170: > >> 1168: long secsDiff = Math.subtractExact(end.seconds, seconds); >> 1169: long totalMicros = Math.multiplyExact(secsDiff, NANOS_PER_SECOND / 1000); >> 1170: return Math.addExact(totalMicros, (end.nanos - nanos) / 1000); > > Can you define NANOS_PER_MICRO, the others conversions use predefined constants. Defined it as a private field in `Instant`. ------------- PR: https://git.openjdk.java.net/jdk/pull/5396 From naoto at openjdk.java.net Tue Sep 7 19:21:21 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 7 Sep 2021 19:21:21 GMT Subject: RFR: 8273369: Computing micros between two instants unexpectedly overflows for some cases [v3] In-Reply-To: References: Message-ID: > Please review the fix to the issue. Avoiding overflow by not calling nanosUntil() directly, which will overflow beyond Long.MAX_VALUE difference in nano unit. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Corrected the constant. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5396/files - new: https://git.openjdk.java.net/jdk/pull/5396/files/4b874ff6..7d567e8b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5396&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5396&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5396.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5396/head:pull/5396 PR: https://git.openjdk.java.net/jdk/pull/5396 From rriggs at openjdk.java.net Tue Sep 7 19:32:58 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 7 Sep 2021 19:32:58 GMT Subject: RFR: 8273369: Computing micros between two instants unexpectedly overflows for some cases [v3] In-Reply-To: References: Message-ID: <0tTIxEUl7ZyBUapRk-uTpOYdm_czmz8e95oyRzum9o0=.a8ab2776-28f7-482b-b0ed-067497c3466c@github.com> On Tue, 7 Sep 2021 19:21:21 GMT, Naoto Sato wrote: >> Please review the fix to the issue. Avoiding overflow by not calling nanosUntil() directly, which will overflow beyond Long.MAX_VALUE difference in nano unit. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Corrected the constant. Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5396 From naoto at openjdk.java.net Tue Sep 7 20:29:29 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 7 Sep 2021 20:29:29 GMT Subject: RFR: 8273369: Computing micros between two instants unexpectedly overflows for some cases [v4] In-Reply-To: References: Message-ID: > Please review the fix to the issue. Avoiding overflow by not calling nanosUntil() directly, which will overflow beyond Long.MAX_VALUE difference in nano unit. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Moved the constant to LocalTime for consistency. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5396/files - new: https://git.openjdk.java.net/jdk/pull/5396/files/7d567e8b..bbd6abc3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5396&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5396&range=02-03 Stats: 10 lines in 2 files changed: 5 ins; 4 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5396.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5396/head:pull/5396 PR: https://git.openjdk.java.net/jdk/pull/5396 From rriggs at openjdk.java.net Tue Sep 7 21:15:06 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 7 Sep 2021 21:15:06 GMT Subject: RFR: 8273369: Computing micros between two instants unexpectedly overflows for some cases [v4] In-Reply-To: References: Message-ID: On Tue, 7 Sep 2021 20:29:29 GMT, Naoto Sato wrote: >> Please review the fix to the issue. Avoiding overflow by not calling nanosUntil() directly, which will overflow beyond Long.MAX_VALUE difference in nano unit. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Moved the constant to LocalTime for consistency. Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5396 From naoto at openjdk.java.net Tue Sep 7 21:21:09 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 7 Sep 2021 21:21:09 GMT Subject: RFR: 8273242: (test) Refactor to use TestNG for RuntimeTests ExecCommand tests In-Reply-To: References: Message-ID: On Wed, 1 Sep 2021 16:37:24 GMT, Roger Riggs wrote: > The ExecCommand test of Runtime.exec is difficult to maintain; the parallel arrays are hard to keep in sync. > This cleanup converts to use TestNG DataProviders and other improvements. LGTM. test/jdk/java/lang/RuntimeTests/exec/ExecCommand.java line 270: > 268: } > 269: } > 270: } No newline at the eof. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5335 From sviswanathan at openjdk.java.net Tue Sep 7 22:14:18 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Tue, 7 Sep 2021 22:14:18 GMT Subject: RFR: 8273450: Fix the copyright header of SVML files Message-ID: <6LV8oNP7aMD5JM5Y6v6D_ozDZg9iDsGEaEk9ScN3KSo=.fea8fb4b-fac7-437a-b6c2-7235c5a589ab@github.com> Fix the copyright header of SVML files to match others. This was brought up on jdk-dev mailing list: https://mail.openjdk.java.net/pipermail/jdk-dev/2021-September/005992.html ------------- Commit messages: - 8273450: Fix the copyright header of SVML file Changes: https://git.openjdk.java.net/jdk/pull/5399/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5399&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273450 Stats: 288 lines in 72 files changed: 144 ins; 0 del; 144 mod Patch: https://git.openjdk.java.net/jdk/pull/5399.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5399/head:pull/5399 PR: https://git.openjdk.java.net/jdk/pull/5399 From lancea at openjdk.java.net Tue Sep 7 22:15:11 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 7 Sep 2021 22:15:11 GMT Subject: RFR: 8273242: (test) Refactor to use TestNG for RuntimeTests ExecCommand tests In-Reply-To: References: Message-ID: On Wed, 1 Sep 2021 16:37:24 GMT, Roger Riggs wrote: > The ExecCommand test of Runtime.exec is difficult to maintain; the parallel arrays are hard to keep in sync. > This cleanup converts to use TestNG DataProviders and other improvements. Looks good Roger. A couple trivial questions/suggestions below but feel free to ignore :-) test/jdk/java/lang/RuntimeTests/exec/ExecCommand.java line 107: > 105: private static void deleteOut(String path) { > 106: try { > 107: Files.delete(FileSystems.getDefault().getPath(path)); More of a curious question, is there a reason you couldn't use Files::deleteIfExists or Path.of() instead of FileSystems.getDefault.... test/jdk/java/lang/RuntimeTests/exec/ExecCommand.java line 199: > 197: System.setSecurityManager(null); > 198: > 199: testCommandMode(command, "Ambiguous Unset", testFile, perModeExpected.get(0)); Any thought to creating a constant for the index value for perModeExpected.get(XX) for extra clarity? ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5335 From msheppar at openjdk.java.net Tue Sep 7 22:21:14 2021 From: msheppar at openjdk.java.net (Mark Sheppard) Date: Tue, 7 Sep 2021 22:21:14 GMT Subject: Integrated: JDK-8273246 Amend the test java/nio/channels/DatagramChannel/ManySourcesAndTargets.java to execute in othervm mode In-Reply-To: References: Message-ID: On Fri, 3 Sep 2021 20:32:20 GMT, Mark Sheppard wrote: > A number of nio DatagramChannel tests are intermittently failing on macosx-aarch64. > In some instances this is a receive call blocking indefinitely waiting on data which has > already been sent, and should be available immediately to the receive method call. > Other test failure scenarios are problems during the test compilation phase with a SocketException being thrown and the message: > "test result: Error. Agent communication error: java.net.SocketException: No buffer space available; check console log for any additional details" > > The ManySourcesAndTargets and other tests execute in agentvm mode. This results in certain test diagnostic > Output being lost during the test failure handling capture process. To mitigate this lost diagnostics, the > ManySourcesAndTargets test has been amended to execute in othervm mode. > > Additionally, to assist in the buffer allocation issue, the netstat command executed by the test > failure_handler has an extra argument added to obtain additional details on mbuf usage. > The failure handler will now execute with netstat -mm This pull request has now been integrated. Changeset: d6d6c069 Author: Mark Sheppard URL: https://git.openjdk.java.net/jdk/commit/d6d6c0692bff77bd18127ed61455aac39370a089 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod 8273246: Amend the test java/nio/channels/DatagramChannel/ManySourcesAndTargets.java to execute in othervm mode Reviewed-by: alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/5366 From dholmes at openjdk.java.net Tue Sep 7 23:11:06 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 7 Sep 2021 23:11:06 GMT Subject: RFR: 8273450: Fix the copyright header of SVML files In-Reply-To: <6LV8oNP7aMD5JM5Y6v6D_ozDZg9iDsGEaEk9ScN3KSo=.fea8fb4b-fac7-437a-b6c2-7235c5a589ab@github.com> References: <6LV8oNP7aMD5JM5Y6v6D_ozDZg9iDsGEaEk9ScN3KSo=.fea8fb4b-fac7-437a-b6c2-7235c5a589ab@github.com> Message-ID: On Tue, 7 Sep 2021 20:25:25 GMT, Sandhya Viswanathan wrote: > Fix the copyright header of SVML files to match others. > > This was brought up on jdk-dev mailing list: > https://mail.openjdk.java.net/pipermail/jdk-dev/2021-September/005992.html Hi Sandhya, You must not change another company's copyright line, so "All rights reserved" needs to be removed again. Thanks, David ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5399 From sviswanathan at openjdk.java.net Tue Sep 7 23:23:07 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Tue, 7 Sep 2021 23:23:07 GMT Subject: RFR: 8273450: Fix the copyright header of SVML files In-Reply-To: References: <6LV8oNP7aMD5JM5Y6v6D_ozDZg9iDsGEaEk9ScN3KSo=.fea8fb4b-fac7-437a-b6c2-7235c5a589ab@github.com> Message-ID: <_SbgIjgVjyLG5q--nX3kXenaeMys3NPbz49Eu_QQBVY=.db477d3e-0b94-4542-89ba-50ce2fa8a5d4@github.com> On Tue, 7 Sep 2021 23:08:08 GMT, David Holmes wrote: >> Fix the copyright header of SVML files to match others. >> >> This was brought up on jdk-dev mailing list: >> https://mail.openjdk.java.net/pipermail/jdk-dev/2021-September/005992.html > > Hi Sandhya, > > You must not change another company's copyright line, so "All rights reserved" needs to be removed again. > > Thanks, > David @dholmes-ora I am from Intel so editing the Intel copyright line should be ok? ------------- PR: https://git.openjdk.java.net/jdk/pull/5399 From dholmes at openjdk.java.net Tue Sep 7 23:45:09 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 7 Sep 2021 23:45:09 GMT Subject: RFR: 8273450: Fix the copyright header of SVML files In-Reply-To: <6LV8oNP7aMD5JM5Y6v6D_ozDZg9iDsGEaEk9ScN3KSo=.fea8fb4b-fac7-437a-b6c2-7235c5a589ab@github.com> References: <6LV8oNP7aMD5JM5Y6v6D_ozDZg9iDsGEaEk9ScN3KSo=.fea8fb4b-fac7-437a-b6c2-7235c5a589ab@github.com> Message-ID: <21HgRpRuw1RsrpzAUjeeZEUMq1r-UQtg6ZCuFxBqeI0=.01562841-5453-4d0c-82ee-8c0dffc0105d@github.com> On Tue, 7 Sep 2021 20:25:25 GMT, Sandhya Viswanathan wrote: > Fix the copyright header of SVML files to match others. > > This was brought up on jdk-dev mailing list: > https://mail.openjdk.java.net/pipermail/jdk-dev/2021-September/005992.html Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5399 From dholmes at openjdk.java.net Tue Sep 7 23:45:09 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 7 Sep 2021 23:45:09 GMT Subject: RFR: 8273450: Fix the copyright header of SVML files In-Reply-To: <_SbgIjgVjyLG5q--nX3kXenaeMys3NPbz49Eu_QQBVY=.db477d3e-0b94-4542-89ba-50ce2fa8a5d4@github.com> References: <6LV8oNP7aMD5JM5Y6v6D_ozDZg9iDsGEaEk9ScN3KSo=.fea8fb4b-fac7-437a-b6c2-7235c5a589ab@github.com> <_SbgIjgVjyLG5q--nX3kXenaeMys3NPbz49Eu_QQBVY=.db477d3e-0b94-4542-89ba-50ce2fa8a5d4@github.com> Message-ID: <86OxvWHqUGRANL7cam2F3GXSMkdt4vuQTJoS0brcuis=.07e24fe6-8130-4d17-ae27-1eff2ec4e473@github.com> On Tue, 7 Sep 2021 23:19:37 GMT, Sandhya Viswanathan wrote: >> Hi Sandhya, >> >> You must not change another company's copyright line, so "All rights reserved" needs to be removed again. >> >> Thanks, >> David > > @dholmes-ora I am from Intel so editing the Intel copyright line should be ok? @sviswa7 My apologies, I hadn't realized you worked for Intel. But note that other Intel files i.e. ./hotspot/cpu/x86/macroAssembler_x86_*.cpp also do not have "All rights reserved". David ------------- PR: https://git.openjdk.java.net/jdk/pull/5399 From joehw at openjdk.java.net Tue Sep 7 23:51:04 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Tue, 7 Sep 2021 23:51:04 GMT Subject: RFR: 8273278: Support XSLT on GraalVM Native Image--deterministic bytecode generation in XSLT In-Reply-To: References: Message-ID: <4sZabPrMuzMcYWhExyMqqljO_ua_LLasEvYE5HcKLWE=.347c45df-b863-45f4-b8a7-dbdbbf3e0c4c@github.com> On Wed, 1 Sep 2021 13:28:34 GMT, Jovan Stevanovic wrote: > GraalVM Native Image supports loading classes at runtime if they are known during image build (class predefinition). This is achieved by the JVMTI agent that registers dynamically generated classes in a regular HotSpot run. The Native Image build uses these registered classes to embed them into the produced binary so they can be loaded at runtime. Loading at runtime is achieved by matching the unique hash of generated classes. > > If the generated bytecode is unstable across runs, the generated native image can not match the hash of the runtime-generated bytecode to the pre-defined classes. The execution failure happens here: > https://github.com/oracle/graal/blob/master/substratevm/src/com.oracle.svm.core/src/com/oracle/svm/core/hub/PredefinedClassesSupport.java#L127-L131. > > In XSLT the produced bytecode is unstable for the following reasons: > > - Methods like ` HashMap#values` and `HashMap#keySet` result in different traversal orders of its elements yielding a different order of methods and fields. > > - The default `Object#toString` includes the current memory reference of `com.sun.org.apache.xalan.internal.xsltc.compiler.Number` in the generated class. Yeah, there hasn't been any major activities (i.e. a minor release) for 7 years. It's also true that the JDK has diverged. ------------- PR: https://git.openjdk.java.net/jdk/pull/5331 From joehw at openjdk.java.net Wed Sep 8 00:19:09 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Wed, 8 Sep 2021 00:19:09 GMT Subject: RFR: 8273369: Computing micros between two instants unexpectedly overflows for some cases [v4] In-Reply-To: References: Message-ID: On Tue, 7 Sep 2021 20:29:29 GMT, Naoto Sato wrote: >> Please review the fix to the issue. Avoiding overflow by not calling nanosUntil() directly, which will overflow beyond Long.MAX_VALUE difference in nano unit. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Moved the constant to LocalTime for consistency. Marked as reviewed by joehw (Reviewer). test/jdk/java/time/test/java/time/TestInstant.java line 102: > 100: > 101: @Test > 102: public void test_microsUntil() { A comment about the test might be helpful. ------------- PR: https://git.openjdk.java.net/jdk/pull/5396 From dholmes at openjdk.java.net Wed Sep 8 00:19:10 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 8 Sep 2021 00:19:10 GMT Subject: RFR: 8273314: Add tier4 test groups [v3] In-Reply-To: References: <6rDioD5KZREYHyzOXol72O0erNDqKHUqb-0k1SwhInA=.90a12492-9e2f-4f0c-bf09-8d67d1d6111f@github.com> Message-ID: On Mon, 6 Sep 2021 13:22:03 GMT, Aleksey Shipilev wrote: >> During the review of JDK-8272914 that added hotspot:tier{2,3} groups, @iignatev suggested to create tier4 groups that capture all tests not in tiers{1,2,3}. I have excluded `vmTestbase` and `hotspot:tier4,` because they take 10+ hours on my highly parallel machine. I have also excluded `applications` from `hotspot:tier4`, because they require test dependencies (e.g. jcstress). >> >> Sample run: >> >> >> ============================== >> Test summary >> ============================== >> TEST TOTAL PASS FAIL ERROR >>>> jtreg:test/hotspot/jtreg:tier4 426 425 1 0 << >>>> jtreg:test/jdk:tier4 2891 2885 4 2 << >> jtreg:test/langtools:tier4 0 0 0 0 >> jtreg:test/jaxp:tier4 0 0 0 0 >> ============================== >> >> real 64m13.994s >> user 1462m1.213s >> sys 39m38.032s >> >> >> There are interesting test failures on my machine, which I would address separately. > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Drop applications and fix the comment Hi Aleksey, I've discussed this with Igor and while I don't agree with the rationale I won't "block it". Cheers, David ------------- PR: https://git.openjdk.java.net/jdk/pull/5357 From joehw at openjdk.java.net Wed Sep 8 00:21:10 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Wed, 8 Sep 2021 00:21:10 GMT Subject: RFR: 8273278: Support XSLT on GraalVM Native Image--deterministic bytecode generation in XSLT In-Reply-To: References: Message-ID: On Wed, 1 Sep 2021 13:28:34 GMT, Jovan Stevanovic wrote: > GraalVM Native Image supports loading classes at runtime if they are known during image build (class predefinition). This is achieved by the JVMTI agent that registers dynamically generated classes in a regular HotSpot run. The Native Image build uses these registered classes to embed them into the produced binary so they can be loaded at runtime. Loading at runtime is achieved by matching the unique hash of generated classes. > > If the generated bytecode is unstable across runs, the generated native image can not match the hash of the runtime-generated bytecode to the pre-defined classes. The execution failure happens here: > https://github.com/oracle/graal/blob/master/substratevm/src/com.oracle.svm.core/src/com/oracle/svm/core/hub/PredefinedClassesSupport.java#L127-L131. > > In XSLT the produced bytecode is unstable for the following reasons: > > - Methods like ` HashMap#values` and `HashMap#keySet` result in different traversal orders of its elements yielding a different order of methods and fields. > > - The default `Object#toString` includes the current memory reference of `com.sun.org.apache.xalan.internal.xsltc.compiler.Number` in the generated class. Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5331 From naoto at openjdk.java.net Wed Sep 8 00:36:29 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 8 Sep 2021 00:36:29 GMT Subject: RFR: 8273369: Computing micros between two instants unexpectedly overflows for some cases [v5] In-Reply-To: References: Message-ID: <32V0J7ABPauaU7rNH2bLtWokVqg54qHMyTr94orkbqI=.15a84693-5a1e-4699-85fa-d4eb33c68b20@github.com> > Please review the fix to the issue. Avoiding overflow by not calling nanosUntil() directly, which will overflow beyond Long.MAX_VALUE difference in nano unit. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Added comments for the test. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5396/files - new: https://git.openjdk.java.net/jdk/pull/5396/files/bbd6abc3..ccf73bf7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5396&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5396&range=03-04 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5396.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5396/head:pull/5396 PR: https://git.openjdk.java.net/jdk/pull/5396 From naoto at openjdk.java.net Wed Sep 8 00:36:30 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 8 Sep 2021 00:36:30 GMT Subject: RFR: 8273369: Computing micros between two instants unexpectedly overflows for some cases [v4] In-Reply-To: References: Message-ID: On Wed, 8 Sep 2021 00:15:46 GMT, Joe Wang wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Moved the constant to LocalTime for consistency. > > test/jdk/java/time/test/java/time/TestInstant.java line 102: > >> 100: >> 101: @Test >> 102: public void test_microsUntil() { > > A comment about the test might be helpful. Indeed. Added some comments to the test. ------------- PR: https://git.openjdk.java.net/jdk/pull/5396 From naoto at openjdk.java.net Wed Sep 8 00:37:41 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 8 Sep 2021 00:37:41 GMT Subject: RFR: 8273259: Character.getName doesn't follow Unicode spec for ideographs [v2] In-Reply-To: <3ZOCioU8lMEPuWdaYlBv8L6oNdIwVjwZpPbKLWwkOjs=.0e8939c8-9cff-4600-a869-9c5f137fd2e5@github.com> References: <3ZOCioU8lMEPuWdaYlBv8L6oNdIwVjwZpPbKLWwkOjs=.0e8939c8-9cff-4600-a869-9c5f137fd2e5@github.com> Message-ID: > Simple spec clarification. A CSR has also been drafted (https://bugs.openjdk.java.net/browse/JDK-8273296). Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Refined wordings. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5354/files - new: https://git.openjdk.java.net/jdk/pull/5354/files/294e3d72..dc36e741 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5354&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5354&range=00-01 Stats: 10 lines in 1 file changed: 4 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/5354.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5354/head:pull/5354 PR: https://git.openjdk.java.net/jdk/pull/5354 From sviswanathan at openjdk.java.net Wed Sep 8 00:46:09 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Wed, 8 Sep 2021 00:46:09 GMT Subject: RFR: 8273450: Fix the copyright header of SVML files In-Reply-To: <86OxvWHqUGRANL7cam2F3GXSMkdt4vuQTJoS0brcuis=.07e24fe6-8130-4d17-ae27-1eff2ec4e473@github.com> References: <6LV8oNP7aMD5JM5Y6v6D_ozDZg9iDsGEaEk9ScN3KSo=.fea8fb4b-fac7-437a-b6c2-7235c5a589ab@github.com> <_SbgIjgVjyLG5q--nX3kXenaeMys3NPbz49Eu_QQBVY=.db477d3e-0b94-4542-89ba-50ce2fa8a5d4@github.com> <86OxvWHqUGRANL7cam2F3GXSMkdt4vuQTJoS0brcuis=.07e24fe6-8130-4d17-ae27-1eff2ec4e473@github.com> Message-ID: On Tue, 7 Sep 2021 23:39:54 GMT, David Holmes wrote: >> @dholmes-ora I am from Intel so editing the Intel copyright line should be ok? > > @sviswa7 My apologies, I hadn't realized you worked for Intel. But note that other Intel files i.e. ./hotspot/cpu/x86/macroAssembler_x86_*.cpp also do not have "All rights reserved". > > David Thanks a lot @dholmes-ora for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/5399 From smarks at openjdk.java.net Wed Sep 8 00:58:08 2021 From: smarks at openjdk.java.net (Stuart Marks) Date: Wed, 8 Sep 2021 00:58:08 GMT Subject: RFR: 8078641: MethodHandle.asTypeCache can retain classes from unloading [v4] In-Reply-To: References: Message-ID: On Fri, 3 Sep 2021 14:41:45 GMT, Vladimir Ivanov wrote: >> `MethodHandle.asTypeCache` keeps a strong reference to adapted `MethodHandle` and it can introduce a class loader leak through its `MethodType`. >> >> Proposed fix introduces a 2-level cache (1 element each) where 1st level can only contain `MethodHandle`s which are guaranteed to not introduce any dependencies on new class loaders compared to the original `MethodHandle`. 2nd level is backed by a `SoftReference` and is used as a backup when the result of `MethodHandle.asType()` conversion can't populate the higher level cache. >> >> The fix is based on [the work](http://cr.openjdk.java.net/~plevart/jdk9-dev/MethodHandle.asTypeCacheLeak/) made by Peter Levart @plevart back in 2015. >> >> Testing: tier1 - tier6 > > Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments I don't have a strong opinion on whether this should use a SoftReference or a WeakReference. (In fact, one might say that I have a phantom opinion.) The main thing was that the bug report mentioned WeakReference but the commit here uses SoftReferences, and I didn't see any discussion about this change. You gave some reasons above for why SoftReference is preferable, and that's ok with me. ------------- PR: https://git.openjdk.java.net/jdk/pull/5246 From iris at openjdk.java.net Wed Sep 8 01:10:10 2021 From: iris at openjdk.java.net (Iris Clark) Date: Wed, 8 Sep 2021 01:10:10 GMT Subject: RFR: 8273259: Character.getName doesn't follow Unicode spec for ideographs [v2] In-Reply-To: References: <3ZOCioU8lMEPuWdaYlBv8L6oNdIwVjwZpPbKLWwkOjs=.0e8939c8-9cff-4600-a869-9c5f137fd2e5@github.com> Message-ID: On Wed, 8 Sep 2021 00:37:41 GMT, Naoto Sato wrote: >> Simple spec clarification. A CSR has also been drafted (https://bugs.openjdk.java.net/browse/JDK-8273296). > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Refined wordings. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5354 From stuart.marks at oracle.com Wed Sep 8 01:19:48 2021 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 7 Sep 2021 18:19:48 -0700 Subject: RFR: 8231640: (prop) Canonical property storage In-Reply-To: <9d26e9cf-f012-564d-7397-445bc2105b92@gmail.com> References: <0851283f-23f6-a8e6-03c5-d98d29770dbc@oracle.com> <9d26e9cf-f012-564d-7397-445bc2105b92@gmail.com> Message-ID: <596d3276-1764-13a1-bf9c-15c903f32799@oracle.com> On 9/7/21 8:27 AM, Jaikiran Pai wrote: > > On 07/09/21 8:35 pm, Roger Riggs wrote: >> >> Though java.util.Date is used in the current implementation, its use is >> discouraged in new code >> in favor of java.time.ZonedDateTime. >> Consider if java.time.format.DateTimeFormatter.RFC_1123_DATE_TIME can be used to >> parse and format the time. > > Noted. I'll take a look at these and update the PR as necessary. Unless there's an overriding reason, it might be nice to have the output format match the format used in the Debian patch that adds SOURCE_DATE_EPOCH: https://salsa.debian.org/openjdk-team/openjdk/-/blob/master/debian/patches/reproducible-properties-timestamp.diff (See JDK-8272157 for the journey that led us here, in particular, lack of doPrivileged when reading the environment. The Debian patch also doesn't provide a reproducible order, which we've already agreed is necessary.) s'marks From joehw at openjdk.java.net Wed Sep 8 01:47:07 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Wed, 8 Sep 2021 01:47:07 GMT Subject: RFR: 8273369: Computing micros between two instants unexpectedly overflows for some cases [v5] In-Reply-To: <32V0J7ABPauaU7rNH2bLtWokVqg54qHMyTr94orkbqI=.15a84693-5a1e-4699-85fa-d4eb33c68b20@github.com> References: <32V0J7ABPauaU7rNH2bLtWokVqg54qHMyTr94orkbqI=.15a84693-5a1e-4699-85fa-d4eb33c68b20@github.com> Message-ID: On Wed, 8 Sep 2021 00:36:29 GMT, Naoto Sato wrote: >> Please review the fix to the issue. Avoiding overflow by not calling nanosUntil() directly, which will overflow beyond Long.MAX_VALUE difference in nano unit. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Added comments for the test. Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5396 From jai.forums2013 at gmail.com Wed Sep 8 01:51:09 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Wed, 8 Sep 2021 07:21:09 +0530 Subject: RFR: 8231640: (prop) Canonical property storage [v2] In-Reply-To: References: Message-ID: <31fe4c4c-cf26-7c61-909c-b202ea731b14@gmail.com> Hello Robert, On 07/09/21 11:24 pm, Robert Scholte wrote: > On Sat, 4 Sep 2021 18:30:06 GMT, Andrey Turbanov wrote: > >>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >>> >>> use @implNote to explain the use of the environment variable >> src/java.base/share/classes/java/util/Properties.java line 924: >> >>> 922: writeDateComment(bw); >>> 923: synchronized (this) { >>> 924: for (Map.Entry e : new TreeMap<>(map).entrySet()) { >> Is this sorting intentionally added? It's not clear from issue description or PR description that order of properties should be changed too. >> Anyway I think copying `entrySet()` to array and then sorting should be faster, than creating a TreeMap > In case of reproducibility it should be at least ordered, i.e. keep original input order. As discussed in the mailing list, it is agreed upon that these property keys will be oredered when they are written out by the store() APIs. Thus providing reproducibility. However, the order will not be the insertion order, instead it will be the natural order of the property keys and this order will only be applicable/maintained when using the store() APIs. Trying to store them in a original input order will be a much bigger change and won't just be applicable for the store() APIs but the entire internal implementation of the Properties class itself. -Jaikiran From psandoz at openjdk.java.net Wed Sep 8 02:06:05 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 8 Sep 2021 02:06:05 GMT Subject: RFR: 8273450: Fix the copyright header of SVML files In-Reply-To: <6LV8oNP7aMD5JM5Y6v6D_ozDZg9iDsGEaEk9ScN3KSo=.fea8fb4b-fac7-437a-b6c2-7235c5a589ab@github.com> References: <6LV8oNP7aMD5JM5Y6v6D_ozDZg9iDsGEaEk9ScN3KSo=.fea8fb4b-fac7-437a-b6c2-7235c5a589ab@github.com> Message-ID: On Tue, 7 Sep 2021 20:25:25 GMT, Sandhya Viswanathan wrote: > Fix the copyright header of SVML files to match others. > > This was brought up on jdk-dev mailing list: > https://mail.openjdk.java.net/pipermail/jdk-dev/2021-September/005992.html Marked as reviewed by psandoz (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5399 From jai.forums2013 at gmail.com Wed Sep 8 02:09:28 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Wed, 8 Sep 2021 07:39:28 +0530 Subject: RFR: 8231640: (prop) Canonical property storage In-Reply-To: <596d3276-1764-13a1-bf9c-15c903f32799@oracle.com> References: <0851283f-23f6-a8e6-03c5-d98d29770dbc@oracle.com> <9d26e9cf-f012-564d-7397-445bc2105b92@gmail.com> <596d3276-1764-13a1-bf9c-15c903f32799@oracle.com> Message-ID: Hello Stuart, On 08/09/21 6:49 am, Stuart Marks wrote: > > > On 9/7/21 8:27 AM, Jaikiran Pai wrote: >> >> On 07/09/21 8:35 pm, Roger Riggs wrote: >>> >>> Though java.util.Date is used in the current implementation, its use >>> is discouraged in new code >>> in favor of java.time.ZonedDateTime. >>> Consider if java.time.format.DateTimeFormatter.RFC_1123_DATE_TIME >>> can be used to parse and format the time. >> >> Noted. I'll take a look at these and update the PR as necessary. > > Unless there's an overriding reason, it might be nice to have the > output format match the format used in the Debian patch that adds > SOURCE_DATE_EPOCH: > > https://salsa.debian.org/openjdk-team/openjdk/-/blob/master/debian/patches/reproducible-properties-timestamp.diff > So the current patch implementation uses the format "d MMM yyyy HH:mm:ss 'GMT'", with a Locale.ROOT (for locale neutral formatting). I chose this format since that was the one that the (deprecated) java.util.Date#toGMTString() was using. Roger's suggestion is to use DateTimeFormatter#RFC_1123_DATE_TIME date format which is "dow, d MMM yyyy HH:mm:ss GMT" (where dow == day of week) IMO, either of these formats are "well known", since they are/were used within the JDK, especially the DateTimeFormatter#RFC_1123_DATE_TIME which Roger suggested, since that's even a public spec. The one in the debian patch is "yyyy-MM-dd HH:mm:ss z" which although is fine to use, it however feels a bit "less known". I was leaning towards Roger's suggestion to use the RFC_1123_DATE_TIME in my upcoming patch update. Is there a reason why the one in debian's patch is preferable compared to a spec backed format? -Jaikiran From github.com+53162078+shiyuexw at openjdk.java.net Wed Sep 8 06:22:39 2021 From: github.com+53162078+shiyuexw at openjdk.java.net (wxiang) Date: Wed, 8 Sep 2021 06:22:39 GMT Subject: RFR: 8273401: Remove JarIndex support in URLClassPath [v2] In-Reply-To: <10Ivl80m4qzRju-gdlcN6t4CA11U2m-Ngn4U7PnMHnI=.d0d5cd3f-8e52-47a4-9b01-fbfae7c70387@github.com> References: <10Ivl80m4qzRju-gdlcN6t4CA11U2m-Ngn4U7PnMHnI=.d0d5cd3f-8e52-47a4-9b01-fbfae7c70387@github.com> Message-ID: On Tue, 7 Sep 2021 10:39:01 GMT, Lance Andersen wrote: >> src/java.base/share/classes/java/util/jar/JarFile.java line 220: >> >>> 218: * The index file name. >>> 219: */ >>> 220: public static final String INDEX_NAME = "META-INF/INDEX.LIST"; >> >> Adding this as a public field means it becomes part of the API, so it shouldn't be public here. > > Agree remove public?but recover the same definition in JarIndex ------------- PR: https://git.openjdk.java.net/jdk/pull/5383 From github.com+53162078+shiyuexw at openjdk.java.net Wed Sep 8 06:22:38 2021 From: github.com+53162078+shiyuexw at openjdk.java.net (wxiang) Date: Wed, 8 Sep 2021 06:22:38 GMT Subject: RFR: 8273401: Remove JarIndex support in URLClassPath [v2] In-Reply-To: References: Message-ID: > There is a bug for URLClassPath.findResources with JarIndex. > With some discussions about the bug, the current priority is to remove the JAR index support in URLClassPath, > and don?t need to do anything to the jar tool in the short term, except just to move JarIndex to the jdk.jartool module. > > The PR includes: > 1. remove the JarIndex support in URLClassPath > 2. move JarIndex into jdk.jartool module. wxiang has updated the pull request incrementally with one additional commit since the last revision: Some minor changes Include: 1. remove public for INDEX_NAME in JarFile 2. recover the definition for INDEX_NAME in JarIndex 3. mv the test case JarIndexMergeTest.java into test/jdk/java/util/jar ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5383/files - new: https://git.openjdk.java.net/jdk/pull/5383/files/7e11c607..cba9047d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5383&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5383&range=00-01 Stats: 12 lines in 4 files changed: 5 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/5383.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5383/head:pull/5383 PR: https://git.openjdk.java.net/jdk/pull/5383 From github.com+53162078+shiyuexw at openjdk.java.net Wed Sep 8 06:22:40 2021 From: github.com+53162078+shiyuexw at openjdk.java.net (wxiang) Date: Wed, 8 Sep 2021 06:22:40 GMT Subject: RFR: 8273401: Remove JarIndex support in URLClassPath [v2] In-Reply-To: <7BzvoN6dbVscgZKB3U3epUjjJ_os26_P5pYPH_rysE8=.c1e499b0-dd77-41fd-b044-76942c0f33cb@github.com> References: <7BzvoN6dbVscgZKB3U3epUjjJ_os26_P5pYPH_rysE8=.c1e499b0-dd77-41fd-b044-76942c0f33cb@github.com> Message-ID: On Tue, 7 Sep 2021 17:39:20 GMT, Sean Mullan wrote: >> src/java.base/share/classes/java/util/jar/JarVerifier.java line 147: >> >>> 145: >>> 146: if (uname.equals(JarFile.MANIFEST_NAME) || >>> 147: uname.equals(JarFile.INDEX_NAME)) { >> >> It would be useful if someone from security-libs could comment on this. The interaction between signed JAR and JAR index isn't very clear. The change you have is safe but it might be that we can drop the checking for INDEX.LIST here. > > I am thinking this line should not be removed for compatibility with existing JARs that have indexes. still keep the code ------------- PR: https://git.openjdk.java.net/jdk/pull/5383 From github.com+53162078+shiyuexw at openjdk.java.net Wed Sep 8 06:22:45 2021 From: github.com+53162078+shiyuexw at openjdk.java.net (wxiang) Date: Wed, 8 Sep 2021 06:22:45 GMT Subject: RFR: 8273401: Remove JarIndex support in URLClassPath [v2] In-Reply-To: References: Message-ID: On Tue, 7 Sep 2021 10:50:39 GMT, Lance Andersen wrote: >> wxiang has updated the pull request incrementally with one additional commit since the last revision: >> >> Some minor changes >> >> Include: >> 1. remove public for INDEX_NAME in JarFile >> 2. recover the definition for INDEX_NAME in JarIndex >> 3. mv the test case JarIndexMergeTest.java into test/jdk/java/util/jar > > src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 73: > >> 71: import static java.util.jar.JarFile.MANIFEST_NAME; >> 72: import static java.util.stream.Collectors.joining; >> 73: import static java.util.jar.JarFile.INDEX_NAME; > > Maybe move this above the java.util.streamCollectors.joining import > > Also, the copyright should probably be updated to 2021 update to 2021 > test/jdk/sun/misc/JarIndex/JarIndexMergeTest.java line 25: > >> 23: >> 24: /* >> 25: * @test > > Probably should update the copyright year to include 2021 The copyright year includes 2021. ------------- PR: https://git.openjdk.java.net/jdk/pull/5383 From github.com+53162078+shiyuexw at openjdk.java.net Wed Sep 8 06:22:49 2021 From: github.com+53162078+shiyuexw at openjdk.java.net (wxiang) Date: Wed, 8 Sep 2021 06:22:49 GMT Subject: RFR: 8273401: Remove JarIndex support in URLClassPath [v2] In-Reply-To: References: Message-ID: On Tue, 7 Sep 2021 07:15:45 GMT, Alan Bateman wrote: >> wxiang has updated the pull request incrementally with one additional commit since the last revision: >> >> Some minor changes >> >> Include: >> 1. remove public for INDEX_NAME in JarFile >> 2. recover the definition for INDEX_NAME in JarIndex >> 3. mv the test case JarIndexMergeTest.java into test/jdk/java/util/jar > > test/jdk/sun/misc/JarIndex/JarIndexMergeTest.java line 44: > >> 42: import sun.tools.jar.JarIndex; >> 43: >> 44: public class JarIndexMergeTest { > > Is this the one remaining test in sun/misc/JarIndex? I think it can be moved to test/jdk/java/util/jar. I think we should change the package name in the summary comment too. This is the only test case, and I move it to test/jdk/java/util/jar. The summary comment is also changed. ------------- PR: https://git.openjdk.java.net/jdk/pull/5383 From github.com+53162078+shiyuexw at openjdk.java.net Wed Sep 8 06:33:06 2021 From: github.com+53162078+shiyuexw at openjdk.java.net (wxiang) Date: Wed, 8 Sep 2021 06:33:06 GMT Subject: RFR: 8273401: Remove JarIndex support in URLClassPath [v2] In-Reply-To: References: Message-ID: On Wed, 8 Sep 2021 06:22:38 GMT, wxiang wrote: >> There is a bug for URLClassPath.findResources with JarIndex. >> With some discussions about the bug, the current priority is to remove the JAR index support in URLClassPath, >> and don?t need to do anything to the jar tool in the short term, except just to move JarIndex to the jdk.jartool module. >> >> The PR includes: >> 1. remove the JarIndex support in URLClassPath >> 2. move JarIndex into jdk.jartool module. > > wxiang has updated the pull request incrementally with one additional commit since the last revision: > > Some minor changes > > Include: > 1. remove public for INDEX_NAME in JarFile > 2. recover the definition for INDEX_NAME in JarIndex > 3. mv the test case JarIndexMergeTest.java into test/jdk/java/util/jar Create CSR: https://bugs.openjdk.java.net/browse/JDK-8273473 ------------- PR: https://git.openjdk.java.net/jdk/pull/5383 From yyang at openjdk.java.net Wed Sep 8 07:47:13 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Wed, 8 Sep 2021 07:47:13 GMT Subject: RFR: 8273401: Remove JarIndex support in URLClassPath [v2] In-Reply-To: References: Message-ID: On Wed, 8 Sep 2021 06:22:38 GMT, wxiang wrote: >> There is a bug for URLClassPath.findResources with JarIndex. >> With some discussions about the bug, the current priority is to remove the JAR index support in URLClassPath, >> and don?t need to do anything to the jar tool in the short term, except just to move JarIndex to the jdk.jartool module. >> >> The PR includes: >> 1. remove the JarIndex support in URLClassPath >> 2. move JarIndex into jdk.jartool module. > > wxiang has updated the pull request incrementally with one additional commit since the last revision: > > Some minor changes > > Include: > 1. remove public for INDEX_NAME in JarFile > 2. recover the definition for INDEX_NAME in JarIndex > 3. mv the test case JarIndexMergeTest.java into test/jdk/java/util/jar Hi all, Just wondering why we remove JarIndex other than fixing it? Is there any strong motive that drives us to do this? Judging from our internal performance testing and user feedback, JarIndex can significantly reduce the time for class/resource lookup. Although JarIndex is an ancient technology, it is still helpful for many modern scenarios such as serverless applications. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/5383 From alanb at openjdk.java.net Wed Sep 8 07:53:04 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 8 Sep 2021 07:53:04 GMT Subject: RFR: 8273401: Remove JarIndex support in URLClassPath [v2] In-Reply-To: References: Message-ID: On Wed, 8 Sep 2021 06:30:34 GMT, wxiang wrote: > Create CSR: https://bugs.openjdk.java.net/browse/JDK-8273473 Thanks. I've updated the CSR to make it clearer what this change is about. There is still some TDB for the JAR file spec. ------------- PR: https://git.openjdk.java.net/jdk/pull/5383 From shade at openjdk.java.net Wed Sep 8 09:17:31 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 8 Sep 2021 09:17:31 GMT Subject: RFR: 8273315: Parallelize and increase timeouts for java/foreign/TestMatrix.java test [v2] In-Reply-To: References: Message-ID: > This test runs a lot of configurations, and spends a lot of time serially. This is especially pronounced when run in prospective tier4 runs (JDK-8273314). There are reports of multi-hour runs (see JDK-8271613). We can parallelize the test configurations for this test to make it hurt less. Also, timeouts need to be increased for `TestUpcall` test configs, because some of them are very slow in fastdebug mode. > > Sample run: > > > $ time CONF=linux-x86_64-server-fastdebug make run-test TEST=java/foreign/TestMatrix.java | ts -s > 00:00:00 Building target 'run-test' in configuration 'linux-x86_64-server-fastdebug' > 00:00:03 Test selection 'java/foreign/TestMatrix.java', will run: > 00:00:03 * jtreg:test/jdk/java/foreign/TestMatrix.java > 00:00:03 > 00:00:03 Running test 'jtreg:test/jdk/java/foreign/TestMatrix.java' > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TTFT > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FFFF > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FFTF > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TTTT > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FTTT > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FFTT > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FFFT > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TTTF > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FTTF > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TFFT > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TFTF > 00:00:32 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TFFF > 00:00:32 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FTFF > 00:00:35 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TFTT > 00:00:35 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TTFF > 00:00:38 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FTFT > 00:01:50 Passed: java/foreign/TestMatrix.java#Downcall-FF > 00:02:27 Passed: java/foreign/TestMatrix.java#Downcall-TF > 00:03:03 Passed: java/foreign/TestMatrix.java#Downcall-FT > 00:03:47 Passed: java/foreign/TestMatrix.java#Downcall-TT > 00:04:17 Passed: java/foreign/TestMatrix.java#Upcall-FTFF > 00:04:23 Passed: java/foreign/TestMatrix.java#Upcall-TFFF > 00:05:46 Passed: java/foreign/TestMatrix.java#Upcall-TTFF > 00:06:03 Passed: java/foreign/TestMatrix.java#Upcall-TFFT > 00:06:44 Passed: java/foreign/TestMatrix.java#Upcall-FTFT > 00:08:24 Passed: java/foreign/TestMatrix.java#Upcall-TFTF > 00:08:39 Passed: java/foreign/TestMatrix.java#Upcall-TTFT > 00:09:16 Passed: java/foreign/TestMatrix.java#Upcall-FTTF > 00:09:19 Passed: java/foreign/TestMatrix.java#Upcall-TFTT > 00:10:01 Passed: java/foreign/TestMatrix.java#Upcall-FTTT > 00:10:37 Passed: java/foreign/TestMatrix.java#Upcall-TTTF > 00:12:16 Passed: java/foreign/TestMatrix.java#Upcall-TTTT > 00:12:17 Test results: passed: 32 > 00:12:21 > 00:12:21 ============================== > 00:12:21 Test summary > 00:12:21 ============================== > 00:12:21 TEST TOTAL PASS FAIL ERROR > 00:12:21 jtreg:test/jdk/java/foreign/TestMatrix.java 32 32 0 0 > 00:12:21 ============================== > > real 12m20.538s > user 131m54.043s > sys 0m59.944s > > > If we don't parallelize, then those 130 minutes are spent serially. Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Go "manual" ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5358/files - new: https://git.openjdk.java.net/jdk/pull/5358/files/a31a14a5..77de8cbd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5358&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5358&range=00-01 Stats: 42 lines in 1 file changed: 10 ins; 0 del; 32 mod Patch: https://git.openjdk.java.net/jdk/pull/5358.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5358/head:pull/5358 PR: https://git.openjdk.java.net/jdk/pull/5358 From shade at openjdk.java.net Wed Sep 8 09:17:31 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 8 Sep 2021 09:17:31 GMT Subject: RFR: 8273315: Parallelize and increase timeouts for java/foreign/TestMatrix.java test In-Reply-To: References: Message-ID: On Fri, 3 Sep 2021 09:53:53 GMT, Aleksey Shipilev wrote: > This test runs a lot of configurations, and spends a lot of time serially. This is especially pronounced when run in prospective tier4 runs (JDK-8273314). There are reports of multi-hour runs (see JDK-8271613). We can parallelize the test configurations for this test to make it hurt less. Also, timeouts need to be increased for `TestUpcall` test configs, because some of them are very slow in fastdebug mode. > > Sample run: > > > $ time CONF=linux-x86_64-server-fastdebug make run-test TEST=java/foreign/TestMatrix.java | ts -s > 00:00:00 Building target 'run-test' in configuration 'linux-x86_64-server-fastdebug' > 00:00:03 Test selection 'java/foreign/TestMatrix.java', will run: > 00:00:03 * jtreg:test/jdk/java/foreign/TestMatrix.java > 00:00:03 > 00:00:03 Running test 'jtreg:test/jdk/java/foreign/TestMatrix.java' > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TTFT > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FFFF > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FFTF > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TTTT > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FTTT > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FFTT > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FFFT > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TTTF > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FTTF > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TFFT > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TFTF > 00:00:32 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TFFF > 00:00:32 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FTFF > 00:00:35 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TFTT > 00:00:35 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TTFF > 00:00:38 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FTFT > 00:01:50 Passed: java/foreign/TestMatrix.java#Downcall-FF > 00:02:27 Passed: java/foreign/TestMatrix.java#Downcall-TF > 00:03:03 Passed: java/foreign/TestMatrix.java#Downcall-FT > 00:03:47 Passed: java/foreign/TestMatrix.java#Downcall-TT > 00:04:17 Passed: java/foreign/TestMatrix.java#Upcall-FTFF > 00:04:23 Passed: java/foreign/TestMatrix.java#Upcall-TFFF > 00:05:46 Passed: java/foreign/TestMatrix.java#Upcall-TTFF > 00:06:03 Passed: java/foreign/TestMatrix.java#Upcall-TFFT > 00:06:44 Passed: java/foreign/TestMatrix.java#Upcall-FTFT > 00:08:24 Passed: java/foreign/TestMatrix.java#Upcall-TFTF > 00:08:39 Passed: java/foreign/TestMatrix.java#Upcall-TTFT > 00:09:16 Passed: java/foreign/TestMatrix.java#Upcall-FTTF > 00:09:19 Passed: java/foreign/TestMatrix.java#Upcall-TFTT > 00:10:01 Passed: java/foreign/TestMatrix.java#Upcall-FTTT > 00:10:37 Passed: java/foreign/TestMatrix.java#Upcall-TTTF > 00:12:16 Passed: java/foreign/TestMatrix.java#Upcall-TTTT > 00:12:17 Test results: passed: 32 > 00:12:21 > 00:12:21 ============================== > 00:12:21 Test summary > 00:12:21 ============================== > 00:12:21 TEST TOTAL PASS FAIL ERROR > 00:12:21 jtreg:test/jdk/java/foreign/TestMatrix.java 32 32 0 0 > 00:12:21 ============================== > > real 12m20.538s > user 131m54.043s > sys 0m59.944s > > > If we don't parallelize, then those 130 minutes are spent serially. New commit: marked tests as `manual`, as per Maurizio's request. This forced me to drop the `timeout=` clauses, as those are incompatible with `manual` (jtreg plainly refuses to run these). Since OpenJDK build always passes `-a` to tests, one would need to run the jtreg separately to get tests to run, which also includes setting up nativepath appropriately. I have put some instructions at the top of the file. $ time ~/Install/jtreg-6+1/bin/jtreg -jdk:/home/shade/trunks/jdk/build/linux-x86_64-server-fastdebug/images/jdk/ -nativepath:/home/shade/trunks/jdk/build/linux-x86_64-server-fastdebug/support/test/jdk/jtreg/native/lib/ -concurrency:auto ./test/jdk/java/foreign/TestMatrix.java Test results: passed: 32 Report written to /home/shade/trunks/jdk/JTreport/html/report.html Results written to /home/shade/trunks/jdk/JTwork real 12m36.699s user 127m9.995s sys 1m1.343s ------------- PR: https://git.openjdk.java.net/jdk/pull/5358 From shade at openjdk.java.net Wed Sep 8 09:17:32 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 8 Sep 2021 09:17:32 GMT Subject: RFR: 8273315: Parallelize and increase timeouts for java/foreign/TestMatrix.java test [v2] In-Reply-To: References: <9U46SyO2BMIePSHZiMyqnENK2w_odsV3SR2ZJUFAi-w=.f19f7ab3-4c6a-4cad-bfd0-09baadea95c2@github.com> <6Wm9vUTm7_fbT69UFSx8iENWjQe2UZsZBmut8_Ap6yM=.e1bcff98-19f3-4bf2-9d41-27076107aa42@github.com> <0-qx18WD9qQgjivnYDhCheryPEzDFbyvNjLRMDQTGRQ=.55fcf55f-dbe2-4a22-bf4d-39a3908d25de@github.com> Message-ID: On Tue, 7 Sep 2021 16:54:11 GMT, Alan Bateman wrote: >> you are right about /manual being for GUI - but @AlanBateman pointed me at few tests with libzip using it for similar reasons (e.g. long running tests). > > I don't think /manual is strictly UI but its usage is discouraged as manual tests are rarely run. The tests for the SmartCard I/O API come to mind as they need special setup. There is one or two ZIP tests that take a long time and have historically been manual tests as a result. There are also a few tests dotted around that do not have the `@Test` tag, one needs to be working in a specific area to know about these. Introducing a new test group or a keyword for these tests could be an option. > > In passing, I should mention the jdk_sctp test group. These tests may require kernel or other configuration and are deliberately not in any tier. That may be a comment for the other PR that is proposing a jdk tier4. See new commit. ------------- PR: https://git.openjdk.java.net/jdk/pull/5358 From jpai at openjdk.java.net Wed Sep 8 09:26:33 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Wed, 8 Sep 2021 09:26:33 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v3] In-Reply-To: References: Message-ID: <6LwZddwwZyA8VbW2qh932vbw9vdqjtf0auS3JFWF7hA=.01ba8840-07b6-40d9-9a2d-c29f595d8797@github.com> > The commit in this PR implements the proposal for enhancement that was discussed in the core-libs-dev mailing list recently[1], for https://bugs.openjdk.java.net/browse/JDK-8231640 > > At a high level - the `store()` APIs in `Properties` have been modified to now look for the `SOURCE_DATE_EPOCH` environment variable[2]. If that env variable is set, then instead of writing out the current date time as a date comment, the `store()` APIs instead will use the value set for this env variable to parse it to a `Date` and write out the string form of such a date. The implementation here uses the `d MMM yyyy HH:mm:ss 'GMT'` date format and `Locale.ROOT` to format and write out such a date. This should provide reproducibility whenever the `SOURCE_DATE_EPOCH` is set. Furthermore, intentionally, no changes in the date format of the "current date" have been done. > > These modified `store()` APIs work in the presence of the `SecurityManager` too. The caller is expected to have a read permission on the `SOURCE_DATE_EPOCH` environment variable. If the caller doesn't have that permission, then the implementation of these `store()` APIs will write out the "current date" and will ignore any value that has been set for the `SOURCE_DATE_EPOCH` env variable. This should allow for backward compatibility of existing applications, where, when they run under a `SecurityManager` and perhaps with an existing restrictive policy file, the presence of `SOURCE_DATE_EPOCH` shouldn't impact their calls to the `store()` APIs. > > The modified `store()` APIs will also ignore any value for `SOURCE_DATE_EPOCH` that cannot be parsed to an `long` value. In such cases, the `store()` APIs will write out the "current date" and ignore the value set for this environment variable. No exceptions will be thrown for such invalid values. This is an additional backward compatibility precaution to prevent any rogue value for `SOURCE_DATE_EPOCH` from breaking applications. > > An additional change in the implementation of these `store()` APIs and unrelated to the date comment, is that these APIs will now write out the property keys in a deterministic order. The keys will be written out in the natural ordering as specified by `java.lang.String#compareTo()` API. > > The combination of the ordering of the property keys when written out and the usage of `SOURCE_DATE_EPOCH` environment value to determine the date comment should together allow for reproducibility of the output generated by these `store()` APIs. > > New jtreg test classes have been introduced to verify these changes. The primary focus of `PropertiesStoreTest` is the ordering aspects of the property keys that are written out. On the other hand `StoreReproducibilityTest` focuses on the reproducibility of the output generated by these APIs. The `StoreReproducibilityTest` runs these tests both in the presence and absence of `SecurityManager`. Plus, in the presence of SecurityManager, it tests both the scenarios where the caller is granted the requisite permission and in other case not granted that permission. > > These new tests and existing tests under `test/jdk/java/util/Properties/` pass with these changes. > > [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-August/080758.html > [2] https://reproducible-builds.org/specs/source-date-epoch/ Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision: - adjust testcases to verify the new semantics - implement review suggestions: - Use doPriveleged instead of explicit permission checks, to reduce complexity - Use DateTimeFormatter and ZonedDateTime instead of Date.toString() - Use DateTimeFormatter.RFC_1123_DATE_TIME for formatting SOURCE_DATE_EPOCH dates - Use Arrays.sort instead of a TreeMap for ordering property keys ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5372/files - new: https://git.openjdk.java.net/jdk/pull/5372/files/641864e2..1ded17f9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5372&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5372&range=01-02 Stats: 225 lines in 4 files changed: 73 ins; 119 del; 33 mod Patch: https://git.openjdk.java.net/jdk/pull/5372.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5372/head:pull/5372 PR: https://git.openjdk.java.net/jdk/pull/5372 From jai.forums2013 at gmail.com Wed Sep 8 09:29:10 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Wed, 8 Sep 2021 14:59:10 +0530 Subject: RFR: 8231640: (prop) Canonical property storage In-Reply-To: <1d66a1eb-7ee6-eabf-751d-9940a6ef4a7b@oracle.com> References: <0851283f-23f6-a8e6-03c5-d98d29770dbc@oracle.com> <1d66a1eb-7ee6-eabf-751d-9940a6ef4a7b@oracle.com> Message-ID: <0e612e79-4a4f-5d9f-f91b-028e85e39598@gmail.com> On 07/09/21 9:02 pm, Alan Bateman wrote: > On 07/09/2021 16:05, Roger Riggs wrote: >> Hi, >> >> The value of SOURCE_DATE_EPOCH is not so sensitive that it needs the >> protections you are applying. >> The doPriv only exposes the value of that specific environment >> variable and in the usual case, it is undefined. >> >> The complexity in the specification and implementation seem >> unnecessary in this case. > > I agree.? Given the complexity then it makes your suggestion/option to > just drop the date from the comment somewhat tempting. > > -Alan I've now updated the PR to take into account the inputs that were provided so far. More specifically, the PR has been updated to: ?- remove the complexity around SecurityManager usage and now just uses a doPriveleged block to get the SOURCE_EPOCH_DATE. ?- use Arrays.sort(...) instead of a TreeMap to write out the sorted properties. This was a suggestion from Andrey and based on my JMH testing (which I will post separately), the Arrays.sort(...) did indeed perform better. ?- use DateTimeFormatter.RFC_1123_DATE_TIME while formatting and writing the reproducible SOURCE_DATE_EPOCH value. There isn't a general agreement yet on what format should be used. Stuart has suggested using a different format (the one in the debian patch). So this part of the change could still undergo further change. ?- use ZonedDateTime along with a DateTimeFormatter which matches the format used by java.util.Date.toString(), instead of using a java.util.Date() instance when writing out the current date. The new tests that have been introduced in this PR have been adjusted to verify these new expectations. The existing and these new tests continue to pass with these changes. -Jaikiran From jpai at openjdk.java.net Wed Sep 8 09:36:05 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Wed, 8 Sep 2021 09:36:05 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v3] In-Reply-To: <6LwZddwwZyA8VbW2qh932vbw9vdqjtf0auS3JFWF7hA=.01ba8840-07b6-40d9-9a2d-c29f595d8797@github.com> References: <6LwZddwwZyA8VbW2qh932vbw9vdqjtf0auS3JFWF7hA=.01ba8840-07b6-40d9-9a2d-c29f595d8797@github.com> Message-ID: On Wed, 8 Sep 2021 09:26:33 GMT, Jaikiran Pai wrote: >> The commit in this PR implements the proposal for enhancement that was discussed in the core-libs-dev mailing list recently[1], for https://bugs.openjdk.java.net/browse/JDK-8231640 >> >> At a high level - the `store()` APIs in `Properties` have been modified to now look for the `SOURCE_DATE_EPOCH` environment variable[2]. If that env variable is set, then instead of writing out the current date time as a date comment, the `store()` APIs instead will use the value set for this env variable to parse it to a `Date` and write out the string form of such a date. The implementation here uses the `d MMM yyyy HH:mm:ss 'GMT'` date format and `Locale.ROOT` to format and write out such a date. This should provide reproducibility whenever the `SOURCE_DATE_EPOCH` is set. Furthermore, intentionally, no changes in the date format of the "current date" have been done. >> >> These modified `store()` APIs work in the presence of the `SecurityManager` too. The caller is expected to have a read permission on the `SOURCE_DATE_EPOCH` environment variable. If the caller doesn't have that permission, then the implementation of these `store()` APIs will write out the "current date" and will ignore any value that has been set for the `SOURCE_DATE_EPOCH` env variable. This should allow for backward compatibility of existing applications, where, when they run under a `SecurityManager` and perhaps with an existing restrictive policy file, the presence of `SOURCE_DATE_EPOCH` shouldn't impact their calls to the `store()` APIs. >> >> The modified `store()` APIs will also ignore any value for `SOURCE_DATE_EPOCH` that cannot be parsed to an `long` value. In such cases, the `store()` APIs will write out the "current date" and ignore the value set for this environment variable. No exceptions will be thrown for such invalid values. This is an additional backward compatibility precaution to prevent any rogue value for `SOURCE_DATE_EPOCH` from breaking applications. >> >> An additional change in the implementation of these `store()` APIs and unrelated to the date comment, is that these APIs will now write out the property keys in a deterministic order. The keys will be written out in the natural ordering as specified by `java.lang.String#compareTo()` API. >> >> The combination of the ordering of the property keys when written out and the usage of `SOURCE_DATE_EPOCH` environment value to determine the date comment should together allow for reproducibility of the output generated by these `store()` APIs. >> >> New jtreg test classes have been introduced to verify these changes. The primary focus of `PropertiesStoreTest` is the ordering aspects of the property keys that are written out. On the other hand `StoreReproducibilityTest` focuses on the reproducibility of the output generated by these APIs. The `StoreReproducibilityTest` runs these tests both in the presence and absence of `SecurityManager`. Plus, in the presence of SecurityManager, it tests both the scenarios where the caller is granted the requisite permission and in other case not granted that permission. >> >> These new tests and existing tests under `test/jdk/java/util/Properties/` pass with these changes. >> >> [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-August/080758.html >> [2] https://reproducible-builds.org/specs/source-date-epoch/ > > Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision: > > - adjust testcases to verify the new semantics > - implement review suggestions: > - Use doPriveleged instead of explicit permission checks, to reduce complexity > - Use DateTimeFormatter and ZonedDateTime instead of Date.toString() > - Use DateTimeFormatter.RFC_1123_DATE_TIME for formatting SOURCE_DATE_EPOCH dates > - Use Arrays.sort instead of a TreeMap for ordering property keys src/java.base/share/classes/java/util/Properties.java line 963: > 961: synchronized (this) { > 962: var entries = map.entrySet().toArray(new Map.Entry[0]); > 963: Arrays.sort(entries, new Comparator>() { This part here, intentionally doesn't use a lambda, since from what I remember seeing in some mail discussion, it was suggested that using lambda in core parts which get used very early during JVM boostrap, should be avoided. If that's not a concern here, do let me know and I can change it to a lambda. ------------- PR: https://git.openjdk.java.net/jdk/pull/5372 From jai.forums2013 at gmail.com Wed Sep 8 09:37:15 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Wed, 8 Sep 2021 15:07:15 +0530 Subject: RFR: 8231640: (prop) Canonical property storage In-Reply-To: References: Message-ID: Hello Andrey, On 07/09/21 7:50 pm, Andrey Turbanov wrote: > On Sun, 5 Sep 2021 12:38:20 GMT, Jaikiran Pai wrote: > >> Do you mean that converting the keySet() of an >> existing Map into an array and then sorting that array and then using >> that sorted array to iterate and using these keys to do an additional >> lookup for value against the original Map would be more efficient in >> this case? > You can convert entrySet() to array. Not a keySet. In this case there is no need to lookup for values. I experimented this in a JMH test and the results matched your expectations. So, I've updated the PR to use array sorting instead of creating a TreeMap. For reference, here's the JMH benchmark code and the results: package org.myapp; import org.openjdk.jmh.annotations.Benchmark; import java.util.*; import java.util.concurrent.*; import org.openjdk.jmh.annotations.*; public class MyBenchmark { ??? @State(Scope.Thread) ??? public static class TestData { ??????? static final Map tenItems; ??????? static final Map hundredItems; ??????? static final Map thousandItems; ??????? static { ??????????? tenItems = new ConcurrentHashMap<>(8); ??????????? hundredItems = new ConcurrentHashMap<>(8); ??????????? thousandItems = new ConcurrentHashMap<>(8); ??????????? for (int i = 0; i < 1000; i++) { ??????????????? thousandItems.put("foo" + i, "bar"); ??????????????? if (i < 100) { ??????????????????? hundredItems.put("hello" + i, "world"); ??????????????? } ??????????????? if (i < 10) { ??????????????????? tenItems.put("good" + i, "morning"); ??????????????? } ??????????? } ??????????? System.out.println("Test data created with " + tenItems.size() + ", " ??????????????? + hundredItems.size() + " and " + thousandItems.size() + " Map keys"); ??????? } ??? } ??? @Benchmark ??? @BenchmarkMode(Mode.AverageTime) ??? @OutputTimeUnit(TimeUnit.MICROSECONDS) ??? public void testTenItemsTreeMapSorting(TestData testData) { ??????? final Map sorted = new TreeMap(testData.tenItems); ??? } ??? @Benchmark ??? @BenchmarkMode(Mode.AverageTime) ??? @OutputTimeUnit(TimeUnit.MICROSECONDS) ??? public void testHundredItemsTreeMapSorting(TestData testData) { ??????? final Map sorted = new TreeMap(testData.hundredItems); ??? } ??? @Benchmark ??? @BenchmarkMode(Mode.AverageTime) ??? @OutputTimeUnit(TimeUnit.MICROSECONDS) ??? public void testThousandItemsTreeMapSorting(TestData testData) { ??????? final Map sorted = new TreeMap(testData.thousandItems); ??? } ??? @Benchmark ??? @BenchmarkMode(Mode.AverageTime) ??? @OutputTimeUnit(TimeUnit.MICROSECONDS) ??? public void testTenItemsArraySorting(TestData testData) { ??????? var entries = testData.tenItems.entrySet().toArray(new Map.Entry[0]); ??????? Arrays.sort(entries, new Comparator>() { ??????????? @Override ??????????? public int compare(Map.Entry o1, Map.Entry o2) { ??????????????? return ((String) o1.getKey()).compareTo((String) o2.getKey()); ??????????? } ??????? }); ??? } ??? @Benchmark ??? @BenchmarkMode(Mode.AverageTime) ??? @OutputTimeUnit(TimeUnit.MICROSECONDS) ??? public void testHundredItemsArraySorting(TestData testData) { ??????? var entries = testData.hundredItems.entrySet().toArray(new Map.Entry[0]); ??????? Arrays.sort(entries, new Comparator>() { ??????????? @Override ??????????? public int compare(Map.Entry o1, Map.Entry o2) { ??????????????? return ((String) o1.getKey()).compareTo((String) o2.getKey()); ??????????? } ??????? }); ??? } ??? @Benchmark ??? @BenchmarkMode(Mode.AverageTime) ??? @OutputTimeUnit(TimeUnit.MICROSECONDS) ??? public void testThousandItemsArraySorting(TestData testData) { ??????? var entries = testData.thousandItems.entrySet().toArray(new Map.Entry[0]); ??????? Arrays.sort(entries, new Comparator>() { ??????????? @Override ??????????? public int compare(Map.Entry o1, Map.Entry o2) { ??????????????? return ((String) o1.getKey()).compareTo((String) o2.getKey()); ??????????? } ??????? }); ??? } } Results: Benchmark??????????????????????????????????? Mode? Cnt??? Score Error? Units MyBenchmark.testHundredItemsArraySorting???? avgt?? 25??? 8.330 ? 0.147? us/op MyBenchmark.testHundredItemsTreeMapSorting?? avgt?? 25??? 8.637 ? 0.333? us/op MyBenchmark.testTenItemsArraySorting???????? avgt?? 25??? 0.261 ? 0.006? us/op MyBenchmark.testTenItemsTreeMapSorting?????? avgt?? 25??? 0.422 ? 0.007? us/op MyBenchmark.testThousandItemsArraySorting??? avgt?? 25? 151.566 ? 1.660? us/op MyBenchmark.testThousandItemsTreeMapSorting? avgt?? 25? 163.767 ? 1.911? us/op -Jaikiran From jpai at openjdk.java.net Wed Sep 8 09:54:33 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Wed, 8 Sep 2021 09:54:33 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v4] In-Reply-To: References: Message-ID: > The commit in this PR implements the proposal for enhancement that was discussed in the core-libs-dev mailing list recently[1], for https://bugs.openjdk.java.net/browse/JDK-8231640 > > At a high level - the `store()` APIs in `Properties` have been modified to now look for the `SOURCE_DATE_EPOCH` environment variable[2]. If that env variable is set, then instead of writing out the current date time as a date comment, the `store()` APIs instead will use the value set for this env variable to parse it to a `Date` and write out the string form of such a date. The implementation here uses the `d MMM yyyy HH:mm:ss 'GMT'` date format and `Locale.ROOT` to format and write out such a date. This should provide reproducibility whenever the `SOURCE_DATE_EPOCH` is set. Furthermore, intentionally, no changes in the date format of the "current date" have been done. > > These modified `store()` APIs work in the presence of the `SecurityManager` too. The caller is expected to have a read permission on the `SOURCE_DATE_EPOCH` environment variable. If the caller doesn't have that permission, then the implementation of these `store()` APIs will write out the "current date" and will ignore any value that has been set for the `SOURCE_DATE_EPOCH` env variable. This should allow for backward compatibility of existing applications, where, when they run under a `SecurityManager` and perhaps with an existing restrictive policy file, the presence of `SOURCE_DATE_EPOCH` shouldn't impact their calls to the `store()` APIs. > > The modified `store()` APIs will also ignore any value for `SOURCE_DATE_EPOCH` that cannot be parsed to an `long` value. In such cases, the `store()` APIs will write out the "current date" and ignore the value set for this environment variable. No exceptions will be thrown for such invalid values. This is an additional backward compatibility precaution to prevent any rogue value for `SOURCE_DATE_EPOCH` from breaking applications. > > An additional change in the implementation of these `store()` APIs and unrelated to the date comment, is that these APIs will now write out the property keys in a deterministic order. The keys will be written out in the natural ordering as specified by `java.lang.String#compareTo()` API. > > The combination of the ordering of the property keys when written out and the usage of `SOURCE_DATE_EPOCH` environment value to determine the date comment should together allow for reproducibility of the output generated by these `store()` APIs. > > New jtreg test classes have been introduced to verify these changes. The primary focus of `PropertiesStoreTest` is the ordering aspects of the property keys that are written out. On the other hand `StoreReproducibilityTest` focuses on the reproducibility of the output generated by these APIs. The `StoreReproducibilityTest` runs these tests both in the presence and absence of `SecurityManager`. Plus, in the presence of SecurityManager, it tests both the scenarios where the caller is granted the requisite permission and in other case not granted that permission. > > These new tests and existing tests under `test/jdk/java/util/Properties/` pass with these changes. > > [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-August/080758.html > [2] https://reproducible-builds.org/specs/source-date-epoch/ Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: update javadoc @implNote to match latest changes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5372/files - new: https://git.openjdk.java.net/jdk/pull/5372/files/1ded17f9..867ec999 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5372&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5372&range=02-03 Stats: 5 lines in 1 file changed: 0 ins; 1 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/5372.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5372/head:pull/5372 PR: https://git.openjdk.java.net/jdk/pull/5372 From github.com+741251+turbanoff at openjdk.java.net Wed Sep 8 10:06:32 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Wed, 8 Sep 2021 10:06:32 GMT Subject: RFR: 8273484: Cleanup unnecessary null comparison before instanceof check in java.naming Message-ID: Update code checks both non-null and instance of a class in java.naming module classes. The checks and explicit casts could also be replaced with pattern matching for the instanceof operator. For example: The following code: return (obj != null && obj instanceof CompoundName && impl.equals(((CompoundName)obj).impl)); Can be simplified to: return (obj instanceof CompoundName other) && impl.equals(other.impl); See similar cleanup in java.base - https://bugs.openjdk.java.net/browse/JDK-8258422 ------------- Commit messages: - [PATCH] Cleanup unnecessary null comparison before instanceof check in java.naming Changes: https://git.openjdk.java.net/jdk/pull/5374/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5374&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273484 Stats: 41 lines in 12 files changed: 0 ins; 11 del; 30 mod Patch: https://git.openjdk.java.net/jdk/pull/5374.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5374/head:pull/5374 PR: https://git.openjdk.java.net/jdk/pull/5374 From shade at openjdk.java.net Wed Sep 8 11:06:18 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 8 Sep 2021 11:06:18 GMT Subject: RFR: 8273487: Zero: Handle "zero" variant in runtime tests Message-ID: JDK-8179317 rewritten runtime shell tests to Java. There is a little omission in VM variant selection, which makes Zero fail some of the tier1 tests, like: $ CONF=linux-x86_64-zero-fastdebug make exploded-test TEST=runtime/StackGap/TestStackGap.java STDERR: java.lang.Error: TESTBUG: unsupported vm variant at jdk.test.lib.Platform.variant(Platform.java:368) at jdk.test.lib.Platform.jvmLibDir(Platform.java:357) at jdk.test.lib.process.ProcessTools.addJvmLib(ProcessTools.java:585) at jdk.test.lib.process.ProcessTools.createNativeTestProcessBuilder(ProcessTools.java:575) Additional testing: - [ ] Linux x86_64 Zero affected tests (StackGap, StackGuardPages, TestTLS) now run ------------- Commit messages: - Fix Changes: https://git.openjdk.java.net/jdk/pull/5413/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5413&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273487 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5413.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5413/head:pull/5413 PR: https://git.openjdk.java.net/jdk/pull/5413 From azeller at openjdk.java.net Wed Sep 8 11:11:05 2021 From: azeller at openjdk.java.net (Arno Zeller) Date: Wed, 8 Sep 2021 11:11:05 GMT Subject: RFR: 8273315: Parallelize and increase timeouts for java/foreign/TestMatrix.java test In-Reply-To: References: Message-ID: On Wed, 8 Sep 2021 09:13:20 GMT, Aleksey Shipilev wrote: > New commit: marked tests as `manual`, as per Maurizio's request. This forced me to drop the `timeout=` clauses, as those are incompatible with `manual` (jtreg plainly refuses to run these). Ok, I am too late, but just for the record: I let your old patch (including timeout adjustments) run in our test infrastructure and it fixed the timeout issue from [JDK-8271613](https://bugs.openjdk.java.net/browse/JDK-8271613). Probably it could be a better solution to add the stress keyword for slow running or high load tests - like it is done in the hotspot part of the tests. Then automated test run can exclude or select these test by keyword. ------------- PR: https://git.openjdk.java.net/jdk/pull/5358 From alanb at openjdk.java.net Wed Sep 8 11:19:06 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 8 Sep 2021 11:19:06 GMT Subject: RFR: 8273487: Zero: Handle "zero" variant in runtime tests In-Reply-To: References: Message-ID: On Wed, 8 Sep 2021 10:57:33 GMT, Aleksey Shipilev wrote: > JDK-8179317 rewritten runtime shell tests to Java. There is a little omission in VM variant selection, which makes Zero fail some of the tier1 tests, like: > > > $ CONF=linux-x86_64-zero-fastdebug make exploded-test TEST=runtime/StackGap/TestStackGap.java > > STDERR: > java.lang.Error: TESTBUG: unsupported vm variant > at jdk.test.lib.Platform.variant(Platform.java:368) > at jdk.test.lib.Platform.jvmLibDir(Platform.java:357) > at jdk.test.lib.process.ProcessTools.addJvmLib(ProcessTools.java:585) > at jdk.test.lib.process.ProcessTools.createNativeTestProcessBuilder(ProcessTools.java:575) > > > Additional testing: > - [ ] Linux x86_64 Zero affected tests (StackGap, StackGuardPages, TestTLS) now run Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5413 From vlivanov at openjdk.java.net Wed Sep 8 11:31:09 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Wed, 8 Sep 2021 11:31:09 GMT Subject: RFR: 8078641: MethodHandle.asTypeCache can retain classes from unloading [v4] In-Reply-To: References: Message-ID: On Fri, 3 Sep 2021 14:41:45 GMT, Vladimir Ivanov wrote: >> `MethodHandle.asTypeCache` keeps a strong reference to adapted `MethodHandle` and it can introduce a class loader leak through its `MethodType`. >> >> Proposed fix introduces a 2-level cache (1 element each) where 1st level can only contain `MethodHandle`s which are guaranteed to not introduce any dependencies on new class loaders compared to the original `MethodHandle`. 2nd level is backed by a `SoftReference` and is used as a backup when the result of `MethodHandle.asType()` conversion can't populate the higher level cache. >> >> The fix is based on [the work](http://cr.openjdk.java.net/~plevart/jdk9-dev/MethodHandle.asTypeCacheLeak/) made by Peter Levart @plevart back in 2015. >> >> Testing: tier1 - tier6 > > Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments Thanks for the reviews, Mandy, Paul, Peter, and Stuart. ------------- PR: https://git.openjdk.java.net/jdk/pull/5246 From vlivanov at openjdk.java.net Wed Sep 8 11:31:10 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Wed, 8 Sep 2021 11:31:10 GMT Subject: Integrated: 8078641: MethodHandle.asTypeCache can retain classes from unloading In-Reply-To: References: Message-ID: On Wed, 25 Aug 2021 09:31:51 GMT, Vladimir Ivanov wrote: > `MethodHandle.asTypeCache` keeps a strong reference to adapted `MethodHandle` and it can introduce a class loader leak through its `MethodType`. > > Proposed fix introduces a 2-level cache (1 element each) where 1st level can only contain `MethodHandle`s which are guaranteed to not introduce any dependencies on new class loaders compared to the original `MethodHandle`. 2nd level is backed by a `SoftReference` and is used as a backup when the result of `MethodHandle.asType()` conversion can't populate the higher level cache. > > The fix is based on [the work](http://cr.openjdk.java.net/~plevart/jdk9-dev/MethodHandle.asTypeCacheLeak/) made by Peter Levart @plevart back in 2015. > > Testing: tier1 - tier6 This pull request has now been integrated. Changeset: 21012f2b Author: Vladimir Ivanov URL: https://git.openjdk.java.net/jdk/commit/21012f2bbe214955d05f8bc583dcdceb0949b601 Stats: 109 lines in 2 files changed: 88 ins; 3 del; 18 mod 8078641: MethodHandle.asTypeCache can retain classes from unloading Co-authored-by: Peter Levart Co-authored-by: Vladimir Ivanov Reviewed-by: psandoz, mchung, plevart ------------- PR: https://git.openjdk.java.net/jdk/pull/5246 From vlivanov at openjdk.java.net Wed Sep 8 11:32:11 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Wed, 8 Sep 2021 11:32:11 GMT Subject: RFR: 8273000: Remove WeakReference-based class initialisation barrier implementation [v3] In-Reply-To: References: Message-ID: On Thu, 2 Sep 2021 11:45:01 GMT, Vladimir Ivanov wrote: >> Get rid of WeakReference-based logic in DirectMethodHandle::checkInitialized() and reimplement it with `Unsafe::ensureClassInitialized()`/`shouldBeInitialized()`. >> >> The key observation is that `Unsafe::ensureClassInitialized()` does not block the initializing thread. >> >> Also, removed `Unsafe::shouldBeInitialized()` in `DMH::shouldBeInitialized(MemberName)` to save on calling into the VM. >> `Unsafe::ensureClassInitialized()` already has a fast-path check which checks whether the class is fully initialized or not. >> >> Testing: tier1 - tier6 > > Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > Update the comment Thanks for the reviews, Mandy, Paul, and David. ------------- PR: https://git.openjdk.java.net/jdk/pull/5258 From vlivanov at openjdk.java.net Wed Sep 8 11:32:12 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Wed, 8 Sep 2021 11:32:12 GMT Subject: Integrated: 8273000: Remove WeakReference-based class initialisation barrier implementation In-Reply-To: References: Message-ID: On Wed, 25 Aug 2021 22:05:24 GMT, Vladimir Ivanov wrote: > Get rid of WeakReference-based logic in DirectMethodHandle::checkInitialized() and reimplement it with `Unsafe::ensureClassInitialized()`/`shouldBeInitialized()`. > > The key observation is that `Unsafe::ensureClassInitialized()` does not block the initializing thread. > > Also, removed `Unsafe::shouldBeInitialized()` in `DMH::shouldBeInitialized(MemberName)` to save on calling into the VM. > `Unsafe::ensureClassInitialized()` already has a fast-path check which checks whether the class is fully initialized or not. > > Testing: tier1 - tier6 This pull request has now been integrated. Changeset: faa942c8 Author: Vladimir Ivanov URL: https://git.openjdk.java.net/jdk/commit/faa942c8ba8ad778b6be20ff6d98a5040a9079e9 Stats: 43 lines in 2 files changed: 5 ins; 28 del; 10 mod 8273000: Remove WeakReference-based class initialisation barrier implementation Reviewed-by: psandoz, mchung ------------- PR: https://git.openjdk.java.net/jdk/pull/5258 From mcimadamore at openjdk.java.net Wed Sep 8 11:37:12 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 8 Sep 2021 11:37:12 GMT Subject: RFR: 8273315: Parallelize and increase timeouts for java/foreign/TestMatrix.java test [v2] In-Reply-To: References: Message-ID: On Wed, 8 Sep 2021 09:17:31 GMT, Aleksey Shipilev wrote: >> This test runs a lot of configurations, and spends a lot of time serially. This is especially pronounced when run in prospective tier4 runs (JDK-8273314). There are reports of multi-hour runs (see JDK-8271613). We can parallelize the test configurations for this test to make it hurt less. Also, timeouts need to be increased for `TestUpcall` test configs, because some of them are very slow in fastdebug mode. >> >> Sample run: >> >> >> $ time CONF=linux-x86_64-server-fastdebug make run-test TEST=java/foreign/TestMatrix.java | ts -s >> 00:00:00 Building target 'run-test' in configuration 'linux-x86_64-server-fastdebug' >> 00:00:03 Test selection 'java/foreign/TestMatrix.java', will run: >> 00:00:03 * jtreg:test/jdk/java/foreign/TestMatrix.java >> 00:00:03 >> 00:00:03 Running test 'jtreg:test/jdk/java/foreign/TestMatrix.java' >> 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TTFT >> 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FFFF >> 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FFTF >> 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TTTT >> 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FTTT >> 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FFTT >> 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FFFT >> 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TTTF >> 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FTTF >> 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TFFT >> 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TFTF >> 00:00:32 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TFFF >> 00:00:32 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FTFF >> 00:00:35 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TFTT >> 00:00:35 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TTFF >> 00:00:38 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FTFT >> 00:01:50 Passed: java/foreign/TestMatrix.java#Downcall-FF >> 00:02:27 Passed: java/foreign/TestMatrix.java#Downcall-TF >> 00:03:03 Passed: java/foreign/TestMatrix.java#Downcall-FT >> 00:03:47 Passed: java/foreign/TestMatrix.java#Downcall-TT >> 00:04:17 Passed: java/foreign/TestMatrix.java#Upcall-FTFF >> 00:04:23 Passed: java/foreign/TestMatrix.java#Upcall-TFFF >> 00:05:46 Passed: java/foreign/TestMatrix.java#Upcall-TTFF >> 00:06:03 Passed: java/foreign/TestMatrix.java#Upcall-TFFT >> 00:06:44 Passed: java/foreign/TestMatrix.java#Upcall-FTFT >> 00:08:24 Passed: java/foreign/TestMatrix.java#Upcall-TFTF >> 00:08:39 Passed: java/foreign/TestMatrix.java#Upcall-TTFT >> 00:09:16 Passed: java/foreign/TestMatrix.java#Upcall-FTTF >> 00:09:19 Passed: java/foreign/TestMatrix.java#Upcall-TFTT >> 00:10:01 Passed: java/foreign/TestMatrix.java#Upcall-FTTT >> 00:10:37 Passed: java/foreign/TestMatrix.java#Upcall-TTTF >> 00:12:16 Passed: java/foreign/TestMatrix.java#Upcall-TTTT >> 00:12:17 Test results: passed: 32 >> 00:12:21 >> 00:12:21 ============================== >> 00:12:21 Test summary >> 00:12:21 ============================== >> 00:12:21 TEST TOTAL PASS FAIL ERROR >> 00:12:21 jtreg:test/jdk/java/foreign/TestMatrix.java 32 32 0 0 >> 00:12:21 ============================== >> >> real 12m20.538s >> user 131m54.043s >> sys 0m59.944s >> >> >> If we don't parallelize, then those 130 minutes are spent serially. > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Go "manual" Changes looks good. Whether we want to use `manual` or `@stress` I'm not sure. I guess it depends a lot on which parameters are typically used by CI to run those tests. ------------- PR: https://git.openjdk.java.net/jdk/pull/5358 From mcimadamore at openjdk.java.net Wed Sep 8 11:51:05 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 8 Sep 2021 11:51:05 GMT Subject: RFR: 8273315: Parallelize and increase timeouts for java/foreign/TestMatrix.java test [v2] In-Reply-To: References: Message-ID: On Wed, 8 Sep 2021 11:34:10 GMT, Maurizio Cimadamore wrote: > Changes looks good. Whether we want to use `manual` or `@stress` I'm not sure. I guess it depends a lot on which parameters are typically used by CI to run those tests. I note that, for instance, the makefile `make/RunTests.gmk` does pass the `-automatic` flag to jtreg, but I don't see any keyword-based exclusion set up there - so I think `manual` would work well there. ------------- PR: https://git.openjdk.java.net/jdk/pull/5358 From mcimadamore at openjdk.java.net Wed Sep 8 11:51:04 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 8 Sep 2021 11:51:04 GMT Subject: RFR: 8273315: Parallelize and increase timeouts for java/foreign/TestMatrix.java test [v2] In-Reply-To: References: Message-ID: On Wed, 8 Sep 2021 09:17:31 GMT, Aleksey Shipilev wrote: >> This test runs a lot of configurations, and spends a lot of time serially. This is especially pronounced when run in prospective tier4 runs (JDK-8273314). There are reports of multi-hour runs (see JDK-8271613). We can parallelize the test configurations for this test to make it hurt less. Also, timeouts need to be increased for `TestUpcall` test configs, because some of them are very slow in fastdebug mode. >> >> Sample run: >> >> >> $ time CONF=linux-x86_64-server-fastdebug make run-test TEST=java/foreign/TestMatrix.java | ts -s >> 00:00:00 Building target 'run-test' in configuration 'linux-x86_64-server-fastdebug' >> 00:00:03 Test selection 'java/foreign/TestMatrix.java', will run: >> 00:00:03 * jtreg:test/jdk/java/foreign/TestMatrix.java >> 00:00:03 >> 00:00:03 Running test 'jtreg:test/jdk/java/foreign/TestMatrix.java' >> 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TTFT >> 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FFFF >> 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FFTF >> 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TTTT >> 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FTTT >> 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FFTT >> 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FFFT >> 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TTTF >> 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FTTF >> 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TFFT >> 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TFTF >> 00:00:32 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TFFF >> 00:00:32 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FTFF >> 00:00:35 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TFTT >> 00:00:35 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TTFF >> 00:00:38 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FTFT >> 00:01:50 Passed: java/foreign/TestMatrix.java#Downcall-FF >> 00:02:27 Passed: java/foreign/TestMatrix.java#Downcall-TF >> 00:03:03 Passed: java/foreign/TestMatrix.java#Downcall-FT >> 00:03:47 Passed: java/foreign/TestMatrix.java#Downcall-TT >> 00:04:17 Passed: java/foreign/TestMatrix.java#Upcall-FTFF >> 00:04:23 Passed: java/foreign/TestMatrix.java#Upcall-TFFF >> 00:05:46 Passed: java/foreign/TestMatrix.java#Upcall-TTFF >> 00:06:03 Passed: java/foreign/TestMatrix.java#Upcall-TFFT >> 00:06:44 Passed: java/foreign/TestMatrix.java#Upcall-FTFT >> 00:08:24 Passed: java/foreign/TestMatrix.java#Upcall-TFTF >> 00:08:39 Passed: java/foreign/TestMatrix.java#Upcall-TTFT >> 00:09:16 Passed: java/foreign/TestMatrix.java#Upcall-FTTF >> 00:09:19 Passed: java/foreign/TestMatrix.java#Upcall-TFTT >> 00:10:01 Passed: java/foreign/TestMatrix.java#Upcall-FTTT >> 00:10:37 Passed: java/foreign/TestMatrix.java#Upcall-TTTF >> 00:12:16 Passed: java/foreign/TestMatrix.java#Upcall-TTTT >> 00:12:17 Test results: passed: 32 >> 00:12:21 >> 00:12:21 ============================== >> 00:12:21 Test summary >> 00:12:21 ============================== >> 00:12:21 TEST TOTAL PASS FAIL ERROR >> 00:12:21 jtreg:test/jdk/java/foreign/TestMatrix.java 32 32 0 0 >> 00:12:21 ============================== >> >> real 12m20.538s >> user 131m54.043s >> sys 0m59.944s >> >> >> If we don't parallelize, then those 130 minutes are spent serially. > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Go "manual" Marked as reviewed by mcimadamore (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5358 From github.com+44313413+jovanstevanovic at openjdk.java.net Wed Sep 8 12:05:11 2021 From: github.com+44313413+jovanstevanovic at openjdk.java.net (Jovan Stevanovic) Date: Wed, 8 Sep 2021 12:05:11 GMT Subject: RFR: 8273278: Support XSLT on GraalVM Native Image--deterministic bytecode generation in XSLT In-Reply-To: <4sZabPrMuzMcYWhExyMqqljO_ua_LLasEvYE5HcKLWE=.347c45df-b863-45f4-b8a7-dbdbbf3e0c4c@github.com> References: <4sZabPrMuzMcYWhExyMqqljO_ua_LLasEvYE5HcKLWE=.347c45df-b863-45f4-b8a7-dbdbbf3e0c4c@github.com> Message-ID: <-0Cu0XshBpu7xuAmKAdAEar4AZJXisPp3_VRqz3eorQ=.512f9452-5cf3-4398-becb-6715c9d611f4@github.com> On Tue, 7 Sep 2021 23:48:08 GMT, Joe Wang wrote: >> GraalVM Native Image supports loading classes at runtime if they are known during image build (class predefinition). This is achieved by the JVMTI agent that registers dynamically generated classes in a regular HotSpot run. The Native Image build uses these registered classes to embed them into the produced binary so they can be loaded at runtime. Loading at runtime is achieved by matching the unique hash of generated classes. >> >> If the generated bytecode is unstable across runs, the generated native image can not match the hash of the runtime-generated bytecode to the pre-defined classes. The execution failure happens here: >> https://github.com/oracle/graal/blob/master/substratevm/src/com.oracle.svm.core/src/com/oracle/svm/core/hub/PredefinedClassesSupport.java#L127-L131. >> >> In XSLT the produced bytecode is unstable for the following reasons: >> >> - Methods like ` HashMap#values` and `HashMap#keySet` result in different traversal orders of its elements yielding a different order of methods and fields. >> >> - The default `Object#toString` includes the current memory reference of `com.sun.org.apache.xalan.internal.xsltc.compiler.Number` in the generated class. > > Yeah, there hasn't been any major activities (i.e. a minor release) for 7 years. It's also true that the JDK has diverged. @JoeWang-Java We need to backport this to JDK 11 as well. How can we do that? Also, is there anything else I should do to merge these changes after approval? ------------- PR: https://git.openjdk.java.net/jdk/pull/5331 From ihse at openjdk.java.net Wed Sep 8 12:55:03 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 8 Sep 2021 12:55:03 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v4] In-Reply-To: References: Message-ID: On Wed, 8 Sep 2021 09:54:33 GMT, Jaikiran Pai wrote: >> The commit in this PR implements the proposal for enhancement that was discussed in the core-libs-dev mailing list recently[1], for https://bugs.openjdk.java.net/browse/JDK-8231640 >> >> At a high level - the `store()` APIs in `Properties` have been modified to now look for the `SOURCE_DATE_EPOCH` environment variable[2]. If that env variable is set, then instead of writing out the current date time as a date comment, the `store()` APIs instead will use the value set for this env variable to parse it to a `Date` and write out the string form of such a date. The implementation here uses the `d MMM yyyy HH:mm:ss 'GMT'` date format and `Locale.ROOT` to format and write out such a date. This should provide reproducibility whenever the `SOURCE_DATE_EPOCH` is set. Furthermore, intentionally, no changes in the date format of the "current date" have been done. >> >> These modified `store()` APIs work in the presence of the `SecurityManager` too. The caller is expected to have a read permission on the `SOURCE_DATE_EPOCH` environment variable. If the caller doesn't have that permission, then the implementation of these `store()` APIs will write out the "current date" and will ignore any value that has been set for the `SOURCE_DATE_EPOCH` env variable. This should allow for backward compatibility of existing applications, where, when they run under a `SecurityManager` and perhaps with an existing restrictive policy file, the presence of `SOURCE_DATE_EPOCH` shouldn't impact their calls to the `store()` APIs. >> >> The modified `store()` APIs will also ignore any value for `SOURCE_DATE_EPOCH` that cannot be parsed to an `long` value. In such cases, the `store()` APIs will write out the "current date" and ignore the value set for this environment variable. No exceptions will be thrown for such invalid values. This is an additional backward compatibility precaution to prevent any rogue value for `SOURCE_DATE_EPOCH` from breaking applications. >> >> An additional change in the implementation of these `store()` APIs and unrelated to the date comment, is that these APIs will now write out the property keys in a deterministic order. The keys will be written out in the natural ordering as specified by `java.lang.String#compareTo()` API. >> >> The combination of the ordering of the property keys when written out and the usage of `SOURCE_DATE_EPOCH` environment value to determine the date comment should together allow for reproducibility of the output generated by these `store()` APIs. >> >> New jtreg test classes have been introduced to verify these changes. The primary focus of `PropertiesStoreTest` is the ordering aspects of the property keys that are written out. On the other hand `StoreReproducibilityTest` focuses on the reproducibility of the output generated by these APIs. The `StoreReproducibilityTest` runs these tests both in the presence and absence of `SecurityManager`. Plus, in the presence of SecurityManager, it tests both the scenarios where the caller is granted the requisite permission and in other case not granted that permission. >> >> These new tests and existing tests under `test/jdk/java/util/Properties/` pass with these changes. >> >> [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-August/080758.html >> [2] https://reproducible-builds.org/specs/source-date-epoch/ > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > update javadoc @implNote to match latest changes Am I the only one thinking there should also be a way for developers to explicitly disable timestamps from the API? I think the current iteration looks okay (but the core-libs guys of course has the say in this), but I still think we need a new method (or overload) to allow for a timestamp-free to be generated, always, independent of environment variables. ------------- PR: https://git.openjdk.java.net/jdk/pull/5372 From dholmes at openjdk.java.net Wed Sep 8 13:02:05 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 8 Sep 2021 13:02:05 GMT Subject: RFR: 8273487: Zero: Handle "zero" variant in runtime tests In-Reply-To: References: Message-ID: <86fqEtk6YKiecpQFyPaSgjD5XM2xKYfT-BrVcie34lQ=.4ea5f855-cb1a-4246-a1d2-7854c2c04966@github.com> On Wed, 8 Sep 2021 10:57:33 GMT, Aleksey Shipilev wrote: > JDK-8179317 rewritten runtime shell tests to Java. There is a little omission in VM variant selection, which makes Zero fail some of the tier1 tests, like: > > > $ CONF=linux-x86_64-zero-fastdebug make exploded-test TEST=runtime/StackGap/TestStackGap.java > > STDERR: > java.lang.Error: TESTBUG: unsupported vm variant > at jdk.test.lib.Platform.variant(Platform.java:368) > at jdk.test.lib.Platform.jvmLibDir(Platform.java:357) > at jdk.test.lib.process.ProcessTools.addJvmLib(ProcessTools.java:585) > at jdk.test.lib.process.ProcessTools.createNativeTestProcessBuilder(ProcessTools.java:575) > > > Additional testing: > - [ ] Linux x86_64 Zero affected tests (StackGap, StackGuardPages, TestTLS) now run Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5413 From shade at openjdk.java.net Wed Sep 8 13:25:27 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 8 Sep 2021 13:25:27 GMT Subject: RFR: 8273487: Zero: Handle "zero" variant in runtime tests [v2] In-Reply-To: References: Message-ID: > JDK-8179317 rewritten runtime shell tests to Java. There is a little omission in VM variant selection, which makes Zero fail some of the tier1 tests, like: > > > $ CONF=linux-x86_64-zero-fastdebug make exploded-test TEST=runtime/StackGap/TestStackGap.java > > STDERR: > java.lang.Error: TESTBUG: unsupported vm variant > at jdk.test.lib.Platform.variant(Platform.java:368) > at jdk.test.lib.Platform.jvmLibDir(Platform.java:357) > at jdk.test.lib.process.ProcessTools.addJvmLib(ProcessTools.java:585) > at jdk.test.lib.process.ProcessTools.createNativeTestProcessBuilder(ProcessTools.java:575) > > > Additional testing: > - [x] Linux x86_64 Zero affected tests (StackGap, StackGuardPages, TestTLS) now run Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Build system awkwardness ensues ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5413/files - new: https://git.openjdk.java.net/jdk/pull/5413/files/141d8184..40998df5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5413&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5413&range=00-01 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5413.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5413/head:pull/5413 PR: https://git.openjdk.java.net/jdk/pull/5413 From shade at openjdk.java.net Wed Sep 8 13:25:27 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 8 Sep 2021 13:25:27 GMT Subject: RFR: 8273487: Zero: Handle "zero" variant in runtime tests In-Reply-To: References: Message-ID: On Wed, 8 Sep 2021 10:57:33 GMT, Aleksey Shipilev wrote: > JDK-8179317 rewritten runtime shell tests to Java. There is a little omission in VM variant selection, which makes Zero fail some of the tier1 tests, like: > > > $ CONF=linux-x86_64-zero-fastdebug make exploded-test TEST=runtime/StackGap/TestStackGap.java > > STDERR: > java.lang.Error: TESTBUG: unsupported vm variant > at jdk.test.lib.Platform.variant(Platform.java:368) > at jdk.test.lib.Platform.jvmLibDir(Platform.java:357) > at jdk.test.lib.process.ProcessTools.addJvmLib(ProcessTools.java:585) > at jdk.test.lib.process.ProcessTools.createNativeTestProcessBuilder(ProcessTools.java:575) > > > Additional testing: > - [x] Linux x86_64 Zero affected tests (StackGap, StackGuardPages, TestTLS) now run Huh, it turns out there is the awkwardness in the build system that puts product `libjvm.so` to `server` for Zero. See [JDK-8273494](https://bugs.openjdk.java.net/browse/JDK-8273494). This was not the cause for gtest `libjvm.so`, which is in `zero` folder for Zero. So I had to make it more awkward until the build system fix is here. See new commit. ------------- PR: https://git.openjdk.java.net/jdk/pull/5413 From rriggs at openjdk.java.net Wed Sep 8 13:28:11 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 8 Sep 2021 13:28:11 GMT Subject: RFR: 8273369: Computing micros between two instants unexpectedly overflows for some cases [v5] In-Reply-To: <32V0J7ABPauaU7rNH2bLtWokVqg54qHMyTr94orkbqI=.15a84693-5a1e-4699-85fa-d4eb33c68b20@github.com> References: <32V0J7ABPauaU7rNH2bLtWokVqg54qHMyTr94orkbqI=.15a84693-5a1e-4699-85fa-d4eb33c68b20@github.com> Message-ID: On Wed, 8 Sep 2021 00:36:29 GMT, Naoto Sato wrote: >> Please review the fix to the issue. Avoiding overflow by not calling nanosUntil() directly, which will overflow beyond Long.MAX_VALUE difference in nano unit. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Added comments for the test. Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5396 From scolebourne at openjdk.java.net Wed Sep 8 14:02:08 2021 From: scolebourne at openjdk.java.net (Stephen Colebourne) Date: Wed, 8 Sep 2021 14:02:08 GMT Subject: RFR: 8273369: Computing micros between two instants unexpectedly overflows for some cases [v5] In-Reply-To: <32V0J7ABPauaU7rNH2bLtWokVqg54qHMyTr94orkbqI=.15a84693-5a1e-4699-85fa-d4eb33c68b20@github.com> References: <32V0J7ABPauaU7rNH2bLtWokVqg54qHMyTr94orkbqI=.15a84693-5a1e-4699-85fa-d4eb33c68b20@github.com> Message-ID: On Wed, 8 Sep 2021 00:36:29 GMT, Naoto Sato wrote: >> Please review the fix to the issue. Avoiding overflow by not calling nanosUntil() directly, which will overflow beyond Long.MAX_VALUE difference in nano unit. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Added comments for the test. This change looks fine, but I think you also need a `millisUntil` private method to fix the identical overflow problem with millis (which might as well be fixed now). ------------- PR: https://git.openjdk.java.net/jdk/pull/5396 From shade at openjdk.java.net Wed Sep 8 14:05:07 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 8 Sep 2021 14:05:07 GMT Subject: RFR: 8273315: Parallelize and increase timeouts for java/foreign/TestMatrix.java test In-Reply-To: References: Message-ID: On Wed, 8 Sep 2021 11:06:50 GMT, Arno Zeller wrote: > Probably it could be a better solution to add the stress keyword for slow running or high load tests - like it is done in the hotspot part of the tests. Then automated test run can exclude or select these test by keyword. Thought so too, but I think Maurizio wants this test to run only explicitly by those who want to run it. So there needs to be something that disallows automatic runs completely. "manual" seems to be good at this. Do you agree? If you do, I'll integrate. ------------- PR: https://git.openjdk.java.net/jdk/pull/5358 From azeller at openjdk.java.net Wed Sep 8 14:37:11 2021 From: azeller at openjdk.java.net (Arno Zeller) Date: Wed, 8 Sep 2021 14:37:11 GMT Subject: RFR: 8273315: Parallelize and increase timeouts for java/foreign/TestMatrix.java test [v2] In-Reply-To: References: Message-ID: <3nxTX6x10GSKRVlSvUOaDSkhLYZdop4XcJ99DwyA0hc=.dc75a9f5-d8e7-4506-afb8-bdf7bc84e70c@github.com> On Wed, 8 Sep 2021 09:17:31 GMT, Aleksey Shipilev wrote: >> This test runs a lot of configurations, and spends a lot of time serially. This is especially pronounced when run in prospective tier4 runs (JDK-8273314). There are reports of multi-hour runs (see JDK-8271613). We can parallelize the test configurations for this test to make it hurt less. Also, timeouts need to be increased for `TestUpcall` test configs, because some of them are very slow in fastdebug mode. >> >> Sample run: >> >> >> $ time CONF=linux-x86_64-server-fastdebug make run-test TEST=java/foreign/TestMatrix.java | ts -s >> 00:00:00 Building target 'run-test' in configuration 'linux-x86_64-server-fastdebug' >> 00:00:03 Test selection 'java/foreign/TestMatrix.java', will run: >> 00:00:03 * jtreg:test/jdk/java/foreign/TestMatrix.java >> 00:00:03 >> 00:00:03 Running test 'jtreg:test/jdk/java/foreign/TestMatrix.java' >> 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TTFT >> 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FFFF >> 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FFTF >> 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TTTT >> 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FTTT >> 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FFTT >> 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FFFT >> 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TTTF >> 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FTTF >> 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TFFT >> 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TFTF >> 00:00:32 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TFFF >> 00:00:32 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FTFF >> 00:00:35 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TFTT >> 00:00:35 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TTFF >> 00:00:38 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FTFT >> 00:01:50 Passed: java/foreign/TestMatrix.java#Downcall-FF >> 00:02:27 Passed: java/foreign/TestMatrix.java#Downcall-TF >> 00:03:03 Passed: java/foreign/TestMatrix.java#Downcall-FT >> 00:03:47 Passed: java/foreign/TestMatrix.java#Downcall-TT >> 00:04:17 Passed: java/foreign/TestMatrix.java#Upcall-FTFF >> 00:04:23 Passed: java/foreign/TestMatrix.java#Upcall-TFFF >> 00:05:46 Passed: java/foreign/TestMatrix.java#Upcall-TTFF >> 00:06:03 Passed: java/foreign/TestMatrix.java#Upcall-TFFT >> 00:06:44 Passed: java/foreign/TestMatrix.java#Upcall-FTFT >> 00:08:24 Passed: java/foreign/TestMatrix.java#Upcall-TFTF >> 00:08:39 Passed: java/foreign/TestMatrix.java#Upcall-TTFT >> 00:09:16 Passed: java/foreign/TestMatrix.java#Upcall-FTTF >> 00:09:19 Passed: java/foreign/TestMatrix.java#Upcall-TFTT >> 00:10:01 Passed: java/foreign/TestMatrix.java#Upcall-FTTT >> 00:10:37 Passed: java/foreign/TestMatrix.java#Upcall-TTTF >> 00:12:16 Passed: java/foreign/TestMatrix.java#Upcall-TTTT >> 00:12:17 Test results: passed: 32 >> 00:12:21 >> 00:12:21 ============================== >> 00:12:21 Test summary >> 00:12:21 ============================== >> 00:12:21 TEST TOTAL PASS FAIL ERROR >> 00:12:21 jtreg:test/jdk/java/foreign/TestMatrix.java 32 32 0 0 >> 00:12:21 ============================== >> >> real 12m20.538s >> user 131m54.043s >> sys 0m59.944s >> >> >> If we don't parallelize, then those 130 minutes are spent serially. > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Go "manual" I am fine with this solution - it solves my issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/5358 From naoto at openjdk.java.net Wed Sep 8 15:38:10 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 8 Sep 2021 15:38:10 GMT Subject: RFR: 8273369: Computing micros between two instants unexpectedly overflows for some cases [v5] In-Reply-To: References: <32V0J7ABPauaU7rNH2bLtWokVqg54qHMyTr94orkbqI=.15a84693-5a1e-4699-85fa-d4eb33c68b20@github.com> Message-ID: On Wed, 8 Sep 2021 13:58:59 GMT, Stephen Colebourne wrote: > This change looks fine, but I think you also need a `millisUntil` private method to fix the identical overflow problem with millis (which might as well be fixed now). `until()` for millis simply subtracts its `toEpochMilli()` from the end Instant's, so I am not sure that would cause the same false `ArithmeticException`. Can you please elaborate more? ------------- PR: https://git.openjdk.java.net/jdk/pull/5396 From scolebourne at openjdk.java.net Wed Sep 8 15:38:11 2021 From: scolebourne at openjdk.java.net (Stephen Colebourne) Date: Wed, 8 Sep 2021 15:38:11 GMT Subject: RFR: 8273369: Computing micros between two instants unexpectedly overflows for some cases [v5] In-Reply-To: <32V0J7ABPauaU7rNH2bLtWokVqg54qHMyTr94orkbqI=.15a84693-5a1e-4699-85fa-d4eb33c68b20@github.com> References: <32V0J7ABPauaU7rNH2bLtWokVqg54qHMyTr94orkbqI=.15a84693-5a1e-4699-85fa-d4eb33c68b20@github.com> Message-ID: On Wed, 8 Sep 2021 00:36:29 GMT, Naoto Sato wrote: >> Please review the fix to the issue. Avoiding overflow by not calling nanosUntil() directly, which will overflow beyond Long.MAX_VALUE difference in nano unit. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Added comments for the test. `toEpochMilli()` overflows at large/small values. Thus any attempt to calculate the difference between two very large instants would fail. ------------- PR: https://git.openjdk.java.net/jdk/pull/5396 From myano at openjdk.java.net Wed Sep 8 15:51:10 2021 From: myano at openjdk.java.net (Masanori Yano) Date: Wed, 8 Sep 2021 15:51:10 GMT Subject: Integrated: 8269373: some tests in jdk/tools/launcher/ fails on localized Windows platform In-Reply-To: References: Message-ID: On Fri, 25 Jun 2021 12:10:18 GMT, Masanori Yano wrote: > Hi all, > > Could you please review the 8269373 bug fixes? > > These tests call java.lang.ProcessBuilder in direct, so not used jtreg command option. To run non-localized tests, -Duser.language=en and -Duser.country=US options should be added in ProcessBuilder. This pull request has now been integrated. Changeset: cb112aff Author: Masanori Yano Committer: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/cb112affd6061e8ace6dad4e92c7b394a413e37f Stats: 14 lines in 2 files changed: 12 ins; 0 del; 2 mod 8269373: some tests in jdk/tools/launcher/ fails on localized Windows platform Reviewed-by: naoto ------------- PR: https://git.openjdk.java.net/jdk/pull/4594 From github.com+10835776+stsypanov at openjdk.java.net Wed Sep 8 15:58:12 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Wed, 8 Sep 2021 15:58:12 GMT Subject: Integrated: 8273329: Remove redundant null check from String.getBytes(String charsetName) In-Reply-To: References: Message-ID: On Fri, 3 Sep 2021 13:22:54 GMT, ?????? ??????? wrote: > Current implementation looks like this: > > public byte[] getBytes(String charsetName) > throws UnsupportedEncodingException { > if (charsetName == null) throw new NullPointerException(); > return encode(lookupCharset(charsetName), coder(), value); > } > > Null check seems to be redundant here because the same check of `charsetName` is done within `String.lookupCharset(String)`: > > private static Charset lookupCharset(String csn) throws UnsupportedEncodingException { > Objects.requireNonNull(csn); > try { > return Charset.forName(csn); > } catch (UnsupportedCharsetException | IllegalCharsetNameException x) { > throw new UnsupportedEncodingException(csn); > } > } This pull request has now been integrated. Changeset: e5f298a7 Author: Sergey Tsypanov Committer: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/e5f298a7f1f3106b72e43c152c090af1657485f0 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod 8273329: Remove redundant null check from String.getBytes(String charsetName) Reviewed-by: rriggs, iris, naoto ------------- PR: https://git.openjdk.java.net/jdk/pull/5361 From sviswanathan at openjdk.java.net Wed Sep 8 16:11:13 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Wed, 8 Sep 2021 16:11:13 GMT Subject: Integrated: 8273450: Fix the copyright header of SVML files In-Reply-To: <6LV8oNP7aMD5JM5Y6v6D_ozDZg9iDsGEaEk9ScN3KSo=.fea8fb4b-fac7-437a-b6c2-7235c5a589ab@github.com> References: <6LV8oNP7aMD5JM5Y6v6D_ozDZg9iDsGEaEk9ScN3KSo=.fea8fb4b-fac7-437a-b6c2-7235c5a589ab@github.com> Message-ID: On Tue, 7 Sep 2021 20:25:25 GMT, Sandhya Viswanathan wrote: > Fix the copyright header of SVML files to match others. > > This was brought up on jdk-dev mailing list: > https://mail.openjdk.java.net/pipermail/jdk-dev/2021-September/005992.html This pull request has now been integrated. Changeset: d7efd0e8 Author: Sandhya Viswanathan URL: https://git.openjdk.java.net/jdk/commit/d7efd0e8cf14c732427d2c1363b60278bebdc06a Stats: 288 lines in 72 files changed: 144 ins; 0 del; 144 mod 8273450: Fix the copyright header of SVML files Reviewed-by: dholmes, psandoz ------------- PR: https://git.openjdk.java.net/jdk/pull/5399 From sviswanathan at openjdk.java.net Wed Sep 8 16:11:12 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Wed, 8 Sep 2021 16:11:12 GMT Subject: RFR: 8273450: Fix the copyright header of SVML files In-Reply-To: References: <6LV8oNP7aMD5JM5Y6v6D_ozDZg9iDsGEaEk9ScN3KSo=.fea8fb4b-fac7-437a-b6c2-7235c5a589ab@github.com> Message-ID: On Wed, 8 Sep 2021 02:03:12 GMT, Paul Sandoz wrote: >> Fix the copyright header of SVML files to match others. >> >> This was brought up on jdk-dev mailing list: >> https://mail.openjdk.java.net/pipermail/jdk-dev/2021-September/005992.html > > Marked as reviewed by psandoz (Reviewer). Thanks a lot @PaulSandoz for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/5399 From naoto at openjdk.java.net Wed Sep 8 17:40:29 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 8 Sep 2021 17:40:29 GMT Subject: RFR: 8273369: Computing micros between two instants unexpectedly overflows for some cases [v6] In-Reply-To: References: Message-ID: > Please review the fix to the issue. Avoiding overflow by not calling nanosUntil() directly, which will overflow beyond Long.MAX_VALUE difference in nano unit. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Corrected the calculation for MILLIS as well. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5396/files - new: https://git.openjdk.java.net/jdk/pull/5396/files/ccf73bf7..1f6fd470 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5396&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5396&range=04-05 Stats: 24 lines in 3 files changed: 21 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5396.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5396/head:pull/5396 PR: https://git.openjdk.java.net/jdk/pull/5396 From naoto at openjdk.java.net Wed Sep 8 17:40:30 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 8 Sep 2021 17:40:30 GMT Subject: RFR: 8273369: Computing micros between two instants unexpectedly overflows for some cases [v5] In-Reply-To: References: <32V0J7ABPauaU7rNH2bLtWokVqg54qHMyTr94orkbqI=.15a84693-5a1e-4699-85fa-d4eb33c68b20@github.com> Message-ID: On Wed, 8 Sep 2021 15:35:27 GMT, Stephen Colebourne wrote: > `toEpochMilli()` overflows at large/small values. Thus any attempt to calculate the difference between two very large instants would fail. Thanks. Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/5396 From rriggs at openjdk.java.net Wed Sep 8 18:07:09 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 8 Sep 2021 18:07:09 GMT Subject: RFR: 8273369: Computing micros between two instants unexpectedly overflows for some cases [v6] In-Reply-To: References: Message-ID: On Wed, 8 Sep 2021 17:40:29 GMT, Naoto Sato wrote: >> Please review the fix to the issue. Avoiding overflow by not calling nanosUntil() directly, which will overflow beyond Long.MAX_VALUE difference in nano unit. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Corrected the calculation for MILLIS as well. Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5396 From lancea at openjdk.java.net Wed Sep 8 18:10:09 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 8 Sep 2021 18:10:09 GMT Subject: RFR: 8273369: Computing micros between two instants unexpectedly overflows for some cases [v6] In-Reply-To: References: Message-ID: On Wed, 8 Sep 2021 17:40:29 GMT, Naoto Sato wrote: >> Please review the fix to the issue. Avoiding overflow by not calling nanosUntil() directly, which will overflow beyond Long.MAX_VALUE difference in nano unit. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Corrected the calculation for MILLIS as well. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5396 From joehw at openjdk.java.net Wed Sep 8 18:19:04 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Wed, 8 Sep 2021 18:19:04 GMT Subject: RFR: 8273278: Support XSLT on GraalVM Native Image--deterministic bytecode generation in XSLT In-Reply-To: References: Message-ID: On Wed, 1 Sep 2021 13:28:34 GMT, Jovan Stevanovic wrote: > GraalVM Native Image supports loading classes at runtime if they are known during image build (class predefinition). This is achieved by the JVMTI agent that registers dynamically generated classes in a regular HotSpot run. The Native Image build uses these registered classes to embed them into the produced binary so they can be loaded at runtime. Loading at runtime is achieved by matching the unique hash of generated classes. > > If the generated bytecode is unstable across runs, the generated native image can not match the hash of the runtime-generated bytecode to the pre-defined classes. The execution failure happens here: > https://github.com/oracle/graal/blob/master/substratevm/src/com.oracle.svm.core/src/com/oracle/svm/core/hub/PredefinedClassesSupport.java#L127-L131. > > In XSLT the produced bytecode is unstable for the following reasons: > > - Methods like ` HashMap#values` and `HashMap#keySet` result in different traversal orders of its elements yielding a different order of methods and fields. > > - The default `Object#toString` includes the current memory reference of `com.sun.org.apache.xalan.internal.xsltc.compiler.Number` in the generated class. I'm not involved in any older releases. You'll need to find the right channel for a particular backport you want to make and ask there. As for merging the change in the current release, please update the copyright header and the LastModified date for each of the classes. The github interface unfortunately won't allow me to add comments directly to the unchanged code area. Once that's done, you'll need to issue an integrate command. I'll sponsor your change. ------------- PR: https://git.openjdk.java.net/jdk/pull/5331 From stuart.marks at oracle.com Wed Sep 8 19:05:50 2021 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 8 Sep 2021 12:05:50 -0700 Subject: [External] : Re: RFR: 8231640: (prop) Canonical property storage In-Reply-To: References: <0851283f-23f6-a8e6-03c5-d98d29770dbc@oracle.com> <9d26e9cf-f012-564d-7397-445bc2105b92@gmail.com> <596d3276-1764-13a1-bf9c-15c903f32799@oracle.com> Message-ID: <4471ef20-4134-6409-2327-8c603325059f@oracle.com> >> Unless there's an overriding reason, it might be nice to have the output format >> match the format used in the Debian patch that adds SOURCE_DATE_EPOCH: >> >> https://salsa.debian.org/openjdk-team/openjdk/-/blob/master/debian/patches/reproducible-properties-timestamp.diff >> > > So the current patch implementation uses the format "d MMM yyyy HH:mm:ss 'GMT'", > with a Locale.ROOT (for locale neutral formatting). I chose this format since that > was the one that the (deprecated) java.util.Date#toGMTString() was using. > > Roger's suggestion is to use DateTimeFormatter#RFC_1123_DATE_TIME date format which > is "dow, d MMM yyyy HH:mm:ss GMT" (where dow == day of week) > > IMO, either of these formats are "well known", since they are/were used within the > JDK, especially the DateTimeFormatter#RFC_1123_DATE_TIME which Roger suggested, > since that's even a public spec. > > The one in the debian patch is "yyyy-MM-dd HH:mm:ss z" which although is fine to > use, it however feels a bit "less known". > > I was leaning towards Roger's suggestion to use the RFC_1123_DATE_TIME in my > upcoming patch update. Is there a reason why the one in debian's patch is preferable > compared to a spec backed format? My point in bringing this is up is to consider interoperability. I don't have a strong preference over the particular date format. As far as I can see, there are currently two behaviors "in the wild": 1) Baseline OpenJDK 17 behavior: dow mon dd hh:mm:ss zzz yyyy This is the behavior provided by "new Date().toString()" and has likely not changed in many years. Of course, the actual values reflect the current time and locale, which hurts reproducibility, but the format itself hasn't changed. 2) Debian's OpenJDK with SOURCE_DATE_EPOCH set: yyyy-MM-dd HH:mm:ss z The question is, what format should the JDK-8231640 use? I had said earlier that it might be a good idea to match the Debian format. But thinking about this further, I think sticking with the original JDK format would be preferable. The Debian change is after all an outlier. So the more specific question is, should we try to continue with the original JDK format or choose a format that's "better" in some sense? It seems to me that if there's something out there that parses the date from a properties file, we'd want to avoid breaking this code if the environment variable is set. So maybe stick with the original format in all cases. But of course for reproducibility use the epoch value from the environment and set the locale and zone offset to known values. s'marks From smarks at openjdk.java.net Wed Sep 8 19:21:17 2021 From: smarks at openjdk.java.net (Stuart Marks) Date: Wed, 8 Sep 2021 19:21:17 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v3] In-Reply-To: References: <6LwZddwwZyA8VbW2qh932vbw9vdqjtf0auS3JFWF7hA=.01ba8840-07b6-40d9-9a2d-c29f595d8797@github.com> Message-ID: On Wed, 8 Sep 2021 09:32:55 GMT, Jaikiran Pai wrote: >> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision: >> >> - adjust testcases to verify the new semantics >> - implement review suggestions: >> - Use doPriveleged instead of explicit permission checks, to reduce complexity >> - Use DateTimeFormatter and ZonedDateTime instead of Date.toString() >> - Use DateTimeFormatter.RFC_1123_DATE_TIME for formatting SOURCE_DATE_EPOCH dates >> - Use Arrays.sort instead of a TreeMap for ordering property keys > > src/java.base/share/classes/java/util/Properties.java line 963: > >> 961: synchronized (this) { >> 962: var entries = map.entrySet().toArray(new Map.Entry[0]); >> 963: Arrays.sort(entries, new Comparator>() { > > This part here, intentionally doesn't use a lambda, since from what I remember seeing in some mail discussion, it was suggested that using lambda in core parts which get used very early during JVM boostrap, should be avoided. If that's not a concern here, do let me know and I can change it to a lambda. This is a fair concern, but writing out a properties file is a pretty high-level operation that doesn't seem likely to be used during bootstrap. Also, I observe that the `doPrivileged` block above uses a lambda. So I think we're probably ok to use a lambda here. But if you get an inexplicable error at build time or at startup time, this would be the reason why. Assuming we're ok with lambdas, it might be easier to use collections instead of arrays in order to preserve generic types. Unfortunately the map is `Map` so we have to do some fancy casting to get the right type. But then we can use `Map.Entry.comparingByKey()` as the comparator. (Note that this uses lambda internally.) Something like this might work: @SuppressWarnings("unchecked") var entries = new ArrayList<>(((Map)(Map)map).entrySet()); entries.sort(Map.Entry.comparingByKey()); ------------- PR: https://git.openjdk.java.net/jdk/pull/5372 From rriggs at openjdk.java.net Wed Sep 8 19:31:46 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 8 Sep 2021 19:31:46 GMT Subject: RFR: 8273242: (test) Refactor to use TestNG for RuntimeTests ExecCommand tests [v2] In-Reply-To: References: Message-ID: > The ExecCommand test of Runtime.exec is difficult to maintain; the parallel arrays are hard to keep in sync. > This cleanup converts to use TestNG DataProviders and other improvements. Roger Riggs 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 three additional commits since the last revision: - Simplify file deletion Add enum to document test modes. - Merge branch 'master' into 8273242-execcommand-refactor - 8273242: Refactored ExecCommand to use TestNG DataProvider for cases ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5335/files - new: https://git.openjdk.java.net/jdk/pull/5335/files/d374449b..8dbd021e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5335&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5335&range=00-01 Stats: 35582 lines in 1179 files changed: 24923 ins; 5611 del; 5048 mod Patch: https://git.openjdk.java.net/jdk/pull/5335.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5335/head:pull/5335 PR: https://git.openjdk.java.net/jdk/pull/5335 From lancea at openjdk.java.net Wed Sep 8 19:36:11 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 8 Sep 2021 19:36:11 GMT Subject: RFR: 8273242: (test) Refactor to use TestNG for RuntimeTests ExecCommand tests [v2] In-Reply-To: References: Message-ID: On Wed, 8 Sep 2021 19:31:46 GMT, Roger Riggs wrote: >> The ExecCommand test of Runtime.exec is difficult to maintain; the parallel arrays are hard to keep in sync. >> This cleanup converts to use TestNG DataProviders and other improvements. > > Roger Riggs 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 three additional commits since the last revision: > > - Simplify file deletion > Add enum to document test modes. > - Merge branch 'master' into 8273242-execcommand-refactor > - 8273242: Refactored ExecCommand to use TestNG DataProvider for cases Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5335 From rriggs at openjdk.java.net Wed Sep 8 19:36:14 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 8 Sep 2021 19:36:14 GMT Subject: RFR: 8273242: (test) Refactor to use TestNG for RuntimeTests ExecCommand tests [v2] In-Reply-To: References: Message-ID: On Tue, 7 Sep 2021 22:01:54 GMT, Lance Andersen wrote: >> Roger Riggs 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 three additional commits since the last revision: >> >> - Simplify file deletion >> Add enum to document test modes. >> - Merge branch 'master' into 8273242-execcommand-refactor >> - 8273242: Refactored ExecCommand to use TestNG DataProvider for cases > > test/jdk/java/lang/RuntimeTests/exec/ExecCommand.java line 107: > >> 105: private static void deleteOut(String path) { >> 106: try { >> 107: Files.delete(FileSystems.getDefault().getPath(path)); > > More of a curious question, is there a reason you couldn't use Files::deleteIfExists or Path.of() instead of FileSystems.getDefault.... That code is pre-existing. Your suggestion can completely replace the deleteOut method. Tnx ------------- PR: https://git.openjdk.java.net/jdk/pull/5335 From naoto at openjdk.java.net Wed Sep 8 20:06:07 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 8 Sep 2021 20:06:07 GMT Subject: RFR: 8273242: (test) Refactor to use TestNG for RuntimeTests ExecCommand tests [v2] In-Reply-To: References: Message-ID: On Wed, 8 Sep 2021 19:31:46 GMT, Roger Riggs wrote: >> The ExecCommand test of Runtime.exec is difficult to maintain; the parallel arrays are hard to keep in sync. >> This cleanup converts to use TestNG DataProviders and other improvements. > > Roger Riggs 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 three additional commits since the last revision: > > - Simplify file deletion > Add enum to document test modes. > - Merge branch 'master' into 8273242-execcommand-refactor > - 8273242: Refactored ExecCommand to use TestNG DataProvider for cases Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5335 From turbanoff at gmail.com Wed Sep 8 20:28:56 2021 From: turbanoff at gmail.com (Andrey Turbanov) Date: Wed, 8 Sep 2021 23:28:56 +0300 Subject: Confusing javadoc on a method java.lang.StringBuilder#readObject Message-ID: Hello. I found a confusing javadoc of the method java.lang.StringBuilder#readObject: "readObject is called to restore the state of the StringBuffer from a stream." I believe there should be "StringBuilder" instead of "StringBuffer". Andrey Turbanov From igraves at openjdk.java.net Wed Sep 8 20:33:26 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Wed, 8 Sep 2021 20:33:26 GMT Subject: RFR: 8273430: Suspicious duplicate condition in java.util.regex.Grapheme#isExcludedSpacingMark Message-ID: <7eQexh7uLUwH-Mh_P_Hdq4clffXUKIRsHhVBWEUYNuA=.04a7b8fa-ba90-4a01-9c08-99604a76c7c2@github.com> The duplicate condition in this chain of expressions needs to be shrunk to drop a couple of character that are not excluded spacing marks. ------------- Commit messages: - 8273430: Suspicious duplicate condition in java.util.regex.Grapheme#isExcludedSpacingMark Changes: https://git.openjdk.java.net/jdk/pull/5425/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5425&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273430 Stats: 10 lines in 2 files changed: 7 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5425.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5425/head:pull/5425 PR: https://git.openjdk.java.net/jdk/pull/5425 From naoto at openjdk.java.net Wed Sep 8 20:46:07 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 8 Sep 2021 20:46:07 GMT Subject: RFR: 8273430: Suspicious duplicate condition in java.util.regex.Grapheme#isExcludedSpacingMark In-Reply-To: <7eQexh7uLUwH-Mh_P_Hdq4clffXUKIRsHhVBWEUYNuA=.04a7b8fa-ba90-4a01-9c08-99604a76c7c2@github.com> References: <7eQexh7uLUwH-Mh_P_Hdq4clffXUKIRsHhVBWEUYNuA=.04a7b8fa-ba90-4a01-9c08-99604a76c7c2@github.com> Message-ID: On Wed, 8 Sep 2021 20:24:31 GMT, Ian Graves wrote: > The duplicate condition in this chain of expressions needs to be shrunk to drop a couple of character that are not excluded spacing marks. The copyright year in Grapheme.java should be 2021, otherwise looks good. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5425 From bpb at openjdk.java.net Wed Sep 8 20:54:07 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 8 Sep 2021 20:54:07 GMT Subject: RFR: 8255878: FilterInputStream is missing implementations of Java 9 InputStream methods [v2] In-Reply-To: <-XW3tJUbBEPFVXK6CuI6UVU_Flg8V70_9gCjwiFedxI=.2b2061b8-738b-48f6-a931-db3ca3e8ffc2@github.com> References: <73JP6cAapkJpM3afNxR0U1m5I3RxshdsRx5oSJgqEJg=.e9f8fc5d-5992-4ead-bfa6-bbfff3728b59@github.com> <-XW3tJUbBEPFVXK6CuI6UVU_Flg8V70_9gCjwiFedxI=.2b2061b8-738b-48f6-a931-db3ca3e8ffc2@github.com> Message-ID: On Fri, 3 Sep 2021 23:19:22 GMT, Brian Burkhalter wrote: >> This request proposes to modify `java.io.FilterInputStream` to override `readAllBytes()`, `readNBytes(int)`, `skipNBytes(long)`, and `transferTo(OutputStream)` in order to leverage any performance advantage that the wrapped stream might have over the `java.io.InputStream` implementations of these methods. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8255878: Add @implSpec where appropriate Created [JDK-8273513](https://bugs.openjdk.java.net/browse/JDK-8273513). Closing this ill-conceived PR as being of too little value compared to the risk of subclass breakage. ------------- PR: https://git.openjdk.java.net/jdk/pull/5367 From bpb at openjdk.java.net Wed Sep 8 20:54:08 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 8 Sep 2021 20:54:08 GMT Subject: Withdrawn: 8255878: FilterInputStream is missing implementations of Java 9 InputStream methods In-Reply-To: <73JP6cAapkJpM3afNxR0U1m5I3RxshdsRx5oSJgqEJg=.e9f8fc5d-5992-4ead-bfa6-bbfff3728b59@github.com> References: <73JP6cAapkJpM3afNxR0U1m5I3RxshdsRx5oSJgqEJg=.e9f8fc5d-5992-4ead-bfa6-bbfff3728b59@github.com> Message-ID: <8mS-1mMql3fu3rIWC9sJJGUyF-gGHATjXZ3LTPQ8zFY=.e0b40b80-5956-410a-bb9a-97546db697d5@github.com> On Fri, 3 Sep 2021 22:29:19 GMT, Brian Burkhalter wrote: > This request proposes to modify `java.io.FilterInputStream` to override `readAllBytes()`, `readNBytes(int)`, `skipNBytes(long)`, and `transferTo(OutputStream)` in order to leverage any performance advantage that the wrapped stream might have over the `java.io.InputStream` implementations of these methods. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/5367 From rriggs at openjdk.java.net Wed Sep 8 20:57:06 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 8 Sep 2021 20:57:06 GMT Subject: Integrated: 8273242: (test) Refactor to use TestNG for RuntimeTests ExecCommand tests In-Reply-To: References: Message-ID: On Wed, 1 Sep 2021 16:37:24 GMT, Roger Riggs wrote: > The ExecCommand test of Runtime.exec is difficult to maintain; the parallel arrays are hard to keep in sync. > This cleanup converts to use TestNG DataProviders and other improvements. This pull request has now been integrated. Changeset: 7fd6b0bf Author: Roger Riggs URL: https://git.openjdk.java.net/jdk/commit/7fd6b0bfd8ab3c64b374c71010bdfa369f0c67e8 Stats: 288 lines in 1 file changed: 149 ins; 105 del; 34 mod 8273242: (test) Refactor to use TestNG for RuntimeTests ExecCommand tests Reviewed-by: naoto, lancea ------------- PR: https://git.openjdk.java.net/jdk/pull/5335 From coleenp at openjdk.java.net Wed Sep 8 22:06:05 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 8 Sep 2021 22:06:05 GMT Subject: RFR: 8266936: Add a finalization JFR event [v10] In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 15:23:35 GMT, Markus Gr?nlund wrote: >> Greetings, >> >> Object.finalize() was deprecated in JDK9. There is an ongoing effort to replace and mitigate Object.finalize() uses in the JDK libraries; please see https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. >> >> We also like to assist users in replacing and mitigating uses in non-JDK code. >> >> Hence, this changeset adds a periodic JFR event to help identify which classes are overriding Object.finalize(). >> >> Thanks >> Markus > > Markus Gr?nlund has updated the pull request incrementally with three additional commits since the last revision: > > - localize > - cleanup > - FinalizerStatistics I have some general comments and questions about this code. src/hotspot/share/services/classLoadingService.cpp line 80: > 78: > 79: size_t ClassLoadingService::compute_class_size(InstanceKlass* k) { > 80: // lifted from ClassStatistics.do_class(Klass* k) Can you remove this line? I think that function is gone now. src/hotspot/share/services/finalizerService.cpp line 44: > 42: _ik(ik), > 43: _objects_on_heap(0), > 44: _total_finalizers_run(0) {} Is this hashtable for every InstanceKlass that defines a finalizer? How many are there generally? Why couldn't this be a simple hashtable like ResourceHashtable (soon to be renamed) which you can write in only a few lines of code? src/hotspot/share/services/finalizerService.cpp line 114: > 112: > 113: static inline void added() { > 114: set_atomic(&_count); Why isn't Atomic::inc() good enough here? It's used everywhere else. src/hotspot/share/services/finalizerService.cpp line 123: > 121: static inline uintx hash_function(const InstanceKlass* ik) { > 122: assert(ik != nullptr, "invariant"); > 123: return primitive_hash(ik); If the hash function is primitive_hash, this hash is good enough to not need rehashing. The only reason for the rehashing for symbol and string table was that the char* had a dumb hash that was faster but could be hacked, so it needed to become a different hashcode. This doesn't need rehashing. src/hotspot/share/services/finalizerService.cpp line 485: > 483: void FinalizerService::purge_unloaded() { > 484: assert_locked_or_safepoint(ClassLoaderDataGraph_lock); > 485: ClassLoaderDataGraph::classes_unloading_do(&on_unloading); Since you remove entries on unloading, I don't see any reason to have any concurrent cleanup. You do however need in the lookup code, some code that doesn't find the InstanceKlass if !ik->is_loader_alive() ------------- PR: https://git.openjdk.java.net/jdk/pull/4731 From bpb at openjdk.java.net Wed Sep 8 22:11:12 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 8 Sep 2021 22:11:12 GMT Subject: RFR: 8273513: Make java.io.FilterInputStream specification more precise about overrides Message-ID: Modify the class level specification of `java.io.FilterInputStream` to be more exact about `java.io.InputStream` methods that it overrides. ------------- Commit messages: - 8273513: Make java.io.FilterInputStream specification more precise about overrides Changes: https://git.openjdk.java.net/jdk/pull/5426/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5426&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273513 Stats: 53 lines in 1 file changed: 21 ins; 9 del; 23 mod Patch: https://git.openjdk.java.net/jdk/pull/5426.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5426/head:pull/5426 PR: https://git.openjdk.java.net/jdk/pull/5426 From bpb at openjdk.java.net Wed Sep 8 22:11:13 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 8 Sep 2021 22:11:13 GMT Subject: RFR: 8273513: Make java.io.FilterInputStream specification more precise about overrides In-Reply-To: References: Message-ID: On Wed, 8 Sep 2021 22:00:53 GMT, Brian Burkhalter wrote: > Modify the class level specification of `java.io.FilterInputStream` to be more exact about `java.io.InputStream` methods that it overrides. Some other incidental modifications are made in passing, principally adding `@Override` annotations and putting statements like `This method does X` in `@implSpec` blocks. ------------- PR: https://git.openjdk.java.net/jdk/pull/5426 From naoto at openjdk.java.net Wed Sep 8 22:26:28 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 8 Sep 2021 22:26:28 GMT Subject: RFR: 8273188: java/lang/instrument/BootClassPath/BootClassPathTest.sh fails with "FATAL ERROR in native method: processing of -javaagent failed, processJavaStart failed" Message-ID: <4L7o9IPAykqulqdtsqnIgfpObxLUaBgbOSU-F7HBXfg=.fdc31bcb-6b59-4e9c-80ee-e8ea513d6bdc@github.com> The gist of the issue is that the test case now always creates the boot classpath with non-ASCII chars appended, because the default encoding is fixed to UTF-8 with the fix to JDK-8260265. On macOS, javaagent tries to load the class with US-ASCII determined by nl_langinfo() (in unix/.../EncodingSupport_md.c). The file system encoding is always UTF-8 on mac, so no need to use the determined encoding by nl_langinfo(). On Linux, the "defaultEncoding" in Setup.java used to be US-ASCII in "C" locale (which matches the result from nl_langinfo()), so no non-ASCII suffix was appended to the `boot` path. But now the "defaultEncoding" is always UTF-8, the setup code appends the non-ASCII suffix, which fails to read in the native code using iconv with US-ASCII. The setup code should use the encoding from "sun.jnu.encoding" instead. Actually, the code there was copied from UnicodeTest.java which was modified with JDK-8260265, so the same fix needs to be applied. Tier5 run succeeds with one unrelated failure. Also, fixed some typos, e.g. "Uft8" -> "Utf8" ------------- Commit messages: - Merge branch 'master' into JDK-8273188 - 8273188: java/lang/instrument/BootClassPath/BootClassPathTest.sh fails with "FATAL ERROR in native method: processing of -javaagent failed, processJavaStart failed" Changes: https://git.openjdk.java.net/jdk/pull/5427/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5427&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273188 Stats: 36 lines in 8 files changed: 5 ins; 16 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/5427.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5427/head:pull/5427 PR: https://git.openjdk.java.net/jdk/pull/5427 From dholmes at openjdk.java.net Wed Sep 8 23:02:00 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 8 Sep 2021 23:02:00 GMT Subject: RFR: 8273188: java/lang/instrument/BootClassPath/BootClassPathTest.sh fails with "FATAL ERROR in native method: processing of -javaagent failed, processJavaStart failed" In-Reply-To: <4L7o9IPAykqulqdtsqnIgfpObxLUaBgbOSU-F7HBXfg=.fdc31bcb-6b59-4e9c-80ee-e8ea513d6bdc@github.com> References: <4L7o9IPAykqulqdtsqnIgfpObxLUaBgbOSU-F7HBXfg=.fdc31bcb-6b59-4e9c-80ee-e8ea513d6bdc@github.com> Message-ID: On Wed, 8 Sep 2021 22:15:12 GMT, Naoto Sato wrote: > The gist of the issue is that the test case now always creates the boot classpath with non-ASCII chars appended, because the default encoding is fixed to UTF-8 with the fix to JDK-8260265. > > On macOS, javaagent tries to load the class with US-ASCII determined by nl_langinfo() (in unix/.../EncodingSupport_md.c). The file system encoding is always UTF-8 on mac, so no need to use the determined encoding by nl_langinfo(). > > On Linux, the "defaultEncoding" in Setup.java used to be US-ASCII in "C" locale (which matches the result from nl_langinfo()), so no non-ASCII suffix was appended to the `boot` path. But now the "defaultEncoding" is always UTF-8, the setup code appends the non-ASCII suffix, which fails to read in the native code using iconv with US-ASCII. The setup code should use the encoding from "sun.jnu.encoding" instead. Actually, the code there was copied from UnicodeTest.java which was modified with JDK-8260265, so the same fix needs to be applied. > > Tier5 run succeeds with one unrelated failure. Also, fixed some typos, e.g. "Uft8" -> "Utf8" Hi Naoto, > The file system encoding is always UTF-8 on mac, so no need to use the determined encoding by nl_langinfo(). Doesn't it depend on the OS version and which file system is being used? HFS+ seems to use UTF-16 Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/5427 From naoto at openjdk.java.net Wed Sep 8 23:18:03 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 8 Sep 2021 23:18:03 GMT Subject: RFR: 8273188: java/lang/instrument/BootClassPath/BootClassPathTest.sh fails with "FATAL ERROR in native method: processing of -javaagent failed, processJavaStart failed" In-Reply-To: <4L7o9IPAykqulqdtsqnIgfpObxLUaBgbOSU-F7HBXfg=.fdc31bcb-6b59-4e9c-80ee-e8ea513d6bdc@github.com> References: <4L7o9IPAykqulqdtsqnIgfpObxLUaBgbOSU-F7HBXfg=.fdc31bcb-6b59-4e9c-80ee-e8ea513d6bdc@github.com> Message-ID: On Wed, 8 Sep 2021 22:15:12 GMT, Naoto Sato wrote: > The gist of the issue is that the test case now always creates the boot classpath with non-ASCII chars appended, because the default encoding is fixed to UTF-8 with the fix to JDK-8260265. > > On macOS, javaagent tries to load the class with US-ASCII determined by nl_langinfo() (in unix/.../EncodingSupport_md.c). The file system encoding is always UTF-8 on mac, so no need to use the determined encoding by nl_langinfo(). > > On Linux, the "defaultEncoding" in Setup.java used to be US-ASCII in "C" locale (which matches the result from nl_langinfo()), so no non-ASCII suffix was appended to the `boot` path. But now the "defaultEncoding" is always UTF-8, the setup code appends the non-ASCII suffix, which fails to read in the native code using iconv with US-ASCII. The setup code should use the encoding from "sun.jnu.encoding" instead. Actually, the code there was copied from UnicodeTest.java which was modified with JDK-8260265, so the same fix needs to be applied. > > Tier5 run succeeds with one unrelated failure. Also, fixed some typos, e.g. "Uft8" -> "Utf8" Hi David, > Doesn't it depend on the OS version and which file system is being used? HFS+ seems to use UTF-16 Right. I was not clear enough as to `file system encoding`, what I meant was the `sun.jnu.encoding`, which is always `UTF-8` with this change: https://bugs.openjdk.java.net/browse/JDK-8003228 ------------- PR: https://git.openjdk.java.net/jdk/pull/5427 From dholmes at openjdk.java.net Wed Sep 8 23:21:00 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 8 Sep 2021 23:21:00 GMT Subject: RFR: 8273487: Zero: Handle "zero" variant in runtime tests [v2] In-Reply-To: References: Message-ID: On Wed, 8 Sep 2021 13:25:27 GMT, Aleksey Shipilev wrote: >> JDK-8179317 rewritten runtime shell tests to Java. There is a little omission in VM variant selection, which makes Zero fail some of the tier1 tests, like: >> >> >> $ CONF=linux-x86_64-zero-fastdebug make exploded-test TEST=runtime/StackGap/TestStackGap.java >> >> STDERR: >> java.lang.Error: TESTBUG: unsupported vm variant >> at jdk.test.lib.Platform.variant(Platform.java:368) >> at jdk.test.lib.Platform.jvmLibDir(Platform.java:357) >> at jdk.test.lib.process.ProcessTools.addJvmLib(ProcessTools.java:585) >> at jdk.test.lib.process.ProcessTools.createNativeTestProcessBuilder(ProcessTools.java:575) >> >> >> Additional testing: >> - [x] Linux x86_64 Zero affected tests (StackGap, StackGuardPages, TestTLS) now run > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Build system awkwardness ensues Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5413 From dholmes at openjdk.java.net Wed Sep 8 23:41:57 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 8 Sep 2021 23:41:57 GMT Subject: RFR: 8273188: java/lang/instrument/BootClassPath/BootClassPathTest.sh fails with "FATAL ERROR in native method: processing of -javaagent failed, processJavaStart failed" In-Reply-To: <4L7o9IPAykqulqdtsqnIgfpObxLUaBgbOSU-F7HBXfg=.fdc31bcb-6b59-4e9c-80ee-e8ea513d6bdc@github.com> References: <4L7o9IPAykqulqdtsqnIgfpObxLUaBgbOSU-F7HBXfg=.fdc31bcb-6b59-4e9c-80ee-e8ea513d6bdc@github.com> Message-ID: On Wed, 8 Sep 2021 22:15:12 GMT, Naoto Sato wrote: > The gist of the issue is that the test case now always creates the boot classpath with non-ASCII chars appended, because the default encoding is fixed to UTF-8 with the fix to JDK-8260265. > > On macOS, javaagent tries to load the class with US-ASCII determined by nl_langinfo() (in unix/.../EncodingSupport_md.c). The file system encoding is always UTF-8 on mac, so no need to use the determined encoding by nl_langinfo(). > > On Linux, the "defaultEncoding" in Setup.java used to be US-ASCII in "C" locale (which matches the result from nl_langinfo()), so no non-ASCII suffix was appended to the `boot` path. But now the "defaultEncoding" is always UTF-8, the setup code appends the non-ASCII suffix, which fails to read in the native code using iconv with US-ASCII. The setup code should use the encoding from "sun.jnu.encoding" instead. Actually, the code there was copied from UnicodeTest.java which was modified with JDK-8260265, so the same fix needs to be applied. > > Tier5 run succeeds with one unrelated failure. Also, fixed some typos, e.g. "Uft8" -> "Utf8" Hi Naoto, Based on what you've said the core functional change seems okay. Good catch on the uft typo! Pre-existing: The initialization logic in this code is quite odd for the case when no conversion is necessary (we call `utfInitialize` on every call to `convertUtf8ToPlatformString`!), but I assume we do not call `appendBootClassPath` and `appendToClassLoaderSearch` very often? Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5427 From naoto at openjdk.java.net Wed Sep 8 23:53:03 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 8 Sep 2021 23:53:03 GMT Subject: RFR: 8273188: java/lang/instrument/BootClassPath/BootClassPathTest.sh fails with "FATAL ERROR in native method: processing of -javaagent failed, processJavaStart failed" In-Reply-To: References: <4L7o9IPAykqulqdtsqnIgfpObxLUaBgbOSU-F7HBXfg=.fdc31bcb-6b59-4e9c-80ee-e8ea513d6bdc@github.com> Message-ID: On Wed, 8 Sep 2021 23:38:38 GMT, David Holmes wrote: > Pre-existing: The initialization logic in this code is quite odd for the case when no conversion is necessary (we call `utfInitialize` on every call to `convertUtf8ToPlatformString`!), but I assume we do not call `appendBootClassPath` and `appendToClassLoaderSearch` very often? Indeed. I assume those methods are only used on agent startup. ------------- PR: https://git.openjdk.java.net/jdk/pull/5427 From bpb at openjdk.java.net Thu Sep 9 01:03:06 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 9 Sep 2021 01:03:06 GMT Subject: RFR: 8273513: Make java.io.FilterInputStream specification more precise about overrides In-Reply-To: References: Message-ID: On Wed, 8 Sep 2021 22:00:53 GMT, Brian Burkhalter wrote: > Modify the class level specification of `java.io.FilterInputStream` to be more exact about `java.io.InputStream` methods that it overrides. CSR filed: [JDK-8273517](https://bugs.openjdk.java.net/browse/JDK-8273517). ------------- PR: https://git.openjdk.java.net/jdk/pull/5426 From wuyan at openjdk.java.net Thu Sep 9 02:12:03 2021 From: wuyan at openjdk.java.net (Wu Yan) Date: Thu, 9 Sep 2021 02:12:03 GMT Subject: RFR: 8268231: Aarch64: Use ldp in intrinsics for String.compareTo [v7] In-Reply-To: References: Message-ID: On Tue, 7 Sep 2021 01:38:02 GMT, Nick Gasson wrote: > Please check the Windows tier1 failure: https://github.com/Wanghuang-Huawei/jdk/runs/3459332995 > > Seems unlikely that it's anything to do with this patch so you may just want to re-run it or merge from master. OK, The rerun of presubmit test show that it passed all tests. The result is here: https://github.com/Wanghuang-Huawei/jdk/actions/runs/1181122290 ------------- PR: https://git.openjdk.java.net/jdk/pull/4722 From ngasson at openjdk.java.net Thu Sep 9 03:10:00 2021 From: ngasson at openjdk.java.net (Nick Gasson) Date: Thu, 9 Sep 2021 03:10:00 GMT Subject: RFR: 8268231: Aarch64: Use ldp in intrinsics for String.compareTo [v7] In-Reply-To: References: Message-ID: On Mon, 30 Aug 2021 06:26:01 GMT, Wang Huang wrote: >> Dear all, >> Can you do me a favor to review this patch. This patch use `ldp` to implement String.compareTo. >> >> * We add a JMH test case >> * Here is the result of this test case >> >> Benchmark |(size)| Mode| Cnt|Score | Error |Units >> ---------------------------------|------|-----|----|------|--------|----- >> StringCompare.compareLL | 64 | avgt| 5 |7.992 | ? 0.005|us/op >> StringCompare.compareLL | 72 | avgt| 5 |15.029| ? 0.006|us/op >> StringCompare.compareLL | 80 | avgt| 5 |14.655| ? 0.011|us/op >> StringCompare.compareLL | 91 | avgt| 5 |16.363| ? 0.12 |us/op >> StringCompare.compareLL | 101 | avgt| 5 |16.966| ? 0.007|us/op >> StringCompare.compareLL | 121 | avgt| 5 |19.276| ? 0.006|us/op >> StringCompare.compareLL | 181 | avgt| 5 |19.002| ? 0.417|us/op >> StringCompare.compareLL | 256 | avgt| 5 |24.707| ? 0.041|us/op >> StringCompare.compareLLWithLdp| 64 | avgt| 5 |8.001 | ? 0.121|us/op >> StringCompare.compareLLWithLdp| 72 | avgt| 5 |11.573| ? 0.003|us/op >> StringCompare.compareLLWithLdp| 80 | avgt| 5 |6.861 | ? 0.004|us/op >> StringCompare.compareLLWithLdp| 91 | avgt| 5 |12.774| ? 0.201|us/op >> StringCompare.compareLLWithLdp| 101 | avgt| 5 |8.691 | ? 0.004|us/op >> StringCompare.compareLLWithLdp| 121 | avgt| 5 |11.091| ? 1.342|us/op >> StringCompare.compareLLWithLdp| 181 | avgt| 5 |14.64 | ? 0.581|us/op >> StringCompare.compareLLWithLdp| 256 | avgt| 5 |25.879| ? 1.775|us/op >> StringCompare.compareUU | 64 | avgt| 5 |13.476| ? 0.01 |us/op >> StringCompare.compareUU | 72 | avgt| 5 |15.078| ? 0.006|us/op >> StringCompare.compareUU | 80 | avgt| 5 |23.512| ? 0.011|us/op >> StringCompare.compareUU | 91 | avgt| 5 |24.284| ? 0.008|us/op >> StringCompare.compareUU | 101 | avgt| 5 |20.707| ? 0.017|us/op >> StringCompare.compareUU | 121 | avgt| 5 |29.302| ? 0.011|us/op >> StringCompare.compareUU | 181 | avgt| 5 |39.31 | ? 0.016|us/op >> StringCompare.compareUU | 256 | avgt| 5 |54.592| ? 0.392|us/op >> StringCompare.compareUUWithLdp| 64 | avgt| 5 |16.389| ? 0.008|us/op >> StringCompare.compareUUWithLdp| 72 | avgt| 5 |10.71 | ? 0.158|us/op >> StringCompare.compareUUWithLdp| 80 | avgt| 5 |11.488| ? 0.024|us/op >> StringCompare.compareUUWithLdp| 91 | avgt| 5 |13.412| ? 0.006|us/op >> StringCompare.compareUUWithLdp| 101 | avgt| 5 |16.245| ? 0.434|us/op >> StringCompare.compareUUWithLdp| 121 | avgt| 5 |16.597| ? 0.016|us/op >> StringCompare.compareUUWithLdp| 181 | avgt| 5 |27.373| ? 0.017|us/op >> StringCompare.compareUUWithLdp| 256 | avgt| 5 |41.74 | ? 3.5 |us/op >> >> From this table, we can see that in most cases, our patch is better than old one. >> >> Thank you for your review. Any suggestions are welcome. > > Wang Huang has updated the pull request incrementally with one additional commit since the last revision: > > fix windows build failed Marked as reviewed by ngasson (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4722 From igraves at openjdk.java.net Thu Sep 9 04:27:16 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Thu, 9 Sep 2021 04:27:16 GMT Subject: RFR: 8273514: java/util/DoubleStreamSums/CompensatedSums.java failure Message-ID: Relaxing some assertion bounds to allow for small error values that still show improvement over previous summation method. ------------- Commit messages: - Dropping unnecessary equals case - Dropping equals zero assert Changes: https://git.openjdk.java.net/jdk/pull/5430/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5430&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273514 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5430.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5430/head:pull/5430 PR: https://git.openjdk.java.net/jdk/pull/5430 From jpai at openjdk.java.net Thu Sep 9 05:37:32 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Thu, 9 Sep 2021 05:37:32 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v5] In-Reply-To: References: Message-ID: > The commit in this PR implements the proposal for enhancement that was discussed in the core-libs-dev mailing list recently[1], for https://bugs.openjdk.java.net/browse/JDK-8231640 > > At a high level - the `store()` APIs in `Properties` have been modified to now look for the `SOURCE_DATE_EPOCH` environment variable[2]. If that env variable is set, then instead of writing out the current date time as a date comment, the `store()` APIs instead will use the value set for this env variable to parse it to a `Date` and write out the string form of such a date. The implementation here uses the `d MMM yyyy HH:mm:ss 'GMT'` date format and `Locale.ROOT` to format and write out such a date. This should provide reproducibility whenever the `SOURCE_DATE_EPOCH` is set. Furthermore, intentionally, no changes in the date format of the "current date" have been done. > > These modified `store()` APIs work in the presence of the `SecurityManager` too. The caller is expected to have a read permission on the `SOURCE_DATE_EPOCH` environment variable. If the caller doesn't have that permission, then the implementation of these `store()` APIs will write out the "current date" and will ignore any value that has been set for the `SOURCE_DATE_EPOCH` env variable. This should allow for backward compatibility of existing applications, where, when they run under a `SecurityManager` and perhaps with an existing restrictive policy file, the presence of `SOURCE_DATE_EPOCH` shouldn't impact their calls to the `store()` APIs. > > The modified `store()` APIs will also ignore any value for `SOURCE_DATE_EPOCH` that cannot be parsed to an `long` value. In such cases, the `store()` APIs will write out the "current date" and ignore the value set for this environment variable. No exceptions will be thrown for such invalid values. This is an additional backward compatibility precaution to prevent any rogue value for `SOURCE_DATE_EPOCH` from breaking applications. > > An additional change in the implementation of these `store()` APIs and unrelated to the date comment, is that these APIs will now write out the property keys in a deterministic order. The keys will be written out in the natural ordering as specified by `java.lang.String#compareTo()` API. > > The combination of the ordering of the property keys when written out and the usage of `SOURCE_DATE_EPOCH` environment value to determine the date comment should together allow for reproducibility of the output generated by these `store()` APIs. > > New jtreg test classes have been introduced to verify these changes. The primary focus of `PropertiesStoreTest` is the ordering aspects of the property keys that are written out. On the other hand `StoreReproducibilityTest` focuses on the reproducibility of the output generated by these APIs. The `StoreReproducibilityTest` runs these tests both in the presence and absence of `SecurityManager`. Plus, in the presence of SecurityManager, it tests both the scenarios where the caller is granted the requisite permission and in other case not granted that permission. > > These new tests and existing tests under `test/jdk/java/util/Properties/` pass with these changes. > > [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-August/080758.html > [2] https://reproducible-builds.org/specs/source-date-epoch/ Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision: - Implement Stuart's suggestion to use Collections instead of Arrays for ordering property keys - update the new tests to match the new date format expectations and also print out some log messages for better debuggability of the tests - Implement Stuart's suggestion on date format: - use the same format for both when writing current date as well as when SOURCE_DATE_EPOCH is set - the format matches the one used in java.util.Date.toString() to preserve backward compatibility - when SOURCE_DATE_EPOCH is set, although the format is the same, the timezone is fixed to UTC and locale is set to ROOT to provide reproducibility of the generated comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5372/files - new: https://git.openjdk.java.net/jdk/pull/5372/files/867ec999..7736a8f2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5372&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5372&range=03-04 Stats: 30 lines in 3 files changed: 9 ins; 5 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/5372.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5372/head:pull/5372 PR: https://git.openjdk.java.net/jdk/pull/5372 From cay.horstmann at gmail.com Thu Sep 9 05:43:36 2021 From: cay.horstmann at gmail.com (Cay Horstmann) Date: Thu, 9 Sep 2021 07:43:36 +0200 Subject: How can I trigger a @Serial warning? Message-ID: <2f2afdb5-c5a0-0cce-a492-8d589b8f058a@gmail.com> I am trying to give an example of the utility of the @Serial annotation. But the JDK 17 javac doesn't seem to do anything with it. I tried: @Serial private void readObject(java.io.ObjectInputStream stream, int shouldNotHaveThisParam) throws IOException, ClassNotFoundException @Serial private static final String serialVersionUID = "Fred"; @Serial public String getName() { ... } Is there some flag that I need to use? I tried -Xlint:serial, but it didn't make a difference. Thanks, Cay -- Cay S. Horstmann | http://horstmann.com | mailto:cay at horstmann.com From jpai at openjdk.java.net Thu Sep 9 05:46:34 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Thu, 9 Sep 2021 05:46:34 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v6] In-Reply-To: References: Message-ID: > The commit in this PR implements the proposal for enhancement that was discussed in the core-libs-dev mailing list recently[1], for https://bugs.openjdk.java.net/browse/JDK-8231640 > > At a high level - the `store()` APIs in `Properties` have been modified to now look for the `SOURCE_DATE_EPOCH` environment variable[2]. If that env variable is set, then instead of writing out the current date time as a date comment, the `store()` APIs instead will use the value set for this env variable to parse it to a `Date` and write out the string form of such a date. The implementation here uses the `d MMM yyyy HH:mm:ss 'GMT'` date format and `Locale.ROOT` to format and write out such a date. This should provide reproducibility whenever the `SOURCE_DATE_EPOCH` is set. Furthermore, intentionally, no changes in the date format of the "current date" have been done. > > These modified `store()` APIs work in the presence of the `SecurityManager` too. The caller is expected to have a read permission on the `SOURCE_DATE_EPOCH` environment variable. If the caller doesn't have that permission, then the implementation of these `store()` APIs will write out the "current date" and will ignore any value that has been set for the `SOURCE_DATE_EPOCH` env variable. This should allow for backward compatibility of existing applications, where, when they run under a `SecurityManager` and perhaps with an existing restrictive policy file, the presence of `SOURCE_DATE_EPOCH` shouldn't impact their calls to the `store()` APIs. > > The modified `store()` APIs will also ignore any value for `SOURCE_DATE_EPOCH` that cannot be parsed to an `long` value. In such cases, the `store()` APIs will write out the "current date" and ignore the value set for this environment variable. No exceptions will be thrown for such invalid values. This is an additional backward compatibility precaution to prevent any rogue value for `SOURCE_DATE_EPOCH` from breaking applications. > > An additional change in the implementation of these `store()` APIs and unrelated to the date comment, is that these APIs will now write out the property keys in a deterministic order. The keys will be written out in the natural ordering as specified by `java.lang.String#compareTo()` API. > > The combination of the ordering of the property keys when written out and the usage of `SOURCE_DATE_EPOCH` environment value to determine the date comment should together allow for reproducibility of the output generated by these `store()` APIs. > > New jtreg test classes have been introduced to verify these changes. The primary focus of `PropertiesStoreTest` is the ordering aspects of the property keys that are written out. On the other hand `StoreReproducibilityTest` focuses on the reproducibility of the output generated by these APIs. The `StoreReproducibilityTest` runs these tests both in the presence and absence of `SecurityManager`. Plus, in the presence of SecurityManager, it tests both the scenarios where the caller is granted the requisite permission and in other case not granted that permission. > > These new tests and existing tests under `test/jdk/java/util/Properties/` pass with these changes. > > [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-August/080758.html > [2] https://reproducible-builds.org/specs/source-date-epoch/ Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: update javadoc to match latest changes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5372/files - new: https://git.openjdk.java.net/jdk/pull/5372/files/7736a8f2..c9d3cb8f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5372&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5372&range=04-05 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/5372.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5372/head:pull/5372 PR: https://git.openjdk.java.net/jdk/pull/5372 From jai.forums2013 at gmail.com Thu Sep 9 07:06:47 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Thu, 9 Sep 2021 12:36:47 +0530 Subject: [External] : Re: RFR: 8231640: (prop) Canonical property storage In-Reply-To: <4471ef20-4134-6409-2327-8c603325059f@oracle.com> References: <0851283f-23f6-a8e6-03c5-d98d29770dbc@oracle.com> <9d26e9cf-f012-564d-7397-445bc2105b92@gmail.com> <596d3276-1764-13a1-bf9c-15c903f32799@oracle.com> <4471ef20-4134-6409-2327-8c603325059f@oracle.com> Message-ID: <1b96cd23-6ff5-4b43-ae18-a370c1713e2d@gmail.com> Hello Stuart, On 09/09/21 12:35 am, Stuart Marks wrote: > > >>> Unless there's an overriding reason, it might be nice to have the >>> output format match the format used in the Debian patch that adds >>> SOURCE_DATE_EPOCH: >>> >>> https://salsa.debian.org/openjdk-team/openjdk/-/blob/master/debian/patches/reproducible-properties-timestamp.diff >>> >> >> So the current patch implementation uses the format "d MMM yyyy >> HH:mm:ss 'GMT'", with a Locale.ROOT (for locale neutral formatting). >> I chose this format since that was the one that the (deprecated) >> java.util.Date#toGMTString() was using. >> >> Roger's suggestion is to use DateTimeFormatter#RFC_1123_DATE_TIME >> date format which is "dow, d MMM yyyy HH:mm:ss GMT" (where dow == day >> of week) >> >> IMO, either of these formats are "well known", since they are/were >> used within the JDK, especially the >> DateTimeFormatter#RFC_1123_DATE_TIME which Roger suggested, since >> that's even a public spec. >> >> The one in the debian patch is "yyyy-MM-dd HH:mm:ss z" which although >> is fine to use, it however feels a bit "less known". >> >> I was leaning towards Roger's suggestion to use the >> RFC_1123_DATE_TIME in my upcoming patch update. Is there a reason why >> the one in debian's patch is preferable compared to a spec backed >> format? > > My point in bringing this is up is to consider interoperability. I > don't have a strong preference over the particular date format. As far > as I can see, there are currently two behaviors "in the wild": > > 1) Baseline OpenJDK 17 behavior: > > ??? dow mon dd hh:mm:ss zzz yyyy > > This is the behavior provided by "new Date().toString()" and has > likely not changed in many years. Of course, the actual values reflect > the current time and locale, which hurts reproducibility, but the > format itself hasn't changed. > > 2) Debian's OpenJDK with SOURCE_DATE_EPOCH set: > > ??? yyyy-MM-dd HH:mm:ss z > > The question is, what format should the JDK-8231640 use? > > I had said earlier that it might be a good idea to match the Debian > format. But thinking about this further, I think sticking with the > original JDK format would be preferable. The Debian change is after > all an outlier. > > So the more specific question is, should we try to continue with the > original JDK format or choose a format that's "better" in some sense? > It seems to me that if there's something out there that parses the > date from a properties file, we'd want to avoid breaking this code if > the environment variable is set. So maybe stick with the original > format in all cases. But of course for reproducibility use the epoch > value from the environment and set the locale and zone offset to known > values. All this makes sense. So I've updated the PR to continue to use the same date format that java.util.Date.toString() was using, in both the cases - while writing out the current date (in absence of SOURCE_DATE_EPOCH) and while writing out the SOURCE_DATE_EPOCH. While writing out the SOURCE_DATE_EPOCH, we will however fix the timezone to UTC and locale to ROOT for reproducibility. -Jaikiran From jai.forums2013 at gmail.com Thu Sep 9 07:14:40 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Thu, 9 Sep 2021 12:44:40 +0530 Subject: RFR: 8231640: (prop) Canonical property storage [v3] In-Reply-To: References: <6LwZddwwZyA8VbW2qh932vbw9vdqjtf0auS3JFWF7hA=.01ba8840-07b6-40d9-9a2d-c29f595d8797@github.com> Message-ID: On 09/09/21 12:51 am, Stuart Marks wrote: > On Wed, 8 Sep 2021 09:32:55 GMT, Jaikiran Pai wrote: > >>> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision: >>> >>> - adjust testcases to verify the new semantics >>> - implement review suggestions: >>> - Use doPriveleged instead of explicit permission checks, to reduce complexity >>> - Use DateTimeFormatter and ZonedDateTime instead of Date.toString() >>> - Use DateTimeFormatter.RFC_1123_DATE_TIME for formatting SOURCE_DATE_EPOCH dates >>> - Use Arrays.sort instead of a TreeMap for ordering property keys >> src/java.base/share/classes/java/util/Properties.java line 963: >> >>> 961: synchronized (this) { >>> 962: var entries = map.entrySet().toArray(new Map.Entry[0]); >>> 963: Arrays.sort(entries, new Comparator>() { >> This part here, intentionally doesn't use a lambda, since from what I remember seeing in some mail discussion, it was suggested that using lambda in core parts which get used very early during JVM boostrap, should be avoided. If that's not a concern here, do let me know and I can change it to a lambda. > This is a fair concern, but writing out a properties file is a pretty high-level operation that doesn't seem likely to be used during bootstrap. Also, I observe that the `doPrivileged` block above uses a lambda. So I think we're probably ok to use a lambda here. But if you get an inexplicable error at build time or at startup time, this would be the reason why. Good catch about the doPriveleged block currently using the lambda. I had overlooked that part. > Assuming we're ok with lambdas, it might be easier to use collections instead of arrays in order to preserve generic types. That usage of lambda in doPriveleged hasn't caused any issues (due to the lazy/delayed implementation this PR uses to parse the environment variable). So I think using lambdas in the store() implementation should be fine then. > Unfortunately the map is `Map` so we have to do some fancy casting to get the right type. But then we can use `Map.Entry.comparingByKey()` as the comparator. (Note that this uses lambda internally.) > > Something like this might work: > > > @SuppressWarnings("unchecked") > var entries = new ArrayList<>(((Map)(Map)map).entrySet()); > entries.sort(Map.Entry.comparingByKey()); Thank you for this snippet (learned something new :)). I've now updated the PR to use this version instead of the Arrays.sort(...) one. I've rerun a modified JMH benchmark, comparing this version with the Arrays.sort(...) version and this one performs slightly better too, so performance shouldn't be a concern here. package org.myapp; import org.openjdk.jmh.annotations.Benchmark; import java.util.*; import java.util.concurrent.*; import org.openjdk.jmh.annotations.*; public class MyBenchmark { ??? @State(Scope.Thread) ??? public static class TestData { ??????? static final Map tenItems; ??????? static final Map hundredItems; ??????? static final Map thousandItems; ??????? static { ??????????? tenItems = new ConcurrentHashMap<>(8); ??????????? hundredItems = new ConcurrentHashMap<>(8); ??????????? thousandItems = new ConcurrentHashMap<>(8); ??????????? for (int i = 0; i < 1000; i++) { ??????????????? thousandItems.put("foo" + i, "bar"); ??????????????? if (i < 100) { ??????????????????? hundredItems.put("hello" + i, "world"); ??????????????? } ??????????????? if (i < 10) { ??????????????????? tenItems.put("good" + i, "morning"); ??????????????? } ??????????? } ??????????? System.out.println("Test data created with " + tenItems.size() + ", " ??????????????? + hundredItems.size() + " and " + thousandItems.size() + " Map keys"); ??????? } ??? } ??? @Benchmark ??? @BenchmarkMode(Mode.AverageTime) ??? @OutputTimeUnit(TimeUnit.MICROSECONDS) ??? public void testTenItemsCollectionSorting(TestData testData) { ??????? @SuppressWarnings("unchecked") ??????? var entries = new ArrayList<>(((Map) (Map) testData.tenItems).entrySet()); ??????? entries.sort(Map.Entry.comparingByKey()); ??? } ??? @Benchmark ??? @BenchmarkMode(Mode.AverageTime) ??? @OutputTimeUnit(TimeUnit.MICROSECONDS) ??? public void testHundredItemsCollectionSorting(TestData testData) { ??????? @SuppressWarnings("unchecked") ??????? var entries = new ArrayList<>(((Map) (Map) testData.hundredItems).entrySet()); ??????? entries.sort(Map.Entry.comparingByKey()); ??? } ??? @Benchmark ??? @BenchmarkMode(Mode.AverageTime) ??? @OutputTimeUnit(TimeUnit.MICROSECONDS) ??? public void testThousandItemsCollectionSorting(TestData testData) { ??????? @SuppressWarnings("unchecked") ??????? var entries = new ArrayList<>(((Map) (Map) testData.thousandItems).entrySet()); ??????? entries.sort(Map.Entry.comparingByKey()); ??? } ??? @Benchmark ??? @BenchmarkMode(Mode.AverageTime) ??? @OutputTimeUnit(TimeUnit.MICROSECONDS) ??? public void testTenItemsArraySorting(TestData testData) { ??????? var entries = testData.tenItems.entrySet().toArray(new Map.Entry[0]); ??????? Arrays.sort(entries, new Comparator>() { ??????????? @Override ??????????? public int compare(Map.Entry o1, Map.Entry o2) { ??????????????? return ((String) o1.getKey()).compareTo((String) o2.getKey()); ??????????? } ??????? }); ??? } ??? @Benchmark ??? @BenchmarkMode(Mode.AverageTime) ??? @OutputTimeUnit(TimeUnit.MICROSECONDS) ??? public void testHundredItemsArraySorting(TestData testData) { ??????? var entries = testData.hundredItems.entrySet().toArray(new Map.Entry[0]); ??????? Arrays.sort(entries, new Comparator>() { ??????????? @Override ??????????? public int compare(Map.Entry o1, Map.Entry o2) { ??????????????? return ((String) o1.getKey()).compareTo((String) o2.getKey()); ??????????? } ??????? }); ??? } ??? @Benchmark ??? @BenchmarkMode(Mode.AverageTime) ??? @OutputTimeUnit(TimeUnit.MICROSECONDS) ??? public void testThousandItemsArraySorting(TestData testData) { ??????? var entries = testData.thousandItems.entrySet().toArray(new Map.Entry[0]); ??????? Arrays.sort(entries, new Comparator>() { ??????????? @Override ??????????? public int compare(Map.Entry o1, Map.Entry o2) { ??????????????? return ((String) o1.getKey()).compareTo((String) o2.getKey()); ??????????? } ??????? }); ??? } } Benchmark?????????????????????????????????????? Mode? Cnt Score?? Error? Units MyBenchmark.testHundredItemsArraySorting??????? avgt?? 25??? 8.375 ? 0.119? us/op MyBenchmark.testHundredItemsCollectionSorting?? avgt?? 25??? 7.608 ? 0.118? us/op MyBenchmark.testTenItemsArraySorting??????????? avgt?? 25??? 0.261 ? 0.004? us/op MyBenchmark.testTenItemsCollectionSorting?????? avgt?? 25??? 0.234 ? 0.004? us/op MyBenchmark.testThousandItemsArraySorting?????? avgt?? 25? 150.934 ? 2.865? us/op MyBenchmark.testThousandItemsCollectionSorting? avgt?? 25? 149.356 ? 4.381? us/op -Jaikiran From shade at openjdk.java.net Thu Sep 9 07:47:04 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 9 Sep 2021 07:47:04 GMT Subject: Integrated: 8273315: Parallelize and increase timeouts for java/foreign/TestMatrix.java test In-Reply-To: References: Message-ID: On Fri, 3 Sep 2021 09:53:53 GMT, Aleksey Shipilev wrote: > This test runs a lot of configurations, and spends a lot of time serially. This is especially pronounced when run in prospective tier4 runs (JDK-8273314). There are reports of multi-hour runs (see JDK-8271613). We can parallelize the test configurations for this test to make it hurt less. Also, timeouts need to be increased for `TestUpcall` test configs, because some of them are very slow in fastdebug mode. > > Sample run: > > > $ time CONF=linux-x86_64-server-fastdebug make run-test TEST=java/foreign/TestMatrix.java | ts -s > 00:00:00 Building target 'run-test' in configuration 'linux-x86_64-server-fastdebug' > 00:00:03 Test selection 'java/foreign/TestMatrix.java', will run: > 00:00:03 * jtreg:test/jdk/java/foreign/TestMatrix.java > 00:00:03 > 00:00:03 Running test 'jtreg:test/jdk/java/foreign/TestMatrix.java' > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TTFT > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FFFF > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FFTF > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TTTT > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FTTT > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FFTT > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FFFT > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TTTF > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FTTF > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TFFT > 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TFTF > 00:00:32 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TFFF > 00:00:32 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FTFF > 00:00:35 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TFTT > 00:00:35 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TTFF > 00:00:38 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FTFT > 00:01:50 Passed: java/foreign/TestMatrix.java#Downcall-FF > 00:02:27 Passed: java/foreign/TestMatrix.java#Downcall-TF > 00:03:03 Passed: java/foreign/TestMatrix.java#Downcall-FT > 00:03:47 Passed: java/foreign/TestMatrix.java#Downcall-TT > 00:04:17 Passed: java/foreign/TestMatrix.java#Upcall-FTFF > 00:04:23 Passed: java/foreign/TestMatrix.java#Upcall-TFFF > 00:05:46 Passed: java/foreign/TestMatrix.java#Upcall-TTFF > 00:06:03 Passed: java/foreign/TestMatrix.java#Upcall-TFFT > 00:06:44 Passed: java/foreign/TestMatrix.java#Upcall-FTFT > 00:08:24 Passed: java/foreign/TestMatrix.java#Upcall-TFTF > 00:08:39 Passed: java/foreign/TestMatrix.java#Upcall-TTFT > 00:09:16 Passed: java/foreign/TestMatrix.java#Upcall-FTTF > 00:09:19 Passed: java/foreign/TestMatrix.java#Upcall-TFTT > 00:10:01 Passed: java/foreign/TestMatrix.java#Upcall-FTTT > 00:10:37 Passed: java/foreign/TestMatrix.java#Upcall-TTTF > 00:12:16 Passed: java/foreign/TestMatrix.java#Upcall-TTTT > 00:12:17 Test results: passed: 32 > 00:12:21 > 00:12:21 ============================== > 00:12:21 Test summary > 00:12:21 ============================== > 00:12:21 TEST TOTAL PASS FAIL ERROR > 00:12:21 jtreg:test/jdk/java/foreign/TestMatrix.java 32 32 0 0 > 00:12:21 ============================== > > real 12m20.538s > user 131m54.043s > sys 0m59.944s > > > If we don't parallelize, then those 130 minutes are spent serially. This pull request has now been integrated. Changeset: dc33bd8b Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/dc33bd8b6cfa9a9cd71d7065d284a807774750a2 Stats: 281 lines in 1 file changed: 219 ins; 28 del; 34 mod 8273315: Parallelize and increase timeouts for java/foreign/TestMatrix.java test Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.java.net/jdk/pull/5358 From shade at openjdk.java.net Thu Sep 9 08:10:09 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 9 Sep 2021 08:10:09 GMT Subject: RFR: 8273487: Zero: Handle "zero" variant in runtime tests [v2] In-Reply-To: References: Message-ID: On Wed, 8 Sep 2021 13:25:27 GMT, Aleksey Shipilev wrote: >> JDK-8179317 rewritten runtime shell tests to Java. There is a little omission in VM variant selection, which makes Zero fail some of the tier1 tests, like: >> >> >> $ CONF=linux-x86_64-zero-fastdebug make exploded-test TEST=runtime/StackGap/TestStackGap.java >> >> STDERR: >> java.lang.Error: TESTBUG: unsupported vm variant >> at jdk.test.lib.Platform.variant(Platform.java:368) >> at jdk.test.lib.Platform.jvmLibDir(Platform.java:357) >> at jdk.test.lib.process.ProcessTools.addJvmLib(ProcessTools.java:585) >> at jdk.test.lib.process.ProcessTools.createNativeTestProcessBuilder(ProcessTools.java:575) >> >> >> Additional testing: >> - [x] Linux x86_64 Zero affected tests (StackGap, StackGuardPages, TestTLS) now run > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Build system awkwardness ensues I am integrating this to get the more complete `tier1` runs for Zero, and then I would tackle JDK-8273494. ------------- PR: https://git.openjdk.java.net/jdk/pull/5413 From shade at openjdk.java.net Thu Sep 9 08:10:10 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 9 Sep 2021 08:10:10 GMT Subject: Integrated: 8273487: Zero: Handle "zero" variant in runtime tests In-Reply-To: References: Message-ID: <5FZ8wHoYKStQS8Vipmacd9L_xUmUpo0lsKjhFA6ALeE=.9282d76e-f1d8-441e-a6e9-d968328213bf@github.com> On Wed, 8 Sep 2021 10:57:33 GMT, Aleksey Shipilev wrote: > JDK-8179317 rewritten runtime shell tests to Java. There is a little omission in VM variant selection, which makes Zero fail some of the tier1 tests, like: > > > $ CONF=linux-x86_64-zero-fastdebug make exploded-test TEST=runtime/StackGap/TestStackGap.java > > STDERR: > java.lang.Error: TESTBUG: unsupported vm variant > at jdk.test.lib.Platform.variant(Platform.java:368) > at jdk.test.lib.Platform.jvmLibDir(Platform.java:357) > at jdk.test.lib.process.ProcessTools.addJvmLib(ProcessTools.java:585) > at jdk.test.lib.process.ProcessTools.createNativeTestProcessBuilder(ProcessTools.java:575) > > > Additional testing: > - [x] Linux x86_64 Zero affected tests (StackGap, StackGuardPages, TestTLS) now run This pull request has now been integrated. Changeset: 8c16f485 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/8c16f485b341ee3071c91df39dfb9ba8b9caa44d Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod 8273487: Zero: Handle "zero" variant in runtime tests Reviewed-by: alanb, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/5413 From wuyan at openjdk.java.net Thu Sep 9 08:25:44 2021 From: wuyan at openjdk.java.net (Wu Yan) Date: Thu, 9 Sep 2021 08:25:44 GMT Subject: RFR: 8273111: Default timezone should return zone ID if /etc/localtime is valid but not canonicalization on linux [v2] In-Reply-To: <6gmVj3r1hjhG5jvo_dSly3ShNnZZSCn-NIjtnvSySrk=.a88def27-7b80-425b-9ab8-2f94f5004b47@github.com> References: <6gmVj3r1hjhG5jvo_dSly3ShNnZZSCn-NIjtnvSySrk=.a88def27-7b80-425b-9ab8-2f94f5004b47@github.com> Message-ID: > Hi, > Please help me review the change to enhance getting time zone ID from /etc/localtime on linux. > > We use `realpath` instead of `readlink` to obtain the link name of /etc/localtime, because `readlink` can only read the value of a symbolic of link, not the canonicalized absolute pathname. > > For example, the value of /etc/localtime is "../usr/share/zoneinfo//Asia/Shanghai", then the linkbuf obtained by `readlink` is "../usr/share/zoneinfo//Asia/Shanghai", and then the call of `getZoneName(linkbuf)` will get "/Asia/Shanghai", not "Asia/Shanghai", which consider as invalid in `ZoneInfoFile.getZoneInfo()`. Using `realpath`, you can get ?/usr/share/zoneinfo/Asia/Shanghai? directly from ?/etc/localtime?. > > Thanks, > wuyan Wu Yan has updated the pull request incrementally with one additional commit since the last revision: replace realpath ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5327/files - new: https://git.openjdk.java.net/jdk/pull/5327/files/9b29edfc..19cc634d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5327&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5327&range=00-01 Stats: 395 lines in 4 files changed: 241 ins; 145 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/5327.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5327/head:pull/5327 PR: https://git.openjdk.java.net/jdk/pull/5327 From jai.forums2013 at gmail.com Thu Sep 9 08:27:30 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Thu, 9 Sep 2021 13:57:30 +0530 Subject: Proposal: JDK-8231640 - (prop) Canonical property storage In-Reply-To: References: <9b90a43f-defc-5100-3b5a-0a69214a706c@gmail.com> <86a3469a-7107-8c32-3240-28b10b470f87@oracle.com> <2c98d073-5a22-9732-b828-c1a08314d1a0@gmail.com> <6d97bada-0388-cb5c-bbbc-2712764e559b@gmail.com> <983f15b6-96e3-9aeb-c203-baea91dd1b24@oracle.com> Message-ID: On 31/08/21 7:09 pm, Jaikiran Pai wrote: > Hello Magnus, > > On 30/08/21 5:29 pm, Magnus Ihse Bursie wrote: >> >> >> On 2021-08-28 17:16, Alan Bateman wrote: >>> On 28/08/2021 05:45, Jaikiran Pai wrote: >>>> I hadn't considered the system property approach to switch to old >>>> behaviour in my proposals, so this is a very good input and I >>>> personally think the most logical proposals so far. >>> >>> Roger may be right that few would care but it would be changing >>> behavior that goes back to JDK 1.0. In your list (and thanks for >>> writing down the options with pros/cons) then your 1a where >>> SOURCE_DATE_EPOCH changes to write the epoch date rather than the >>> current date seems to be most consistent with other tools and the >>> wider eco system. It seems the least disruptive in that it doesn't >>> change existing behavior and would be opt-in when reproducibility is >>> required. Previous discussion was leading towards your option 2 (or >>> variants of) but isn't option doesn't help the cases where build >>> tools use libraries that rely on the older methods. >> >> If I understood the numbering and alternatives correctly, I don't >> think there is a conflict between 1a and 2, and I think both should >> be implemented, for different reasons. >> >> This is my understanding of the options, with the rationale I see for >> choosing them: >> >> * 1a says that we change the store() method to write the date from >> SOURCE_DATE_EPOCH, if it is set -- otherwise it keeps the old >> behavior. This allows users who want to use old Java code (or code >> they can't modify) to produce output in a reproducible way to do so >> without changing the source code of the product. >> >> * 2 says that we add a new override to store() which also takes an >> Instant. This way programmers who write new code and want to make >> sure it is always reproducible can send in Instant.EPOCH, and not >> rely on the user to configure SOURCE_DATE_EPOCH. >> >> (In fact, when thinking of it, this seems overly complex. There is no >> real need to send in a generic Instant, just an override with a >> boolean skipTimestamp, or something like that. Basically, any >> solution which allows programmers who write new code to get property >> files without timestamps easily, is what's needed to fulfill this spot. >> > I do agree that it would be good to just get rid of the date comment > and let callers control what exact comments (if any) get written out. > However, I think that having both - a new method (overloaded or named > differently) and at the same time changing the implementation of the > existing store(...) methods to make the date comment reproducible is a > bit of a overkill for a comment that doesn't even play a functional > role in that API. I listed that option of a new overloaded API and > would have been in favour of it, if that was the only addition/change > that we did to support the date comment disabling/reproducibility. > > Having said that, I will gladly go ahead and include/work on that > additional new API, if there is some general agreement on doing so. > The PR[1] related to the changes that have been agreed upon in this discussion has reached a decent state, I think. There's however still a valid question from Magnus. I am pasting that comment from Magnus, from the PR, here: "Am I the only one thinking there should also be a way for developers to explicitly disable timestamps from the API? I think the current iteration looks okay (but the core-libs guys of course has the say in this), but I still think we need a new method (or overload) to allow for a timestamp-free to be generated, always, independent of environment variables." Magnus, I too think that there should be a way to completely get rid of the date comment. It's my opinion that this date comment is almost useless for Java programs because the Properties.load() doesn't load any comments. So whatever/whoever is relying on these properties is most likely going to be external (non-Java) scripts/tooling or some really specific/odd Java code which reads this stored properties file, per line and does something with the date comment. Highly unlikely but still possible. So far, from what I have followed, no one has stated that they use the date comment in some form. I even searched JBS issues to see if there was any hint of this usage. On the contrary, I found an (old) issue where someone asked for disabling the date comment altogether and they explained a use case where they think the current default of writing out that comment isn't helpful[2]. At the same time, I think the concern for backward compatibility is valid, plus the concern that introducing a new store API (either overloaded or differently named) which allows reproducibility plus the ability to disable date comment, will require existing code to migrate to this new ones, which realistically takes many years. So, if callers/users still want to get rid of the date comment when dealing with the Properties.store() APIs, we could ask them to come up with a custom implementation which extends the java.util.Properties class. That is easier said than done, because the store() APIs have very involved logic when it comes to formatting and writing out the key/values of that instance. That logic is private to the java.util.Properties, which effectively means these custom extended classes can't use it (unless they copy it over and make these implementations very brittle). So extending/overriding the entirety of these store() APIs is realistically ruled out. Having said all that and reviewing again the potential options that I listed in my earlier mail, I think there's probably a more easier middle ground here, which allows callers/tools/libraries to control whether or not the date comment gets written out. So here's a proposal which might help - how about, *in addition to* what we have already done in this PR, we also introduce a new protected method in java.util.Properties which looks like: /** ?* Returns {@code true} if the {@link #store} methods of this properties ?* instance must write out the date comment. Returns {@code false} otherwise. ?* @since 18 ?*/ protected boolean mustStoreDateComment() { ? // by default we store a date comment ? return true; } (ignore any javadoc issues, please :)) Then the implementation of existing store() APIs in java.util.Properties, can call this method to decide whether or not to write out a date comment. By default, the implementation of this new mustStoreDateComment() in java.util.Properties will return true, which means there shouldn't be any backward compatibility issues. At the same time this will allow tools/libraries/callers to extend the java.util.Properties class and (only) override this method to return false, if they want to disable writing out the date comment. The advantage of this would be: ?- Ability to fully disable the date comment and have full control on what comments (if any) get written out by the existing store() APIs ?- These custom extended classes don't have to worry or deal with the formatting rules of key/values that the existing store() APIs will continue to take care off. ?- No system property or additional environment variable necessary for disabling the date comment altogether - The JDK will still have full control on how the date comment is written out and will continue to write it out in a reproducible manner when SOURCE_DATE_EPOCH is set. ?- The new "protected" API, IMO, doesn't introduce a big new API surface, unlike the previously proposed overloaded or differently named variants of the store() APIs. The name of this new method of course is something that can be decided - I just came up with that name just to explain what I mean. Is this something that is acceptable and worth adding? [1] https://github.com/openjdk/jdk/pull/5372 [2] https://bugs.openjdk.java.net/browse/JDK-5032603 -Jaikiran From jpai at openjdk.java.net Thu Sep 9 08:33:59 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Thu, 9 Sep 2021 08:33:59 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v6] In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 05:46:34 GMT, Jaikiran Pai wrote: >> The commit in this PR implements the proposal for enhancement that was discussed in the core-libs-dev mailing list recently[1], for https://bugs.openjdk.java.net/browse/JDK-8231640 >> >> At a high level - the `store()` APIs in `Properties` have been modified to now look for the `SOURCE_DATE_EPOCH` environment variable[2]. If that env variable is set, then instead of writing out the current date time as a date comment, the `store()` APIs instead will use the value set for this env variable to parse it to a `Date` and write out the string form of such a date. The implementation here uses the `d MMM yyyy HH:mm:ss 'GMT'` date format and `Locale.ROOT` to format and write out such a date. This should provide reproducibility whenever the `SOURCE_DATE_EPOCH` is set. Furthermore, intentionally, no changes in the date format of the "current date" have been done. >> >> These modified `store()` APIs work in the presence of the `SecurityManager` too. The caller is expected to have a read permission on the `SOURCE_DATE_EPOCH` environment variable. If the caller doesn't have that permission, then the implementation of these `store()` APIs will write out the "current date" and will ignore any value that has been set for the `SOURCE_DATE_EPOCH` env variable. This should allow for backward compatibility of existing applications, where, when they run under a `SecurityManager` and perhaps with an existing restrictive policy file, the presence of `SOURCE_DATE_EPOCH` shouldn't impact their calls to the `store()` APIs. >> >> The modified `store()` APIs will also ignore any value for `SOURCE_DATE_EPOCH` that cannot be parsed to an `long` value. In such cases, the `store()` APIs will write out the "current date" and ignore the value set for this environment variable. No exceptions will be thrown for such invalid values. This is an additional backward compatibility precaution to prevent any rogue value for `SOURCE_DATE_EPOCH` from breaking applications. >> >> An additional change in the implementation of these `store()` APIs and unrelated to the date comment, is that these APIs will now write out the property keys in a deterministic order. The keys will be written out in the natural ordering as specified by `java.lang.String#compareTo()` API. >> >> The combination of the ordering of the property keys when written out and the usage of `SOURCE_DATE_EPOCH` environment value to determine the date comment should together allow for reproducibility of the output generated by these `store()` APIs. >> >> New jtreg test classes have been introduced to verify these changes. The primary focus of `PropertiesStoreTest` is the ordering aspects of the property keys that are written out. On the other hand `StoreReproducibilityTest` focuses on the reproducibility of the output generated by these APIs. The `StoreReproducibilityTest` runs these tests both in the presence and absence of `SecurityManager`. Plus, in the presence of SecurityManager, it tests both the scenarios where the caller is granted the requisite permission and in other case not granted that permission. >> >> These new tests and existing tests under `test/jdk/java/util/Properties/` pass with these changes. >> >> [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-August/080758.html >> [2] https://reproducible-builds.org/specs/source-date-epoch/ > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > update javadoc to match latest changes Hello Magnus, > Am I the only one thinking there should also be a way for developers to explicitly disable timestamps from the API? > > I think the current iteration looks okay (but the core-libs guys of course has the say in this), but I still think we need a new method (or overload) to allow for a timestamp-free to be generated, always, independent of environment variables. I decided to take this comment to the mailing list[1] where the proposal for this change was discussed, since it's likely more people will be watching that thread than this RFR thread. [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-September/081305.html ------------- PR: https://git.openjdk.java.net/jdk/pull/5372 From wuyan at openjdk.java.net Thu Sep 9 08:59:08 2021 From: wuyan at openjdk.java.net (Wu Yan) Date: Thu, 9 Sep 2021 08:59:08 GMT Subject: RFR: 8273111: Default timezone should return zone ID if /etc/localtime is valid but not canonicalization on linux [v2] In-Reply-To: References: <6gmVj3r1hjhG5jvo_dSly3ShNnZZSCn-NIjtnvSySrk=.a88def27-7b80-425b-9ab8-2f94f5004b47@github.com> Message-ID: On Thu, 9 Sep 2021 08:25:44 GMT, Wu Yan wrote: >> Hi, >> Please help me review the change to enhance getting time zone ID from /etc/localtime on linux. >> >> We use `realpath` instead of `readlink` to obtain the link name of /etc/localtime, because `readlink` can only read the value of a symbolic of link, not the canonicalized absolute pathname. >> >> For example, the value of /etc/localtime is "../usr/share/zoneinfo//Asia/Shanghai", then the linkbuf obtained by `readlink` is "../usr/share/zoneinfo//Asia/Shanghai", and then the call of `getZoneName(linkbuf)` will get "/Asia/Shanghai", not "Asia/Shanghai", which consider as invalid in `ZoneInfoFile.getZoneInfo()`. Using `realpath`, you can get ?/usr/share/zoneinfo/Asia/Shanghai? directly from ?/etc/localtime?. >> >> Thanks, >> wuyan > > Wu Yan has updated the pull request incrementally with one additional commit since the last revision: > > replace realpath Hi, we directly process the characters in `linkbuf` instead of realpath. And we reuse [collapse()](https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/libjava/canonicalize_md.c#L129) to process the '.' and '..' in `linkbuf`. We tested some cases about /etc/localtime, and it works well. Test cases and results are in the attachment. [testcase.log](https://github.com/openjdk/jdk/files/7135028/testcase.log) [result.log](https://github.com/openjdk/jdk/files/7135030/result.log) ------------- PR: https://git.openjdk.java.net/jdk/pull/5327 From dfuchs at openjdk.java.net Thu Sep 9 09:01:07 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 9 Sep 2021 09:01:07 GMT Subject: RFR: 8273513: Make java.io.FilterInputStream specification more precise about overrides In-Reply-To: References: Message-ID: <7LURs8iUMwwIXjbhFvASWn2W-gzHSJuHrZfUx57lULc=.403e6b91-ded2-43ad-98ad-2b019b3ae146@github.com> On Wed, 8 Sep 2021 22:00:53 GMT, Brian Burkhalter wrote: > Modify the class level specification of `java.io.FilterInputStream` to be more exact about `java.io.InputStream` methods that it overrides. LGTM. The use of `synchronized` on `mark()` and `reset()` is strange. But I guess that should be for another day... ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5426 From mbaesken at openjdk.java.net Thu Sep 9 09:29:14 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Thu, 9 Sep 2021 09:29:14 GMT Subject: RFR: JDK-8273526: Extend the OSContainer API pids controller with pids.current Message-ID: https://bugs.openjdk.java.net/browse/JDK-8266490 extended the OSContainer API in order to also support the pids controller of cgroups. However only pids.max output was added with 8266490. There is a second parameter pids.current , see https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#pid that would be helpful too and can be added to the OSContainer API . pids.current : A read-only single value file which exists on all cgroups. The number of processes currently in the cgroup and its descendants. Best regards, Matthias ------------- Commit messages: - JDK-8273526 Changes: https://git.openjdk.java.net/jdk/pull/5437/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5437&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273526 Stats: 104 lines in 15 files changed: 102 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5437.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5437/head:pull/5437 PR: https://git.openjdk.java.net/jdk/pull/5437 From jpai at openjdk.java.net Thu Sep 9 09:56:30 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Thu, 9 Sep 2021 09:56:30 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v7] In-Reply-To: References: Message-ID: > The commit in this PR implements the proposal for enhancement that was discussed in the core-libs-dev mailing list recently[1], for https://bugs.openjdk.java.net/browse/JDK-8231640 > > At a high level - the `store()` APIs in `Properties` have been modified to now look for the `SOURCE_DATE_EPOCH` environment variable[2]. If that env variable is set, then instead of writing out the current date time as a date comment, the `store()` APIs instead will use the value set for this env variable to parse it to a `Date` and write out the string form of such a date. The implementation here uses the `d MMM yyyy HH:mm:ss 'GMT'` date format and `Locale.ROOT` to format and write out such a date. This should provide reproducibility whenever the `SOURCE_DATE_EPOCH` is set. Furthermore, intentionally, no changes in the date format of the "current date" have been done. > > These modified `store()` APIs work in the presence of the `SecurityManager` too. The caller is expected to have a read permission on the `SOURCE_DATE_EPOCH` environment variable. If the caller doesn't have that permission, then the implementation of these `store()` APIs will write out the "current date" and will ignore any value that has been set for the `SOURCE_DATE_EPOCH` env variable. This should allow for backward compatibility of existing applications, where, when they run under a `SecurityManager` and perhaps with an existing restrictive policy file, the presence of `SOURCE_DATE_EPOCH` shouldn't impact their calls to the `store()` APIs. > > The modified `store()` APIs will also ignore any value for `SOURCE_DATE_EPOCH` that cannot be parsed to an `long` value. In such cases, the `store()` APIs will write out the "current date" and ignore the value set for this environment variable. No exceptions will be thrown for such invalid values. This is an additional backward compatibility precaution to prevent any rogue value for `SOURCE_DATE_EPOCH` from breaking applications. > > An additional change in the implementation of these `store()` APIs and unrelated to the date comment, is that these APIs will now write out the property keys in a deterministic order. The keys will be written out in the natural ordering as specified by `java.lang.String#compareTo()` API. > > The combination of the ordering of the property keys when written out and the usage of `SOURCE_DATE_EPOCH` environment value to determine the date comment should together allow for reproducibility of the output generated by these `store()` APIs. > > New jtreg test classes have been introduced to verify these changes. The primary focus of `PropertiesStoreTest` is the ordering aspects of the property keys that are written out. On the other hand `StoreReproducibilityTest` focuses on the reproducibility of the output generated by these APIs. The `StoreReproducibilityTest` runs these tests both in the presence and absence of `SecurityManager`. Plus, in the presence of SecurityManager, it tests both the scenarios where the caller is granted the requisite permission and in other case not granted that permission. > > These new tests and existing tests under `test/jdk/java/util/Properties/` pass with these changes. > > [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-August/080758.html > [2] https://reproducible-builds.org/specs/source-date-epoch/ Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: dummy commit to trigger GitHub actions job to try and reproduce an unexplained failure with the new tests that happened around 24 hours back, this time yesterday (rule out any time/date/timezone specific issues) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5372/files - new: https://git.openjdk.java.net/jdk/pull/5372/files/c9d3cb8f..a29d0f08 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5372&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5372&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5372.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5372/head:pull/5372 PR: https://git.openjdk.java.net/jdk/pull/5372 From magnus.ihse.bursie at oracle.com Thu Sep 9 10:04:32 2021 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 9 Sep 2021 12:04:32 +0200 Subject: Proposal: JDK-8231640 - (prop) Canonical property storage In-Reply-To: References: <9b90a43f-defc-5100-3b5a-0a69214a706c@gmail.com> <86a3469a-7107-8c32-3240-28b10b470f87@oracle.com> <2c98d073-5a22-9732-b828-c1a08314d1a0@gmail.com> <6d97bada-0388-cb5c-bbbc-2712764e559b@gmail.com> <983f15b6-96e3-9aeb-c203-baea91dd1b24@oracle.com> Message-ID: On 2021-09-09 10:27, Jaikiran Pai wrote: > > > On 31/08/21 7:09 pm, Jaikiran Pai wrote: >> Hello Magnus, >> >> On 30/08/21 5:29 pm, Magnus Ihse Bursie wrote: >>> >>> >>> On 2021-08-28 17:16, Alan Bateman wrote: >>>> On 28/08/2021 05:45, Jaikiran Pai wrote: >>>>> I hadn't considered the system property approach to switch to old >>>>> behaviour in my proposals, so this is a very good input and I >>>>> personally think the most logical proposals so far. >>>> >>>> Roger may be right that few would care but it would be changing >>>> behavior that goes back to JDK 1.0. In your list (and thanks for >>>> writing down the options with pros/cons) then your 1a where >>>> SOURCE_DATE_EPOCH changes to write the epoch date rather than the >>>> current date seems to be most consistent with other tools and the >>>> wider eco system. It seems the least disruptive in that it doesn't >>>> change existing behavior and would be opt-in when reproducibility >>>> is required. Previous discussion was leading towards your option 2 >>>> (or variants of) but isn't option doesn't help the cases where >>>> build tools use libraries that rely on the older methods. >>> >>> If I understood the numbering and alternatives correctly, I don't >>> think there is a conflict between 1a and 2, and I think both should >>> be implemented, for different reasons. >>> >>> This is my understanding of the options, with the rationale I see >>> for choosing them: >>> >>> * 1a says that we change the store() method to write the date from >>> SOURCE_DATE_EPOCH, if it is set -- otherwise it keeps the old >>> behavior. This allows users who want to use old Java code (or code >>> they can't modify) to produce output in a reproducible way to do so >>> without changing the source code of the product. >>> >>> * 2 says that we add a new override to store() which also takes an >>> Instant. This way programmers who write new code and want to make >>> sure it is always reproducible can send in Instant.EPOCH, and not >>> rely on the user to configure SOURCE_DATE_EPOCH. >>> >>> (In fact, when thinking of it, this seems overly complex. There is >>> no real need to send in a generic Instant, just an override with a >>> boolean skipTimestamp, or something like that. Basically, any >>> solution which allows programmers who write new code to get property >>> files without timestamps easily, is what's needed to fulfill this spot. >>> >> I do agree that it would be good to just get rid of the date comment >> and let callers control what exact comments (if any) get written out. >> However, I think that having both - a new method (overloaded or named >> differently) and at the same time changing the implementation of the >> existing store(...) methods to make the date comment reproducible is >> a bit of a overkill for a comment that doesn't even play a functional >> role in that API. I listed that option of a new overloaded API and >> would have been in favour of it, if that was the only addition/change >> that we did to support the date comment disabling/reproducibility. >> >> Having said that, I will gladly go ahead and include/work on that >> additional new API, if there is some general agreement on doing so. >> > The PR[1] related to the changes that have been agreed upon in this > discussion has reached a decent state, I think. There's however still > a valid question from Magnus. I am pasting that comment from Magnus, > from the PR, here: > > "Am I the only one thinking there should also be a way for > developers to explicitly disable timestamps from the API? > > I think the current iteration looks okay (but the core-libs guys > of course has the say in this), but I still think we need a new > method (or overload) to allow for a timestamp-free to be > generated, always, independent of environment variables." > > Magnus, I too think that there should be a way to completely get rid > of the date comment. It's my opinion that this date comment is almost > useless for Java programs because the Properties.load() doesn't load > any comments. So whatever/whoever is relying on these properties is > most likely going to be external (non-Java) scripts/tooling or some > really specific/odd Java code which reads this stored properties file, > per line and does something with the date comment. Highly unlikely but > still possible. So far, from what I have followed, no one has stated > that they use the date comment in some form. I even searched JBS > issues to see if there was any hint of this usage. On the contrary, I > found an (old) issue where someone asked for disabling the date > comment altogether and they explained a use case where they think the > current default of writing out that comment isn't helpful[2]. > > At the same time, I think the concern for backward compatibility is > valid, plus the concern that introducing a new store API (either > overloaded or differently named) which allows reproducibility plus the > ability to disable date comment, will require existing code to migrate > to this new ones, which realistically takes many years. > > So, if callers/users still want to get rid of the date comment when > dealing with the Properties.store() APIs, we could ask them to come up > with a custom implementation which extends the java.util.Properties > class. That is easier said than done, because the store() APIs have > very involved logic when it comes to formatting and writing out the > key/values of that instance. That logic is private to the > java.util.Properties, which effectively means these custom extended > classes can't use it (unless they copy it over and make these > implementations very brittle). So extending/overriding the entirety of > these store() APIs is realistically ruled out. > > Having said all that and reviewing again the potential options that I > listed in my earlier mail, I think there's probably a more easier > middle ground here, which allows callers/tools/libraries to control > whether or not the date comment gets written out. So here's a proposal > which might help - how about, *in addition to* what we have already > done in this PR, we also introduce a new protected method in > java.util.Properties which looks like: > > /** > ?* Returns {@code true} if the {@link #store} methods of this properties > ?* instance must write out the date comment. Returns {@code false} > otherwise. > ?* @since 18 > ?*/ > protected boolean mustStoreDateComment() { > ? // by default we store a date comment > ? return true; > } > > (ignore any javadoc issues, please :)) > > Then the implementation of existing store() APIs in > java.util.Properties, can call this method to decide whether or not to > write out a date comment. By default, the implementation of this new > mustStoreDateComment() in java.util.Properties will return true, which > means there shouldn't be any backward compatibility issues. At the > same time this will allow tools/libraries/callers to extend the > java.util.Properties class and (only) override this method to return > false, if they want to disable writing out the date comment. The > advantage of this would be: > > ?- Ability to fully disable the date comment and have full control on > what comments (if any) get written out by the existing store() APIs > ?- These custom extended classes don't have to worry or deal with the > formatting rules of key/values that the existing store() APIs will > continue to take care off. > ?- No system property or additional environment variable necessary for > disabling the date comment altogether > - The JDK will still have full control on how the date comment is > written out and will continue to write it out in a reproducible manner > when SOURCE_DATE_EPOCH is set. > ?- The new "protected" API, IMO, doesn't introduce a big new API > surface, unlike the previously proposed overloaded or differently > named variants of the store() APIs. > > The name of this new method of course is something that can be decided > - I just came up with that name just to explain what I mean. > > Is this something that is acceptable and worth adding? Why is this complexity needed? Let me be more concrete: I suggest adding a new overloaded method, publicvoidstore(Writerout, Stringcomments, boolean includeTimestamp) (As Roger says, there's no point in duplicating the OutputStream version of the API as well, since it's trivial to convert an OutputStream to a Writer.) If called with includeTimestamp = true, it will be identical to store(Writer out, String comments). But if called with false, the timestamp line will be omitted. SOURCE_DATE_EPOCH has no relevance in this case, since no timestamp is produced. This way someone who writes a new tool (or whatever) can decide upfront to generate reproducible output. The method will also be "discoverable" for developers, since an IDE will typically show the overloaded method as an alternative for code completion, which will immediately signal to programmers that there is a way to disable timestamps. I can't say I understood any arguments against a solution like this. Are there any? /Magnus > > [1] https://github.com/openjdk/jdk/pull/5372 > > [2] https://bugs.openjdk.java.net/browse/JDK-5032603 > > -Jaikiran > From mcimadamore at openjdk.java.net Thu Sep 9 10:42:07 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 9 Sep 2021 10:42:07 GMT Subject: RFR: 8273315: Parallelize and increase timeouts for java/foreign/TestMatrix.java test [v2] In-Reply-To: References: Message-ID: On Wed, 8 Sep 2021 09:17:31 GMT, Aleksey Shipilev wrote: >> This test runs a lot of configurations, and spends a lot of time serially. This is especially pronounced when run in prospective tier4 runs (JDK-8273314). There are reports of multi-hour runs (see JDK-8271613). We can parallelize the test configurations for this test to make it hurt less. Also, timeouts need to be increased for `TestUpcall` test configs, because some of them are very slow in fastdebug mode. >> >> Sample run: >> >> >> $ time CONF=linux-x86_64-server-fastdebug make run-test TEST=java/foreign/TestMatrix.java | ts -s >> 00:00:00 Building target 'run-test' in configuration 'linux-x86_64-server-fastdebug' >> 00:00:03 Test selection 'java/foreign/TestMatrix.java', will run: >> 00:00:03 * jtreg:test/jdk/java/foreign/TestMatrix.java >> 00:00:03 >> 00:00:03 Running test 'jtreg:test/jdk/java/foreign/TestMatrix.java' >> 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TTFT >> 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FFFF >> 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FFTF >> 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TTTT >> 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FTTT >> 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FFTT >> 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FFFT >> 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TTTF >> 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FTTF >> 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TFFT >> 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TFTF >> 00:00:32 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TFFF >> 00:00:32 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FTFF >> 00:00:35 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TFTT >> 00:00:35 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TTFF >> 00:00:38 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FTFT >> 00:01:50 Passed: java/foreign/TestMatrix.java#Downcall-FF >> 00:02:27 Passed: java/foreign/TestMatrix.java#Downcall-TF >> 00:03:03 Passed: java/foreign/TestMatrix.java#Downcall-FT >> 00:03:47 Passed: java/foreign/TestMatrix.java#Downcall-TT >> 00:04:17 Passed: java/foreign/TestMatrix.java#Upcall-FTFF >> 00:04:23 Passed: java/foreign/TestMatrix.java#Upcall-TFFF >> 00:05:46 Passed: java/foreign/TestMatrix.java#Upcall-TTFF >> 00:06:03 Passed: java/foreign/TestMatrix.java#Upcall-TFFT >> 00:06:44 Passed: java/foreign/TestMatrix.java#Upcall-FTFT >> 00:08:24 Passed: java/foreign/TestMatrix.java#Upcall-TFTF >> 00:08:39 Passed: java/foreign/TestMatrix.java#Upcall-TTFT >> 00:09:16 Passed: java/foreign/TestMatrix.java#Upcall-FTTF >> 00:09:19 Passed: java/foreign/TestMatrix.java#Upcall-TFTT >> 00:10:01 Passed: java/foreign/TestMatrix.java#Upcall-FTTT >> 00:10:37 Passed: java/foreign/TestMatrix.java#Upcall-TTTF >> 00:12:16 Passed: java/foreign/TestMatrix.java#Upcall-TTTT >> 00:12:17 Test results: passed: 32 >> 00:12:21 >> 00:12:21 ============================== >> 00:12:21 Test summary >> 00:12:21 ============================== >> 00:12:21 TEST TOTAL PASS FAIL ERROR >> 00:12:21 jtreg:test/jdk/java/foreign/TestMatrix.java 32 32 0 0 >> 00:12:21 ============================== >> >> real 12m20.538s >> user 131m54.043s >> sys 0m59.944s >> >> >> If we don't parallelize, then those 130 minutes are spent serially. > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Go "manual" Thanks for taking care of this! ------------- PR: https://git.openjdk.java.net/jdk/pull/5358 From sgehwolf at openjdk.java.net Thu Sep 9 11:02:02 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Thu, 9 Sep 2021 11:02:02 GMT Subject: RFR: JDK-8273526: Extend the OSContainer API pids controller with pids.current In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 09:21:59 GMT, Matthias Baesken wrote: > https://bugs.openjdk.java.net/browse/JDK-8266490 > extended the OSContainer API in order to also support the pids controller of cgroups. However only pids.max output was added with 8266490. > There is a second parameter pids.current , see https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#pid > that would be helpful too and can be added to the OSContainer API . > pids.current : > A read-only single value file which exists on all cgroups. > The number of processes currently in the cgroup and its descendants. > > Best regards, Matthias This could get simplified a bit as we don't need to consider `max` values for `pids.current`. src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 287: > 285: * OSCONTAINER_ERROR for not supported > 286: */ > 287: jlong CgroupV1Subsystem::pids_current() { `pids.current` never contains a string `max` (for unlimited). Therefore, we shouldn't need to do the `pids_current_val` -> `limit_from_str()` trick. We should be able to use `GET_CONTAINER_INFO(int, [...]` akin to `cpu_quota`. `int` or `long` would both be suitable. Up to you to decide which data type to use. I don't think it'll ever be beyond the maximum integrer value. src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1Subsystem.java line 421: > 419: public long getPidsCurrent() { > 420: String pidsCurrentStr = CgroupSubsystemController.getStringValue(pids, "pids.current"); > 421: return CgroupSubsystem.limitFromString(pidsCurrentStr); `return getLongValue(pids, "pids.current");` should be sufficient here. test/hotspot/jtreg/containers/docker/TestPids.java line 97: > 95: System.out.println("DEBUG: parts.length = " + parts.length); > 96: if (expectedValue.equals("no_value_expected")) { > 97: System.out.println("No value expected for " + lineMarker); Perhaps this debug print could say `System.out.println("Found '" + lineMarker + "' with value: '" + +"');` and actually parse the number as we'd expect an integer there? ------------- Changes requested by sgehwolf (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5437 From magnus.ihse.bursie at oracle.com Thu Sep 9 11:34:28 2021 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 9 Sep 2021 13:34:28 +0200 Subject: Proposal: JDK-8231640 - (prop) Canonical property storage In-Reply-To: References: <9b90a43f-defc-5100-3b5a-0a69214a706c@gmail.com> <86a3469a-7107-8c32-3240-28b10b470f87@oracle.com> <2c98d073-5a22-9732-b828-c1a08314d1a0@gmail.com> <6d97bada-0388-cb5c-bbbc-2712764e559b@gmail.com> <983f15b6-96e3-9aeb-c203-baea91dd1b24@oracle.com> Message-ID: <594a960b-61ee-6802-4719-be974bb22e3f@oracle.com> On 2021-09-09 12:04, Magnus Ihse Bursie wrote: > > Let me be more concrete: I suggest adding a new overloaded method, > > publicvoidstore(Writerout, Stringcomments, boolean includeTimestamp) And somehow my email program managed to mess up the code formatting. :-( The signature I meant was of course: public void store(Writer out, String comments, boolean includeTimestamp) /Magnus From github.com+44313413+jovanstevanovic at openjdk.java.net Thu Sep 9 12:25:17 2021 From: github.com+44313413+jovanstevanovic at openjdk.java.net (Jovan Stevanovic) Date: Thu, 9 Sep 2021 12:25:17 GMT Subject: RFR: 8273278: Support XSLT on GraalVM Native Image--deterministic bytecode generation in XSLT [v2] In-Reply-To: References: Message-ID: > GraalVM Native Image supports loading classes at runtime if they are known during image build (class predefinition). This is achieved by the JVMTI agent that registers dynamically generated classes in a regular HotSpot run. The Native Image build uses these registered classes to embed them into the produced binary so they can be loaded at runtime. Loading at runtime is achieved by matching the unique hash of generated classes. > > If the generated bytecode is unstable across runs, the generated native image can not match the hash of the runtime-generated bytecode to the pre-defined classes. The execution failure happens here: > https://github.com/oracle/graal/blob/master/substratevm/src/com.oracle.svm.core/src/com/oracle/svm/core/hub/PredefinedClassesSupport.java#L127-L131. > > In XSLT the produced bytecode is unstable for the following reasons: > > - Methods like ` HashMap#values` and `HashMap#keySet` result in different traversal orders of its elements yielding a different order of methods and fields. > > - The default `Object#toString` includes the current memory reference of `com.sun.org.apache.xalan.internal.xsltc.compiler.Number` in the generated class. Jovan Stevanovic has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: 8273278: Improving XSLT support for GraalVM's Native Image. ------------- Changes: https://git.openjdk.java.net/jdk/pull/5331/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5331&range=01 Stats: 23 lines in 4 files changed: 5 ins; 0 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/5331.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5331/head:pull/5331 PR: https://git.openjdk.java.net/jdk/pull/5331 From github.com+44313413+jovanstevanovic at openjdk.java.net Thu Sep 9 12:29:03 2021 From: github.com+44313413+jovanstevanovic at openjdk.java.net (Jovan Stevanovic) Date: Thu, 9 Sep 2021 12:29:03 GMT Subject: RFR: 8273278: Support XSLT on GraalVM Native Image--deterministic bytecode generation in XSLT In-Reply-To: References: Message-ID: On Wed, 8 Sep 2021 18:15:47 GMT, Joe Wang wrote: > I'm not involved in any older releases. You'll need to find the right channel for a particular backport you want to make and ask there. As for merging the change in the current release, please update the copyright header and the LastModified date for each of the classes. The github interface unfortunately won't allow me to add comments directly to the unchanged code area. Once that's done, you'll need to issue an integrate command. I'll sponsor your change. Okay, I'll take a look for a proper channel. Also, copyright headers and LastModified dates are not up to date. ------------- PR: https://git.openjdk.java.net/jdk/pull/5331 From aefimov at openjdk.java.net Thu Sep 9 12:35:58 2021 From: aefimov at openjdk.java.net (Aleksei Efimov) Date: Thu, 9 Sep 2021 12:35:58 GMT Subject: RFR: 8273484: Cleanup unnecessary null comparison before instanceof check in java.naming In-Reply-To: References: Message-ID: On Mon, 6 Sep 2021 08:08:33 GMT, Andrey Turbanov wrote: > Update code checks both non-null and instance of a class in java.naming module classes. > The checks and explicit casts could also be replaced with pattern matching for the instanceof operator. > For example: > The following code: > > return (obj != null && > obj instanceof CompoundName && > impl.equals(((CompoundName)obj).impl)); > > > Can be simplified to: > > > return (obj instanceof CompoundName other) && > impl.equals(other.impl); > > > See similar cleanup in java.base - https://bugs.openjdk.java.net/browse/JDK-8258422 Hi Andrey, The changes look good to me. And it looks like there is one more method to cleanup: [LdapReferralContext.setHopCount](https://github.com/openjdk/jdk/blob/master/src/java.naming/share/classes/com/sun/jndi/ldap/LdapReferralContext.java#L201) ------------- PR: https://git.openjdk.java.net/jdk/pull/5374 From kartikohri13 at gmail.com Thu Sep 9 12:36:57 2021 From: kartikohri13 at gmail.com (Kartik Ohri) Date: Thu, 9 Sep 2021 18:06:57 +0530 Subject: Patch for JDK-8273541 Message-ID: Hi all! I would like to work on a fix for JDK-8273541 . I think the regression was introduced by the change here . It seems that this was accidentally changed from Thread.MAX_PRIORITY to Thread.MIN_PRIORITY. As Thread.MIN_PRIORITY - 2 is negative and because of the check here , the thread priority is not set. Changing this back to Thread.MAX_PRIORITY should fix the problem. I tried the patch locally and it seems to fix the issue for me. If it is fine, I would like to submit this fix. Regards, Kartik From shade at redhat.com Thu Sep 9 12:53:33 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 9 Sep 2021 14:53:33 +0200 Subject: Patch for JDK-8273541 In-Reply-To: References: Message-ID: <152b134e-245f-a62d-f968-5c2710593157@redhat.com> On 9/9/21 2:36 PM, Kartik Ohri wrote: > I would like to work on a fix for JDK-8273541 Sure, it does not seem taken yet. Submit the PR, and work there. -- Thanks, -Aleksey From shade at openjdk.java.net Thu Sep 9 12:54:22 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 9 Sep 2021 12:54:22 GMT Subject: RFR: 8273494: Zero: Put libjvm.so into "zero" folder, not "server" Message-ID: Currently, the build system defaults the libjvm.so location to "server". This makes looking for `libjvm.so` awkward, see JDK-8273487 for example. We need to see if moving the libjvm.so to a proper location breaks anything. Additional testing: - [x] Linux x86_64 Zero build - [x] Linux x86_64 Zero bootcycle-images - [ ] Linux x86_64 Zero `tier1` ------------- Commit messages: - Fix Changes: https://git.openjdk.java.net/jdk/pull/5440/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5440&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273494 Stats: 14 lines in 6 files changed: 0 ins; 3 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/5440.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5440/head:pull/5440 PR: https://git.openjdk.java.net/jdk/pull/5440 From Alan.Bateman at oracle.com Thu Sep 9 13:02:27 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 9 Sep 2021 14:02:27 +0100 Subject: Patch for JDK-8273541 In-Reply-To: References: Message-ID: <88b67d49-cffb-0a1b-819d-5eea5a7762a1@oracle.com> On 09/09/2021 13:36, Kartik Ohri wrote: > Hi all! > I would like to work on a fix for JDK-8273541 > . I think the regression > was introduced by the change here > . > It seems that this was accidentally changed from Thread.MAX_PRIORITY to > Thread.MIN_PRIORITY. As Thread.MIN_PRIORITY - 2 is negative and because of > the check here > , > the thread priority is not set. Changing this back to > Thread.MAX_PRIORITY should fix the problem. I tried the patch > > locally and it seems to fix the issue for me. If it is fine, I would like > to submit this fix. > Heinz Kabutz is working on a PR here: ?? https://github.com/openjdk/jdk/pull/5439 -Alan From kartikohri13 at gmail.com Thu Sep 9 13:07:47 2021 From: kartikohri13 at gmail.com (Kartik Ohri) Date: Thu, 9 Sep 2021 18:37:47 +0530 Subject: Patch for JDK-8273541 In-Reply-To: <88b67d49-cffb-0a1b-819d-5eea5a7762a1@oracle.com> References: <88b67d49-cffb-0a1b-819d-5eea5a7762a1@oracle.com> Message-ID: Hi! Thanks for the reply, Aleksey and Alan. I had submitted the patch after viewing the first response but have now withdrawn it as PR is already open. Regards, Kartik On Thu, Sep 9, 2021 at 6:32 PM Alan Bateman wrote: > On 09/09/2021 13:36, Kartik Ohri wrote: > > Hi all! > > I would like to work on a fix for JDK-8273541 > > . I think the > regression > > was introduced by the change here > > < > https://github.com/openjdk/jdk/pull/2380/files#diff-d62f4055445b40f5d9862e02f8be6da2d547ac77ffae362d7034595d58c7389aL220-R217 > >. > > It seems that this was accidentally changed from Thread.MAX_PRIORITY to > > Thread.MIN_PRIORITY. As Thread.MIN_PRIORITY - 2 is negative and because > of > > the check here > > < > https://github.com/openjdk/jdk/pull/2380/files#diff-9f140a5980d51de2a5f392a6ffb91f51d2303760b699d5366125fb66f55b70f0R120-R122 > >, > > the thread priority is not set. Changing this back to > > Thread.MAX_PRIORITY should fix the problem. I tried the patch > > < > https://github.com/amCap1712/jdk/commit/b894bda67f9f4f8f48ba97679247a8218f6b95dc > > > > locally and it seems to fix the issue for me. If it is fine, I would like > > to submit this fix. > > > Heinz Kabutz is working on a PR here: > https://github.com/openjdk/jdk/pull/5439 > > -Alan > > > From dholmes at openjdk.java.net Thu Sep 9 13:12:01 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 9 Sep 2021 13:12:01 GMT Subject: RFR: 8273494: Zero: Put libjvm.so into "zero" folder, not "server" In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 10:17:02 GMT, Aleksey Shipilev wrote: > Currently, the build system defaults the libjvm.so location to "server". This makes looking for `libjvm.so` awkward, see JDK-8273487 for example. We need to see if moving the libjvm.so to a proper location breaks anything. > > Additional testing: > - [x] Linux x86_64 Zero build > - [x] Linux x86_64 Zero bootcycle-images > - [ ] Linux x86_64 Zero `tier1` This does what it intends but I can't approve it via a review as the issue is more about whether this should be done. The people who own/maintain/support Zero are the ones who should be directing this. David make/autoconf/hotspot.m4 line 86: > 84: fi > 85: > 86: # All "special" variants share the same output directory ("server") I presume "zero" was a special variant? Are there any other variants remaining? make/modules/java.base/Copy.gmk line 98: > 96: DEFAULT_CFG_VARIANT ?= server > 97: > 98: # Any variant other than server, client, minimal, or zero is represented as server in Are there any other variants now? ------------- PR: https://git.openjdk.java.net/jdk/pull/5440 From shade at openjdk.java.net Thu Sep 9 13:18:04 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 9 Sep 2021 13:18:04 GMT Subject: RFR: 8273494: Zero: Put libjvm.so into "zero" folder, not "server" In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 13:02:23 GMT, David Holmes wrote: >> Currently, the build system defaults the libjvm.so location to "server". This makes looking for `libjvm.so` awkward, see JDK-8273487 for example. We need to see if moving the libjvm.so to a proper location breaks anything. >> >> Additional testing: >> - [x] Linux x86_64 Zero build >> - [x] Linux x86_64 Zero bootcycle-images >> - [ ] Linux x86_64 Zero `tier1` > > make/autoconf/hotspot.m4 line 86: > >> 84: fi >> 85: >> 86: # All "special" variants share the same output directory ("server") > > I presume "zero" was a special variant? Are there any other variants remaining? Yes, there are at least "core" and "custom": # All valid JVM variants VALID_JVM_VARIANTS="server client minimal core zero custom" ------------- PR: https://git.openjdk.java.net/jdk/pull/5440 From github.com+741251+turbanoff at openjdk.java.net Thu Sep 9 13:24:27 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Thu, 9 Sep 2021 13:24:27 GMT Subject: RFR: 8273484: Cleanup unnecessary null comparison before instanceof check in java.naming [v2] In-Reply-To: References: Message-ID: > Update code checks both non-null and instance of a class in java.naming module classes. > The checks and explicit casts could also be replaced with pattern matching for the instanceof operator. > For example: > The following code: > > return (obj != null && > obj instanceof CompoundName && > impl.equals(((CompoundName)obj).impl)); > > > Can be simplified to: > > > return (obj instanceof CompoundName other) && > impl.equals(other.impl); > > > See similar cleanup in java.base - https://bugs.openjdk.java.net/browse/JDK-8258422 Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8273484: Cleanup unnecessary null comparison before instanceof check in java.naming ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5374/files - new: https://git.openjdk.java.net/jdk/pull/5374/files/0c72cddc..4b1bc753 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5374&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5374&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5374.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5374/head:pull/5374 PR: https://git.openjdk.java.net/jdk/pull/5374 From github.com+741251+turbanoff at openjdk.java.net Thu Sep 9 13:24:27 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Thu, 9 Sep 2021 13:24:27 GMT Subject: RFR: 8273484: Cleanup unnecessary null comparison before instanceof check in java.naming In-Reply-To: References: Message-ID: <3H3upC9jeRl_1-xiZOPh3xtstJXnOIZVJtkTiLjMBs8=.e7322c8a-83bd-4e74-b4e3-3c3677193d65@github.com> On Mon, 6 Sep 2021 08:08:33 GMT, Andrey Turbanov wrote: > Update code checks both non-null and instance of a class in java.naming module classes. > The checks and explicit casts could also be replaced with pattern matching for the instanceof operator. > For example: > The following code: > > return (obj != null && > obj instanceof CompoundName && > impl.equals(((CompoundName)obj).impl)); > > > Can be simplified to: > > > return (obj instanceof CompoundName other) && > impl.equals(other.impl); > > > See similar cleanup in java.base - https://bugs.openjdk.java.net/browse/JDK-8258422 Good catch! Improved. Not sure why IDEA don't report such case. Created https://youtrack.jetbrains.com/issue/IDEA-277851 ------------- PR: https://git.openjdk.java.net/jdk/pull/5374 From alanb at openjdk.java.net Thu Sep 9 14:11:59 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 9 Sep 2021 14:11:59 GMT Subject: RFR: 8273188: java/lang/instrument/BootClassPath/BootClassPathTest.sh fails with "FATAL ERROR in native method: processing of -javaagent failed, processJavaStart failed" In-Reply-To: <4L7o9IPAykqulqdtsqnIgfpObxLUaBgbOSU-F7HBXfg=.fdc31bcb-6b59-4e9c-80ee-e8ea513d6bdc@github.com> References: <4L7o9IPAykqulqdtsqnIgfpObxLUaBgbOSU-F7HBXfg=.fdc31bcb-6b59-4e9c-80ee-e8ea513d6bdc@github.com> Message-ID: On Wed, 8 Sep 2021 22:15:12 GMT, Naoto Sato wrote: > The gist of the issue is that the test case now always creates the boot classpath with non-ASCII chars appended, because the default encoding is fixed to UTF-8 with the fix to JDK-8260265. > > On macOS, javaagent tries to load the class with US-ASCII determined by nl_langinfo() (in unix/.../EncodingSupport_md.c). The file system encoding is always UTF-8 on mac, so no need to use the determined encoding by nl_langinfo(). > > On Linux, the "defaultEncoding" in Setup.java used to be US-ASCII in "C" locale (which matches the result from nl_langinfo()), so no non-ASCII suffix was appended to the `boot` path. But now the "defaultEncoding" is always UTF-8, the setup code appends the non-ASCII suffix, which fails to read in the native code using iconv with US-ASCII. The setup code should use the encoding from "sun.jnu.encoding" instead. Actually, the code there was copied from UnicodeTest.java which was modified with JDK-8260265, so the same fix needs to be applied. > > Tier5 run succeeds with one unrelated failure. Also, fixed some typos, e.g. "Uft8" -> "Utf8" Good sleuthing. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5427 From ihse at openjdk.java.net Thu Sep 9 14:34:08 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 9 Sep 2021 14:34:08 GMT Subject: RFR: 8273494: Zero: Put libjvm.so into "zero" folder, not "server" In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 10:17:02 GMT, Aleksey Shipilev wrote: > Currently, the build system defaults the libjvm.so location to "server". This makes looking for `libjvm.so` awkward, see JDK-8273487 for example. We need to see if moving the libjvm.so to a proper location breaks anything. > > Additional testing: > - [x] Linux x86_64 Zero build > - [x] Linux x86_64 Zero bootcycle-images > - [ ] Linux x86_64 Zero `tier1` And as for @dholmes-ora comment: I'm not sure who "own" zero at this point in time. Aleksey has made a lot of the zero patches lately; does that not count? Are you thinking about any specific person that needs to weight in on this? ------------- PR: https://git.openjdk.java.net/jdk/pull/5440 From ihse at openjdk.java.net Thu Sep 9 14:34:09 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 9 Sep 2021 14:34:09 GMT Subject: RFR: 8273494: Zero: Put libjvm.so into "zero" folder, not "server" In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 13:14:35 GMT, Aleksey Shipilev wrote: >> make/autoconf/hotspot.m4 line 86: >> >>> 84: fi >>> 85: >>> 86: # All "special" variants share the same output directory ("server") >> >> I presume "zero" was a special variant? Are there any other variants remaining? > > Yes, there are at least "core" and "custom": > > > # All valid JVM variants > VALID_JVM_VARIANTS="server client minimal core zero custom" I think we should stop these as well from impersonating the server JVM. Preferably in the same fix, so we can remove all the special casing for "server" being anything else but server. ------------- PR: https://git.openjdk.java.net/jdk/pull/5440 From shade at openjdk.java.net Thu Sep 9 14:44:08 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 9 Sep 2021 14:44:08 GMT Subject: RFR: 8273494: Zero: Put libjvm.so into "zero" folder, not "server" In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 14:28:19 GMT, Magnus Ihse Bursie wrote: >> Yes, there are at least "core" and "custom": >> >> >> # All valid JVM variants >> VALID_JVM_VARIANTS="server client minimal core zero custom" > > I think we should stop these as well from impersonating the server JVM. Preferably in the same fix, so we can remove all the special casing for "server" being anything else but server. Ok, I agree. Can I do a Zero-specific thing here (so that it is potentially cleanly backportable), and then handle the rest of the variants? ------------- PR: https://git.openjdk.java.net/jdk/pull/5440 From ihse at openjdk.java.net Thu Sep 9 15:15:00 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 9 Sep 2021 15:15:00 GMT Subject: RFR: 8273494: Zero: Put libjvm.so into "zero" folder, not "server" In-Reply-To: References: Message-ID: <6EpZHKmu05w7CmXzMXmUPMHwKrsBT7anSPbMUwA69TI=.a409d263-8316-4774-85fd-67981e64d579@github.com> On Thu, 9 Sep 2021 14:41:02 GMT, Aleksey Shipilev wrote: >> I think we should stop these as well from impersonating the server JVM. Preferably in the same fix, so we can remove all the special casing for "server" being anything else but server. > > Ok, I agree. Can I do a Zero-specific thing here (so that it is potentially cleanly backportable), and then handle the rest of the variants? Sure, that works for me. ------------- PR: https://git.openjdk.java.net/jdk/pull/5440 From shade at openjdk.java.net Thu Sep 9 15:27:12 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 9 Sep 2021 15:27:12 GMT Subject: RFR: 8273494: Zero: Put libjvm.so into "zero" folder, not "server" In-Reply-To: <6EpZHKmu05w7CmXzMXmUPMHwKrsBT7anSPbMUwA69TI=.a409d263-8316-4774-85fd-67981e64d579@github.com> References: <6EpZHKmu05w7CmXzMXmUPMHwKrsBT7anSPbMUwA69TI=.a409d263-8316-4774-85fd-67981e64d579@github.com> Message-ID: On Thu, 9 Sep 2021 15:12:27 GMT, Magnus Ihse Bursie wrote: >> Ok, I agree. Can I do a Zero-specific thing here (so that it is potentially cleanly backportable), and then handle the rest of the variants? > > Sure, that works for me. While we are at it, do `core` and `custom` even carry their weight? I cannot remember if I ever seen anyone using them. Maybe we should "just" drop those variants, and leave only "server, client, minimal, zero"? ------------- PR: https://git.openjdk.java.net/jdk/pull/5440 From ihse at openjdk.java.net Thu Sep 9 15:38:07 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 9 Sep 2021 15:38:07 GMT Subject: RFR: 8273494: Zero: Put libjvm.so into "zero" folder, not "server" In-Reply-To: References: <6EpZHKmu05w7CmXzMXmUPMHwKrsBT7anSPbMUwA69TI=.a409d263-8316-4774-85fd-67981e64d579@github.com> Message-ID: On Thu, 9 Sep 2021 15:23:45 GMT, Aleksey Shipilev wrote: >> Sure, that works for me. > > While we are at it, do `core` and `custom` even carry their weight? I cannot remember if I ever seen anyone using them. Maybe we should "just" drop those variants, and leave only "server, client, minimal, zero"? I don't know about "core". Last time it was up for discussion, some old-timer I've forgotten pointed out that it was useful for such-and-such. I'm not sure if the cost for keeping it is high enough to make the effort to figure out if anyone is going to miss it if we remove it. As for "custom", it is not a real JVM configuration per se. Instead, it's more of a testing ground for the build system. Basically, the JVM "variants" are just named pre-defined sets of enabled JVM features. To test this properly, I introduced the "custom" variant which is just an empty set of JVM features from the start, so that individual features can be fully controlled. I don't really think anyone is using this in the "real world", but I'd like to keep it for testing purposes. ------------- PR: https://git.openjdk.java.net/jdk/pull/5440 From joehw at openjdk.java.net Thu Sep 9 15:59:10 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Thu, 9 Sep 2021 15:59:10 GMT Subject: RFR: 8273278: Support XSLT on GraalVM Native Image--deterministic bytecode generation in XSLT [v2] In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 12:25:17 GMT, Jovan Stevanovic wrote: >> GraalVM Native Image supports loading classes at runtime if they are known during image build (class predefinition). This is achieved by the JVMTI agent that registers dynamically generated classes in a regular HotSpot run. The Native Image build uses these registered classes to embed them into the produced binary so they can be loaded at runtime. Loading at runtime is achieved by matching the unique hash of generated classes. >> >> If the generated bytecode is unstable across runs, the generated native image can not match the hash of the runtime-generated bytecode to the pre-defined classes. The execution failure happens here: >> https://github.com/oracle/graal/blob/master/substratevm/src/com.oracle.svm.core/src/com/oracle/svm/core/hub/PredefinedClassesSupport.java#L127-L131. >> >> In XSLT the produced bytecode is unstable for the following reasons: >> >> - Methods like ` HashMap#values` and `HashMap#keySet` result in different traversal orders of its elements yielding a different order of methods and fields. >> >> - The default `Object#toString` includes the current memory reference of `com.sun.org.apache.xalan.internal.xsltc.compiler.Number` in the generated class. > > Jovan Stevanovic 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 one additional commit since the last revision: > > 8273278: Improving XSLT support for GraalVM's Native Image. Marked as reviewed by joehw (Reviewer). The headers look good now. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/5331 From mchung at openjdk.java.net Thu Sep 9 16:19:07 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 9 Sep 2021 16:19:07 GMT Subject: RFR: 8078641: MethodHandle.asTypeCache can retain classes from unloading [v3] In-Reply-To: References: Message-ID: On Fri, 3 Sep 2021 12:01:12 GMT, Vladimir Ivanov wrote: > > For the change of MethodHandle::asType to a final method, this needs a CSR. > > It is not allowed to extend/subclass `MethodHandle` outside `java.lang.invoke` package. > So, the aforementioned change doesn't have any compatibility risks. Do I miss something important? > > ``` > /** > * Package-private constructor for the method handle implementation hierarchy. > * Method handle inheritance will be contained completely within > * the {@code java.lang.invoke} package. > */ > // @param type type (permanently assigned) of the new method handle > /*non-public*/ > MethodHandle(MethodType type, LambdaForm form) { > ``` Sorry for the late reply as I was on vacation and just return today. Thanks for the clarification. I missed the fact that `MethodHandle` has no public constructor and cannot be extended. This is fine. ------------- PR: https://git.openjdk.java.net/jdk/pull/5246 From igraves at openjdk.java.net Thu Sep 9 16:30:29 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Thu, 9 Sep 2021 16:30:29 GMT Subject: RFR: 8273514: java/util/DoubleStreamSums/CompensatedSums.java failure [v2] In-Reply-To: References: Message-ID: > Relaxing some assertion bounds to allow for small error values that still show improvement over previous summation method. Ian Graves has updated the pull request incrementally with one additional commit since the last revision: Tweaking asserts ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5430/files - new: https://git.openjdk.java.net/jdk/pull/5430/files/e3aaa680..8f77f3d3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5430&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5430&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5430.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5430/head:pull/5430 PR: https://git.openjdk.java.net/jdk/pull/5430 From herrick at openjdk.java.net Thu Sep 9 16:44:21 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Thu, 9 Sep 2021 16:44:21 GMT Subject: [jdk17] RFR: 8271868: Warn user when using mac-sign option with unsigned app-image. Message-ID: This is a backport from JDK-18 ------------- Commit messages: - JDK-8271868: Warn user when using mac-sign option with unsigned app-image. Changes: https://git.openjdk.java.net/jdk17/pull/305/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=305&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271868 Stats: 65 lines in 9 files changed: 46 ins; 11 del; 8 mod Patch: https://git.openjdk.java.net/jdk17/pull/305.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/305/head:pull/305 PR: https://git.openjdk.java.net/jdk17/pull/305 From asemenyuk at openjdk.java.net Thu Sep 9 17:16:12 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Thu, 9 Sep 2021 17:16:12 GMT Subject: [jdk17] RFR: 8271868: Warn user when using mac-sign option with unsigned app-image. In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 16:36:44 GMT, Andy Herrick wrote: > This is a backport from JDK-18 Marked as reviewed by asemenyuk (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk17/pull/305 From mcimadamore at openjdk.java.net Thu Sep 9 17:19:08 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 9 Sep 2021 17:19:08 GMT Subject: RFR: 8272903: Missing license header in ArenaAllocator.java Message-ID: This small patch adds missing copyright header to a segment allocator implementation class. ------------- Commit messages: - Add missing copyright header Changes: https://git.openjdk.java.net/jdk/pull/5447/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5447&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272903 Stats: 25 lines in 1 file changed: 25 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5447.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5447/head:pull/5447 PR: https://git.openjdk.java.net/jdk/pull/5447 From bpb at openjdk.java.net Thu Sep 9 17:24:59 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 9 Sep 2021 17:24:59 GMT Subject: RFR: 8272903: Missing license header in ArenaAllocator.java In-Reply-To: References: Message-ID: <_H5TlLLM5r8JomZf3XM9-5hb2mKkxG6bJL5NohCtggQ=.917a86d4-370b-40cc-8d1a-f223e7d0a730@github.com> On Thu, 9 Sep 2021 17:12:23 GMT, Maurizio Cimadamore wrote: > This small patch adds missing copyright header to a segment allocator implementation class. Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5447 From mcimadamore at openjdk.java.net Thu Sep 9 17:31:03 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 9 Sep 2021 17:31:03 GMT Subject: Integrated: 8272903: Missing license header in ArenaAllocator.java In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 17:12:23 GMT, Maurizio Cimadamore wrote: > This small patch adds missing copyright header to a segment allocator implementation class. This pull request has now been integrated. Changeset: 96614da0 Author: Maurizio Cimadamore URL: https://git.openjdk.java.net/jdk/commit/96614da0254e7fd4ac9dd3c3059bf23c1aaf37ff Stats: 25 lines in 1 file changed: 25 ins; 0 del; 0 mod 8272903: Missing license header in ArenaAllocator.java Reviewed-by: bpb, lancea ------------- PR: https://git.openjdk.java.net/jdk/pull/5447 From lancea at openjdk.java.net Thu Sep 9 17:31:02 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 9 Sep 2021 17:31:02 GMT Subject: RFR: 8272903: Missing license header in ArenaAllocator.java In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 17:12:23 GMT, Maurizio Cimadamore wrote: > This small patch adds missing copyright header to a segment allocator implementation class. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5447 From jlaskey at openjdk.java.net Thu Sep 9 18:07:18 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Thu, 9 Sep 2021 18:07:18 GMT Subject: RFR: JDK-8273162 AbstractSplittableWithBrineGenerator does not create a random salt Message-ID: RandomSupport.AbstractSplittableWithBrineGenerator. makeSplitsSpliterator is intending to create a salt from a random long. The salt should have random letters of size 4 for each consecutive 4 bits and then the last 4 bits as ff, i.e. all bits set. However the loop is never executed, the random bits are not used and the salt is always the same. This condition is false on the first execution: long multiplier = (1L << SALT_SHIFT) - 1; long salt = multiplier << (64 - SALT_SHIFT); while ((salt & multiplier) != 0) { This can be corrected by changing: while ((salt & multiplier) != 0) { to while ((salt & multiplier) == 0) { ------------- Commit messages: - Correct the loop condition Changes: https://git.openjdk.java.net/jdk/pull/5449/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5449&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273162 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5449.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5449/head:pull/5449 PR: https://git.openjdk.java.net/jdk/pull/5449 From roger.riggs at oracle.com Thu Sep 9 18:54:26 2021 From: roger.riggs at oracle.com (Roger Riggs) Date: Thu, 9 Sep 2021 14:54:26 -0400 Subject: Proposal: JDK-8231640 - (prop) Canonical property storage In-Reply-To: References: <9b90a43f-defc-5100-3b5a-0a69214a706c@gmail.com> <86a3469a-7107-8c32-3240-28b10b470f87@oracle.com> <2c98d073-5a22-9732-b828-c1a08314d1a0@gmail.com> <6d97bada-0388-cb5c-bbbc-2712764e559b@gmail.com> <983f15b6-96e3-9aeb-c203-baea91dd1b24@oracle.com> Message-ID: <80420e06-8ca9-a5d8-a467-61709114a40f@oracle.com> Hi Jaikiran, I agree with separating out the discussion of a new store method and (mostly) with the list of objectives below. And I'd propose doing it in a separate RFE[1] and PR. As to support for comments, I think we can omit them entirely from the new method. Since the caller has access to the stream or writer and with knowledge that comment lines start with "#" the caller can write whatever comment header they like before calling the new method. If the new method writes only the names and values, then it can be called in other contexts. For example, an application might provide a subclass for its own purposes and add its own headers. Supposing 1-arg store method that only writes the property names and values. ??? ??? public Properties save(Writer writer) {...} So basically, a refactoring to expose that subset of the existing store0. Regards, Roger [1]? RFE https://bugs.openjdk.java.net/browse/JDK-8273564 On 9/9/21 4:27 AM, Jaikiran Pai wrote: > > > On 31/08/21 7:09 pm, Jaikiran Pai wrote: >> Hello Magnus, >> >> On 30/08/21 5:29 pm, Magnus Ihse Bursie wrote: >>> >>> >>> On 2021-08-28 17:16, Alan Bateman wrote: >>>> On 28/08/2021 05:45, Jaikiran Pai wrote: >>>>> I hadn't considered the system property approach to switch to old >>>>> behaviour in my proposals, so this is a very good input and I >>>>> personally think the most logical proposals so far. >>>> >>>> Roger may be right that few would care but it would be changing >>>> behavior that goes back to JDK 1.0. In your list (and thanks for >>>> writing down the options with pros/cons) then your 1a where >>>> SOURCE_DATE_EPOCH changes to write the epoch date rather than the >>>> current date seems to be most consistent with other tools and the >>>> wider eco system. It seems the least disruptive in that it doesn't >>>> change existing behavior and would be opt-in when reproducibility >>>> is required. Previous discussion was leading towards your option 2 >>>> (or variants of) but isn't option doesn't help the cases where >>>> build tools use libraries that rely on the older methods. >>> >>> If I understood the numbering and alternatives correctly, I don't >>> think there is a conflict between 1a and 2, and I think both should >>> be implemented, for different reasons. >>> >>> This is my understanding of the options, with the rationale I see >>> for choosing them: >>> >>> * 1a says that we change the store() method to write the date from >>> SOURCE_DATE_EPOCH, if it is set -- otherwise it keeps the old >>> behavior. This allows users who want to use old Java code (or code >>> they can't modify) to produce output in a reproducible way to do so >>> without changing the source code of the product. >>> >>> * 2 says that we add a new override to store() which also takes an >>> Instant. This way programmers who write new code and want to make >>> sure it is always reproducible can send in Instant.EPOCH, and not >>> rely on the user to configure SOURCE_DATE_EPOCH. >>> >>> (In fact, when thinking of it, this seems overly complex. There is >>> no real need to send in a generic Instant, just an override with a >>> boolean skipTimestamp, or something like that. Basically, any >>> solution which allows programmers who write new code to get property >>> files without timestamps easily, is what's needed to fulfill this spot. >>> >> I do agree that it would be good to just get rid of the date comment >> and let callers control what exact comments (if any) get written out. >> However, I think that having both - a new method (overloaded or named >> differently) and at the same time changing the implementation of the >> existing store(...) methods to make the date comment reproducible is >> a bit of a overkill for a comment that doesn't even play a functional >> role in that API. I listed that option of a new overloaded API and >> would have been in favour of it, if that was the only addition/change >> that we did to support the date comment disabling/reproducibility. >> >> Having said that, I will gladly go ahead and include/work on that >> additional new API, if there is some general agreement on doing so. >> > The PR[1] related to the changes that have been agreed upon in this > discussion has reached a decent state, I think. There's however still > a valid question from Magnus. I am pasting that comment from Magnus, > from the PR, here: > > "Am I the only one thinking there should also be a way for > developers to explicitly disable timestamps from the API? > > I think the current iteration looks okay (but the core-libs guys > of course has the say in this), but I still think we need a new > method (or overload) to allow for a timestamp-free to be > generated, always, independent of environment variables." > > Magnus, I too think that there should be a way to completely get rid > of the date comment. It's my opinion that this date comment is almost > useless for Java programs because the Properties.load() doesn't load > any comments. So whatever/whoever is relying on these properties is > most likely going to be external (non-Java) scripts/tooling or some > really specific/odd Java code which reads this stored properties file, > per line and does something with the date comment. Highly unlikely but > still possible. So far, from what I have followed, no one has stated > that they use the date comment in some form. I even searched JBS > issues to see if there was any hint of this usage. On the contrary, I > found an (old) issue where someone asked for disabling the date > comment altogether and they explained a use case where they think the > current default of writing out that comment isn't helpful[2]. > > At the same time, I think the concern for backward compatibility is > valid, plus the concern that introducing a new store API (either > overloaded or differently named) which allows reproducibility plus the > ability to disable date comment, will require existing code to migrate > to this new ones, which realistically takes many years. > > So, if callers/users still want to get rid of the date comment when > dealing with the Properties.store() APIs, we could ask them to come up > with a custom implementation which extends the java.util.Properties > class. That is easier said than done, because the store() APIs have > very involved logic when it comes to formatting and writing out the > key/values of that instance. That logic is private to the > java.util.Properties, which effectively means these custom extended > classes can't use it (unless they copy it over and make these > implementations very brittle). So extending/overriding the entirety of > these store() APIs is realistically ruled out. > > Having said all that and reviewing again the potential options that I > listed in my earlier mail, I think there's probably a more easier > middle ground here, which allows callers/tools/libraries to control > whether or not the date comment gets written out. So here's a proposal > which might help - how about, *in addition to* what we have already > done in this PR, we also introduce a new protected method in > java.util.Properties which looks like: > > /** > ?* Returns {@code true} if the {@link #store} methods of this properties > ?* instance must write out the date comment. Returns {@code false} > otherwise. > ?* @since 18 > ?*/ > protected boolean mustStoreDateComment() { > ? // by default we store a date comment > ? return true; > } > > (ignore any javadoc issues, please :)) > > Then the implementation of existing store() APIs in > java.util.Properties, can call this method to decide whether or not to > write out a date comment. By default, the implementation of this new > mustStoreDateComment() in java.util.Properties will return true, which > means there shouldn't be any backward compatibility issues. At the > same time this will allow tools/libraries/callers to extend the > java.util.Properties class and (only) override this method to return > false, if they want to disable writing out the date comment. The > advantage of this would be: > > ?- Ability to fully disable the date comment and have full control on > what comments (if any) get written out by the existing store() APIs > ?- These custom extended classes don't have to worry or deal with the > formatting rules of key/values that the existing store() APIs will > continue to take care off. > ?- No system property or additional environment variable necessary for > disabling the date comment altogether > - The JDK will still have full control on how the date comment is > written out and will continue to write it out in a reproducible manner > when SOURCE_DATE_EPOCH is set. > ?- The new "protected" API, IMO, doesn't introduce a big new API > surface, unlike the previously proposed overloaded or differently > named variants of the store() APIs. > > The name of this new method of course is something that can be decided > - I just came up with that name just to explain what I mean. > > Is this something that is acceptable and worth adding? > > [1] https://github.com/openjdk/jdk/pull/5372 > > [2] https://bugs.openjdk.java.net/browse/JDK-5032603 > > -Jaikiran > From github.com+70726043+rgiulietti at openjdk.java.net Thu Sep 9 18:56:10 2021 From: github.com+70726043+rgiulietti at openjdk.java.net (Raffaello Giulietti) Date: Thu, 9 Sep 2021 18:56:10 GMT Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v2] In-Reply-To: References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com> Message-ID: On Fri, 16 Apr 2021 11:30:32 GMT, Raffaello Giulietti wrote: >> Hello, >> >> here's a PR for a patch submitted on March 2020 [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a thing. >> >> The patch has been edited to adhere to OpenJDK code conventions about multi-line (block) comments. Nothing in the code proper has changed, except for the addition of redundant but clarifying parentheses in some expressions. >> >> >> Greetings >> Raffaello > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > 4511638: Double.toString(double) sometimes produces incorrect results The usual refresh comment to keep this PR to remain active. Nothing new. ------------- PR: https://git.openjdk.java.net/jdk/pull/3402 From rriggs at openjdk.java.net Thu Sep 9 19:02:07 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 9 Sep 2021 19:02:07 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v7] In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 09:56:30 GMT, Jaikiran Pai wrote: >> The commit in this PR implements the proposal for enhancement that was discussed in the core-libs-dev mailing list recently[1], for https://bugs.openjdk.java.net/browse/JDK-8231640 >> >> At a high level - the `store()` APIs in `Properties` have been modified to now look for the `SOURCE_DATE_EPOCH` environment variable[2]. If that env variable is set, then instead of writing out the current date time as a date comment, the `store()` APIs instead will use the value set for this env variable to parse it to a `Date` and write out the string form of such a date. The implementation here uses the `d MMM yyyy HH:mm:ss 'GMT'` date format and `Locale.ROOT` to format and write out such a date. This should provide reproducibility whenever the `SOURCE_DATE_EPOCH` is set. Furthermore, intentionally, no changes in the date format of the "current date" have been done. >> >> These modified `store()` APIs work in the presence of the `SecurityManager` too. The caller is expected to have a read permission on the `SOURCE_DATE_EPOCH` environment variable. If the caller doesn't have that permission, then the implementation of these `store()` APIs will write out the "current date" and will ignore any value that has been set for the `SOURCE_DATE_EPOCH` env variable. This should allow for backward compatibility of existing applications, where, when they run under a `SecurityManager` and perhaps with an existing restrictive policy file, the presence of `SOURCE_DATE_EPOCH` shouldn't impact their calls to the `store()` APIs. >> >> The modified `store()` APIs will also ignore any value for `SOURCE_DATE_EPOCH` that cannot be parsed to an `long` value. In such cases, the `store()` APIs will write out the "current date" and ignore the value set for this environment variable. No exceptions will be thrown for such invalid values. This is an additional backward compatibility precaution to prevent any rogue value for `SOURCE_DATE_EPOCH` from breaking applications. >> >> An additional change in the implementation of these `store()` APIs and unrelated to the date comment, is that these APIs will now write out the property keys in a deterministic order. The keys will be written out in the natural ordering as specified by `java.lang.String#compareTo()` API. >> >> The combination of the ordering of the property keys when written out and the usage of `SOURCE_DATE_EPOCH` environment value to determine the date comment should together allow for reproducibility of the output generated by these `store()` APIs. >> >> New jtreg test classes have been introduced to verify these changes. The primary focus of `PropertiesStoreTest` is the ordering aspects of the property keys that are written out. On the other hand `StoreReproducibilityTest` focuses on the reproducibility of the output generated by these APIs. The `StoreReproducibilityTest` runs these tests both in the presence and absence of `SecurityManager`. Plus, in the presence of SecurityManager, it tests both the scenarios where the caller is granted the requisite permission and in other case not granted that permission. >> >> These new tests and existing tests under `test/jdk/java/util/Properties/` pass with these changes. >> >> [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-August/080758.html >> [2] https://reproducible-builds.org/specs/source-date-epoch/ > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > dummy commit to trigger GitHub actions job to try and reproduce an unexplained failure with the new tests that happened around 24 hours back, this time yesterday (rule out any time/date/timezone specific issues) Overall looks good, though a system property would be more in keeping with existing JDK pattern. See comments. src/java.base/share/classes/java/util/Properties.java line 187: > 185: ? System.getenv("SOURCE_DATE_EPOCH") > 186: : AccessController.doPrivileged((PrivilegedAction) > 187: () -> System.getenv("SOURCE_DATE_EPOCH")); The format of SOURCE_DATE_EPOCH is fine, but referring to an external document as part of the OpenJDK spec is undesirable in the long run. Previous comments gave support to using the environment variable directly but it very unlike similar cases that use system properties when the behavior of an API needs to be overridden or modified. As a system property, specified on the command line, it would be visible when the program is invoked, explicitly intended to change behavior and not having a context sensitive effect. Named perhaps, java.util.Properties.storeDate. It can be documented as part of the spec with the javadoc tag "{@systemProperty ...}" There is a cache of properties in jdk.internal.util.StaticProperty that captures the state when the runtime is initialized. For specific properties, they are cached and available without regard to the setting of the SecurityManager or not. (BTW, there is no need to special case doPriv calls, they are pretty well optimized when the security manager is not set and it keeps the code simpler.) Given the low frequency of calls to store(), even caching the parsed date doesn't save much. And the cost is the cost of the size and loading an extra class. src/java.base/share/classes/java/util/Properties.java line 887: > 885: * If the value set for {@code SOURCE_DATE_EPOCH} cannot be parsed to a {@code long}, > 886: * then the current date and time will be written. > 887: * Update to refer to the property and add the {@systemProperty ...} javadoc tag so the property is listed in the system property reference. ------------- Changes requested by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5372 From herrick at openjdk.java.net Thu Sep 9 19:35:15 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Thu, 9 Sep 2021 19:35:15 GMT Subject: [jdk17] Integrated: 8271868: Warn user when using mac-sign option with unsigned app-image. In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 16:36:44 GMT, Andy Herrick wrote: > This is a backport from JDK-18 This pull request has now been integrated. Changeset: a37254c7 Author: Andy Herrick URL: https://git.openjdk.java.net/jdk17/commit/a37254c79fa5973465d90f4b52ab88fe68016c9f Stats: 65 lines in 9 files changed: 46 ins; 11 del; 8 mod 8271868: Warn user when using mac-sign option with unsigned app-image. Reviewed-by: asemenyuk ------------- PR: https://git.openjdk.java.net/jdk17/pull/305 From naoto at openjdk.java.net Thu Sep 9 19:45:09 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 9 Sep 2021 19:45:09 GMT Subject: Integrated: 8273188: java/lang/instrument/BootClassPath/BootClassPathTest.sh fails with "FATAL ERROR in native method: processing of -javaagent failed, processJavaStart failed" In-Reply-To: <4L7o9IPAykqulqdtsqnIgfpObxLUaBgbOSU-F7HBXfg=.fdc31bcb-6b59-4e9c-80ee-e8ea513d6bdc@github.com> References: <4L7o9IPAykqulqdtsqnIgfpObxLUaBgbOSU-F7HBXfg=.fdc31bcb-6b59-4e9c-80ee-e8ea513d6bdc@github.com> Message-ID: On Wed, 8 Sep 2021 22:15:12 GMT, Naoto Sato wrote: > The gist of the issue is that the test case now always creates the boot classpath with non-ASCII chars appended, because the default encoding is fixed to UTF-8 with the fix to JDK-8260265. > > On macOS, javaagent tries to load the class with US-ASCII determined by nl_langinfo() (in unix/.../EncodingSupport_md.c). The file system encoding is always UTF-8 on mac, so no need to use the determined encoding by nl_langinfo(). > > On Linux, the "defaultEncoding" in Setup.java used to be US-ASCII in "C" locale (which matches the result from nl_langinfo()), so no non-ASCII suffix was appended to the `boot` path. But now the "defaultEncoding" is always UTF-8, the setup code appends the non-ASCII suffix, which fails to read in the native code using iconv with US-ASCII. The setup code should use the encoding from "sun.jnu.encoding" instead. Actually, the code there was copied from UnicodeTest.java which was modified with JDK-8260265, so the same fix needs to be applied. > > Tier5 run succeeds with one unrelated failure. Also, fixed some typos, e.g. "Uft8" -> "Utf8" This pull request has now been integrated. Changeset: 54dee132 Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/54dee132d1a149165e7478b29b740d086c18c424 Stats: 36 lines in 8 files changed: 5 ins; 16 del; 15 mod 8273188: java/lang/instrument/BootClassPath/BootClassPathTest.sh fails with "FATAL ERROR in native method: processing of -javaagent failed, processJavaStart failed" Reviewed-by: dholmes, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/5427 From herrick at openjdk.java.net Thu Sep 9 20:22:20 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Thu, 9 Sep 2021 20:22:20 GMT Subject: [jdk17] RFR: JDK-8272639: jpackaged applications using microphone on mac Message-ID: backport from jdk-18 ------------- Commit messages: - JDK-8272639: jpackaged applications using microphone on mac Changes: https://git.openjdk.java.net/jdk17/pull/306/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=306&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272639 Stats: 5 lines in 3 files changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk17/pull/306.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/306/head:pull/306 PR: https://git.openjdk.java.net/jdk17/pull/306 From aefimov at openjdk.java.net Thu Sep 9 21:09:06 2021 From: aefimov at openjdk.java.net (Aleksei Efimov) Date: Thu, 9 Sep 2021 21:09:06 GMT Subject: RFR: 8273484: Cleanup unnecessary null comparison before instanceof check in java.naming [v2] In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 13:24:27 GMT, Andrey Turbanov wrote: >> Update code checks both non-null and instance of a class in java.naming module classes. >> The checks and explicit casts could also be replaced with pattern matching for the instanceof operator. >> For example: >> The following code: >> >> return (obj != null && >> obj instanceof CompoundName && >> impl.equals(((CompoundName)obj).impl)); >> >> >> Can be simplified to: >> >> >> return (obj instanceof CompoundName other) && >> impl.equals(other.impl); >> >> >> See similar cleanup in java.base - https://bugs.openjdk.java.net/browse/JDK-8258422 > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8273484: Cleanup unnecessary null comparison before instanceof check in java.naming The latest version looks good to me. Our CI system is also happy with this patch - no `java.naming` test failures observed. ------------- Marked as reviewed by aefimov (Committer). PR: https://git.openjdk.java.net/jdk/pull/5374 From aefimov at openjdk.java.net Thu Sep 9 22:14:12 2021 From: aefimov at openjdk.java.net (Aleksei Efimov) Date: Thu, 9 Sep 2021 22:14:12 GMT Subject: RFR: 8273402: Use derived NamingExceptions in com.sun.jndi.ldap.Connection#readReply Message-ID: Hi, The following fix changes type of exception thrown when an LDAP operation fails for reasons like read timeout or connection closure/cancellation: instead of throwing a general `NamingException`, the internal LDAP connection class will throw a [`CommunicationException`](https://github.com/openjdk/jdk/blob/master/src/java.naming/share/classes/javax/naming/CommunicationException.java#L29) that better matches the reasons described. Testing shows no problem with the proposed fix. ------------- Commit messages: - 8273402: Remove redundant catch statement, change comment to match fix - 8273402: Use derived NamingExceptions in com.sun.jndi.ldap.Connection#readReply Changes: https://git.openjdk.java.net/jdk/pull/5456/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5456&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273402 Stats: 41 lines in 3 files changed: 13 ins; 3 del; 25 mod Patch: https://git.openjdk.java.net/jdk/pull/5456.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5456/head:pull/5456 PR: https://git.openjdk.java.net/jdk/pull/5456 From almatvee at openjdk.java.net Thu Sep 9 22:28:17 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Thu, 9 Sep 2021 22:28:17 GMT Subject: [jdk17] RFR: JDK-8272639: jpackaged applications using microphone on mac In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 20:14:01 GMT, Andy Herrick wrote: > backport from jdk-18 Marked as reviewed by almatvee (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk17/pull/306 From serb at openjdk.java.net Thu Sep 9 22:41:05 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 9 Sep 2021 22:41:05 GMT Subject: [jdk17] RFR: JDK-8272639: jpackaged applications using microphone on mac In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 20:14:01 GMT, Andy Herrick wrote: > backport from jdk-18 Is it for jdk17 or for jdk17u? ------------- PR: https://git.openjdk.java.net/jdk17/pull/306 From mchung at openjdk.java.net Thu Sep 9 22:53:01 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 9 Sep 2021 22:53:01 GMT Subject: RFR: 8273101: Eliminate the usage of threadgroup sandboxing in the java.util.logging In-Reply-To: References: Message-ID: <3YsvWiK0yxQFHzt8Y6zKU3ucGZbQ3FqFWJfs_PnITBY=.7442a7bf-6c49-4a58-a0eb-0f2015dc98f9@github.com> On Fri, 3 Sep 2021 17:19:05 GMT, Phil Race wrote: > Hmm I was under the impression this was removing AppContext itself but it is just removing the backdoor needed by logging > Perhaps this isn't the change that requires the CSR but it then leaves an inconsistent state where desktop supports AppContext still but other modules don't ... What is the plan to remove AppContext completely from java.desktop? It's okay to have a separate PR to remove the logging dependency on AppContext but I'd prefer to see AppContext be removed about the same time with this PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/5326 From dholmes at openjdk.java.net Thu Sep 9 22:59:02 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 9 Sep 2021 22:59:02 GMT Subject: RFR: 8273494: Zero: Put libjvm.so into "zero" folder, not "server" In-Reply-To: References: Message-ID: <2Yn8M-t8DrfBLGDJIgqCAHV1rIp0CydCE3wFSC-Ktu0=.b83f7003-a851-4dbf-9c9b-5d23fedc4757@github.com> On Thu, 9 Sep 2021 14:31:19 GMT, Magnus Ihse Bursie wrote: >> Currently, the build system defaults the libjvm.so location to "server". This makes looking for `libjvm.so` awkward, see JDK-8273487 for example. We need to see if moving the libjvm.so to a proper location breaks anything. >> >> Additional testing: >> - [x] Linux x86_64 Zero build >> - [x] Linux x86_64 Zero bootcycle-images >> - [ ] Linux x86_64 Zero `tier1` > > And as for @dholmes-ora comment: I'm not sure who "own" zero at this point in time. Aleksey has made a lot of the zero patches lately; does that not count? Are you thinking about any specific person that needs to weight in on this? @magicus every "port" in OpenJDK is supposed to have a clear owner and support system. Zero has been somewhat lacking in that area but there were enough people to keep it surviving. Now I'm not so sure. Does Zero have an active user community? Developer community? If so they are the ones who need to assess this change. ------------- PR: https://git.openjdk.java.net/jdk/pull/5440 From serb at openjdk.java.net Thu Sep 9 23:01:10 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 9 Sep 2021 23:01:10 GMT Subject: RFR: 8273101: Eliminate the usage of threadgroup sandboxing in the java.util.logging In-Reply-To: References: Message-ID: On Wed, 1 Sep 2021 06:31:16 GMT, Sergey Bylokhov wrote: > The "java.util.logging.LogManager" class uses the "threadgroup sandboxing" via an AppContext to support "applet logging isolation". The AppContext class became useless since the plugin and webstart are no longer supported and removed in jdk11. > > This is the request to delete the usage of AppContext in the LogManager and related tests. > > Tested by tier1/tier2/tier3 and jdk_desktop tests. I'll remove its used one by one from the external usage like in "java.base" here, then in Swing, then in 2D like fonts, then last in AWT. That change should not break something other than the tests which intentionally create different appcontexts. And it's easy to review. ------------- PR: https://git.openjdk.java.net/jdk/pull/5326 From asemenyuk at openjdk.java.net Thu Sep 9 23:17:33 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Thu, 9 Sep 2021 23:17:33 GMT Subject: [jdk17] RFR: JDK-8272639: jpackaged applications using microphone on mac In-Reply-To: References: Message-ID: <1AlOYCvtFfM7CegZOjEsuXJ5CEsdiw_C6Wh0QN_W4qE=.41de025c-a494-4509-b775-ae3fcc730224@github.com> On Thu, 9 Sep 2021 20:14:01 GMT, Andy Herrick wrote: > backport from jdk-18 Marked as reviewed by asemenyuk (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk17/pull/306 From naoto at openjdk.java.net Thu Sep 9 23:42:08 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 9 Sep 2021 23:42:08 GMT Subject: RFR: 8273491: java.util.spi.LocaleServiceProvider spec contains statement that is too strict Message-ID: Small spec clarification. Corresponding CSR has also been drafted. ------------- Commit messages: - 8273491: java.util.spi.LocaleServiceProvider spec contains statement that is too strict Changes: https://git.openjdk.java.net/jdk/pull/5457/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5457&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273491 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5457.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5457/head:pull/5457 PR: https://git.openjdk.java.net/jdk/pull/5457 From bpb at openjdk.java.net Thu Sep 9 23:48:06 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 9 Sep 2021 23:48:06 GMT Subject: RFR: 8271602: Add Math.ceilDiv() family parallel to Math.floorDiv() family In-Reply-To: <2RZKAf-GYIh36SSVTA-22F4qXJ72qNSwO3ZIO9wl9kE=.b08de4f8-34da-4658-9a05-1eec7bce88f4@github.com> References: <2RZKAf-GYIh36SSVTA-22F4qXJ72qNSwO3ZIO9wl9kE=.b08de4f8-34da-4658-9a05-1eec7bce88f4@github.com> Message-ID: On Wed, 1 Sep 2021 20:13:38 GMT, Raffaello Giulietti wrote: > This PR ideally continues #5285, which has been closed as a consequence of inadvertently removing the branch on my repo. See there for initial discussion. > > Sorry for the mess. src/java.base/share/classes/java/lang/StrictMath.java line 1464: > 1462: * Returns the ceiling modulus of the {@code long} arguments. > 1463: *

> 1464: * The floor modulus is {@code r = x - (ceilDiv(x, y) * y)}, In line 1464 I think `floor` should be `ceiling`. src/java.base/share/classes/java/lang/StrictMath.java line 1465: > 1463: *

> 1464: * The floor modulus is {@code r = x - (ceilDiv(x, y) * y)}, > 1465: * has the same sign as the divisor {@code y} or is zero, and In line 1465 I think `same` should be `opposite`. ------------- PR: https://git.openjdk.java.net/jdk/pull/5341 From bpb at openjdk.java.net Thu Sep 9 23:54:25 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 9 Sep 2021 23:54:25 GMT Subject: RFR: 8273513: Make java.io.FilterInputStream specification more precise about overrides [v2] In-Reply-To: References: Message-ID: > Modify the class level specification of `java.io.FilterInputStream` to be more exact about `java.io.InputStream` methods that it overrides. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8273513: Change key to select as suggested in CSR comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5426/files - new: https://git.openjdk.java.net/jdk/pull/5426/files/07dbe2fc..96f5ffc3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5426&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5426&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5426.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5426/head:pull/5426 PR: https://git.openjdk.java.net/jdk/pull/5426 From naoto at openjdk.java.net Fri Sep 10 00:43:02 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 10 Sep 2021 00:43:02 GMT Subject: RFR: 8273513: Make java.io.FilterInputStream specification more precise about overrides [v2] In-Reply-To: References: Message-ID: <3h9WQ60D6zmqGB7FYACFGQSJwCPMIm0pdd0UPQDGZTo=.a3db4cd5-128d-4a35-84d2-a7cfa55b5a35@github.com> On Thu, 9 Sep 2021 23:54:25 GMT, Brian Burkhalter wrote: >> Modify the class level specification of `java.io.FilterInputStream` to be more exact about `java.io.InputStream` methods that it overrides. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8273513: Change key to select as suggested in CSR comment LGTM. src/java.base/share/classes/java/io/FilterInputStream.java line 90: > 88: * This method simply performs the call > 89: * {@code read(b, 0, b.length)} and returns > 90: * the result. It is important that it does Preexisting: an extra space before "result." ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5426 From bpb at openjdk.java.net Fri Sep 10 00:56:29 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 10 Sep 2021 00:56:29 GMT Subject: RFR: 8273513: Make java.io.FilterInputStream specification more precise about overrides [v3] In-Reply-To: References: Message-ID: > Modify the class level specification of `java.io.FilterInputStream` to be more exact about `java.io.InputStream` methods that it overrides. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8273513: Remove an extra space ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5426/files - new: https://git.openjdk.java.net/jdk/pull/5426/files/96f5ffc3..bf2896a4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5426&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5426&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5426.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5426/head:pull/5426 PR: https://git.openjdk.java.net/jdk/pull/5426 From jai.forums2013 at gmail.com Fri Sep 10 01:57:27 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Fri, 10 Sep 2021 07:27:27 +0530 Subject: RFR: 8231640: (prop) Canonical property storage [v7] In-Reply-To: References: Message-ID: Hello Roger, On 10/09/21 12:32 am, Roger Riggs wrote: > src/java.base/share/classes/java/util/Properties.java line 187: > >> 185: ? System.getenv("SOURCE_DATE_EPOCH") >> 186: : AccessController.doPrivileged((PrivilegedAction) >> 187: () -> System.getenv("SOURCE_DATE_EPOCH")); > The format of SOURCE_DATE_EPOCH is fine, but referring to an external document as part of the OpenJDK spec is undesirable in the long run. Previous comments gave support to using the environment variable directly but > it very unlike similar cases that use system properties when the behavior of an API needs to be overridden or modified. > > As a system property, specified on the command line, it would be visible when the program is invoked, > explicitly intended to change behavior and not having a context sensitive effect. Named perhaps, java.util.Properties.storeDate. Would this system property have a value that represents what SOURCE_DATE_EPOCH environment variable would have contained? i.e. it is the "A UNIX timestamp, defined as the number of seconds, excluding leap seconds, since 01 Jan 1970 00:00:00 UTC."? So users can potentially do -Djava.util.Properties.storeDate=${SOURCE_DATE_EPOCH}? Or would this system property be just some kind flag, which when having a value of "true" would expect the java.util.Properties code to lookup the SOURCE_DATE_EPOCH environment variable and use that value from the environment variable? I'm guessing it's the former where the value is the number of epoch seconds, but just wanted to be sure before I do this change. > (BTW, there is no need to special case doPriv calls, they are pretty well optimized when the security manager is not set and it keeps the code simpler.) From what I see in the implementation of AccessController.doPriveleged(), I see that it does a bunch of uncoditional work (like Reflection.getCallerClass() and then Reference.reachabilityFence() calls). Do you mean that additional work is neglible in the absence of a security manager, that this special casing of the doPriv call can be removed? > Given the low frequency of calls to store(), even caching the parsed date doesn't save much. > And the cost is the cost of the size and loading an extra class. Sounds fine. I'll remove the caching part in my subsequent update. -Jaikiran From joe.darcy at oracle.com Fri Sep 10 05:02:08 2021 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Thu, 9 Sep 2021 22:02:08 -0700 Subject: How can I trigger a @Serial warning? In-Reply-To: <2f2afdb5-c5a0-0cce-a492-8d589b8f058a@gmail.com> References: <2f2afdb5-c5a0-0cce-a492-8d589b8f058a@gmail.com> Message-ID: <584486d8-48be-73da-c358-e579587d048b@oracle.com> Hi Cay, The enhancements to javac's serial lint checking have not been implemented as of yet. For now, @Serial is just documentation. HTH, -Joe On 9/8/2021 10:43 PM, Cay Horstmann wrote: > I am trying to give an example of the utility of the @Serial > annotation. But the JDK 17 javac doesn't seem to do anything with it. > I tried: > > @Serial private void readObject(java.io.ObjectInputStream stream, int > shouldNotHaveThisParam) throws IOException, ClassNotFoundException > @Serial private static final String serialVersionUID = "Fred"; > @Serial public String getName() { ... } > > Is there some flag that I need to use? I tried -Xlint:serial, but it > didn't make a difference. > > Thanks, > > Cay > From jpai at openjdk.java.net Fri Sep 10 05:24:38 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Fri, 10 Sep 2021 05:24:38 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v8] In-Reply-To: References: Message-ID: > The commit in this PR implements the proposal for enhancement that was discussed in the core-libs-dev mailing list recently[1], for https://bugs.openjdk.java.net/browse/JDK-8231640 > > At a high level - the `store()` APIs in `Properties` have been modified to now look for the `SOURCE_DATE_EPOCH` environment variable[2]. If that env variable is set, then instead of writing out the current date time as a date comment, the `store()` APIs instead will use the value set for this env variable to parse it to a `Date` and write out the string form of such a date. The implementation here uses the `d MMM yyyy HH:mm:ss 'GMT'` date format and `Locale.ROOT` to format and write out such a date. This should provide reproducibility whenever the `SOURCE_DATE_EPOCH` is set. Furthermore, intentionally, no changes in the date format of the "current date" have been done. > > These modified `store()` APIs work in the presence of the `SecurityManager` too. The caller is expected to have a read permission on the `SOURCE_DATE_EPOCH` environment variable. If the caller doesn't have that permission, then the implementation of these `store()` APIs will write out the "current date" and will ignore any value that has been set for the `SOURCE_DATE_EPOCH` env variable. This should allow for backward compatibility of existing applications, where, when they run under a `SecurityManager` and perhaps with an existing restrictive policy file, the presence of `SOURCE_DATE_EPOCH` shouldn't impact their calls to the `store()` APIs. > > The modified `store()` APIs will also ignore any value for `SOURCE_DATE_EPOCH` that cannot be parsed to an `long` value. In such cases, the `store()` APIs will write out the "current date" and ignore the value set for this environment variable. No exceptions will be thrown for such invalid values. This is an additional backward compatibility precaution to prevent any rogue value for `SOURCE_DATE_EPOCH` from breaking applications. > > An additional change in the implementation of these `store()` APIs and unrelated to the date comment, is that these APIs will now write out the property keys in a deterministic order. The keys will be written out in the natural ordering as specified by `java.lang.String#compareTo()` API. > > The combination of the ordering of the property keys when written out and the usage of `SOURCE_DATE_EPOCH` environment value to determine the date comment should together allow for reproducibility of the output generated by these `store()` APIs. > > New jtreg test classes have been introduced to verify these changes. The primary focus of `PropertiesStoreTest` is the ordering aspects of the property keys that are written out. On the other hand `StoreReproducibilityTest` focuses on the reproducibility of the output generated by these APIs. The `StoreReproducibilityTest` runs these tests both in the presence and absence of `SecurityManager`. Plus, in the presence of SecurityManager, it tests both the scenarios where the caller is granted the requisite permission and in other case not granted that permission. > > These new tests and existing tests under `test/jdk/java/util/Properties/` pass with these changes. > > [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-August/080758.html > [2] https://reproducible-builds.org/specs/source-date-epoch/ Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: Implement Roger's suggestions: - Rely on java.util.Properties.storeDate system property instead of SOURCE_DATE_EPOCH environment variable - No need for caching the parsed date - Update the javadoc to match new expectations - Update tests to match the new expectations ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5372/files - new: https://git.openjdk.java.net/jdk/pull/5372/files/a29d0f08..a9b71d2f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5372&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5372&range=06-07 Stats: 149 lines in 4 files changed: 50 ins; 39 del; 60 mod Patch: https://git.openjdk.java.net/jdk/pull/5372.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5372/head:pull/5372 PR: https://git.openjdk.java.net/jdk/pull/5372 From github.com+332398+kabutz at openjdk.java.net Fri Sep 10 06:25:23 2021 From: github.com+332398+kabutz at openjdk.java.net (kabutz) Date: Fri, 10 Sep 2021 06:25:23 GMT Subject: RFR: 8273541: Cleaner Thread creates with normal priority instead of MAX_PRIORITY - 2 Message-ID: <1NRlROh9TTsjWpOfyZNQohDUcdkn__KnwD90pu6t6X4=.1b9d7bb8-3bc9-403c-8006-4cdde210dd5d@github.com> ?of MAX_PRIORITY-2 during refactoring Appears in Java 17 for the first time. During refactoring, the priority was changed from Thread.MAX_PRIORITY - 2 to instead state Thread.MIN_PRIORITY - 2, which results in a negative priority, and is thus set to Thread.NORM_PRIORITY. Thus the Cleaner by default now has threads with priority 5, instead of 8. The change was done in git revision # 992b50087d2ec8878dfcbbd1820a00b6b6bdf644 and label 8261036 by Claes Redestad ------------- Commit messages: - Merge branch 'openjdk:master' into thread_priority - Merge remote-tracking branch 'origin/thread_priority' into thread_priority - Merge branch 'openjdk:master' into thread_priority - Merge branch 'openjdk:master' into thread_priority - Merge branch 'openjdk:master' into thread_priority - Redo the change to MAX_PRIORITY - 2 - Removed stray "java" - Thread priority of Cleaner threads was set to MIN_PRIORITY-2 instead of MAX_PRIORITY-2 during refactoring Changes: https://git.openjdk.java.net/jdk/pull/5439/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5439&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273541 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5439.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5439/head:pull/5439 PR: https://git.openjdk.java.net/jdk/pull/5439 From shade at openjdk.java.net Fri Sep 10 06:25:23 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 10 Sep 2021 06:25:23 GMT Subject: RFR: 8273541: Cleaner Thread creates with normal priority instead of MAX_PRIORITY - 2 In-Reply-To: <1NRlROh9TTsjWpOfyZNQohDUcdkn__KnwD90pu6t6X4=.1b9d7bb8-3bc9-403c-8006-4cdde210dd5d@github.com> References: <1NRlROh9TTsjWpOfyZNQohDUcdkn__KnwD90pu6t6X4=.1b9d7bb8-3bc9-403c-8006-4cdde210dd5d@github.com> Message-ID: On Thu, 9 Sep 2021 10:14:48 GMT, kabutz wrote: > ?of MAX_PRIORITY-2 during refactoring > > Appears in Java 17 for the first time. > > During refactoring, the priority was changed from Thread.MAX_PRIORITY - 2 to instead state Thread.MIN_PRIORITY - 2, which results in a negative priority, and is thus set to Thread.NORM_PRIORITY. Thus the Cleaner by default now has threads with priority 5, instead of 8. > > The change was done in git revision # 992b50087d2ec8878dfcbbd1820a00b6b6bdf644 and label 8261036 by Claes Redestad This looks good. @cl4es might want to confirm that change was not intentional. Please change the PR title to "8273541: Cleaner Thread creates with normal priority instead of MAX_PRIORITY - 2" to get it automatically hooked by bots. src/java.base/share/classes/jdk/internal/ref/CleanerImpl.java line 228: > 226: super(cleaner, cleaner); > 227: } > 228: java Stray change. ------------- Changes requested by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5439 From alanb at openjdk.java.net Fri Sep 10 06:25:24 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 10 Sep 2021 06:25:24 GMT Subject: RFR: 8273541: Cleaner Thread creates with normal priority instead of MAX_PRIORITY - 2 In-Reply-To: <1NRlROh9TTsjWpOfyZNQohDUcdkn__KnwD90pu6t6X4=.1b9d7bb8-3bc9-403c-8006-4cdde210dd5d@github.com> References: <1NRlROh9TTsjWpOfyZNQohDUcdkn__KnwD90pu6t6X4=.1b9d7bb8-3bc9-403c-8006-4cdde210dd5d@github.com> Message-ID: <2TUxfre0iQqNGbcSkYJezga0dMUA7MdgzEe6eB343nk=.922d46d7-5354-4619-a081-946c87debacc@github.com> On Thu, 9 Sep 2021 10:14:48 GMT, kabutz wrote: > ?of MAX_PRIORITY-2 during refactoring > > Appears in Java 17 for the first time. > > During refactoring, the priority was changed from Thread.MAX_PRIORITY - 2 to instead state Thread.MIN_PRIORITY - 2, which results in a negative priority, and is thus set to Thread.NORM_PRIORITY. Thus the Cleaner by default now has threads with priority 5, instead of 8. > > The change was done in git revision # 992b50087d2ec8878dfcbbd1820a00b6b6bdf644 and label 8261036 by Claes Redestad I've created JDK-8273541 to track this. It looks like d621cdd957b78e53ea63b6b9bb2fce08560a8620 has undone the changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/5439 From github.com+332398+kabutz at openjdk.java.net Fri Sep 10 06:25:24 2021 From: github.com+332398+kabutz at openjdk.java.net (kabutz) Date: Fri, 10 Sep 2021 06:25:24 GMT Subject: RFR: 8273541: Cleaner Thread creates with normal priority instead of MAX_PRIORITY - 2 In-Reply-To: References: <1NRlROh9TTsjWpOfyZNQohDUcdkn__KnwD90pu6t6X4=.1b9d7bb8-3bc9-403c-8006-4cdde210dd5d@github.com> Message-ID: On Thu, 9 Sep 2021 13:38:32 GMT, Aleksey Shipilev wrote: >> ?of MAX_PRIORITY-2 during refactoring >> >> Appears in Java 17 for the first time. >> >> During refactoring, the priority was changed from Thread.MAX_PRIORITY - 2 to instead state Thread.MIN_PRIORITY - 2, which results in a negative priority, and is thus set to Thread.NORM_PRIORITY. Thus the Cleaner by default now has threads with priority 5, instead of 8. >> >> The change was done in git revision # 992b50087d2ec8878dfcbbd1820a00b6b6bdf644 and label 8261036 by Claes Redestad > > Please change the PR title to "8273541: Cleaner Thread creates with normal priority instead of MAX_PRIORITY - 2" to get it automatically hooked by bots. Why would jcheck say "This PR contains no changes" @shipilev ? ------------- PR: https://git.openjdk.java.net/jdk/pull/5439 From github.com+332398+kabutz at openjdk.java.net Fri Sep 10 06:25:24 2021 From: github.com+332398+kabutz at openjdk.java.net (kabutz) Date: Fri, 10 Sep 2021 06:25:24 GMT Subject: RFR: 8273541: Cleaner Thread creates with normal priority instead of MAX_PRIORITY - 2 In-Reply-To: <1NRlROh9TTsjWpOfyZNQohDUcdkn__KnwD90pu6t6X4=.1b9d7bb8-3bc9-403c-8006-4cdde210dd5d@github.com> References: <1NRlROh9TTsjWpOfyZNQohDUcdkn__KnwD90pu6t6X4=.1b9d7bb8-3bc9-403c-8006-4cdde210dd5d@github.com> Message-ID: On Thu, 9 Sep 2021 10:14:48 GMT, kabutz wrote: > ?of MAX_PRIORITY-2 during refactoring > > Appears in Java 17 for the first time. > > During refactoring, the priority was changed from Thread.MAX_PRIORITY - 2 to instead state Thread.MIN_PRIORITY - 2, which results in a negative priority, and is thus set to Thread.NORM_PRIORITY. Thus the Cleaner by default now has threads with priority 5, instead of 8. > > The change was done in git revision # 992b50087d2ec8878dfcbbd1820a00b6b6bdf644 and label 8261036 by Claes Redestad > It looks like [d621cdd](https://github.com/openjdk/jdk/commit/d621cdd957b78e53ea63b6b9bb2fce08560a8620) has undone the changes. Thanks Alan! ------------- PR: https://git.openjdk.java.net/jdk/pull/5439 From lancea at openjdk.java.net Fri Sep 10 06:25:25 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Fri, 10 Sep 2021 06:25:25 GMT Subject: RFR: 8273541: Cleaner Thread creates with normal priority instead of MAX_PRIORITY - 2 In-Reply-To: References: <1NRlROh9TTsjWpOfyZNQohDUcdkn__KnwD90pu6t6X4=.1b9d7bb8-3bc9-403c-8006-4cdde210dd5d@github.com> Message-ID: On Thu, 9 Sep 2021 13:37:23 GMT, Aleksey Shipilev wrote: >> ?of MAX_PRIORITY-2 during refactoring >> >> Appears in Java 17 for the first time. >> >> During refactoring, the priority was changed from Thread.MAX_PRIORITY - 2 to instead state Thread.MIN_PRIORITY - 2, which results in a negative priority, and is thus set to Thread.NORM_PRIORITY. Thus the Cleaner by default now has threads with priority 5, instead of 8. >> >> The change was done in git revision # 992b50087d2ec8878dfcbbd1820a00b6b6bdf644 and label 8261036 by Claes Redestad > > src/java.base/share/classes/jdk/internal/ref/CleanerImpl.java line 228: > >> 226: super(cleaner, cleaner); >> 227: } >> 228: java > > Stray change. Not sure what the "java" is for here seems like a typo ------------- PR: https://git.openjdk.java.net/jdk/pull/5439 From github.com+332398+kabutz at openjdk.java.net Fri Sep 10 06:25:25 2021 From: github.com+332398+kabutz at openjdk.java.net (kabutz) Date: Fri, 10 Sep 2021 06:25:25 GMT Subject: RFR: 8273541: Cleaner Thread creates with normal priority instead of MAX_PRIORITY - 2 In-Reply-To: References: <1NRlROh9TTsjWpOfyZNQohDUcdkn__KnwD90pu6t6X4=.1b9d7bb8-3bc9-403c-8006-4cdde210dd5d@github.com> Message-ID: On Thu, 9 Sep 2021 15:36:08 GMT, Lance Andersen wrote: >> src/java.base/share/classes/jdk/internal/ref/CleanerImpl.java line 228: >> >>> 226: super(cleaner, cleaner); >>> 227: } >>> 228: java >> >> Stray change. > > Not sure what the "java" is for here seems like a typo Yes, sorry. ------------- PR: https://git.openjdk.java.net/jdk/pull/5439 From shade at openjdk.java.net Fri Sep 10 06:55:59 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 10 Sep 2021 06:55:59 GMT Subject: RFR: 8273541: Cleaner Thread creates with normal priority instead of MAX_PRIORITY - 2 In-Reply-To: <1NRlROh9TTsjWpOfyZNQohDUcdkn__KnwD90pu6t6X4=.1b9d7bb8-3bc9-403c-8006-4cdde210dd5d@github.com> References: <1NRlROh9TTsjWpOfyZNQohDUcdkn__KnwD90pu6t6X4=.1b9d7bb8-3bc9-403c-8006-4cdde210dd5d@github.com> Message-ID: On Thu, 9 Sep 2021 10:14:48 GMT, kabutz wrote: > ?of MAX_PRIORITY-2 during refactoring > > Appears in Java 17 for the first time. > > During refactoring, the priority was changed from Thread.MAX_PRIORITY - 2 to instead state Thread.MIN_PRIORITY - 2, which results in a negative priority, and is thus set to Thread.NORM_PRIORITY. Thus the Cleaner by default now has threads with priority 5, instead of 8. > > The change was done in git revision # 992b50087d2ec8878dfcbbd1820a00b6b6bdf644 and label 8261036 by Claes Redestad This looks fine to me. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5439 From rfscholte at apache.org Fri Sep 10 07:01:56 2021 From: rfscholte at apache.org (Robert Scholte) Date: Fri, 10 Sep 2021 07:01:56 +0000 Subject: RFR: 8231640: (prop) Canonical property storage [v7] In-Reply-To: References: Message-ID: Looking at the discussion I see a fear of extending the Properties API, where every solution comes with its own little ugliness. There's one topic that hasn't been mentioned yet: is Properties responsible for writing its own content? While breaking up the JDK into modules, an weird thing was exposed: storeToXML, which would need a dependency on java.xml but java.base does not. Should there be a new class for writing Properties, where we have the control for specifying a new clean API? thanks, Robert ------ Origineel bericht ------ Van: "Jaikiran Pai" Aan: core-libs-dev at openjdk.java.net; "Roger Riggs" Verzonden: 10-9-2021 03:57:27 Onderwerp: Re: RFR: 8231640: (prop) Canonical property storage [v7] >Hello Roger, > >On 10/09/21 12:32 am, Roger Riggs wrote: >>src/java.base/share/classes/java/util/Properties.java line 187: >> >>>185: ? System.getenv("SOURCE_DATE_EPOCH") >>>186: : AccessController.doPrivileged((PrivilegedAction) >>>187: () -> System.getenv("SOURCE_DATE_EPOCH")); >>The format of SOURCE_DATE_EPOCH is fine, but referring to an external document as part of the OpenJDK spec is undesirable in the long run. Previous comments gave support to using the environment variable directly but >>it very unlike similar cases that use system properties when the behavior of an API needs to be overridden or modified. >> >>As a system property, specified on the command line, it would be visible when the program is invoked, >>explicitly intended to change behavior and not having a context sensitive effect. Named perhaps, java.util.Properties.storeDate. > >Would this system property have a value that represents what SOURCE_DATE_EPOCH environment variable would have contained? i.e. it is the "A UNIX timestamp, defined as the number of seconds, excluding leap seconds, since 01 Jan 1970 00:00:00 UTC."? So users can potentially do -Djava.util.Properties.storeDate=${SOURCE_DATE_EPOCH}? > >Or would this system property be just some kind flag, which when having a value of "true" would expect the java.util.Properties code to lookup the SOURCE_DATE_EPOCH environment variable and use that value from the environment variable? > >I'm guessing it's the former where the value is the number of epoch seconds, but just wanted to be sure before I do this change. > >> (BTW, there is no need to special case doPriv calls, they are pretty well optimized when the security manager is not set and it keeps the code simpler.) > >From what I see in the implementation of AccessController.doPriveleged(), I see that it does a bunch of uncoditional work (like Reflection.getCallerClass() and then Reference.reachabilityFence() calls). Do you mean that additional work is neglible in the absence of a security manager, that this special casing of the doPriv call can be removed? > >>Given the low frequency of calls to store(), even caching the parsed date doesn't save much. >>And the cost is the cost of the size and loading an extra class. > >Sounds fine. I'll remove the caching part in my subsequent update. > > >-Jaikiran > > From alanb at openjdk.java.net Fri Sep 10 07:12:09 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 10 Sep 2021 07:12:09 GMT Subject: RFR: 8273541: Cleaner Thread creates with normal priority instead of MAX_PRIORITY - 2 In-Reply-To: <1NRlROh9TTsjWpOfyZNQohDUcdkn__KnwD90pu6t6X4=.1b9d7bb8-3bc9-403c-8006-4cdde210dd5d@github.com> References: <1NRlROh9TTsjWpOfyZNQohDUcdkn__KnwD90pu6t6X4=.1b9d7bb8-3bc9-403c-8006-4cdde210dd5d@github.com> Message-ID: <6FWnmeP0wxaLnDM-fL3a68vHdBlyPz8fLeyZh2iNFvc=.eaee446b-479b-43cf-bed0-71f2b2bd22ce@github.com> On Thu, 9 Sep 2021 10:14:48 GMT, kabutz wrote: > ?of MAX_PRIORITY-2 during refactoring > > Appears in Java 17 for the first time. > > During refactoring, the priority was changed from Thread.MAX_PRIORITY - 2 to instead state Thread.MIN_PRIORITY - 2, which results in a negative priority, and is thus set to Thread.NORM_PRIORITY. Thus the Cleaner by default now has threads with priority 5, instead of 8. > > The change was done in git revision # 992b50087d2ec8878dfcbbd1820a00b6b6bdf644 and label 8261036 by Claes Redestad Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5439 From shade at openjdk.java.net Fri Sep 10 07:23:06 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 10 Sep 2021 07:23:06 GMT Subject: RFR: 8273494: Zero: Put libjvm.so into "zero" folder, not "server" In-Reply-To: References: Message-ID: <8vaICuN5ZWtQ8WJyIrW_-My_g72eC_TYdL6KtGE8NOs=.deb9e722-2f77-4cec-a2b3-4f9cc9db479a@github.com> On Thu, 9 Sep 2021 14:31:19 GMT, Magnus Ihse Bursie wrote: >> Currently, the build system defaults the libjvm.so location to "server". This makes looking for `libjvm.so` awkward, see JDK-8273487 for example. We need to see if moving the libjvm.so to a proper location breaks anything. >> >> Additional testing: >> - [x] Linux x86_64 Zero build >> - [x] Linux x86_64 Zero bootcycle-images >> - [ ] Linux x86_64 Zero `tier1` > > And as for @dholmes-ora comment: I'm not sure who "own" zero at this point in time. Aleksey has made a lot of the zero patches lately; does that not count? Are you thinking about any specific person that needs to weight in on this? > @magicus every "port" in OpenJDK is supposed to have a clear owner and support system. Zero has been somewhat lacking in that area but there were enough people to keep it surviving. Now I'm not so sure. Does Zero have an active user community? Developer community? If so they are the ones who need to assess this change. FWIW, Zero had fallen into Red Hat hands for support. The official lead (if you look at Census) is Gary Benson, who is not active in this project anymore. Since then, it was mostly supported by RH folks (like me) with contributions from Debian, Tencent, Huawei, Alibaba -- mostly because all of us have arch ports that do not have full-blown Server VMs yet. I have put things in motion to claim the leadership more formally. I do have to note, though, that over the last few years of me whipping Zero into shape, this is the first time anyone asked the formal governance question, which must tell us something about how much we care about ownership formalities here ;) ------------- PR: https://git.openjdk.java.net/jdk/pull/5440 From Alan.Bateman at oracle.com Fri Sep 10 07:42:36 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 10 Sep 2021 08:42:36 +0100 Subject: RFR: 8231640: (prop) Canonical property storage [v7] In-Reply-To: References: Message-ID: <8bef6847-ff39-2364-328e-65a09785f6fe@oracle.com> On 10/09/2021 08:01, Robert Scholte wrote: > Looking at the discussion I see a fear of extending the Properties > API, where every solution comes with its own little ugliness. > > There's one topic that hasn't been mentioned yet: is Properties > responsible for writing its own content? > While breaking up the JDK into modules, an weird thing was exposed: > storeToXML, which would need a dependency on java.xml but java.base > does not. > > Should there be a new class for writing Properties, where we have the > control for specifying a new clean API? Properties is a Map so anyone can write the mappings out in any format they want. The properties format that the store methods are specified to write involve escaping characters that aren't in Latin-1 so a bit tricky, but not impossible. The storeToXML method is unfortunate but we have an implementation in java.base so all good. A number of us discussed this topic yesterday and converged on change the existing store methods to have a standard property to configure the timestamp. Separately, we can explore a 1-arg store method that does not write any comments. There is more on the PR on this. -Alan From dfuchs at openjdk.java.net Fri Sep 10 09:02:08 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 10 Sep 2021 09:02:08 GMT Subject: RFR: 8273484: Cleanup unnecessary null comparison before instanceof check in java.naming [v2] In-Reply-To: References: Message-ID: <6tOLve9Y6i5GefBXkB-OxVRuk6RvXvlRYXj9bVXEZrM=.aea43fcb-0065-40d8-8691-cc63b2ae1f25@github.com> On Thu, 9 Sep 2021 13:24:27 GMT, Andrey Turbanov wrote: >> Update code checks both non-null and instance of a class in java.naming module classes. >> The checks and explicit casts could also be replaced with pattern matching for the instanceof operator. >> For example: >> The following code: >> >> return (obj != null && >> obj instanceof CompoundName && >> impl.equals(((CompoundName)obj).impl)); >> >> >> Can be simplified to: >> >> >> return (obj instanceof CompoundName other) && >> impl.equals(other.impl); >> >> >> See similar cleanup in java.base - https://bugs.openjdk.java.net/browse/JDK-8258422 > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8273484: Cleanup unnecessary null comparison before instanceof check in java.naming Nice simplification and usage of the new instanceof pattern. Thanks Andrey for this patch! LGTM - Aleksei or I will sponsor this if needed. ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5374 From dfuchs at openjdk.java.net Fri Sep 10 09:06:04 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 10 Sep 2021 09:06:04 GMT Subject: RFR: 8273402: Use derived NamingExceptions in com.sun.jndi.ldap.Connection#readReply In-Reply-To: References: Message-ID: <2-aWow49Qu_LFYMk_u05wwJVLwH8GTmVBla6Ar13Evs=.bec2a019-af36-4a9f-b1d2-395208d6e077@github.com> On Thu, 9 Sep 2021 22:02:55 GMT, Aleksei Efimov wrote: > Hi, > The following fix changes type of exception thrown when an LDAP operation fails for reasons like read timeout or connection closure/cancellation: instead of throwing a general `NamingException`, the internal LDAP connection class will throw a [`CommunicationException`](https://github.com/openjdk/jdk/blob/master/src/java.naming/share/classes/javax/naming/CommunicationException.java#L29) that better matches the reasons described. > > Testing shows no problem with the proposed fix. Thanks Aleksei. Using an IOException as the cause of CommunicationException, rather than a plain NamingException, to convey exceptional cases like "connection closed" seems to be the right choice to me. ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5456 From myano at openjdk.java.net Fri Sep 10 09:33:33 2021 From: myano at openjdk.java.net (Masanori Yano) Date: Fri, 10 Sep 2021 09:33:33 GMT Subject: RFR: 8233674: JarURLConnection.getJarFile throws Exception if some process is holding the file Message-ID: Could you please review the 8233674 bug fixes? This problem is caused by the antivirus software opening the file for a short time, so CreateFile() should be retried. ------------- Commit messages: - 8233674: JarURLConnection.getJarFile throws Exception if some process is holding the file Changes: https://git.openjdk.java.net/jdk/pull/5460/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5460&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8233674 Stats: 299 lines in 3 files changed: 261 ins; 12 del; 26 mod Patch: https://git.openjdk.java.net/jdk/pull/5460.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5460/head:pull/5460 PR: https://git.openjdk.java.net/jdk/pull/5460 From dholmes at openjdk.java.net Fri Sep 10 10:06:09 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 10 Sep 2021 10:06:09 GMT Subject: RFR: 8273494: Zero: Put libjvm.so into "zero" folder, not "server" In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 10:17:02 GMT, Aleksey Shipilev wrote: > Currently, the build system defaults the libjvm.so location to "server". This makes looking for `libjvm.so` awkward, see JDK-8273487 for example. We need to see if moving the libjvm.so to a proper location breaks anything. > > Additional testing: > - [x] Linux x86_64 Zero build > - [x] Linux x86_64 Zero bootcycle-images > - [ ] Linux x86_64 Zero `tier1` It isn't the "formal governance" I'm concerned about, more about the folk who use/rely on Zero being the ones to evaluate the impact of a change like this. People, like myself, who do not use Zero in any way cannot evaluate whether this change is appropriate - it's that simple. :) ------------- PR: https://git.openjdk.java.net/jdk/pull/5440 From jpai at openjdk.java.net Fri Sep 10 10:15:45 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Fri, 10 Sep 2021 10:15:45 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v9] In-Reply-To: References: Message-ID: > The commit in this PR implements the proposal for enhancement that was discussed in the core-libs-dev mailing list recently[1], for https://bugs.openjdk.java.net/browse/JDK-8231640 > > At a high level - the `store()` APIs in `Properties` have been modified to now look for the `SOURCE_DATE_EPOCH` environment variable[2]. If that env variable is set, then instead of writing out the current date time as a date comment, the `store()` APIs instead will use the value set for this env variable to parse it to a `Date` and write out the string form of such a date. The implementation here uses the `d MMM yyyy HH:mm:ss 'GMT'` date format and `Locale.ROOT` to format and write out such a date. This should provide reproducibility whenever the `SOURCE_DATE_EPOCH` is set. Furthermore, intentionally, no changes in the date format of the "current date" have been done. > > These modified `store()` APIs work in the presence of the `SecurityManager` too. The caller is expected to have a read permission on the `SOURCE_DATE_EPOCH` environment variable. If the caller doesn't have that permission, then the implementation of these `store()` APIs will write out the "current date" and will ignore any value that has been set for the `SOURCE_DATE_EPOCH` env variable. This should allow for backward compatibility of existing applications, where, when they run under a `SecurityManager` and perhaps with an existing restrictive policy file, the presence of `SOURCE_DATE_EPOCH` shouldn't impact their calls to the `store()` APIs. > > The modified `store()` APIs will also ignore any value for `SOURCE_DATE_EPOCH` that cannot be parsed to an `long` value. In such cases, the `store()` APIs will write out the "current date" and ignore the value set for this environment variable. No exceptions will be thrown for such invalid values. This is an additional backward compatibility precaution to prevent any rogue value for `SOURCE_DATE_EPOCH` from breaking applications. > > An additional change in the implementation of these `store()` APIs and unrelated to the date comment, is that these APIs will now write out the property keys in a deterministic order. The keys will be written out in the natural ordering as specified by `java.lang.String#compareTo()` API. > > The combination of the ordering of the property keys when written out and the usage of `SOURCE_DATE_EPOCH` environment value to determine the date comment should together allow for reproducibility of the output generated by these `store()` APIs. > > New jtreg test classes have been introduced to verify these changes. The primary focus of `PropertiesStoreTest` is the ordering aspects of the property keys that are written out. On the other hand `StoreReproducibilityTest` focuses on the reproducibility of the output generated by these APIs. The `StoreReproducibilityTest` runs these tests both in the presence and absence of `SecurityManager`. Plus, in the presence of SecurityManager, it tests both the scenarios where the caller is granted the requisite permission and in other case not granted that permission. > > These new tests and existing tests under `test/jdk/java/util/Properties/` pass with these changes. > > [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-August/080758.html > [2] https://reproducible-builds.org/specs/source-date-epoch/ Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: jcheck fix - trailing whitespace in test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5372/files - new: https://git.openjdk.java.net/jdk/pull/5372/files/a9b71d2f..06ff3bdb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5372&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5372&range=07-08 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5372.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5372/head:pull/5372 PR: https://git.openjdk.java.net/jdk/pull/5372 From kcr at openjdk.java.net Fri Sep 10 10:47:21 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 10 Sep 2021 10:47:21 GMT Subject: [jdk17] RFR: JDK-8272639: jpackaged applications using microphone on mac In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 20:14:01 GMT, Andy Herrick wrote: > backport from jdk-18 This must _not_ be integrated into this repo. See [JDK-8273592](https://bugs.openjdk.java.net/browse/JDK-8273592) for an explanation as to why. There is no more content approved for JDK 17. This should go into [openjdk/jdk17u](https://github.com/openjdk/jdk17u). ------------- PR: https://git.openjdk.java.net/jdk17/pull/306 From kcr at openjdk.java.net Fri Sep 10 10:47:21 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 10 Sep 2021 10:47:21 GMT Subject: [jdk17] Withdrawn: JDK-8272639: jpackaged applications using microphone on mac In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 20:14:01 GMT, Andy Herrick wrote: > backport from jdk-18 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk17/pull/306 From lancea at openjdk.java.net Fri Sep 10 10:49:07 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Fri, 10 Sep 2021 10:49:07 GMT Subject: RFR: 8273541: Cleaner Thread creates with normal priority instead of MAX_PRIORITY - 2 In-Reply-To: <1NRlROh9TTsjWpOfyZNQohDUcdkn__KnwD90pu6t6X4=.1b9d7bb8-3bc9-403c-8006-4cdde210dd5d@github.com> References: <1NRlROh9TTsjWpOfyZNQohDUcdkn__KnwD90pu6t6X4=.1b9d7bb8-3bc9-403c-8006-4cdde210dd5d@github.com> Message-ID: On Thu, 9 Sep 2021 10:14:48 GMT, kabutz wrote: > ?of MAX_PRIORITY-2 during refactoring > > Appears in Java 17 for the first time. > > During refactoring, the priority was changed from Thread.MAX_PRIORITY - 2 to instead state Thread.MIN_PRIORITY - 2, which results in a negative priority, and is thus set to Thread.NORM_PRIORITY. Thus the Cleaner by default now has threads with priority 5, instead of 8. > > The change was done in git revision # 992b50087d2ec8878dfcbbd1820a00b6b6bdf644 and label 8261036 by Claes Redestad This should be ready to integrate so please enter /integrate in a new comment and then it can be sponsored. Thank you ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5439 From mbaesken at openjdk.java.net Fri Sep 10 11:07:53 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Fri, 10 Sep 2021 11:07:53 GMT Subject: RFR: JDK-8273526: Extend the OSContainer API pids controller with pids.current In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 09:21:59 GMT, Matthias Baesken wrote: > https://bugs.openjdk.java.net/browse/JDK-8266490 > extended the OSContainer API in order to also support the pids controller of cgroups. However only pids.max output was added with 8266490. > There is a second parameter pids.current , see https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#pid > that would be helpful too and can be added to the OSContainer API . > pids.current : > A read-only single value file which exists on all cgroups. > The number of processes currently in the cgroup and its descendants. > > Best regards, Matthias Hi Severin, I added another commit dealing with your comments. Thanks, Matthias ------------- PR: https://git.openjdk.java.net/jdk/pull/5437 From mbaesken at openjdk.java.net Fri Sep 10 11:07:52 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Fri, 10 Sep 2021 11:07:52 GMT Subject: RFR: JDK-8273526: Extend the OSContainer API pids controller with pids.current [v2] In-Reply-To: References: Message-ID: <3PokFyPHsil0S9A15OWUj97Xls1tFpkeXuqHydXnh4o=.64e6daaa-5dc3-438c-b362-ba61775d1403@github.com> > https://bugs.openjdk.java.net/browse/JDK-8266490 > extended the OSContainer API in order to also support the pids controller of cgroups. However only pids.max output was added with 8266490. > There is a second parameter pids.current , see https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#pid > that would be helpful too and can be added to the OSContainer API . > pids.current : > A read-only single value file which exists on all cgroups. > The number of processes currently in the cgroup and its descendants. > > Best regards, Matthias Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Some simplifications and test adjustment suggested by Severin ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5437/files - new: https://git.openjdk.java.net/jdk/pull/5437/files/aa93a12b..422aef68 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5437&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5437&range=00-01 Stats: 13 lines in 3 files changed: 8 ins; 1 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/5437.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5437/head:pull/5437 PR: https://git.openjdk.java.net/jdk/pull/5437 From aoqi at openjdk.java.net Fri Sep 10 12:14:25 2021 From: aoqi at openjdk.java.net (Ao Qi) Date: Fri, 10 Sep 2021 12:14:25 GMT Subject: RFR: 8273595: tools/jpackage tests do not work on apt-based Linux Distros like Debian Message-ID: A similar issue on Ubuntu has been fixed by [JDK-8238953](https://bugs.openjdk.java.net/browse/JDK-8238953). However, tools/jpackage tests do not work on Debian Linux or other apt-based Linux, when rpm package is installed. This issue proposes a general fix for apt-based Linux. ------------- Commit messages: - copyright year update and less import - 8273595: tools/jpackage tests do not work on apt-based Linux Distros like Debian Changes: https://git.openjdk.java.net/jdk/pull/5462/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5462&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273595 Stats: 20 lines in 2 files changed: 0 ins; 15 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/5462.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5462/head:pull/5462 PR: https://git.openjdk.java.net/jdk/pull/5462 From naoto at openjdk.java.net Fri Sep 10 12:21:41 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 10 Sep 2021 12:21:41 GMT Subject: RFR: 8273259: Character.getName doesn't follow Unicode spec for ideographs [v3] In-Reply-To: <3ZOCioU8lMEPuWdaYlBv8L6oNdIwVjwZpPbKLWwkOjs=.0e8939c8-9cff-4600-a869-9c5f137fd2e5@github.com> References: <3ZOCioU8lMEPuWdaYlBv8L6oNdIwVjwZpPbKLWwkOjs=.0e8939c8-9cff-4600-a869-9c5f137fd2e5@github.com> Message-ID: > Simple spec clarification. A CSR has also been drafted (https://bugs.openjdk.java.net/browse/JDK-8273296). Naoto Sato 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 four additional commits since the last revision: - Merge branch 'master' into JDK-8273259 - Reflecting the CSR review comment - Refined wordings. - 8273259: Character.getName doesn't follow Unicode spec for ideographs ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5354/files - new: https://git.openjdk.java.net/jdk/pull/5354/files/dc36e741..04034295 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5354&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5354&range=01-02 Stats: 12617 lines in 569 files changed: 7866 ins; 2572 del; 2179 mod Patch: https://git.openjdk.java.net/jdk/pull/5354.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5354/head:pull/5354 PR: https://git.openjdk.java.net/jdk/pull/5354 From magnus.ihse.bursie at oracle.com Fri Sep 10 12:25:47 2021 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 10 Sep 2021 14:25:47 +0200 Subject: RFR: 8231640: (prop) Canonical property storage [v7] In-Reply-To: References: Message-ID: <47b7bbcc-af74-9003-9310-3ec25aff2a71@oracle.com> On 2021-09-10 03:57, Jaikiran Pai wrote: > Would this system property have a value that represents what > SOURCE_DATE_EPOCH environment variable would have contained? i.e. it > is the "A UNIX timestamp, defined as the number of seconds, excluding > leap seconds, since 01 Jan 1970 00:00:00 UTC."? So users can > potentially do -Djava.util.Properties.storeDate=${SOURCE_DATE_EPOCH}? > > Or would this system property be just some kind flag, which when > having a value of "true" would expect the java.util.Properties code to > lookup the SOURCE_DATE_EPOCH environment variable and use that value > from the environment variable? > > I'm guessing it's the former where the value is the number of epoch > seconds, but just wanted to be sure before I do this change. Actually, why don't we define it as a free-form string instead? That way the onus is on the user setting the property to get it formatted the way they want. If they want a backwards-compatibly formatted string for SOURCE_DATE_EPOCH, they'd have to call Java with an argument something along the lines of: -Djava.util.Properties.storeDate="$(date --date=@${SOURCE_DATE_EPOCH} +"%a %b %d %H:%M:%S %Z %Y")" which is not much more terrible than -Djava.util.Properties.storeDate=${SOURCE_DATE_EPOCH} given that we in any case won't be reading SOURCE_DATE_EPOCH directly. This also allows for the user to just skip the date completely: -Djava.util.Properties.storeDate="" By changing this property from a epoch based long to a string, all formatting and verification gets removed from your patch, and it is greatly simplified. /Magnus From github.com+44313413+jovanstevanovic at openjdk.java.net Fri Sep 10 12:38:12 2021 From: github.com+44313413+jovanstevanovic at openjdk.java.net (Jovan Stevanovic) Date: Fri, 10 Sep 2021 12:38:12 GMT Subject: RFR: 8273278: Support XSLT on GraalVM Native Image--deterministic bytecode generation in XSLT [v2] In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 12:25:17 GMT, Jovan Stevanovic wrote: >> GraalVM Native Image supports loading classes at runtime if they are known during image build (class predefinition). This is achieved by the JVMTI agent that registers dynamically generated classes in a regular HotSpot run. The Native Image build uses these registered classes to embed them into the produced binary so they can be loaded at runtime. Loading at runtime is achieved by matching the unique hash of generated classes. >> >> If the generated bytecode is unstable across runs, the generated native image can not match the hash of the runtime-generated bytecode to the pre-defined classes. The execution failure happens here: >> https://github.com/oracle/graal/blob/master/substratevm/src/com.oracle.svm.core/src/com/oracle/svm/core/hub/PredefinedClassesSupport.java#L127-L131. >> >> In XSLT the produced bytecode is unstable for the following reasons: >> >> - Methods like ` HashMap#values` and `HashMap#keySet` result in different traversal orders of its elements yielding a different order of methods and fields. >> >> - The default `Object#toString` includes the current memory reference of `com.sun.org.apache.xalan.internal.xsltc.compiler.Number` in the generated class. > > Jovan Stevanovic has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > 8273278: Improving XSLT support for GraalVM's Native Image. `/integrate` ------------- PR: https://git.openjdk.java.net/jdk/pull/5331 From github.com+44313413+jovanstevanovic at openjdk.java.net Fri Sep 10 12:38:10 2021 From: github.com+44313413+jovanstevanovic at openjdk.java.net (Jovan Stevanovic) Date: Fri, 10 Sep 2021 12:38:10 GMT Subject: RFR: 8273278: Support XSLT on GraalVM Native Image--deterministic bytecode generation in XSLT [v2] In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 15:56:04 GMT, Joe Wang wrote: > The headers look good now. Thanks. Great! ------------- PR: https://git.openjdk.java.net/jdk/pull/5331 From sgehwolf at openjdk.java.net Fri Sep 10 12:41:08 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Fri, 10 Sep 2021 12:41:08 GMT Subject: RFR: JDK-8273526: Extend the OSContainer API pids controller with pids.current [v2] In-Reply-To: <3PokFyPHsil0S9A15OWUj97Xls1tFpkeXuqHydXnh4o=.64e6daaa-5dc3-438c-b362-ba61775d1403@github.com> References: <3PokFyPHsil0S9A15OWUj97Xls1tFpkeXuqHydXnh4o=.64e6daaa-5dc3-438c-b362-ba61775d1403@github.com> Message-ID: On Fri, 10 Sep 2021 11:07:52 GMT, Matthias Baesken wrote: >> https://bugs.openjdk.java.net/browse/JDK-8266490 >> extended the OSContainer API in order to also support the pids controller of cgroups. However only pids.max output was added with 8266490. >> There is a second parameter pids.current , see https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#pid >> that would be helpful too and can be added to the OSContainer API . >> pids.current : >> A read-only single value file which exists on all cgroups. >> The number of processes currently in the cgroup and its descendants. >> >> Best regards, Matthias > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Some simplifications and test adjustment suggested by Severin Sorry for not being clear earlier. I meant that we can do those simplifications throughout. src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 255: > 253: } > 254: > 255: char* CgroupV1Subsystem::pids_current_val() { This function can get removed. It's unused now. src/hotspot/os/linux/cgroupV1Subsystem_linux.hpp line 110: > 108: > 109: char * pids_max_val(); > 110: char * pids_current_val(); This is not needed. src/hotspot/os/linux/cgroupV2Subsystem_linux.cpp line 238: > 236: } > 237: > 238: char* CgroupV2Subsystem::pids_current_val() { We don't need that function. src/hotspot/os/linux/cgroupV2Subsystem_linux.cpp line 270: > 268: * OSCONTAINER_ERROR for not supported > 269: */ > 270: jlong CgroupV2Subsystem::pids_current() { This should use something akin to `memory_usage_in_bytes` in this class. `pids_current_val()` isn't needed. src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2Subsystem.java line 317: > 315: public long getPidsCurrent() { > 316: String pidsCurrentStr = CgroupSubsystemController.getStringValue(unified, "pids.current"); > 317: return CgroupSubsystem.limitFromString(pidsCurrentStr); This should use: `return getLongVal("pids.current");` instead. src/java.base/share/classes/sun/launcher/LauncherHelper.java line 415: > 413: ostream.println(formatLimitString(val, INDENT + "Current number of processes: ", > 414: longRetvalNotSupported, false)); > 415: I'm not sure we should add this to `-XshowSettings:system` output at all. What's reported there is enforced limits. Note that current memory usage isn't shown either. test/hotspot/jtreg/containers/docker/TestPids.java line 101: > 99: System.out.println("Found " + lineMarker + " with value: " + ivalue); > 100: try { > 101: int ai = Integer.parseInt(ivalue); Could you move the debug print line to after line 101, please. It could say: `System.out.println("Found " + lineMarker + " with value: " + ai + ". PASS.");` ------------- Changes requested by sgehwolf (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5437 From herrick at openjdk.java.net Fri Sep 10 13:30:35 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Fri, 10 Sep 2021 13:30:35 GMT Subject: [jdk17] RFR: JDK-8273592: Backout JDK-8271868 Message-ID: JDK-8271868 was pushed to JDK17 instead of jdk17u. This change is to back it out ------------- Commit messages: - JDK-8273592: Backout JDK-8271868 Changes: https://git.openjdk.java.net/jdk17/pull/307/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=307&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273592 Stats: 65 lines in 9 files changed: 11 ins; 46 del; 8 mod Patch: https://git.openjdk.java.net/jdk17/pull/307.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/307/head:pull/307 PR: https://git.openjdk.java.net/jdk17/pull/307 From iris at openjdk.java.net Fri Sep 10 13:59:41 2021 From: iris at openjdk.java.net (Iris Clark) Date: Fri, 10 Sep 2021 13:59:41 GMT Subject: RFR: 8273259: Character.getName doesn't follow Unicode spec for ideographs [v3] In-Reply-To: References: <3ZOCioU8lMEPuWdaYlBv8L6oNdIwVjwZpPbKLWwkOjs=.0e8939c8-9cff-4600-a869-9c5f137fd2e5@github.com> Message-ID: On Fri, 10 Sep 2021 12:21:41 GMT, Naoto Sato wrote: >> Simple spec clarification. A CSR has also been drafted (https://bugs.openjdk.java.net/browse/JDK-8273296). > > Naoto Sato 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 four additional commits since the last revision: > > - Merge branch 'master' into JDK-8273259 > - Reflecting the CSR review comment > - Refined wordings. > - 8273259: Character.getName doesn't follow Unicode spec for ideographs Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5354 From kcr at openjdk.java.net Fri Sep 10 14:08:27 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 10 Sep 2021 14:08:27 GMT Subject: [jdk17] RFR: JDK-8273592: Backout JDK-8271868 In-Reply-To: References: Message-ID: On Fri, 10 Sep 2021 13:18:49 GMT, Andy Herrick wrote: > JDK-8271868 was pushed to JDK17 instead of jdk17u. > This change is to back it out I fetched the PR commit and confirmed that it is a correct backout (revert) of JDK-8271868. ------------- Marked as reviewed by kcr (Author). PR: https://git.openjdk.java.net/jdk17/pull/307 From redestad at openjdk.java.net Fri Sep 10 14:10:56 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 10 Sep 2021 14:10:56 GMT Subject: RFR: 8273541: Cleaner Thread creates with normal priority instead of MAX_PRIORITY - 2 In-Reply-To: References: <1NRlROh9TTsjWpOfyZNQohDUcdkn__KnwD90pu6t6X4=.1b9d7bb8-3bc9-403c-8006-4cdde210dd5d@github.com> Message-ID: On Thu, 9 Sep 2021 13:37:45 GMT, Aleksey Shipilev wrote: > This looks good. @cl4es might want to confirm that change was not intentional. Completely unintentional, and perplexing since it's not a simple copy-paste error.. ------------- PR: https://git.openjdk.java.net/jdk/pull/5439 From github.com+332398+kabutz at openjdk.java.net Fri Sep 10 14:16:50 2021 From: github.com+332398+kabutz at openjdk.java.net (kabutz) Date: Fri, 10 Sep 2021 14:16:50 GMT Subject: Integrated: 8273541: Cleaner Thread creates with normal priority instead of MAX_PRIORITY - 2 In-Reply-To: <1NRlROh9TTsjWpOfyZNQohDUcdkn__KnwD90pu6t6X4=.1b9d7bb8-3bc9-403c-8006-4cdde210dd5d@github.com> References: <1NRlROh9TTsjWpOfyZNQohDUcdkn__KnwD90pu6t6X4=.1b9d7bb8-3bc9-403c-8006-4cdde210dd5d@github.com> Message-ID: On Thu, 9 Sep 2021 10:14:48 GMT, kabutz wrote: > ?of MAX_PRIORITY-2 during refactoring > > Appears in Java 17 for the first time. > > During refactoring, the priority was changed from Thread.MAX_PRIORITY - 2 to instead state Thread.MIN_PRIORITY - 2, which results in a negative priority, and is thus set to Thread.NORM_PRIORITY. Thus the Cleaner by default now has threads with priority 5, instead of 8. > > The change was done in git revision # 992b50087d2ec8878dfcbbd1820a00b6b6bdf644 and label 8261036 by Claes Redestad This pull request has now been integrated. Changeset: 4e6de5f9 Author: kabutz Committer: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/4e6de5f9defc031158e027bcbbaf6232b8c03d60 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8273541: Cleaner Thread creates with normal priority instead of MAX_PRIORITY - 2 Reviewed-by: shade, alanb, lancea ------------- PR: https://git.openjdk.java.net/jdk/pull/5439 From asemenyuk at openjdk.java.net Fri Sep 10 14:17:05 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Fri, 10 Sep 2021 14:17:05 GMT Subject: [jdk17] RFR: JDK-8273592: Backout JDK-8271868 In-Reply-To: References: Message-ID: On Fri, 10 Sep 2021 13:18:49 GMT, Andy Herrick wrote: > JDK-8271868 was pushed to JDK17 instead of jdk17u. > This change is to back it out Marked as reviewed by asemenyuk (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk17/pull/307 From aefimov at openjdk.java.net Fri Sep 10 14:18:53 2021 From: aefimov at openjdk.java.net (Aleksei Efimov) Date: Fri, 10 Sep 2021 14:18:53 GMT Subject: Integrated: 8273402: Use derived NamingExceptions in com.sun.jndi.ldap.Connection#readReply In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 22:02:55 GMT, Aleksei Efimov wrote: > Hi, > The following fix changes type of exception thrown when an LDAP operation fails for reasons like read timeout or connection closure/cancellation: instead of throwing a general `NamingException`, the internal LDAP connection class will throw a [`CommunicationException`](https://github.com/openjdk/jdk/blob/master/src/java.naming/share/classes/javax/naming/CommunicationException.java#L29) that better matches the reasons described. > > Testing shows no problem with the proposed fix. This pull request has now been integrated. Changeset: c464f090 Author: Aleksei Efimov URL: https://git.openjdk.java.net/jdk/commit/c464f09056c239f701b400a5c59c54646f840391 Stats: 41 lines in 3 files changed: 13 ins; 3 del; 25 mod 8273402: Use derived NamingExceptions in com.sun.jndi.ldap.Connection#readReply Reviewed-by: dfuchs ------------- PR: https://git.openjdk.java.net/jdk/pull/5456 From asemenyuk at openjdk.java.net Fri Sep 10 14:19:56 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Fri, 10 Sep 2021 14:19:56 GMT Subject: RFR: 8273595: tools/jpackage tests do not work on apt-based Linux distros like Debian In-Reply-To: References: Message-ID: On Fri, 10 Sep 2021 12:03:48 GMT, Ao Qi wrote: > A similar issue on Ubuntu has been fixed by [JDK-8238953](https://bugs.openjdk.java.net/browse/JDK-8238953). However, tools/jpackage tests do not work on Debian Linux or other apt-based Linux, when rpm package is installed. This issue proposes a general fix for apt-based Linux. Marked as reviewed by asemenyuk (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5462 From herrick at openjdk.java.net Fri Sep 10 14:21:18 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Fri, 10 Sep 2021 14:21:18 GMT Subject: [jdk17] Integrated: JDK-8273592: Backout JDK-8271868 In-Reply-To: References: Message-ID: <6bsiL-L_V-fuFIvFV7scXxnU7UijndL3uxgFH4T7Su8=.10deb8e8-ce8f-4cf7-b83d-1726db792863@github.com> On Fri, 10 Sep 2021 13:18:49 GMT, Andy Herrick wrote: > JDK-8271868 was pushed to JDK17 instead of jdk17u. > This change is to back it out This pull request has now been integrated. Changeset: 4afbcaf5 Author: Andy Herrick URL: https://git.openjdk.java.net/jdk17/commit/4afbcaf55383ec2f5da53282a1547bac3d099e9d Stats: 65 lines in 9 files changed: 11 ins; 46 del; 8 mod 8273592: Backout JDK-8271868 Reviewed-by: kcr, asemenyuk ------------- PR: https://git.openjdk.java.net/jdk17/pull/307 From rriggs at openjdk.java.net Fri Sep 10 14:29:55 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 10 Sep 2021 14:29:55 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v9] In-Reply-To: References: Message-ID: On Fri, 10 Sep 2021 10:15:45 GMT, Jaikiran Pai wrote: >> The commit in this PR implements the proposal for enhancement that was discussed in the core-libs-dev mailing list recently[1], for https://bugs.openjdk.java.net/browse/JDK-8231640 >> >> At a high level - the `store()` APIs in `Properties` have been modified to now look for the `SOURCE_DATE_EPOCH` environment variable[2]. If that env variable is set, then instead of writing out the current date time as a date comment, the `store()` APIs instead will use the value set for this env variable to parse it to a `Date` and write out the string form of such a date. The implementation here uses the `d MMM yyyy HH:mm:ss 'GMT'` date format and `Locale.ROOT` to format and write out such a date. This should provide reproducibility whenever the `SOURCE_DATE_EPOCH` is set. Furthermore, intentionally, no changes in the date format of the "current date" have been done. >> >> These modified `store()` APIs work in the presence of the `SecurityManager` too. The caller is expected to have a read permission on the `SOURCE_DATE_EPOCH` environment variable. If the caller doesn't have that permission, then the implementation of these `store()` APIs will write out the "current date" and will ignore any value that has been set for the `SOURCE_DATE_EPOCH` env variable. This should allow for backward compatibility of existing applications, where, when they run under a `SecurityManager` and perhaps with an existing restrictive policy file, the presence of `SOURCE_DATE_EPOCH` shouldn't impact their calls to the `store()` APIs. >> >> The modified `store()` APIs will also ignore any value for `SOURCE_DATE_EPOCH` that cannot be parsed to an `long` value. In such cases, the `store()` APIs will write out the "current date" and ignore the value set for this environment variable. No exceptions will be thrown for such invalid values. This is an additional backward compatibility precaution to prevent any rogue value for `SOURCE_DATE_EPOCH` from breaking applications. >> >> An additional change in the implementation of these `store()` APIs and unrelated to the date comment, is that these APIs will now write out the property keys in a deterministic order. The keys will be written out in the natural ordering as specified by `java.lang.String#compareTo()` API. >> >> The combination of the ordering of the property keys when written out and the usage of `SOURCE_DATE_EPOCH` environment value to determine the date comment should together allow for reproducibility of the output generated by these `store()` APIs. >> >> New jtreg test classes have been introduced to verify these changes. The primary focus of `PropertiesStoreTest` is the ordering aspects of the property keys that are written out. On the other hand `StoreReproducibilityTest` focuses on the reproducibility of the output generated by these APIs. The `StoreReproducibilityTest` runs these tests both in the presence and absence of `SecurityManager`. Plus, in the presence of SecurityManager, it tests both the scenarios where the caller is granted the requisite permission and in other case not granted that permission. >> >> These new tests and existing tests under `test/jdk/java/util/Properties/` pass with these changes. >> >> [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-August/080758.html >> [2] https://reproducible-builds.org/specs/source-date-epoch/ > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > jcheck fix - trailing whitespace in test I'm inclined to agree with Magnus, supplying the property as a string, avoids hardcoding details that are not really in the domain of Properties. It opens up the option to omit the date and simplifies the code and spec. Since the tools exist at build time or in the setting of the property to format it as needed, Properties does not need to. If non-null and non-empty it would be inserted as a comment. The string would not contain the "# " prefix. ------------- PR: https://git.openjdk.java.net/jdk/pull/5372 From jai.forums2013 at gmail.com Fri Sep 10 14:40:43 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Fri, 10 Sep 2021 20:10:43 +0530 Subject: RFR: 8231640: (prop) Canonical property storage [v9] In-Reply-To: References: Message-ID: On 10/09/21 7:59 pm, Roger Riggs wrote: > On Fri, 10 Sep 2021 10:15:45 GMT, Jaikiran Pai wrote: > >>> The commit in this PR implements the proposal for enhancement that was discussed in the core-libs-dev mailing list recently[1], for https://bugs.openjdk.java.net/browse/JDK-8231640 >>> >>> At a high level - the `store()` APIs in `Properties` have been modified to now look for the `SOURCE_DATE_EPOCH` environment variable[2]. If that env variable is set, then instead of writing out the current date time as a date comment, the `store()` APIs instead will use the value set for this env variable to parse it to a `Date` and write out the string form of such a date. The implementation here uses the `d MMM yyyy HH:mm:ss 'GMT'` date format and `Locale.ROOT` to format and write out such a date. This should provide reproducibility whenever the `SOURCE_DATE_EPOCH` is set. Furthermore, intentionally, no changes in the date format of the "current date" have been done. >>> >>> These modified `store()` APIs work in the presence of the `SecurityManager` too. The caller is expected to have a read permission on the `SOURCE_DATE_EPOCH` environment variable. If the caller doesn't have that permission, then the implementation of these `store()` APIs will write out the "current date" and will ignore any value that has been set for the `SOURCE_DATE_EPOCH` env variable. This should allow for backward compatibility of existing applications, where, when they run under a `SecurityManager` and perhaps with an existing restrictive policy file, the presence of `SOURCE_DATE_EPOCH` shouldn't impact their calls to the `store()` APIs. >>> >>> The modified `store()` APIs will also ignore any value for `SOURCE_DATE_EPOCH` that cannot be parsed to an `long` value. In such cases, the `store()` APIs will write out the "current date" and ignore the value set for this environment variable. No exceptions will be thrown for such invalid values. This is an additional backward compatibility precaution to prevent any rogue value for `SOURCE_DATE_EPOCH` from breaking applications. >>> >>> An additional change in the implementation of these `store()` APIs and unrelated to the date comment, is that these APIs will now write out the property keys in a deterministic order. The keys will be written out in the natural ordering as specified by `java.lang.String#compareTo()` API. >>> >>> The combination of the ordering of the property keys when written out and the usage of `SOURCE_DATE_EPOCH` environment value to determine the date comment should together allow for reproducibility of the output generated by these `store()` APIs. >>> >>> New jtreg test classes have been introduced to verify these changes. The primary focus of `PropertiesStoreTest` is the ordering aspects of the property keys that are written out. On the other hand `StoreReproducibilityTest` focuses on the reproducibility of the output generated by these APIs. The `StoreReproducibilityTest` runs these tests both in the presence and absence of `SecurityManager`. Plus, in the presence of SecurityManager, it tests both the scenarios where the caller is granted the requisite permission and in other case not granted that permission. >>> >>> These new tests and existing tests under `test/jdk/java/util/Properties/` pass with these changes. >>> >>> [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-August/080758.html >>> [2] https://reproducible-builds.org/specs/source-date-epoch/ >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> jcheck fix - trailing whitespace in test > I'm inclined to agree with Magnus, supplying the property as a string, avoids hardcoding details that are not really in the domain of Properties. It opens up the option to omit the date and simplifies the code and spec. > Since the tools exist at build time or in the setting of the property to format it as needed, Properties does not need to. > > If non-null and non-empty it would be inserted as a comment. The string would not contain the "# " prefix. However, that goes against one of the goals this PR is trying to achieve of backward compatibility of these existing store() APIs. Allowing a free form text will mean that someone can feed a "foo bar" and we will end up writing that as a comment, which essentially means that the stored properties file no longer has any date comment. Another example is, someone feeds a valid formatted text date to this system property but that format doesn't match the format that is advertized till date (the one which Date.toString() uses). Are we willing to allow that? -Jaikiran From rriggs at openjdk.java.net Fri Sep 10 14:47:51 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 10 Sep 2021 14:47:51 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v9] In-Reply-To: References: Message-ID: On Fri, 10 Sep 2021 10:15:45 GMT, Jaikiran Pai wrote: >> The commit in this PR implements the proposal for enhancement that was discussed in the core-libs-dev mailing list recently[1], for https://bugs.openjdk.java.net/browse/JDK-8231640 >> >> At a high level - the `store()` APIs in `Properties` have been modified to now look for the `SOURCE_DATE_EPOCH` environment variable[2]. If that env variable is set, then instead of writing out the current date time as a date comment, the `store()` APIs instead will use the value set for this env variable to parse it to a `Date` and write out the string form of such a date. The implementation here uses the `d MMM yyyy HH:mm:ss 'GMT'` date format and `Locale.ROOT` to format and write out such a date. This should provide reproducibility whenever the `SOURCE_DATE_EPOCH` is set. Furthermore, intentionally, no changes in the date format of the "current date" have been done. >> >> These modified `store()` APIs work in the presence of the `SecurityManager` too. The caller is expected to have a read permission on the `SOURCE_DATE_EPOCH` environment variable. If the caller doesn't have that permission, then the implementation of these `store()` APIs will write out the "current date" and will ignore any value that has been set for the `SOURCE_DATE_EPOCH` env variable. This should allow for backward compatibility of existing applications, where, when they run under a `SecurityManager` and perhaps with an existing restrictive policy file, the presence of `SOURCE_DATE_EPOCH` shouldn't impact their calls to the `store()` APIs. >> >> The modified `store()` APIs will also ignore any value for `SOURCE_DATE_EPOCH` that cannot be parsed to an `long` value. In such cases, the `store()` APIs will write out the "current date" and ignore the value set for this environment variable. No exceptions will be thrown for such invalid values. This is an additional backward compatibility precaution to prevent any rogue value for `SOURCE_DATE_EPOCH` from breaking applications. >> >> An additional change in the implementation of these `store()` APIs and unrelated to the date comment, is that these APIs will now write out the property keys in a deterministic order. The keys will be written out in the natural ordering as specified by `java.lang.String#compareTo()` API. >> >> The combination of the ordering of the property keys when written out and the usage of `SOURCE_DATE_EPOCH` environment value to determine the date comment should together allow for reproducibility of the output generated by these `store()` APIs. >> >> New jtreg test classes have been introduced to verify these changes. The primary focus of `PropertiesStoreTest` is the ordering aspects of the property keys that are written out. On the other hand `StoreReproducibilityTest` focuses on the reproducibility of the output generated by these APIs. The `StoreReproducibilityTest` runs these tests both in the presence and absence of `SecurityManager`. Plus, in the presence of SecurityManager, it tests both the scenarios where the caller is granted the requisite permission and in other case not granted that permission. >> >> These new tests and existing tests under `test/jdk/java/util/Properties/` pass with these changes. >> >> [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-August/080758.html >> [2] https://reproducible-builds.org/specs/source-date-epoch/ > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > jcheck fix - trailing whitespace in test Hi Jaikiran, On 9/9/21 9:59 PM, mlbridge[bot] wrote: > > /Mailing list message from Jaikiran Pai > ***@***.***> on core-libs-dev > ***@***.***>:/ > > Hello Roger, > > On 10/09/21 12:32 am, Roger Riggs wrote: > > src/java.base/share/classes/java/util/Properties.java line 187: > > 185: ? System.getenv("SOURCE_DATE_EPOCH") > 186: : AccessController.doPrivileged((PrivilegedAction) > 187: () -> System.getenv("SOURCE_DATE_EPOCH")); > The format of SOURCE_DATE_EPOCH is fine, but referring to an > external document as part of the OpenJDK spec is undesirable > in the long run. Previous comments gave support to using the > environment variable directly but > it very unlike similar cases that use system properties when > the behavior of an API needs to be overridden or modified. > > As a system property, specified on the command line, it would be > visible when the program is invoked, > explicitly intended to change behavior and not having a context > sensitive effect. Named perhaps, java.util.Properties.storeDate. > > Would this system property have a value that represents what > SOURCE_DATE_EPOCH environment variable would have contained? i.e. it is > the "A UNIX timestamp, defined as the number of seconds, excluding leap > seconds, since 01 Jan 1970 00:00:00 UTC."? So users can potentially do > -Djava.util.Properties.storeDate=${SOURCE_DATE_EPOCH}? > > Or would this system property be just some kind flag, which when having > a value of "true" would expect the java.util.Properties code to lookup > the SOURCE_DATE_EPOCH environment variable and use that value from the > environment variable? > > I'm guessing it's the former where the value is the number of epoch > seconds, but just wanted to be sure before I do this change. > I agree with Magnus' suggestion to make it just a comment string to be included if it is non-null and non-empty. > > (BTW, there is no need to special case doPriv calls, they are > pretty well optimized when the security manager is not set and it > keeps the code simpler.) > > From what I see in the implementation of > AccessController.doPriveleged(), I see that it does a bunch of > uncoditional work (like Reflection.getCallerClass() and then > Reference.reachabilityFence() calls). Do you mean that additional work > is neglible in the absence of a security manager, that this special > casing of the doPriv call can be removed? > (The code is gone now) I meant that the testing for SM == null to avoid the doPriv won't improve performance much and performance isn't critical here. The context will be null, getCallerClass is optimized(an Intrinsic), and the reachabilityFence() is effectively a no-op, to keep gc from reclaiming objects too soon. So all those a lightweight or optimized away. > Given the low frequency of calls to store(), even caching the > parsed date doesn't save much. > And the cost is the cost of the size and loading an extra class. > > Sounds fine. I'll remove the caching part in my subsequent update. > Thanks, Roger > -Jaikiran > > ? > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > , > or unsubscribe > . > Triage notifications on the go with GitHub Mobile for iOS > > or Android > . > > ------------- PR: https://git.openjdk.java.net/jdk/pull/5372 From roger.riggs at oracle.com Fri Sep 10 15:00:06 2021 From: roger.riggs at oracle.com (Roger Riggs) Date: Fri, 10 Sep 2021 11:00:06 -0400 Subject: RFR: 8231640: (prop) Canonical property storage [v9] In-Reply-To: References: Message-ID: Hi, It does move the responsibility for that specific compatibility to the person defining the system property. I would document it as conventionally having the date in the format expected. In the context of a reproducible build, where the property is expected to be used, the builder would be able to track down tools that were expecting a specific format and correct the input/property setting. I think the incorrectly formatted string would be more use for tracking down a problem than having the date be in the correct format but quietly different from what was expected. (As is, an unparseable property value is replaced by the current date). Roger On 9/10/21 10:40 AM, Jaikiran Pai wrote: > > On 10/09/21 7:59 pm, Roger Riggs wrote: >> On Fri, 10 Sep 2021 10:15:45 GMT, Jaikiran Pai wrote: >> I'm inclined to agree with Magnus, supplying the property as a >> string, avoids hardcoding details that are not really in the domain >> of Properties.? It opens up the option to omit the date and >> simplifies the code and spec. >> Since the tools exist at build time or in the setting of the property >> to format it as needed, Properties does not need to. >> >> If non-null and non-empty it would be inserted as a comment. The >> string would not contain the "# " prefix. > > However, that goes against one of the goals this PR is trying to > achieve of backward compatibility of these existing store() APIs. > Allowing a free form text will mean that someone can feed a "foo bar" > and we will end up writing that as a comment, which essentially means > that the stored properties file no longer has any date comment. > Another example is, someone feeds a valid formatted text date to this > system property but that format doesn't match the format that is > advertized till date (the one which Date.toString() uses). > > Are we willing to allow that? > > -Jaikiran > > From jai.forums2013 at gmail.com Fri Sep 10 15:52:28 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Fri, 10 Sep 2021 21:22:28 +0530 Subject: RFR: 8231640: (prop) Canonical property storage [v9] In-Reply-To: References: Message-ID: Based on these inputs, I have now updated the PR to use the value of this new system property verbatim while writing out the comment. I realize you mentioned that we should use this value if it is non-null and non-empty. In my updated PR, I instead use this value only if it is non-null and non-blank. I based it on my opinion that whitespace-only comment through this system property, shouldn't be allowed. If however you and others think that using non-empty check instead of non-blank check is more appropriate, feel free to let me know and I'll update the PR accordingly. The new tests have been updated accordingly and they continue to pass along with the existing ones in test/jdk/java/util/Properties/. -Jaikiran On 10/09/21 8:30 pm, Roger Riggs wrote: > Hi, > > It does move the responsibility for that specific compatibility to the > person defining the system property. > I would document it as conventionally having the date in the format > expected. > > In the context of a reproducible build, where the property is expected > to be used, the builder would be > able to track down tools that were expecting a specific format and > correct the input/property setting. > > I think the incorrectly formatted string would be more use for > tracking down a problem > than having the date be in the correct format but quietly different > from what was expected. > (As is, an unparseable property value is replaced by the current date). > > Roger > > > On 9/10/21 10:40 AM, Jaikiran Pai wrote: >> >> On 10/09/21 7:59 pm, Roger Riggs wrote: >>> On Fri, 10 Sep 2021 10:15:45 GMT, Jaikiran Pai >>> wrote: >>> I'm inclined to agree with Magnus, supplying the property as a >>> string, avoids hardcoding details that are not really in the domain >>> of Properties.? It opens up the option to omit the date and >>> simplifies the code and spec. >>> Since the tools exist at build time or in the setting of the >>> property to format it as needed, Properties does not need to. >>> >>> If non-null and non-empty it would be inserted as a comment. The >>> string would not contain the "# " prefix. >> >> However, that goes against one of the goals this PR is trying to >> achieve of backward compatibility of these existing store() APIs. >> Allowing a free form text will mean that someone can feed a "foo bar" >> and we will end up writing that as a comment, which essentially means >> that the stored properties file no longer has any date comment. >> Another example is, someone feeds a valid formatted text date to this >> system property but that format doesn't match the format that is >> advertized till date (the one which Date.toString() uses). >> >> Are we willing to allow that? >> >> -Jaikiran >> >> > From jpai at openjdk.java.net Fri Sep 10 15:51:30 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Fri, 10 Sep 2021 15:51:30 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v10] In-Reply-To: References: Message-ID: > The commit in this PR implements the proposal for enhancement that was discussed in the core-libs-dev mailing list recently[1], for https://bugs.openjdk.java.net/browse/JDK-8231640 > > At a high level - the `store()` APIs in `Properties` have been modified to now look for the `SOURCE_DATE_EPOCH` environment variable[2]. If that env variable is set, then instead of writing out the current date time as a date comment, the `store()` APIs instead will use the value set for this env variable to parse it to a `Date` and write out the string form of such a date. The implementation here uses the `d MMM yyyy HH:mm:ss 'GMT'` date format and `Locale.ROOT` to format and write out such a date. This should provide reproducibility whenever the `SOURCE_DATE_EPOCH` is set. Furthermore, intentionally, no changes in the date format of the "current date" have been done. > > These modified `store()` APIs work in the presence of the `SecurityManager` too. The caller is expected to have a read permission on the `SOURCE_DATE_EPOCH` environment variable. If the caller doesn't have that permission, then the implementation of these `store()` APIs will write out the "current date" and will ignore any value that has been set for the `SOURCE_DATE_EPOCH` env variable. This should allow for backward compatibility of existing applications, where, when they run under a `SecurityManager` and perhaps with an existing restrictive policy file, the presence of `SOURCE_DATE_EPOCH` shouldn't impact their calls to the `store()` APIs. > > The modified `store()` APIs will also ignore any value for `SOURCE_DATE_EPOCH` that cannot be parsed to an `long` value. In such cases, the `store()` APIs will write out the "current date" and ignore the value set for this environment variable. No exceptions will be thrown for such invalid values. This is an additional backward compatibility precaution to prevent any rogue value for `SOURCE_DATE_EPOCH` from breaking applications. > > An additional change in the implementation of these `store()` APIs and unrelated to the date comment, is that these APIs will now write out the property keys in a deterministic order. The keys will be written out in the natural ordering as specified by `java.lang.String#compareTo()` API. > > The combination of the ordering of the property keys when written out and the usage of `SOURCE_DATE_EPOCH` environment value to determine the date comment should together allow for reproducibility of the output generated by these `store()` APIs. > > New jtreg test classes have been introduced to verify these changes. The primary focus of `PropertiesStoreTest` is the ordering aspects of the property keys that are written out. On the other hand `StoreReproducibilityTest` focuses on the reproducibility of the output generated by these APIs. The `StoreReproducibilityTest` runs these tests both in the presence and absence of `SecurityManager`. Plus, in the presence of SecurityManager, it tests both the scenarios where the caller is granted the requisite permission and in other case not granted that permission. > > These new tests and existing tests under `test/jdk/java/util/Properties/` pass with these changes. > > [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-August/080758.html > [2] https://reproducible-builds.org/specs/source-date-epoch/ Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: allow free-form text for java.util.Properties.storeDate system property ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5372/files - new: https://git.openjdk.java.net/jdk/pull/5372/files/06ff3bdb..1d24a3a8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5372&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5372&range=08-09 Stats: 94 lines in 2 files changed: 32 ins; 36 del; 26 mod Patch: https://git.openjdk.java.net/jdk/pull/5372.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5372/head:pull/5372 PR: https://git.openjdk.java.net/jdk/pull/5372 From andrew at openjdk.java.net Fri Sep 10 15:51:49 2021 From: andrew at openjdk.java.net (Andrew John Hughes) Date: Fri, 10 Sep 2021 15:51:49 GMT Subject: RFR: 8273494: Zero: Put libjvm.so into "zero" folder, not "server" In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 14:31:19 GMT, Magnus Ihse Bursie wrote: >> Currently, the build system defaults the libjvm.so location to "server". This makes looking for `libjvm.so` awkward, see JDK-8273487 for example. We need to see if moving the libjvm.so to a proper location breaks anything. >> >> Additional testing: >> - [x] Linux x86_64 Zero build >> - [x] Linux x86_64 Zero bootcycle-images >> - [ ] Linux x86_64 Zero `tier1` > > And as for @dholmes-ora comment: I'm not sure who "own" zero at this point in time. Aleksey has made a lot of the zero patches lately; does that not count? Are you thinking about any specific person that needs to weight in on this? > > @magicus every "port" in OpenJDK is supposed to have a clear owner and support system. Zero has been somewhat lacking in that area but there were enough people to keep it surviving. Now I'm not so sure. Does Zero have an active user community? Developer community? If so they are the ones who need to assess this change. > > FWIW, Zero had fallen into Red Hat hands for support. The official lead (if you look at Census) is Gary Benson, who is not active in this project anymore. Since then, it was mostly supported by RH folks (like me) with contributions from Debian, Tencent, Huawei, Alibaba -- mostly because all of us have arch ports that do not have full-blown Server VMs yet. For clarity, Gary was a part of the Red Hat Java team at the time, so it has always been a Red Hat project. At the time, the only JIT ports in OpenJDK were x86, x86-64 and SPARC, so the other architectures Red Hat supported (ppc, ppc64, s390, s390x) needed some way to at least build and run to allow OpenJDK packages to be shipped, even if end users desiring greater performance used some other JDK. As OpenJDK has gained further JIT ports, the use of Zero has declined in response. For example, we can build OpenJDK 17 on every architecture we need without using Zero, so it's not going to receive that kind of "you broke our build" testing any more. It is still used for 8u & 11u, and is definitely worth keeping alive to help bootstrap any new ports. So, in short, the owner has always been and remains Red Hat, even if the individual personnel have changed. The formal project represents a time when it was maintained outside the mainline OpenJDK, so there has been no need to update that for a long time, as any JDK project committer can make changes to the code in the main JDK project. > > I have put things in motion to claim the leadership more formally. I do have to note, though, that over the last few years of me whipping Zero into shape, this is the first time anyone asked the formal governance question, which must tell us something about how much we care about ownership formalities here ;) Most of the OpenJDK committers at Red Hat have pushed Zero fixes at some time, myself included, as need has arisen. This has the first time this has been raised to my knowledge. Regarding this change itself, I think it's fine for trunk, where there's time to shake out any issues for OpenJDK 18, but I wouldn't want to backport it. These kind of changes tend to throw up things only when someone's application breaks, and, at least if that's a new JDK version, that's somewhat expected. ------------- PR: https://git.openjdk.java.net/jdk/pull/5440 From naoto at openjdk.java.net Fri Sep 10 16:40:49 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 10 Sep 2021 16:40:49 GMT Subject: Integrated: 8273369: Computing micros between two instants unexpectedly overflows for some cases In-Reply-To: References: Message-ID: On Tue, 7 Sep 2021 18:18:49 GMT, Naoto Sato wrote: > Please review the fix to the issue. Avoiding overflow by not calling nanosUntil() directly, which will overflow beyond Long.MAX_VALUE difference in nano unit. This pull request has now been integrated. Changeset: 81d2acee Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/81d2acee57188a4507c798b46b0bd129dc302fec Stats: 52 lines in 3 files changed: 46 ins; 0 del; 6 mod 8273369: Computing micros between two instants unexpectedly overflows for some cases Reviewed-by: lancea, rriggs, joehw ------------- PR: https://git.openjdk.java.net/jdk/pull/5396 From asemenyuk at openjdk.java.net Fri Sep 10 16:50:48 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Fri, 10 Sep 2021 16:50:48 GMT Subject: RFR: 8273595: tools/jpackage tests do not work on apt-based Linux distros like Debian In-Reply-To: References: Message-ID: On Fri, 10 Sep 2021 12:03:48 GMT, Ao Qi wrote: > A similar issue on Ubuntu has been fixed by [JDK-8238953](https://bugs.openjdk.java.net/browse/JDK-8238953). However, tools/jpackage tests do not work on Debian Linux or other apt-based Linux, when rpm package is installed. This issue proposes a general fix for apt-based Linux. Sorry, I issued the "integrate" command as I got confused with the "contributor" comment. ------------- PR: https://git.openjdk.java.net/jdk/pull/5462 From aoqi at openjdk.java.net Fri Sep 10 16:54:48 2021 From: aoqi at openjdk.java.net (Ao Qi) Date: Fri, 10 Sep 2021 16:54:48 GMT Subject: RFR: 8273595: tools/jpackage tests do not work on apt-based Linux distros like Debian In-Reply-To: References: Message-ID: <6vp-bDyqGgzfw841gNyeY_CxLrgJHZcMZgPjbWjkyr0=.ae61b3ba-e1d1-4649-b4d1-4d8d346fd42f@github.com> On Fri, 10 Sep 2021 16:48:15 GMT, Alexey Semenyuk wrote: >> A similar issue on Ubuntu has been fixed by [JDK-8238953](https://bugs.openjdk.java.net/browse/JDK-8238953). However, tools/jpackage tests do not work on Debian Linux or other apt-based Linux, when rpm package is installed. This issue proposes a general fix for apt-based Linux. > > Sorry, I issued the "integrate" command as I got confused with the "contributor" comment. Thanks for your review, @alexeysemenyukoracle ! I have typed "/integrate", but I am not sure if this needs a second reviewer or should wait for a longer time. ------------- PR: https://git.openjdk.java.net/jdk/pull/5462 From github.com+573017+michael-o at openjdk.java.net Fri Sep 10 17:07:52 2021 From: github.com+573017+michael-o at openjdk.java.net (Michael Osipov) Date: Fri, 10 Sep 2021 17:07:52 GMT Subject: RFR: 8273402: Use derived NamingExceptions in com.sun.jndi.ldap.Connection#readReply In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 22:02:55 GMT, Aleksei Efimov wrote: > Hi, > The following fix changes type of exception thrown when an LDAP operation fails for reasons like read timeout or connection closure/cancellation: instead of throwing a general `NamingException`, the internal LDAP connection class will throw a [`CommunicationException`](https://github.com/openjdk/jdk/blob/master/src/java.naming/share/classes/javax/naming/CommunicationException.java#L29) that better matches the reasons described. > > Testing shows no problem with the proposed fix. @AlekseiEfimov Thanks for making this happen so fast. Do you see any chance to have this backported to LTS releases where this is required? I have reported the issue initially and like to make this available in Tomcat 8.5+. ------------- PR: https://git.openjdk.java.net/jdk/pull/5456 From smarks at openjdk.java.net Fri Sep 10 17:19:48 2021 From: smarks at openjdk.java.net (Stuart Marks) Date: Fri, 10 Sep 2021 17:19:48 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v6] In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 08:31:30 GMT, Jaikiran Pai wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> update javadoc to match latest changes > > Hello Magnus, > >> Am I the only one thinking there should also be a way for developers to explicitly disable timestamps from the API? >> >> I think the current iteration looks okay (but the core-libs guys of course has the say in this), but I still think we need a new method (or overload) to allow for a timestamp-free to be generated, always, independent of environment variables. > > I decided to take this comment to the mailing list[1] where the proposal for this change was discussed, since it's likely more people will be watching that thread than this RFR thread. > > [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-September/081305.html @jaikiran Thanks for following this through all the twists and turns. The review thread here is pretty long, but I think we've made a lot of progress and are close to converging. In addition, the code keeps getting simpler, so that's a good thing. ------------- PR: https://git.openjdk.java.net/jdk/pull/5372 From mchung at openjdk.java.net Fri Sep 10 17:20:55 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 10 Sep 2021 17:20:55 GMT Subject: Integrated: JDK-8273194: Document the two possible cases when Lookup::ensureInitialized returns In-Reply-To: References: Message-ID: On Wed, 1 Sep 2021 20:56:59 GMT, Mandy Chung wrote: > Improve the specification to document the cases when `Lookup::ensureInitialized` returns as specified JVMS 5.5 and matches the implementation. > > Please also review CSR: https://bugs.openjdk.java.net/browse/JDK-8273253 This pull request has now been integrated. Changeset: ec9d1beb Author: Mandy Chung URL: https://git.openjdk.java.net/jdk/commit/ec9d1bebd772b3ca4ad3e0654cb4833c72ee238a Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod 8273194: Document the two possible cases when Lookup::ensureInitialized returns Reviewed-by: alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/5343 From herrick at openjdk.java.net Fri Sep 10 17:34:48 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Fri, 10 Sep 2021 17:34:48 GMT Subject: RFR: 8273595: tools/jpackage tests do not work on apt-based Linux distros like Debian In-Reply-To: References: Message-ID: On Fri, 10 Sep 2021 12:03:48 GMT, Ao Qi wrote: > A similar issue on Ubuntu has been fixed by [JDK-8238953](https://bugs.openjdk.java.net/browse/JDK-8238953). However, tools/jpackage tests do not work on Debian Linux or other apt-based Linux, when rpm package is installed. This issue proposes a general fix for apt-based Linux. Marked as reviewed by herrick (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5462 From smarks at openjdk.java.net Fri Sep 10 17:42:51 2021 From: smarks at openjdk.java.net (Stuart Marks) Date: Fri, 10 Sep 2021 17:42:51 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v10] In-Reply-To: References: Message-ID: On Fri, 10 Sep 2021 15:51:30 GMT, Jaikiran Pai wrote: >> The commit in this PR implements the proposal for enhancement that was discussed in the core-libs-dev mailing list recently[1], for https://bugs.openjdk.java.net/browse/JDK-8231640 >> >> At a high level - the `store()` APIs in `Properties` have been modified to now look for the `SOURCE_DATE_EPOCH` environment variable[2]. If that env variable is set, then instead of writing out the current date time as a date comment, the `store()` APIs instead will use the value set for this env variable to parse it to a `Date` and write out the string form of such a date. The implementation here uses the `d MMM yyyy HH:mm:ss 'GMT'` date format and `Locale.ROOT` to format and write out such a date. This should provide reproducibility whenever the `SOURCE_DATE_EPOCH` is set. Furthermore, intentionally, no changes in the date format of the "current date" have been done. >> >> These modified `store()` APIs work in the presence of the `SecurityManager` too. The caller is expected to have a read permission on the `SOURCE_DATE_EPOCH` environment variable. If the caller doesn't have that permission, then the implementation of these `store()` APIs will write out the "current date" and will ignore any value that has been set for the `SOURCE_DATE_EPOCH` env variable. This should allow for backward compatibility of existing applications, where, when they run under a `SecurityManager` and perhaps with an existing restrictive policy file, the presence of `SOURCE_DATE_EPOCH` shouldn't impact their calls to the `store()` APIs. >> >> The modified `store()` APIs will also ignore any value for `SOURCE_DATE_EPOCH` that cannot be parsed to an `long` value. In such cases, the `store()` APIs will write out the "current date" and ignore the value set for this environment variable. No exceptions will be thrown for such invalid values. This is an additional backward compatibility precaution to prevent any rogue value for `SOURCE_DATE_EPOCH` from breaking applications. >> >> An additional change in the implementation of these `store()` APIs and unrelated to the date comment, is that these APIs will now write out the property keys in a deterministic order. The keys will be written out in the natural ordering as specified by `java.lang.String#compareTo()` API. >> >> The combination of the ordering of the property keys when written out and the usage of `SOURCE_DATE_EPOCH` environment value to determine the date comment should together allow for reproducibility of the output generated by these `store()` APIs. >> >> New jtreg test classes have been introduced to verify these changes. The primary focus of `PropertiesStoreTest` is the ordering aspects of the property keys that are written out. On the other hand `StoreReproducibilityTest` focuses on the reproducibility of the output generated by these APIs. The `StoreReproducibilityTest` runs these tests both in the presence and absence of `SecurityManager`. Plus, in the presence of SecurityManager, it tests both the scenarios where the caller is granted the requisite permission and in other case not granted that permission. >> >> These new tests and existing tests under `test/jdk/java/util/Properties/` pass with these changes. >> >> [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-August/080758.html >> [2] https://reproducible-builds.org/specs/source-date-epoch/ > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > allow free-form text for java.util.Properties.storeDate system property src/java.base/share/classes/java/util/Properties.java line 832: > 830: * {@code #} character, the current date and time (formatted using the > 831: * {@code EEE MMM dd HH:mm:ss zzz yyyy} {@link DateTimeFormatter date format}), > 832: * and a line separator as generated by the {@code Writer}. Since this behavior is affected by a system property, and that property name is in the standard `java.*` namespace, that should be documented here. In addition, `Writer` has no notion of a line separator; it just comes from `System.lineSeparator`. I'd suggest something like this, replacing the paragraph starting with "Next": If the {@systemProperty java.util.Properties.storeDate} is set and is non-blank (as determined by {@link String#isBlank String.isBlank}, a comment line is written as follows. First, a {@code #} character is written, followed by the contents of the property, followed by a line separator. If the system property is not set or is blank, a comment line is written as follows. First, a {@code #} character is written, followed by the current date and time formatted as if by {@link DateTimeFormatter} with the format {@code "EEE MMM dd HH:mm:ss zzz yyyy"}, followed by a line separator. This was discussed elsewhere, but after writing that, I'm now thinking that we **should** honor the property even if it is blank. It would be useful to disable the timestamp simply by setting the property to the empty string; this will simply result in an empty comment line. This would simplify the code (and the spec) by removing conditions related to String::isBlank. Side question: do we want to do any escaping or vetting of the property value? If for example it contains embedded newlines, this could result in a malformed property file. Or, if carefully constructed, it could contain additional property values. I think this is an unintended consequence of changing the property value from a numeric time value to a free-form string. We may want to reconsider this. src/java.base/share/classes/java/util/Properties.java line 855: > 853: * the value of this system property represents a formatted > 854: * date time value that can be parsed back into a {@link Date} using an appropriate > 855: * {@link DateTimeFormatter} With the property behavior added to normative text above, I don't think we need this note anymore. We might want to leave something here about the convention of putting a timestamp here, and an implicit(?) requirement that it be formatted properly. ------------- PR: https://git.openjdk.java.net/jdk/pull/5372 From rriggs at openjdk.java.net Fri Sep 10 17:58:48 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 10 Sep 2021 17:58:48 GMT Subject: RFR: JDK-8273162 AbstractSplittableWithBrineGenerator does not create a random salt In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 18:01:04 GMT, Jim Laskey wrote: > RandomSupport.AbstractSplittableWithBrineGenerator. makeSplitsSpliterator is intending to create a salt from a random long. The salt should have random letters of size 4 for each consecutive 4 bits and then the last 4 bits as ff, i.e. all bits set. > > However the loop is never executed, the random bits are not used and the salt is always the same. > > This condition is false on the first execution: > > long multiplier = (1L << SALT_SHIFT) - 1; > long salt = multiplier << (64 - SALT_SHIFT); > while ((salt & multiplier) != 0) { > > > This can be corrected by changing: > > while ((salt & multiplier) != 0) { > > to > > while ((salt & multiplier) == 0) { Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5449 From bpb at openjdk.java.net Fri Sep 10 17:58:48 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 10 Sep 2021 17:58:48 GMT Subject: RFR: JDK-8273162 AbstractSplittableWithBrineGenerator does not create a random salt In-Reply-To: References: Message-ID: <-Rmsr3KMCywQ9qcQfmWy6HOACO9Su50xQK9LparaKVA=.ab8e32fb-ce5b-44d4-873b-e8258180eb4f@github.com> On Thu, 9 Sep 2021 18:01:04 GMT, Jim Laskey wrote: > RandomSupport.AbstractSplittableWithBrineGenerator. makeSplitsSpliterator is intending to create a salt from a random long. The salt should have random letters of size 4 for each consecutive 4 bits and then the last 4 bits as ff, i.e. all bits set. > > However the loop is never executed, the random bits are not used and the salt is always the same. > > This condition is false on the first execution: > > long multiplier = (1L << SALT_SHIFT) - 1; > long salt = multiplier << (64 - SALT_SHIFT); > while ((salt & multiplier) != 0) { > > > This can be corrected by changing: > > while ((salt & multiplier) != 0) { > > to > > while ((salt & multiplier) == 0) { Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5449 From jlaskey at openjdk.java.net Fri Sep 10 18:06:54 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Fri, 10 Sep 2021 18:06:54 GMT Subject: Integrated: JDK-8273162 AbstractSplittableWithBrineGenerator does not create a random salt In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 18:01:04 GMT, Jim Laskey wrote: > RandomSupport.AbstractSplittableWithBrineGenerator. makeSplitsSpliterator is intending to create a salt from a random long. The salt should have random letters of size 4 for each consecutive 4 bits and then the last 4 bits as ff, i.e. all bits set. > > However the loop is never executed, the random bits are not used and the salt is always the same. > > This condition is false on the first execution: > > long multiplier = (1L << SALT_SHIFT) - 1; > long salt = multiplier << (64 - SALT_SHIFT); > while ((salt & multiplier) != 0) { > > > This can be corrected by changing: > > while ((salt & multiplier) != 0) { > > to > > while ((salt & multiplier) == 0) { This pull request has now been integrated. Changeset: 5e1df2c7 Author: Jim Laskey URL: https://git.openjdk.java.net/jdk/commit/5e1df2c7d71e9393beaa4fd2d8812b065d053392 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8273162: AbstractSplittableWithBrineGenerator does not create a random salt Reviewed-by: rriggs, bpb ------------- PR: https://git.openjdk.java.net/jdk/pull/5449 From joehw at openjdk.java.net Fri Sep 10 18:14:49 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Fri, 10 Sep 2021 18:14:49 GMT Subject: RFR: 8273491: java.util.spi.LocaleServiceProvider spec contains statement that is too strict In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 23:29:24 GMT, Naoto Sato wrote: > Small spec clarification. Corresponding CSR has also been drafted. src/java.base/share/classes/java/util/spi/LocaleServiceProvider.java line 120: > 118: * the locale sensitive services separated by a comma. It is only read and cached at > 119: * the initialization of this class, so the later call to > 120: * {@link System#setProperty(String, String)} may not affect the order. I wonder if we can be clearer as "may not" implies uncertainty. While it indeed may or may not work due to the timing of the initialization of this class, my understanding of the above statement is that it implied the runtime startup is recommended as it provides assurance. Would it be better to put that in the statement? sth. like: It is read once and cached at the Java runtime startup or initialization of this class. A call after the initialization of this class will not affect the order. There's still uncertainty ------------- PR: https://git.openjdk.java.net/jdk/pull/5457 From github.com+44313413+jovanstevanovic at openjdk.java.net Fri Sep 10 18:33:51 2021 From: github.com+44313413+jovanstevanovic at openjdk.java.net (Jovan Stevanovic) Date: Fri, 10 Sep 2021 18:33:51 GMT Subject: RFR: 8273278: Support XSLT on GraalVM Native Image--deterministic bytecode generation in XSLT [v2] In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 15:56:04 GMT, Joe Wang wrote: >> Jovan Stevanovic 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 one additional commit since the last revision: >> >> 8273278: Improving XSLT support for GraalVM's Native Image. > > The headers look good now. Thanks. @JoeWang-Java Looks like the OpenJDK bot is bugging, so I think you need to comment again with the same sponsor command. ------------- PR: https://git.openjdk.java.net/jdk/pull/5331 From github.com+70726043+rgiulietti at openjdk.java.net Fri Sep 10 18:42:07 2021 From: github.com+70726043+rgiulietti at openjdk.java.net (Raffaello Giulietti) Date: Fri, 10 Sep 2021 18:42:07 GMT Subject: RFR: 8271602: Add Math.ceilDiv() family parallel to Math.floorDiv() family [v2] In-Reply-To: <2RZKAf-GYIh36SSVTA-22F4qXJ72qNSwO3ZIO9wl9kE=.b08de4f8-34da-4658-9a05-1eec7bce88f4@github.com> References: <2RZKAf-GYIh36SSVTA-22F4qXJ72qNSwO3ZIO9wl9kE=.b08de4f8-34da-4658-9a05-1eec7bce88f4@github.com> Message-ID: > This PR ideally continues #5285, which has been closed as a consequence of inadvertently removing the branch on my repo. See there for initial discussion. > > Sorry for the mess. Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: 8271602: Add Math.ceilDiv() family parallel to Math.floorDiv() family ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5341/files - new: https://git.openjdk.java.net/jdk/pull/5341/files/7afe3cf0..8e368361 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5341&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5341&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5341.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5341/head:pull/5341 PR: https://git.openjdk.java.net/jdk/pull/5341 From github.com+70726043+rgiulietti at openjdk.java.net Fri Sep 10 18:42:08 2021 From: github.com+70726043+rgiulietti at openjdk.java.net (Raffaello Giulietti) Date: Fri, 10 Sep 2021 18:42:08 GMT Subject: RFR: 8271602: Add Math.ceilDiv() family parallel to Math.floorDiv() family [v2] In-Reply-To: References: <2RZKAf-GYIh36SSVTA-22F4qXJ72qNSwO3ZIO9wl9kE=.b08de4f8-34da-4658-9a05-1eec7bce88f4@github.com> Message-ID: On Thu, 9 Sep 2021 23:44:49 GMT, Brian Burkhalter wrote: >> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: >> >> 8271602: Add Math.ceilDiv() family parallel to Math.floorDiv() family > > src/java.base/share/classes/java/lang/StrictMath.java line 1465: > >> 1463: *

>> 1464: * The floor modulus is {@code r = x - (ceilDiv(x, y) * y)}, >> 1465: * has the same sign as the divisor {@code y} or is zero, and > > In line 1465 I think `same` should be `opposite`. Just pushed the corrections. ------------- PR: https://git.openjdk.java.net/jdk/pull/5341 From github.com+44313413+jovanstevanovic at openjdk.java.net Fri Sep 10 19:16:51 2021 From: github.com+44313413+jovanstevanovic at openjdk.java.net (Jovan Stevanovic) Date: Fri, 10 Sep 2021 19:16:51 GMT Subject: Integrated: 8273278: Support XSLT on GraalVM Native Image--deterministic bytecode generation in XSLT In-Reply-To: References: Message-ID: On Wed, 1 Sep 2021 13:28:34 GMT, Jovan Stevanovic wrote: > GraalVM Native Image supports loading classes at runtime if they are known during image build (class predefinition). This is achieved by the JVMTI agent that registers dynamically generated classes in a regular HotSpot run. The Native Image build uses these registered classes to embed them into the produced binary so they can be loaded at runtime. Loading at runtime is achieved by matching the unique hash of generated classes. > > If the generated bytecode is unstable across runs, the generated native image can not match the hash of the runtime-generated bytecode to the pre-defined classes. The execution failure happens here: > https://github.com/oracle/graal/blob/master/substratevm/src/com.oracle.svm.core/src/com/oracle/svm/core/hub/PredefinedClassesSupport.java#L127-L131. > > In XSLT the produced bytecode is unstable for the following reasons: > > - Methods like ` HashMap#values` and `HashMap#keySet` result in different traversal orders of its elements yielding a different order of methods and fields. > > - The default `Object#toString` includes the current memory reference of `com.sun.org.apache.xalan.internal.xsltc.compiler.Number` in the generated class. This pull request has now been integrated. Changeset: f690a01f Author: jovanstevanovic Committer: Joe Wang URL: https://git.openjdk.java.net/jdk/commit/f690a01f1e5de4ace39aefad656cb7c99f9ec4e1 Stats: 23 lines in 4 files changed: 5 ins; 0 del; 18 mod 8273278: Support XSLT on GraalVM Native Image--deterministic bytecode generation in XSLT Reviewed-by: joehw ------------- PR: https://git.openjdk.java.net/jdk/pull/5331 From github.com+332398+kabutz at openjdk.java.net Fri Sep 10 19:24:56 2021 From: github.com+332398+kabutz at openjdk.java.net (kabutz) Date: Fri, 10 Sep 2021 19:24:56 GMT Subject: RFR: 8273541: Cleaner Thread creates with normal priority instead of MAX_PRIORITY - 2 In-Reply-To: References: <1NRlROh9TTsjWpOfyZNQohDUcdkn__KnwD90pu6t6X4=.1b9d7bb8-3bc9-403c-8006-4cdde210dd5d@github.com> Message-ID: On Fri, 10 Sep 2021 14:08:05 GMT, Claes Redestad wrote: > > This looks good. @cl4es might want to confirm that change was not intentional. > > Completely unintentional, and perplexing since it's not a simple copy-paste error.. The thread priorities in Java are the wrong way round, (high is 10, low is 1) so I was not surprised by this mistake. ------------- PR: https://git.openjdk.java.net/jdk/pull/5439 From naoto at openjdk.java.net Fri Sep 10 20:35:28 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 10 Sep 2021 20:35:28 GMT Subject: RFR: 8273491: java.util.spi.LocaleServiceProvider spec contains statement that is too strict [v2] In-Reply-To: References: Message-ID: <6QAY-otAZ7nOSgzBbA7WP8KPxeAgykHdBJVwcHz2NL8=.927a7fee-a360-4322-9bf5-2b1e67421773@github.com> On Fri, 10 Sep 2021 18:11:37 GMT, Joe Wang wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Reflecting review comment. > > src/java.base/share/classes/java/util/spi/LocaleServiceProvider.java line 120: > >> 118: * the locale sensitive services separated by a comma. It is only read and cached at >> 119: * the initialization of this class, so the later call to >> 120: * {@link System#setProperty(String, String)} may not affect the order. > > I wonder if we can be clearer as "may not" implies uncertainty. While it indeed may or may not work due to the timing of the initialization of this class, my understanding of the above statement is that it implied the runtime startup is recommended as it provides assurance. Would it be better to put that in the statement? sth. like: It is read once and cached at the Java runtime startup or initialization of this class. A call after the initialization of this class will not affect the order. It was intentional to use `may not` because as you said, there's still uncertainty. To clarify it more, I added wording that `setProperty` use is discouraged to change the preferred order. ------------- PR: https://git.openjdk.java.net/jdk/pull/5457 From naoto at openjdk.java.net Fri Sep 10 20:35:25 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 10 Sep 2021 20:35:25 GMT Subject: RFR: 8273491: java.util.spi.LocaleServiceProvider spec contains statement that is too strict [v2] In-Reply-To: References: Message-ID: <9vqR_Aqw-VATdBcDldc00t5J7pLtq9NXFVk8DfJ8eFM=.3de32058-5443-4556-b819-e09b188b0de2@github.com> > Small spec clarification. Corresponding CSR has also been drafted. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Reflecting review comment. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5457/files - new: https://git.openjdk.java.net/jdk/pull/5457/files/2781ad32..70bfbd69 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5457&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5457&range=00-01 Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5457.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5457/head:pull/5457 PR: https://git.openjdk.java.net/jdk/pull/5457 From joehw at openjdk.java.net Fri Sep 10 20:56:50 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Fri, 10 Sep 2021 20:56:50 GMT Subject: RFR: 8273491: java.util.spi.LocaleServiceProvider spec contains statement that is too strict [v2] In-Reply-To: <6QAY-otAZ7nOSgzBbA7WP8KPxeAgykHdBJVwcHz2NL8=.927a7fee-a360-4322-9bf5-2b1e67421773@github.com> References: <6QAY-otAZ7nOSgzBbA7WP8KPxeAgykHdBJVwcHz2NL8=.927a7fee-a360-4322-9bf5-2b1e67421773@github.com> Message-ID: On Fri, 10 Sep 2021 20:32:03 GMT, Naoto Sato wrote: >> src/java.base/share/classes/java/util/spi/LocaleServiceProvider.java line 120: >> >>> 118: * the locale sensitive services separated by a comma. It is only read and cached at >>> 119: * the initialization of this class, so the later call to >>> 120: * {@link System#setProperty(String, String)} may not affect the order. >> >> I wonder if we can be clearer as "may not" implies uncertainty. While it indeed may or may not work due to the timing of the initialization of this class, my understanding of the above statement is that it implied the runtime startup is recommended as it provides assurance. Would it be better to put that in the statement? sth. like: It is read once and cached at the Java runtime startup or initialization of this class. A call after the initialization of this class will not affect the order. > > It was intentional to use `may not` because as you said, there's still uncertainty. To clarify it more, I added wording that `setProperty` use is discouraged to change the preferred order. That sounds good to me, suggesting doing it at launch while discouraging the use of setProperty. ------------- PR: https://git.openjdk.java.net/jdk/pull/5457 From joehw at openjdk.java.net Fri Sep 10 20:56:49 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Fri, 10 Sep 2021 20:56:49 GMT Subject: RFR: 8273491: java.util.spi.LocaleServiceProvider spec contains statement that is too strict [v2] In-Reply-To: <9vqR_Aqw-VATdBcDldc00t5J7pLtq9NXFVk8DfJ8eFM=.3de32058-5443-4556-b819-e09b188b0de2@github.com> References: <9vqR_Aqw-VATdBcDldc00t5J7pLtq9NXFVk8DfJ8eFM=.3de32058-5443-4556-b819-e09b188b0de2@github.com> Message-ID: <_zEFOBYwH4HSehQO54L_63t3o-blOvn96BtELg77NCs=.696be05c-65fb-405d-b7ea-0fb7eb01642d@github.com> On Fri, 10 Sep 2021 20:35:25 GMT, Naoto Sato wrote: >> Small spec clarification. Corresponding CSR has also been drafted. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Reflecting review comment. Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5457 From igraves at openjdk.java.net Fri Sep 10 20:57:34 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Fri, 10 Sep 2021 20:57:34 GMT Subject: RFR: 8273430: Suspicious duplicate condition in java.util.regex.Grapheme#isExcludedSpacingMark [v2] In-Reply-To: <7eQexh7uLUwH-Mh_P_Hdq4clffXUKIRsHhVBWEUYNuA=.04a7b8fa-ba90-4a01-9c08-99604a76c7c2@github.com> References: <7eQexh7uLUwH-Mh_P_Hdq4clffXUKIRsHhVBWEUYNuA=.04a7b8fa-ba90-4a01-9c08-99604a76c7c2@github.com> Message-ID: > The duplicate condition in this chain of expressions needs to be shrunk to drop a couple of character that are not excluded spacing marks. Ian Graves has updated the pull request incrementally with one additional commit since the last revision: Refactoring test to whitebox ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5425/files - new: https://git.openjdk.java.net/jdk/pull/5425/files/ed2e4d2a..c60523af Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5425&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5425&range=00-01 Stats: 545 lines in 4 files changed: 147 ins; 395 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5425.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5425/head:pull/5425 PR: https://git.openjdk.java.net/jdk/pull/5425 From igraves at openjdk.java.net Fri Sep 10 21:02:45 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Fri, 10 Sep 2021 21:02:45 GMT Subject: RFR: 8273430: Suspicious duplicate condition in java.util.regex.Grapheme#isExcludedSpacingMark [v2] In-Reply-To: References: <7eQexh7uLUwH-Mh_P_Hdq4clffXUKIRsHhVBWEUYNuA=.04a7b8fa-ba90-4a01-9c08-99604a76c7c2@github.com> Message-ID: On Fri, 10 Sep 2021 20:57:34 GMT, Ian Graves wrote: >> The duplicate condition in this chain of expressions needs to be shrunk to drop a couple of character that are not excluded spacing marks. > > Ian Graves has updated the pull request incrementally with one additional commit since the last revision: > > Refactoring test to whitebox Updating the tests here. Existing ones included code copy/pasted directly from the unit under test. Refactored to a whitebox-style testing that injects accessors into `java.util.regex` so we don't have to modify code in two places to keep it in sync. Also relaxed two private static methods in `java.util.regex.Grapheme` to package-private so the injected accessor class can reach them and expose them for the test. ------------- PR: https://git.openjdk.java.net/jdk/pull/5425 From naoto at openjdk.java.net Fri Sep 10 21:12:50 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 10 Sep 2021 21:12:50 GMT Subject: RFR: 8273430: Suspicious duplicate condition in java.util.regex.Grapheme#isExcludedSpacingMark [v2] In-Reply-To: References: <7eQexh7uLUwH-Mh_P_Hdq4clffXUKIRsHhVBWEUYNuA=.04a7b8fa-ba90-4a01-9c08-99604a76c7c2@github.com> Message-ID: <1gQaiN6z_9DqZDBuBbdxmcfKrRwA0DWNQtICgq76qY0=.5e836544-30b5-4465-a08c-76c40a8ef556@github.com> On Fri, 10 Sep 2021 20:57:34 GMT, Ian Graves wrote: >> The duplicate condition in this chain of expressions needs to be shrunk to drop a couple of character that are not excluded spacing marks. > > Ian Graves has updated the pull request incrementally with one additional commit since the last revision: > > Refactoring test to whitebox Looks good. Nice cleanup! ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5425 From prappo at openjdk.java.net Fri Sep 10 21:25:00 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Fri, 10 Sep 2021 21:25:00 GMT Subject: RFR: 8273616: Fix trivial doc typos in the java.base module Message-ID: 8273616: Fix trivial doc typos in the java.base module ------------- Commit messages: - Initial commit Changes: https://git.openjdk.java.net/jdk/pull/5475/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5475&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273616 Stats: 55 lines in 34 files changed: 0 ins; 0 del; 55 mod Patch: https://git.openjdk.java.net/jdk/pull/5475.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5475/head:pull/5475 PR: https://git.openjdk.java.net/jdk/pull/5475 From rriggs at openjdk.java.net Fri Sep 10 21:29:49 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 10 Sep 2021 21:29:49 GMT Subject: RFR: 8273514: java/util/DoubleStreamSums/CompensatedSums.java failure [v2] In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 16:30:29 GMT, Ian Graves wrote: >> Relaxing some assertion bounds to allow for small error values that still show improvement over previous summation method. > > Ian Graves has updated the pull request incrementally with one additional commit since the last revision: > > Tweaking asserts LGTM ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5430 From jrose at openjdk.java.net Fri Sep 10 21:58:48 2021 From: jrose at openjdk.java.net (John R Rose) Date: Fri, 10 Sep 2021 21:58:48 GMT Subject: RFR: 8273616: Fix trivial doc typos in the java.base module In-Reply-To: References: Message-ID: On Fri, 10 Sep 2021 21:16:19 GMT, Pavel Rappo wrote: > 8273616: Fix trivial doc typos in the java.base module Approved, except for two changes commented above: the original "it need only force" is correct usage, and "it needs only force" is not good usage, but "it only needs to force" would be clearer and also correct. src/java.base/share/classes/java/nio/channels/AsynchronousFileChannel.java line 399: > 397: * If {@code true} then this method is required to force changes > 398: * to both the file's content and metadata to be written to > 399: * storage; otherwise, it needs only force content changes to be This is a correct though rare use of subjunctive mood: One need not change it. However, if be desired that we change the mood to indicative, I suggest s/it need only force/it only needs to force/. src/java.base/share/classes/java/nio/channels/FileChannel.java line 567: > 565: * If {@code true} then this method is required to force changes > 566: * to both the file's content and metadata to be written to > 567: * storage; otherwise, it needs only force content changes to be (same as previous comment: the suggested fix makes the English *less* correct) ------------- Marked as reviewed by jrose (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5475 From github.com+592810+efge at openjdk.java.net Fri Sep 10 22:55:43 2021 From: github.com+592810+efge at openjdk.java.net (Florent Guillaume) Date: Fri, 10 Sep 2021 22:55:43 GMT Subject: RFR: 8273616: Fix trivial doc typos in the java.base module In-Reply-To: References: Message-ID: On Fri, 10 Sep 2021 21:51:45 GMT, John R Rose wrote: >> 8273616: Fix trivial doc typos in the java.base module > > src/java.base/share/classes/java/nio/channels/AsynchronousFileChannel.java line 399: > >> 397: * If {@code true} then this method is required to force changes >> 398: * to both the file's content and metadata to be written to >> 399: * storage; otherwise, it needs only force content changes to be > > This is a correct though rare use of subjunctive mood: One need not change it. > However, if be desired that we change the mood to indicative, I suggest s/it need only force/it only needs to force/. (_it need only force_ is not really subjunctive mood, but rather usage as a modal auxiliary, see https://english.stackexchange.com/a/297235) ------------- PR: https://git.openjdk.java.net/jdk/pull/5475 From darcy at openjdk.java.net Fri Sep 10 23:14:59 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 10 Sep 2021 23:14:59 GMT Subject: RFR: 8273259: Character.getName doesn't follow Unicode spec for ideographs [v3] In-Reply-To: References: <3ZOCioU8lMEPuWdaYlBv8L6oNdIwVjwZpPbKLWwkOjs=.0e8939c8-9cff-4600-a869-9c5f137fd2e5@github.com> Message-ID: <8IAkYctKoeaTyFcsgmLEe0-zOecIYMZeU5hP7LILbqo=.a9e297ce-013e-4fd5-affb-02297b192f53@github.com> On Fri, 10 Sep 2021 12:21:41 GMT, Naoto Sato wrote: >> Simple spec clarification. A CSR has also been drafted (https://bugs.openjdk.java.net/browse/JDK-8273296). > > Naoto Sato 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 four additional commits since the last revision: > > - Merge branch 'master' into JDK-8273259 > - Reflecting the CSR review comment > - Refined wordings. > - 8273259: Character.getName doesn't follow Unicode spec for ideographs Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5354 From aoqi at openjdk.java.net Fri Sep 10 23:15:54 2021 From: aoqi at openjdk.java.net (Ao Qi) Date: Fri, 10 Sep 2021 23:15:54 GMT Subject: Integrated: 8273595: tools/jpackage tests do not work on apt-based Linux distros like Debian In-Reply-To: References: Message-ID: On Fri, 10 Sep 2021 12:03:48 GMT, Ao Qi wrote: > A similar issue on Ubuntu has been fixed by [JDK-8238953](https://bugs.openjdk.java.net/browse/JDK-8238953). However, tools/jpackage tests do not work on Debian Linux or other apt-based Linux, when rpm package is installed. This issue proposes a general fix for apt-based Linux. This pull request has now been integrated. Changeset: f189dff5 Author: Ao Qi Committer: Jie Fu URL: https://git.openjdk.java.net/jdk/commit/f189dff5cbd4d47e1b2f3c0e5f2c866a7effccdf Stats: 20 lines in 2 files changed: 0 ins; 15 del; 5 mod 8273595: tools/jpackage tests do not work on apt-based Linux distros like Debian Co-authored-by: Sun Xu Reviewed-by: asemenyuk, herrick ------------- PR: https://git.openjdk.java.net/jdk/pull/5462 From prappo at openjdk.java.net Fri Sep 10 23:20:12 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Fri, 10 Sep 2021 23:20:12 GMT Subject: RFR: 8273616: Fix trivial doc typos in the java.base module [v2] In-Reply-To: References: Message-ID: On Fri, 10 Sep 2021 21:52:36 GMT, John R Rose wrote: >> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert two fixes > > src/java.base/share/classes/java/nio/channels/FileChannel.java line 567: > >> 565: * If {@code true} then this method is required to force changes >> 566: * to both the file's content and metadata to be written to >> 567: * storage; otherwise, it needs only force content changes to be > > (same as previous comment: the suggested fix makes the English *less* correct) Reverted both in 9a9deee; thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/5475 From prappo at openjdk.java.net Fri Sep 10 23:20:11 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Fri, 10 Sep 2021 23:20:11 GMT Subject: RFR: 8273616: Fix trivial doc typos in the java.base module [v2] In-Reply-To: References: Message-ID: > 8273616: Fix trivial doc typos in the java.base module Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: Revert two fixes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5475/files - new: https://git.openjdk.java.net/jdk/pull/5475/files/b90d1556..9a9deee1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5475&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5475&range=00-01 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5475.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5475/head:pull/5475 PR: https://git.openjdk.java.net/jdk/pull/5475 From iris at openjdk.java.net Sat Sep 11 00:55:44 2021 From: iris at openjdk.java.net (Iris Clark) Date: Sat, 11 Sep 2021 00:55:44 GMT Subject: RFR: 8273616: Fix trivial doc typos in the java.base module [v2] In-Reply-To: References: Message-ID: On Fri, 10 Sep 2021 23:20:11 GMT, Pavel Rappo wrote: >> 8273616: Fix trivial doc typos in the java.base module > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Revert two fixes Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5475 From bpb at openjdk.java.net Sat Sep 11 02:11:47 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Sat, 11 Sep 2021 02:11:47 GMT Subject: RFR: 8271602: Add Math.ceilDiv() family parallel to Math.floorDiv() family [v2] In-Reply-To: References: <2RZKAf-GYIh36SSVTA-22F4qXJ72qNSwO3ZIO9wl9kE=.b08de4f8-34da-4658-9a05-1eec7bce88f4@github.com> Message-ID: On Fri, 10 Sep 2021 18:42:07 GMT, Raffaello Giulietti wrote: >> This PR ideally continues #5285, which has been closed as a consequence of inadvertently removing the branch on my repo. See there for initial discussion. >> >> Sorry for the mess. > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > 8271602: Add Math.ceilDiv() family parallel to Math.floorDiv() family Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5341 From lancea at openjdk.java.net Sat Sep 11 11:09:48 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Sat, 11 Sep 2021 11:09:48 GMT Subject: RFR: 8273491: java.util.spi.LocaleServiceProvider spec contains statement that is too strict [v2] In-Reply-To: <6QAY-otAZ7nOSgzBbA7WP8KPxeAgykHdBJVwcHz2NL8=.927a7fee-a360-4322-9bf5-2b1e67421773@github.com> References: <6QAY-otAZ7nOSgzBbA7WP8KPxeAgykHdBJVwcHz2NL8=.927a7fee-a360-4322-9bf5-2b1e67421773@github.com> Message-ID: On Fri, 10 Sep 2021 20:32:03 GMT, Naoto Sato wrote: >> src/java.base/share/classes/java/util/spi/LocaleServiceProvider.java line 120: >> >>> 118: * the locale sensitive services separated by a comma. It is only read and cached at >>> 119: * the initialization of this class, so the later call to >>> 120: * {@link System#setProperty(String, String)} may not affect the order. >> >> I wonder if we can be clearer as "may not" implies uncertainty. While it indeed may or may not work due to the timing of the initialization of this class, my understanding of the above statement is that it implied the runtime startup is recommended as it provides assurance. Would it be better to put that in the statement? sth. like: It is read once and cached at the Java runtime startup or initialization of this class. A call after the initialization of this class will not affect the order. > > It was intentional to use `may not` because as you said, there's still uncertainty. To clarify it more, I added wording that `setProperty` use is discouraged to change the preferred order. Hi Naoto, A couple of questions: - Are there any scenarios where invoking setProperty will not override the command line setting ? - Did you consider an `@ImplNote` for your clarification given the behavior "might" be different in other implementations (I am not sure myself) and is implementation defined? Best Lance ------------- PR: https://git.openjdk.java.net/jdk/pull/5457 From naoto at openjdk.java.net Sat Sep 11 14:02:46 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Sat, 11 Sep 2021 14:02:46 GMT Subject: RFR: 8273491: java.util.spi.LocaleServiceProvider spec contains statement that is too strict [v2] In-Reply-To: References: <6QAY-otAZ7nOSgzBbA7WP8KPxeAgykHdBJVwcHz2NL8=.927a7fee-a360-4322-9bf5-2b1e67421773@github.com> Message-ID: <3ZahQVUuID0T_d1E25ER9yfhFUHtA5Lcb9V3TwW5Dkg=.06e1a3a6-7398-4f06-8886-bd03040503d2@github.com> On Fri, 10 Sep 2021 20:53:35 GMT, Joe Wang wrote: >> Hi Naoto, >> >> A couple of questions: >> >> - Are there any scenarios where invoking setProperty will not override the command line setting ? >> - Did you consider an `@ImplNote` for your clarification given the behavior "might" be different in other implementations (I am not sure myself) and is implementation defined? >> >> Best >> Lance > > That sounds good to me, suggesting doing it at launch while discouraging the use of setProperty. Hi Lance, > * Are there any scenarios where invoking setProperty will not override the command line setting ? Yes. For example, if a logger is installed, it formats the log date/time which causes initialization of locale-related classes before the app's main() method invocation, resulting setProperty() having no effect. > * Did you consider an `@ImplNote` for your clarification given the behavior "might" be different in other implementations (I am not sure myself) and is implementation defined? As in the above example, the behavior changes regardless of the implementation of the runtime. The clarification is mainly for the API consumer, rather than platform implementors. Hope this answers your questions. ------------- PR: https://git.openjdk.java.net/jdk/pull/5457 From lancea at openjdk.java.net Sat Sep 11 15:02:52 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Sat, 11 Sep 2021 15:02:52 GMT Subject: RFR: 8273491: java.util.spi.LocaleServiceProvider spec contains statement that is too strict [v2] In-Reply-To: <3ZahQVUuID0T_d1E25ER9yfhFUHtA5Lcb9V3TwW5Dkg=.06e1a3a6-7398-4f06-8886-bd03040503d2@github.com> References: <6QAY-otAZ7nOSgzBbA7WP8KPxeAgykHdBJVwcHz2NL8=.927a7fee-a360-4322-9bf5-2b1e67421773@github.com> <3ZahQVUuID0T_d1E25ER9yfhFUHtA5Lcb9V3TwW5Dkg=.06e1a3a6-7398-4f06-8886-bd03040503d2@github.com> Message-ID: On Sat, 11 Sep 2021 13:59:25 GMT, Naoto Sato wrote: >> That sounds good to me, suggesting doing it at launch while discouraging the use of setProperty. > > Hi Lance, > >> * Are there any scenarios where invoking setProperty will not override the command line setting ? > > Yes. For example, if a logger is installed, it formats the log date/time which causes initialization of locale-related classes before the app's main() method invocation, resulting setProperty() having no effect. > >> * Did you consider an `@ImplNote` for your clarification given the behavior "might" be different in other implementations (I am not sure myself) and is implementation defined? > > As in the above example, the behavior changes regardless of the implementation of the runtime. The clarification is mainly for the API consumer, rather than platform implementors. > > Hope this answers your questions. Hi Naoto, Thank you for the clarification. Yes it makes sense. Best Lance ------------- PR: https://git.openjdk.java.net/jdk/pull/5457 From lancea at openjdk.java.net Sat Sep 11 15:02:52 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Sat, 11 Sep 2021 15:02:52 GMT Subject: RFR: 8273491: java.util.spi.LocaleServiceProvider spec contains statement that is too strict [v2] In-Reply-To: <9vqR_Aqw-VATdBcDldc00t5J7pLtq9NXFVk8DfJ8eFM=.3de32058-5443-4556-b819-e09b188b0de2@github.com> References: <9vqR_Aqw-VATdBcDldc00t5J7pLtq9NXFVk8DfJ8eFM=.3de32058-5443-4556-b819-e09b188b0de2@github.com> Message-ID: On Fri, 10 Sep 2021 20:35:25 GMT, Naoto Sato wrote: >> Small spec clarification. Corresponding CSR has also been drafted. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Reflecting review comment. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5457 From lancea at openjdk.java.net Sat Sep 11 15:05:49 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Sat, 11 Sep 2021 15:05:49 GMT Subject: RFR: 8273616: Fix trivial doc typos in the java.base module [v2] In-Reply-To: References: Message-ID: On Fri, 10 Sep 2021 23:20:11 GMT, Pavel Rappo wrote: >> 8273616: Fix trivial doc typos in the java.base module > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Revert two fixes Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5475 From david.holmes at oracle.com Sun Sep 12 06:20:11 2021 From: david.holmes at oracle.com (David Holmes) Date: Sun, 12 Sep 2021 16:20:11 +1000 Subject: RFR: 8273541: Cleaner Thread creates with normal priority instead of MAX_PRIORITY - 2 In-Reply-To: References: <1NRlROh9TTsjWpOfyZNQohDUcdkn__KnwD90pu6t6X4=.1b9d7bb8-3bc9-403c-8006-4cdde210dd5d@github.com> Message-ID: <6be87777-d60d-7d29-b209-1c241997ffd3@oracle.com> On 11/09/2021 5:24 am, kabutz wrote: > On Fri, 10 Sep 2021 14:08:05 GMT, Claes Redestad wrote: > >>> This looks good. @cl4es might want to confirm that change was not intentional. >> >> Completely unintentional, and perplexing since it's not a simple copy-paste error.. > > The thread priorities in Java are the wrong way round, (high is 10, low is 1) so I was not surprised by this mistake. They are not "the wrong way around" they followed Solaris Global Dispatch Priorities (and Windows priorities for that matter). It makes a lot more sense than systems where a "higher priority" means a lower numerical priority value IMO. :) Cheers, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/5439 > From github.com+741251+turbanoff at openjdk.java.net Sun Sep 12 13:52:52 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Sun, 12 Sep 2021 13:52:52 GMT Subject: Integrated: 8273484: Cleanup unnecessary null comparison before instanceof check in java.naming In-Reply-To: References: Message-ID: On Mon, 6 Sep 2021 08:08:33 GMT, Andrey Turbanov wrote: > Update code checks both non-null and instance of a class in java.naming module classes. > The checks and explicit casts could also be replaced with pattern matching for the instanceof operator. > For example: > The following code: > > return (obj != null && > obj instanceof CompoundName && > impl.equals(((CompoundName)obj).impl)); > > > Can be simplified to: > > > return (obj instanceof CompoundName other) && > impl.equals(other.impl); > > > See similar cleanup in java.base - https://bugs.openjdk.java.net/browse/JDK-8258422 This pull request has now been integrated. Changeset: 2ee1f96c Author: Andrey Turbanov Committer: Aleksei Efimov URL: https://git.openjdk.java.net/jdk/commit/2ee1f96c14b80b63a29445629b1f2e1caf88e075 Stats: 44 lines in 13 files changed: 0 ins; 11 del; 33 mod 8273484: Cleanup unnecessary null comparison before instanceof check in java.naming Reviewed-by: aefimov, dfuchs ------------- PR: https://git.openjdk.java.net/jdk/pull/5374 From jpai at openjdk.java.net Sun Sep 12 14:03:42 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Sun, 12 Sep 2021 14:03:42 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v11] In-Reply-To: References: Message-ID: > The commit in this PR implements the proposal for enhancement that was discussed in the core-libs-dev mailing list recently[1], for https://bugs.openjdk.java.net/browse/JDK-8231640 > > At a high level - the `store()` APIs in `Properties` have been modified to now look for the `SOURCE_DATE_EPOCH` environment variable[2]. If that env variable is set, then instead of writing out the current date time as a date comment, the `store()` APIs instead will use the value set for this env variable to parse it to a `Date` and write out the string form of such a date. The implementation here uses the `d MMM yyyy HH:mm:ss 'GMT'` date format and `Locale.ROOT` to format and write out such a date. This should provide reproducibility whenever the `SOURCE_DATE_EPOCH` is set. Furthermore, intentionally, no changes in the date format of the "current date" have been done. > > These modified `store()` APIs work in the presence of the `SecurityManager` too. The caller is expected to have a read permission on the `SOURCE_DATE_EPOCH` environment variable. If the caller doesn't have that permission, then the implementation of these `store()` APIs will write out the "current date" and will ignore any value that has been set for the `SOURCE_DATE_EPOCH` env variable. This should allow for backward compatibility of existing applications, where, when they run under a `SecurityManager` and perhaps with an existing restrictive policy file, the presence of `SOURCE_DATE_EPOCH` shouldn't impact their calls to the `store()` APIs. > > The modified `store()` APIs will also ignore any value for `SOURCE_DATE_EPOCH` that cannot be parsed to an `long` value. In such cases, the `store()` APIs will write out the "current date" and ignore the value set for this environment variable. No exceptions will be thrown for such invalid values. This is an additional backward compatibility precaution to prevent any rogue value for `SOURCE_DATE_EPOCH` from breaking applications. > > An additional change in the implementation of these `store()` APIs and unrelated to the date comment, is that these APIs will now write out the property keys in a deterministic order. The keys will be written out in the natural ordering as specified by `java.lang.String#compareTo()` API. > > The combination of the ordering of the property keys when written out and the usage of `SOURCE_DATE_EPOCH` environment value to determine the date comment should together allow for reproducibility of the output generated by these `store()` APIs. > > New jtreg test classes have been introduced to verify these changes. The primary focus of `PropertiesStoreTest` is the ordering aspects of the property keys that are written out. On the other hand `StoreReproducibilityTest` focuses on the reproducibility of the output generated by these APIs. The `StoreReproducibilityTest` runs these tests both in the presence and absence of `SecurityManager`. Plus, in the presence of SecurityManager, it tests both the scenarios where the caller is granted the requisite permission and in other case not granted that permission. > > These new tests and existing tests under `test/jdk/java/util/Properties/` pass with these changes. > > [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-August/080758.html > [2] https://reproducible-builds.org/specs/source-date-epoch/ Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: Update javadoc based on Stuart's inputs ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5372/files - new: https://git.openjdk.java.net/jdk/pull/5372/files/1d24a3a8..c1dfb18f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5372&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5372&range=09-10 Stats: 17 lines in 1 file changed: 6 ins; 3 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/5372.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5372/head:pull/5372 PR: https://git.openjdk.java.net/jdk/pull/5372 From jai.forums2013 at gmail.com Sun Sep 12 14:29:38 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Sun, 12 Sep 2021 19:59:38 +0530 Subject: RFR: 8231640: (prop) Canonical property storage [v10] In-Reply-To: References: Message-ID: Hello Stuart, On 10/09/21 11:12 pm, Stuart Marks wrote: > > src/java.base/share/classes/java/util/Properties.java line 832: > >> 830: * {@code #} character, the current date and time (formatted using the >> 831: * {@code EEE MMM dd HH:mm:ss zzz yyyy} {@link DateTimeFormatter date format}), >> 832: * and a line separator as generated by the {@code Writer}. > Since this behavior is affected by a system property, and that property name is in the standard `java.*` namespace, that should be documented here. In addition, `Writer` has no notion of a line separator; it just comes from `System.lineSeparator`. I'd suggest something like this, replacing the paragraph starting with "Next": > > > If the {@systemProperty java.util.Properties.storeDate} is set and is non-blank (as determined by > {@link String#isBlank String.isBlank}, a comment line is written as follows. First, a {@code #} character is written, followed by the contents of the property, followed by a line separator. > > If the system property is not set or is blank, a comment line is written as follows. First, a {@code #} character is written, followed by the current date and time formatted as if by {@link DateTimeFormatter} with the format > {@code "EEE MMM dd HH:mm:ss zzz yyyy"}, followed by a line separator. Done. I've updated the PR to use this text in the javadoc. > This was discussed elsewhere, but after writing that, I'm now thinking that we **should** honor the property even if it is blank. It would be useful to disable the timestamp simply by setting the property to the empty string; this will simply result in an empty comment line. This would simplify the code (and the spec) by removing conditions related to String::isBlank. OK. I don't see any obvious issues with interpreting empty/whitespace-only value for the system property to translate to an empty comment line. To be clear, an empty comment line that gets written out in such cases is *always* going to be the "#" character followed by a line separator right? Irrespective of what or how many whitespace characters are present in the property value? Or do you want those characters to be carried over into that comment line that gets written out? The reason I ask this is because I think we should always write just the "#" followed by the line separator character in such cases, which effectively means we will still need the String::isBlank check which would then look something like: if (propVal.isBlank()) { ? bw.write("#"); ? bw.newLine(); } > Side question: do we want to do any escaping or vetting of the property value? One of the reasons why we didn't want to use the date in epoch seconds or a formatted date string was to avoid the complexities that come with managing that property value. So a free-form property value seemed more appropriate and I think a free-form value still seems appropriate, but I think we should keep any vetting to minimal. More details below. > If for example it contains embedded newlines, this could result in a malformed property file. Or, if carefully constructed, it could contain additional property values. I think this is an unintended consequence of changing the property value from a numeric time value to a free-form string. We may want to reconsider this. The specification on the load(Reader reader) method of the java.util.Properties class has this to say about comment lines (and lines in general). (snipped relevant content): There are two kinds of line, natural lines and logical lines. A natural line is defined as a line of characters that is terminated either by a set of line terminator characters ({@code \n} or {@code \r} or {@code \r\n}) or by the end of the stream. A natural line may be either a blank line, a comment line, or hold all or some of a key-element pair. A logical line holds all the data of a key-element pair, which may be spread out across several adjacent natural lines by escaping the line terminator sequence with a backslash character {@code \}.? Note that a comment line cannot be extended in this manner; every natural line that is a comment must have its own comment indicator, as described below. With that knowledge about comment lines, I think what we should do is disallow system property values that contain any form of line terminator characters (\n or \r or \r\n). If the system property value is _not_ blank (as specified by String::isBlank) and contains any of these line terminator characters, we should simply ignore it and write out the current date as the date comment. That, IMO, should prevent any of these sneaky/rogue value that can end up either creating additional property key/values to be written out or causing any malformed properties file. Plus, that would help us keep the vetting to minimal without involving too much complexity. > src/java.base/share/classes/java/util/Properties.java line 855: > >> 853: * the value of this system property represents a formatted >> 854: * date time value that can be parsed back into a {@link Date} using an appropriate >> 855: * {@link DateTimeFormatter} > With the property behavior added to normative text above, I don't think we need this note anymore. We might want to leave something here about the convention of putting a timestamp here, and an implicit(?) requirement that it be formatted properly. The newly updated PR has updated this @implNote to remove some of the previous text and yet retain some hints on what would be an "ideal" value for the system property value. But I think we should perhaps just get rid of this @implNote since we are now proposing to allow empty comment lines and free form text and this no longer is a "let's use this system property to allow users to specify a fixed date" enhancement. -Jaikiran From alanb at openjdk.java.net Sun Sep 12 14:31:50 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 12 Sep 2021 14:31:50 GMT Subject: RFR: 8233674: JarURLConnection.getJarFile throws Exception if some process is holding the file In-Reply-To: References: Message-ID: On Fri, 10 Sep 2021 09:23:52 GMT, Masanori Yano wrote: > Could you please review the 8233674 bug fixes? > This problem is caused by the antivirus software opening the file for a short time, so CreateFile() should be retried. This will need discussion as to whether the JDK should put in retry loops to work around interference from virus checkers. I wonder if it possible to get any input from the Microsoft engineers on whether native applications are expected to do this or whether the issue here is actually a configuration issue or problem with a specific virus checker. If we are adding a workaround to the JDK then it will require much more broader changes that does proposed so I think more analysis and discussion will be required before deciding whether it is right to do anywhere here or not. ------------- Changes requested by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5460 From jpai at openjdk.java.net Sun Sep 12 16:09:51 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Sun, 12 Sep 2021 16:09:51 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v11] In-Reply-To: References: Message-ID: On Sun, 12 Sep 2021 14:03:42 GMT, Jaikiran Pai wrote: >> The commit in this PR implements the proposal for enhancement that was discussed in the core-libs-dev mailing list recently[1], for https://bugs.openjdk.java.net/browse/JDK-8231640 >> >> At a high level - the `store()` APIs in `Properties` have been modified to now look for the `SOURCE_DATE_EPOCH` environment variable[2]. If that env variable is set, then instead of writing out the current date time as a date comment, the `store()` APIs instead will use the value set for this env variable to parse it to a `Date` and write out the string form of such a date. The implementation here uses the `d MMM yyyy HH:mm:ss 'GMT'` date format and `Locale.ROOT` to format and write out such a date. This should provide reproducibility whenever the `SOURCE_DATE_EPOCH` is set. Furthermore, intentionally, no changes in the date format of the "current date" have been done. >> >> These modified `store()` APIs work in the presence of the `SecurityManager` too. The caller is expected to have a read permission on the `SOURCE_DATE_EPOCH` environment variable. If the caller doesn't have that permission, then the implementation of these `store()` APIs will write out the "current date" and will ignore any value that has been set for the `SOURCE_DATE_EPOCH` env variable. This should allow for backward compatibility of existing applications, where, when they run under a `SecurityManager` and perhaps with an existing restrictive policy file, the presence of `SOURCE_DATE_EPOCH` shouldn't impact their calls to the `store()` APIs. >> >> The modified `store()` APIs will also ignore any value for `SOURCE_DATE_EPOCH` that cannot be parsed to an `long` value. In such cases, the `store()` APIs will write out the "current date" and ignore the value set for this environment variable. No exceptions will be thrown for such invalid values. This is an additional backward compatibility precaution to prevent any rogue value for `SOURCE_DATE_EPOCH` from breaking applications. >> >> An additional change in the implementation of these `store()` APIs and unrelated to the date comment, is that these APIs will now write out the property keys in a deterministic order. The keys will be written out in the natural ordering as specified by `java.lang.String#compareTo()` API. >> >> The combination of the ordering of the property keys when written out and the usage of `SOURCE_DATE_EPOCH` environment value to determine the date comment should together allow for reproducibility of the output generated by these `store()` APIs. >> >> New jtreg test classes have been introduced to verify these changes. The primary focus of `PropertiesStoreTest` is the ordering aspects of the property keys that are written out. On the other hand `StoreReproducibilityTest` focuses on the reproducibility of the output generated by these APIs. The `StoreReproducibilityTest` runs these tests both in the presence and absence of `SecurityManager`. Plus, in the presence of SecurityManager, it tests both the scenarios where the caller is granted the requisite permission and in other case not granted that permission. >> >> These new tests and existing tests under `test/jdk/java/util/Properties/` pass with these changes. >> >> [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-August/080758.html >> [2] https://reproducible-builds.org/specs/source-date-epoch/ > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Update javadoc based on Stuart's inputs Thinking more about this, given that there's now willingless to allow this system property to allow empty comments or even free form text and do away with backward compatibilty concerns that this will no longer be representing a date comment, I would like to propose something else. Let's take a small step back though. I think we all agree that the text of the default date comment isn't what is contentious. Instead, it's the presence of that comment itself. So instead of trying to allow users to feed some different text into this comment, why not just allow them to say whether or not they want this comment? In other words, why not consider the value of java.util.Properties.storeDate be either "true" or "false" and consider it a boolean system property? That should avoid all these complexities. ------------- PR: https://git.openjdk.java.net/jdk/pull/5372 From darcy at openjdk.java.net Mon Sep 13 00:26:47 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 13 Sep 2021 00:26:47 GMT Subject: RFR: 8273514: java/util/DoubleStreamSums/CompensatedSums.java failure [v2] In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 16:30:29 GMT, Ian Graves wrote: >> Relaxing some assertion bounds to allow for small error values that still show improvement over previous summation method. > > Ian Graves has updated the pull request incrementally with one additional commit since the last revision: > > Tweaking asserts Marked as reviewed by darcy (Reviewer). test/jdk/java/util/DoubleStreamSums/CompensatedSums.java line 87: > 85: badParallelStreamError += Math.pow(computeFinalSum(DoubleStream.of(rand).parallel().collect(doubleSupplier,objDoubleConsumer,badCollectorConsumer)) - sum[0], 2); > 86: > 87: Above, if there are going to be multiple uese of Math.pow(arg, 2) in the test, I recommend defining a local private static square(double d) method for this test where square is double square(double arg) {return arg * arg;} The library method pow(arg, 2) does a check for the exponent being two and does a multiple instead. ------------- PR: https://git.openjdk.java.net/jdk/pull/5430 From jpai at openjdk.java.net Mon Sep 13 05:44:22 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Mon, 13 Sep 2021 05:44:22 GMT Subject: RFR: 8258117: jar tool sets the time stamp of module-info.class entries to the current time Message-ID: The commit here is a potential fix for the issue noted in https://bugs.openjdk.java.net/browse/JDK-8258117. The change here repurposes an existing internal interface `ModuleInfoEntry` to keep track of the last modified timestamp of a `module-info.class` descriptor. This commit uses the timestamp of the `module-info.class` on the filesystem to set the time on the `JarEntry`. There are a couple of cases to consider here: 1. When creating a jar (using `--create`), we use the source `module-info.class` from the filesystem and then add extended info to it (attributes like packages, module version etc...). In such cases, this patch will use the lastmodified timestamp from the filesystem of `module-info.class` even though we might end up updating/extending/modifying (for example by adding a module version) its content while storing it as a `JarEntry`. 2. When updating a jar (using `--update`), this patch will use the lastmodified timestamp of `module-info.class` either from the filesystem or from the source jar's entry (depending on whether a new `module-info.class` is being passed to the command). Here too, it's possible that we might end up changing/modifying/extending the `module-info.class` (for example, changing the module version to a new version) that gets written into the updated jar file, but this patch _won't_ use `System.currentTimeMillis()` even in such cases. If we do have to track actual changes that might happen to `module-info.class` while extending its info (in `extendedInfoBytes()`) and then decide whether to use current system time as last modified time, then this will require a bigger change and also a discussion on what kind of extending of module-info.class content will require a change to the lastmodifiedtime of that entry. ------------- Commit messages: - 8258117: jar tool sets the time stamp of module-info.class entries to the current time Changes: https://git.openjdk.java.net/jdk/pull/5486/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5486&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258117 Stats: 317 lines in 2 files changed: 298 ins; 0 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/5486.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5486/head:pull/5486 PR: https://git.openjdk.java.net/jdk/pull/5486 From plevart at openjdk.java.net Mon Sep 13 09:54:54 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Mon, 13 Sep 2021 09:54:54 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v8] In-Reply-To: <5V0eAcrG9rS-d9RnyC2oJ5kVo6v84IhyBn40M71mYUg=.5d8c17fe-a23b-49a8-bfef-f670c0f013eb@github.com> References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> <5V0eAcrG9rS-d9RnyC2oJ5kVo6v84IhyBn40M71mYUg=.5d8c17fe-a23b-49a8-bfef-f670c0f013eb@github.com> Message-ID: <6ckCSYt0UBCdrt330nvj7BYS8FTlV4UpcJ5ARMuBBeI=.28238820-8ac8-4abf-9789-71f0e5895438@github.com> On Wed, 1 Sep 2021 01:05:32 GMT, Mandy Chung wrote: >> This reimplements core reflection with method handles. >> >> For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. >> >> The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. >> >> The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. >> >> Ran tier1-tier8 tests. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8013527 >> [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > minor cleanup and more test case. Hi Mandy, I'm still looking at this great work and have a few questions that I want to ask upfront. I understand the need for hard-coded specialization as opposed to inserting more MH transformations. You want to squeeze the startup costs as much as possible. But what I would like to understand is the need for MHInvoker and generated implementations of that interface. I can see that by making the target MH a constant in such generated MHInvoker, JVM is able to optimize the MH invocation chain better when JIT kicks-in. So instead of holding the reference to a target MethodHandle in say DirectMethodHandleAccessor, you hold a reference to MHInvoker. You trade constant MH optimization for indirection to a non-constant MHInvoker instance (I see @Stable annotation there, but it would only be effective when the holder MethodAccessor instance was also constant which unfortunately isn't as it is held by a volatile field in Method so even if Method was constant, its MethodAccessor would not be). So my question is whether this trade pays off. I wonder what the performance would be if: - MHInvoker was eliminated - the DirectMethodHandleAccessor just used the target MH directly (via @Stable field) but still using hard-coded specializations - AdaptiveMethodHandleAccessor would not be needed then - the Method had @Stable reference to MethodAccessor instead of volatile (data races are used everywhere so why not for this field too?) I guess you already tried this approach and later added MHInvoker "middleman" to optimize the warmed-up performance. If not, I can try that variant and come up with benchmark results to compare... ------------- PR: https://git.openjdk.java.net/jdk/pull/5027 From egahlin at openjdk.java.net Mon Sep 13 11:03:08 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Mon, 13 Sep 2021 11:03:08 GMT Subject: RFR: 8272515: JFR: Names should only be valid Java identifiers Message-ID: Hi, Could I have a review of change that prevents invalid Java identifiers or type names in JFR events. For rationale and compatibility issues see the CSR request. The only change to java.base is making jdk.modules.internal.Checks::isJavaIdentifier(String) public, so it can be reused by the jdk.jfr module. Testing: /jdk/jdk/jfr + tier1 + tier2 Thanks Erik ------------- Commit messages: - Improve guard against invalid type - Remove unused imports - Initial Changes: https://git.openjdk.java.net/jdk/pull/5415/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5415&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272515 Stats: 308 lines in 11 files changed: 259 ins; 23 del; 26 mod Patch: https://git.openjdk.java.net/jdk/pull/5415.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5415/head:pull/5415 PR: https://git.openjdk.java.net/jdk/pull/5415 From mgronlun at openjdk.java.net Mon Sep 13 11:04:58 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 13 Sep 2021 11:04:58 GMT Subject: RFR: 8266936: Add a finalization JFR event [v10] In-Reply-To: References: Message-ID: On Wed, 8 Sep 2021 17:37:20 GMT, Coleen Phillimore wrote: >> Markus Gr?nlund has updated the pull request incrementally with three additional commits since the last revision: >> >> - localize >> - cleanup >> - FinalizerStatistics > > src/hotspot/share/services/classLoadingService.cpp line 80: > >> 78: >> 79: size_t ClassLoadingService::compute_class_size(InstanceKlass* k) { >> 80: // lifted from ClassStatistics.do_class(Klass* k) > > Can you remove this line? I think that function is gone now. Thanks Coleen for taking a look at this. It is used internally by notify_class_loaded() and notify_class_unloaded(); therefore I will change it to have internal linkage. > src/hotspot/share/services/finalizerService.cpp line 44: > >> 42: _ik(ik), >> 43: _objects_on_heap(0), >> 44: _total_finalizers_run(0) {} > > Is this hashtable for every InstanceKlass that defines a finalizer? How many are there generally? Why couldn't this be a simple hashtable like ResourceHashtable (soon to be renamed) which you can write in only a few lines of code? This hashtable holds a FinalizerEntry for every InstanceKlass that provides a non-empty finalizer method and have allocated at least one object. How many there are in general depends on the application. A ResourceHashtable does not have the concurrency property required, as lookups and inserts will happen as part of object allocation. > src/hotspot/share/services/finalizerService.cpp line 114: > >> 112: >> 113: static inline void added() { >> 114: set_atomic(&_count); > > Why isn't Atomic::inc() good enough here? It's used everywhere else. Our Atomic implementation does not support CAS of a 64-bit value on 32-bit platforms (compiles but does not link). > src/hotspot/share/services/finalizerService.cpp line 123: > >> 121: static inline uintx hash_function(const InstanceKlass* ik) { >> 122: assert(ik != nullptr, "invariant"); >> 123: return primitive_hash(ik); > > If the hash function is primitive_hash, this hash is good enough to not need rehashing. The only reason for the rehashing for symbol and string table was that the char* had a dumb hash that was faster but could be hacked, so it needed to become a different hashcode. This doesn't need rehashing. Thank you for pointing that out. I had assumed this to be a part of the syntactic contract for using the ConcurrentHashTable. My wrong assumption was because the SymbolTable (which I used as a model) seemed to pass a "rehash_warning" bool to the accessor APIs (get, insert). However, looking more closely at the signatures in ConcurrentHashTable, that bool is a "grow_hint", not "rehash" specifically. Thanks again; I will remove the rehash support code. > src/hotspot/share/services/finalizerService.cpp line 485: > >> 483: void FinalizerService::purge_unloaded() { >> 484: assert_locked_or_safepoint(ClassLoaderDataGraph_lock); >> 485: ClassLoaderDataGraph::classes_unloading_do(&on_unloading); > > Since you remove entries on unloading, I don't see any reason to have any concurrent cleanup. > You do however need in the lookup code, some code that doesn't find the InstanceKlass if !ik->is_loader_alive() "Since you remove entries on unloading, I don't see any reason to have any concurrent cleanup." Thank you, that is true. The only concurrent work required will be to grow the table. "You do however need in the lookup code, some code that doesn't find the InstanceKlass if !ik->is_loader_alive()" A precondition is that the code doing the lookup hold the ClassLoaderDataGraph_lock or is at a safepoint. Is that still the case? Would not purge_unloaded() take out the InstanceKlass from the table, as part of unloading, before !ik->is_loader_alive() is published to the outside world? ------------- PR: https://git.openjdk.java.net/jdk/pull/4731 From github.com+10835776+stsypanov at openjdk.java.net Mon Sep 13 11:15:02 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 13 Sep 2021 11:15:02 GMT Subject: RFR: 8273656: Improve java.lang.invoke.MethodType.parameterList() and its usage Message-ID: Currently the method is implemented like public List> parameterList() { return Collections.unmodifiableList(Arrays.asList(ptypes.clone())); } This seems to be excessive, as three objects are allocated here. Instead we can use `List.of(ptypes)` which doesn't allocate anything for empty array and for one of length 1 and 2 it allocates lightweight objects with 2 fields, still copying longer arrays. This is likely to be fruitful as most of methods have 0-2 parameters. Also there is a couple of cases when `MethodType.parameterLis()` is called to get its size, which is excessive either as we can use `MethodType.parameterCount()` instead. ------------- Commit messages: - 8273656: Improve java.lang.invoke.MethodType.parameterList() and its usage Changes: https://git.openjdk.java.net/jdk/pull/5489/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5489&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273656 Stats: 7 lines in 2 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/5489.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5489/head:pull/5489 PR: https://git.openjdk.java.net/jdk/pull/5489 From prappo at openjdk.java.net Mon Sep 13 11:22:27 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Mon, 13 Sep 2021 11:22:27 GMT Subject: RFR: 8273616: Fix trivial doc typos in the java.base module [v3] In-Reply-To: References: Message-ID: <-FYpghxAFYk15OireziuPEkSxKJUSndwl70Ti2HDUUk=.3062ce6e-2d19-48ff-91c8-02640ca6f39a@github.com> > 8273616: Fix trivial doc typos in the java.base module Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: Use "ensure" instead of "insure" ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5475/files - new: https://git.openjdk.java.net/jdk/pull/5475/files/9a9deee1..4b33fb94 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5475&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5475&range=01-02 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5475.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5475/head:pull/5475 PR: https://git.openjdk.java.net/jdk/pull/5475 From prappo at openjdk.java.net Mon Sep 13 11:22:30 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Mon, 13 Sep 2021 11:22:30 GMT Subject: RFR: 8273616: Fix trivial doc typos in the java.base module [v2] In-Reply-To: References: Message-ID: On Fri, 10 Sep 2021 23:20:11 GMT, Pavel Rappo wrote: >> 8273616: Fix trivial doc typos in the java.base module > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Revert two fixes Thanks to those who reviewed this PR. Since I posted it, I've found three more occurrences of _insure_ used in the sense of _ensure_: two in the `java.io.Object*Stream` area and one in the `java.util.Currency` class. I decided to fix those in this PR, which now needs to be (re)reviewed. Thanks! There are more occurrences of _insure_, which I didn't touch. Some of them are in java.sql, java.sql.rowset and java.desktop. In the latter, _insure_ even crept into method names. ------------- PR: https://git.openjdk.java.net/jdk/pull/5475 From dfuchs at openjdk.java.net Mon Sep 13 13:11:57 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Mon, 13 Sep 2021 13:11:57 GMT Subject: RFR: 8273616: Fix trivial doc typos in the java.base module [v3] In-Reply-To: <-FYpghxAFYk15OireziuPEkSxKJUSndwl70Ti2HDUUk=.3062ce6e-2d19-48ff-91c8-02640ca6f39a@github.com> References: <-FYpghxAFYk15OireziuPEkSxKJUSndwl70Ti2HDUUk=.3062ce6e-2d19-48ff-91c8-02640ca6f39a@github.com> Message-ID: On Mon, 13 Sep 2021 11:22:27 GMT, Pavel Rappo wrote: >> 8273616: Fix trivial doc typos in the java.base module > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Use "ensure" instead of "insure" LGTM ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5475 From jvernee at openjdk.java.net Mon Sep 13 13:34:10 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 13 Sep 2021 13:34:10 GMT Subject: RFR: 8273656: Improve java.lang.invoke.MethodType.parameterList() and its usage In-Reply-To: References: Message-ID: On Mon, 13 Sep 2021 11:06:15 GMT, ?????? ??????? wrote: > Currently the method is implemented like > > public List> parameterList() { > return Collections.unmodifiableList(Arrays.asList(ptypes.clone())); > } > > This seems to be excessive, as three objects are allocated here. Instead we can use `List.of(ptypes)` which doesn't allocate anything for empty array and for one of length 1 and 2 it allocates lightweight objects with 2 fields, still copying longer arrays. This is likely to be fruitful as most of methods have 0-2 parameters. > > Also there is a couple of cases when `MethodType.parameterLis()` is called to get its size, which is excessive either as we can use `MethodType.parameterCount()` instead. LGTM ------------- Marked as reviewed by jvernee (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5489 From rriggs at openjdk.java.net Mon Sep 13 13:34:08 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 13 Sep 2021 13:34:08 GMT Subject: RFR: 8273616: Fix trivial doc typos in the java.base module [v3] In-Reply-To: <-FYpghxAFYk15OireziuPEkSxKJUSndwl70Ti2HDUUk=.3062ce6e-2d19-48ff-91c8-02640ca6f39a@github.com> References: <-FYpghxAFYk15OireziuPEkSxKJUSndwl70Ti2HDUUk=.3062ce6e-2d19-48ff-91c8-02640ca6f39a@github.com> Message-ID: On Mon, 13 Sep 2021 11:22:27 GMT, Pavel Rappo wrote: >> 8273616: Fix trivial doc typos in the java.base module > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Use "ensure" instead of "insure" Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5475 From roger.riggs at oracle.com Mon Sep 13 13:43:24 2021 From: roger.riggs at oracle.com (Roger Riggs) Date: Mon, 13 Sep 2021 09:43:24 -0400 Subject: RFR: 8231640: (prop) Canonical property storage [v10] In-Reply-To: References: Message-ID: <89636de4-4c03-8a10-8097-be93b1a01c31@oracle.com> Hi Jaikiran, "Editing" the value of the comment property, to remove or ignore blanks for other special characters makes the code more complex and adds a bunch of conditions. Dropping the comment if it doesn't have the allowed format is hard to track down, because there's no way to report it was dropped or why. I would write the value of the comment property using the writeComments method so it is encoded the same as the other comment passed as an store argument. That will handle all special characters and multi-line comments.? It is simpler to specify and has the same predictable output as other comments. if the property is non-empty On 9/12/21 10:29 AM, Jaikiran Pai wrote: > ... > >> This was discussed elsewhere, but after writing that, I'm now >> thinking that we **should** honor the property even if it is blank. >> It would be useful to disable the timestamp simply by setting the >> property to the empty string; this will simply result in an empty >> comment line. This would simplify the code (and the spec) by removing >> conditions related to String::isBlank. > > OK. I don't see any obvious issues with interpreting > empty/whitespace-only value for the system property to translate to an > empty comment line. To be clear, an empty comment line that gets > written out in such cases is *always* going to be the "#" character > followed by a line separator right? Irrespective of what or how many > whitespace characters are present in the property value? Or do you > want those characters to be carried over into that comment line that > gets written out? The reason I ask this is because I think we should > always write just the "#" followed by the line separator character in > such cases, which effectively means we will still need the > String::isBlank check which would then look something like: > > if (propVal.isBlank()) { > ? bw.write("#"); > ? bw.newLine(); > } >> Side question: do we want to do any escaping or vetting of the >> property value? > > One of the reasons why we didn't want to use the date in epoch seconds > or a formatted date string was to avoid the complexities that come > with managing that property value. So a free-form property value > seemed more appropriate and I think a free-form value still seems > appropriate, but I think we should keep any vetting to minimal. More > details below. > >> If for example it contains embedded newlines, this could result in a >> malformed property file. Or, if carefully constructed, it could >> contain additional property values. I think this is an unintended >> consequence of changing the property value from a numeric time value >> to a free-form string. We may want to reconsider this. > > The specification on the load(Reader reader) method of the > java.util.Properties class has this to say about comment lines (and > lines in general). > > (snipped relevant content): > > ?? There are two kinds of line, natural lines and logical > ?? lines. > ?? A natural line is defined as a line of characters that is terminated > ?? either > ?? by a set of line terminator characters ({@code \n} or {@code \r} or > ?? {@code \r\n}) or by the end of the stream. A natural line may be > ?? either a blank line, a comment line, or hold all or some of a > ?? key-element pair. A logical > ?? line holds all the data of a key-element pair, which may be spread > ?? out across several adjacent natural lines by escaping > ?? the line terminator sequence with a backslash character > ?? {@code \}.? Note that a comment line cannot be extended > ?? in this manner; every natural line that is a comment must have > ?? its own comment indicator, as described below. > > > With that knowledge about comment lines, I think what we should do is > disallow system property values that contain any form of line > terminator characters (\n or \r or \r\n). If the system property value > is _not_ blank (as specified by String::isBlank) and contains any of > these line terminator characters, we should simply ignore it and write > out the current date as the date comment. That, IMO, should prevent > any of these sneaky/rogue value that can end up either creating > additional property key/values to be written out or causing any > malformed properties file. Plus, that would help us keep the vetting > to minimal without involving too much complexity. > >> src/java.base/share/classes/java/util/Properties.java line 855: >> >>> 853:????? * the value of this system property represents a formatted >>> 854:????? * date time value that can be parsed back into a {@link >>> Date} using an appropriate >>> 855:????? * {@link DateTimeFormatter} >> With the property behavior added to normative text above, I don't >> think we need this note anymore. We might want to leave something >> here about the convention of putting a timestamp here, and an >> implicit(?) requirement that it be formatted properly. > > The newly updated PR has updated this @implNote to remove some of the > previous text and yet retain some hints on what would be an "ideal" > value for the system property value. But I think we should perhaps > just get rid of this @implNote since we are now proposing to allow > empty comment lines and free form text and this no longer is a "let's > use this system property to allow users to specify a fixed date" > enhancement. good > > -Jaikiran > From jvernee at openjdk.java.net Mon Sep 13 14:46:09 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 13 Sep 2021 14:46:09 GMT Subject: RFR: 8273656: Improve java.lang.invoke.MethodType.parameterList() and its usage In-Reply-To: References: Message-ID: On Mon, 13 Sep 2021 11:06:15 GMT, ?????? ??????? wrote: > Currently the method is implemented like > > public List> parameterList() { > return Collections.unmodifiableList(Arrays.asList(ptypes.clone())); > } > > This seems to be excessive, as three objects are allocated here. Instead we can use `List.of(ptypes)` which doesn't allocate anything for empty array and for one of length 1 and 2 it allocates lightweight objects with 2 fields, still copying longer arrays. This is likely to be fruitful as most of methods have 0-2 parameters. > > Also there is a couple of cases when `MethodType.parameterLis()` is called to get its size, which is excessive either as we can use `MethodType.parameterCount()` instead. I'm also running a test job for this change. If that comes back green I'll sponsor the PR after the 24 hour review period (in case anybody else wants to comment). ------------- PR: https://git.openjdk.java.net/jdk/pull/5489 From iris at openjdk.java.net Mon Sep 13 15:16:54 2021 From: iris at openjdk.java.net (Iris Clark) Date: Mon, 13 Sep 2021 15:16:54 GMT Subject: RFR: 8273616: Fix trivial doc typos in the java.base module [v3] In-Reply-To: <-FYpghxAFYk15OireziuPEkSxKJUSndwl70Ti2HDUUk=.3062ce6e-2d19-48ff-91c8-02640ca6f39a@github.com> References: <-FYpghxAFYk15OireziuPEkSxKJUSndwl70Ti2HDUUk=.3062ce6e-2d19-48ff-91c8-02640ca6f39a@github.com> Message-ID: On Mon, 13 Sep 2021 11:22:27 GMT, Pavel Rappo wrote: >> 8273616: Fix trivial doc typos in the java.base module > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Use "ensure" instead of "insure" Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5475 From naoto at openjdk.java.net Mon Sep 13 16:10:03 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 13 Sep 2021 16:10:03 GMT Subject: Integrated: 8273259: Character.getName doesn't follow Unicode spec for ideographs In-Reply-To: <3ZOCioU8lMEPuWdaYlBv8L6oNdIwVjwZpPbKLWwkOjs=.0e8939c8-9cff-4600-a869-9c5f137fd2e5@github.com> References: <3ZOCioU8lMEPuWdaYlBv8L6oNdIwVjwZpPbKLWwkOjs=.0e8939c8-9cff-4600-a869-9c5f137fd2e5@github.com> Message-ID: On Thu, 2 Sep 2021 19:26:12 GMT, Naoto Sato wrote: > Simple spec clarification. A CSR has also been drafted (https://bugs.openjdk.java.net/browse/JDK-8273296). This pull request has now been integrated. Changeset: 4cfa230e Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/4cfa230e2daac118f21c7d8996d48a1a15d87a62 Stats: 21 lines in 1 file changed: 12 ins; 0 del; 9 mod 8273259: Character.getName doesn't follow Unicode spec for ideographs Reviewed-by: bpb, lancea, iris, darcy ------------- PR: https://git.openjdk.java.net/jdk/pull/5354 From lancea at openjdk.java.net Mon Sep 13 16:23:58 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 13 Sep 2021 16:23:58 GMT Subject: RFR: 8273616: Fix trivial doc typos in the java.base module [v3] In-Reply-To: <-FYpghxAFYk15OireziuPEkSxKJUSndwl70Ti2HDUUk=.3062ce6e-2d19-48ff-91c8-02640ca6f39a@github.com> References: <-FYpghxAFYk15OireziuPEkSxKJUSndwl70Ti2HDUUk=.3062ce6e-2d19-48ff-91c8-02640ca6f39a@github.com> Message-ID: <7B5F0eR1t3Y3RrxNeDG8VxLJpO4JVD-cXFBY5YbEErw=.8f5679bf-98cf-4670-97bb-b58c64ce1147@github.com> On Mon, 13 Sep 2021 11:22:27 GMT, Pavel Rappo wrote: >> 8273616: Fix trivial doc typos in the java.base module > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Use "ensure" instead of "insure" Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5475 From igraves at openjdk.java.net Mon Sep 13 16:28:15 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Mon, 13 Sep 2021 16:28:15 GMT Subject: RFR: 8273514: java/util/DoubleStreamSums/CompensatedSums.java failure [v3] In-Reply-To: References: Message-ID: <9XqusZqU_RWhKyQxiMSjxX3HR9mpMYxBrGcuZB4BbGo=.dd67721b-9c7c-45c2-8e3e-51ead3ff5b82@github.com> > Relaxing some assertion bounds to allow for small error values that still show improvement over previous summation method. Ian Graves has updated the pull request incrementally with one additional commit since the last revision: Factoring out Math.pow for squares ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5430/files - new: https://git.openjdk.java.net/jdk/pull/5430/files/8f77f3d3..bcd5892d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5430&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5430&range=01-02 Stats: 13 lines in 1 file changed: 4 ins; 3 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/5430.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5430/head:pull/5430 PR: https://git.openjdk.java.net/jdk/pull/5430 From igraves at openjdk.java.net Mon Sep 13 16:28:18 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Mon, 13 Sep 2021 16:28:18 GMT Subject: RFR: 8273514: java/util/DoubleStreamSums/CompensatedSums.java failure [v2] In-Reply-To: References: Message-ID: On Mon, 13 Sep 2021 00:08:20 GMT, Joe Darcy wrote: >> Ian Graves has updated the pull request incrementally with one additional commit since the last revision: >> >> Tweaking asserts > > test/jdk/java/util/DoubleStreamSums/CompensatedSums.java line 87: > >> 85: badParallelStreamError += Math.pow(computeFinalSum(DoubleStream.of(rand).parallel().collect(doubleSupplier,objDoubleConsumer,badCollectorConsumer)) - sum[0], 2); >> 86: >> 87: > > Above, if there are going to be multiple uese of Math.pow(arg, 2) in the test, I recommend defining a local private static square(double d) method for this test where square is > double square(double arg) {return arg * arg;} > The library method pow(arg, 2) does a check for the exponent being two and does a multiple instead. Good call. Done. ------------- PR: https://git.openjdk.java.net/jdk/pull/5430 From mchung at openjdk.java.net Mon Sep 13 16:45:00 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 13 Sep 2021 16:45:00 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v8] In-Reply-To: <5V0eAcrG9rS-d9RnyC2oJ5kVo6v84IhyBn40M71mYUg=.5d8c17fe-a23b-49a8-bfef-f670c0f013eb@github.com> References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> <5V0eAcrG9rS-d9RnyC2oJ5kVo6v84IhyBn40M71mYUg=.5d8c17fe-a23b-49a8-bfef-f670c0f013eb@github.com> Message-ID: <0Mo4IE_MgYHmU3VDiAkf_g0hdQB2M0P2e_X8gOrlfAc=.1f79e5ca-158c-4eb6-ad0c-bbf643025994@github.com> On Wed, 1 Sep 2021 01:05:32 GMT, Mandy Chung wrote: >> This reimplements core reflection with method handles. >> >> For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. >> >> The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. >> >> The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. >> >> Ran tier1-tier8 tests. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8013527 >> [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > minor cleanup and more test case. Hi Peter, I haven't tried the approach of making the Method @stable reference to MethodAccessor instead of volatile. This reminds me of your experiment [1] which I lost track of. It'd be good if you can try that approach and compare the benchmark results. [1] https://bugs.openjdk.java.net/browse/JDK-6824466?focusedCommentId=14212580&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14212580 ------------- PR: https://git.openjdk.java.net/jdk/pull/5027 From shade at openjdk.java.net Mon Sep 13 16:52:53 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 13 Sep 2021 16:52:53 GMT Subject: RFR: 8247980: Exclusive execution of java/util/stream tests slows down tier1 In-Reply-To: References: Message-ID: <9AmUjaY6ImMglo-rAt8B2xqLc9DT7yobImdjAXHOOSM=.720eee1c-f340-4b4b-8583-2e72642d4b00@github.com> On Thu, 19 Aug 2021 15:15:31 GMT, Aleksey Shipilev wrote: > See the bug report for more details. I would appreciate if people with their corporate testing systems would run this through their systems to avoid surprises. (ping @RealCLanger, @iignatev). @ArnoZeller, have your runs identify any problems with these tests? I wonder if we want to integrate this PR, and see if we see any problems going forward. If we do, and those problems look environmental or intrinsic to the tests, we can revert the patch. Thoughts? ------------- PR: https://git.openjdk.java.net/jdk/pull/5189 From mgronlun at openjdk.java.net Mon Sep 13 17:12:49 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 13 Sep 2021 17:12:49 GMT Subject: RFR: 8266936: Add a finalization JFR event [v11] In-Reply-To: References: Message-ID: <3hNX4mQ98TyLNDmCXO4hDz8EMDoQ4ukr1Y1bvX1k8kk=.cc67221c-258a-4cac-a368-09d5fe44f245@github.com> > Greetings, > > Object.finalize() was deprecated in JDK9. There is an ongoing effort to replace and mitigate Object.finalize() uses in the JDK libraries; please see https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. > > We also like to assist users in replacing and mitigating uses in non-JDK code. > > Hence, this changeset adds a periodic JFR event to help identify which classes are overriding Object.finalize(). > > Thanks > Markus Markus Gr?nlund has updated the pull request incrementally with two additional commits since the last revision: - remove rehashing and rely on default grow_hint for table resize - mtStatistics ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4731/files - new: https://git.openjdk.java.net/jdk/pull/4731/files/fd86899f..62592daf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=09-10 Stats: 258 lines in 6 files changed: 25 ins; 197 del; 36 mod Patch: https://git.openjdk.java.net/jdk/pull/4731.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4731/head:pull/4731 PR: https://git.openjdk.java.net/jdk/pull/4731 From jrose at openjdk.java.net Mon Sep 13 17:19:55 2021 From: jrose at openjdk.java.net (John R Rose) Date: Mon, 13 Sep 2021 17:19:55 GMT Subject: RFR: 8273616: Fix trivial doc typos in the java.base module [v3] In-Reply-To: <-FYpghxAFYk15OireziuPEkSxKJUSndwl70Ti2HDUUk=.3062ce6e-2d19-48ff-91c8-02640ca6f39a@github.com> References: <-FYpghxAFYk15OireziuPEkSxKJUSndwl70Ti2HDUUk=.3062ce6e-2d19-48ff-91c8-02640ca6f39a@github.com> Message-ID: On Mon, 13 Sep 2021 11:22:27 GMT, Pavel Rappo wrote: >> 8273616: Fix trivial doc typos in the java.base module > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Use "ensure" instead of "insure" Marked as reviewed by jrose (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5475 From vlivanov at openjdk.java.net Mon Sep 13 17:24:52 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Mon, 13 Sep 2021 17:24:52 GMT Subject: RFR: 8273656: Improve java.lang.invoke.MethodType.parameterList() and its usage In-Reply-To: References: Message-ID: On Mon, 13 Sep 2021 11:06:15 GMT, ?????? ??????? wrote: > Currently the method is implemented like > > public List> parameterList() { > return Collections.unmodifiableList(Arrays.asList(ptypes.clone())); > } > > This seems to be excessive, as three objects are allocated here. Instead we can use `List.of(ptypes)` which doesn't allocate anything for empty array and for one of length 1 and 2 it allocates lightweight objects with 2 fields, still copying longer arrays. This is likely to be fruitful as most of methods have 0-2 parameters. > > Also there is a couple of cases when `MethodType.parameterLis()` is called to get its size, which is excessive either as we can use `MethodType.parameterCount()` instead. Looks good. BTW it can be improved even further by caching the immutable List view of parameters. ------------- Marked as reviewed by vlivanov (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5489 From mchung at openjdk.java.net Mon Sep 13 17:24:52 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 13 Sep 2021 17:24:52 GMT Subject: RFR: 8273656: Improve java.lang.invoke.MethodType.parameterList() and its usage In-Reply-To: References: Message-ID: <3588QVYXtO9_ljvTJDslM_ISduhuayiVkkPsf82lSas=.13cd8825-cf11-437f-abb3-949ed13f4a82@github.com> On Mon, 13 Sep 2021 11:06:15 GMT, ?????? ??????? wrote: > Currently the method is implemented like > > public List> parameterList() { > return Collections.unmodifiableList(Arrays.asList(ptypes.clone())); > } > > This seems to be excessive, as three objects are allocated here. Instead we can use `List.of(ptypes)` which doesn't allocate anything for empty array and for one of length 1 and 2 it allocates lightweight objects with 2 fields, still copying longer arrays. This is likely to be fruitful as most of methods have 0-2 parameters. > > Also there is a couple of cases when `MethodType.parameterLis()` is called to get its size, which is excessive either as we can use `MethodType.parameterCount()` instead. Looks good to me. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5489 From github.com+43264149+iaroslavski at openjdk.java.net Mon Sep 13 17:28:42 2021 From: github.com+43264149+iaroslavski at openjdk.java.net (iaroslavski) Date: Mon, 13 Sep 2021 17:28:42 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) Message-ID: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> Sorting: - adopt radix sort for sequential and parallel sorts on int/long/float/double arrays (almost random and length > 6K) - fix tryMergeRuns() to better handle case when the last run is a single element - minor javadoc and comment changes Testing: - add new data inputs in tests for sorting - add min/max/infinity values to float/double testing - add tests for radix sort ------------- Commit messages: - JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) - JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) - JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) Changes: https://git.openjdk.java.net/jdk/pull/3938/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3938&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266431 Stats: 889 lines in 3 files changed: 718 ins; 46 del; 125 mod Patch: https://git.openjdk.java.net/jdk/pull/3938.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3938/head:pull/3938 PR: https://git.openjdk.java.net/jdk/pull/3938 From lbourges at openjdk.java.net Mon Sep 13 17:28:43 2021 From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Mon, 13 Sep 2021 17:28:43 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) In-Reply-To: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> Message-ID: <75Nj_vbtmqUEj1XoUw9i3kTL140mcy6mZEmHyLyHa0U=.4eadfe72-2e17-4fa2-8f00-ba36f2c46305@github.com> On Sat, 8 May 2021 20:54:48 GMT, iaroslavski wrote: > Sorting: > > - adopt radix sort for sequential and parallel sorts on int/long/float/double arrays (almost random and length > 6K) > - fix tryMergeRuns() to better handle case when the last run is a single element > - minor javadoc and comment changes > > Testing: > - add new data inputs in tests for sorting > - add min/max/infinity values to float/double testing > - add tests for radix sort Congratulation, what an amazing job ! DPQS is now 50% faster in average but 2.5 times faster (rms) my favorite !! Finally OOME is now handled to let sort work under low-mem conditions ! I will work on more benchmarks for long/float/double types. Laurent Still waiting for individual OCA approval src/java.base/share/classes/java/util/DualPivotQuicksort.java line 47: > 45: * @author Doug Lea > 46: * > 47: * @version 2020.06.14 Vladimir, I would update to 2021.05.06 (+your hash) src/java.base/share/classes/java/util/DualPivotQuicksort.java line 288: > 286: /* > 287: * Invoke radix sort on large array. > 288: */ I prefer testing (sorter == null) first as it is always true for sequential sort and avoid testing bits > ... in this case ------------- PR: https://git.openjdk.java.net/jdk/pull/3938 From github.com+43264149+iaroslavski at openjdk.java.net Mon Sep 13 17:28:43 2021 From: github.com+43264149+iaroslavski at openjdk.java.net (iaroslavski) Date: Mon, 13 Sep 2021 17:28:43 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) In-Reply-To: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> Message-ID: On Sat, 8 May 2021 20:54:48 GMT, iaroslavski wrote: > Sorting: > > - adopt radix sort for sequential and parallel sorts on int/long/float/double arrays (almost random and length > 6K) > - fix tryMergeRuns() to better handle case when the last run is a single element > - minor javadoc and comment changes > > Testing: > - add new data inputs in tests for sorting > - add min/max/infinity values to float/double testing > - add tests for radix sort Still waiting OCA approval Yes, I ping again, will see what happens ? >???????, 24 ???? 2021, 14:47 +03:00 ?? Laurent Bourg?s ***@***.***>: >? >? >Still waiting for individual OCA approval >? >You are receiving this because you were mentioned. >Reply to this email directly, view it on GitHub , or unsubscribe . Still waiting OCA approval ------------- PR: https://git.openjdk.java.net/jdk/pull/3938 From github.com+43264149+iaroslavski at openjdk.java.net Mon Sep 13 17:28:44 2021 From: github.com+43264149+iaroslavski at openjdk.java.net (iaroslavski) Date: Mon, 13 Sep 2021 17:28:44 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) In-Reply-To: <75Nj_vbtmqUEj1XoUw9i3kTL140mcy6mZEmHyLyHa0U=.4eadfe72-2e17-4fa2-8f00-ba36f2c46305@github.com> References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> <75Nj_vbtmqUEj1XoUw9i3kTL140mcy6mZEmHyLyHa0U=.4eadfe72-2e17-4fa2-8f00-ba36f2c46305@github.com> Message-ID: On Wed, 12 May 2021 11:36:09 GMT, Laurent Bourg?s wrote: >> Sorting: >> >> - adopt radix sort for sequential and parallel sorts on int/long/float/double arrays (almost random and length > 6K) >> - fix tryMergeRuns() to better handle case when the last run is a single element >> - minor javadoc and comment changes >> >> Testing: >> - add new data inputs in tests for sorting >> - add min/max/infinity values to float/double testing >> - add tests for radix sort > > src/java.base/share/classes/java/util/DualPivotQuicksort.java line 47: > >> 45: * @author Doug Lea >> 46: * >> 47: * @version 2020.06.14 > > Vladimir, I would update to 2021.05.06 (+your hash) Laurent, the date in this class is not the date of our last commit, this date is the date when I have final idea regarding to Radix sort, therefore, I prefer to keep 2020.06.14 > src/java.base/share/classes/java/util/DualPivotQuicksort.java line 288: > >> 286: /* >> 287: * Invoke radix sort on large array. >> 288: */ > > I prefer testing (sorter == null) first as it is always true for sequential sort and avoid testing bits > ... in this case It makes sense, I will update. ------------- PR: https://git.openjdk.java.net/jdk/pull/3938 From lbourges at openjdk.java.net Mon Sep 13 17:28:45 2021 From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Mon, 13 Sep 2021 17:28:45 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) In-Reply-To: References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> <75Nj_vbtmqUEj1XoUw9i3kTL140mcy6mZEmHyLyHa0U=.4eadfe72-2e17-4fa2-8f00-ba36f2c46305@github.com> Message-ID: On Wed, 12 May 2021 12:20:09 GMT, iaroslavski wrote: >> src/java.base/share/classes/java/util/DualPivotQuicksort.java line 47: >> >>> 45: * @author Doug Lea >>> 46: * >>> 47: * @version 2020.06.14 >> >> Vladimir, I would update to 2021.05.06 (+your hash) > > Laurent, the date in this class is not the date of our last commit, > this date is the date when I have final idea regarding to Radix sort, > therefore, I prefer to keep 2020.06.14 as you want, but you should maybe indicate which version corresponds to your master code too. It would help tracking changes between forks (iarosalvskiy/sorting master) ------------- PR: https://git.openjdk.java.net/jdk/pull/3938 From github.com+16439049+richardstartin at openjdk.java.net Mon Sep 13 17:28:45 2021 From: github.com+16439049+richardstartin at openjdk.java.net (Richard Startin) Date: Mon, 13 Sep 2021 17:28:45 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) In-Reply-To: References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> <75Nj_vbtmqUEj1XoUw9i3kTL140mcy6mZEmHyLyHa0U=.4eadfe72-2e17-4fa2-8f00-ba36f2c46305@github.com> Message-ID: <8zsz0oqYToH6u-FsIvYMrKxdJYG4AgftI9Fn5hC7v8E=.cf5db5a8-b69d-4e58-8ffd-ac86d6bd198f@github.com> On Wed, 12 May 2021 12:20:09 GMT, iaroslavski wrote: >> src/java.base/share/classes/java/util/DualPivotQuicksort.java line 47: >> >>> 45: * @author Doug Lea >>> 46: * >>> 47: * @version 2020.06.14 >> >> Vladimir, I would update to 2021.05.06 (+your hash) > > Laurent, the date in this class is not the date of our last commit, > this date is the date when I have final idea regarding to Radix sort, > therefore, I prefer to keep 2020.06.14 Hi @iaroslavski I'm unconvinced that this work was from 14/06/2020 - I believe this work derives from an unsigned radix sort I implemented on 10/04/2021 https://github.com/richardstartin/radix-sort-benchmark/commit/ab4da230e1d0ac68e5ee2cee38d71c7e7d50f49b#diff-6c13d3fb74f38906677dbfa1a70a123c8e5baf4a39219c81ef121e078d0013bcR226 which has numerous structural similarities to this work: * Producing all four histograms in one pass * Skipping passes based on detecting the total in the histogram * Bailing out of the skip detection if a nonzero value not equal to the total is encountered * Manually unrolling the LSD radix sort loop in order to avoid array copies My implementation from 10th April is below for reference: public static void unrollOnePassHistogramsSkipLevels(int[] data) { int[] histogram1 = new int[257]; int[] histogram2 = new int[257]; int[] histogram3 = new int[257]; int[] histogram4 = new int[257]; for (int value : data) { ++histogram1[(value & 0xFF) + 1]; ++histogram2[((value >>> 8) & 0xFF) + 1]; ++histogram3[((value >>> 16) & 0xFF) + 1]; ++histogram4[(value >>> 24) + 1]; } boolean skipLevel1 = canSkipLevel(histogram1, data.length); boolean skipLevel2 = canSkipLevel(histogram2, data.length); boolean skipLevel3 = canSkipLevel(histogram3, data.length); boolean skipLevel4 = canSkipLevel(histogram4, data.length); if (skipLevel1 && skipLevel2 && skipLevel3 && skipLevel4) { return; } int[] copy = new int[data.length]; int[] source = data; int[] dest = copy; if (!skipLevel1) { for (int i = 1; i < histogram1.length; ++i) { histogram1[i] += histogram1[i - 1]; } for (int value : source) { dest[histogram1[value & 0xFF]++] = value; } if (!skipLevel2 || !skipLevel3 || !skipLevel4) { int[] tmp = dest; dest = source; source = tmp; } } if (!skipLevel2) { for (int i = 1; i < histogram2.length; ++i) { histogram2[i] += histogram2[i - 1]; } for (int value : source) { dest[histogram2[(value >>> 8) & 0xFF]++] = value; } if (!skipLevel3 || !skipLevel4) { int[] tmp = dest; dest = source; source = tmp; } } if (!skipLevel3) { for (int i = 1; i < histogram3.length; ++i) { histogram3[i] += histogram3[i - 1]; } for (int value : data) { dest[histogram3[(value >>> 16) & 0xFF]++] = value; } if (!skipLevel4) { int[] tmp = dest; dest = source; source = tmp; } } if (!skipLevel4) { for (int i = 1; i < histogram4.length; ++i) { histogram4[i] += histogram4[i - 1]; } for (int value : source) { dest[histogram4[value >>> 24]++] = value; } } if (dest != data) { System.arraycopy(dest, 0, data, 0, data.length); } } private static boolean canSkipLevel(int[] histogram, int dataSize) { for (int count : histogram) { if (count == dataSize) { return true; } else if (count > 0) { return false; } } return true; } Moreover, @bourgesl forked my repository on 11/04/2021 and communicated with me about doing so. On 25/04/2021 there was a new implementation of `DualPivotQuicksort` with a signed radix sort but the same structural similarities, and with the same method and variable names in places https://github.com/bourgesl/radix-sort-benchmark/commit/90ff7e427da0fa49f374bff0241fb2487bd87bde#diff-397ce8fd791e2ce508cf9127201bc9ab46264cd2a79fd0487a63569f2e4b59b2R607-R609 // TODO add javadoc private static void radixSort(Sorter sorter, int[] a, int low, int high) { int[] b; // LBO: prealloc (high - low) +1 element: if (sorter == null || (b = sorter.b) == null || b.length < (high - low)) { // System.out.println("alloc b: " + (high - low)); b = new int[high - low]; } int[] count1, count2, count3, count4; if (sorter != null) { sorter.resetRadixBuffers(); count1 = sorter.count1; count2 = sorter.count2; count3 = sorter.count3; count4 = sorter.count4; } else { // System.out.println("alloc radix buffers(4x256)"); count1 = new int[256]; count2 = new int[256]; count3 = new int[256]; count4 = new int[256]; } for (int i = low; i < high; ++i) { --count1[ a[i] & 0xFF ]; --count2[(a[i] >>> 8) & 0xFF ]; --count3[(a[i] >>> 16) & 0xFF ]; --count4[(a[i] >>> 24) ^ 0x80 ]; } boolean skipLevel4 = canSkipLevel(count4, low - high); boolean skipLevel3 = skipLevel4 && canSkipLevel(count3, low - high); boolean skipLevel2 = skipLevel3 && canSkipLevel(count2, low - high); count1[255] += high; count2[255] += high; count3[255] += high; count4[255] += high; // 1 todo process LSD for (int i = 255; i > 0; --i) { count1[i - 1] += count1[i]; } for (int i = low; i < high; ++i) { b[count1[a[i] & 0xFF]++ - low] = a[i]; } if (skipLevel2) { System.arraycopy(b, 0, a, low, high - low); return; } // 2 for (int i = 255; i > 0; --i) { count2[i - 1] += count2[i]; } //for (int value : b) { // a[count2[(value >> 8) & 0xFF]++] = value; for (int i = low; i < high; ++i) { a[count2[(b[i] >> 8) & 0xFF]++] = b[i]; } if (skipLevel3) { return; } // 3 for (int i = 255; i > 0; --i) { count3[i - 1] += count3[i]; } for (int i = low; i < high; ++i) { b[count3[(a[i] >> 16) & 0xFF]++ - low] = a[i]; } if (skipLevel4) { System.arraycopy(b, 0, a, low, high - low); return; } // 4 for (int i = 255; i > 0; --i) { count4[i - 1] += count4[i]; } // for (int value : b) { // a[count4[ (value >>> 24) ^ 0x80]++] = value; for (int i = low; i < high; ++i) { a[count4[ (b[i] >>> 24) ^ 0x80]++] = b[i]; } } // TODO: add javadoc private static boolean canSkipLevel(int[] count, int total) { for (int c : count) { if (c == 0) { continue; } return c == total; } return true; } Later, the name of the method `canSkipLevel` changed to `skipByte`: https://github.com/bourgesl/radix-sort-benchmark/commit/a693b26b2e2c14cfeedf9c753c9d643096b0e38d#diff-397ce8fd791e2ce508cf9127201bc9ab46264cd2a79fd0487a63569f2e4b59b2R719 - this is the name of the method in the version of this sort you committed on 05/01/2021 https://github.com/richardstartin/sorting/commit/f076073b8b819a9687613903a164e3ed71821769#diff-4b4d68fc834c2ad12a9fb9d316a812221af7c398338ed2ee907d0a795e7aadafR601-R604 // TODO add javadoc // private static void radixSort(Sorter sorter, int[] a, int low, int high) { //System.out.println(" Radix !!!"); int[] count1 = new int[256]; int[] count2 = new int[256]; int[] count3 = new int[256]; int[] count4 = new int[256]; for (int i = low; i < high; ++i) { count1[ a[i] & 0xFF ]--; count2[(a[i] >>> 8) & 0xFF ]--; count3[(a[i] >>> 16) & 0xFF ]--; count4[(a[i] >>> 24) ^ 0x80 ]--; } boolean skipByte4 = skipByte(count4, low - high, high, true); boolean skipByte3 = skipByte(count3, low - high, high, skipByte4); boolean skipByte2 = skipByte(count2, low - high, high, skipByte3); boolean skipByte1 = skipByte(count1, low - high, high, skipByte2); if (skipByte1) { //Main.check(a, low, high - 1); // todo return; } // int xorA = Main.getXor(a, low, high); int[] b; int offset = low; if (sorter == null || (b = (int[]) sorter.b) == null) { b = new int[high - low]; } else { offset = sorter.offset; //System.out.println(" !!!! offset: " + offset); } int start = low - offset; int last = high - offset; // 1 todo process LSD for (int i = low; i < high; ++i) { b[count1[a[i] & 0xFF]++ - offset] = a[i]; } // if (xorA != Main.getXor(a, low, high)) System.out.println("6K_4 1 xor changed"); if (skipByte2) { System.arraycopy(b, start, a, low, high - low); //Main.check(a, low, high - 1); // todo return; } // 2 for (int i = start; i < last; ++i) { a[count2[(b[i] >> 8) & 0xFF]++] = b[i]; } // if (xorA != Main.getXor(a, low, high)) System.out.println("6K_4 2 xor changed"); if (skipByte3) { //Main.check(a, low, high - 1); // todo return; } // 3 for (int i = low; i < high; ++i) { b[count3[(a[i] >> 16) & 0xFF]++ - offset] = a[i]; } // if (xorA != Main.getXor(a, low, high)) System.out.println("6K_4 3 xor changed"); if (skipByte4) { System.arraycopy(b, start, a, low, high - low); //Main.check(a, low, high - 1); // todo return; } // if (xorA != Main.getXor(a, low, high)) System.out.println("6K_4 4 xor changed"); // 4 for (int i = start; i < last; ++i) { a[count4[(b[i] >>> 24) ^ 0x80]++] = b[i]; } // if (xorA != Main.getXor(a, low, high)) System.out.println("6K_4 5 xor changed"); //Main.check(a, low, high - 1); // todo } // TODO: add javadoc private static boolean skipByte(int[] count, int total, int high, boolean prevSkip) { if (prevSkip) { for (int c : count) { if (c == 0) { continue; } if (c == total) { return true; } break; } } // todo create historgam count[255] += high; for (int i = 255; i > 0; --i) { count[i - 1] += count[i]; } return false; } `skipByte` was later renamed to `passLevel` here, which is the name used in this PR: https://github.com/richardstartin/sorting/commit/22357e407d3ae7a1e159e06fe4afbb2c57f7d34c#diff-4b4d68fc834c2ad12a9fb9d316a812221af7c398338ed2ee907d0a795e7aadaf Given the structural similarities mentioned, the chronological order of these commits, and the demonstrable provenance of the method name `passLevel` from `canSkipLevel` and since you have patented sort algorithms in the past, I want to make sure that it is recognised that this work is derived from my own. ------------- PR: https://git.openjdk.java.net/jdk/pull/3938 From lbourges at openjdk.java.net Mon Sep 13 17:28:45 2021 From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Mon, 13 Sep 2021 17:28:45 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) In-Reply-To: <8zsz0oqYToH6u-FsIvYMrKxdJYG4AgftI9Fn5hC7v8E=.cf5db5a8-b69d-4e58-8ffd-ac86d6bd198f@github.com> References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> <75Nj_vbtmqUEj1XoUw9i3kTL140mcy6mZEmHyLyHa0U=.4eadfe72-2e17-4fa2-8f00-ba36f2c46305@github.com> <8zsz0oqYToH6u-FsIvYMrKxdJYG4AgftI9Fn5hC7v8E=.cf5db5a8-b69d-4e58-8ffd-ac86d6bd198f@github.com> Message-ID: On Thu, 13 May 2021 09:53:37 GMT, Richard Startin wrote: >> Laurent, the date in this class is not the date of our last commit, >> this date is the date when I have final idea regarding to Radix sort, >> therefore, I prefer to keep 2020.06.14 > > Hi @iaroslavski I'm unconvinced that this work was from 14/06/2020 - I believe this work derives from an unsigned radix sort I implemented on 10/04/2021 https://github.com/richardstartin/radix-sort-benchmark/commit/ab4da230e1d0ac68e5ee2cee38d71c7e7d50f49b#diff-6c13d3fb74f38906677dbfa1a70a123c8e5baf4a39219c81ef121e078d0013bcR226 which has numerous structural similarities to this work: > * Producing all four histograms in one pass > * Skipping passes based on detecting the total in the histogram > * Bailing out of the skip detection if a nonzero value not equal to the total is encountered > * Manually unrolling the LSD radix sort loop in order to avoid array copies > > My implementation from 10th April is below for reference: > > public static void unrollOnePassHistogramsSkipLevels(int[] data) { > int[] histogram1 = new int[257]; > int[] histogram2 = new int[257]; > int[] histogram3 = new int[257]; > int[] histogram4 = new int[257]; > > for (int value : data) { > ++histogram1[(value & 0xFF) + 1]; > ++histogram2[((value >>> 8) & 0xFF) + 1]; > ++histogram3[((value >>> 16) & 0xFF) + 1]; > ++histogram4[(value >>> 24) + 1]; > } > boolean skipLevel1 = canSkipLevel(histogram1, data.length); > boolean skipLevel2 = canSkipLevel(histogram2, data.length); > boolean skipLevel3 = canSkipLevel(histogram3, data.length); > boolean skipLevel4 = canSkipLevel(histogram4, data.length); > > if (skipLevel1 && skipLevel2 && skipLevel3 && skipLevel4) { > return; > } > int[] copy = new int[data.length]; > > int[] source = data; > int[] dest = copy; > > if (!skipLevel1) { > for (int i = 1; i < histogram1.length; ++i) { > histogram1[i] += histogram1[i - 1]; > } > for (int value : source) { > dest[histogram1[value & 0xFF]++] = value; > } > if (!skipLevel2 || !skipLevel3 || !skipLevel4) { > int[] tmp = dest; > dest = source; > source = tmp; > } > } > > if (!skipLevel2) { > for (int i = 1; i < histogram2.length; ++i) { > histogram2[i] += histogram2[i - 1]; > } > for (int value : source) { > dest[histogram2[(value >>> 8) & 0xFF]++] = value; > } > if (!skipLevel3 || !skipLevel4) { > int[] tmp = dest; > dest = source; > source = tmp; > } > } > > if (!skipLevel3) { > for (int i = 1; i < histogram3.length; ++i) { > histogram3[i] += histogram3[i - 1]; > } > for (int value : data) { > dest[histogram3[(value >>> 16) & 0xFF]++] = value; > } > if (!skipLevel4) { > int[] tmp = dest; > dest = source; > source = tmp; > } > } > > if (!skipLevel4) { > for (int i = 1; i < histogram4.length; ++i) { > histogram4[i] += histogram4[i - 1]; > } > for (int value : source) { > dest[histogram4[value >>> 24]++] = value; > } > } > if (dest != data) { > System.arraycopy(dest, 0, data, 0, data.length); > } > } > > private static boolean canSkipLevel(int[] histogram, int dataSize) { > for (int count : histogram) { > if (count == dataSize) { > return true; > } else if (count > 0) { > return false; > } > } > return true; > } > > > Moreover, @bourgesl forked my repository on 11/04/2021 and communicated with me about doing so. On 25/04/2021 there was a new implementation of `DualPivotQuicksort` with a signed radix sort but the same structural similarities, and with the same method and variable names in places https://github.com/bourgesl/radix-sort-benchmark/commit/90ff7e427da0fa49f374bff0241fb2487bd87bde#diff-397ce8fd791e2ce508cf9127201bc9ab46264cd2a79fd0487a63569f2e4b59b2R607-R609 > > > // TODO add javadoc > private static void radixSort(Sorter sorter, int[] a, int low, int high) { > int[] b; > // LBO: prealloc (high - low) +1 element: > if (sorter == null || (b = sorter.b) == null || b.length < (high - low)) { > // System.out.println("alloc b: " + (high - low)); > b = new int[high - low]; > } > > int[] count1, count2, count3, count4; > if (sorter != null) { > sorter.resetRadixBuffers(); > count1 = sorter.count1; > count2 = sorter.count2; > count3 = sorter.count3; > count4 = sorter.count4; > } else { > // System.out.println("alloc radix buffers(4x256)"); > count1 = new int[256]; > count2 = new int[256]; > count3 = new int[256]; > count4 = new int[256]; > } > > for (int i = low; i < high; ++i) { > --count1[ a[i] & 0xFF ]; > --count2[(a[i] >>> 8) & 0xFF ]; > --count3[(a[i] >>> 16) & 0xFF ]; > --count4[(a[i] >>> 24) ^ 0x80 ]; > } > > boolean skipLevel4 = canSkipLevel(count4, low - high); > boolean skipLevel3 = skipLevel4 && canSkipLevel(count3, low - high); > boolean skipLevel2 = skipLevel3 && canSkipLevel(count2, low - high); > > count1[255] += high; > count2[255] += high; > count3[255] += high; > count4[255] += high; > > // 1 todo process LSD > for (int i = 255; i > 0; --i) { > count1[i - 1] += count1[i]; > } > > for (int i = low; i < high; ++i) { > b[count1[a[i] & 0xFF]++ - low] = a[i]; > } > > if (skipLevel2) { > System.arraycopy(b, 0, a, low, high - low); > return; > } > > // 2 > for (int i = 255; i > 0; --i) { > count2[i - 1] += count2[i]; > } > > //for (int value : b) { > // a[count2[(value >> 8) & 0xFF]++] = value; > for (int i = low; i < high; ++i) { > a[count2[(b[i] >> 8) & 0xFF]++] = b[i]; > } > > if (skipLevel3) { > return; > } > > // 3 > for (int i = 255; i > 0; --i) { > count3[i - 1] += count3[i]; > } > > for (int i = low; i < high; ++i) { > b[count3[(a[i] >> 16) & 0xFF]++ - low] = a[i]; > } > > if (skipLevel4) { > System.arraycopy(b, 0, a, low, high - low); > return; > } > > // 4 > for (int i = 255; i > 0; --i) { > count4[i - 1] += count4[i]; > } > > // for (int value : b) { > // a[count4[ (value >>> 24) ^ 0x80]++] = value; > for (int i = low; i < high; ++i) { > a[count4[ (b[i] >>> 24) ^ 0x80]++] = b[i]; > } > } > > // TODO: add javadoc > private static boolean canSkipLevel(int[] count, int total) { > for (int c : count) { > if (c == 0) { > continue; > } > return c == total; > } > return true; > } > > > Later, the name of the method `canSkipLevel` changed to `skipByte`: https://github.com/bourgesl/radix-sort-benchmark/commit/a693b26b2e2c14cfeedf9c753c9d643096b0e38d#diff-397ce8fd791e2ce508cf9127201bc9ab46264cd2a79fd0487a63569f2e4b59b2R719 - this is the name of the method in the version of this sort you committed on 05/01/2021 https://github.com/richardstartin/sorting/commit/f076073b8b819a9687613903a164e3ed71821769#diff-4b4d68fc834c2ad12a9fb9d316a812221af7c398338ed2ee907d0a795e7aadafR601-R604 > > > // TODO add javadoc > // private > static void radixSort(Sorter sorter, int[] a, int low, int high) { > //System.out.println(" Radix !!!"); > int[] count1 = new int[256]; > int[] count2 = new int[256]; > int[] count3 = new int[256]; > int[] count4 = new int[256]; > > for (int i = low; i < high; ++i) { > count1[ a[i] & 0xFF ]--; > count2[(a[i] >>> 8) & 0xFF ]--; > count3[(a[i] >>> 16) & 0xFF ]--; > count4[(a[i] >>> 24) ^ 0x80 ]--; > } > boolean skipByte4 = skipByte(count4, low - high, high, true); > boolean skipByte3 = skipByte(count3, low - high, high, skipByte4); > boolean skipByte2 = skipByte(count2, low - high, high, skipByte3); > boolean skipByte1 = skipByte(count1, low - high, high, skipByte2); > > if (skipByte1) { > //Main.check(a, low, high - 1); // todo > return; > } > // int xorA = Main.getXor(a, low, high); > > int[] b; int offset = low; > > if (sorter == null || (b = (int[]) sorter.b) == null) { > b = new int[high - low]; > } else { > offset = sorter.offset; > //System.out.println(" !!!! offset: " + offset); > } > int start = low - offset; > int last = high - offset; > > > // 1 todo process LSD > for (int i = low; i < high; ++i) { > b[count1[a[i] & 0xFF]++ - offset] = a[i]; > } > > // if (xorA != Main.getXor(a, low, high)) System.out.println("6K_4 1 xor changed"); > > if (skipByte2) { > System.arraycopy(b, start, a, low, high - low); > //Main.check(a, low, high - 1); // todo > return; > } > > // 2 > for (int i = start; i < last; ++i) { > a[count2[(b[i] >> 8) & 0xFF]++] = b[i]; > } > > // if (xorA != Main.getXor(a, low, high)) System.out.println("6K_4 2 xor changed"); > > if (skipByte3) { > //Main.check(a, low, high - 1); // todo > return; > } > > // 3 > for (int i = low; i < high; ++i) { > b[count3[(a[i] >> 16) & 0xFF]++ - offset] = a[i]; > } > > // if (xorA != Main.getXor(a, low, high)) System.out.println("6K_4 3 xor changed"); > > if (skipByte4) { > System.arraycopy(b, start, a, low, high - low); > //Main.check(a, low, high - 1); // todo > return; > } > > // if (xorA != Main.getXor(a, low, high)) System.out.println("6K_4 4 xor changed"); > // 4 > for (int i = start; i < last; ++i) { > a[count4[(b[i] >>> 24) ^ 0x80]++] = b[i]; > } > // if (xorA != Main.getXor(a, low, high)) System.out.println("6K_4 5 xor changed"); > //Main.check(a, low, high - 1); // todo > } > > // TODO: add javadoc > private static boolean skipByte(int[] count, int total, int high, boolean prevSkip) { > if (prevSkip) { > for (int c : count) { > if (c == 0) { > continue; > } > if (c == total) { > return true; > } > break; > } > } > // todo create historgam > count[255] += high; > > for (int i = 255; i > 0; --i) { > count[i - 1] += count[i]; > } > return false; > } > > > `skipByte` was later renamed to `passLevel` here, which is the name used in this PR: https://github.com/richardstartin/sorting/commit/22357e407d3ae7a1e159e06fe4afbb2c57f7d34c#diff-4b4d68fc834c2ad12a9fb9d316a812221af7c398338ed2ee907d0a795e7aadaf > > Given the structural similarities mentioned, the chronological order of these commits, and the demonstrable provenance of the method name `passLevel` from `canSkipLevel` and since you have patented sort algorithms in the past, I want to make sure that it is recognised that this work is derived from my own. You misunderstood my approach: - vladimir & tagir discussed radix sorts since previous work on DPQS in 2019 - I enjoyed reading your blog post testing the performance of your radix sort vs Arrays.sort() - I tested and forked your radix-sort-benchmark to reproduce your experiments on openjdk16 (dpqs 19.11) - Vladimir proposed his own radixsort() - I did port DPQS impls in my fork of your benchmark to make a global comparison: dpqs 11, 19, 21 vs yours + arrays.sort(): it helped comparing implementations and decide when radix sort wins depending on dataset presortness - I tried many variants on my github repositories, but Vladimir never merged any of my change as he is not a regular github user (clone, fork, merge). Our goal is not to underestimate your work (sort + benchmark) but Vladimir wrote his own code, me many experiments (tests, benchmarks) to obtain this original patch, written by Vladimir, with his radix sort implementation working on any int/long/float/double arrays, following the GPLv2 license. You gave me motivation to make Arrays.sort() faster and we worked hard to write, test and benchmark this patch to be ready for OpenJDK 17 ------------- PR: https://git.openjdk.java.net/jdk/pull/3938 From github.com+43264149+iaroslavski at openjdk.java.net Mon Sep 13 17:28:46 2021 From: github.com+43264149+iaroslavski at openjdk.java.net (iaroslavski) Date: Mon, 13 Sep 2021 17:28:46 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) In-Reply-To: <-exCZ7NcHfpt_xWuhuEsNxondubbjJQVaFmqn6jk79I=.0dae33f1-dbfd-4c07-a4ad-039070fdb62a@github.com> References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> <75Nj_vbtmqUEj1XoUw9i3kTL140mcy6mZEmHyLyHa0U=.4eadfe72-2e17-4fa2-8f00-ba36f2c46305@github.com> <8zsz0oqYToH6u-FsIvYMrKxdJYG4AgftI9Fn5hC7v8E=.cf5db5a8-b69d-4e58-8ffd-ac86d6bd198f@github.com> <-exCZ7NcHfpt_xWuhuEsNxondubbjJQVaFmqn6jk79I=.0dae33f1-dbfd-4c07-a4ad-039070fdb62a@github.com> Message-ID: On Thu, 13 May 2021 10:53:48 GMT, Richard Startin wrote: >> You misunderstood my approach: >> - vladimir & tagir discussed radix sorts since previous work on DPQS in 2019 >> - I enjoyed reading your blog post testing the performance of your radix sort vs Arrays.sort() >> - I tested and forked your radix-sort-benchmark to reproduce your experiments on openjdk16 (dpqs 19.11) >> - Vladimir proposed his own radixsort() >> - I did port DPQS impls in my fork of your benchmark to make a global comparison: dpqs 11, 19, 21 vs yours + arrays.sort(): it helped comparing implementations and decide when radix sort wins depending on dataset presortness >> - I tried many variants on my github repositories, but Vladimir never merged any of my change as he is not a regular github user (clone, fork, merge). >> >> Our goal is not to underestimate your work (sort + benchmark) but Vladimir wrote his own code, me many experiments (tests, benchmarks) to obtain this original patch, written by Vladimir, with his radix sort implementation working on any int/long/float/double arrays, following the GPLv2 license. >> >> You gave me motivation to make Arrays.sort() faster and we worked hard to write, test and benchmark this patch to be ready for OpenJDK 17 > > Perhaps we can resolve this issue in private - my email address is on my profile (or in the commits in `radix-sort-benchmark`)? @richardstartin The ideas to take 4 histograms at once or use check to skip digits are very simple and come not only from you, for example, see article from 2001, http://stereopsis.com/radix.html When Laurent and I discussed our Radix sort, your code was demonstrated. I wrote my implementation and at the first version I took the similar names (even not perfect for my cases) and later I renamed them to better values. You can see that from functional point of view your code and my code are different, they process skipped digits in different manner, No your code was copied. Date 2020.06.14 means the start of my activities on Radix sort, not final version. Let me know, if you have any questions @richardstartin And one more addon: my first version of Radix sort, see my github https://github.com/iaroslavski/sorting/tree/master/radixsort uses another name, like skipBytes, then renamed to passLevel. So, the common part is "skip". And this method has different number of parameters. I don't see any collision with your code. ------------- PR: https://git.openjdk.java.net/jdk/pull/3938 From github.com+16439049+richardstartin at openjdk.java.net Mon Sep 13 17:28:45 2021 From: github.com+16439049+richardstartin at openjdk.java.net (Richard Startin) Date: Mon, 13 Sep 2021 17:28:45 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) In-Reply-To: References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> <75Nj_vbtmqUEj1XoUw9i3kTL140mcy6mZEmHyLyHa0U=.4eadfe72-2e17-4fa2-8f00-ba36f2c46305@github.com> <8zsz0oqYToH6u-FsIvYMrKxdJYG4AgftI9Fn5hC7v8E=.cf5db5a8-b69d-4e58-8ffd-ac86d6bd198f@github.com> Message-ID: <-exCZ7NcHfpt_xWuhuEsNxondubbjJQVaFmqn6jk79I=.0dae33f1-dbfd-4c07-a4ad-039070fdb62a@github.com> On Thu, 13 May 2021 10:22:57 GMT, Laurent Bourg?s wrote: >> Hi @iaroslavski I'm unconvinced that this work was from 14/06/2020 - I believe this work derives from an unsigned radix sort I implemented on 10/04/2021 https://github.com/richardstartin/radix-sort-benchmark/commit/ab4da230e1d0ac68e5ee2cee38d71c7e7d50f49b#diff-6c13d3fb74f38906677dbfa1a70a123c8e5baf4a39219c81ef121e078d0013bcR226 which has numerous structural similarities to this work: >> * Producing all four histograms in one pass >> * Skipping passes based on detecting the total in the histogram >> * Bailing out of the skip detection if a nonzero value not equal to the total is encountered >> * Manually unrolling the LSD radix sort loop in order to avoid array copies >> >> My implementation from 10th April is below for reference: >> >> public static void unrollOnePassHistogramsSkipLevels(int[] data) { >> int[] histogram1 = new int[257]; >> int[] histogram2 = new int[257]; >> int[] histogram3 = new int[257]; >> int[] histogram4 = new int[257]; >> >> for (int value : data) { >> ++histogram1[(value & 0xFF) + 1]; >> ++histogram2[((value >>> 8) & 0xFF) + 1]; >> ++histogram3[((value >>> 16) & 0xFF) + 1]; >> ++histogram4[(value >>> 24) + 1]; >> } >> boolean skipLevel1 = canSkipLevel(histogram1, data.length); >> boolean skipLevel2 = canSkipLevel(histogram2, data.length); >> boolean skipLevel3 = canSkipLevel(histogram3, data.length); >> boolean skipLevel4 = canSkipLevel(histogram4, data.length); >> >> if (skipLevel1 && skipLevel2 && skipLevel3 && skipLevel4) { >> return; >> } >> int[] copy = new int[data.length]; >> >> int[] source = data; >> int[] dest = copy; >> >> if (!skipLevel1) { >> for (int i = 1; i < histogram1.length; ++i) { >> histogram1[i] += histogram1[i - 1]; >> } >> for (int value : source) { >> dest[histogram1[value & 0xFF]++] = value; >> } >> if (!skipLevel2 || !skipLevel3 || !skipLevel4) { >> int[] tmp = dest; >> dest = source; >> source = tmp; >> } >> } >> >> if (!skipLevel2) { >> for (int i = 1; i < histogram2.length; ++i) { >> histogram2[i] += histogram2[i - 1]; >> } >> for (int value : source) { >> dest[histogram2[(value >>> 8) & 0xFF]++] = value; >> } >> if (!skipLevel3 || !skipLevel4) { >> int[] tmp = dest; >> dest = source; >> source = tmp; >> } >> } >> >> if (!skipLevel3) { >> for (int i = 1; i < histogram3.length; ++i) { >> histogram3[i] += histogram3[i - 1]; >> } >> for (int value : data) { >> dest[histogram3[(value >>> 16) & 0xFF]++] = value; >> } >> if (!skipLevel4) { >> int[] tmp = dest; >> dest = source; >> source = tmp; >> } >> } >> >> if (!skipLevel4) { >> for (int i = 1; i < histogram4.length; ++i) { >> histogram4[i] += histogram4[i - 1]; >> } >> for (int value : source) { >> dest[histogram4[value >>> 24]++] = value; >> } >> } >> if (dest != data) { >> System.arraycopy(dest, 0, data, 0, data.length); >> } >> } >> >> private static boolean canSkipLevel(int[] histogram, int dataSize) { >> for (int count : histogram) { >> if (count == dataSize) { >> return true; >> } else if (count > 0) { >> return false; >> } >> } >> return true; >> } >> >> >> Moreover, @bourgesl forked my repository on 11/04/2021 and communicated with me about doing so. On 25/04/2021 there was a new implementation of `DualPivotQuicksort` with a signed radix sort but the same structural similarities, and with the same method and variable names in places https://github.com/bourgesl/radix-sort-benchmark/commit/90ff7e427da0fa49f374bff0241fb2487bd87bde#diff-397ce8fd791e2ce508cf9127201bc9ab46264cd2a79fd0487a63569f2e4b59b2R607-R609 >> >> >> // TODO add javadoc >> private static void radixSort(Sorter sorter, int[] a, int low, int high) { >> int[] b; >> // LBO: prealloc (high - low) +1 element: >> if (sorter == null || (b = sorter.b) == null || b.length < (high - low)) { >> // System.out.println("alloc b: " + (high - low)); >> b = new int[high - low]; >> } >> >> int[] count1, count2, count3, count4; >> if (sorter != null) { >> sorter.resetRadixBuffers(); >> count1 = sorter.count1; >> count2 = sorter.count2; >> count3 = sorter.count3; >> count4 = sorter.count4; >> } else { >> // System.out.println("alloc radix buffers(4x256)"); >> count1 = new int[256]; >> count2 = new int[256]; >> count3 = new int[256]; >> count4 = new int[256]; >> } >> >> for (int i = low; i < high; ++i) { >> --count1[ a[i] & 0xFF ]; >> --count2[(a[i] >>> 8) & 0xFF ]; >> --count3[(a[i] >>> 16) & 0xFF ]; >> --count4[(a[i] >>> 24) ^ 0x80 ]; >> } >> >> boolean skipLevel4 = canSkipLevel(count4, low - high); >> boolean skipLevel3 = skipLevel4 && canSkipLevel(count3, low - high); >> boolean skipLevel2 = skipLevel3 && canSkipLevel(count2, low - high); >> >> count1[255] += high; >> count2[255] += high; >> count3[255] += high; >> count4[255] += high; >> >> // 1 todo process LSD >> for (int i = 255; i > 0; --i) { >> count1[i - 1] += count1[i]; >> } >> >> for (int i = low; i < high; ++i) { >> b[count1[a[i] & 0xFF]++ - low] = a[i]; >> } >> >> if (skipLevel2) { >> System.arraycopy(b, 0, a, low, high - low); >> return; >> } >> >> // 2 >> for (int i = 255; i > 0; --i) { >> count2[i - 1] += count2[i]; >> } >> >> //for (int value : b) { >> // a[count2[(value >> 8) & 0xFF]++] = value; >> for (int i = low; i < high; ++i) { >> a[count2[(b[i] >> 8) & 0xFF]++] = b[i]; >> } >> >> if (skipLevel3) { >> return; >> } >> >> // 3 >> for (int i = 255; i > 0; --i) { >> count3[i - 1] += count3[i]; >> } >> >> for (int i = low; i < high; ++i) { >> b[count3[(a[i] >> 16) & 0xFF]++ - low] = a[i]; >> } >> >> if (skipLevel4) { >> System.arraycopy(b, 0, a, low, high - low); >> return; >> } >> >> // 4 >> for (int i = 255; i > 0; --i) { >> count4[i - 1] += count4[i]; >> } >> >> // for (int value : b) { >> // a[count4[ (value >>> 24) ^ 0x80]++] = value; >> for (int i = low; i < high; ++i) { >> a[count4[ (b[i] >>> 24) ^ 0x80]++] = b[i]; >> } >> } >> >> // TODO: add javadoc >> private static boolean canSkipLevel(int[] count, int total) { >> for (int c : count) { >> if (c == 0) { >> continue; >> } >> return c == total; >> } >> return true; >> } >> >> >> Later, the name of the method `canSkipLevel` changed to `skipByte`: https://github.com/bourgesl/radix-sort-benchmark/commit/a693b26b2e2c14cfeedf9c753c9d643096b0e38d#diff-397ce8fd791e2ce508cf9127201bc9ab46264cd2a79fd0487a63569f2e4b59b2R719 - this is the name of the method in the version of this sort you committed on 05/01/2021 https://github.com/richardstartin/sorting/commit/f076073b8b819a9687613903a164e3ed71821769#diff-4b4d68fc834c2ad12a9fb9d316a812221af7c398338ed2ee907d0a795e7aadafR601-R604 >> >> >> // TODO add javadoc >> // private >> static void radixSort(Sorter sorter, int[] a, int low, int high) { >> //System.out.println(" Radix !!!"); >> int[] count1 = new int[256]; >> int[] count2 = new int[256]; >> int[] count3 = new int[256]; >> int[] count4 = new int[256]; >> >> for (int i = low; i < high; ++i) { >> count1[ a[i] & 0xFF ]--; >> count2[(a[i] >>> 8) & 0xFF ]--; >> count3[(a[i] >>> 16) & 0xFF ]--; >> count4[(a[i] >>> 24) ^ 0x80 ]--; >> } >> boolean skipByte4 = skipByte(count4, low - high, high, true); >> boolean skipByte3 = skipByte(count3, low - high, high, skipByte4); >> boolean skipByte2 = skipByte(count2, low - high, high, skipByte3); >> boolean skipByte1 = skipByte(count1, low - high, high, skipByte2); >> >> if (skipByte1) { >> //Main.check(a, low, high - 1); // todo >> return; >> } >> // int xorA = Main.getXor(a, low, high); >> >> int[] b; int offset = low; >> >> if (sorter == null || (b = (int[]) sorter.b) == null) { >> b = new int[high - low]; >> } else { >> offset = sorter.offset; >> //System.out.println(" !!!! offset: " + offset); >> } >> int start = low - offset; >> int last = high - offset; >> >> >> // 1 todo process LSD >> for (int i = low; i < high; ++i) { >> b[count1[a[i] & 0xFF]++ - offset] = a[i]; >> } >> >> // if (xorA != Main.getXor(a, low, high)) System.out.println("6K_4 1 xor changed"); >> >> if (skipByte2) { >> System.arraycopy(b, start, a, low, high - low); >> //Main.check(a, low, high - 1); // todo >> return; >> } >> >> // 2 >> for (int i = start; i < last; ++i) { >> a[count2[(b[i] >> 8) & 0xFF]++] = b[i]; >> } >> >> // if (xorA != Main.getXor(a, low, high)) System.out.println("6K_4 2 xor changed"); >> >> if (skipByte3) { >> //Main.check(a, low, high - 1); // todo >> return; >> } >> >> // 3 >> for (int i = low; i < high; ++i) { >> b[count3[(a[i] >> 16) & 0xFF]++ - offset] = a[i]; >> } >> >> // if (xorA != Main.getXor(a, low, high)) System.out.println("6K_4 3 xor changed"); >> >> if (skipByte4) { >> System.arraycopy(b, start, a, low, high - low); >> //Main.check(a, low, high - 1); // todo >> return; >> } >> >> // if (xorA != Main.getXor(a, low, high)) System.out.println("6K_4 4 xor changed"); >> // 4 >> for (int i = start; i < last; ++i) { >> a[count4[(b[i] >>> 24) ^ 0x80]++] = b[i]; >> } >> // if (xorA != Main.getXor(a, low, high)) System.out.println("6K_4 5 xor changed"); >> //Main.check(a, low, high - 1); // todo >> } >> >> // TODO: add javadoc >> private static boolean skipByte(int[] count, int total, int high, boolean prevSkip) { >> if (prevSkip) { >> for (int c : count) { >> if (c == 0) { >> continue; >> } >> if (c == total) { >> return true; >> } >> break; >> } >> } >> // todo create historgam >> count[255] += high; >> >> for (int i = 255; i > 0; --i) { >> count[i - 1] += count[i]; >> } >> return false; >> } >> >> >> `skipByte` was later renamed to `passLevel` here, which is the name used in this PR: https://github.com/richardstartin/sorting/commit/22357e407d3ae7a1e159e06fe4afbb2c57f7d34c#diff-4b4d68fc834c2ad12a9fb9d316a812221af7c398338ed2ee907d0a795e7aadaf >> >> Given the structural similarities mentioned, the chronological order of these commits, and the demonstrable provenance of the method name `passLevel` from `canSkipLevel` and since you have patented sort algorithms in the past, I want to make sure that it is recognised that this work is derived from my own. > > You misunderstood my approach: > - vladimir & tagir discussed radix sorts since previous work on DPQS in 2019 > - I enjoyed reading your blog post testing the performance of your radix sort vs Arrays.sort() > - I tested and forked your radix-sort-benchmark to reproduce your experiments on openjdk16 (dpqs 19.11) > - Vladimir proposed his own radixsort() > - I did port DPQS impls in my fork of your benchmark to make a global comparison: dpqs 11, 19, 21 vs yours + arrays.sort(): it helped comparing implementations and decide when radix sort wins depending on dataset presortness > - I tried many variants on my github repositories, but Vladimir never merged any of my change as he is not a regular github user (clone, fork, merge). > > Our goal is not to underestimate your work (sort + benchmark) but Vladimir wrote his own code, me many experiments (tests, benchmarks) to obtain this original patch, written by Vladimir, with his radix sort implementation working on any int/long/float/double arrays, following the GPLv2 license. > > You gave me motivation to make Arrays.sort() faster and we worked hard to write, test and benchmark this patch to be ready for OpenJDK 17 Perhaps we can resolve this issue in private - my email address is on my profile (or in the commits in `radix-sort-benchmark`)? ------------- PR: https://git.openjdk.java.net/jdk/pull/3938 From github.com+16439049+richardstartin at openjdk.java.net Mon Sep 13 17:28:46 2021 From: github.com+16439049+richardstartin at openjdk.java.net (Richard Startin) Date: Mon, 13 Sep 2021 17:28:46 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) In-Reply-To: References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> <75Nj_vbtmqUEj1XoUw9i3kTL140mcy6mZEmHyLyHa0U=.4eadfe72-2e17-4fa2-8f00-ba36f2c46305@github.com> <8zsz0oqYToH6u-FsIvYMrKxdJYG4AgftI9Fn5hC7v8E=.cf5db5a8-b69d-4e58-8ffd-ac86d6bd198f@github.com> <-exCZ7NcHfpt_xWuhuEsNxondubbjJQVaFmqn6jk79I=.0dae33f1-dbfd-4c07-a4ad-039070fdb62a@github.com> Message-ID: On Thu, 13 May 2021 11:31:49 GMT, iaroslavski wrote: >> Perhaps we can resolve this issue in private - my email address is on my profile (or in the commits in `radix-sort-benchmark`)? > > @richardstartin And one more addon: my first version of Radix sort, see my github https://github.com/iaroslavski/sorting/tree/master/radixsort uses another name, like skipBytes, then renamed to passLevel. > So, the common part is "skip". And this method has different number of parameters. I don't see any collision with your code. @iaroslavski I would prefer to discuss this in private than here, but my argument is that the name `skipByte` came from Laurent's code, and that Laurent's code was clearly derived from my own within a fork of my repository. I linked the commits where you changed `skipByte` to `passLevel` and Laurent changed my name `canSkipLevel` to `skipByte`. For me, this raises questions about the independence of your work from Laurent's, and Laurent's work is clearly derived from my own (and I don't think anyone is disputing the latter). I would be happy to sort this out in private. ------------- PR: https://git.openjdk.java.net/jdk/pull/3938 From github.com+16439049+richardstartin at openjdk.java.net Mon Sep 13 17:28:46 2021 From: github.com+16439049+richardstartin at openjdk.java.net (Richard Startin) Date: Mon, 13 Sep 2021 17:28:46 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) In-Reply-To: References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> <75Nj_vbtmqUEj1XoUw9i3kTL140mcy6mZEmHyLyHa0U=.4eadfe72-2e17-4fa2-8f00-ba36f2c46305@github.com> <8zsz0oqYToH6u-FsIvYMrKxdJYG4AgftI9Fn5hC7v8E=.cf5db5a8-b69d-4e58-8ffd-ac86d6bd198f@github.com> <-exCZ7NcHfpt_xWuhuEsNxondubbjJQVaFmqn6jk79I=.0dae33f1-dbfd-4c07-a4ad-039070fdb62a@github.com> Message-ID: On Thu, 13 May 2021 11:47:58 GMT, Richard Startin wrote: >> @richardstartin And one more addon: my first version of Radix sort, see my github https://github.com/iaroslavski/sorting/tree/master/radixsort uses another name, like skipBytes, then renamed to passLevel. >> So, the common part is "skip". And this method has different number of parameters. I don't see any collision with your code. > > @iaroslavski I would prefer to discuss this in private than here, but my argument is that the name `skipByte` came from Laurent's code, and that Laurent's code was clearly derived from my own within a fork of my repository. I linked the commits where you changed `skipByte` to `passLevel` and Laurent changed my name `canSkipLevel` to `skipByte`. > > For me, this raises questions about the independence of your work from Laurent's, and Laurent's work is clearly derived from my own (and I don't think anyone is disputing the latter). I would be happy to sort this out in private. In private correspondence with Vladimir, it was explained that where Vladimir's code and Laurent's code are identical, including typos ([Vladimir's code](https://github.com/iaroslavski/sorting/commit/f076073b8b819a9687613903a164e3ed71821769#diff-4b4d68fc834c2ad12a9fb9d316a812221af7c398338ed2ee907d0a795e7aadafR672), [Laurent's code](https://github.com/bourgesl/radix-sort-benchmark/commit/a693b26b2e2c14cfeedf9c753c9d643096b0e38d#diff-397ce8fd791e2ce508cf9127201bc9ab46264cd2a79fd0487a63569f2e4b59b2R719)) it is because Vladimir sent the code to Laurent, not the other way around, therefore Vladimir's code does not derive from Laurent's, and it does not derive from mine. I can only trust that this is the case, so please disregard my claim that this is derivative work when reviewing this PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/3938 From github.com+16439049+richardstartin at openjdk.java.net Mon Sep 13 17:28:46 2021 From: github.com+16439049+richardstartin at openjdk.java.net (Richard Startin) Date: Mon, 13 Sep 2021 17:28:46 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) In-Reply-To: <2xNg3TOybhBILE2c7kj3NWIOUDQ8WgQgrCmzKnltx7E=.2997ae60-493f-462f-b54d-77c332cf5f90@github.com> References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> <75Nj_vbtmqUEj1XoUw9i3kTL140mcy6mZEmHyLyHa0U=.4eadfe72-2e17-4fa2-8f00-ba36f2c46305@github.com> <8zsz0oqYToH6u-FsIvYMrKxdJYG4AgftI9Fn5hC7v8E=.cf5db5a8-b69d-4e58-8ffd-ac86d6bd198f@github.com> <-exCZ7NcHfpt_xWuhuEsNxondubbjJQVaFmqn6jk79I=.0dae33f1-dbfd-4c07-a4ad-039070fdb62a@github.com> <2xNg3TOybhBILE2c7kj3NWIOUDQ8WgQgrCmzKnltx7E=.2997ae60-493f-462f-b54d-77c332cf5f90@github.com> Message-ID: On Thu, 13 May 2021 20:23:16 GMT, Richard Startin wrote: >> In private correspondence with Vladimir, it was explained that where Vladimir's code and Laurent's code are identical, including typos ([Vladimir's code](https://github.com/iaroslavski/sorting/commit/f076073b8b819a9687613903a164e3ed71821769#diff-4b4d68fc834c2ad12a9fb9d316a812221af7c398338ed2ee907d0a795e7aadafR672), [Laurent's code](https://github.com/bourgesl/radix-sort-benchmark/commit/a693b26b2e2c14cfeedf9c753c9d643096b0e38d#diff-397ce8fd791e2ce508cf9127201bc9ab46264cd2a79fd0487a63569f2e4b59b2R719)) it is because Vladimir sent the code to Laurent, not the other way around, therefore Vladimir's code does not derive from Laurent's, and it does not derive from mine. I can only trust that this is the case, so please disregard my claim that this is derivative work when reviewing this PR. > > For what it's worth, I benchmarked this implementation radix sort ([adapted here to fit in to my harness](https://github.com/richardstartin/radix-sort-benchmark/commit/07169e8e8602152cfda859baa159db165bf5fcab#diff-6c13d3fb74f38906677dbfa1a70a123c8e5baf4a39219c81ef121e078d0013bcR681-R710782)) against a [signed variant](https://github.com/richardstartin/radix-sort-benchmark/commit/07169e8e8602152cfda859baa159db165bf5fcab#diff-6c13d3fb74f38906677dbfa1a70a123c8e5baf4a39219c81ef121e078d0013bcR396-R478) of what I have claimed this work was derived from and the proposed implementation does not perform favourably on uniformly random data: > > > > Benchmark (bits) (padding) (scenario) (seed) (size) Mode Cnt Score Error Units > RadixSortBenchmark.jdk 17 7 UNIFORM 0 1000000 avgt 5 11301.950 ? 113.691 us/op > RadixSortBenchmark.jdk 23 7 UNIFORM 0 1000000 avgt 5 11792.351 ? 60.757 us/op > RadixSortBenchmark.jdk 30 7 UNIFORM 0 1000000 avgt 5 11184.616 ? 67.094 us/op > RadixSortBenchmark.unrollOnePassSkipLevelsSigned 17 7 UNIFORM 0 1000000 avgt 5 9564.626 ? 69.497 us/op > RadixSortBenchmark.unrollOnePassSkipLevelsSigned 23 7 UNIFORM 0 1000000 avgt 5 9432.085 ? 58.983 us/op > RadixSortBenchmark.unrollOnePassSkipLevelsSigned 30 7 UNIFORM 0 1000000 avgt 5 10772.975 ? 51.848 us/op > > > > I believe the root cause is a defect in the mechanism employed to skip passes as can be seen by the increased number of instructions and cycles here. In the proposed implementation, instructions is roughly constant as a function of bits. In the case where all passes must be performed (bits = 30), IPC is superior in `unrollOnePassHistogramsSkipLevelsSigned`. > > > Benchmark (bits) (padding) (scenario) (seed) (size) Mode Cnt Score Error Units > RadixSortBenchmark.jdk:cycles 17 7 UNIFORM 0 1000000 avgt 34976971.877 #/op > RadixSortBenchmark.jdk:instructions 17 7 UNIFORM 0 1000000 avgt 70121142.003 #/op > RadixSortBenchmark.jdk:cycles 23 7 UNIFORM 0 1000000 avgt 32369970.385 #/op > RadixSortBenchmark.jdk:instructions 23 7 UNIFORM 0 1000000 avgt 70201664.963 #/op > RadixSortBenchmark.jdk:cycles 30 7 UNIFORM 0 1000000 avgt 30789736.602 #/op > RadixSortBenchmark.jdk:instructions 30 7 UNIFORM 0 1000000 avgt 70180942.122 #/op > RadixSortBenchmark.jdk:IPC 30 7 UNIFORM 0 1000000 avgt 2.279 insns/clk > RadixSortBenchmark.unrollOnePassSkipLevelsSigned:cycles 17 7 UNIFORM 0 1000000 avgt 26983994.479 #/op > RadixSortBenchmark.unrollOnePassSkipLevelsSigned:instructions 17 7 UNIFORM 0 1000000 avgt 62065304.827 #/op > RadixSortBenchmark.unrollOnePassSkipLevelsSigned:cycles 23 7 UNIFORM 0 1000000 avgt 26161703.124 #/op > RadixSortBenchmark.unrollOnePassSkipLevelsSigned:instructions 23 7 UNIFORM 0 1000000 avgt 63102683.167 #/op > RadixSortBenchmark.unrollOnePassSkipLevelsSigned:cycles 30 7 UNIFORM 0 1000000 avgt 29780103.795 #/op > RadixSortBenchmark.unrollOnePassSkipLevelsSigned:instructions 30 7 UNIFORM 0 1000000 avgt 74437097.025 #/op > RadixSortBenchmark.unrollOnePassSkipLevelsSigned:IPC 30 7 UNIFORM 0 1000000 avgt 2.500 insns/clk > > > > The biggest difference in executed code appears to be that bounds checks are not eliminated in the first counting pass in the proposed implementation: > > > ....[Hottest Region 1].............................................................................. > c2, level 4, io.github.richardstartin.radixsort.RadixSort::jdk, version 402 (166 bytes) > > 0x00007f0d2fb20579: cmp $0x100,%r10d > 0x00007f0d2fb20580: jae 0x00007f0d2fb21344 > 0x00007f0d2fb20586: decl 0x10(%rdx,%r10,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} > ; - io.github.richardstartin.radixsort.RadixSort::jdk at 107 (line 697) > 0x00007f0d2fb2058b: cmp $0x1,%esi > 0x00007f0d2fb2058e: jle 0x00007f0d2fb2134c > 0x00007f0d2fb20594: mov $0x1,%r11d > 0x00007f0d2fb2059a: xor %ecx,%ecx > 0x00007f0d2fb2059c: nopl 0x0(%rax) ;*aload_2 {reexecute=0 rethrow=0 return_oop=0} > ; - io.github.richardstartin.radixsort.RadixSort::jdk at 41 (line 694) > 0.06% ? 0x00007f0d2fb205a0: movzbl 0x10(%rbp,%r11,4),%r10d ;*iand {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::jdk at 49 (line 694) > 0.18% ? 0x00007f0d2fb205a6: decl 0x10(%r8,%r10,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::jdk at 54 (line 694) > 1.37% ? 0x00007f0d2fb205ab: mov 0x10(%rbp,%r11,4),%r10d > 0.42% ? 0x00007f0d2fb205b0: shr $0x8,%r10d > 0.34% ? 0x00007f0d2fb205b4: movzbl %r10b,%r10d ;*iand {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::jdk at 66 (line 695) > 0.50% ? 0x00007f0d2fb205b8: decl 0x10(%r9,%r10,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::jdk at 71 (line 695) > 1.75% ? 0x00007f0d2fb205bd: mov 0x10(%rbp,%r11,4),%r10d > 0.42% ? 0x00007f0d2fb205c2: shr $0x10,%r10d > 0.12% ? 0x00007f0d2fb205c6: movzbl %r10b,%r10d ;*iand {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::jdk at 84 (line 696) > 0.36% ? 0x00007f0d2fb205ca: decl 0x10(%rbx,%r10,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::jdk at 89 (line 696) > 1.73% ? 0x00007f0d2fb205cf: mov 0x10(%rbp,%r11,4),%r10d > 0.26% ? 0x00007f0d2fb205d4: shr $0x18,%r10d > 0.38% ? 0x00007f0d2fb205d8: xor $0x80,%r10d ;*ixor {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::jdk at 102 (line 697) > 0.28% ? 0x00007f0d2fb205df: cmp $0x100,%r10d > ? 0x00007f0d2fb205e6: jae 0x00007f0d2fb20bab > 0.38% ? 0x00007f0d2fb205ec: decl 0x10(%rdx,%r10,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::jdk at 107 (line 697) > 1.25% ? 0x00007f0d2fb205f1: movzbl 0x14(%rbp,%r11,4),%r10d ;*iand {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::jdk at 49 (line 694) > 1.63% ? 0x00007f0d2fb205f7: decl 0x10(%r8,%r10,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::jdk at 54 (line 694) > 1.71% ? 0x00007f0d2fb205fc: mov 0x14(%rbp,%r11,4),%r10d > 0.16% ? 0x00007f0d2fb20601: shr $0x8,%r10d > 0.18% ? 0x00007f0d2fb20605: movzbl %r10b,%r10d ;*iand {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::jdk at 66 (line 695) > 0.36% ? 0x00007f0d2fb20609: decl 0x10(%r9,%r10,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::jdk at 71 (line 695) > 2.05% ? 0x00007f0d2fb2060e: mov 0x14(%rbp,%r11,4),%r10d > 0.14% ? 0x00007f0d2fb20613: shr $0x10,%r10d > 0.38% ? 0x00007f0d2fb20617: movzbl %r10b,%r10d ;*iand {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::jdk at 84 (line 696) > 0.14% ? 0x00007f0d2fb2061b: decl 0x10(%rbx,%r10,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::jdk at 89 (line 696) > 1.51% ? 0x00007f0d2fb20620: mov 0x14(%rbp,%r11,4),%r10d > 0.14% ? 0x00007f0d2fb20625: shr $0x18,%r10d > 0.32% ? 0x00007f0d2fb20629: xor $0x80,%r10d ;*ixor {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::jdk at 102 (line 697) > 0.12% ? 0x00007f0d2fb20630: cmp $0x100,%r10d > ? 0x00007f0d2fb20637: jae 0x00007f0d2fb20ba8 > 0.78% ? 0x00007f0d2fb2063d: decl 0x10(%rdx,%r10,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::jdk at 107 (line 697) > 1.04% ? 0x00007f0d2fb20642: add $0x2,%r11d ;*iinc {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::jdk at 108 (line 693) > 0.64% ? 0x00007f0d2fb20646: cmp %esi,%r11d > ? 0x00007f0d2fb20649: jl 0x00007f0d2fb205a0 ;*if_icmpge {reexecute=0 rethrow=0 return_oop=0} > ; - io.github.richardstartin.radixsort.RadixSort::jdk at 38 (line 693) > 0x00007f0d2fb2064f: cmp %r13d,%r11d > 0x00007f0d2fb20652: jge 0x00007f0d2fb206ad ;*aload_2 {reexecute=0 rethrow=0 return_oop=0} > ; - io.github.richardstartin.radixsort.RadixSort::jdk at 41 (line 694) > 0x00007f0d2fb20654: movzbl 0x10(%rbp,%r11,4),%r10d ;*iand {reexecute=0 rethrow=0 return_oop=0} > ; - io.github.richardstartin.radixsort.RadixSort::jdk at 49 (line 694) > 0x00007f0d2fb2065a: decl 0x10(%r8,%r10,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} > ; - io.github.richardstartin.radixsort.RadixSort::jdk at 54 (line 694) > .................................................................................................... > 21.11% > > > > Whereas they have been eliminated in the first pass of `unrollOnePassHistogramsSkipLevelsSigned`: > > > ....[Hottest Region 1].............................................................................. > c2, level 4, io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned, version 402 (544 bytes) > > 0x00007f123035bb6c: incl 0x14(%rbp,%rcx,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} > ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 106 (line 405) > 0x00007f123035bb70: incl 0x14(%r9,%r10,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} > ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 123 (line 406) > 0x00007f123035bb75: cmp $0x1,%esi > 0x00007f123035bb78: jle 0x00007f123035cc28 > 0x00007f123035bb7e: mov $0x1,%edi > 0x00007f123035bb83: mov $0x1,%ebx > 0x00007f123035bb88: nopl 0x0(%rax,%rax,1) ;*aload {reexecute=0 rethrow=0 return_oop=0} > ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 43 (line 402) > 0.12% ? 0x00007f123035bb90: mov $0x80000000,%r10d > 0.06% ? 0x00007f123035bb96: add 0x10(%rdx,%rdi,4),%r10d ;*isub {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::signed at 3 (line 476) > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 53 (line 403) > 0.04% ? 0x00007f123035bb9b: mov %r10d,%r8d > 0.10% ? 0x00007f123035bb9e: shr $0x18,%r8d ;*iushr {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 116 (line 406) > 0.12% ? 0x00007f123035bba2: mov %r10d,%r11d > 0.08% ? 0x00007f123035bba5: shr $0x10,%r11d > 0.08% ? 0x00007f123035bba9: movzbl %r11b,%r11d ;*iand {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 99 (line 405) > 0.08% ? 0x00007f123035bbad: mov %r10d,%ecx > 0.04% ? 0x00007f123035bbb0: shr $0x8,%ecx > 0.08% ? 0x00007f123035bbb3: movzbl %r10b,%r10d ;*iand {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 59 (line 403) > 0.14% ? 0x00007f123035bbb7: mov 0x18(%rsp),%r14 > 0.16% ? 0x00007f123035bbbc: incl 0x14(%r14,%r10,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 66 (line 403) > 0.36% ? 0x00007f123035bbc1: movzbl %cl,%ecx ;*iand {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 79 (line 404) > 0.06% ? 0x00007f123035bbc4: mov 0x10(%rsp),%r10 > 0.10% ? 0x00007f123035bbc9: incl 0x14(%r10,%rcx,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 86 (line 404) > 0.26% ? 0x00007f123035bbce: incl 0x14(%rbp,%r11,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 106 (line 405) > 0.28% ? 0x00007f123035bbd3: incl 0x14(%r9,%r8,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 123 (line 406) > 0.20% ? 0x00007f123035bbd8: mov $0x80000000,%r10d > 0.10% ? 0x00007f123035bbde: add 0x14(%rdx,%rdi,4),%r10d ;*isub {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::signed at 3 (line 476) > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 53 (line 403) > 0.08% ? 0x00007f123035bbe3: mov %r10d,%r8d > 0.12% ? 0x00007f123035bbe6: shr $0x18,%r8d ;*iushr {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 116 (line 406) > 0.04% ? 0x00007f123035bbea: mov %r10d,%r11d > 0.06% ? 0x00007f123035bbed: shr $0x10,%r11d > 0.06% ? 0x00007f123035bbf1: movzbl %r11b,%r11d ;*iand {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 99 (line 405) > 0.14% ? 0x00007f123035bbf5: mov %r10d,%ecx > 0.04% ? 0x00007f123035bbf8: shr $0x8,%ecx > 0.04% ? 0x00007f123035bbfb: movzbl %r10b,%r10d ;*iand {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 59 (line 403) > 0.08% ? 0x00007f123035bbff: incl 0x14(%r14,%r10,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 66 (line 403) > 0.46% ? 0x00007f123035bc04: movzbl %cl,%ecx ;*iand {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 79 (line 404) > 0.10% ? 0x00007f123035bc07: mov 0x10(%rsp),%r10 > 0.08% ? 0x00007f123035bc0c: incl 0x14(%r10,%rcx,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 86 (line 404) > 0.22% ? 0x00007f123035bc11: incl 0x14(%rbp,%r11,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 106 (line 405) > 0.30% ? 0x00007f123035bc16: incl 0x14(%r9,%r8,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 123 (line 406) > 0.22% ? 0x00007f123035bc1b: mov $0x80000000,%r10d > 0.04% ? 0x00007f123035bc21: add 0x18(%rdx,%rdi,4),%r10d ;*isub {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::signed at 3 (line 476) > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 53 (line 403) > 0.20% ? 0x00007f123035bc26: mov %r10d,%r8d > 0.18% ? 0x00007f123035bc29: shr $0x18,%r8d ;*iushr {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 116 (line 406) > 0.12% ? 0x00007f123035bc2d: mov %r10d,%r11d > 0.06% ? 0x00007f123035bc30: shr $0x10,%r11d > 0.20% ? 0x00007f123035bc34: movzbl %r11b,%r11d ;*iand {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 99 (line 405) > 0.10% ? 0x00007f123035bc38: mov %r10d,%ecx > 0.12% ? 0x00007f123035bc3b: shr $0x8,%ecx > 0.20% ? 0x00007f123035bc3e: movzbl %r10b,%r10d ;*iand {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 59 (line 403) > 0.08% ? 0x00007f123035bc42: incl 0x14(%r14,%r10,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 66 (line 403) > 0.18% ? 0x00007f123035bc47: movzbl %cl,%ecx ;*iand {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 79 (line 404) > 0.08% ? 0x00007f123035bc4a: mov 0x10(%rsp),%r10 > 0.10% ? 0x00007f123035bc4f: incl 0x14(%r10,%rcx,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 86 (line 404) > 0.20% ? 0x00007f123035bc54: incl 0x14(%rbp,%r11,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 106 (line 405) > 0.12% ? 0x00007f123035bc59: incl 0x14(%r9,%r8,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 123 (line 406) > 0.34% ? 0x00007f123035bc5e: mov $0x80000000,%r10d > 0.04% ? 0x00007f123035bc64: add 0x1c(%rdx,%rdi,4),%r10d ;*isub {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::signed at 3 (line 476) > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 53 (line 403) > 0.91% ? 0x00007f123035bc69: mov %r10d,%r8d > 0.02% ? 0x00007f123035bc6c: shr $0x18,%r8d ;*iushr {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 116 (line 406) > 0.12% ? 0x00007f123035bc70: mov %r10d,%r11d > 0.06% ? 0x00007f123035bc73: shr $0x10,%r11d > 0.06% ? 0x00007f123035bc77: movzbl %r11b,%r11d ;*iand {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 99 (line 405) > 0.06% ? 0x00007f123035bc7b: mov %r10d,%ecx > ? 0x00007f123035bc7e: shr $0x8,%ecx > 0.10% ? 0x00007f123035bc81: movzbl %r10b,%r10d ;*iand {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 59 (line 403) > 0.08% ? 0x00007f123035bc85: incl 0x14(%r14,%r10,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 66 (line 403) > 0.16% ? 0x00007f123035bc8a: movzbl %cl,%ecx ;*iand {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 79 (line 404) > ? 0x00007f123035bc8d: mov 0x10(%rsp),%r10 > 0.14% ? 0x00007f123035bc92: incl 0x14(%r10,%rcx,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 86 (line 404) > 0.32% ? 0x00007f123035bc97: incl 0x14(%rbp,%r11,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 106 (line 405) > 0.32% ? 0x00007f123035bc9c: incl 0x14(%r9,%r8,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 123 (line 406) > 0.24% ? 0x00007f123035bca1: mov $0x80000000,%r10d > 0.12% ? 0x00007f123035bca7: add 0x20(%rdx,%rdi,4),%r10d ;*isub {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::signed at 3 (line 476) > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 53 (line 403) > 0.08% ? 0x00007f123035bcac: mov %r10d,%r8d > 0.08% ? 0x00007f123035bcaf: shr $0x18,%r8d ;*iushr {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 116 (line 406) > 0.06% ? 0x00007f123035bcb3: mov %r10d,%r11d > 0.08% ? 0x00007f123035bcb6: shr $0x10,%r11d > 0.10% ? 0x00007f123035bcba: movzbl %r11b,%r11d ;*iand {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 99 (line 405) > 0.14% ? 0x00007f123035bcbe: mov %r10d,%ecx > 0.14% ? 0x00007f123035bcc1: shr $0x8,%ecx > 0.14% ? 0x00007f123035bcc4: movzbl %r10b,%r10d ;*iand {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 59 (line 403) > 0.08% ? 0x00007f123035bcc8: incl 0x14(%r14,%r10,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 66 (line 403) > 0.22% ? 0x00007f123035bccd: movzbl %cl,%ecx ;*iand {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 79 (line 404) > 0.10% ? 0x00007f123035bcd0: mov 0x10(%rsp),%r10 > 0.14% ? 0x00007f123035bcd5: incl 0x14(%r10,%rcx,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 86 (line 404) > 0.24% ? 0x00007f123035bcda: incl 0x14(%rbp,%r11,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 106 (line 405) > 0.20% ? 0x00007f123035bcdf: incl 0x14(%r9,%r8,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 123 (line 406) > 0.18% ? 0x00007f123035bce4: mov $0x80000000,%r10d > 0.04% ? 0x00007f123035bcea: add 0x24(%rdx,%rdi,4),%r10d ;*isub {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::signed at 3 (line 476) > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 53 (line 403) > 0.12% ? 0x00007f123035bcef: mov %r10d,%r8d > 0.04% ? 0x00007f123035bcf2: shr $0x18,%r8d ;*iushr {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 116 (line 406) > 0.08% ? 0x00007f123035bcf6: mov %r10d,%r11d > 0.16% ? 0x00007f123035bcf9: shr $0x10,%r11d > 0.06% ? 0x00007f123035bcfd: movzbl %r11b,%r11d ;*iand {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 99 (line 405) > 0.06% ? 0x00007f123035bd01: mov %r10d,%ecx > 0.04% ? 0x00007f123035bd04: shr $0x8,%ecx > 0.02% ? 0x00007f123035bd07: movzbl %r10b,%r10d ;*iand {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 59 (line 403) > 0.12% ? 0x00007f123035bd0b: incl 0x14(%r14,%r10,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 66 (line 403) > 0.22% ? 0x00007f123035bd10: movzbl %cl,%ecx ;*iand {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 79 (line 404) > 0.06% ? 0x00007f123035bd13: mov 0x10(%rsp),%r10 > 0.04% ? 0x00007f123035bd18: incl 0x14(%r10,%rcx,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 86 (line 404) > 0.20% ? 0x00007f123035bd1d: incl 0x14(%rbp,%r11,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 106 (line 405) > 0.28% ? 0x00007f123035bd22: incl 0x14(%r9,%r8,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 123 (line 406) > 0.46% ? 0x00007f123035bd27: mov $0x80000000,%r10d > 0.08% ? 0x00007f123035bd2d: add 0x28(%rdx,%rdi,4),%r10d ;*isub {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::signed at 3 (line 476) > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 53 (line 403) > 0.08% ? 0x00007f123035bd32: mov %r10d,%r8d > 0.04% ? 0x00007f123035bd35: shr $0x18,%r8d ;*iushr {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 116 (line 406) > 0.10% ? 0x00007f123035bd39: mov %r10d,%r11d > 0.04% ? 0x00007f123035bd3c: shr $0x10,%r11d > 0.06% ? 0x00007f123035bd40: movzbl %r11b,%r11d ;*iand {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 99 (line 405) > 0.04% ? 0x00007f123035bd44: mov %r10d,%ecx > 0.10% ? 0x00007f123035bd47: shr $0x8,%ecx > 0.10% ? 0x00007f123035bd4a: movzbl %r10b,%r10d ;*iand {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 59 (line 403) > 0.10% ? 0x00007f123035bd4e: incl 0x14(%r14,%r10,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 66 (line 403) > 0.28% ? 0x00007f123035bd53: movzbl %cl,%ecx ;*iand {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 79 (line 404) > 0.14% ? 0x00007f123035bd56: mov 0x10(%rsp),%r10 > 0.10% ? 0x00007f123035bd5b: incl 0x14(%r10,%rcx,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 86 (line 404) > 0.36% ? 0x00007f123035bd60: incl 0x14(%rbp,%r11,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 106 (line 405) > 0.20% ? 0x00007f123035bd65: incl 0x14(%r9,%r8,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 123 (line 406) > 0.28% ? 0x00007f123035bd6a: mov $0x80000000,%r10d > 0.16% ? 0x00007f123035bd70: add 0x2c(%rdx,%rdi,4),%r10d ;*isub {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::signed at 3 (line 476) > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 53 (line 403) > 0.08% ? 0x00007f123035bd75: mov %r10d,%r8d > 0.10% ? 0x00007f123035bd78: shr $0x18,%r8d ;*iushr {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 116 (line 406) > 0.08% ? 0x00007f123035bd7c: mov %r10d,%r11d > 0.08% ? 0x00007f123035bd7f: shr $0x10,%r11d > 0.14% ? 0x00007f123035bd83: movzbl %r11b,%r11d ;*iand {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 99 (line 405) > 0.02% ? 0x00007f123035bd87: mov %r10d,%ecx > 0.02% ? 0x00007f123035bd8a: shr $0x8,%ecx > 0.20% ? 0x00007f123035bd8d: movzbl %r10b,%r10d ;*iand {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 59 (line 403) > 0.22% ? 0x00007f123035bd91: incl 0x14(%r14,%r10,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 66 (line 403) > 0.22% ? 0x00007f123035bd96: movzbl %cl,%ecx ;*iand {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 79 (line 404) > 0.12% ? 0x00007f123035bd99: mov 0x10(%rsp),%r10 > 0.04% ? 0x00007f123035bd9e: incl 0x14(%r10,%rcx,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 86 (line 404) > 0.22% ? 0x00007f123035bda3: incl 0x14(%rbp,%r11,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 106 (line 405) > 0.20% ? 0x00007f123035bda8: incl 0x14(%r9,%r8,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 123 (line 406) > 0.26% ? 0x00007f123035bdad: add $0x8,%edi ;*iinc {reexecute=0 rethrow=0 return_oop=0} > ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 124 (line 402) > 0.10% ? 0x00007f123035bdb0: cmp %esi,%edi > ? 0x00007f123035bdb2: jl 0x00007f123035bb90 ;*if_icmpge {reexecute=0 rethrow=0 return_oop=0} > ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 40 (line 402) > 0x00007f123035bdb8: cmp %eax,%edi > 0x00007f123035bdba: jge 0x00007f123035be09 ;*aload {reexecute=0 rethrow=0 return_oop=0} > ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 43 (line 402) > 0x00007f123035bdbc: mov $0x80000000,%esi > 0x00007f123035bdc1: add 0x10(%rdx,%rdi,4),%esi ;*isub {reexecute=0 rethrow=0 return_oop=0} > ; - io.github.richardstartin.radixsort.RadixSort::signed at 3 (line 476) > ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 53 (line 403) > .................................................................................................... > 18.02% > > > > So, I think there may be some room for improvement in this submission. Benchmarking is hard, and it's possible I have made a mistake or have misinterpreted the results, but I think such a big difference warrants investigation before pushing this change to so many users. I ran these benchmarks on JDK 11.0.11. I have run a range of randomised tests to verify that the two implementations produce the same results. So the issue of not skipping passes was my fault in the translation process, so not something to worry about, though after [fixing that](https://github.com/richardstartin/radix-sort-benchmark/commit/ccbee984c6a0e0f50c30de59e1a5e9fbcad89510) the original implementation still has the edge because of the bounds checks on the `xor` not getting eliminated. Benchmark (bits) (padding) (scenario) (seed) (size) Mode Cnt Score Error Units RadixSortBenchmark.jdk 17 7 UNIFORM 0 1000000 avgt 5 10432.408 ? 87.024 us/op RadixSortBenchmark.jdk 23 7 UNIFORM 0 1000000 avgt 5 9465.990 ? 40.598 us/op RadixSortBenchmark.jdk 30 7 UNIFORM 0 1000000 avgt 5 11189.146 ? 50.972 us/op RadixSortBenchmark.unrollOnePassSkipLevelsSigned 17 7 UNIFORM 0 1000000 avgt 5 9546.963 ? 41.698 us/op RadixSortBenchmark.unrollOnePassSkipLevelsSigned 23 7 UNIFORM 0 1000000 avgt 5 9412.114 ? 43.081 us/op RadixSortBenchmark.unrollOnePassSkipLevelsSigned 30 7 UNIFORM 0 1000000 avgt 5 10823.618 ? 64.311 us/op ------------- PR: https://git.openjdk.java.net/jdk/pull/3938 From github.com+16439049+richardstartin at openjdk.java.net Mon Sep 13 17:28:46 2021 From: github.com+16439049+richardstartin at openjdk.java.net (Richard Startin) Date: Mon, 13 Sep 2021 17:28:46 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) In-Reply-To: References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> <75Nj_vbtmqUEj1XoUw9i3kTL140mcy6mZEmHyLyHa0U=.4eadfe72-2e17-4fa2-8f00-ba36f2c46305@github.com> <8zsz0oqYToH6u-FsIvYMrKxdJYG4AgftI9Fn5hC7v8E=.cf5db5a8-b69d-4e58-8ffd-ac86d6bd198f@github.com> <-exCZ7NcHfpt_xWuhuEsNxondubbjJQVaFmqn6jk79I=.0dae33f1-dbfd-4c07-a4ad-039070fdb62a@github.com> Message-ID: <2xNg3TOybhBILE2c7kj3NWIOUDQ8WgQgrCmzKnltx7E=.2997ae60-493f-462f-b54d-77c332cf5f90@github.com> On Thu, 13 May 2021 14:44:28 GMT, Richard Startin wrote: >> @iaroslavski I would prefer to discuss this in private than here, but my argument is that the name `skipByte` came from Laurent's code, and that Laurent's code was clearly derived from my own within a fork of my repository. I linked the commits where you changed `skipByte` to `passLevel` and Laurent changed my name `canSkipLevel` to `skipByte`. >> >> For me, this raises questions about the independence of your work from Laurent's, and Laurent's work is clearly derived from my own (and I don't think anyone is disputing the latter). I would be happy to sort this out in private. > > In private correspondence with Vladimir, it was explained that where Vladimir's code and Laurent's code are identical, including typos ([Vladimir's code](https://github.com/iaroslavski/sorting/commit/f076073b8b819a9687613903a164e3ed71821769#diff-4b4d68fc834c2ad12a9fb9d316a812221af7c398338ed2ee907d0a795e7aadafR672), [Laurent's code](https://github.com/bourgesl/radix-sort-benchmark/commit/a693b26b2e2c14cfeedf9c753c9d643096b0e38d#diff-397ce8fd791e2ce508cf9127201bc9ab46264cd2a79fd0487a63569f2e4b59b2R719)) it is because Vladimir sent the code to Laurent, not the other way around, therefore Vladimir's code does not derive from Laurent's, and it does not derive from mine. I can only trust that this is the case, so please disregard my claim that this is derivative work when reviewing this PR. For what it's worth, I benchmarked this implementation radix sort ([adapted here to fit in to my harness](https://github.com/richardstartin/radix-sort-benchmark/commit/07169e8e8602152cfda859baa159db165bf5fcab#diff-6c13d3fb74f38906677dbfa1a70a123c8e5baf4a39219c81ef121e078d0013bcR681-R710782)) against a [signed variant](https://github.com/richardstartin/radix-sort-benchmark/commit/07169e8e8602152cfda859baa159db165bf5fcab#diff-6c13d3fb74f38906677dbfa1a70a123c8e5baf4a39219c81ef121e078d0013bcR396-R478) of what I have claimed this work was derived from and the proposed implementation does not perform favourably on uniformly random data: Benchmark (bits) (padding) (scenario) (seed) (size) Mode Cnt Score Error Units RadixSortBenchmark.jdk 17 7 UNIFORM 0 1000000 avgt 5 11301.950 ? 113.691 us/op RadixSortBenchmark.jdk 23 7 UNIFORM 0 1000000 avgt 5 11792.351 ? 60.757 us/op RadixSortBenchmark.jdk 30 7 UNIFORM 0 1000000 avgt 5 11184.616 ? 67.094 us/op RadixSortBenchmark.unrollOnePassSkipLevelsSigned 17 7 UNIFORM 0 1000000 avgt 5 9564.626 ? 69.497 us/op RadixSortBenchmark.unrollOnePassSkipLevelsSigned 23 7 UNIFORM 0 1000000 avgt 5 9432.085 ? 58.983 us/op RadixSortBenchmark.unrollOnePassSkipLevelsSigned 30 7 UNIFORM 0 1000000 avgt 5 10772.975 ? 51.848 us/op I believe the root cause is a defect in the mechanism employed to skip passes as can be seen by the increased number of instructions and cycles here. In the proposed implementation, instructions is roughly constant as a function of bits. In the case where all passes must be performed (bits = 30), IPC is superior in `unrollOnePassHistogramsSkipLevelsSigned`. Benchmark (bits) (padding) (scenario) (seed) (size) Mode Cnt Score Error Units RadixSortBenchmark.jdk:cycles 17 7 UNIFORM 0 1000000 avgt 34976971.877 #/op RadixSortBenchmark.jdk:instructions 17 7 UNIFORM 0 1000000 avgt 70121142.003 #/op RadixSortBenchmark.jdk:cycles 23 7 UNIFORM 0 1000000 avgt 32369970.385 #/op RadixSortBenchmark.jdk:instructions 23 7 UNIFORM 0 1000000 avgt 70201664.963 #/op RadixSortBenchmark.jdk:cycles 30 7 UNIFORM 0 1000000 avgt 30789736.602 #/op RadixSortBenchmark.jdk:instructions 30 7 UNIFORM 0 1000000 avgt 70180942.122 #/op RadixSortBenchmark.jdk:IPC 30 7 UNIFORM 0 1000000 avgt 2.279 insns/clk RadixSortBenchmark.unrollOnePassSkipLevelsSigned:cycles 17 7 UNIFORM 0 1000000 avgt 26983994.479 #/op RadixSortBenchmark.unrollOnePassSkipLevelsSigned:instructions 17 7 UNIFORM 0 1000000 avgt 62065304.827 #/op RadixSortBenchmark.unrollOnePassSkipLevelsSigned:cycles 23 7 UNIFORM 0 1000000 avgt 26161703.124 #/op RadixSortBenchmark.unrollOnePassSkipLevelsSigned:instructions 23 7 UNIFORM 0 1000000 avgt 63102683.167 #/op RadixSortBenchmark.unrollOnePassSkipLevelsSigned:cycles 30 7 UNIFORM 0 1000000 avgt 29780103.795 #/op RadixSortBenchmark.unrollOnePassSkipLevelsSigned:instructions 30 7 UNIFORM 0 1000000 avgt 74437097.025 #/op RadixSortBenchmark.unrollOnePassSkipLevelsSigned:IPC 30 7 UNIFORM 0 1000000 avgt 2.500 insns/clk The biggest difference in executed code appears to be that bounds checks are not eliminated in the first counting pass in the proposed implementation: ....[Hottest Region 1].............................................................................. c2, level 4, io.github.richardstartin.radixsort.RadixSort::jdk, version 402 (166 bytes) 0x00007f0d2fb20579: cmp $0x100,%r10d 0x00007f0d2fb20580: jae 0x00007f0d2fb21344 0x00007f0d2fb20586: decl 0x10(%rdx,%r10,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} ; - io.github.richardstartin.radixsort.RadixSort::jdk at 107 (line 697) 0x00007f0d2fb2058b: cmp $0x1,%esi 0x00007f0d2fb2058e: jle 0x00007f0d2fb2134c 0x00007f0d2fb20594: mov $0x1,%r11d 0x00007f0d2fb2059a: xor %ecx,%ecx 0x00007f0d2fb2059c: nopl 0x0(%rax) ;*aload_2 {reexecute=0 rethrow=0 return_oop=0} ; - io.github.richardstartin.radixsort.RadixSort::jdk at 41 (line 694) 0.06% ? 0x00007f0d2fb205a0: movzbl 0x10(%rbp,%r11,4),%r10d ;*iand {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::jdk at 49 (line 694) 0.18% ? 0x00007f0d2fb205a6: decl 0x10(%r8,%r10,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::jdk at 54 (line 694) 1.37% ? 0x00007f0d2fb205ab: mov 0x10(%rbp,%r11,4),%r10d 0.42% ? 0x00007f0d2fb205b0: shr $0x8,%r10d 0.34% ? 0x00007f0d2fb205b4: movzbl %r10b,%r10d ;*iand {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::jdk at 66 (line 695) 0.50% ? 0x00007f0d2fb205b8: decl 0x10(%r9,%r10,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::jdk at 71 (line 695) 1.75% ? 0x00007f0d2fb205bd: mov 0x10(%rbp,%r11,4),%r10d 0.42% ? 0x00007f0d2fb205c2: shr $0x10,%r10d 0.12% ? 0x00007f0d2fb205c6: movzbl %r10b,%r10d ;*iand {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::jdk at 84 (line 696) 0.36% ? 0x00007f0d2fb205ca: decl 0x10(%rbx,%r10,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::jdk at 89 (line 696) 1.73% ? 0x00007f0d2fb205cf: mov 0x10(%rbp,%r11,4),%r10d 0.26% ? 0x00007f0d2fb205d4: shr $0x18,%r10d 0.38% ? 0x00007f0d2fb205d8: xor $0x80,%r10d ;*ixor {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::jdk at 102 (line 697) 0.28% ? 0x00007f0d2fb205df: cmp $0x100,%r10d ? 0x00007f0d2fb205e6: jae 0x00007f0d2fb20bab 0.38% ? 0x00007f0d2fb205ec: decl 0x10(%rdx,%r10,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::jdk at 107 (line 697) 1.25% ? 0x00007f0d2fb205f1: movzbl 0x14(%rbp,%r11,4),%r10d ;*iand {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::jdk at 49 (line 694) 1.63% ? 0x00007f0d2fb205f7: decl 0x10(%r8,%r10,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::jdk at 54 (line 694) 1.71% ? 0x00007f0d2fb205fc: mov 0x14(%rbp,%r11,4),%r10d 0.16% ? 0x00007f0d2fb20601: shr $0x8,%r10d 0.18% ? 0x00007f0d2fb20605: movzbl %r10b,%r10d ;*iand {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::jdk at 66 (line 695) 0.36% ? 0x00007f0d2fb20609: decl 0x10(%r9,%r10,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::jdk at 71 (line 695) 2.05% ? 0x00007f0d2fb2060e: mov 0x14(%rbp,%r11,4),%r10d 0.14% ? 0x00007f0d2fb20613: shr $0x10,%r10d 0.38% ? 0x00007f0d2fb20617: movzbl %r10b,%r10d ;*iand {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::jdk at 84 (line 696) 0.14% ? 0x00007f0d2fb2061b: decl 0x10(%rbx,%r10,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::jdk at 89 (line 696) 1.51% ? 0x00007f0d2fb20620: mov 0x14(%rbp,%r11,4),%r10d 0.14% ? 0x00007f0d2fb20625: shr $0x18,%r10d 0.32% ? 0x00007f0d2fb20629: xor $0x80,%r10d ;*ixor {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::jdk at 102 (line 697) 0.12% ? 0x00007f0d2fb20630: cmp $0x100,%r10d ? 0x00007f0d2fb20637: jae 0x00007f0d2fb20ba8 0.78% ? 0x00007f0d2fb2063d: decl 0x10(%rdx,%r10,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::jdk at 107 (line 697) 1.04% ? 0x00007f0d2fb20642: add $0x2,%r11d ;*iinc {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::jdk at 108 (line 693) 0.64% ? 0x00007f0d2fb20646: cmp %esi,%r11d ? 0x00007f0d2fb20649: jl 0x00007f0d2fb205a0 ;*if_icmpge {reexecute=0 rethrow=0 return_oop=0} ; - io.github.richardstartin.radixsort.RadixSort::jdk at 38 (line 693) 0x00007f0d2fb2064f: cmp %r13d,%r11d 0x00007f0d2fb20652: jge 0x00007f0d2fb206ad ;*aload_2 {reexecute=0 rethrow=0 return_oop=0} ; - io.github.richardstartin.radixsort.RadixSort::jdk at 41 (line 694) 0x00007f0d2fb20654: movzbl 0x10(%rbp,%r11,4),%r10d ;*iand {reexecute=0 rethrow=0 return_oop=0} ; - io.github.richardstartin.radixsort.RadixSort::jdk at 49 (line 694) 0x00007f0d2fb2065a: decl 0x10(%r8,%r10,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} ; - io.github.richardstartin.radixsort.RadixSort::jdk at 54 (line 694) .................................................................................................... 21.11% Whereas they have been eliminated in the first pass of `unrollOnePassHistogramsSkipLevelsSigned`: ....[Hottest Region 1].............................................................................. c2, level 4, io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned, version 402 (544 bytes) 0x00007f123035bb6c: incl 0x14(%rbp,%rcx,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 106 (line 405) 0x00007f123035bb70: incl 0x14(%r9,%r10,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 123 (line 406) 0x00007f123035bb75: cmp $0x1,%esi 0x00007f123035bb78: jle 0x00007f123035cc28 0x00007f123035bb7e: mov $0x1,%edi 0x00007f123035bb83: mov $0x1,%ebx 0x00007f123035bb88: nopl 0x0(%rax,%rax,1) ;*aload {reexecute=0 rethrow=0 return_oop=0} ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 43 (line 402) 0.12% ? 0x00007f123035bb90: mov $0x80000000,%r10d 0.06% ? 0x00007f123035bb96: add 0x10(%rdx,%rdi,4),%r10d ;*isub {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::signed at 3 (line 476) ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 53 (line 403) 0.04% ? 0x00007f123035bb9b: mov %r10d,%r8d 0.10% ? 0x00007f123035bb9e: shr $0x18,%r8d ;*iushr {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 116 (line 406) 0.12% ? 0x00007f123035bba2: mov %r10d,%r11d 0.08% ? 0x00007f123035bba5: shr $0x10,%r11d 0.08% ? 0x00007f123035bba9: movzbl %r11b,%r11d ;*iand {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 99 (line 405) 0.08% ? 0x00007f123035bbad: mov %r10d,%ecx 0.04% ? 0x00007f123035bbb0: shr $0x8,%ecx 0.08% ? 0x00007f123035bbb3: movzbl %r10b,%r10d ;*iand {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 59 (line 403) 0.14% ? 0x00007f123035bbb7: mov 0x18(%rsp),%r14 0.16% ? 0x00007f123035bbbc: incl 0x14(%r14,%r10,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 66 (line 403) 0.36% ? 0x00007f123035bbc1: movzbl %cl,%ecx ;*iand {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 79 (line 404) 0.06% ? 0x00007f123035bbc4: mov 0x10(%rsp),%r10 0.10% ? 0x00007f123035bbc9: incl 0x14(%r10,%rcx,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 86 (line 404) 0.26% ? 0x00007f123035bbce: incl 0x14(%rbp,%r11,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 106 (line 405) 0.28% ? 0x00007f123035bbd3: incl 0x14(%r9,%r8,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 123 (line 406) 0.20% ? 0x00007f123035bbd8: mov $0x80000000,%r10d 0.10% ? 0x00007f123035bbde: add 0x14(%rdx,%rdi,4),%r10d ;*isub {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::signed at 3 (line 476) ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 53 (line 403) 0.08% ? 0x00007f123035bbe3: mov %r10d,%r8d 0.12% ? 0x00007f123035bbe6: shr $0x18,%r8d ;*iushr {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 116 (line 406) 0.04% ? 0x00007f123035bbea: mov %r10d,%r11d 0.06% ? 0x00007f123035bbed: shr $0x10,%r11d 0.06% ? 0x00007f123035bbf1: movzbl %r11b,%r11d ;*iand {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 99 (line 405) 0.14% ? 0x00007f123035bbf5: mov %r10d,%ecx 0.04% ? 0x00007f123035bbf8: shr $0x8,%ecx 0.04% ? 0x00007f123035bbfb: movzbl %r10b,%r10d ;*iand {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 59 (line 403) 0.08% ? 0x00007f123035bbff: incl 0x14(%r14,%r10,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 66 (line 403) 0.46% ? 0x00007f123035bc04: movzbl %cl,%ecx ;*iand {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 79 (line 404) 0.10% ? 0x00007f123035bc07: mov 0x10(%rsp),%r10 0.08% ? 0x00007f123035bc0c: incl 0x14(%r10,%rcx,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 86 (line 404) 0.22% ? 0x00007f123035bc11: incl 0x14(%rbp,%r11,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 106 (line 405) 0.30% ? 0x00007f123035bc16: incl 0x14(%r9,%r8,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 123 (line 406) 0.22% ? 0x00007f123035bc1b: mov $0x80000000,%r10d 0.04% ? 0x00007f123035bc21: add 0x18(%rdx,%rdi,4),%r10d ;*isub {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::signed at 3 (line 476) ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 53 (line 403) 0.20% ? 0x00007f123035bc26: mov %r10d,%r8d 0.18% ? 0x00007f123035bc29: shr $0x18,%r8d ;*iushr {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 116 (line 406) 0.12% ? 0x00007f123035bc2d: mov %r10d,%r11d 0.06% ? 0x00007f123035bc30: shr $0x10,%r11d 0.20% ? 0x00007f123035bc34: movzbl %r11b,%r11d ;*iand {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 99 (line 405) 0.10% ? 0x00007f123035bc38: mov %r10d,%ecx 0.12% ? 0x00007f123035bc3b: shr $0x8,%ecx 0.20% ? 0x00007f123035bc3e: movzbl %r10b,%r10d ;*iand {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 59 (line 403) 0.08% ? 0x00007f123035bc42: incl 0x14(%r14,%r10,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 66 (line 403) 0.18% ? 0x00007f123035bc47: movzbl %cl,%ecx ;*iand {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 79 (line 404) 0.08% ? 0x00007f123035bc4a: mov 0x10(%rsp),%r10 0.10% ? 0x00007f123035bc4f: incl 0x14(%r10,%rcx,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 86 (line 404) 0.20% ? 0x00007f123035bc54: incl 0x14(%rbp,%r11,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 106 (line 405) 0.12% ? 0x00007f123035bc59: incl 0x14(%r9,%r8,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 123 (line 406) 0.34% ? 0x00007f123035bc5e: mov $0x80000000,%r10d 0.04% ? 0x00007f123035bc64: add 0x1c(%rdx,%rdi,4),%r10d ;*isub {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::signed at 3 (line 476) ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 53 (line 403) 0.91% ? 0x00007f123035bc69: mov %r10d,%r8d 0.02% ? 0x00007f123035bc6c: shr $0x18,%r8d ;*iushr {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 116 (line 406) 0.12% ? 0x00007f123035bc70: mov %r10d,%r11d 0.06% ? 0x00007f123035bc73: shr $0x10,%r11d 0.06% ? 0x00007f123035bc77: movzbl %r11b,%r11d ;*iand {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 99 (line 405) 0.06% ? 0x00007f123035bc7b: mov %r10d,%ecx ? 0x00007f123035bc7e: shr $0x8,%ecx 0.10% ? 0x00007f123035bc81: movzbl %r10b,%r10d ;*iand {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 59 (line 403) 0.08% ? 0x00007f123035bc85: incl 0x14(%r14,%r10,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 66 (line 403) 0.16% ? 0x00007f123035bc8a: movzbl %cl,%ecx ;*iand {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 79 (line 404) ? 0x00007f123035bc8d: mov 0x10(%rsp),%r10 0.14% ? 0x00007f123035bc92: incl 0x14(%r10,%rcx,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 86 (line 404) 0.32% ? 0x00007f123035bc97: incl 0x14(%rbp,%r11,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 106 (line 405) 0.32% ? 0x00007f123035bc9c: incl 0x14(%r9,%r8,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 123 (line 406) 0.24% ? 0x00007f123035bca1: mov $0x80000000,%r10d 0.12% ? 0x00007f123035bca7: add 0x20(%rdx,%rdi,4),%r10d ;*isub {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::signed at 3 (line 476) ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 53 (line 403) 0.08% ? 0x00007f123035bcac: mov %r10d,%r8d 0.08% ? 0x00007f123035bcaf: shr $0x18,%r8d ;*iushr {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 116 (line 406) 0.06% ? 0x00007f123035bcb3: mov %r10d,%r11d 0.08% ? 0x00007f123035bcb6: shr $0x10,%r11d 0.10% ? 0x00007f123035bcba: movzbl %r11b,%r11d ;*iand {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 99 (line 405) 0.14% ? 0x00007f123035bcbe: mov %r10d,%ecx 0.14% ? 0x00007f123035bcc1: shr $0x8,%ecx 0.14% ? 0x00007f123035bcc4: movzbl %r10b,%r10d ;*iand {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 59 (line 403) 0.08% ? 0x00007f123035bcc8: incl 0x14(%r14,%r10,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 66 (line 403) 0.22% ? 0x00007f123035bccd: movzbl %cl,%ecx ;*iand {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 79 (line 404) 0.10% ? 0x00007f123035bcd0: mov 0x10(%rsp),%r10 0.14% ? 0x00007f123035bcd5: incl 0x14(%r10,%rcx,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 86 (line 404) 0.24% ? 0x00007f123035bcda: incl 0x14(%rbp,%r11,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 106 (line 405) 0.20% ? 0x00007f123035bcdf: incl 0x14(%r9,%r8,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 123 (line 406) 0.18% ? 0x00007f123035bce4: mov $0x80000000,%r10d 0.04% ? 0x00007f123035bcea: add 0x24(%rdx,%rdi,4),%r10d ;*isub {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::signed at 3 (line 476) ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 53 (line 403) 0.12% ? 0x00007f123035bcef: mov %r10d,%r8d 0.04% ? 0x00007f123035bcf2: shr $0x18,%r8d ;*iushr {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 116 (line 406) 0.08% ? 0x00007f123035bcf6: mov %r10d,%r11d 0.16% ? 0x00007f123035bcf9: shr $0x10,%r11d 0.06% ? 0x00007f123035bcfd: movzbl %r11b,%r11d ;*iand {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 99 (line 405) 0.06% ? 0x00007f123035bd01: mov %r10d,%ecx 0.04% ? 0x00007f123035bd04: shr $0x8,%ecx 0.02% ? 0x00007f123035bd07: movzbl %r10b,%r10d ;*iand {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 59 (line 403) 0.12% ? 0x00007f123035bd0b: incl 0x14(%r14,%r10,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 66 (line 403) 0.22% ? 0x00007f123035bd10: movzbl %cl,%ecx ;*iand {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 79 (line 404) 0.06% ? 0x00007f123035bd13: mov 0x10(%rsp),%r10 0.04% ? 0x00007f123035bd18: incl 0x14(%r10,%rcx,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 86 (line 404) 0.20% ? 0x00007f123035bd1d: incl 0x14(%rbp,%r11,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 106 (line 405) 0.28% ? 0x00007f123035bd22: incl 0x14(%r9,%r8,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 123 (line 406) 0.46% ? 0x00007f123035bd27: mov $0x80000000,%r10d 0.08% ? 0x00007f123035bd2d: add 0x28(%rdx,%rdi,4),%r10d ;*isub {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::signed at 3 (line 476) ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 53 (line 403) 0.08% ? 0x00007f123035bd32: mov %r10d,%r8d 0.04% ? 0x00007f123035bd35: shr $0x18,%r8d ;*iushr {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 116 (line 406) 0.10% ? 0x00007f123035bd39: mov %r10d,%r11d 0.04% ? 0x00007f123035bd3c: shr $0x10,%r11d 0.06% ? 0x00007f123035bd40: movzbl %r11b,%r11d ;*iand {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 99 (line 405) 0.04% ? 0x00007f123035bd44: mov %r10d,%ecx 0.10% ? 0x00007f123035bd47: shr $0x8,%ecx 0.10% ? 0x00007f123035bd4a: movzbl %r10b,%r10d ;*iand {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 59 (line 403) 0.10% ? 0x00007f123035bd4e: incl 0x14(%r14,%r10,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 66 (line 403) 0.28% ? 0x00007f123035bd53: movzbl %cl,%ecx ;*iand {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 79 (line 404) 0.14% ? 0x00007f123035bd56: mov 0x10(%rsp),%r10 0.10% ? 0x00007f123035bd5b: incl 0x14(%r10,%rcx,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 86 (line 404) 0.36% ? 0x00007f123035bd60: incl 0x14(%rbp,%r11,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 106 (line 405) 0.20% ? 0x00007f123035bd65: incl 0x14(%r9,%r8,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 123 (line 406) 0.28% ? 0x00007f123035bd6a: mov $0x80000000,%r10d 0.16% ? 0x00007f123035bd70: add 0x2c(%rdx,%rdi,4),%r10d ;*isub {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::signed at 3 (line 476) ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 53 (line 403) 0.08% ? 0x00007f123035bd75: mov %r10d,%r8d 0.10% ? 0x00007f123035bd78: shr $0x18,%r8d ;*iushr {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 116 (line 406) 0.08% ? 0x00007f123035bd7c: mov %r10d,%r11d 0.08% ? 0x00007f123035bd7f: shr $0x10,%r11d 0.14% ? 0x00007f123035bd83: movzbl %r11b,%r11d ;*iand {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 99 (line 405) 0.02% ? 0x00007f123035bd87: mov %r10d,%ecx 0.02% ? 0x00007f123035bd8a: shr $0x8,%ecx 0.20% ? 0x00007f123035bd8d: movzbl %r10b,%r10d ;*iand {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 59 (line 403) 0.22% ? 0x00007f123035bd91: incl 0x14(%r14,%r10,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 66 (line 403) 0.22% ? 0x00007f123035bd96: movzbl %cl,%ecx ;*iand {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 79 (line 404) 0.12% ? 0x00007f123035bd99: mov 0x10(%rsp),%r10 0.04% ? 0x00007f123035bd9e: incl 0x14(%r10,%rcx,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 86 (line 404) 0.22% ? 0x00007f123035bda3: incl 0x14(%rbp,%r11,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 106 (line 405) 0.20% ? 0x00007f123035bda8: incl 0x14(%r9,%r8,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 123 (line 406) 0.26% ? 0x00007f123035bdad: add $0x8,%edi ;*iinc {reexecute=0 rethrow=0 return_oop=0} ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 124 (line 402) 0.10% ? 0x00007f123035bdb0: cmp %esi,%edi ? 0x00007f123035bdb2: jl 0x00007f123035bb90 ;*if_icmpge {reexecute=0 rethrow=0 return_oop=0} ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 40 (line 402) 0x00007f123035bdb8: cmp %eax,%edi 0x00007f123035bdba: jge 0x00007f123035be09 ;*aload {reexecute=0 rethrow=0 return_oop=0} ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 43 (line 402) 0x00007f123035bdbc: mov $0x80000000,%esi 0x00007f123035bdc1: add 0x10(%rdx,%rdi,4),%esi ;*isub {reexecute=0 rethrow=0 return_oop=0} ; - io.github.richardstartin.radixsort.RadixSort::signed at 3 (line 476) ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 53 (line 403) .................................................................................................... 18.02% So, I think there may be some room for improvement in this submission. Benchmarking is hard, and it's possible I have made a mistake or have misinterpreted the results, but I think such a big difference warrants investigation before pushing this change to so many users. I ran these benchmarks on JDK 11.0.11. I have run a range of randomised tests to verify that the two implementations produce the same results. ------------- PR: https://git.openjdk.java.net/jdk/pull/3938 From lbourges at openjdk.java.net Mon Sep 13 17:28:47 2021 From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Mon, 13 Sep 2021 17:28:47 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) In-Reply-To: References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> <75Nj_vbtmqUEj1XoUw9i3kTL140mcy6mZEmHyLyHa0U=.4eadfe72-2e17-4fa2-8f00-ba36f2c46305@github.com> <8zsz0oqYToH6u-FsIvYMrKxdJYG4AgftI9Fn5hC7v8E=.cf5db5a8-b69d-4e58-8ffd-ac86d6bd198f@github.com> <-exCZ7NcHfpt_xWuhuEsNxondubbjJQVaFmqn6jk79I=.0dae33f1-dbfd-4c07-a4ad-039070fdb62a@github.com> <2xNg3TOybhBILE2c7kj3NWIOUDQ8WgQgrCmzKnltx7E=.2997ae60-493f-462f-b54d-77c332cf5f90@github.com> Message-ID: <_UUKVWVyQtw3zDw86pcbQqtvpqFAdlRvlkhnIQkC_cU=.0d144e04-7d31-49ef-b386-3906ac6909a7@github.com> On Thu, 13 May 2021 21:44:38 GMT, Richard Startin wrote: >> For what it's worth, I benchmarked this implementation radix sort ([adapted here to fit in to my harness](https://github.com/richardstartin/radix-sort-benchmark/commit/07169e8e8602152cfda859baa159db165bf5fcab#diff-6c13d3fb74f38906677dbfa1a70a123c8e5baf4a39219c81ef121e078d0013bcR681-R710782)) against a [signed variant](https://github.com/richardstartin/radix-sort-benchmark/commit/07169e8e8602152cfda859baa159db165bf5fcab#diff-6c13d3fb74f38906677dbfa1a70a123c8e5baf4a39219c81ef121e078d0013bcR396-R478) of what I have claimed this work was derived from and the proposed implementation does not perform favourably on uniformly random data: >> >> >> >> Benchmark (bits) (padding) (scenario) (seed) (size) Mode Cnt Score Error Units >> RadixSortBenchmark.jdk 17 7 UNIFORM 0 1000000 avgt 5 11301.950 ? 113.691 us/op >> RadixSortBenchmark.jdk 23 7 UNIFORM 0 1000000 avgt 5 11792.351 ? 60.757 us/op >> RadixSortBenchmark.jdk 30 7 UNIFORM 0 1000000 avgt 5 11184.616 ? 67.094 us/op >> RadixSortBenchmark.unrollOnePassSkipLevelsSigned 17 7 UNIFORM 0 1000000 avgt 5 9564.626 ? 69.497 us/op >> RadixSortBenchmark.unrollOnePassSkipLevelsSigned 23 7 UNIFORM 0 1000000 avgt 5 9432.085 ? 58.983 us/op >> RadixSortBenchmark.unrollOnePassSkipLevelsSigned 30 7 UNIFORM 0 1000000 avgt 5 10772.975 ? 51.848 us/op >> >> >> >> I believe the root cause is a defect in the mechanism employed to skip passes as can be seen by the increased number of instructions and cycles here. In the proposed implementation, instructions is roughly constant as a function of bits. In the case where all passes must be performed (bits = 30), IPC is superior in `unrollOnePassHistogramsSkipLevelsSigned`. >> >> >> Benchmark (bits) (padding) (scenario) (seed) (size) Mode Cnt Score Error Units >> RadixSortBenchmark.jdk:cycles 17 7 UNIFORM 0 1000000 avgt 34976971.877 #/op >> RadixSortBenchmark.jdk:instructions 17 7 UNIFORM 0 1000000 avgt 70121142.003 #/op >> RadixSortBenchmark.jdk:cycles 23 7 UNIFORM 0 1000000 avgt 32369970.385 #/op >> RadixSortBenchmark.jdk:instructions 23 7 UNIFORM 0 1000000 avgt 70201664.963 #/op >> RadixSortBenchmark.jdk:cycles 30 7 UNIFORM 0 1000000 avgt 30789736.602 #/op >> RadixSortBenchmark.jdk:instructions 30 7 UNIFORM 0 1000000 avgt 70180942.122 #/op >> RadixSortBenchmark.jdk:IPC 30 7 UNIFORM 0 1000000 avgt 2.279 insns/clk >> RadixSortBenchmark.unrollOnePassSkipLevelsSigned:cycles 17 7 UNIFORM 0 1000000 avgt 26983994.479 #/op >> RadixSortBenchmark.unrollOnePassSkipLevelsSigned:instructions 17 7 UNIFORM 0 1000000 avgt 62065304.827 #/op >> RadixSortBenchmark.unrollOnePassSkipLevelsSigned:cycles 23 7 UNIFORM 0 1000000 avgt 26161703.124 #/op >> RadixSortBenchmark.unrollOnePassSkipLevelsSigned:instructions 23 7 UNIFORM 0 1000000 avgt 63102683.167 #/op >> RadixSortBenchmark.unrollOnePassSkipLevelsSigned:cycles 30 7 UNIFORM 0 1000000 avgt 29780103.795 #/op >> RadixSortBenchmark.unrollOnePassSkipLevelsSigned:instructions 30 7 UNIFORM 0 1000000 avgt 74437097.025 #/op >> RadixSortBenchmark.unrollOnePassSkipLevelsSigned:IPC 30 7 UNIFORM 0 1000000 avgt 2.500 insns/clk >> >> >> >> The biggest difference in executed code appears to be that bounds checks are not eliminated in the first counting pass in the proposed implementation: >> >> >> ....[Hottest Region 1].............................................................................. >> c2, level 4, io.github.richardstartin.radixsort.RadixSort::jdk, version 402 (166 bytes) >> >> 0x00007f0d2fb20579: cmp $0x100,%r10d >> 0x00007f0d2fb20580: jae 0x00007f0d2fb21344 >> 0x00007f0d2fb20586: decl 0x10(%rdx,%r10,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} >> ; - io.github.richardstartin.radixsort.RadixSort::jdk at 107 (line 697) >> 0x00007f0d2fb2058b: cmp $0x1,%esi >> 0x00007f0d2fb2058e: jle 0x00007f0d2fb2134c >> 0x00007f0d2fb20594: mov $0x1,%r11d >> 0x00007f0d2fb2059a: xor %ecx,%ecx >> 0x00007f0d2fb2059c: nopl 0x0(%rax) ;*aload_2 {reexecute=0 rethrow=0 return_oop=0} >> ; - io.github.richardstartin.radixsort.RadixSort::jdk at 41 (line 694) >> 0.06% ? 0x00007f0d2fb205a0: movzbl 0x10(%rbp,%r11,4),%r10d ;*iand {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::jdk at 49 (line 694) >> 0.18% ? 0x00007f0d2fb205a6: decl 0x10(%r8,%r10,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::jdk at 54 (line 694) >> 1.37% ? 0x00007f0d2fb205ab: mov 0x10(%rbp,%r11,4),%r10d >> 0.42% ? 0x00007f0d2fb205b0: shr $0x8,%r10d >> 0.34% ? 0x00007f0d2fb205b4: movzbl %r10b,%r10d ;*iand {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::jdk at 66 (line 695) >> 0.50% ? 0x00007f0d2fb205b8: decl 0x10(%r9,%r10,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::jdk at 71 (line 695) >> 1.75% ? 0x00007f0d2fb205bd: mov 0x10(%rbp,%r11,4),%r10d >> 0.42% ? 0x00007f0d2fb205c2: shr $0x10,%r10d >> 0.12% ? 0x00007f0d2fb205c6: movzbl %r10b,%r10d ;*iand {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::jdk at 84 (line 696) >> 0.36% ? 0x00007f0d2fb205ca: decl 0x10(%rbx,%r10,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::jdk at 89 (line 696) >> 1.73% ? 0x00007f0d2fb205cf: mov 0x10(%rbp,%r11,4),%r10d >> 0.26% ? 0x00007f0d2fb205d4: shr $0x18,%r10d >> 0.38% ? 0x00007f0d2fb205d8: xor $0x80,%r10d ;*ixor {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::jdk at 102 (line 697) >> 0.28% ? 0x00007f0d2fb205df: cmp $0x100,%r10d >> ? 0x00007f0d2fb205e6: jae 0x00007f0d2fb20bab >> 0.38% ? 0x00007f0d2fb205ec: decl 0x10(%rdx,%r10,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::jdk at 107 (line 697) >> 1.25% ? 0x00007f0d2fb205f1: movzbl 0x14(%rbp,%r11,4),%r10d ;*iand {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::jdk at 49 (line 694) >> 1.63% ? 0x00007f0d2fb205f7: decl 0x10(%r8,%r10,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::jdk at 54 (line 694) >> 1.71% ? 0x00007f0d2fb205fc: mov 0x14(%rbp,%r11,4),%r10d >> 0.16% ? 0x00007f0d2fb20601: shr $0x8,%r10d >> 0.18% ? 0x00007f0d2fb20605: movzbl %r10b,%r10d ;*iand {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::jdk at 66 (line 695) >> 0.36% ? 0x00007f0d2fb20609: decl 0x10(%r9,%r10,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::jdk at 71 (line 695) >> 2.05% ? 0x00007f0d2fb2060e: mov 0x14(%rbp,%r11,4),%r10d >> 0.14% ? 0x00007f0d2fb20613: shr $0x10,%r10d >> 0.38% ? 0x00007f0d2fb20617: movzbl %r10b,%r10d ;*iand {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::jdk at 84 (line 696) >> 0.14% ? 0x00007f0d2fb2061b: decl 0x10(%rbx,%r10,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::jdk at 89 (line 696) >> 1.51% ? 0x00007f0d2fb20620: mov 0x14(%rbp,%r11,4),%r10d >> 0.14% ? 0x00007f0d2fb20625: shr $0x18,%r10d >> 0.32% ? 0x00007f0d2fb20629: xor $0x80,%r10d ;*ixor {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::jdk at 102 (line 697) >> 0.12% ? 0x00007f0d2fb20630: cmp $0x100,%r10d >> ? 0x00007f0d2fb20637: jae 0x00007f0d2fb20ba8 >> 0.78% ? 0x00007f0d2fb2063d: decl 0x10(%rdx,%r10,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::jdk at 107 (line 697) >> 1.04% ? 0x00007f0d2fb20642: add $0x2,%r11d ;*iinc {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::jdk at 108 (line 693) >> 0.64% ? 0x00007f0d2fb20646: cmp %esi,%r11d >> ? 0x00007f0d2fb20649: jl 0x00007f0d2fb205a0 ;*if_icmpge {reexecute=0 rethrow=0 return_oop=0} >> ; - io.github.richardstartin.radixsort.RadixSort::jdk at 38 (line 693) >> 0x00007f0d2fb2064f: cmp %r13d,%r11d >> 0x00007f0d2fb20652: jge 0x00007f0d2fb206ad ;*aload_2 {reexecute=0 rethrow=0 return_oop=0} >> ; - io.github.richardstartin.radixsort.RadixSort::jdk at 41 (line 694) >> 0x00007f0d2fb20654: movzbl 0x10(%rbp,%r11,4),%r10d ;*iand {reexecute=0 rethrow=0 return_oop=0} >> ; - io.github.richardstartin.radixsort.RadixSort::jdk at 49 (line 694) >> 0x00007f0d2fb2065a: decl 0x10(%r8,%r10,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} >> ; - io.github.richardstartin.radixsort.RadixSort::jdk at 54 (line 694) >> .................................................................................................... >> 21.11% >> >> >> >> Whereas they have been eliminated in the first pass of `unrollOnePassHistogramsSkipLevelsSigned`: >> >> >> ....[Hottest Region 1].............................................................................. >> c2, level 4, io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned, version 402 (544 bytes) >> >> 0x00007f123035bb6c: incl 0x14(%rbp,%rcx,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} >> ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 106 (line 405) >> 0x00007f123035bb70: incl 0x14(%r9,%r10,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} >> ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 123 (line 406) >> 0x00007f123035bb75: cmp $0x1,%esi >> 0x00007f123035bb78: jle 0x00007f123035cc28 >> 0x00007f123035bb7e: mov $0x1,%edi >> 0x00007f123035bb83: mov $0x1,%ebx >> 0x00007f123035bb88: nopl 0x0(%rax,%rax,1) ;*aload {reexecute=0 rethrow=0 return_oop=0} >> ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 43 (line 402) >> 0.12% ? 0x00007f123035bb90: mov $0x80000000,%r10d >> 0.06% ? 0x00007f123035bb96: add 0x10(%rdx,%rdi,4),%r10d ;*isub {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::signed at 3 (line 476) >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 53 (line 403) >> 0.04% ? 0x00007f123035bb9b: mov %r10d,%r8d >> 0.10% ? 0x00007f123035bb9e: shr $0x18,%r8d ;*iushr {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 116 (line 406) >> 0.12% ? 0x00007f123035bba2: mov %r10d,%r11d >> 0.08% ? 0x00007f123035bba5: shr $0x10,%r11d >> 0.08% ? 0x00007f123035bba9: movzbl %r11b,%r11d ;*iand {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 99 (line 405) >> 0.08% ? 0x00007f123035bbad: mov %r10d,%ecx >> 0.04% ? 0x00007f123035bbb0: shr $0x8,%ecx >> 0.08% ? 0x00007f123035bbb3: movzbl %r10b,%r10d ;*iand {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 59 (line 403) >> 0.14% ? 0x00007f123035bbb7: mov 0x18(%rsp),%r14 >> 0.16% ? 0x00007f123035bbbc: incl 0x14(%r14,%r10,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 66 (line 403) >> 0.36% ? 0x00007f123035bbc1: movzbl %cl,%ecx ;*iand {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 79 (line 404) >> 0.06% ? 0x00007f123035bbc4: mov 0x10(%rsp),%r10 >> 0.10% ? 0x00007f123035bbc9: incl 0x14(%r10,%rcx,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 86 (line 404) >> 0.26% ? 0x00007f123035bbce: incl 0x14(%rbp,%r11,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 106 (line 405) >> 0.28% ? 0x00007f123035bbd3: incl 0x14(%r9,%r8,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 123 (line 406) >> 0.20% ? 0x00007f123035bbd8: mov $0x80000000,%r10d >> 0.10% ? 0x00007f123035bbde: add 0x14(%rdx,%rdi,4),%r10d ;*isub {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::signed at 3 (line 476) >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 53 (line 403) >> 0.08% ? 0x00007f123035bbe3: mov %r10d,%r8d >> 0.12% ? 0x00007f123035bbe6: shr $0x18,%r8d ;*iushr {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 116 (line 406) >> 0.04% ? 0x00007f123035bbea: mov %r10d,%r11d >> 0.06% ? 0x00007f123035bbed: shr $0x10,%r11d >> 0.06% ? 0x00007f123035bbf1: movzbl %r11b,%r11d ;*iand {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 99 (line 405) >> 0.14% ? 0x00007f123035bbf5: mov %r10d,%ecx >> 0.04% ? 0x00007f123035bbf8: shr $0x8,%ecx >> 0.04% ? 0x00007f123035bbfb: movzbl %r10b,%r10d ;*iand {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 59 (line 403) >> 0.08% ? 0x00007f123035bbff: incl 0x14(%r14,%r10,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 66 (line 403) >> 0.46% ? 0x00007f123035bc04: movzbl %cl,%ecx ;*iand {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 79 (line 404) >> 0.10% ? 0x00007f123035bc07: mov 0x10(%rsp),%r10 >> 0.08% ? 0x00007f123035bc0c: incl 0x14(%r10,%rcx,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 86 (line 404) >> 0.22% ? 0x00007f123035bc11: incl 0x14(%rbp,%r11,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 106 (line 405) >> 0.30% ? 0x00007f123035bc16: incl 0x14(%r9,%r8,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 123 (line 406) >> 0.22% ? 0x00007f123035bc1b: mov $0x80000000,%r10d >> 0.04% ? 0x00007f123035bc21: add 0x18(%rdx,%rdi,4),%r10d ;*isub {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::signed at 3 (line 476) >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 53 (line 403) >> 0.20% ? 0x00007f123035bc26: mov %r10d,%r8d >> 0.18% ? 0x00007f123035bc29: shr $0x18,%r8d ;*iushr {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 116 (line 406) >> 0.12% ? 0x00007f123035bc2d: mov %r10d,%r11d >> 0.06% ? 0x00007f123035bc30: shr $0x10,%r11d >> 0.20% ? 0x00007f123035bc34: movzbl %r11b,%r11d ;*iand {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 99 (line 405) >> 0.10% ? 0x00007f123035bc38: mov %r10d,%ecx >> 0.12% ? 0x00007f123035bc3b: shr $0x8,%ecx >> 0.20% ? 0x00007f123035bc3e: movzbl %r10b,%r10d ;*iand {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 59 (line 403) >> 0.08% ? 0x00007f123035bc42: incl 0x14(%r14,%r10,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 66 (line 403) >> 0.18% ? 0x00007f123035bc47: movzbl %cl,%ecx ;*iand {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 79 (line 404) >> 0.08% ? 0x00007f123035bc4a: mov 0x10(%rsp),%r10 >> 0.10% ? 0x00007f123035bc4f: incl 0x14(%r10,%rcx,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 86 (line 404) >> 0.20% ? 0x00007f123035bc54: incl 0x14(%rbp,%r11,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 106 (line 405) >> 0.12% ? 0x00007f123035bc59: incl 0x14(%r9,%r8,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 123 (line 406) >> 0.34% ? 0x00007f123035bc5e: mov $0x80000000,%r10d >> 0.04% ? 0x00007f123035bc64: add 0x1c(%rdx,%rdi,4),%r10d ;*isub {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::signed at 3 (line 476) >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 53 (line 403) >> 0.91% ? 0x00007f123035bc69: mov %r10d,%r8d >> 0.02% ? 0x00007f123035bc6c: shr $0x18,%r8d ;*iushr {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 116 (line 406) >> 0.12% ? 0x00007f123035bc70: mov %r10d,%r11d >> 0.06% ? 0x00007f123035bc73: shr $0x10,%r11d >> 0.06% ? 0x00007f123035bc77: movzbl %r11b,%r11d ;*iand {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 99 (line 405) >> 0.06% ? 0x00007f123035bc7b: mov %r10d,%ecx >> ? 0x00007f123035bc7e: shr $0x8,%ecx >> 0.10% ? 0x00007f123035bc81: movzbl %r10b,%r10d ;*iand {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 59 (line 403) >> 0.08% ? 0x00007f123035bc85: incl 0x14(%r14,%r10,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 66 (line 403) >> 0.16% ? 0x00007f123035bc8a: movzbl %cl,%ecx ;*iand {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 79 (line 404) >> ? 0x00007f123035bc8d: mov 0x10(%rsp),%r10 >> 0.14% ? 0x00007f123035bc92: incl 0x14(%r10,%rcx,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 86 (line 404) >> 0.32% ? 0x00007f123035bc97: incl 0x14(%rbp,%r11,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 106 (line 405) >> 0.32% ? 0x00007f123035bc9c: incl 0x14(%r9,%r8,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 123 (line 406) >> 0.24% ? 0x00007f123035bca1: mov $0x80000000,%r10d >> 0.12% ? 0x00007f123035bca7: add 0x20(%rdx,%rdi,4),%r10d ;*isub {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::signed at 3 (line 476) >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 53 (line 403) >> 0.08% ? 0x00007f123035bcac: mov %r10d,%r8d >> 0.08% ? 0x00007f123035bcaf: shr $0x18,%r8d ;*iushr {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 116 (line 406) >> 0.06% ? 0x00007f123035bcb3: mov %r10d,%r11d >> 0.08% ? 0x00007f123035bcb6: shr $0x10,%r11d >> 0.10% ? 0x00007f123035bcba: movzbl %r11b,%r11d ;*iand {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 99 (line 405) >> 0.14% ? 0x00007f123035bcbe: mov %r10d,%ecx >> 0.14% ? 0x00007f123035bcc1: shr $0x8,%ecx >> 0.14% ? 0x00007f123035bcc4: movzbl %r10b,%r10d ;*iand {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 59 (line 403) >> 0.08% ? 0x00007f123035bcc8: incl 0x14(%r14,%r10,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 66 (line 403) >> 0.22% ? 0x00007f123035bccd: movzbl %cl,%ecx ;*iand {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 79 (line 404) >> 0.10% ? 0x00007f123035bcd0: mov 0x10(%rsp),%r10 >> 0.14% ? 0x00007f123035bcd5: incl 0x14(%r10,%rcx,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 86 (line 404) >> 0.24% ? 0x00007f123035bcda: incl 0x14(%rbp,%r11,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 106 (line 405) >> 0.20% ? 0x00007f123035bcdf: incl 0x14(%r9,%r8,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 123 (line 406) >> 0.18% ? 0x00007f123035bce4: mov $0x80000000,%r10d >> 0.04% ? 0x00007f123035bcea: add 0x24(%rdx,%rdi,4),%r10d ;*isub {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::signed at 3 (line 476) >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 53 (line 403) >> 0.12% ? 0x00007f123035bcef: mov %r10d,%r8d >> 0.04% ? 0x00007f123035bcf2: shr $0x18,%r8d ;*iushr {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 116 (line 406) >> 0.08% ? 0x00007f123035bcf6: mov %r10d,%r11d >> 0.16% ? 0x00007f123035bcf9: shr $0x10,%r11d >> 0.06% ? 0x00007f123035bcfd: movzbl %r11b,%r11d ;*iand {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 99 (line 405) >> 0.06% ? 0x00007f123035bd01: mov %r10d,%ecx >> 0.04% ? 0x00007f123035bd04: shr $0x8,%ecx >> 0.02% ? 0x00007f123035bd07: movzbl %r10b,%r10d ;*iand {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 59 (line 403) >> 0.12% ? 0x00007f123035bd0b: incl 0x14(%r14,%r10,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 66 (line 403) >> 0.22% ? 0x00007f123035bd10: movzbl %cl,%ecx ;*iand {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 79 (line 404) >> 0.06% ? 0x00007f123035bd13: mov 0x10(%rsp),%r10 >> 0.04% ? 0x00007f123035bd18: incl 0x14(%r10,%rcx,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 86 (line 404) >> 0.20% ? 0x00007f123035bd1d: incl 0x14(%rbp,%r11,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 106 (line 405) >> 0.28% ? 0x00007f123035bd22: incl 0x14(%r9,%r8,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 123 (line 406) >> 0.46% ? 0x00007f123035bd27: mov $0x80000000,%r10d >> 0.08% ? 0x00007f123035bd2d: add 0x28(%rdx,%rdi,4),%r10d ;*isub {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::signed at 3 (line 476) >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 53 (line 403) >> 0.08% ? 0x00007f123035bd32: mov %r10d,%r8d >> 0.04% ? 0x00007f123035bd35: shr $0x18,%r8d ;*iushr {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 116 (line 406) >> 0.10% ? 0x00007f123035bd39: mov %r10d,%r11d >> 0.04% ? 0x00007f123035bd3c: shr $0x10,%r11d >> 0.06% ? 0x00007f123035bd40: movzbl %r11b,%r11d ;*iand {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 99 (line 405) >> 0.04% ? 0x00007f123035bd44: mov %r10d,%ecx >> 0.10% ? 0x00007f123035bd47: shr $0x8,%ecx >> 0.10% ? 0x00007f123035bd4a: movzbl %r10b,%r10d ;*iand {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 59 (line 403) >> 0.10% ? 0x00007f123035bd4e: incl 0x14(%r14,%r10,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 66 (line 403) >> 0.28% ? 0x00007f123035bd53: movzbl %cl,%ecx ;*iand {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 79 (line 404) >> 0.14% ? 0x00007f123035bd56: mov 0x10(%rsp),%r10 >> 0.10% ? 0x00007f123035bd5b: incl 0x14(%r10,%rcx,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 86 (line 404) >> 0.36% ? 0x00007f123035bd60: incl 0x14(%rbp,%r11,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 106 (line 405) >> 0.20% ? 0x00007f123035bd65: incl 0x14(%r9,%r8,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 123 (line 406) >> 0.28% ? 0x00007f123035bd6a: mov $0x80000000,%r10d >> 0.16% ? 0x00007f123035bd70: add 0x2c(%rdx,%rdi,4),%r10d ;*isub {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::signed at 3 (line 476) >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 53 (line 403) >> 0.08% ? 0x00007f123035bd75: mov %r10d,%r8d >> 0.10% ? 0x00007f123035bd78: shr $0x18,%r8d ;*iushr {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 116 (line 406) >> 0.08% ? 0x00007f123035bd7c: mov %r10d,%r11d >> 0.08% ? 0x00007f123035bd7f: shr $0x10,%r11d >> 0.14% ? 0x00007f123035bd83: movzbl %r11b,%r11d ;*iand {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 99 (line 405) >> 0.02% ? 0x00007f123035bd87: mov %r10d,%ecx >> 0.02% ? 0x00007f123035bd8a: shr $0x8,%ecx >> 0.20% ? 0x00007f123035bd8d: movzbl %r10b,%r10d ;*iand {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 59 (line 403) >> 0.22% ? 0x00007f123035bd91: incl 0x14(%r14,%r10,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 66 (line 403) >> 0.22% ? 0x00007f123035bd96: movzbl %cl,%ecx ;*iand {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 79 (line 404) >> 0.12% ? 0x00007f123035bd99: mov 0x10(%rsp),%r10 >> 0.04% ? 0x00007f123035bd9e: incl 0x14(%r10,%rcx,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 86 (line 404) >> 0.22% ? 0x00007f123035bda3: incl 0x14(%rbp,%r11,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 106 (line 405) >> 0.20% ? 0x00007f123035bda8: incl 0x14(%r9,%r8,4) ;*iastore {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 123 (line 406) >> 0.26% ? 0x00007f123035bdad: add $0x8,%edi ;*iinc {reexecute=0 rethrow=0 return_oop=0} >> ? ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 124 (line 402) >> 0.10% ? 0x00007f123035bdb0: cmp %esi,%edi >> ? 0x00007f123035bdb2: jl 0x00007f123035bb90 ;*if_icmpge {reexecute=0 rethrow=0 return_oop=0} >> ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 40 (line 402) >> 0x00007f123035bdb8: cmp %eax,%edi >> 0x00007f123035bdba: jge 0x00007f123035be09 ;*aload {reexecute=0 rethrow=0 return_oop=0} >> ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 43 (line 402) >> 0x00007f123035bdbc: mov $0x80000000,%esi >> 0x00007f123035bdc1: add 0x10(%rdx,%rdi,4),%esi ;*isub {reexecute=0 rethrow=0 return_oop=0} >> ; - io.github.richardstartin.radixsort.RadixSort::signed at 3 (line 476) >> ; - io.github.richardstartin.radixsort.RadixSort::unrollOnePassHistogramsSkipLevelsSigned at 53 (line 403) >> .................................................................................................... >> 18.02% >> >> >> >> So, I think there may be some room for improvement in this submission. Benchmarking is hard, and it's possible I have made a mistake or have misinterpreted the results, but I think such a big difference warrants investigation before pushing this change to so many users. I ran these benchmarks on JDK 11.0.11. I have run a range of randomised tests to verify that the two implementations produce the same results. > > So the issue of not skipping passes was my fault in the translation process, so not something to worry about, though after [fixing that](https://github.com/richardstartin/radix-sort-benchmark/commit/ccbee984c6a0e0f50c30de59e1a5e9fbcad89510) the original implementation still has the edge because of the bounds checks on the `xor` not getting eliminated. > > > Benchmark (bits) (padding) (scenario) (seed) (size) Mode Cnt Score Error Units > RadixSortBenchmark.jdk 17 7 UNIFORM 0 1000000 avgt 5 10432.408 ? 87.024 us/op > RadixSortBenchmark.jdk 23 7 UNIFORM 0 1000000 avgt 5 9465.990 ? 40.598 us/op > RadixSortBenchmark.jdk 30 7 UNIFORM 0 1000000 avgt 5 11189.146 ? 50.972 us/op > RadixSortBenchmark.unrollOnePassSkipLevelsSigned 17 7 UNIFORM 0 1000000 avgt 5 9546.963 ? 41.698 us/op > RadixSortBenchmark.unrollOnePassSkipLevelsSigned 23 7 UNIFORM 0 1000000 avgt 5 9412.114 ? 43.081 us/op > RadixSortBenchmark.unrollOnePassSkipLevelsSigned 30 7 UNIFORM 0 1000000 avgt 5 10823.618 ? 64.311 us/op Great analysis on C2, richard. maybe (x ^ 0x80) &0xFF would help C2 to eliminate bound checks... ------------- PR: https://git.openjdk.java.net/jdk/pull/3938 From github.com+16439049+richardstartin at openjdk.java.net Mon Sep 13 17:28:47 2021 From: github.com+16439049+richardstartin at openjdk.java.net (Richard Startin) Date: Mon, 13 Sep 2021 17:28:47 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) In-Reply-To: <_UUKVWVyQtw3zDw86pcbQqtvpqFAdlRvlkhnIQkC_cU=.0d144e04-7d31-49ef-b386-3906ac6909a7@github.com> References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> <75Nj_vbtmqUEj1XoUw9i3kTL140mcy6mZEmHyLyHa0U=.4eadfe72-2e17-4fa2-8f00-ba36f2c46305@github.com> <8zsz0oqYToH6u-FsIvYMrKxdJYG4AgftI9Fn5hC7v8E=.cf5db5a8-b69d-4e58-8ffd-ac86d6bd198f@github.com> <-exCZ7NcHfpt_xWuhuEsNxondubbjJQVaFmqn6jk79I=.0dae33f1-dbfd-4c07-a4ad-039070fdb62a@github.com> <2xNg3TOybhBILE2c7kj3NWIOUDQ8WgQgrCmzKnltx7E=.2997ae60-493f-462f-b54d-77c332cf5f90@github.com> <_UUKVWVyQtw3zDw86pcbQqtvpqFAdlRvlkhnIQkC_cU=.0d144e04-7d31-49ef-b386-3906ac6909a7@github.com> Message-ID: On Fri, 14 May 2021 07:14:27 GMT, Laurent Bourg?s wrote: >> So the issue of not skipping passes was my fault in the translation process, so not something to worry about, though after [fixing that](https://github.com/richardstartin/radix-sort-benchmark/commit/ccbee984c6a0e0f50c30de59e1a5e9fbcad89510) the original implementation still has the edge because of the bounds checks on the `xor` not getting eliminated. >> >> >> Benchmark (bits) (padding) (scenario) (seed) (size) Mode Cnt Score Error Units >> RadixSortBenchmark.jdk 17 7 UNIFORM 0 1000000 avgt 5 10432.408 ? 87.024 us/op >> RadixSortBenchmark.jdk 23 7 UNIFORM 0 1000000 avgt 5 9465.990 ? 40.598 us/op >> RadixSortBenchmark.jdk 30 7 UNIFORM 0 1000000 avgt 5 11189.146 ? 50.972 us/op >> RadixSortBenchmark.unrollOnePassSkipLevelsSigned 17 7 UNIFORM 0 1000000 avgt 5 9546.963 ? 41.698 us/op >> RadixSortBenchmark.unrollOnePassSkipLevelsSigned 23 7 UNIFORM 0 1000000 avgt 5 9412.114 ? 43.081 us/op >> RadixSortBenchmark.unrollOnePassSkipLevelsSigned 30 7 UNIFORM 0 1000000 avgt 5 10823.618 ? 64.311 us/op > > Great analysis on C2, richard. > > maybe (x ^ 0x80) &0xFF would help C2 to eliminate bound checks... I don't know Laurent, I find the handling of signed order over-complicated. Subtracting `Integer.MIN_VALUE` is really cheap... ------------- PR: https://git.openjdk.java.net/jdk/pull/3938 From lbourges at openjdk.java.net Mon Sep 13 17:28:47 2021 From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Mon, 13 Sep 2021 17:28:47 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) In-Reply-To: References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> <75Nj_vbtmqUEj1XoUw9i3kTL140mcy6mZEmHyLyHa0U=.4eadfe72-2e17-4fa2-8f00-ba36f2c46305@github.com> <8zsz0oqYToH6u-FsIvYMrKxdJYG4AgftI9Fn5hC7v8E=.cf5db5a8-b69d-4e58-8ffd-ac86d6bd198f@github.com> <-exCZ7NcHfpt_xWuhuEsNxondubbjJQVaFmqn6jk79I=.0dae33f1-dbfd-4c07-a4ad-039070fdb62a@github.com> <2xNg3TOybhBILE2c7kj3NWIOUDQ8WgQgrCmzKnltx7E=.2997ae60-493f-462f-b54d-77c332cf5f90@github.com> <_UUKVWVyQtw3zDw86pcbQqtvpqFAdlRvlkhnIQkC_cU=.0d144e04-7d31-49ef-b386-3906ac6909a7@github.com> Message-ID: On Fri, 14 May 2021 17:50:11 GMT, Piotr Tarsa wrote: >> I made a JMH test on jdk16 to test count4 (xor) performance: >> https://github.com/bourgesl/nearly-optimal-mergesort-code/tree/master/sort-bench/results/count_xor >> >> >> Benchmark (size) Mode Cnt Score Error Units >> ArrayXorBenchmark.arrayAndOriginal 1000000 avgt 20 684561,951 ? 2177,120 ns/op >> ArrayXorBenchmark.arrayXorOriginal 1000000 avgt 20 777255,465 ? 1815,136 ns/op >> ArrayXorBenchmark.arrayXor_Masked 1000000 avgt 20 814163,377 ? 2665,436 ns/op >> ArrayXorBenchmark.arrayXor_Unsafe 1000000 avgt 20 707273,922 ? 2994,380 ns/op >> >> Masked xor does not get optimized by c2 too. >> >> Using Unsafe is better, see: >> https://github.com/bourgesl/nearly-optimal-mergesort-code/blob/master/sort-bench/src/main/java/edu/sorting/bench/ArrayXorBenchmark.java >> >> If you want, I could make another radixsort() using on or off heap count buffers and Unsafe, as I did in Marlin to avoid bound checks... > > I think an uncontroversial and efficient solution would be to replace > > count4[(a[i] >>> 24) ^ 0x80]--; > > with > > count4[(a[i] >>> 24) & 0xFF]--; > > and after finishing counting, first half of `count4` should be swapped with second half of `count4`. FYI I made another radixsortNew() using Unsafe to access to all count arrays: https://github.com/bourgesl/nearly-optimal-mergesort-code/blob/dbfbd731ffd798defc75528cc1db04063bdb4619/src/edu/sorting/DualPivotQuicksort202105.java#L795 But it is only 2% faster in radix-sort-benchmark (1M arrays): https://github.com/bourgesl/radix-sort-benchmark/blob/main/results/2021-ref/cmp-16-1M-full.log It looks not worth the extra complexity for few percents, I think. ------------- PR: https://git.openjdk.java.net/jdk/pull/3938 From lbourges at openjdk.java.net Mon Sep 13 17:28:47 2021 From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Mon, 13 Sep 2021 17:28:47 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) In-Reply-To: References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> <75Nj_vbtmqUEj1XoUw9i3kTL140mcy6mZEmHyLyHa0U=.4eadfe72-2e17-4fa2-8f00-ba36f2c46305@github.com> <8zsz0oqYToH6u-FsIvYMrKxdJYG4AgftI9Fn5hC7v8E=.cf5db5a8-b69d-4e58-8ffd-ac86d6bd198f@github.com> <-exCZ7NcHfpt_xWuhuEsNxondubbjJQVaFmqn6jk79I=.0dae33f1-dbfd-4c07-a4ad-039070fdb62a@github.com> <2xNg3TOybhBILE2c7kj3NWIOUDQ8WgQgrCmzKnltx7E=.2997ae60-493f-462f-b54d-77c332cf5f90@github.com> <_UUKVWVyQtw3zDw86pcbQqtvpqFAdlRvlkhnIQkC_cU=.0d144e04-7d31-49ef-b386-3906ac6909a7@github.com> Message-ID: On Fri, 14 May 2021 07:41:19 GMT, Richard Startin wrote: >> Great analysis on C2, richard. >> >> maybe (x ^ 0x80) &0xFF would help C2 to eliminate bound checks... > > I don't know Laurent, I find the handling of signed order over-complicated. Subtracting `Integer.MIN_VALUE` is really cheap... I made a JMH test on jdk16 to test count4 (xor) performance: https://github.com/bourgesl/nearly-optimal-mergesort-code/tree/master/sort-bench/results/count_xor Benchmark (size) Mode Cnt Score Error Units ArrayXorBenchmark.arrayAndOriginal 1000000 avgt 20 684561,951 ? 2177,120 ns/op ArrayXorBenchmark.arrayXorOriginal 1000000 avgt 20 777255,465 ? 1815,136 ns/op ArrayXorBenchmark.arrayXor_Masked 1000000 avgt 20 814163,377 ? 2665,436 ns/op ArrayXorBenchmark.arrayXor_Unsafe 1000000 avgt 20 707273,922 ? 2994,380 ns/op Masked xor does not get optimized by c2 too. Using Unsafe is better, see: https://github.com/bourgesl/nearly-optimal-mergesort-code/blob/master/sort-bench/src/main/java/edu/sorting/bench/ArrayXorBenchmark.java If you want, I could make another radixsort() using on or off heap count buffers and Unsafe, as I did in Marlin to avoid bound checks... ------------- PR: https://git.openjdk.java.net/jdk/pull/3938 From github.com+1282159+tarsa at openjdk.java.net Mon Sep 13 17:28:47 2021 From: github.com+1282159+tarsa at openjdk.java.net (Piotr Tarsa) Date: Mon, 13 Sep 2021 17:28:47 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) In-Reply-To: References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> <75Nj_vbtmqUEj1XoUw9i3kTL140mcy6mZEmHyLyHa0U=.4eadfe72-2e17-4fa2-8f00-ba36f2c46305@github.com> <8zsz0oqYToH6u-FsIvYMrKxdJYG4AgftI9Fn5hC7v8E=.cf5db5a8-b69d-4e58-8ffd-ac86d6bd198f@github.com> <-exCZ7NcHfpt_xWuhuEsNxondubbjJQVaFmqn6jk79I=.0dae33f1-dbfd-4c07-a4ad-039070fdb62a@github.com> <2xNg3TOybhBILE2c7kj3NWIOUDQ8WgQgrCmzKnltx7E=.2997ae60-493f-462f-b54d-77c332cf5f90@github.com> <_UUKVWVyQtw3zDw86pcbQqtvpqFAdlRvlkhnIQkC_cU=.0d144e04-7d31-49ef-b386-3906ac6909a7@github.com> Message-ID: On Fri, 14 May 2021 13:18:27 GMT, Laurent Bourg?s wrote: >> I don't know Laurent, I find the handling of signed order over-complicated. Subtracting `Integer.MIN_VALUE` is really cheap... > > I made a JMH test on jdk16 to test count4 (xor) performance: > https://github.com/bourgesl/nearly-optimal-mergesort-code/tree/master/sort-bench/results/count_xor > > > Benchmark (size) Mode Cnt Score Error Units > ArrayXorBenchmark.arrayAndOriginal 1000000 avgt 20 684561,951 ? 2177,120 ns/op > ArrayXorBenchmark.arrayXorOriginal 1000000 avgt 20 777255,465 ? 1815,136 ns/op > ArrayXorBenchmark.arrayXor_Masked 1000000 avgt 20 814163,377 ? 2665,436 ns/op > ArrayXorBenchmark.arrayXor_Unsafe 1000000 avgt 20 707273,922 ? 2994,380 ns/op > > Masked xor does not get optimized by c2 too. > > Using Unsafe is better, see: > https://github.com/bourgesl/nearly-optimal-mergesort-code/blob/master/sort-bench/src/main/java/edu/sorting/bench/ArrayXorBenchmark.java > > If you want, I could make another radixsort() using on or off heap count buffers and Unsafe, as I did in Marlin to avoid bound checks... I think an uncontroversial and efficient solution would be to replace count4[(a[i] >>> 24) ^ 0x80]--; with count4[(a[i] >>> 24) & 0xFF]--; and after finishing counting, first half of `count4` should be swapped with second half of `count4`. ------------- PR: https://git.openjdk.java.net/jdk/pull/3938 From github.com+689138+jhorstmann at openjdk.java.net Mon Sep 13 17:28:48 2021 From: github.com+689138+jhorstmann at openjdk.java.net (=?UTF-8?B?SsO2cm4=?= Horstmann) Date: Mon, 13 Sep 2021 17:28:48 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) In-Reply-To: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> Message-ID: <8Ba31LPnIJajfU4KJZ7WOZG1FVQzZj4tiYpjtMIovhI=.d92f337e-db3e-44ce-977b-9183116b2439@github.com> On Sat, 8 May 2021 20:54:48 GMT, iaroslavski wrote: > Sorting: > > - adopt radix sort for sequential and parallel sorts on int/long/float/double arrays (almost random and length > 6K) > - fix tryMergeRuns() to better handle case when the last run is a single element > - minor javadoc and comment changes > > Testing: > - add new data inputs in tests for sorting > - add min/max/infinity values to float/double testing > - add tests for radix sort src/java.base/share/classes/java/util/DualPivotQuicksort.java line 669: > 667: > 668: for (int i = low; i < high; ++i) { > 669: count1[ a[i] & 0xFF]--; Not a reviewer, but having recently implemented a radixsort myself I'm wondering what is the logic or benefit of decrementing and counting backwards here? One thing I did differently, and I'm not fully sure is an optimization, is remembering the last bucket for each of the 4 counts. Checking whether the data is already sorted by that digit can then be done by checking `count[last_bucket] == size`, which avoids the first loop in `passLevel`. Again, not sure whether it is actually faster, maybe the two separate simple loops like here are better. ------------- PR: https://git.openjdk.java.net/jdk/pull/3938 From github.com+43264149+iaroslavski at openjdk.java.net Mon Sep 13 17:28:48 2021 From: github.com+43264149+iaroslavski at openjdk.java.net (iaroslavski) Date: Mon, 13 Sep 2021 17:28:48 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) In-Reply-To: <8Ba31LPnIJajfU4KJZ7WOZG1FVQzZj4tiYpjtMIovhI=.d92f337e-db3e-44ce-977b-9183116b2439@github.com> References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> <8Ba31LPnIJajfU4KJZ7WOZG1FVQzZj4tiYpjtMIovhI=.d92f337e-db3e-44ce-977b-9183116b2439@github.com> Message-ID: On Tue, 11 May 2021 14:37:21 GMT, J?rn Horstmann wrote: >> Sorting: >> >> - adopt radix sort for sequential and parallel sorts on int/long/float/double arrays (almost random and length > 6K) >> - fix tryMergeRuns() to better handle case when the last run is a single element >> - minor javadoc and comment changes >> >> Testing: >> - add new data inputs in tests for sorting >> - add min/max/infinity values to float/double testing >> - add tests for radix sort > > src/java.base/share/classes/java/util/DualPivotQuicksort.java line 669: > >> 667: >> 668: for (int i = low; i < high; ++i) { >> 669: count1[ a[i] & 0xFF]--; > > Not a reviewer, but having recently implemented a radixsort myself I'm wondering what is the logic or benefit of decrementing and counting backwards here? > > One thing I did differently, and I'm not fully sure is an optimization, is remembering the last bucket for each of the 4 counts. Checking whether the data is already sorted by that digit can then be done by checking `count[last_bucket] == size`, which avoids the first loop in `passLevel`. Again, not sure whether it is actually faster, maybe the two separate simple loops like here are better. @jhorstmann In counting backwards we perform comparing with 0 in a loop, Comparing with 0 may be faster than comparing with other value. In general, backward or forward moving is your favor. Keeping last_bucket and use check count[last_bucket] == size sounds good, but we need to run benchmarking and compare. I think we will not see big difference because the size of count array is too small, 256 only, whereas we scan whole array with size at least 6K. The corner case when we can see max effect of using last_bucket is array with all equal elements (4 count arrays will have only one non-zero element). but such array will be caught by tryMerge method. ------------- PR: https://git.openjdk.java.net/jdk/pull/3938 From github.com+16439049+richardstartin at openjdk.java.net Mon Sep 13 17:28:49 2021 From: github.com+16439049+richardstartin at openjdk.java.net (Richard Startin) Date: Mon, 13 Sep 2021 17:28:49 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) In-Reply-To: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> Message-ID: On Sat, 8 May 2021 20:54:48 GMT, iaroslavski wrote: > Sorting: > > - adopt radix sort for sequential and parallel sorts on int/long/float/double arrays (almost random and length > 6K) > - fix tryMergeRuns() to better handle case when the last run is a single element > - minor javadoc and comment changes > > Testing: > - add new data inputs in tests for sorting > - add min/max/infinity values to float/double testing > - add tests for radix sort src/java.base/share/classes/java/util/DualPivotQuicksort.java line 672: > 670: count2[(a[i] >>> 8) & 0xFF]--; > 671: count3[(a[i] >>> 16) & 0xFF]--; > 672: count4[(a[i] >>> 24) ^ 0x80]--; It seems that C2 can't eliminate the bounds check here because of the `xor`, even though this can't possibly exceed 256. The three masked accesses above are all eliminated. Maybe someone could look in to improving that. ------------- PR: https://git.openjdk.java.net/jdk/pull/3938 From neliasso at openjdk.java.net Mon Sep 13 17:28:50 2021 From: neliasso at openjdk.java.net (Nils Eliasson) Date: Mon, 13 Sep 2021 17:28:50 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) In-Reply-To: References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> Message-ID: On Thu, 13 May 2021 20:47:48 GMT, Richard Startin wrote: >> Sorting: >> >> - adopt radix sort for sequential and parallel sorts on int/long/float/double arrays (almost random and length > 6K) >> - fix tryMergeRuns() to better handle case when the last run is a single element >> - minor javadoc and comment changes >> >> Testing: >> - add new data inputs in tests for sorting >> - add min/max/infinity values to float/double testing >> - add tests for radix sort > > src/java.base/share/classes/java/util/DualPivotQuicksort.java line 672: > >> 670: count2[(a[i] >>> 8) & 0xFF]--; >> 671: count3[(a[i] >>> 16) & 0xFF]--; >> 672: count4[(a[i] >>> 24) ^ 0x80]--; > > It seems that C2 can't eliminate the bounds check here because of the `xor`, even though this can't possibly exceed 256. The three masked accesses above are all eliminated. Maybe someone could look in to improving that. https://bugs.openjdk.java.net/browse/JDK-8267332 ------------- PR: https://git.openjdk.java.net/jdk/pull/3938 From github.com+43264149+iaroslavski at openjdk.java.net Mon Sep 13 17:28:50 2021 From: github.com+43264149+iaroslavski at openjdk.java.net (iaroslavski) Date: Mon, 13 Sep 2021 17:28:50 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) In-Reply-To: References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> Message-ID: <83UXJ659mscq_GpjAIt4bLBPBTivPWRFeMMZW4dKpeU=.24bb4c35-3f43-460f-b011-010053102cd2@github.com> On Tue, 18 May 2021 18:06:21 GMT, Nils Eliasson wrote: >> src/java.base/share/classes/java/util/DualPivotQuicksort.java line 672: >> >>> 670: count2[(a[i] >>> 8) & 0xFF]--; >>> 671: count3[(a[i] >>> 16) & 0xFF]--; >>> 672: count4[(a[i] >>> 24) ^ 0x80]--; >> >> It seems that C2 can't eliminate the bounds check here because of the `xor`, even though this can't possibly exceed 256. The three masked accesses above are all eliminated. Maybe someone could look in to improving that. > > https://bugs.openjdk.java.net/browse/JDK-8267332 I agree with Laurent (bourgesl), see his comment on May 15 regarding to xor: using Unsafe is only 2% faster, not worth the extra complexity for few percent. ------------- PR: https://git.openjdk.java.net/jdk/pull/3938 From lbourges at openjdk.java.net Mon Sep 13 17:28:50 2021 From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Mon, 13 Sep 2021 17:28:50 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) In-Reply-To: <4hnqP-IQBm9Cp1IBEl-TmajiBVJGZgajbuZMroCUZTk=.afd3ab72-5cd0-481e-9f7f-cd24a3b15721@github.com> References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> <83UXJ659mscq_GpjAIt4bLBPBTivPWRFeMMZW4dKpeU=.24bb4c35-3f43-460f-b011-010053102cd2@github.com> <4hnqP-IQBm9Cp1IBEl-TmajiBVJGZgajbuZMroCUZTk=.afd3ab72-5cd0-481e-9f7f-cd24a3b15721@github.com> Message-ID: <01WkM55Ydb-m0XHTsyw9_sz6-wXRxtVo0MVxt_9f71E=.680c9a9b-407b-486d-9a06-c9c6a434388a@github.com> On Thu, 20 May 2021 21:21:26 GMT, Nils Eliasson wrote: >> A small update of the XorINodes type calculation makes the bound check go away. Testing now. > > That bounds check shouldn't be there, it's an obvious case and will be fixed: https://github.com/openjdk/jdk/pull/4136 Thanks for fixing hotspot C2 (xor) so quickly ! ------------- PR: https://git.openjdk.java.net/jdk/pull/3938 From neliasso at openjdk.java.net Mon Sep 13 17:28:50 2021 From: neliasso at openjdk.java.net (Nils Eliasson) Date: Mon, 13 Sep 2021 17:28:50 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) In-Reply-To: References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> <83UXJ659mscq_GpjAIt4bLBPBTivPWRFeMMZW4dKpeU=.24bb4c35-3f43-460f-b011-010053102cd2@github.com> Message-ID: <4hnqP-IQBm9Cp1IBEl-TmajiBVJGZgajbuZMroCUZTk=.afd3ab72-5cd0-481e-9f7f-cd24a3b15721@github.com> On Thu, 20 May 2021 08:03:03 GMT, Nils Eliasson wrote: >> I agree with Laurent (bourgesl), see his comment on May 15 regarding to xor: >> using Unsafe is only 2% faster, not worth the extra complexity for few percent. > > A small update of the XorINodes type calculation makes the bound check go away. Testing now. That bounds check shouldn't be there, it's an obvious case and will be fixed: https://github.com/openjdk/jdk/pull/4136 ------------- PR: https://git.openjdk.java.net/jdk/pull/3938 From neliasso at openjdk.java.net Mon Sep 13 17:28:50 2021 From: neliasso at openjdk.java.net (Nils Eliasson) Date: Mon, 13 Sep 2021 17:28:50 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) In-Reply-To: <83UXJ659mscq_GpjAIt4bLBPBTivPWRFeMMZW4dKpeU=.24bb4c35-3f43-460f-b011-010053102cd2@github.com> References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> <83UXJ659mscq_GpjAIt4bLBPBTivPWRFeMMZW4dKpeU=.24bb4c35-3f43-460f-b011-010053102cd2@github.com> Message-ID: On Tue, 18 May 2021 19:58:35 GMT, iaroslavski wrote: >> https://bugs.openjdk.java.net/browse/JDK-8267332 > > I agree with Laurent (bourgesl), see his comment on May 15 regarding to xor: > using Unsafe is only 2% faster, not worth the extra complexity for few percent. A small update of the XorINodes type calculation makes the bound check go away. Testing now. ------------- PR: https://git.openjdk.java.net/jdk/pull/3938 From prappo at openjdk.java.net Mon Sep 13 17:48:58 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Mon, 13 Sep 2021 17:48:58 GMT Subject: Integrated: 8273616: Fix trivial doc typos in the java.base module In-Reply-To: References: Message-ID: On Fri, 10 Sep 2021 21:16:19 GMT, Pavel Rappo wrote: > 8273616: Fix trivial doc typos in the java.base module This pull request has now been integrated. Changeset: b4b12101 Author: Pavel Rappo URL: https://git.openjdk.java.net/jdk/commit/b4b121018d16e531f3a51ff75ae37fdc374d530b Stats: 55 lines in 34 files changed: 0 ins; 0 del; 55 mod 8273616: Fix trivial doc typos in the java.base module Reviewed-by: jrose, iris, lancea, dfuchs, rriggs ------------- PR: https://git.openjdk.java.net/jdk/pull/5475 From bpb at openjdk.java.net Mon Sep 13 17:54:01 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 13 Sep 2021 17:54:01 GMT Subject: Integrated: 8273513: Make java.io.FilterInputStream specification more precise about overrides In-Reply-To: References: Message-ID: On Wed, 8 Sep 2021 22:00:53 GMT, Brian Burkhalter wrote: > Modify the class level specification of `java.io.FilterInputStream` to be more exact about `java.io.InputStream` methods that it overrides. This pull request has now been integrated. Changeset: 6cf5079d Author: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/6cf5079d8e789c82646a3e16b1763e2c7646d400 Stats: 54 lines in 1 file changed: 21 ins; 9 del; 24 mod 8273513: Make java.io.FilterInputStream specification more precise about overrides Reviewed-by: dfuchs, naoto ------------- PR: https://git.openjdk.java.net/jdk/pull/5426 From github.com+27751938+amcap1712 at openjdk.java.net Mon Sep 13 17:57:24 2021 From: github.com+27751938+amcap1712 at openjdk.java.net (Kartik Ohri) Date: Mon, 13 Sep 2021 17:57:24 GMT Subject: RFR: 8273681: Add Vector API vs Arrays.mismatch intrinsic benchmark Message-ID: <4KB5kKx9tx7ORFdIm3DvI_A4Udv16Vd-RFSHHIsCZoI=.0a05541b-051a-4009-b198-b4f0a576cb5c@github.com> Hi all! Please review this PR to add a benchmark comparing the performance of Arrays.mismatch intrinsic in the JDK with that of the Vector API. Kindly refer to this [thread] on panama-dev regarding some initial discussion about this benchmark. I have attached the [results] of the full benchmark run along with the [assembly] output of a shorter run I had done while analysing the results. The benchmarks were run against the latest build of panama-vector available from builds.shipilev.net. Also, I have not added the copyright header to this file yet as I am an individual contributor (OCA signed) and do not know what to put there. [thread]: https://mail.openjdk.java.net/pipermail/panama-dev/2021-September/014839.html [results]: https://github.com/openjdk/jdk/files/7142452/results.csv [assembly]: https://github.com/openjdk/jdk/files/7142362/benchmarks.txt Regards, Kartik ------------- Commit messages: - Add Vector API vs Arrays.mismatch intrinsic benchmark Changes: https://git.openjdk.java.net/jdk/pull/5459/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5459&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273681 Stats: 213 lines in 1 file changed: 213 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5459.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5459/head:pull/5459 PR: https://git.openjdk.java.net/jdk/pull/5459 From alanb at openjdk.java.net Mon Sep 13 18:05:54 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 13 Sep 2021 18:05:54 GMT Subject: RFR: 8272515: JFR: Names should only be valid Java identifiers In-Reply-To: References: Message-ID: On Wed, 8 Sep 2021 13:00:17 GMT, Erik Gahlin wrote: > Hi, > > Could I have a review of change that prevents invalid Java identifiers or type names in JFR events. For rationale and compatibility issues see the CSR request. The only change to java.base is making jdk.modules.internal.Checks::isJavaIdentifier(String) public, so it can be reused by the jdk.jfr module. > > Testing: /jdk/jdk/jfr + tier1 + tier2 > > Thanks > Erik src/java.base/share/classes/jdk/internal/module/Checks.java line 171: > 169: * otherwise false. > 170: */ > 171: public static boolean isJavaIdentifier(String str) { I see Checks is already used by code in the jdk.jlink and jdk.jartool module so probably okay if JFR uses it. At some point we need to get back to trimming back the qualified exports to avoid too much back sliding into a ball of mud. ------------- PR: https://git.openjdk.java.net/jdk/pull/5415 From psandoz at openjdk.java.net Mon Sep 13 18:09:00 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Mon, 13 Sep 2021 18:09:00 GMT Subject: RFR: 8273681: Add Vector API vs Arrays.mismatch intrinsic benchmark In-Reply-To: <4KB5kKx9tx7ORFdIm3DvI_A4Udv16Vd-RFSHHIsCZoI=.0a05541b-051a-4009-b198-b4f0a576cb5c@github.com> References: <4KB5kKx9tx7ORFdIm3DvI_A4Udv16Vd-RFSHHIsCZoI=.0a05541b-051a-4009-b198-b4f0a576cb5c@github.com> Message-ID: On Fri, 10 Sep 2021 08:32:02 GMT, Kartik Ohri wrote: > Hi all! > > Please review this PR to add a benchmark comparing the performance of Arrays.mismatch intrinsic in the JDK with that of the Vector API. Kindly refer to this [thread] on panama-dev regarding some initial discussion about this benchmark. I have attached the [results] of the full benchmark run along with the [assembly] output of a shorter run I had done while analysing the results. The benchmarks were run against the latest build of panama-vector available from builds.shipilev.net. > > Also, I have not added the copyright header to this file yet as I am an individual contributor (OCA signed) and do not know what to put there. > > [thread]: https://mail.openjdk.java.net/pipermail/panama-dev/2021-September/014839.html > [results]: https://github.com/openjdk/jdk/files/7142452/results.csv > [assembly]: https://github.com/openjdk/jdk/files/7142362/benchmarks.txt > > Regards, > Kartik The simplest approach is to copy the license from here https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/jdk/incubator/vector/RotateBenchmark.java ------------- PR: https://git.openjdk.java.net/jdk/pull/5459 From psandoz at openjdk.java.net Mon Sep 13 18:22:50 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Mon, 13 Sep 2021 18:22:50 GMT Subject: RFR: 8273681: Add Vector API vs Arrays.mismatch intrinsic benchmark In-Reply-To: <4KB5kKx9tx7ORFdIm3DvI_A4Udv16Vd-RFSHHIsCZoI=.0a05541b-051a-4009-b198-b4f0a576cb5c@github.com> References: <4KB5kKx9tx7ORFdIm3DvI_A4Udv16Vd-RFSHHIsCZoI=.0a05541b-051a-4009-b198-b4f0a576cb5c@github.com> Message-ID: On Fri, 10 Sep 2021 08:32:02 GMT, Kartik Ohri wrote: > Hi all! > > Please review this PR to add a benchmark comparing the performance of Arrays.mismatch intrinsic in the JDK with that of the Vector API. Kindly refer to this [thread] on panama-dev regarding some initial discussion about this benchmark. I have attached the [results] of the full benchmark run along with the [assembly] output of a shorter run I had done while analysing the results. The benchmarks were run against the latest build of panama-vector available from builds.shipilev.net. > > Also, I have not added the copyright header to this file yet as I am an individual contributor (OCA signed) and do not know what to put there. > > [thread]: https://mail.openjdk.java.net/pipermail/panama-dev/2021-September/014839.html > [results]: https://github.com/openjdk/jdk/files/7142452/results.csv > [assembly]: https://github.com/openjdk/jdk/files/7142362/benchmarks.txt > > Regards, > Kartik Benchmark looks good (assuming license is added). test/micro/org/openjdk/bench/jdk/incubator/vector/ArrayMismatchBenchmark.java line 52: > 50: static final VectorSpecies LONG_SPECIES_PREFERRED = LongVector.SPECIES_PREFERRED; > 51: > 52: static final Random random = new Random(); We could use the recently added `RandomGenerator` instead in the spirit of encouraging the use of new and preferred APIs: - remove the static field - replace `FLOAT_SPECIES` with `DOUBLE_SPECIES` - in `setup` create an instance `RandomGenerator rg = RandomGenerator.getDefault()` - remove `createRandomFloats` and use `rg.doubles(...).toArray()` ------------- PR: https://git.openjdk.java.net/jdk/pull/5459 From igraves at openjdk.java.net Mon Sep 13 21:54:11 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Mon, 13 Sep 2021 21:54:11 GMT Subject: Integrated: 8273430: Suspicious duplicate condition in java.util.regex.Grapheme#isExcludedSpacingMark In-Reply-To: <7eQexh7uLUwH-Mh_P_Hdq4clffXUKIRsHhVBWEUYNuA=.04a7b8fa-ba90-4a01-9c08-99604a76c7c2@github.com> References: <7eQexh7uLUwH-Mh_P_Hdq4clffXUKIRsHhVBWEUYNuA=.04a7b8fa-ba90-4a01-9c08-99604a76c7c2@github.com> Message-ID: On Wed, 8 Sep 2021 20:24:31 GMT, Ian Graves wrote: > The duplicate condition in this chain of expressions needs to be shrunk to drop a couple of character that are not excluded spacing marks. This pull request has now been integrated. Changeset: 3d9dc8f8 Author: Ian Graves URL: https://git.openjdk.java.net/jdk/commit/3d9dc8f824abf597d9b28f456cfeb5af927221b8 Stats: 539 lines in 4 files changed: 147 ins; 388 del; 4 mod 8273430: Suspicious duplicate condition in java.util.regex.Grapheme#isExcludedSpacingMark Reviewed-by: naoto ------------- PR: https://git.openjdk.java.net/jdk/pull/5425 From ecki at zusammenkunft.net Tue Sep 14 00:40:05 2021 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Tue, 14 Sep 2021 00:40:05 +0000 Subject: RFR: 8258117: jar tool sets the time stamp of module-info.class entries to the current time In-Reply-To: References: Message-ID: Is there support for repeatable builds planned? Using the source file might be acceptable, but the class file timestamp could be changing more likely for repeated builds? -- http://bernd.eckenfels.net ________________________________ Von: core-libs-dev im Auftrag von Jaikiran Pai Gesendet: Monday, September 13, 2021 7:44:22 AM An: compiler-dev at openjdk.java.net ; core-libs-dev at openjdk.java.net Betreff: RFR: 8258117: jar tool sets the time stamp of module-info.class entries to the current time The commit here is a potential fix for the issue noted in https://bugs.openjdk.java.net/browse/JDK-8258117. The change here repurposes an existing internal interface `ModuleInfoEntry` to keep track of the last modified timestamp of a `module-info.class` descriptor. This commit uses the timestamp of the `module-info.class` on the filesystem to set the time on the `JarEntry`. There are a couple of cases to consider here: 1. When creating a jar (using `--create`), we use the source `module-info.class` from the filesystem and then add extended info to it (attributes like packages, module version etc...). In such cases, this patch will use the lastmodified timestamp from the filesystem of `module-info.class` even though we might end up updating/extending/modifying (for example by adding a module version) its content while storing it as a `JarEntry`. 2. When updating a jar (using `--update`), this patch will use the lastmodified timestamp of `module-info.class` either from the filesystem or from the source jar's entry (depending on whether a new `module-info.class` is being passed to the command). Here too, it's possible that we might end up changing/modifying/extending the `module-info.class` (for example, changing the module version to a new version) that gets written into the updated jar file, but this patch _won't_ use `System.currentTimeMillis()` even in such cases. If we do have to track actual changes that might happen to `module-info.class` while extending its info (in `extendedInfoBytes()`) and then decide whether to use current system time as last modified time, then this will require a bigger change and also a discussion on what kind of extending of module-info.class content will require a change to the lastmodifiedtime of that entry. ------------- Commit messages: - 8258117: jar tool sets the time stamp of module-info.class entries to the current time Changes: https://git.openjdk.java.net/jdk/pull/5486/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5486&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258117 Stats: 317 lines in 2 files changed: 298 ins; 0 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/5486.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5486/head:pull/5486 PR: https://git.openjdk.java.net/jdk/pull/5486 From dholmes at openjdk.java.net Tue Sep 14 00:54:29 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 14 Sep 2021 00:54:29 GMT Subject: RFR: 8273691: Missing comma after 2021 in GraphemeTestAccessor.java copyright notice Message-ID: Please review this trivial fix to add the missing comma. Thanks, David ------------- Commit messages: - 8273691: Missing comma after 2021 in GraphemeTestAccessor.java copyright notice Changes: https://git.openjdk.java.net/jdk/pull/5504/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5504&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273691 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5504.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5504/head:pull/5504 PR: https://git.openjdk.java.net/jdk/pull/5504 From psandoz at openjdk.java.net Tue Sep 14 00:58:09 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Tue, 14 Sep 2021 00:58:09 GMT Subject: RFR: 8273691: Missing comma after 2021 in GraphemeTestAccessor.java copyright notice In-Reply-To: References: Message-ID: On Tue, 14 Sep 2021 00:15:31 GMT, David Holmes wrote: > Please review this trivial fix to add the missing comma. > > Thanks, > David Marked as reviewed by psandoz (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5504 From igraves at openjdk.java.net Tue Sep 14 00:58:09 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Tue, 14 Sep 2021 00:58:09 GMT Subject: RFR: 8273691: Missing comma after 2021 in GraphemeTestAccessor.java copyright notice In-Reply-To: References: Message-ID: On Tue, 14 Sep 2021 00:15:31 GMT, David Holmes wrote: > Please review this trivial fix to add the missing comma. > > Thanks, > David LGTM. Thanks @dholmes-ora ------------- PR: https://git.openjdk.java.net/jdk/pull/5504 From dholmes at openjdk.java.net Tue Sep 14 01:03:38 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 14 Sep 2021 01:03:38 GMT Subject: RFR: 8273691: Missing comma after 2021 in GraphemeTestAccessor.java copyright notice In-Reply-To: References: Message-ID: On Tue, 14 Sep 2021 00:15:31 GMT, David Holmes wrote: > Please review this trivial fix to add the missing comma. > > Thanks, > David Thanks Paul and Ian! ------------- PR: https://git.openjdk.java.net/jdk/pull/5504 From dholmes at openjdk.java.net Tue Sep 14 01:04:21 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 14 Sep 2021 01:04:21 GMT Subject: Integrated: 8273691: Missing comma after 2021 in GraphemeTestAccessor.java copyright notice In-Reply-To: References: Message-ID: On Tue, 14 Sep 2021 00:15:31 GMT, David Holmes wrote: > Please review this trivial fix to add the missing comma. > > Thanks, > David This pull request has now been integrated. Changeset: c54a918a Author: David Holmes URL: https://git.openjdk.java.net/jdk/commit/c54a918a0e526403a395ad76c1dd0519be136ac7 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8273691: Missing comma after 2021 in GraphemeTestAccessor.java copyright notice Reviewed-by: psandoz ------------- PR: https://git.openjdk.java.net/jdk/pull/5504 From jai.forums2013 at gmail.com Tue Sep 14 01:36:13 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Tue, 14 Sep 2021 07:06:13 +0530 Subject: RFR: 8258117: jar tool sets the time stamp of module-info.class entries to the current time In-Reply-To: References: Message-ID: <4097a3d1-9f0b-aabf-9908-131f2aa390a3@gmail.com> Hello Bernd, On 14/09/21 6:10 am, Bernd Eckenfels wrote: > Is there support for repeatable builds planned? Using the source file might be acceptable, but the class file timestamp could be changing more likely for repeated builds? To clarify the description of my PR, this change uses the timestamp of the (compiled) module-info.class file that is being added/updated to the jar. -Jaikiran From jpai at openjdk.java.net Tue Sep 14 02:26:03 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 14 Sep 2021 02:26:03 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v12] In-Reply-To: References: Message-ID: > The commit in this PR implements the proposal for enhancement that was discussed in the core-libs-dev mailing list recently[1], for https://bugs.openjdk.java.net/browse/JDK-8231640 > > At a high level - the `store()` APIs in `Properties` have been modified to now look for the `SOURCE_DATE_EPOCH` environment variable[2]. If that env variable is set, then instead of writing out the current date time as a date comment, the `store()` APIs instead will use the value set for this env variable to parse it to a `Date` and write out the string form of such a date. The implementation here uses the `d MMM yyyy HH:mm:ss 'GMT'` date format and `Locale.ROOT` to format and write out such a date. This should provide reproducibility whenever the `SOURCE_DATE_EPOCH` is set. Furthermore, intentionally, no changes in the date format of the "current date" have been done. > > These modified `store()` APIs work in the presence of the `SecurityManager` too. The caller is expected to have a read permission on the `SOURCE_DATE_EPOCH` environment variable. If the caller doesn't have that permission, then the implementation of these `store()` APIs will write out the "current date" and will ignore any value that has been set for the `SOURCE_DATE_EPOCH` env variable. This should allow for backward compatibility of existing applications, where, when they run under a `SecurityManager` and perhaps with an existing restrictive policy file, the presence of `SOURCE_DATE_EPOCH` shouldn't impact their calls to the `store()` APIs. > > The modified `store()` APIs will also ignore any value for `SOURCE_DATE_EPOCH` that cannot be parsed to an `long` value. In such cases, the `store()` APIs will write out the "current date" and ignore the value set for this environment variable. No exceptions will be thrown for such invalid values. This is an additional backward compatibility precaution to prevent any rogue value for `SOURCE_DATE_EPOCH` from breaking applications. > > An additional change in the implementation of these `store()` APIs and unrelated to the date comment, is that these APIs will now write out the property keys in a deterministic order. The keys will be written out in the natural ordering as specified by `java.lang.String#compareTo()` API. > > The combination of the ordering of the property keys when written out and the usage of `SOURCE_DATE_EPOCH` environment value to determine the date comment should together allow for reproducibility of the output generated by these `store()` APIs. > > New jtreg test classes have been introduced to verify these changes. The primary focus of `PropertiesStoreTest` is the ordering aspects of the property keys that are written out. On the other hand `StoreReproducibilityTest` focuses on the reproducibility of the output generated by these APIs. The `StoreReproducibilityTest` runs these tests both in the presence and absence of `SecurityManager`. Plus, in the presence of SecurityManager, it tests both the scenarios where the caller is granted the requisite permission and in other case not granted that permission. > > These new tests and existing tests under `test/jdk/java/util/Properties/` pass with these changes. > > [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-August/080758.html > [2] https://reproducible-builds.org/specs/source-date-epoch/ Jaikiran Pai 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 16 additional commits since the last revision: - Merge latest from master branch - Implement Roger's and the agreed upon decision to allow free-form text for the system property. Plus updates to test to match the expectations - Update javadoc based on Stuart's inputs - allow free-form text for java.util.Properties.storeDate system property - jcheck fix - trailing whitespace in test - Implement Roger's suggestions: - Rely on java.util.Properties.storeDate system property instead of SOURCE_DATE_EPOCH environment variable - No need for caching the parsed date - Update the javadoc to match new expectations - Update tests to match the new expectations - dummy commit to trigger GitHub actions job to try and reproduce an unexplained failure with the new tests that happened around 24 hours back, this time yesterday (rule out any time/date/timezone specific issues) - update javadoc to match latest changes - Implement Stuart's suggestion to use Collections instead of Arrays for ordering property keys - update the new tests to match the new date format expectations and also print out some log messages for better debuggability of the tests - ... and 6 more: https://git.openjdk.java.net/jdk/compare/dae096b0...6447f9bb ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5372/files - new: https://git.openjdk.java.net/jdk/pull/5372/files/c1dfb18f..6447f9bb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5372&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5372&range=10-11 Stats: 10450 lines in 483 files changed: 6216 ins; 2542 del; 1692 mod Patch: https://git.openjdk.java.net/jdk/pull/5372.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5372/head:pull/5372 PR: https://git.openjdk.java.net/jdk/pull/5372 From jai.forums2013 at gmail.com Tue Sep 14 02:28:17 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Tue, 14 Sep 2021 07:58:17 +0530 Subject: RFR: 8231640: (prop) Canonical property storage [v10] In-Reply-To: <89636de4-4c03-8a10-8097-be93b1a01c31@oracle.com> References: <89636de4-4c03-8a10-8097-be93b1a01c31@oracle.com> Message-ID: <74ddb97a-e40b-1304-e0ce-7e8925703b1c@gmail.com> Hello Roger, I've now updated the PR to implement these suggested changes. I think at this point all suggestions have been implemented and I don't think there are any open questions. If the latest PR looks fine, I think the next step will be a CSR creation. -Jaikiran On 13/09/21 7:13 pm, Roger Riggs wrote: > Hi Jaikiran, > > "Editing" the value of the comment property, to remove or ignore > blanks for other special > characters makes the code more complex and adds a bunch of conditions. > Dropping > the comment if it doesn't have the allowed format is hard to track > down, because there's > no way to report it was dropped or why. > > I would write the value of the comment property using the > writeComments method > so it is encoded the same as the other comment passed as an store > argument. > That will handle all special characters and multi-line comments. It is > simpler to specify > and has the same predictable output as other comments. > > if the property is non-empty > > > > On 9/12/21 10:29 AM, Jaikiran Pai wrote: >> ... >> >>> This was discussed elsewhere, but after writing that, I'm now >>> thinking that we **should** honor the property even if it is blank. >>> It would be useful to disable the timestamp simply by setting the >>> property to the empty string; this will simply result in an empty >>> comment line. This would simplify the code (and the spec) by >>> removing conditions related to String::isBlank. >> >> OK. I don't see any obvious issues with interpreting >> empty/whitespace-only value for the system property to translate to >> an empty comment line. To be clear, an empty comment line that gets >> written out in such cases is *always* going to be the "#" character >> followed by a line separator right? Irrespective of what or how many >> whitespace characters are present in the property value? Or do you >> want those characters to be carried over into that comment line that >> gets written out? The reason I ask this is because I think we should >> always write just the "#" followed by the line separator character in >> such cases, which effectively means we will still need the >> String::isBlank check which would then look something like: >> >> if (propVal.isBlank()) { >> ? bw.write("#"); >> ? bw.newLine(); >> } >>> Side question: do we want to do any escaping or vetting of the >>> property value? >> >> One of the reasons why we didn't want to use the date in epoch >> seconds or a formatted date string was to avoid the complexities that >> come with managing that property value. So a free-form property value >> seemed more appropriate and I think a free-form value still seems >> appropriate, but I think we should keep any vetting to minimal. More >> details below. >> >>> If for example it contains embedded newlines, this could result in a >>> malformed property file. Or, if carefully constructed, it could >>> contain additional property values. I think this is an unintended >>> consequence of changing the property value from a numeric time value >>> to a free-form string. We may want to reconsider this. >> >> The specification on the load(Reader reader) method of the >> java.util.Properties class has this to say about comment lines (and >> lines in general). >> >> (snipped relevant content): >> >> ?? There are two kinds of line, natural lines and logical >> ?? lines. >> ?? A natural line is defined as a line of characters that is terminated >> ?? either >> ?? by a set of line terminator characters ({@code \n} or {@code \r} or >> ?? {@code \r\n}) or by the end of the stream. A natural line may be >> ?? either a blank line, a comment line, or hold all or some of a >> ?? key-element pair. A logical >> ?? line holds all the data of a key-element pair, which may be spread >> ?? out across several adjacent natural lines by escaping >> ?? the line terminator sequence with a backslash character >> ?? {@code \}.? Note that a comment line cannot be extended >> ?? in this manner; every natural line that is a comment must have >> ?? its own comment indicator, as described below. >> >> >> With that knowledge about comment lines, I think what we should do is >> disallow system property values that contain any form of line >> terminator characters (\n or \r or \r\n). If the system property >> value is _not_ blank (as specified by String::isBlank) and contains >> any of these line terminator characters, we should simply ignore it >> and write out the current date as the date comment. That, IMO, should >> prevent any of these sneaky/rogue value that can end up either >> creating additional property key/values to be written out or causing >> any malformed properties file. Plus, that would help us keep the >> vetting to minimal without involving too much complexity. >> >>> src/java.base/share/classes/java/util/Properties.java line 855: >>> >>>> 853:????? * the value of this system property represents a formatted >>>> 854:????? * date time value that can be parsed back into a {@link >>>> Date} using an appropriate >>>> 855:????? * {@link DateTimeFormatter} >>> With the property behavior added to normative text above, I don't >>> think we need this note anymore. We might want to leave something >>> here about the convention of putting a timestamp here, and an >>> implicit(?) requirement that it be formatted properly. >> >> The newly updated PR has updated this @implNote to remove some of the >> previous text and yet retain some hints on what would be an "ideal" >> value for the system property value. But I think we should perhaps >> just get rid of this @implNote since we are now proposing to allow >> empty comment lines and free form text and this no longer is a "let's >> use this system property to allow users to specify a fixed date" >> enhancement. > good >> >> -Jaikiran >> > From jpai at openjdk.java.net Tue Sep 14 02:30:01 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 14 Sep 2021 02:30:01 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v13] In-Reply-To: References: Message-ID: > The commit in this PR implements the proposal for enhancement that was discussed in the core-libs-dev mailing list recently[1], for https://bugs.openjdk.java.net/browse/JDK-8231640 > > At a high level - the `store()` APIs in `Properties` have been modified to now look for the `SOURCE_DATE_EPOCH` environment variable[2]. If that env variable is set, then instead of writing out the current date time as a date comment, the `store()` APIs instead will use the value set for this env variable to parse it to a `Date` and write out the string form of such a date. The implementation here uses the `d MMM yyyy HH:mm:ss 'GMT'` date format and `Locale.ROOT` to format and write out such a date. This should provide reproducibility whenever the `SOURCE_DATE_EPOCH` is set. Furthermore, intentionally, no changes in the date format of the "current date" have been done. > > These modified `store()` APIs work in the presence of the `SecurityManager` too. The caller is expected to have a read permission on the `SOURCE_DATE_EPOCH` environment variable. If the caller doesn't have that permission, then the implementation of these `store()` APIs will write out the "current date" and will ignore any value that has been set for the `SOURCE_DATE_EPOCH` env variable. This should allow for backward compatibility of existing applications, where, when they run under a `SecurityManager` and perhaps with an existing restrictive policy file, the presence of `SOURCE_DATE_EPOCH` shouldn't impact their calls to the `store()` APIs. > > The modified `store()` APIs will also ignore any value for `SOURCE_DATE_EPOCH` that cannot be parsed to an `long` value. In such cases, the `store()` APIs will write out the "current date" and ignore the value set for this environment variable. No exceptions will be thrown for such invalid values. This is an additional backward compatibility precaution to prevent any rogue value for `SOURCE_DATE_EPOCH` from breaking applications. > > An additional change in the implementation of these `store()` APIs and unrelated to the date comment, is that these APIs will now write out the property keys in a deterministic order. The keys will be written out in the natural ordering as specified by `java.lang.String#compareTo()` API. > > The combination of the ordering of the property keys when written out and the usage of `SOURCE_DATE_EPOCH` environment value to determine the date comment should together allow for reproducibility of the output generated by these `store()` APIs. > > New jtreg test classes have been introduced to verify these changes. The primary focus of `PropertiesStoreTest` is the ordering aspects of the property keys that are written out. On the other hand `StoreReproducibilityTest` focuses on the reproducibility of the output generated by these APIs. The `StoreReproducibilityTest` runs these tests both in the presence and absence of `SecurityManager`. Plus, in the presence of SecurityManager, it tests both the scenarios where the caller is granted the requisite permission and in other case not granted that permission. > > These new tests and existing tests under `test/jdk/java/util/Properties/` pass with these changes. > > [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-August/080758.html > [2] https://reproducible-builds.org/specs/source-date-epoch/ Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: unused imports ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5372/files - new: https://git.openjdk.java.net/jdk/pull/5372/files/6447f9bb..92374664 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5372&range=12 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5372&range=11-12 Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5372.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5372/head:pull/5372 PR: https://git.openjdk.java.net/jdk/pull/5372 From github.com+741251+turbanoff at openjdk.java.net Tue Sep 14 08:38:45 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Tue, 14 Sep 2021 08:38:45 GMT Subject: RFR: 8273711: Remove redundant stream() call before forEach in jdk.jlink Message-ID: <3ABdvBiCu8znAgbmq2XW3wsWVEPqwIGbPJnmEdW-1jc=.2148d9d8-f14f-49ad-a58f-6f843bba27d3@github.com> 8273711: Remove redundant stream() call before forEach in jdk.jlink ------------- Commit messages: - [PATCH] Remove redundant stream() call before forEach in jdk.jlink Changes: https://git.openjdk.java.net/jdk/pull/5500/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5500&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273711 Stats: 17 lines in 9 files changed: 0 ins; 0 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/5500.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5500/head:pull/5500 PR: https://git.openjdk.java.net/jdk/pull/5500 From github.com+741251+turbanoff at openjdk.java.net Tue Sep 14 08:39:53 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Tue, 14 Sep 2021 08:39:53 GMT Subject: RFR: 8273710: Remove redundant stream() call before forEach in jdk.jdeps Message-ID: 8273710: Remove redundant stream() call before forEach in jdk.jdeps ------------- Commit messages: - [PATCH] Remove redundant stream() call before forEach in jdk.jdeps Changes: https://git.openjdk.java.net/jdk/pull/5498/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5498&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273710 Stats: 30 lines in 10 files changed: 0 ins; 5 del; 25 mod Patch: https://git.openjdk.java.net/jdk/pull/5498.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5498/head:pull/5498 PR: https://git.openjdk.java.net/jdk/pull/5498 From alanb at openjdk.java.net Tue Sep 14 09:26:18 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 14 Sep 2021 09:26:18 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) In-Reply-To: References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> <75Nj_vbtmqUEj1XoUw9i3kTL140mcy6mZEmHyLyHa0U=.4eadfe72-2e17-4fa2-8f00-ba36f2c46305@github.com> <8zsz0oqYToH6u-FsIvYMrKxdJYG4AgftI9Fn5hC7v8E=.cf5db5a8-b69d-4e58-8ffd-ac86d6bd198f@github.com> <-exCZ7NcHfpt_xWuhuEsNxondubbjJQVaFmqn6jk79I=.0dae33f1-dbfd-4c07-a4ad-039070fdb62a@github.com> Message-ID: On Thu, 13 May 2021 11:31:49 GMT, iaroslavski wrote: >> Perhaps we can resolve this issue in private - my email address is on my profile (or in the commits in `radix-sort-benchmark`)? > > @richardstartin And one more addon: my first version of Radix sort, see my github https://github.com/iaroslavski/sorting/tree/master/radixsort uses another name, like skipBytes, then renamed to passLevel. > So, the common part is "skip". And this method has different number of parameters. I don't see any collision with your code. > Hi @iaroslavski I'm unconvinced that this work was from 14/06/2020 - I believe this work derives from an unsigned radix sort I implemented on 10/04/2021 [richardstartin/radix-sort-benchmark at ab4da23#diff-6c13d3fb74f38906677dbfa1a70a123c8e5baf4a39219c81ef121e078d0013bcR226](https://github.com/richardstartin/radix-sort-benchmark/commit/ab4da230e1d0ac68e5ee2cee38d71c7e7d50f49b#diff-6c13d3fb74f38906677dbfa1a70a123c8e5baf4a39219c81ef121e078d0013bcR226) which has numerous structural similarities to this work: > Moreover, @bourgesl forked my repository on 11/04/2021 and communicated with me about doing so. On 25/04/2021 there was a new implementation of `DualPivotQuicksort` with a signed radix sort but the same structural similarities, and with the same method and variable names in places [bourgesl/radix-sort-benchmark at 90ff7e4#diff-397ce8fd791e2ce508cf9127201bc9ab46264cd2a79fd0487a63569f2e4b59b2R607-R609](https://github.com/bourgesl/radix-sort-benchmark/commit/90ff7e427da0fa49f374bff0241fb2487bd87bde#diff-397ce8fd791e2ce508cf9127201bc9ab46264cd2a79fd0487a63569f2e4b59b2R607-R609) @iaroslavski The attribution is not clear here. Can you provide a summary as to who is contributing to this patch? I can't tell if all involved have signed the OCA or not. I'm sure there will be questions about space/time trade-offs with radix sort but I think it's important to first establish the origins of this patch first. ------------- PR: https://git.openjdk.java.net/jdk/pull/3938 From alanb at openjdk.java.net Tue Sep 14 09:29:06 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 14 Sep 2021 09:29:06 GMT Subject: RFR: 8273711: Remove redundant stream() call before forEach in jdk.jlink In-Reply-To: <3ABdvBiCu8znAgbmq2XW3wsWVEPqwIGbPJnmEdW-1jc=.2148d9d8-f14f-49ad-a58f-6f843bba27d3@github.com> References: <3ABdvBiCu8znAgbmq2XW3wsWVEPqwIGbPJnmEdW-1jc=.2148d9d8-f14f-49ad-a58f-6f843bba27d3@github.com> Message-ID: <3OAjACtUqY_BzF4UK_Ef0-TK-oRusKtY1r4ZJyVRwvs=.cfcfb102-f484-499d-99ff-c981bcd91374@github.com> On Mon, 13 Sep 2021 20:06:08 GMT, Andrey Turbanov wrote: > 8273711: Remove redundant stream() call before forEach in jdk.jlink Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5500 From jboes at openjdk.java.net Tue Sep 14 10:02:46 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Tue, 14 Sep 2021 10:02:46 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server Message-ID: This change implements a simple web server that can be run on the command-line with `java -m jdk.httpserver`. This is facilitated by adding an entry point for the `jdk.httpserver` module, an implementation class whose main method is run when the above command is executed. This is the first such module entry point in the JDK. The server is a minimal HTTP server that serves the static files of a given directory, similar to existing alternatives on other platforms and convenient for testing, development, and debugging. Additionally, a small API is introduced for programmatic creation and customization. Testing: tier1-3. ------------- Commit messages: - fix whitespace - Move changes from sandbox to mainline Changes: https://git.openjdk.java.net/jdk/pull/5505/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5505&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8245095 Stats: 6891 lines in 42 files changed: 6856 ins; 15 del; 20 mod Patch: https://git.openjdk.java.net/jdk/pull/5505.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5505/head:pull/5505 PR: https://git.openjdk.java.net/jdk/pull/5505 From github.com+43264149+iaroslavski at openjdk.java.net Tue Sep 14 10:08:14 2021 From: github.com+43264149+iaroslavski at openjdk.java.net (iaroslavski) Date: Tue, 14 Sep 2021 10:08:14 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) In-Reply-To: References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> <75Nj_vbtmqUEj1XoUw9i3kTL140mcy6mZEmHyLyHa0U=.4eadfe72-2e17-4fa2-8f00-ba36f2c46305@github.com> <8zsz0oqYToH6u-FsIvYMrKxdJYG4AgftI9Fn5hC7v8E=.cf5db5a8-b69d-4e58-8ffd-ac86d6bd198f@github.com> <-exCZ7NcHfpt_xWuhuEsNxondubbjJQVaFmqn6jk79I=.0dae33f1-dbfd-4c07-a4ad-039070fdb62a@github.com> Message-ID: <2k3IaQ8usbpOG-LfRozJ5EvwLzvRboFAMW4lEN2ctNY=.09f681a7-5f82-488a-930b-aa0d4602abd5@github.com> On Tue, 14 Sep 2021 09:23:23 GMT, Alan Bateman wrote: >> @richardstartin And one more addon: my first version of Radix sort, see my github https://github.com/iaroslavski/sorting/tree/master/radixsort uses another name, like skipBytes, then renamed to passLevel. >> So, the common part is "skip". And this method has different number of parameters. I don't see any collision with your code. > >> Hi @iaroslavski I'm unconvinced that this work was from 14/06/2020 - I believe this work derives from an unsigned radix sort I implemented on 10/04/2021 [richardstartin/radix-sort-benchmark at ab4da23#diff-6c13d3fb74f38906677dbfa1a70a123c8e5baf4a39219c81ef121e078d0013bcR226](https://github.com/richardstartin/radix-sort-benchmark/commit/ab4da230e1d0ac68e5ee2cee38d71c7e7d50f49b#diff-6c13d3fb74f38906677dbfa1a70a123c8e5baf4a39219c81ef121e078d0013bcR226) which has numerous structural similarities to this work: >> Moreover, @bourgesl forked my repository on 11/04/2021 and communicated with me about doing so. On 25/04/2021 there was a new implementation of `DualPivotQuicksort` with a signed radix sort but the same structural similarities, and with the same method and variable names in places [bourgesl/radix-sort-benchmark at 90ff7e4#diff-397ce8fd791e2ce508cf9127201bc9ab46264cd2a79fd0487a63569f2e4b59b2R607-R609](https://github.com/bourgesl/radix-sort-benchmark/commit/90ff7e427da0fa49f374bff0241fb2487bd87bde#diff-397ce8fd791e2ce508cf9127201bc9ab46264cd2a79fd0487a63569f2e4b59b2R607-R609) > > @iaroslavski The attribution is not clear here. Can you provide a summary as to who is contributing to this patch? I can't tell if all involved have signed the OCA or not. I'm sure there will be questions about space/time trade-offs with radix sort but I think it's important to first establish the origins of this patch first. @AlanBateman There was discussion with Richard Startin, where Laurent and I explained the origin of my patch. There was misunderstanding based on git changes only. Finally Richard wrote comment in PR on May 13, 2021, I duplicate it here: "In private correspondence with Vladimir, it was explained that where Vladimir's code and Laurent's code are identical, including typos (Vladimir's code, Laurent's code) it is because Vladimir sent the code to Laurent, not the other way around, therefore Vladimir's code does not derive from Laurent's, and it does not derive from mine. I can only trust that this is the case, so please disregard my claim that this is derivative work when reviewing this PR." @AlanBateman Vertical pipeline of PR hides comments in the middle and you have to click on "Show more..." to see all comments. There are no claims related to the origin of my patch, it doesn't violate any rights. ------------- PR: https://git.openjdk.java.net/jdk/pull/3938 From Alan.Bateman at oracle.com Tue Sep 14 10:33:42 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 14 Sep 2021 11:33:42 +0100 Subject: RFR: 8231640: (prop) Canonical property storage [v10] In-Reply-To: <74ddb97a-e40b-1304-e0ce-7e8925703b1c@gmail.com> References: <89636de4-4c03-8a10-8097-be93b1a01c31@oracle.com> <74ddb97a-e40b-1304-e0ce-7e8925703b1c@gmail.com> Message-ID: <2e9e29d8-4d2c-ea00-adeb-523619daac6a@oracle.com> On 14/09/2021 03:28, Jaikiran Pai wrote: > Hello Roger, > > I've now updated the PR to implement these suggested changes. I think > at this point all suggestions have been implemented and I don't think > there are any open questions. > > If the latest PR looks fine, I think the next step will be a CSR > creation. Thanks for hanging in there, I think you've got this to a good place. The system property and resulting behavior look good so you should be able to create the CSR. -Alan From dfuchs at openjdk.java.net Tue Sep 14 10:52:11 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 14 Sep 2021 10:52:11 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v13] In-Reply-To: References: Message-ID: On Tue, 14 Sep 2021 02:30:01 GMT, Jaikiran Pai wrote: >> The commit in this PR implements the proposal for enhancement that was discussed in the core-libs-dev mailing list recently[1], for https://bugs.openjdk.java.net/browse/JDK-8231640 >> >> At a high level - the `store()` APIs in `Properties` have been modified to now look for the `SOURCE_DATE_EPOCH` environment variable[2]. If that env variable is set, then instead of writing out the current date time as a date comment, the `store()` APIs instead will use the value set for this env variable to parse it to a `Date` and write out the string form of such a date. The implementation here uses the `d MMM yyyy HH:mm:ss 'GMT'` date format and `Locale.ROOT` to format and write out such a date. This should provide reproducibility whenever the `SOURCE_DATE_EPOCH` is set. Furthermore, intentionally, no changes in the date format of the "current date" have been done. >> >> These modified `store()` APIs work in the presence of the `SecurityManager` too. The caller is expected to have a read permission on the `SOURCE_DATE_EPOCH` environment variable. If the caller doesn't have that permission, then the implementation of these `store()` APIs will write out the "current date" and will ignore any value that has been set for the `SOURCE_DATE_EPOCH` env variable. This should allow for backward compatibility of existing applications, where, when they run under a `SecurityManager` and perhaps with an existing restrictive policy file, the presence of `SOURCE_DATE_EPOCH` shouldn't impact their calls to the `store()` APIs. >> >> The modified `store()` APIs will also ignore any value for `SOURCE_DATE_EPOCH` that cannot be parsed to an `long` value. In such cases, the `store()` APIs will write out the "current date" and ignore the value set for this environment variable. No exceptions will be thrown for such invalid values. This is an additional backward compatibility precaution to prevent any rogue value for `SOURCE_DATE_EPOCH` from breaking applications. >> >> An additional change in the implementation of these `store()` APIs and unrelated to the date comment, is that these APIs will now write out the property keys in a deterministic order. The keys will be written out in the natural ordering as specified by `java.lang.String#compareTo()` API. >> >> The combination of the ordering of the property keys when written out and the usage of `SOURCE_DATE_EPOCH` environment value to determine the date comment should together allow for reproducibility of the output generated by these `store()` APIs. >> >> New jtreg test classes have been introduced to verify these changes. The primary focus of `PropertiesStoreTest` is the ordering aspects of the property keys that are written out. On the other hand `StoreReproducibilityTest` focuses on the reproducibility of the output generated by these APIs. The `StoreReproducibilityTest` runs these tests both in the presence and absence of `SecurityManager`. Plus, in the presence of SecurityManager, it tests both the scenarios where the caller is granted the requisite permission and in other case not granted that permission. >> >> These new tests and existing tests under `test/jdk/java/util/Properties/` pass with these changes. >> >> [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-August/080758.html >> [2] https://reproducible-builds.org/specs/source-date-epoch/ > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > unused imports src/java.base/share/classes/java/util/Properties.java line 836: > 834: *

> 835: * Then every entry in this {@code Properties} table is > 836: * written out, one per line. For each entry the key string is Sorry for coming late to the party: I don't remember if this was already asked for and rejected - but shouldn't there be a non-normative `@implNote` here to state that the default implementation of this method will write the properties sorted by their keys in alphanumeric ordering? Otherwise this looks very good! ------------- PR: https://git.openjdk.java.net/jdk/pull/5372 From dfuchs at openjdk.java.net Tue Sep 14 10:52:12 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 14 Sep 2021 10:52:12 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v3] In-Reply-To: <6LwZddwwZyA8VbW2qh932vbw9vdqjtf0auS3JFWF7hA=.01ba8840-07b6-40d9-9a2d-c29f595d8797@github.com> References: <6LwZddwwZyA8VbW2qh932vbw9vdqjtf0auS3JFWF7hA=.01ba8840-07b6-40d9-9a2d-c29f595d8797@github.com> Message-ID: On Wed, 8 Sep 2021 09:26:33 GMT, Jaikiran Pai wrote: >> The commit in this PR implements the proposal for enhancement that was discussed in the core-libs-dev mailing list recently[1], for https://bugs.openjdk.java.net/browse/JDK-8231640 >> >> At a high level - the `store()` APIs in `Properties` have been modified to now look for the `SOURCE_DATE_EPOCH` environment variable[2]. If that env variable is set, then instead of writing out the current date time as a date comment, the `store()` APIs instead will use the value set for this env variable to parse it to a `Date` and write out the string form of such a date. The implementation here uses the `d MMM yyyy HH:mm:ss 'GMT'` date format and `Locale.ROOT` to format and write out such a date. This should provide reproducibility whenever the `SOURCE_DATE_EPOCH` is set. Furthermore, intentionally, no changes in the date format of the "current date" have been done. >> >> These modified `store()` APIs work in the presence of the `SecurityManager` too. The caller is expected to have a read permission on the `SOURCE_DATE_EPOCH` environment variable. If the caller doesn't have that permission, then the implementation of these `store()` APIs will write out the "current date" and will ignore any value that has been set for the `SOURCE_DATE_EPOCH` env variable. This should allow for backward compatibility of existing applications, where, when they run under a `SecurityManager` and perhaps with an existing restrictive policy file, the presence of `SOURCE_DATE_EPOCH` shouldn't impact their calls to the `store()` APIs. >> >> The modified `store()` APIs will also ignore any value for `SOURCE_DATE_EPOCH` that cannot be parsed to an `long` value. In such cases, the `store()` APIs will write out the "current date" and ignore the value set for this environment variable. No exceptions will be thrown for such invalid values. This is an additional backward compatibility precaution to prevent any rogue value for `SOURCE_DATE_EPOCH` from breaking applications. >> >> An additional change in the implementation of these `store()` APIs and unrelated to the date comment, is that these APIs will now write out the property keys in a deterministic order. The keys will be written out in the natural ordering as specified by `java.lang.String#compareTo()` API. >> >> The combination of the ordering of the property keys when written out and the usage of `SOURCE_DATE_EPOCH` environment value to determine the date comment should together allow for reproducibility of the output generated by these `store()` APIs. >> >> New jtreg test classes have been introduced to verify these changes. The primary focus of `PropertiesStoreTest` is the ordering aspects of the property keys that are written out. On the other hand `StoreReproducibilityTest` focuses on the reproducibility of the output generated by these APIs. The `StoreReproducibilityTest` runs these tests both in the presence and absence of `SecurityManager`. Plus, in the presence of SecurityManager, it tests both the scenarios where the caller is granted the requisite permission and in other case not granted that permission. >> >> These new tests and existing tests under `test/jdk/java/util/Properties/` pass with these changes. >> >> [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-August/080758.html >> [2] https://reproducible-builds.org/specs/source-date-epoch/ > > Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision: > > - adjust testcases to verify the new semantics > - implement review suggestions: > - Use doPriveleged instead of explicit permission checks, to reduce complexity > - Use DateTimeFormatter and ZonedDateTime instead of Date.toString() > - Use DateTimeFormatter.RFC_1123_DATE_TIME for formatting SOURCE_DATE_EPOCH dates > - Use Arrays.sort instead of a TreeMap for ordering property keys src/java.base/share/classes/java/util/Properties.java line 886: > 884: * In the presence of a SecurityManager, if the caller doesn't have permission > 885: * to read the {@code SOURCE_DATE_EPOCH} environment variable, then the current date > 886: * and time will be written. Similarly, if the value set for {@code SOURCE_DATE_EPOCH} This is no longer true - is it? It seems you changed the code but not the spec :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/5372 From alanb at openjdk.java.net Tue Sep 14 11:00:16 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 14 Sep 2021 11:00:16 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) In-Reply-To: References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> <75Nj_vbtmqUEj1XoUw9i3kTL140mcy6mZEmHyLyHa0U=.4eadfe72-2e17-4fa2-8f00-ba36f2c46305@github.com> <8zsz0oqYToH6u-FsIvYMrKxdJYG4AgftI9Fn5hC7v8E=.cf5db5a8-b69d-4e58-8ffd-ac86d6bd198f@github.com> <-exCZ7NcHfpt_xWuhuEsNxondubbjJQVaFmqn6jk79I=.0dae33f1-dbfd-4c07-a4ad-039070fdb62a@github.com> Message-ID: On Tue, 14 Sep 2021 09:23:23 GMT, Alan Bateman wrote: >> @richardstartin And one more addon: my first version of Radix sort, see my github https://github.com/iaroslavski/sorting/tree/master/radixsort uses another name, like skipBytes, then renamed to passLevel. >> So, the common part is "skip". And this method has different number of parameters. I don't see any collision with your code. > >> Hi @iaroslavski I'm unconvinced that this work was from 14/06/2020 - I believe this work derives from an unsigned radix sort I implemented on 10/04/2021 [richardstartin/radix-sort-benchmark at ab4da23#diff-6c13d3fb74f38906677dbfa1a70a123c8e5baf4a39219c81ef121e078d0013bcR226](https://github.com/richardstartin/radix-sort-benchmark/commit/ab4da230e1d0ac68e5ee2cee38d71c7e7d50f49b#diff-6c13d3fb74f38906677dbfa1a70a123c8e5baf4a39219c81ef121e078d0013bcR226) which has numerous structural similarities to this work: >> Moreover, @bourgesl forked my repository on 11/04/2021 and communicated with me about doing so. On 25/04/2021 there was a new implementation of `DualPivotQuicksort` with a signed radix sort but the same structural similarities, and with the same method and variable names in places [bourgesl/radix-sort-benchmark at 90ff7e4#diff-397ce8fd791e2ce508cf9127201bc9ab46264cd2a79fd0487a63569f2e4b59b2R607-R609](https://github.com/bourgesl/radix-sort-benchmark/commit/90ff7e427da0fa49f374bff0241fb2487bd87bde#diff-397ce8fd791e2ce508cf9127201bc9ab46264cd2a79fd0487a63569f2e4b59b2R607-R609) > > @iaroslavski The attribution is not clear here. Can you provide a summary as to who is contributing to this patch? I can't tell if all involved have signed the OCA or not. I'm sure there will be questions about space/time trade-offs with radix sort but I think it's important to first establish the origins of this patch first. > @AlanBateman Vertical pipeline of PR hides comments in the middle and you have to click on "Show more..." to see all comments. There are no claims related to the origin of my patch, it doesn't violate any rights. There is a comment from richardstartin suggesting that something was derived from code in his repo. Is this a benchmark that is not part of this PR? Only asking because I can't find him on OCA signatories. You can use the Skara /contributor command to list the contributors. ------------- PR: https://git.openjdk.java.net/jdk/pull/3938 From github.com+43264149+iaroslavski at openjdk.java.net Tue Sep 14 11:30:13 2021 From: github.com+43264149+iaroslavski at openjdk.java.net (iaroslavski) Date: Tue, 14 Sep 2021 11:30:13 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) In-Reply-To: References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> <75Nj_vbtmqUEj1XoUw9i3kTL140mcy6mZEmHyLyHa0U=.4eadfe72-2e17-4fa2-8f00-ba36f2c46305@github.com> <8zsz0oqYToH6u-FsIvYMrKxdJYG4AgftI9Fn5hC7v8E=.cf5db5a8-b69d-4e58-8ffd-ac86d6bd198f@github.com> <-exCZ7NcHfpt_xWuhuEsNxondubbjJQVaFmqn6jk79I=.0dae33f1-dbfd-4c07-a4ad-039070fdb62a@github.com> Message-ID: <__QdHuLZ-btQIUZi0BZdQp05Eo4CkoIgg-LwVUMm9F8=.c886e182-994c-48ff-a656-cadf1d7824d9@github.com> On Tue, 14 Sep 2021 10:57:17 GMT, Alan Bateman wrote: >>> Hi @iaroslavski I'm unconvinced that this work was from 14/06/2020 - I believe this work derives from an unsigned radix sort I implemented on 10/04/2021 [richardstartin/radix-sort-benchmark at ab4da23#diff-6c13d3fb74f38906677dbfa1a70a123c8e5baf4a39219c81ef121e078d0013bcR226](https://github.com/richardstartin/radix-sort-benchmark/commit/ab4da230e1d0ac68e5ee2cee38d71c7e7d50f49b#diff-6c13d3fb74f38906677dbfa1a70a123c8e5baf4a39219c81ef121e078d0013bcR226) which has numerous structural similarities to this work: >>> Moreover, @bourgesl forked my repository on 11/04/2021 and communicated with me about doing so. On 25/04/2021 there was a new implementation of `DualPivotQuicksort` with a signed radix sort but the same structural similarities, and with the same method and variable names in places [bourgesl/radix-sort-benchmark at 90ff7e4#diff-397ce8fd791e2ce508cf9127201bc9ab46264cd2a79fd0487a63569f2e4b59b2R607-R609](https://github.com/bourgesl/radix-sort-benchmark/commit/90ff7e427da0fa49f374bff0241fb2487bd87bde#diff-397ce8fd791e2ce508cf9127201bc9ab46264cd2a79fd0487a63569f2e4b59b2R607-R609) >> >> @iaroslavski The attribution is not clear here. Can you provide a summary as to who is contributing to this patch? I can't tell if all involved have signed the OCA or not. I'm sure there will be questions about space/time trade-offs with radix sort but I think it's important to first establish the origins of this patch first. > >> @AlanBateman Vertical pipeline of PR hides comments in the middle and you have to click on "Show more..." to see all comments. There are no claims related to the origin of my patch, it doesn't violate any rights. > > There is a comment from richardstartin suggesting that something was derived from code in his repo. Is this a benchmark that is not part of this PR? Only asking because I can't find him on OCA signatories. You can use the Skara /contributor command to list the contributors. Mentioned benchmarking is not a part of this PR. Our benchmarking was done by Laurent. ------------- PR: https://git.openjdk.java.net/jdk/pull/3938 From dfuchs at openjdk.java.net Tue Sep 14 11:34:18 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 14 Sep 2021 11:34:18 GMT Subject: RFR: 8273710: Remove redundant stream() call before forEach in jdk.jdeps In-Reply-To: References: Message-ID: On Mon, 13 Sep 2021 19:57:14 GMT, Andrey Turbanov wrote: > 8273710: Remove redundant stream() call before forEach in jdk.jdeps LGTM ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5498 From ihse at openjdk.java.net Tue Sep 14 11:36:09 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 14 Sep 2021 11:36:09 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server In-Reply-To: References: Message-ID: <3_Uc2ddU6Ixh4R05LHfTkphvui1z1xEUakIEKRxvAmw=.67feb225-399d-41df-af1f-405d5764f882@github.com> On Tue, 14 Sep 2021 08:52:37 GMT, Julia Boes wrote: > This change implements a simple web server that can be run on the command-line with `java -m jdk.httpserver`. > > This is facilitated by adding an entry point for the `jdk.httpserver` module, an implementation class whose main method is run when the above command is executed. This is the first such module entry point in the JDK. > > The server is a minimal HTTP server that serves the static files of a given directory, similar to existing alternatives on other platforms and convenient for testing, development, and debugging. > > Additionally, a small API is introduced for programmatic creation and customization. > > Testing: tier1-3. Build changes look good. ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5505 From ihse at openjdk.java.net Tue Sep 14 11:37:58 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 14 Sep 2021 11:37:58 GMT Subject: RFR: 8273494: Zero: Put libjvm.so into "zero" folder, not "server" In-Reply-To: References: Message-ID: <_RzxWBDAsjsGgktVG8WL_0Xhgl894b6LXeb33cQGowM=.37460cd8-7b3c-4f44-b677-fc05a641be96@github.com> On Thu, 9 Sep 2021 10:17:02 GMT, Aleksey Shipilev wrote: > Currently, the build system defaults the libjvm.so location to "server". This makes looking for `libjvm.so` awkward, see JDK-8273487 for example. We need to see if moving the libjvm.so to a proper location breaks anything. > > Additional testing: > - [x] Linux x86_64 Zero build > - [x] Linux x86_64 Zero bootcycle-images > - [ ] Linux x86_64 Zero `tier1` I'm changing my response to "approve". I agree that we can change zero only in this patch to facilitate backporting, and fix the remaining odds and ends in a separate PR. And also let me be clear that I see no reason to delay pushing this any further. Everyone who has any vested interest in zero has had ample chance to comment on the PR. ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5440 From ihse at openjdk.java.net Tue Sep 14 11:46:07 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 14 Sep 2021 11:46:07 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v13] In-Reply-To: References: Message-ID: On Tue, 14 Sep 2021 02:30:01 GMT, Jaikiran Pai wrote: >> The commit in this PR implements the proposal for enhancement that was discussed in the core-libs-dev mailing list recently[1], for https://bugs.openjdk.java.net/browse/JDK-8231640 >> >> At a high level - the `store()` APIs in `Properties` have been modified to now look for the `SOURCE_DATE_EPOCH` environment variable[2]. If that env variable is set, then instead of writing out the current date time as a date comment, the `store()` APIs instead will use the value set for this env variable to parse it to a `Date` and write out the string form of such a date. The implementation here uses the `d MMM yyyy HH:mm:ss 'GMT'` date format and `Locale.ROOT` to format and write out such a date. This should provide reproducibility whenever the `SOURCE_DATE_EPOCH` is set. Furthermore, intentionally, no changes in the date format of the "current date" have been done. >> >> These modified `store()` APIs work in the presence of the `SecurityManager` too. The caller is expected to have a read permission on the `SOURCE_DATE_EPOCH` environment variable. If the caller doesn't have that permission, then the implementation of these `store()` APIs will write out the "current date" and will ignore any value that has been set for the `SOURCE_DATE_EPOCH` env variable. This should allow for backward compatibility of existing applications, where, when they run under a `SecurityManager` and perhaps with an existing restrictive policy file, the presence of `SOURCE_DATE_EPOCH` shouldn't impact their calls to the `store()` APIs. >> >> The modified `store()` APIs will also ignore any value for `SOURCE_DATE_EPOCH` that cannot be parsed to an `long` value. In such cases, the `store()` APIs will write out the "current date" and ignore the value set for this environment variable. No exceptions will be thrown for such invalid values. This is an additional backward compatibility precaution to prevent any rogue value for `SOURCE_DATE_EPOCH` from breaking applications. >> >> An additional change in the implementation of these `store()` APIs and unrelated to the date comment, is that these APIs will now write out the property keys in a deterministic order. The keys will be written out in the natural ordering as specified by `java.lang.String#compareTo()` API. >> >> The combination of the ordering of the property keys when written out and the usage of `SOURCE_DATE_EPOCH` environment value to determine the date comment should together allow for reproducibility of the output generated by these `store()` APIs. >> >> New jtreg test classes have been introduced to verify these changes. The primary focus of `PropertiesStoreTest` is the ordering aspects of the property keys that are written out. On the other hand `StoreReproducibilityTest` focuses on the reproducibility of the output generated by these APIs. The `StoreReproducibilityTest` runs these tests both in the presence and absence of `SecurityManager`. Plus, in the presence of SecurityManager, it tests both the scenarios where the caller is granted the requisite permission and in other case not granted that permission. >> >> These new tests and existing tests under `test/jdk/java/util/Properties/` pass with these changes. >> >> [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-August/080758.html >> [2] https://reproducible-builds.org/specs/source-date-epoch/ > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > unused imports src/java.base/share/classes/java/util/Properties.java line 828: > 826: * a comment line is written as follows. > 827: * First, a {@code #} character is written, followed by the contents > 828: * of the property, followed by a line separator. Maybe you should refer to how the comment is written out above, since you use the same method. The spec changes as written above does not specify how newlines in the property would be handled (which is possible to get, I believe, even if it means an intricate command line escape dance) ------------- PR: https://git.openjdk.java.net/jdk/pull/5372 From github.com+16439049+richardstartin at openjdk.java.net Tue Sep 14 11:58:07 2021 From: github.com+16439049+richardstartin at openjdk.java.net (Richard Startin) Date: Tue, 14 Sep 2021 11:58:07 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) In-Reply-To: References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> <75Nj_vbtmqUEj1XoUw9i3kTL140mcy6mZEmHyLyHa0U=.4eadfe72-2e17-4fa2-8f00-ba36f2c46305@github.com> <8zsz0oqYToH6u-FsIvYMrKxdJYG4AgftI9Fn5hC7v8E=.cf5db5a8-b69d-4e58-8ffd-ac86d6bd198f@github.com> <-exCZ7NcHfpt_xWuhuEsNxondubbjJQVaFmqn6jk79I=.0dae33f1-dbfd-4c07-a4ad-039070fdb62a@github.com> Message-ID: <7Lb8Gi46IPSR1PEGcSp5-HdrPb8z5NQR-qaf4-Qamao=.6fceb547-411e-4135-9b1e-fd0b338fd17a@github.com> On Tue, 14 Sep 2021 10:57:17 GMT, Alan Bateman wrote: >>> Hi @iaroslavski I'm unconvinced that this work was from 14/06/2020 - I believe this work derives from an unsigned radix sort I implemented on 10/04/2021 [richardstartin/radix-sort-benchmark at ab4da23#diff-6c13d3fb74f38906677dbfa1a70a123c8e5baf4a39219c81ef121e078d0013bcR226](https://github.com/richardstartin/radix-sort-benchmark/commit/ab4da230e1d0ac68e5ee2cee38d71c7e7d50f49b#diff-6c13d3fb74f38906677dbfa1a70a123c8e5baf4a39219c81ef121e078d0013bcR226) which has numerous structural similarities to this work: >>> Moreover, @bourgesl forked my repository on 11/04/2021 and communicated with me about doing so. On 25/04/2021 there was a new implementation of `DualPivotQuicksort` with a signed radix sort but the same structural similarities, and with the same method and variable names in places [bourgesl/radix-sort-benchmark at 90ff7e4#diff-397ce8fd791e2ce508cf9127201bc9ab46264cd2a79fd0487a63569f2e4b59b2R607-R609](https://github.com/bourgesl/radix-sort-benchmark/commit/90ff7e427da0fa49f374bff0241fb2487bd87bde#diff-397ce8fd791e2ce508cf9127201bc9ab46264cd2a79fd0487a63569f2e4b59b2R607-R609) >> >> @iaroslavski The attribution is not clear here. Can you provide a summary as to who is contributing to this patch? I can't tell if all involved have signed the OCA or not. I'm sure there will be questions about space/time trade-offs with radix sort but I think it's important to first establish the origins of this patch first. > >> @AlanBateman Vertical pipeline of PR hides comments in the middle and you have to click on "Show more..." to see all comments. There are no claims related to the origin of my patch, it doesn't violate any rights. > > There is a comment from richardstartin suggesting that something was derived from code in his repo. Is this a benchmark that is not part of this PR? Only asking because I can't find him on OCA signatories. You can use the Skara /contributor command to list the contributors. @AlanBateman my claim was that the implementation was derived from my implementation, and demonstrated a sequence of name changes after @bourgesl forked my repository containing a structurally similar radix sort implementation and benchmarks, in order to provide circumstantial evidence for my claim. Via email @iaroslavski told me that this was not the case, which I decided to accept at face value. So please judge this PR on its merits, and disregard the claims made in these comments. I have not signed an OCA but do not want to block this PR if the space time tradeoff is deemed acceptable. ------------- PR: https://git.openjdk.java.net/jdk/pull/3938 From jpai at openjdk.java.net Tue Sep 14 12:03:16 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 14 Sep 2021 12:03:16 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v13] In-Reply-To: References: Message-ID: On Tue, 14 Sep 2021 10:47:34 GMT, Daniel Fuchs wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> unused imports > > src/java.base/share/classes/java/util/Properties.java line 836: > >> 834: *

>> 835: * Then every entry in this {@code Properties} table is >> 836: * written out, one per line. For each entry the key string is > > Sorry for coming late to the party: I don't remember if this was already asked for and rejected - but shouldn't there be a non-normative `@implNote` here to state that the default implementation of this method will write the properties sorted by their keys in alphanumeric ordering? > Otherwise this looks very good! Hello Daniel, you are right - I missed discussing whether or not to include a `@implNote` to explain the natural sorted order of the property keys. When we started this whole PR proposal, Alan had hinted that maybe we should "specify" this behaviour. Should this be a `@implNote` or should this be part of the formal spec like we did for the system property handling? ------------- PR: https://git.openjdk.java.net/jdk/pull/5372 From duke at openjdk.java.net Tue Sep 14 12:09:08 2021 From: duke at openjdk.java.net (duke) Date: Tue, 14 Sep 2021 12:09:08 GMT Subject: Withdrawn: 8270057: Use Objects.checkFromToIndex for j.u.c.CopyOnWriteArrayList In-Reply-To: References: Message-ID: On Thu, 8 Jul 2021 11:51:18 GMT, Yi Yang wrote: > After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase. > > As Mandy suggested, I create this PR for changes involving JUC changes. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/4723 From alanb at openjdk.java.net Tue Sep 14 12:43:08 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 14 Sep 2021 12:43:08 GMT Subject: RFR: 8273401: Remove JarIndex support in URLClassPath [v2] In-Reply-To: References: Message-ID: On Wed, 8 Sep 2021 06:30:34 GMT, wxiang wrote: >> wxiang has updated the pull request incrementally with one additional commit since the last revision: >> >> Some minor changes >> >> Include: >> 1. remove public for INDEX_NAME in JarFile >> 2. recover the definition for INDEX_NAME in JarIndex >> 3. mv the test case JarIndexMergeTest.java into test/jdk/java/util/jar > > Create CSR: https://bugs.openjdk.java.net/browse/JDK-8273473 @shiyuexw I discussed this issue with other maintainers in this area. There was agreement on dropping the support from the URLClassLoader implementation but it was suggested that it should be disabled for a release or two before the code is removed. A system property can be used to re-enable. I've updated the CSR to reflect this proposal. Are you okay to continue with this new proposal? It would mean that we wouldn't remove the tests but instead change them to run with the system property. ------------- PR: https://git.openjdk.java.net/jdk/pull/5383 From sgehwolf at openjdk.java.net Tue Sep 14 12:47:11 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 14 Sep 2021 12:47:11 GMT Subject: RFR: 8273494: Zero: Put libjvm.so into "zero" folder, not "server" In-Reply-To: References: Message-ID: <_qfv6SEbfuo5um8s87v9BLlw7gwLdl-MdDbGvPZOR3g=.23f2ba5c-fc04-46bd-b167-2b027e88eae6@github.com> On Thu, 9 Sep 2021 10:17:02 GMT, Aleksey Shipilev wrote: > Currently, the build system defaults the libjvm.so location to "server". This makes looking for `libjvm.so` awkward, see JDK-8273487 for example. We need to see if moving the libjvm.so to a proper location breaks anything. > > Additional testing: > - [x] Linux x86_64 Zero build > - [x] Linux x86_64 Zero bootcycle-images > - [ ] Linux x86_64 Zero `tier1` Looks fine to me. ------------- Marked as reviewed by sgehwolf (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5440 From jpai at openjdk.java.net Tue Sep 14 12:48:05 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 14 Sep 2021 12:48:05 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v13] In-Reply-To: References: Message-ID: On Tue, 14 Sep 2021 02:30:01 GMT, Jaikiran Pai wrote: >> The commit in this PR implements the proposal for enhancement that was discussed in the core-libs-dev mailing list recently[1], for https://bugs.openjdk.java.net/browse/JDK-8231640 >> >> At a high level - the `store()` APIs in `Properties` have been modified to now look for the `SOURCE_DATE_EPOCH` environment variable[2]. If that env variable is set, then instead of writing out the current date time as a date comment, the `store()` APIs instead will use the value set for this env variable to parse it to a `Date` and write out the string form of such a date. The implementation here uses the `d MMM yyyy HH:mm:ss 'GMT'` date format and `Locale.ROOT` to format and write out such a date. This should provide reproducibility whenever the `SOURCE_DATE_EPOCH` is set. Furthermore, intentionally, no changes in the date format of the "current date" have been done. >> >> These modified `store()` APIs work in the presence of the `SecurityManager` too. The caller is expected to have a read permission on the `SOURCE_DATE_EPOCH` environment variable. If the caller doesn't have that permission, then the implementation of these `store()` APIs will write out the "current date" and will ignore any value that has been set for the `SOURCE_DATE_EPOCH` env variable. This should allow for backward compatibility of existing applications, where, when they run under a `SecurityManager` and perhaps with an existing restrictive policy file, the presence of `SOURCE_DATE_EPOCH` shouldn't impact their calls to the `store()` APIs. >> >> The modified `store()` APIs will also ignore any value for `SOURCE_DATE_EPOCH` that cannot be parsed to an `long` value. In such cases, the `store()` APIs will write out the "current date" and ignore the value set for this environment variable. No exceptions will be thrown for such invalid values. This is an additional backward compatibility precaution to prevent any rogue value for `SOURCE_DATE_EPOCH` from breaking applications. >> >> An additional change in the implementation of these `store()` APIs and unrelated to the date comment, is that these APIs will now write out the property keys in a deterministic order. The keys will be written out in the natural ordering as specified by `java.lang.String#compareTo()` API. >> >> The combination of the ordering of the property keys when written out and the usage of `SOURCE_DATE_EPOCH` environment value to determine the date comment should together allow for reproducibility of the output generated by these `store()` APIs. >> >> New jtreg test classes have been introduced to verify these changes. The primary focus of `PropertiesStoreTest` is the ordering aspects of the property keys that are written out. On the other hand `StoreReproducibilityTest` focuses on the reproducibility of the output generated by these APIs. The `StoreReproducibilityTest` runs these tests both in the presence and absence of `SecurityManager`. Plus, in the presence of SecurityManager, it tests both the scenarios where the caller is granted the requisite permission and in other case not granted that permission. >> >> These new tests and existing tests under `test/jdk/java/util/Properties/` pass with these changes. >> >> [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-August/080758.html >> [2] https://reproducible-builds.org/specs/source-date-epoch/ > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > unused imports I've created a CSR https://bugs.openjdk.java.net/browse/JDK-8273727 and added the details. I'll update that javadoc to include the properties order specification too once we decide whether it makes sense to have it in `@implNote` or as the main text. ------------- PR: https://git.openjdk.java.net/jdk/pull/5372 From naoto at openjdk.java.net Tue Sep 14 12:49:12 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 14 Sep 2021 12:49:12 GMT Subject: Integrated: 8273491: java.util.spi.LocaleServiceProvider spec contains statement that is too strict In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 23:29:24 GMT, Naoto Sato wrote: > Small spec clarification. Corresponding CSR has also been drafted. This pull request has now been integrated. Changeset: 31667daa Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/31667daa50b2faf82943821ee02071d222e38268 Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod 8273491: java.util.spi.LocaleServiceProvider spec contains statement that is too strict Reviewed-by: joehw, lancea ------------- PR: https://git.openjdk.java.net/jdk/pull/5457 From dfuchs at openjdk.java.net Tue Sep 14 13:01:10 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 14 Sep 2021 13:01:10 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v13] In-Reply-To: References: Message-ID: On Tue, 14 Sep 2021 11:59:56 GMT, Jaikiran Pai wrote: >> src/java.base/share/classes/java/util/Properties.java line 836: >> >>> 834: *

>>> 835: * Then every entry in this {@code Properties} table is >>> 836: * written out, one per line. For each entry the key string is >> >> Sorry for coming late to the party: I don't remember if this was already asked for and rejected - but shouldn't there be a non-normative `@implNote` here to state that the default implementation of this method will write the properties sorted by their keys in alphanumeric ordering? >> Otherwise this looks very good! > > Hello Daniel, you are right - I missed discussing whether or not to include a `@implNote` to explain the natural sorted order of the property keys. When we started this whole PR proposal, Alan had hinted that maybe we should "specify" this behaviour. Should this be a `@implNote` or should this be part of the formal spec like we did for the system property handling? I would leave it as an `@implNote` - or possibly `@implSpec`: depending on whether or not we want all implementations of the spec to behave in this way. However I don't think we would want to prevent subclasses from overriding this behavior and using their own business-logic ordering. So I believe the default behavior should be specified, if only so that subclasses can decide whether or not to override this method, without invalidating what subclasses might currently have implemented - or might wish to implement in the future. The CSR will be a good way to get feedback on whether `@implNote` or `@implSpec` is more appropriate. Also this is a change in behavior that needs to be made visible somewhere - and nobody reads release notes ;-) ------------- PR: https://git.openjdk.java.net/jdk/pull/5372 From jpai at openjdk.java.net Tue Sep 14 13:22:48 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 14 Sep 2021 13:22:48 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v14] In-Reply-To: References: Message-ID: > The commit in this PR implements the proposal for enhancement that was discussed in the core-libs-dev mailing list recently[1], for https://bugs.openjdk.java.net/browse/JDK-8231640 > > At a high level - the `store()` APIs in `Properties` have been modified to now look for the `SOURCE_DATE_EPOCH` environment variable[2]. If that env variable is set, then instead of writing out the current date time as a date comment, the `store()` APIs instead will use the value set for this env variable to parse it to a `Date` and write out the string form of such a date. The implementation here uses the `d MMM yyyy HH:mm:ss 'GMT'` date format and `Locale.ROOT` to format and write out such a date. This should provide reproducibility whenever the `SOURCE_DATE_EPOCH` is set. Furthermore, intentionally, no changes in the date format of the "current date" have been done. > > These modified `store()` APIs work in the presence of the `SecurityManager` too. The caller is expected to have a read permission on the `SOURCE_DATE_EPOCH` environment variable. If the caller doesn't have that permission, then the implementation of these `store()` APIs will write out the "current date" and will ignore any value that has been set for the `SOURCE_DATE_EPOCH` env variable. This should allow for backward compatibility of existing applications, where, when they run under a `SecurityManager` and perhaps with an existing restrictive policy file, the presence of `SOURCE_DATE_EPOCH` shouldn't impact their calls to the `store()` APIs. > > The modified `store()` APIs will also ignore any value for `SOURCE_DATE_EPOCH` that cannot be parsed to an `long` value. In such cases, the `store()` APIs will write out the "current date" and ignore the value set for this environment variable. No exceptions will be thrown for such invalid values. This is an additional backward compatibility precaution to prevent any rogue value for `SOURCE_DATE_EPOCH` from breaking applications. > > An additional change in the implementation of these `store()` APIs and unrelated to the date comment, is that these APIs will now write out the property keys in a deterministic order. The keys will be written out in the natural ordering as specified by `java.lang.String#compareTo()` API. > > The combination of the ordering of the property keys when written out and the usage of `SOURCE_DATE_EPOCH` environment value to determine the date comment should together allow for reproducibility of the output generated by these `store()` APIs. > > New jtreg test classes have been introduced to verify these changes. The primary focus of `PropertiesStoreTest` is the ordering aspects of the property keys that are written out. On the other hand `StoreReproducibilityTest` focuses on the reproducibility of the output generated by these APIs. The `StoreReproducibilityTest` runs these tests both in the presence and absence of `SecurityManager`. Plus, in the presence of SecurityManager, it tests both the scenarios where the caller is granted the requisite permission and in other case not granted that permission. > > These new tests and existing tests under `test/jdk/java/util/Properties/` pass with these changes. > > [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-August/080758.html > [2] https://reproducible-builds.org/specs/source-date-epoch/ Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision: - Add a @implNote to specify the order in which the properties are written out - update the javadoc to clarify how line terminator characters are handled in the value of the java.util.Properties.storeDate system property ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5372/files - new: https://git.openjdk.java.net/jdk/pull/5372/files/92374664..14711a92 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5372&range=13 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5372&range=12-13 Stats: 12 lines in 1 file changed: 5 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/5372.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5372/head:pull/5372 PR: https://git.openjdk.java.net/jdk/pull/5372 From dfuchs at openjdk.java.net Tue Sep 14 13:22:52 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 14 Sep 2021 13:22:52 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v14] In-Reply-To: References: Message-ID: On Tue, 14 Sep 2021 13:19:25 GMT, Jaikiran Pai wrote: >> The commit in this PR implements the proposal for enhancement that was discussed in the core-libs-dev mailing list recently[1], for https://bugs.openjdk.java.net/browse/JDK-8231640 >> >> At a high level - the `store()` APIs in `Properties` have been modified to now look for the `SOURCE_DATE_EPOCH` environment variable[2]. If that env variable is set, then instead of writing out the current date time as a date comment, the `store()` APIs instead will use the value set for this env variable to parse it to a `Date` and write out the string form of such a date. The implementation here uses the `d MMM yyyy HH:mm:ss 'GMT'` date format and `Locale.ROOT` to format and write out such a date. This should provide reproducibility whenever the `SOURCE_DATE_EPOCH` is set. Furthermore, intentionally, no changes in the date format of the "current date" have been done. >> >> These modified `store()` APIs work in the presence of the `SecurityManager` too. The caller is expected to have a read permission on the `SOURCE_DATE_EPOCH` environment variable. If the caller doesn't have that permission, then the implementation of these `store()` APIs will write out the "current date" and will ignore any value that has been set for the `SOURCE_DATE_EPOCH` env variable. This should allow for backward compatibility of existing applications, where, when they run under a `SecurityManager` and perhaps with an existing restrictive policy file, the presence of `SOURCE_DATE_EPOCH` shouldn't impact their calls to the `store()` APIs. >> >> The modified `store()` APIs will also ignore any value for `SOURCE_DATE_EPOCH` that cannot be parsed to an `long` value. In such cases, the `store()` APIs will write out the "current date" and ignore the value set for this environment variable. No exceptions will be thrown for such invalid values. This is an additional backward compatibility precaution to prevent any rogue value for `SOURCE_DATE_EPOCH` from breaking applications. >> >> An additional change in the implementation of these `store()` APIs and unrelated to the date comment, is that these APIs will now write out the property keys in a deterministic order. The keys will be written out in the natural ordering as specified by `java.lang.String#compareTo()` API. >> >> The combination of the ordering of the property keys when written out and the usage of `SOURCE_DATE_EPOCH` environment value to determine the date comment should together allow for reproducibility of the output generated by these `store()` APIs. >> >> New jtreg test classes have been introduced to verify these changes. The primary focus of `PropertiesStoreTest` is the ordering aspects of the property keys that are written out. On the other hand `StoreReproducibilityTest` focuses on the reproducibility of the output generated by these APIs. The `StoreReproducibilityTest` runs these tests both in the presence and absence of `SecurityManager`. Plus, in the presence of SecurityManager, it tests both the scenarios where the caller is granted the requisite permission and in other case not granted that permission. >> >> These new tests and existing tests under `test/jdk/java/util/Properties/` pass with these changes. >> >> [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-August/080758.html >> [2] https://reproducible-builds.org/specs/source-date-epoch/ > > Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision: > > - Add a @implNote to specify the order in which the properties are written out > - update the javadoc to clarify how line terminator characters are handled in the value of the java.util.Properties.storeDate system property src/java.base/share/classes/java/util/Properties.java line 822: > 820: * {@link System#lineSeparator() line separator} and if the next > 821: * character in comments is not character {@code #} or character {@code !} then > 822: * an ASCII {@code #} is written out after that line separator. Should something be done for comments ending with \ (backslash) ? It might otherwise suppress the first property assignment that follows. ------------- PR: https://git.openjdk.java.net/jdk/pull/5372 From jpai at openjdk.java.net Tue Sep 14 13:22:55 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 14 Sep 2021 13:22:55 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v13] In-Reply-To: References: Message-ID: On Tue, 14 Sep 2021 11:43:25 GMT, Magnus Ihse Bursie wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> unused imports > > src/java.base/share/classes/java/util/Properties.java line 828: > >> 826: * a comment line is written as follows. >> 827: * First, a {@code #} character is written, followed by the contents >> 828: * of the property, followed by a line separator. > > Maybe you should refer to how the comment is written out above, since you use the same method. The spec changes as written above does not specify how newlines in the property would be handled (which is possible to get, I believe, even if it means an intricate command line escape dance) Hello Magnus, > Maybe you should refer to how the comment is written out above, since you use the same method. I've updated the javadoc to capture this part of the detail. > The spec changes as written above does not specify how newlines in the property would be handled (which is possible to get, I believe, even if it means an intricate command line escape dance) The new tests that were added in this PR has one specific test to verify how line terminators are dealt with, if the system property value has them https://github.com/openjdk/jdk/pull/5372/files#diff-220f7bcc6d1a7ec33764f81eb95ccb0f69444e1eb923b015025e2140c3ffe145R280 ------------- PR: https://git.openjdk.java.net/jdk/pull/5372 From jpai at openjdk.java.net Tue Sep 14 13:22:58 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 14 Sep 2021 13:22:58 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v13] In-Reply-To: References: Message-ID: On Tue, 14 Sep 2021 12:56:28 GMT, Daniel Fuchs wrote: >> Hello Daniel, you are right - I missed discussing whether or not to include a `@implNote` to explain the natural sorted order of the property keys. When we started this whole PR proposal, Alan had hinted that maybe we should "specify" this behaviour. Should this be a `@implNote` or should this be part of the formal spec like we did for the system property handling? > > I would leave it as an `@implNote` - or possibly `@implSpec`: depending on whether or not we want all implementations of the spec to behave in this way. However I don't think we would want to prevent subclasses from overriding this behavior and using their own business-logic ordering. So I believe the default behavior should be specified, if only so that subclasses can decide whether or not to override this method, without invalidating what subclasses might currently have implemented - or might wish to implement in the future. The CSR will be a good way to get feedback on whether `@implNote` or `@implSpec` is more appropriate. Also this is a change in behavior that needs to be made visible somewhere - and nobody reads release notes ;-) Done. I've updated the PR to include a `@implNote` specifying the order of the properties. The CSR has been updated too to reflect this. ------------- PR: https://git.openjdk.java.net/jdk/pull/5372 From github.com+741251+turbanoff at openjdk.java.net Tue Sep 14 13:23:14 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Tue, 14 Sep 2021 13:23:14 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server In-Reply-To: References: Message-ID: <4x6-khhmw9bKpARkEOpSZSk8hfgFtdvuvv5ZIACrAuQ=.bed5405c-c05d-4361-aa97-8f27d10b61de@github.com> On Tue, 14 Sep 2021 08:52:37 GMT, Julia Boes wrote: > This change implements a simple web server that can be run on the command-line with `java -m jdk.httpserver`. > > This is facilitated by adding an entry point for the `jdk.httpserver` module, an implementation class whose main method is run when the above command is executed. This is the first such module entry point in the JDK. > > The server is a minimal HTTP server that serves the static files of a given directory, similar to existing alternatives on other platforms and convenient for testing, development, and debugging. > > Additionally, a small API is introduced for programmatic creation and customization. > > Testing: tier1-3. src/jdk.httpserver/share/classes/com/sun/net/httpserver/Headers.java line 106: > 104: var h = headers.entrySet().stream() > 105: .collect(Collectors.toUnmodifiableMap( > 106: Entry::getKey, e -> new LinkedList<>(e.getValue()))); I wonder, what the reason of `LinkedList` usages here? As I know ArrayList is faster in all real-world scenarios. ------------- PR: https://git.openjdk.java.net/jdk/pull/5505 From dfuchs at openjdk.java.net Tue Sep 14 13:22:58 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 14 Sep 2021 13:22:58 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v13] In-Reply-To: References: Message-ID: <6WLtwdyQIvHwYhponAy3p4t-0wy-S9XQzS-8kcw-Np4=.073a698c-6a80-4e2e-8e7f-a1dad6053153@github.com> On Tue, 14 Sep 2021 13:15:18 GMT, Jaikiran Pai wrote: >> I would leave it as an `@implNote` - or possibly `@implSpec`: depending on whether or not we want all implementations of the spec to behave in this way. However I don't think we would want to prevent subclasses from overriding this behavior and using their own business-logic ordering. So I believe the default behavior should be specified, if only so that subclasses can decide whether or not to override this method, without invalidating what subclasses might currently have implemented - or might wish to implement in the future. The CSR will be a good way to get feedback on whether `@implNote` or `@implSpec` is more appropriate. Also this is a change in behavior that needs to be made visible somewhere - and nobody reads release notes ;-) > > Done. I've updated the PR to include a `@implNote` specifying the order of the properties. The CSR has been updated too to reflect this. Thanks Jaikiran, - the `@implNote` looks good to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/5372 From jpai at openjdk.java.net Tue Sep 14 13:28:16 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 14 Sep 2021 13:28:16 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v14] In-Reply-To: References: Message-ID: <_JUn5s89HGKGku7OWlKBW--ECKJQM4YIGIZSj8sBj6Y=.f1e11100-2b5d-4d17-a170-3d0895449cb3@github.com> On Tue, 14 Sep 2021 13:17:42 GMT, Daniel Fuchs wrote: >> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision: >> >> - Add a @implNote to specify the order in which the properties are written out >> - update the javadoc to clarify how line terminator characters are handled in the value of the java.util.Properties.storeDate system property > > src/java.base/share/classes/java/util/Properties.java line 822: > >> 820: * {@link System#lineSeparator() line separator} and if the next >> 821: * character in comments is not character {@code #} or character {@code !} then >> 822: * an ASCII {@code #} is written out after that line separator. > > Should something be done for comments ending with \ (backslash) ? It might otherwise suppress the first property assignment that follows. There has been no change in how we deal with this aspect. The existing specification (stated in the `load` method) says: > * Properties are processed in terms of lines. There are two > * kinds of line, natural lines and logical lines. > * A natural line is defined as a line of > * characters that is terminated either by a set of line terminator > * characters ({@code \n} or {@code \r} or {@code \r\n}) > * or by the end of the stream. A natural line may be either a blank line, > * a comment line, or hold all or some of a key-element pair. A logical > * line holds all the data of a key-element pair, which may be spread > * out across several adjacent natural lines by escaping > * the line terminator sequence with a backslash character > * {@code }. **Note that a comment line cannot be extended > * in this manner;** (emphasis on that last sentence). I'll anyway go ahead and add new tests around this to be sure that this works as advertised. ------------- PR: https://git.openjdk.java.net/jdk/pull/5372 From dfuchs at openjdk.java.net Tue Sep 14 13:31:13 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 14 Sep 2021 13:31:13 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v14] In-Reply-To: <_JUn5s89HGKGku7OWlKBW--ECKJQM4YIGIZSj8sBj6Y=.f1e11100-2b5d-4d17-a170-3d0895449cb3@github.com> References: <_JUn5s89HGKGku7OWlKBW--ECKJQM4YIGIZSj8sBj6Y=.f1e11100-2b5d-4d17-a170-3d0895449cb3@github.com> Message-ID: On Tue, 14 Sep 2021 13:24:55 GMT, Jaikiran Pai wrote: >> src/java.base/share/classes/java/util/Properties.java line 822: >> >>> 820: * {@link System#lineSeparator() line separator} and if the next >>> 821: * character in comments is not character {@code #} or character {@code !} then >>> 822: * an ASCII {@code #} is written out after that line separator. >> >> Should something be done for comments ending with \ (backslash) ? It might otherwise suppress the first property assignment that follows. > > There has been no change in how we deal with this aspect. The existing specification (stated in the `load` method) says: > > >> * Properties are processed in terms of lines. There are two >> * kinds of line, natural lines and logical lines. >> * A natural line is defined as a line of >> * characters that is terminated either by a set of line terminator >> * characters ({@code \n} or {@code \r} or {@code \r\n}) >> * or by the end of the stream. A natural line may be either a blank line, >> * a comment line, or hold all or some of a key-element pair. A logical >> * line holds all the data of a key-element pair, which may be spread >> * out across several adjacent natural lines by escaping >> * the line terminator sequence with a backslash character >> * {@code }. **Note that a comment line cannot be extended >> * in this manner;** > (emphasis on that last sentence). > I'll anyway go ahead and add new tests around this to be sure that this works as advertised. Oh - great - thanks - verifying by a test that it also applies to the comment specified by `java.util.Properties.storeDate` would be good. ------------- PR: https://git.openjdk.java.net/jdk/pull/5372 From dfuchs at openjdk.java.net Tue Sep 14 13:41:03 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 14 Sep 2021 13:41:03 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server In-Reply-To: <4x6-khhmw9bKpARkEOpSZSk8hfgFtdvuvv5ZIACrAuQ=.bed5405c-c05d-4361-aa97-8f27d10b61de@github.com> References: <4x6-khhmw9bKpARkEOpSZSk8hfgFtdvuvv5ZIACrAuQ=.bed5405c-c05d-4361-aa97-8f27d10b61de@github.com> Message-ID: <31drgqqPbEvMqgrQwn2enoGWQNC-wj-_-mkU5Z-jqko=.5a74059f-49f6-41b7-9d28-ed82a386abe9@github.com> On Tue, 14 Sep 2021 13:19:17 GMT, Andrey Turbanov wrote: >> This change implements a simple web server that can be run on the command-line with `java -m jdk.httpserver`. >> >> This is facilitated by adding an entry point for the `jdk.httpserver` module, an implementation class whose main method is run when the above command is executed. This is the first such module entry point in the JDK. >> >> The server is a minimal HTTP server that serves the static files of a given directory, similar to existing alternatives on other platforms and convenient for testing, development, and debugging. >> >> Additionally, a small API is introduced for programmatic creation and customization. >> >> Testing: tier1-3. > > src/jdk.httpserver/share/classes/com/sun/net/httpserver/Headers.java line 106: > >> 104: var h = headers.entrySet().stream() >> 105: .collect(Collectors.toUnmodifiableMap( >> 106: Entry::getKey, e -> new LinkedList<>(e.getValue()))); > > I wonder, what the reason of `LinkedList` usages here? > As I know ArrayList is faster in all real-world scenarios. Hi Andrey, IIRC from when I reviewed this code the current implementation of `Headers` already uses `LinkedList` in other places - so this preserves the concrete list implementation class that `Headers` uses (see `Headers::add`). Not that it matters much - but if we wanted to replace `LinkedList` with `ArrayList` I believe we should do it consistently in this class - and probably outside of the realm of this JEP. ------------- PR: https://git.openjdk.java.net/jdk/pull/5505 From herrick at openjdk.java.net Tue Sep 14 13:48:43 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Tue, 14 Sep 2021 13:48:43 GMT Subject: RFR: JDK-8273040: Turning off JpAllowDowngrades (or Upgrades) Message-ID: JDK-8273040: Turning off JpAllowDowngrades (or Upgrades) ------------- Commit messages: - JDK-8273040: Turning off JpAllowDowngrades (or Upgrades) - JDK-8273040: Turning off JpAllowDowngrades (or Upgrades) Changes: https://git.openjdk.java.net/jdk/pull/5509/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5509&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273040 Stats: 17 lines in 3 files changed: 7 ins; 5 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/5509.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5509/head:pull/5509 PR: https://git.openjdk.java.net/jdk/pull/5509 From github.com+741251+turbanoff at openjdk.java.net Tue Sep 14 13:51:05 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Tue, 14 Sep 2021 13:51:05 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server In-Reply-To: References: Message-ID: <3UnSj9AyBgLbpVUUeJzvsI30F_2pU_Vt4f54wFPb-Us=.56ea3d8e-5b11-4924-9a80-2ae7db83ab1f@github.com> On Tue, 14 Sep 2021 08:52:37 GMT, Julia Boes wrote: > This change implements a simple web server that can be run on the command-line with `java -m jdk.httpserver`. > > This is facilitated by adding an entry point for the `jdk.httpserver` module, an implementation class whose main method is run when the above command is executed. This is the first such module entry point in the JDK. > > The server is a minimal HTTP server that serves the static files of a given directory, similar to existing alternatives on other platforms and convenient for testing, development, and debugging. > > Additionally, a small API is introduced for programmatic creation and customization. > > Testing: tier1-3. src/jdk.httpserver/share/classes/com/sun/net/httpserver/Headers.java line 288: > 286: } > 287: > 288: private static final Headers EMPTY = new UnmodifiableHeaders(new Headers()); IDEA warns here: >Referencing subclass UnmodifiableHeaders from superclass Headers initializer might lead to class loading deadlock >Such references can cause JVM-level deadlocks in multithreaded environment, when one thread tries to load the superclass and another thread tries to load the subclass at the same time. ------------- PR: https://git.openjdk.java.net/jdk/pull/5505 From jpai at openjdk.java.net Tue Sep 14 14:02:10 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 14 Sep 2021 14:02:10 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v15] In-Reply-To: References: Message-ID: > The commit in this PR implements the proposal for enhancement that was discussed in the core-libs-dev mailing list recently[1], for https://bugs.openjdk.java.net/browse/JDK-8231640 > > At a high level - the `store()` APIs in `Properties` have been modified to now look for the `SOURCE_DATE_EPOCH` environment variable[2]. If that env variable is set, then instead of writing out the current date time as a date comment, the `store()` APIs instead will use the value set for this env variable to parse it to a `Date` and write out the string form of such a date. The implementation here uses the `d MMM yyyy HH:mm:ss 'GMT'` date format and `Locale.ROOT` to format and write out such a date. This should provide reproducibility whenever the `SOURCE_DATE_EPOCH` is set. Furthermore, intentionally, no changes in the date format of the "current date" have been done. > > These modified `store()` APIs work in the presence of the `SecurityManager` too. The caller is expected to have a read permission on the `SOURCE_DATE_EPOCH` environment variable. If the caller doesn't have that permission, then the implementation of these `store()` APIs will write out the "current date" and will ignore any value that has been set for the `SOURCE_DATE_EPOCH` env variable. This should allow for backward compatibility of existing applications, where, when they run under a `SecurityManager` and perhaps with an existing restrictive policy file, the presence of `SOURCE_DATE_EPOCH` shouldn't impact their calls to the `store()` APIs. > > The modified `store()` APIs will also ignore any value for `SOURCE_DATE_EPOCH` that cannot be parsed to an `long` value. In such cases, the `store()` APIs will write out the "current date" and ignore the value set for this environment variable. No exceptions will be thrown for such invalid values. This is an additional backward compatibility precaution to prevent any rogue value for `SOURCE_DATE_EPOCH` from breaking applications. > > An additional change in the implementation of these `store()` APIs and unrelated to the date comment, is that these APIs will now write out the property keys in a deterministic order. The keys will be written out in the natural ordering as specified by `java.lang.String#compareTo()` API. > > The combination of the ordering of the property keys when written out and the usage of `SOURCE_DATE_EPOCH` environment value to determine the date comment should together allow for reproducibility of the output generated by these `store()` APIs. > > New jtreg test classes have been introduced to verify these changes. The primary focus of `PropertiesStoreTest` is the ordering aspects of the property keys that are written out. On the other hand `StoreReproducibilityTest` focuses on the reproducibility of the output generated by these APIs. The `StoreReproducibilityTest` runs these tests both in the presence and absence of `SecurityManager`. Plus, in the presence of SecurityManager, it tests both the scenarios where the caller is granted the requisite permission and in other case not granted that permission. > > These new tests and existing tests under `test/jdk/java/util/Properties/` pass with these changes. > > [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-August/080758.html > [2] https://reproducible-builds.org/specs/source-date-epoch/ Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: Introduce a test to make sure backslash character in the system property value doesn't cause unexpected output. Plus minor updates to tests to add additional checks. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5372/files - new: https://git.openjdk.java.net/jdk/pull/5372/files/14711a92..6f5f1be2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5372&range=14 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5372&range=13-14 Stats: 65 lines in 1 file changed: 64 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5372.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5372/head:pull/5372 PR: https://git.openjdk.java.net/jdk/pull/5372 From jpai at openjdk.java.net Tue Sep 14 14:12:07 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 14 Sep 2021 14:12:07 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v14] In-Reply-To: References: <_JUn5s89HGKGku7OWlKBW--ECKJQM4YIGIZSj8sBj6Y=.f1e11100-2b5d-4d17-a170-3d0895449cb3@github.com> Message-ID: On Tue, 14 Sep 2021 13:28:24 GMT, Daniel Fuchs wrote: >> There has been no change in how we deal with this aspect. The existing specification (stated in the `load` method) says: >> >> >>> * Properties are processed in terms of lines. There are two >>> * kinds of line, natural lines and logical lines. >>> * A natural line is defined as a line of >>> * characters that is terminated either by a set of line terminator >>> * characters ({@code \n} or {@code \r} or {@code \r\n}) >>> * or by the end of the stream. A natural line may be either a blank line, >>> * a comment line, or hold all or some of a key-element pair. A logical >>> * line holds all the data of a key-element pair, which may be spread >>> * out across several adjacent natural lines by escaping >>> * the line terminator sequence with a backslash character >>> * {@code }. **Note that a comment line cannot be extended >>> * in this manner;** >> (emphasis on that last sentence). >> I'll anyway go ahead and add new tests around this to be sure that this works as advertised. > > Oh - great - thanks - verifying by a test that it also applies to the comment specified by `java.util.Properties.storeDate` would be good. Done. A new test `StoreReproducibilityTest#testBackSlashInStoreDateValue` has been added in the latest updated version of this PR. This test passes. Plus I checked the written out properties file, from these tests, for such values in `java.util.Properties.storeDate` and the content matches what the spec says. Just for quick reference - a run of that test case with the "newline-plus-backslash...." system property value (cannot paste that exact string value from that test case because GitHub editor is messing up the special characters) generates output like below: #some user specified comment #newline-plus-backslash\ #c=d a=b ------------- PR: https://git.openjdk.java.net/jdk/pull/5372 From aefimov at openjdk.java.net Tue Sep 14 14:18:08 2021 From: aefimov at openjdk.java.net (Aleksei Efimov) Date: Tue, 14 Sep 2021 14:18:08 GMT Subject: RFR: 8273402: Use derived NamingExceptions in com.sun.jndi.ldap.Connection#readReply In-Reply-To: References: Message-ID: On Fri, 10 Sep 2021 17:04:58 GMT, Michael Osipov wrote: >> Hi, >> The following fix changes type of exception thrown when an LDAP operation fails for reasons like read timeout or connection closure/cancellation: instead of throwing a general `NamingException`, the internal LDAP connection class will throw a [`CommunicationException`](https://github.com/openjdk/jdk/blob/master/src/java.naming/share/classes/javax/naming/CommunicationException.java#L29) that better matches the reasons described. >> >> Testing shows no problem with the proposed fix. > > @AlekseiEfimov Thanks for making this happen so fast. Do you see any chance to have this backported to LTS releases where this is required? I have reported the issue initially and like to make this available in Tomcat 8.5+. Hi @michael-o, I'm not involved in the backporting process to older releases. You'll need to find the right contact for a particular release you need a backport for, and ask there. ------------- PR: https://git.openjdk.java.net/jdk/pull/5456 From mbaesken at openjdk.java.net Tue Sep 14 14:27:36 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Tue, 14 Sep 2021 14:27:36 GMT Subject: RFR: JDK-8273526: Extend the OSContainer API pids controller with pids.current [v3] In-Reply-To: References: Message-ID: > https://bugs.openjdk.java.net/browse/JDK-8266490 > extended the OSContainer API in order to also support the pids controller of cgroups. However only pids.max output was added with 8266490. > There is a second parameter pids.current , see https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#pid > that would be helpful too and can be added to the OSContainer API . > pids.current : > A read-only single value file which exists on all cgroups. > The number of processes currently in the cgroup and its descendants. > > Best regards, Matthias Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Simplify coding following Severins advice ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5437/files - new: https://git.openjdk.java.net/jdk/pull/5437/files/422aef68..afe0efd4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5437&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5437&range=01-02 Stats: 31 lines in 6 files changed: 1 ins; 27 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5437.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5437/head:pull/5437 PR: https://git.openjdk.java.net/jdk/pull/5437 From mbaesken at openjdk.java.net Tue Sep 14 14:27:40 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Tue, 14 Sep 2021 14:27:40 GMT Subject: RFR: JDK-8273526: Extend the OSContainer API pids controller with pids.current [v2] In-Reply-To: <3PokFyPHsil0S9A15OWUj97Xls1tFpkeXuqHydXnh4o=.64e6daaa-5dc3-438c-b362-ba61775d1403@github.com> References: <3PokFyPHsil0S9A15OWUj97Xls1tFpkeXuqHydXnh4o=.64e6daaa-5dc3-438c-b362-ba61775d1403@github.com> Message-ID: On Fri, 10 Sep 2021 11:07:52 GMT, Matthias Baesken wrote: >> https://bugs.openjdk.java.net/browse/JDK-8266490 >> extended the OSContainer API in order to also support the pids controller of cgroups. However only pids.max output was added with 8266490. >> There is a second parameter pids.current , see https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#pid >> that would be helpful too and can be added to the OSContainer API . >> pids.current : >> A read-only single value file which exists on all cgroups. >> The number of processes currently in the cgroup and its descendants. >> >> Best regards, Matthias > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Some simplifications and test adjustment suggested by Severin Hi Severin, I adjusted my change following your latest comments. Thanks, Matthias ------------- PR: https://git.openjdk.java.net/jdk/pull/5437 From github.com+573017+michael-o at openjdk.java.net Tue Sep 14 15:15:09 2021 From: github.com+573017+michael-o at openjdk.java.net (Michael Osipov) Date: Tue, 14 Sep 2021 15:15:09 GMT Subject: RFR: 8273402: Use derived NamingExceptions in com.sun.jndi.ldap.Connection#readReply In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 22:02:55 GMT, Aleksei Efimov wrote: > Hi, > The following fix changes type of exception thrown when an LDAP operation fails for reasons like read timeout or connection closure/cancellation: instead of throwing a general `NamingException`, the internal LDAP connection class will throw a [`CommunicationException`](https://github.com/openjdk/jdk/blob/master/src/java.naming/share/classes/javax/naming/CommunicationException.java#L29) that better matches the reasons described. > > Testing shows no problem with the proposed fix. Thanks, will do. ------------- PR: https://git.openjdk.java.net/jdk/pull/5456 From psandoz at openjdk.java.net Tue Sep 14 15:19:07 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Tue, 14 Sep 2021 15:19:07 GMT Subject: RFR: 8273711: Remove redundant stream() call before forEach in jdk.jlink In-Reply-To: <3ABdvBiCu8znAgbmq2XW3wsWVEPqwIGbPJnmEdW-1jc=.2148d9d8-f14f-49ad-a58f-6f843bba27d3@github.com> References: <3ABdvBiCu8znAgbmq2XW3wsWVEPqwIGbPJnmEdW-1jc=.2148d9d8-f14f-49ad-a58f-6f843bba27d3@github.com> Message-ID: <6Sv50vuaUvaU8zpxqAEU4W13ZqAG7KlaJqLNzFWeVrQ=.2464fdc8-e7a9-4491-8d4e-9bbdb525191f@github.com> On Mon, 13 Sep 2021 20:06:08 GMT, Andrey Turbanov wrote: > 8273711: Remove redundant stream() call before forEach in jdk.jlink In some cases you can use a method ref (no need for another review if you update those). src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ReleaseInfoPlugin.java line 102: > 100: throw new IllegalArgumentException("No key specified for delete"); > 101: } > 102: Utils.parseList(keys).forEach((k) -> { Use method ref: `release::remove` ------------- Marked as reviewed by psandoz (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5500 From jpai at openjdk.java.net Tue Sep 14 15:34:03 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 14 Sep 2021 15:34:03 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server In-Reply-To: References: Message-ID: On Tue, 14 Sep 2021 08:52:37 GMT, Julia Boes wrote: > This change implements a simple web server that can be run on the command-line with `java -m jdk.httpserver`. > > This is facilitated by adding an entry point for the `jdk.httpserver` module, an implementation class whose main method is run when the above command is executed. This is the first such module entry point in the JDK. > > The server is a minimal HTTP server that serves the static files of a given directory, similar to existing alternatives on other platforms and convenient for testing, development, and debugging. > > Additionally, a small API is introduced for programmatic creation and customization. > > Testing: tier1-3. src/java.base/windows/classes/sun/net/www/content-types.properties line 30: > 28: application/octet-stream: \ > 29: description=Generic Binary Stream;\ > 30: file_extensions=.saveme,.dump,.hqx,.arc,.obj,.lib,.bin,.exe,.gz Hello Julia, Is this an intentional change, to remove the mapping of `.zip` to `application/octet-stream`? In a later part of this patch there's a commented out test `testCommonExtensions` which deals with these extension types and that has a link to https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Common_types which states that `.zip` should be mapped to `application/zip` instead of the current `application/octet-stream`, so I'm guessing this changed line is intentional. On an unrelated note, the unix variant of this file `src/java.base/unix/classes/sun/net/www/content-types.properties` interestingly uses `.z` for `.zip`? Commit history on that file doesn't provide any hint on whether that is intentional either. ------------- PR: https://git.openjdk.java.net/jdk/pull/5505 From jpai at openjdk.java.net Tue Sep 14 15:45:11 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 14 Sep 2021 15:45:11 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server In-Reply-To: References: Message-ID: On Tue, 14 Sep 2021 15:30:31 GMT, Jaikiran Pai wrote: >> This change implements a simple web server that can be run on the command-line with `java -m jdk.httpserver`. >> >> This is facilitated by adding an entry point for the `jdk.httpserver` module, an implementation class whose main method is run when the above command is executed. This is the first such module entry point in the JDK. >> >> The server is a minimal HTTP server that serves the static files of a given directory, similar to existing alternatives on other platforms and convenient for testing, development, and debugging. >> >> Additionally, a small API is introduced for programmatic creation and customization. >> >> Testing: tier1-3. > > src/java.base/windows/classes/sun/net/www/content-types.properties line 30: > >> 28: application/octet-stream: \ >> 29: description=Generic Binary Stream;\ >> 30: file_extensions=.saveme,.dump,.hqx,.arc,.obj,.lib,.bin,.exe,.gz > > Hello Julia, > Is this an intentional change, to remove the mapping of `.zip` to `application/octet-stream`? In a later part of this patch there's a commented out test `testCommonExtensions` which deals with these extension types and that has a link to https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Common_types which states that `.zip` should be mapped to `application/zip` instead of the current `application/octet-stream`, so I'm guessing this changed line is intentional. > > On an unrelated note, the unix variant of this file `src/java.base/unix/classes/sun/net/www/content-types.properties` interestingly uses `.z` for `.zip`? Commit history on that file doesn't provide any hint on whether that is intentional either. I think you can ignore my comment above. I went and checked the `content-types.properties` in their current state for both unix and windows and they already have a separate `application/zip` which is mapped to `.zip`. So I think this above change shouldn't impact anything. ------------- PR: https://git.openjdk.java.net/jdk/pull/5505 From shade at openjdk.java.net Tue Sep 14 15:53:08 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 14 Sep 2021 15:53:08 GMT Subject: RFR: 8273494: Zero: Put libjvm.so into "zero" folder, not "server" In-Reply-To: References: Message-ID: On Fri, 10 Sep 2021 10:02:43 GMT, David Holmes wrote: >> Currently, the build system defaults the libjvm.so location to "server". This makes looking for `libjvm.so` awkward, see JDK-8273487 for example. We need to see if moving the libjvm.so to a proper location breaks anything. >> >> Additional testing: >> - [x] Linux x86_64 Zero build >> - [x] Linux x86_64 Zero bootcycle-images >> - [x] Linux x86_64 Zero `tier1` > > It isn't the "formal governance" I'm concerned about, more about the folk who use/rely on Zero being the ones to evaluate the impact of a change like this. People, like myself, who do not use Zero in any way cannot evaluate whether this change is appropriate - it's that simple. :) I'll be happy to integrate as long as @dholmes-ora has no objections. ------------- PR: https://git.openjdk.java.net/jdk/pull/5440 From jboes at openjdk.java.net Tue Sep 14 16:00:02 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Tue, 14 Sep 2021 16:00:02 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server In-Reply-To: References: Message-ID: On Tue, 14 Sep 2021 15:42:06 GMT, Jaikiran Pai wrote: >> src/java.base/windows/classes/sun/net/www/content-types.properties line 30: >> >>> 28: application/octet-stream: \ >>> 29: description=Generic Binary Stream;\ >>> 30: file_extensions=.saveme,.dump,.hqx,.arc,.obj,.lib,.bin,.exe,.gz >> >> Hello Julia, >> Is this an intentional change, to remove the mapping of `.zip` to `application/octet-stream`? In a later part of this patch there's a commented out test `testCommonExtensions` which deals with these extension types and that has a link to https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Common_types which states that `.zip` should be mapped to `application/zip` instead of the current `application/octet-stream`, so I'm guessing this changed line is intentional. >> >> On an unrelated note, the unix variant of this file `src/java.base/unix/classes/sun/net/www/content-types.properties` interestingly uses `.z` for `.zip`? Commit history on that file doesn't provide any hint on whether that is intentional either. > > I think you can ignore my comment above. I went and checked the `content-types.properties` in their current state for both unix and windows and they already have a separate `application/zip` which is mapped to `.zip`. So I think this above change shouldn't impact anything. That's right, there was a duplicate entry for `.zip` in the Windows properties file only, which I removed. I'm not sure if `.z` in the Unix properties file is intentional, but I do have a PR in progress in the same area, which I will link here shortly. ------------- PR: https://git.openjdk.java.net/jdk/pull/5505 From jboes at openjdk.java.net Tue Sep 14 16:10:09 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Tue, 14 Sep 2021 16:10:09 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server In-Reply-To: <3UnSj9AyBgLbpVUUeJzvsI30F_2pU_Vt4f54wFPb-Us=.56ea3d8e-5b11-4924-9a80-2ae7db83ab1f@github.com> References: <3UnSj9AyBgLbpVUUeJzvsI30F_2pU_Vt4f54wFPb-Us=.56ea3d8e-5b11-4924-9a80-2ae7db83ab1f@github.com> Message-ID: On Tue, 14 Sep 2021 13:47:48 GMT, Andrey Turbanov wrote: >> This change implements a simple web server that can be run on the command-line with `java -m jdk.httpserver`. >> >> This is facilitated by adding an entry point for the `jdk.httpserver` module, an implementation class whose main method is run when the above command is executed. This is the first such module entry point in the JDK. >> >> The server is a minimal HTTP server that serves the static files of a given directory, similar to existing alternatives on other platforms and convenient for testing, development, and debugging. >> >> Additionally, a small API is introduced for programmatic creation and customization. >> >> Testing: tier1-3. > > src/jdk.httpserver/share/classes/com/sun/net/httpserver/Headers.java line 288: > >> 286: } >> 287: >> 288: private static final Headers EMPTY = new UnmodifiableHeaders(new Headers()); > > IDEA warns here: >>Referencing subclass UnmodifiableHeaders from superclass Headers initializer might lead to class loading deadlock >>Such references can cause JVM-level deadlocks in multithreaded environment, when one thread tries to load the superclass and another thread tries to load the subclass at the same time. Interesting, thanks for noting. We can return a new instance instead on line 307, the only place the constant is used. ------------- PR: https://git.openjdk.java.net/jdk/pull/5505 From asemenyuk at openjdk.java.net Tue Sep 14 16:13:01 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Tue, 14 Sep 2021 16:13:01 GMT Subject: RFR: JDK-8273040: Turning off JpAllowDowngrades (or Upgrades) In-Reply-To: References: Message-ID: On Tue, 14 Sep 2021 13:38:42 GMT, Andy Herrick wrote: > JDK-8273040: Turning off JpAllowDowngrades (or Upgrades) Marked as reviewed by asemenyuk (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5509 From dfuchs at openjdk.java.net Tue Sep 14 16:22:03 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 14 Sep 2021 16:22:03 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server In-Reply-To: References: <3UnSj9AyBgLbpVUUeJzvsI30F_2pU_Vt4f54wFPb-Us=.56ea3d8e-5b11-4924-9a80-2ae7db83ab1f@github.com> Message-ID: On Tue, 14 Sep 2021 16:07:21 GMT, Julia Boes wrote: >> src/jdk.httpserver/share/classes/com/sun/net/httpserver/Headers.java line 288: >> >>> 286: } >>> 287: >>> 288: private static final Headers EMPTY = new UnmodifiableHeaders(new Headers()); >> >> IDEA warns here: >>>Referencing subclass UnmodifiableHeaders from superclass Headers initializer might lead to class loading deadlock >>>Such references can cause JVM-level deadlocks in multithreaded environment, when one thread tries to load the superclass and another thread tries to load the subclass at the same time. > > Interesting, thanks for noting. We can return a new instance instead on line 307, the only place the constant is used. Or you could possibly define the constant in UnmodifiableHeaders instead. ------------- PR: https://git.openjdk.java.net/jdk/pull/5505 From jlaskey at openjdk.java.net Tue Sep 14 16:33:04 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Tue, 14 Sep 2021 16:33:04 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server In-Reply-To: References: Message-ID: <50yuahjxwmeRdrRh1z6VLAbscVU5sJ3w4qddmNMBDJ0=.408e29b1-7644-40c9-83ca-59d3ebba9633@github.com> On Tue, 14 Sep 2021 08:52:37 GMT, Julia Boes wrote: > This change implements a simple web server that can be run on the command-line with `java -m jdk.httpserver`. > > This is facilitated by adding an entry point for the `jdk.httpserver` module, an implementation class whose main method is run when the above command is executed. This is the first such module entry point in the JDK. > > The server is a minimal HTTP server that serves the static files of a given directory, similar to existing alternatives on other platforms and convenient for testing, development, and debugging. > > Additionally, a small API is introduced for programmatic creation and customization. > > Testing: tier1-3. Very nice. LGTM. src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpHandlers.java line 128: > 126: *

{@code headers} are the effective headers of the response. The > 127: * response body bytes are a {@code UTF-8} encoded byte sequence of > 128: * {@code body}. The response {@linkplain HttpExchange#sendResponseHeaders(int, long) is sent} Not sure what the javadoc looks like here, but it looks like the link is "is sent". Curious. src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpsServer.java line 152: > 150: return server; > 151: } > 152: Too bad we couldn't simplify the setting up a basic certificate for https. ------------- Marked as reviewed by jlaskey (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5505 From jlaskey at openjdk.java.net Tue Sep 14 16:33:05 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Tue, 14 Sep 2021 16:33:05 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server In-Reply-To: <50yuahjxwmeRdrRh1z6VLAbscVU5sJ3w4qddmNMBDJ0=.408e29b1-7644-40c9-83ca-59d3ebba9633@github.com> References: <50yuahjxwmeRdrRh1z6VLAbscVU5sJ3w4qddmNMBDJ0=.408e29b1-7644-40c9-83ca-59d3ebba9633@github.com> Message-ID: On Tue, 14 Sep 2021 12:36:28 GMT, Jim Laskey wrote: >> This change implements a simple web server that can be run on the command-line with `java -m jdk.httpserver`. >> >> This is facilitated by adding an entry point for the `jdk.httpserver` module, an implementation class whose main method is run when the above command is executed. This is the first such module entry point in the JDK. >> >> The server is a minimal HTTP server that serves the static files of a given directory, similar to existing alternatives on other platforms and convenient for testing, development, and debugging. >> >> Additionally, a small API is introduced for programmatic creation and customization. >> >> Testing: tier1-3. > > src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpHandlers.java line 128: > >> 126: *

{@code headers} are the effective headers of the response. The >> 127: * response body bytes are a {@code UTF-8} encoded byte sequence of >> 128: * {@code body}. The response {@linkplain HttpExchange#sendResponseHeaders(int, long) is sent} > > Not sure what the javadoc looks like here, but it looks like the link is "is sent". Curious. Just a rewording, maybe. ------------- PR: https://git.openjdk.java.net/jdk/pull/5505 From sgehwolf at openjdk.java.net Tue Sep 14 16:36:09 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 14 Sep 2021 16:36:09 GMT Subject: RFR: JDK-8273526: Extend the OSContainer API pids controller with pids.current [v3] In-Reply-To: References: Message-ID: <3aTKQILDCNwWGM4TGKA-YjW86UQFqKujjWyrGkrNf-s=.e489ddac-53dd-4c91-a608-e5b04f95f5ec@github.com> On Tue, 14 Sep 2021 14:27:36 GMT, Matthias Baesken wrote: >> https://bugs.openjdk.java.net/browse/JDK-8266490 >> extended the OSContainer API in order to also support the pids controller of cgroups. However only pids.max output was added with 8266490. >> There is a second parameter pids.current , see https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#pid >> that would be helpful too and can be added to the OSContainer API . >> pids.current : >> A read-only single value file which exists on all cgroups. >> The number of processes currently in the cgroup and its descendants. >> >> Best regards, Matthias > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Simplify coding following Severins advice Looks fine. I suggest to move the debug printing from line 99 to after line 101 as suggested here: https://github.com/openjdk/jdk/pull/5437#discussion_r706145165 ------------- Marked as reviewed by sgehwolf (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5437 From iklam at openjdk.java.net Tue Sep 14 16:40:11 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 14 Sep 2021 16:40:11 GMT Subject: RFR: JDK-8273526: Extend the OSContainer API pids controller with pids.current [v3] In-Reply-To: References: Message-ID: On Tue, 14 Sep 2021 14:27:36 GMT, Matthias Baesken wrote: >> https://bugs.openjdk.java.net/browse/JDK-8266490 >> extended the OSContainer API in order to also support the pids controller of cgroups. However only pids.max output was added with 8266490. >> There is a second parameter pids.current , see https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#pid >> that would be helpful too and can be added to the OSContainer API . >> pids.current : >> A read-only single value file which exists on all cgroups. >> The number of processes currently in the cgroup and its descendants. >> >> Best regards, Matthias > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Simplify coding following Severins advice HotSpot changes look good to me. I have a comment on the test. test/hotspot/jtreg/containers/docker/TestPids.java line 97: > 95: System.out.println("DEBUG: parts.length = " + parts.length); > 96: if (expectedValue.equals("no_value_expected")) { > 97: Asserts.assertEquals(parts.length, 2); Is "no_value_expected" generated by Docker? I searched the entire HotSpot source code and couldn't find it. I also couldn't find "WARNING: Your kernel does not support pids limit capabilities". To make it easier to understand this test, I would suggest grouping all messages that were generated outside of HotSpot into something like: // These messages are generated by Docker static final String warning_kernel_no_pids_support = "WARNING: Your kernel does not support pids limit capabilities"; static final String no_value_expected = "no_value_expected"; ------------- PR: https://git.openjdk.java.net/jdk/pull/5437 From dfuchs at openjdk.java.net Tue Sep 14 16:51:08 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 14 Sep 2021 16:51:08 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server In-Reply-To: References: <50yuahjxwmeRdrRh1z6VLAbscVU5sJ3w4qddmNMBDJ0=.408e29b1-7644-40c9-83ca-59d3ebba9633@github.com> Message-ID: On Tue, 14 Sep 2021 12:38:19 GMT, Jim Laskey wrote: >> src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpHandlers.java line 128: >> >>> 126: *

{@code headers} are the effective headers of the response. The >>> 127: * response body bytes are a {@code UTF-8} encoded byte sequence of >>> 128: * {@code body}. The response {@linkplain HttpExchange#sendResponseHeaders(int, long) is sent} >> >> Not sure what the javadoc looks like here, but it looks like the link is "is sent". Curious. > > Just a rewording, maybe. Hmm... Maye that should be "The response headers *are sent*". The non-obvious technical details is that the response headers are sent before the body - as soon as you call `sendResponseHeaders`. The link is here to provide a better understanding of the workings of the new Handler. The headers are sent by calling `sendResponseHeaders` on the HttpExchange. ------------- PR: https://git.openjdk.java.net/jdk/pull/5505 From dfuchs at openjdk.java.net Tue Sep 14 16:51:09 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 14 Sep 2021 16:51:09 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server In-Reply-To: References: Message-ID: On Tue, 14 Sep 2021 08:52:37 GMT, Julia Boes wrote: > This change implements a simple web server that can be run on the command-line with `java -m jdk.httpserver`. > > This is facilitated by adding an entry point for the `jdk.httpserver` module, an implementation class whose main method is run when the above command is executed. This is the first such module entry point in the JDK. > > The server is a minimal HTTP server that serves the static files of a given directory, similar to existing alternatives on other platforms and convenient for testing, development, and debugging. > > Additionally, a small API is introduced for programmatic creation and customization. > > Testing: tier1-3. src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpHandlers.java line 129: > 127: * response body bytes are a {@code UTF-8} encoded byte sequence of > 128: * {@code body}. The response {@linkplain HttpExchange#sendResponseHeaders(int, long) is sent} > 129: * with the given {@code statusCode} and the body bytes' length. The body That might give the impression that chunked encoding will be used if the body length is 0. I wonder if it should say instead: with the given {@code statusCode} and a {@code Content-Length} field set to the body bytes' length. ------------- PR: https://git.openjdk.java.net/jdk/pull/5505 From dfuchs at openjdk.java.net Tue Sep 14 16:55:08 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 14 Sep 2021 16:55:08 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server In-Reply-To: References: Message-ID: On Tue, 14 Sep 2021 16:47:45 GMT, Daniel Fuchs wrote: >> This change implements a simple web server that can be run on the command-line with `java -m jdk.httpserver`. >> >> This is facilitated by adding an entry point for the `jdk.httpserver` module, an implementation class whose main method is run when the above command is executed. This is the first such module entry point in the JDK. >> >> The server is a minimal HTTP server that serves the static files of a given directory, similar to existing alternatives on other platforms and convenient for testing, development, and debugging. >> >> Additionally, a small API is introduced for programmatic creation and customization. >> >> Testing: tier1-3. > > src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpHandlers.java line 129: > >> 127: * response body bytes are a {@code UTF-8} encoded byte sequence of >> 128: * {@code body}. The response {@linkplain HttpExchange#sendResponseHeaders(int, long) is sent} >> 129: * with the given {@code statusCode} and the body bytes' length. The body > > That might give the impression that chunked encoding will be used if the body length is 0. I wonder if it should say instead: > > > with the given {@code statusCode} and a {@code Content-Length} field set to the body bytes' length. Or maybe - which would be more accurate: with the given {@code statusCode} and the body bytes' length (or {@code -1} if the body is empty). ------------- PR: https://git.openjdk.java.net/jdk/pull/5505 From iklam at openjdk.java.net Tue Sep 14 17:28:03 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 14 Sep 2021 17:28:03 GMT Subject: RFR: JDK-8273526: Extend the OSContainer API pids controller with pids.current [v3] In-Reply-To: References: Message-ID: On Tue, 14 Sep 2021 16:36:24 GMT, Ioi Lam wrote: >> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: >> >> Simplify coding following Severins advice > > test/hotspot/jtreg/containers/docker/TestPids.java line 97: > >> 95: System.out.println("DEBUG: parts.length = " + parts.length); >> 96: if (expectedValue.equals("no_value_expected")) { >> 97: Asserts.assertEquals(parts.length, 2); > > Is "no_value_expected" generated by Docker? I searched the entire HotSpot source code and couldn't find it. I also couldn't find "WARNING: Your kernel does not support pids limit capabilities". > > To make it easier to understand this test, I would suggest grouping all messages that were generated outside of HotSpot into something like: > > > // These messages are generated by Docker > static final String warning_kernel_no_pids_support = "WARNING: Your kernel does not support pids limit capabilities"; > static final String no_value_expected = "no_value_expected"; Oh, I misunderstood the test. "no_value_expected" was passed in from `testPids()` in this file, but that's confusing because you are expecting an integer value. Maybe it should be "any_integer"? ------------- PR: https://git.openjdk.java.net/jdk/pull/5437 From herrick at openjdk.java.net Tue Sep 14 17:49:14 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Tue, 14 Sep 2021 17:49:14 GMT Subject: Integrated: JDK-8273040: Turning off JpAllowDowngrades (or Upgrades) In-Reply-To: References: Message-ID: <8mYdEHXW7TwZ5WgEQDxFUEg1mbbl15WM6DHNhu-agtQ=.da9d9804-e887-4dfb-9b43-cfd737a2ae34@github.com> On Tue, 14 Sep 2021 13:38:42 GMT, Andy Herrick wrote: > JDK-8273040: Turning off JpAllowDowngrades (or Upgrades) This pull request has now been integrated. Changeset: 22a7191f Author: Andy Herrick URL: https://git.openjdk.java.net/jdk/commit/22a7191f700c6966c59dcd12476f01452243542b Stats: 17 lines in 3 files changed: 7 ins; 5 del; 5 mod 8273040: Turning off JpAllowDowngrades (or Upgrades) Reviewed-by: asemenyuk ------------- PR: https://git.openjdk.java.net/jdk/pull/5509 From asemenyuk at openjdk.java.net Tue Sep 14 17:50:27 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Tue, 14 Sep 2021 17:50:27 GMT Subject: RFR: 8272815: jpackage --type rpm produces an error: Invalid or unsupported type: [null] Message-ID: Fix jpackage error output when "--type" CLI option is missing and jpackage detects that it can't build native packages in the environment. ------------- Commit messages: - 8272815: jpackage --type rpm produces an error: Invalid or unsupported type: [null] Changes: https://git.openjdk.java.net/jdk/pull/5512/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5512&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272815 Stats: 18 lines in 2 files changed: 2 ins; 4 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/5512.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5512/head:pull/5512 PR: https://git.openjdk.java.net/jdk/pull/5512 From smarks at openjdk.java.net Tue Sep 14 18:05:12 2021 From: smarks at openjdk.java.net (Stuart Marks) Date: Tue, 14 Sep 2021 18:05:12 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v15] In-Reply-To: References: Message-ID: On Tue, 14 Sep 2021 14:02:10 GMT, Jaikiran Pai wrote: >> The commit in this PR implements the proposal for enhancement that was discussed in the core-libs-dev mailing list recently[1], for https://bugs.openjdk.java.net/browse/JDK-8231640 >> >> At a high level - the `store()` APIs in `Properties` have been modified to now look for the `SOURCE_DATE_EPOCH` environment variable[2]. If that env variable is set, then instead of writing out the current date time as a date comment, the `store()` APIs instead will use the value set for this env variable to parse it to a `Date` and write out the string form of such a date. The implementation here uses the `d MMM yyyy HH:mm:ss 'GMT'` date format and `Locale.ROOT` to format and write out such a date. This should provide reproducibility whenever the `SOURCE_DATE_EPOCH` is set. Furthermore, intentionally, no changes in the date format of the "current date" have been done. >> >> These modified `store()` APIs work in the presence of the `SecurityManager` too. The caller is expected to have a read permission on the `SOURCE_DATE_EPOCH` environment variable. If the caller doesn't have that permission, then the implementation of these `store()` APIs will write out the "current date" and will ignore any value that has been set for the `SOURCE_DATE_EPOCH` env variable. This should allow for backward compatibility of existing applications, where, when they run under a `SecurityManager` and perhaps with an existing restrictive policy file, the presence of `SOURCE_DATE_EPOCH` shouldn't impact their calls to the `store()` APIs. >> >> The modified `store()` APIs will also ignore any value for `SOURCE_DATE_EPOCH` that cannot be parsed to an `long` value. In such cases, the `store()` APIs will write out the "current date" and ignore the value set for this environment variable. No exceptions will be thrown for such invalid values. This is an additional backward compatibility precaution to prevent any rogue value for `SOURCE_DATE_EPOCH` from breaking applications. >> >> An additional change in the implementation of these `store()` APIs and unrelated to the date comment, is that these APIs will now write out the property keys in a deterministic order. The keys will be written out in the natural ordering as specified by `java.lang.String#compareTo()` API. >> >> The combination of the ordering of the property keys when written out and the usage of `SOURCE_DATE_EPOCH` environment value to determine the date comment should together allow for reproducibility of the output generated by these `store()` APIs. >> >> New jtreg test classes have been introduced to verify these changes. The primary focus of `PropertiesStoreTest` is the ordering aspects of the property keys that are written out. On the other hand `StoreReproducibilityTest` focuses on the reproducibility of the output generated by these APIs. The `StoreReproducibilityTest` runs these tests both in the presence and absence of `SecurityManager`. Plus, in the presence of SecurityManager, it tests both the scenarios where the caller is granted the requisite permission and in other case not granted that permission. >> >> These new tests and existing tests under `test/jdk/java/util/Properties/` pass with these changes. >> >> [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-August/080758.html >> [2] https://reproducible-builds.org/specs/source-date-epoch/ > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Introduce a test to make sure backslash character in the system property value doesn't cause unexpected output. > Plus minor updates to tests to add additional checks. Marked as reviewed by smarks (Reviewer). OK, after all the twists and turns, this looks good! src/java.base/share/classes/java/util/Properties.java line 173: > 171: // used to format the date comment written out by the store() APIs. > 172: // This format matches the one used by java.util.Date.toString() > 173: private static final String dateFormatPattern = "EEE MMM dd HH:mm:ss zzz yyyy"; I'd rename this something like DATE_FORMAT_PATTERN to conform to naming conventions for constants. ------------- PR: https://git.openjdk.java.net/jdk/pull/5372 From herrick at openjdk.java.net Tue Sep 14 18:09:04 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Tue, 14 Sep 2021 18:09:04 GMT Subject: RFR: 8272815: jpackage --type rpm produces an error: Invalid or unsupported type: [null] In-Reply-To: References: Message-ID: On Tue, 14 Sep 2021 17:21:29 GMT, Alexey Semenyuk wrote: > Fix jpackage error output when "--type" CLI option is missing and jpackage detects that it can't build native packages in the environment. Marked as reviewed by herrick (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5512 From sgehwolf at openjdk.java.net Tue Sep 14 18:27:10 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 14 Sep 2021 18:27:10 GMT Subject: RFR: JDK-8273526: Extend the OSContainer API pids controller with pids.current [v3] In-Reply-To: References: Message-ID: On Tue, 14 Sep 2021 17:25:05 GMT, Ioi Lam wrote: > Maybe it should be "any_integer"? +1 ------------- PR: https://git.openjdk.java.net/jdk/pull/5437 From rriggs at openjdk.java.net Tue Sep 14 18:28:04 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 14 Sep 2021 18:28:04 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v15] In-Reply-To: References: Message-ID: <3KPH5SFn4_3DyV8dmlG5JL6OAV9kTZXhyn1-v6-Q7JY=.56767af0-e971-4059-8d83-4dfa9e612f16@github.com> On Tue, 14 Sep 2021 14:02:10 GMT, Jaikiran Pai wrote: >> The commit in this PR implements the proposal for enhancement that was discussed in the core-libs-dev mailing list recently[1], for https://bugs.openjdk.java.net/browse/JDK-8231640 >> >> At a high level - the `store()` APIs in `Properties` have been modified to now look for the `SOURCE_DATE_EPOCH` environment variable[2]. If that env variable is set, then instead of writing out the current date time as a date comment, the `store()` APIs instead will use the value set for this env variable to parse it to a `Date` and write out the string form of such a date. The implementation here uses the `d MMM yyyy HH:mm:ss 'GMT'` date format and `Locale.ROOT` to format and write out such a date. This should provide reproducibility whenever the `SOURCE_DATE_EPOCH` is set. Furthermore, intentionally, no changes in the date format of the "current date" have been done. >> >> These modified `store()` APIs work in the presence of the `SecurityManager` too. The caller is expected to have a read permission on the `SOURCE_DATE_EPOCH` environment variable. If the caller doesn't have that permission, then the implementation of these `store()` APIs will write out the "current date" and will ignore any value that has been set for the `SOURCE_DATE_EPOCH` env variable. This should allow for backward compatibility of existing applications, where, when they run under a `SecurityManager` and perhaps with an existing restrictive policy file, the presence of `SOURCE_DATE_EPOCH` shouldn't impact their calls to the `store()` APIs. >> >> The modified `store()` APIs will also ignore any value for `SOURCE_DATE_EPOCH` that cannot be parsed to an `long` value. In such cases, the `store()` APIs will write out the "current date" and ignore the value set for this environment variable. No exceptions will be thrown for such invalid values. This is an additional backward compatibility precaution to prevent any rogue value for `SOURCE_DATE_EPOCH` from breaking applications. >> >> An additional change in the implementation of these `store()` APIs and unrelated to the date comment, is that these APIs will now write out the property keys in a deterministic order. The keys will be written out in the natural ordering as specified by `java.lang.String#compareTo()` API. >> >> The combination of the ordering of the property keys when written out and the usage of `SOURCE_DATE_EPOCH` environment value to determine the date comment should together allow for reproducibility of the output generated by these `store()` APIs. >> >> New jtreg test classes have been introduced to verify these changes. The primary focus of `PropertiesStoreTest` is the ordering aspects of the property keys that are written out. On the other hand `StoreReproducibilityTest` focuses on the reproducibility of the output generated by these APIs. The `StoreReproducibilityTest` runs these tests both in the presence and absence of `SecurityManager`. Plus, in the presence of SecurityManager, it tests both the scenarios where the caller is granted the requisite permission and in other case not granted that permission. >> >> These new tests and existing tests under `test/jdk/java/util/Properties/` pass with these changes. >> >> [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-August/080758.html >> [2] https://reproducible-builds.org/specs/source-date-epoch/ > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Introduce a test to make sure backslash character in the system property value doesn't cause unexpected output. > Plus minor updates to tests to add additional checks. Looks good. src/java.base/share/classes/java/util/Properties.java line 955: > 953: bw.write("#" + DateTimeFormatter.ofPattern(dateFormatPattern).format(ZonedDateTime.now())); > 954: bw.newLine(); > 955: } Since there is no longer a need to format an arbitrary date, I'd suggest going back to the original Date.toString() code. It removes the need to replicate the format using DateTimeBuilder and is known to be the same as before. If you keep the DateTimeFormat version, you would want "uuuu" instead of "yyyy". In java.time. DateTimeFormatterBuilder uses slightly different pattern letter conventions as compared to SimpleDateFormat. test/jdk/java/util/Properties/StoreReproducibilityTest.java line 429: > 427: try { > 428: parsedDate = new SimpleDateFormat(dateCommentFormat).parse(dateComment); > 429: } catch (ParseException pe) { Its slightly better to use the same date formatting and parsing APIs consistently. DateTimeFormatter.parse could be used here since DateTimeFormatter was used above. (Though the pattern uses "yyyy" instead of "uuuu" for the year.) ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5372 From rriggs at openjdk.java.net Tue Sep 14 18:56:12 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 14 Sep 2021 18:56:12 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v15] In-Reply-To: References: Message-ID: <-B-eCk3BMG0dyyc2dQfVgDmR2ruBu4OUpEWg0p_gyzY=.1eb1105e-c68f-44cc-9424-a3303e3aa081@github.com> On Tue, 14 Sep 2021 14:02:10 GMT, Jaikiran Pai wrote: >> The commit in this PR implements the proposal for enhancement that was discussed in the core-libs-dev mailing list recently[1], for https://bugs.openjdk.java.net/browse/JDK-8231640 >> >> At a high level - the `store()` APIs in `Properties` have been modified to now look for the `SOURCE_DATE_EPOCH` environment variable[2]. If that env variable is set, then instead of writing out the current date time as a date comment, the `store()` APIs instead will use the value set for this env variable to parse it to a `Date` and write out the string form of such a date. The implementation here uses the `d MMM yyyy HH:mm:ss 'GMT'` date format and `Locale.ROOT` to format and write out such a date. This should provide reproducibility whenever the `SOURCE_DATE_EPOCH` is set. Furthermore, intentionally, no changes in the date format of the "current date" have been done. >> >> These modified `store()` APIs work in the presence of the `SecurityManager` too. The caller is expected to have a read permission on the `SOURCE_DATE_EPOCH` environment variable. If the caller doesn't have that permission, then the implementation of these `store()` APIs will write out the "current date" and will ignore any value that has been set for the `SOURCE_DATE_EPOCH` env variable. This should allow for backward compatibility of existing applications, where, when they run under a `SecurityManager` and perhaps with an existing restrictive policy file, the presence of `SOURCE_DATE_EPOCH` shouldn't impact their calls to the `store()` APIs. >> >> The modified `store()` APIs will also ignore any value for `SOURCE_DATE_EPOCH` that cannot be parsed to an `long` value. In such cases, the `store()` APIs will write out the "current date" and ignore the value set for this environment variable. No exceptions will be thrown for such invalid values. This is an additional backward compatibility precaution to prevent any rogue value for `SOURCE_DATE_EPOCH` from breaking applications. >> >> An additional change in the implementation of these `store()` APIs and unrelated to the date comment, is that these APIs will now write out the property keys in a deterministic order. The keys will be written out in the natural ordering as specified by `java.lang.String#compareTo()` API. >> >> The combination of the ordering of the property keys when written out and the usage of `SOURCE_DATE_EPOCH` environment value to determine the date comment should together allow for reproducibility of the output generated by these `store()` APIs. >> >> New jtreg test classes have been introduced to verify these changes. The primary focus of `PropertiesStoreTest` is the ordering aspects of the property keys that are written out. On the other hand `StoreReproducibilityTest` focuses on the reproducibility of the output generated by these APIs. The `StoreReproducibilityTest` runs these tests both in the presence and absence of `SecurityManager`. Plus, in the presence of SecurityManager, it tests both the scenarios where the caller is granted the requisite permission and in other case not granted that permission. >> >> These new tests and existing tests under `test/jdk/java/util/Properties/` pass with these changes. >> >> [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-August/080758.html >> [2] https://reproducible-builds.org/specs/source-date-epoch/ > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Introduce a test to make sure backslash character in the system property value doesn't cause unexpected output. > Plus minor updates to tests to add additional checks. src/java.base/share/classes/java/util/Properties.java line 929: > 927: @SuppressWarnings("unchecked") > 928: var entries = new ArrayList<>(((Map) (Map) map).entrySet()); > 929: entries.sort(Map.Entry.comparingByKey()); Since Properties can be subclassed and the `entrySet()` method overridden, should the set of entries to be sorted be taken from this.entrySet() instead of bypassing the public API? ------------- PR: https://git.openjdk.java.net/jdk/pull/5372 From github.com+18482851+stefan-zobel at openjdk.java.net Tue Sep 14 19:01:29 2021 From: github.com+18482851+stefan-zobel at openjdk.java.net (stefan-zobel) Date: Tue, 14 Sep 2021 19:01:29 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v42] In-Reply-To: References: Message-ID: On Mon, 5 Apr 2021 14:20:56 GMT, Jim Laskey wrote: >> This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . >> >> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html >> >> old PR: https://github.com/openjdk/jdk/pull/1273 > > Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 78 commits: > > - Merge branch 'master' into 8248862 > - Fix NotCompliantCauseTest to not rely on Random not being a bean > - Merge branch 'master' into 8248862 > - Correct return type of RandomGeneratorFactory.of > - Merge branch 'master' into 8248862 > - CSR review revisions > - CSR review updates > - Removed @since from nextDouble ThreadLocalRandom > - RandomGeneratorFactory::all(Class category) @implNote was out of date > - Clarify all() > - ... and 68 more: https://git.openjdk.java.net/jdk/compare/a8005efd...ffd982b0 The package javadoc of java.util.random says that `mixLea32` is used as a mixing function in the L64 and L128 generators which doesn't seem to be correct. That should probably read `mixLea64` ------------- PR: https://git.openjdk.java.net/jdk/pull/1292 From jlaskey at openjdk.java.net Tue Sep 14 19:10:29 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Tue, 14 Sep 2021 19:10:29 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v42] In-Reply-To: References: Message-ID: <44FW-mHCNHd1NiM9QnJZ23NtjnGmkzLxLk7CRDuYjx8=.fc3004c8-94b6-4559-853e-56e4dc0c9326@github.com> On Tue, 14 Sep 2021 18:58:16 GMT, stefan-zobel wrote: > The package javadoc of java.util.random says that `mixLea32` is used as a mixing function in the L64 and L128 generators which doesn't seem to be correct. That should probably read `mixLea64` See https://bugs.openjdk.java.net/browse/JDK-8272866 ------------- PR: https://git.openjdk.java.net/jdk/pull/1292 From github.com+43264149+iaroslavski at openjdk.java.net Tue Sep 14 19:20:10 2021 From: github.com+43264149+iaroslavski at openjdk.java.net (iaroslavski) Date: Tue, 14 Sep 2021 19:20:10 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v2] In-Reply-To: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> Message-ID: > Sorting: > > - adopt radix sort for sequential and parallel sorts on int/long/float/double arrays (almost random and length > 6K) > - fix tryMergeRuns() to better handle case when the last run is a single element > - minor javadoc and comment changes > > Testing: > - add new data inputs in tests for sorting > - add min/max/infinity values to float/double testing > - add tests for radix sort iaroslavski has updated the pull request incrementally with one additional commit since the last revision: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) Update target version ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3938/files - new: https://git.openjdk.java.net/jdk/pull/3938/files/2d972887..189f547a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3938&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3938&range=00-01 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3938.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3938/head:pull/3938 PR: https://git.openjdk.java.net/jdk/pull/3938 From plevart at openjdk.java.net Tue Sep 14 19:28:07 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Tue, 14 Sep 2021 19:28:07 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v8] In-Reply-To: <5V0eAcrG9rS-d9RnyC2oJ5kVo6v84IhyBn40M71mYUg=.5d8c17fe-a23b-49a8-bfef-f670c0f013eb@github.com> References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> <5V0eAcrG9rS-d9RnyC2oJ5kVo6v84IhyBn40M71mYUg=.5d8c17fe-a23b-49a8-bfef-f670c0f013eb@github.com> Message-ID: On Wed, 1 Sep 2021 01:05:32 GMT, Mandy Chung wrote: >> This reimplements core reflection with method handles. >> >> For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. >> >> The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. >> >> The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. >> >> Ran tier1-tier8 tests. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8013527 >> [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > minor cleanup and more test case. Hi Mandy, So, here's the mentioned approach: https://github.com/plevart/jdk/commit/1a31508b7d73bd9fa40aae845c06b24c3cbcfd16 This is a commit above your changes that I have picked from your branch and squashed as a single commit above current master: https://github.com/plevart/jdk/commit/a2e4a1f9dad9e6951949ce82af54639ed2da9ddf I think you could chery-pick the former commit into your branch if you wanted to. What I have done is mainly removing all code around MHInvoker and VHInvoker and calling the target MethodHandle/VarHandle directly in the XxxAccessors. I also made sure that the path of references going from Method/Constructor/Field via MethodAccessor(s)/ConstructorAccessor(s)/FieldAccessor(s) and to MethodHandle/VarHandle is marked with @Stable. So if the Method/Constructor/Field is found to be constant by JIT, so is its associated MethodHandle/VarHandle. I also "fixed" existing MethodAccessor(s)/ConstructorAccessor(s)/FieldAccessor(s) so that they are safe to be "published" via data-race as the fields holding them in Method/Constructor are no longer volatile (in Field they never have been volatile). In Field I had to make two distinct call-sites for fieldAccessor vs. overrideFieldAccessor in order for JIT to propagate @Stable-ness down the chain. I then ran the following JMH benchmarks (not included in my variant of patch yet) on jdk16, mandy's variant and peter's variant: https://gist.github.com/plevart/b9c62c8cac9784e2c6d5f51a6386fa84 The results can be visualized via the following links: jdk16 vs. mandy: https://jmh.morethan.io/?gists=9219d79a09a805eb39607830270d1513,80203847700b9ab8baeb346a02efc804 jdk16 vs. peter: https://jmh.morethan.io/?gists=9219d79a09a805eb39607830270d1513,b11842fbd48ebbd9234251fded50d52e mandy vs. peter: https://jmh.morethan.io/?gists=80203847700b9ab8baeb346a02efc804,b11842fbd48ebbd9234251fded50d52e Comparing mandy vs. peter, there are pros and cons. If Method/Field instance is found to be constant by JIT, peter's variant is a little better (16...36%). It Method/Field is not constant as found by JIT, but still a single instance of Method/Field is invoked in a particular call-site, peter's variant is worse (22...48%). I added another variant called "Poly" (for static methods/fields only, but I think results would be similar for instance too). In this variant a single call-site operates with distinct instances of Method/Field and peter's variant is a little better there (3...11%). The cold-start is a little better for peter's variant too (5%). I think the "Poly" variants are an important representative of real-world usage. Every usage happens in the real world (Const, Var, Poly), but most applications/frameworks that use reflection and where performance matters (such as JPA, various serialization frameworks, etc.) are generic algorithm(s) that abstract over various runtime types, accessing methods/fields/constructors via call-sites that deal with multiple instances of Mehod/Field/Constructor each. Top speed is possible with peter's variant and even better than with mandys's variant when each call-site is dealing with single instance of Mehod/Field/Constructor but user has to make such instance a constant for JIT (by accessing it from static final or @Stable field) I don't know how realistic for real world the "Var" class of invocations is where mandy's variant performs equivalently to "Const" class. Are there real world apps where call-sites deal with single instances of Mehod/Field/Constructor but such instances are not constant for JIT? Comparing jdk16 vs. peter's variant we see peter's variant performs better in "Const" class (11...67%) and worse for "Var" class (11...46%). For "Poly" variant jdk16 is still better (44%) when accessing fields (nothing can beat Unsafe) but when accessing methods peter's variant is just 3% short of jdk16. So what do you think? Does increased speed of "Var" class of usages (single Mehod/Field/Constructor instance per call-site but not constant) outweight complexity and total work added by MHInvoker/VHInvoker code generation and class loading? ------------- PR: https://git.openjdk.java.net/jdk/pull/5027 From plevart at openjdk.java.net Tue Sep 14 19:37:08 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Tue, 14 Sep 2021 19:37:08 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v8] In-Reply-To: <5V0eAcrG9rS-d9RnyC2oJ5kVo6v84IhyBn40M71mYUg=.5d8c17fe-a23b-49a8-bfef-f670c0f013eb@github.com> References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> <5V0eAcrG9rS-d9RnyC2oJ5kVo6v84IhyBn40M71mYUg=.5d8c17fe-a23b-49a8-bfef-f670c0f013eb@github.com> Message-ID: On Wed, 1 Sep 2021 01:05:32 GMT, Mandy Chung wrote: >> This reimplements core reflection with method handles. >> >> For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. >> >> The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. >> >> The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. >> >> Ran tier1-tier8 tests. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8013527 >> [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > minor cleanup and more test case. Just another question: Is migrating from Unsafe based FieldAccessor(s) to VarHandle based an important step to final goal of Unsafe elimination because I don't think it is a necessary step for Loom. ------------- PR: https://git.openjdk.java.net/jdk/pull/5027 From plevart at openjdk.java.net Tue Sep 14 20:09:22 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Tue, 14 Sep 2021 20:09:22 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v8] In-Reply-To: <5V0eAcrG9rS-d9RnyC2oJ5kVo6v84IhyBn40M71mYUg=.5d8c17fe-a23b-49a8-bfef-f670c0f013eb@github.com> References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> <5V0eAcrG9rS-d9RnyC2oJ5kVo6v84IhyBn40M71mYUg=.5d8c17fe-a23b-49a8-bfef-f670c0f013eb@github.com> Message-ID: On Wed, 1 Sep 2021 01:05:32 GMT, Mandy Chung wrote: >> This reimplements core reflection with method handles. >> >> For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. >> >> The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. >> >> The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. >> >> Ran tier1-tier8 tests. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8013527 >> [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > minor cleanup and more test case. Ah, I found some late copy-paste mistakes. Here's the commit (on top of peter's variant commit mentioned above): https://github.com/plevart/jdk/commit/791a9a69967674836fcfc41746dc731396f3bb3e ------------- PR: https://git.openjdk.java.net/jdk/pull/5027 From mchung at openjdk.java.net Tue Sep 14 20:21:01 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 14 Sep 2021 20:21:01 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v8] In-Reply-To: References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> <5V0eAcrG9rS-d9RnyC2oJ5kVo6v84IhyBn40M71mYUg=.5d8c17fe-a23b-49a8-bfef-f670c0f013eb@github.com> Message-ID: On Tue, 14 Sep 2021 19:33:38 GMT, Peter Levart wrote: > Just another question: Is migrating from Unsafe based FieldAccessor(s) to VarHandle based an important step to final goal of Unsafe elimination because I don't think it is a necessary step for Loom. No. We could continue to use Unsafe but moving to VarHandle reduces the development cost when extending core reflection for a new feature for example for Project Valhalla, which is one of the goals. ------------- PR: https://git.openjdk.java.net/jdk/pull/5027 From mchung at openjdk.java.net Tue Sep 14 20:21:22 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 14 Sep 2021 20:21:22 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v8] In-Reply-To: <5V0eAcrG9rS-d9RnyC2oJ5kVo6v84IhyBn40M71mYUg=.5d8c17fe-a23b-49a8-bfef-f670c0f013eb@github.com> References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> <5V0eAcrG9rS-d9RnyC2oJ5kVo6v84IhyBn40M71mYUg=.5d8c17fe-a23b-49a8-bfef-f670c0f013eb@github.com> Message-ID: On Wed, 1 Sep 2021 01:05:32 GMT, Mandy Chung wrote: >> This reimplements core reflection with method handles. >> >> For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. >> >> The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. >> >> The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. >> >> Ran tier1-tier8 tests. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8013527 >> [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > minor cleanup and more test case. For the performance comparison, the current baseline for this PR is jdk-18+9 that will better reflect the performance gain/regression. ------------- PR: https://git.openjdk.java.net/jdk/pull/5027 From mchung at openjdk.java.net Tue Sep 14 20:35:49 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 14 Sep 2021 20:35:49 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v8] In-Reply-To: <5V0eAcrG9rS-d9RnyC2oJ5kVo6v84IhyBn40M71mYUg=.5d8c17fe-a23b-49a8-bfef-f670c0f013eb@github.com> References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> <5V0eAcrG9rS-d9RnyC2oJ5kVo6v84IhyBn40M71mYUg=.5d8c17fe-a23b-49a8-bfef-f670c0f013eb@github.com> Message-ID: On Wed, 1 Sep 2021 01:05:32 GMT, Mandy Chung wrote: >> This reimplements core reflection with method handles. >> >> For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. >> >> The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. >> >> The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. >> >> Ran tier1-tier8 tests. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8013527 >> [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > minor cleanup and more test case. > Ah, I found some late copy-paste mistakes. Here's the commit (on top of peter's variant commit mentioned above): > [plevart at 791a9a6](https://github.com/plevart/jdk/commit/791a9a69967674836fcfc41746dc731396f3bb3e) Thanks for catching it. Will fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/5027 From dfuchs at openjdk.java.net Tue Sep 14 20:43:40 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 14 Sep 2021 20:43:40 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v15] In-Reply-To: <-B-eCk3BMG0dyyc2dQfVgDmR2ruBu4OUpEWg0p_gyzY=.1eb1105e-c68f-44cc-9424-a3303e3aa081@github.com> References: <-B-eCk3BMG0dyyc2dQfVgDmR2ruBu4OUpEWg0p_gyzY=.1eb1105e-c68f-44cc-9424-a3303e3aa081@github.com> Message-ID: On Tue, 14 Sep 2021 18:53:27 GMT, Roger Riggs wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> Introduce a test to make sure backslash character in the system property value doesn't cause unexpected output. >> Plus minor updates to tests to add additional checks. > > src/java.base/share/classes/java/util/Properties.java line 929: > >> 927: @SuppressWarnings("unchecked") >> 928: var entries = new ArrayList<>(((Map) (Map) map).entrySet()); >> 929: entries.sort(Map.Entry.comparingByKey()); > > Since Properties can be subclassed and the `entrySet()` method overridden, should the set of entries to be sorted be taken from this.entrySet() instead of bypassing the public API? Hmm, so if someone has subclassed `Properties` and overridden `entrySet` for the purpose of ordering entries, that trick will no longer work with the new code. I wonder - should we sort entries only when the `java.util.Properties.storeDate` is also defined and not empty? Or should we simply state in the release notes that such tricks will no longer work? ------------- PR: https://git.openjdk.java.net/jdk/pull/5372 From rriggs at openjdk.java.net Tue Sep 14 21:11:54 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 14 Sep 2021 21:11:54 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v15] In-Reply-To: References: <-B-eCk3BMG0dyyc2dQfVgDmR2ruBu4OUpEWg0p_gyzY=.1eb1105e-c68f-44cc-9424-a3303e3aa081@github.com> Message-ID: On Tue, 14 Sep 2021 20:34:21 GMT, Daniel Fuchs wrote: >> src/java.base/share/classes/java/util/Properties.java line 929: >> >>> 927: @SuppressWarnings("unchecked") >>> 928: var entries = new ArrayList<>(((Map) (Map) map).entrySet()); >>> 929: entries.sort(Map.Entry.comparingByKey()); >> >> Since Properties can be subclassed and the `entrySet()` method overridden, should the set of entries to be sorted be taken from this.entrySet() instead of bypassing the public API? > > Hmm, so if someone has subclassed `Properties` and overridden `entrySet` for the purpose of ordering entries, that trick will no longer work with the new code. I wonder - should we sort entries only when the `java.util.Properties.storeDate` is also defined and not empty? Or should we simply state in the release notes that such tricks will no longer work? I think we want the entries to be sorted by default; that is the most useful to the most people. Checking for the overloaded method seems like trying too hard. Changing the entrySet to return them sorted (always) would add overhead in a lot of cases but would allow a subclass to re-sort them as they see fit. A half measure would be to sort only if the properties instance was not subclassed and spec it that way as an implementation detail. ------------- PR: https://git.openjdk.java.net/jdk/pull/5372 From asemenyuk at openjdk.java.net Tue Sep 14 21:47:36 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Tue, 14 Sep 2021 21:47:36 GMT Subject: RFR: 8272815: jpackage --type rpm produces an error: Invalid or unsupported type: [null] [v2] In-Reply-To: References: Message-ID: > Fix jpackage error output when "--type" CLI option is missing and jpackage detects that it can't build native packages in the environment. Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: dummy commit ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5512/files - new: https://git.openjdk.java.net/jdk/pull/5512/files/caac338f..44cf9fde Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5512&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5512&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5512.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5512/head:pull/5512 PR: https://git.openjdk.java.net/jdk/pull/5512 From plevart at openjdk.java.net Tue Sep 14 22:07:03 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Tue, 14 Sep 2021 22:07:03 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v8] In-Reply-To: <5V0eAcrG9rS-d9RnyC2oJ5kVo6v84IhyBn40M71mYUg=.5d8c17fe-a23b-49a8-bfef-f670c0f013eb@github.com> References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> <5V0eAcrG9rS-d9RnyC2oJ5kVo6v84IhyBn40M71mYUg=.5d8c17fe-a23b-49a8-bfef-f670c0f013eb@github.com> Message-ID: <1xThCdbGBqHfeq-RP2AHQQvCa2kpQwnEL6vwDqrw178=.44c7f8e7-a13c-4ddb-a21e-bd7807470164@github.com> On Wed, 1 Sep 2021 01:05:32 GMT, Mandy Chung wrote: >> This reimplements core reflection with method handles. >> >> For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. >> >> The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. >> >> The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. >> >> Ran tier1-tier8 tests. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8013527 >> [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > minor cleanup and more test case. Ok, here are comparisons with jdk18+9: jdk18+9 vs. mandy: https://jmh.morethan.io/?gists=7b2399cea71d12dfd3434701ddeed026,80203847700b9ab8baeb346a02efc804 jdk18+9 vs. peter: https://jmh.morethan.io/?gists=7b2399cea71d12dfd3434701ddeed026,b11842fbd48ebbd9234251fded50d52e mandy vs. peter: https://jmh.morethan.io/?gists=80203847700b9ab8baeb346a02efc804,b11842fbd48ebbd9234251fded50d52e jdk16 vs. jdk18+9: https://jmh.morethan.io/?gists=9219d79a09a805eb39607830270d1513,7b2399cea71d12dfd3434701ddeed026 As can be seen from the jdk16 vs. jdk18+9, jdk18+9 has improved mainly on `staticMethodConst`, but peter's variant still beats it by large margin. ------------- PR: https://git.openjdk.java.net/jdk/pull/5027 From almatvee at openjdk.java.net Tue Sep 14 23:02:50 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Tue, 14 Sep 2021 23:02:50 GMT Subject: RFR: 8272815: jpackage --type rpm produces an error: Invalid or unsupported type: [null] [v2] In-Reply-To: References: Message-ID: On Tue, 14 Sep 2021 21:47:36 GMT, Alexey Semenyuk wrote: >> Fix jpackage error output when "--type" CLI option is missing and jpackage detects that it can't build native packages in the environment. > > Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: > > dummy commit Marked as reviewed by almatvee (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5512 From mchung at openjdk.java.net Wed Sep 15 01:04:55 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 15 Sep 2021 01:04:55 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v8] In-Reply-To: <5V0eAcrG9rS-d9RnyC2oJ5kVo6v84IhyBn40M71mYUg=.5d8c17fe-a23b-49a8-bfef-f670c0f013eb@github.com> References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> <5V0eAcrG9rS-d9RnyC2oJ5kVo6v84IhyBn40M71mYUg=.5d8c17fe-a23b-49a8-bfef-f670c0f013eb@github.com> Message-ID: On Wed, 1 Sep 2021 01:05:32 GMT, Mandy Chung wrote: >> This reimplements core reflection with method handles. >> >> For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. >> >> The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. >> >> The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. >> >> Ran tier1-tier8 tests. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8013527 >> [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > minor cleanup and more test case. Hi Peter, thanks for the patch and performance measurement. Yesterday I did a quick hack and observed similar result. I'm excited to see the performance improvement in the `Const` cases without the need of spinning the hidden class and it's a simplification. On the other hand, I'm concerned of the regression of the `Var` case for field access (80%) whereas the regression of the `Var` case for method may be tolerable (9-10%) [1]. We don't have a representative benchmark for core reflection that represents the performance charactistics of real-world applications/frameworks. I can't make a conclusion whether regression of `Var` cases matter in real-world applications/frameworks until customers run their benchmarks. We have to take the conservative side to ensure no significant regression based on micro-benchmarks result. I'm afraid it's not a good state to accept. Claes is on vacation and we should get his opinion. I tried one suggestion from Vladimir Ivanov to ensure `MethodHandle::customize` on top of your patch. But it does not seem to help. In any case, the patch to make `methodAccessor` and `fieldAccessor` not volatile is a good improvement by itself (not to be a volatile field). I would suggest to fix that separately from JEP 416. For JEP 416, two possible options: 1. Keep it as is and no significant performance regression. Continue to work on the performance improvement to remove the need of spinning class. 2. Disable the spinning hidden class and have a flag to enable it so that customers can workaround if having performance issue. However, performance regression on field access is not desirable. So I would prefer option 1 and continue work on the performance improvement as follow-up work. What do you think? [1] https://jmh.morethan.io/?gists=7b2399cea71d12dfd3434701ddeed026,b11842fbd48ebbd9234251fded50d52e ------------- PR: https://git.openjdk.java.net/jdk/pull/5027 From dholmes at openjdk.java.net Wed Sep 15 01:36:50 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 15 Sep 2021 01:36:50 GMT Subject: RFR: 8273494: Zero: Put libjvm.so into "zero" folder, not "server" In-Reply-To: References: Message-ID: On Tue, 14 Sep 2021 15:49:36 GMT, Aleksey Shipilev wrote: >> It isn't the "formal governance" I'm concerned about, more about the folk who use/rely on Zero being the ones to evaluate the impact of a change like this. People, like myself, who do not use Zero in any way cannot evaluate whether this change is appropriate - it's that simple. :) > > I'll be happy to integrate as long as @dholmes-ora has no objections. @shipilev no objections from me. I will leave it to the Zero developers to worry, or not, about the Zero users. Cheers, David ------------- PR: https://git.openjdk.java.net/jdk/pull/5440 From github.com+53162078+shiyuexw at openjdk.java.net Wed Sep 15 01:48:46 2021 From: github.com+53162078+shiyuexw at openjdk.java.net (wxiang) Date: Wed, 15 Sep 2021 01:48:46 GMT Subject: RFR: 8273401: Remove JarIndex support in URLClassPath [v2] In-Reply-To: References: Message-ID: <9FAk9cObH2-NC5fgf7gAE0o4PEhCmja13cwcL0lCrTg=.78759581-f42f-4ed4-a4a3-581ff84451af@github.com> On Wed, 8 Sep 2021 06:30:34 GMT, wxiang wrote: >> wxiang has updated the pull request incrementally with one additional commit since the last revision: >> >> Some minor changes >> >> Include: >> 1. remove public for INDEX_NAME in JarFile >> 2. recover the definition for INDEX_NAME in JarIndex >> 3. mv the test case JarIndexMergeTest.java into test/jdk/java/util/jar > > Create CSR: https://bugs.openjdk.java.net/browse/JDK-8273473 > @shiyuexw I discussed this issue with other maintainers in this area. There was agreement on dropping the support from the URLClassLoader implementation but it was suggested that it should be disabled for a release or two before the code is removed. A system property can be used to re-enable. I've updated the CSR to reflect this proposal. Are you okay to continue with this new proposal? It would mean that we wouldn't remove the tests but instead change them to run with the system property. Yes, I will take care of it. Need I create a new PR? ------------- PR: https://git.openjdk.java.net/jdk/pull/5383 From github.com+592810+efge at openjdk.java.net Wed Sep 15 01:57:47 2021 From: github.com+592810+efge at openjdk.java.net (Florent Guillaume) Date: Wed, 15 Sep 2021 01:57:47 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server In-Reply-To: References: Message-ID: On Tue, 14 Sep 2021 15:56:53 GMT, Julia Boes wrote: >> I think you can ignore my comment above. I went and checked the `content-types.properties` in their current state for both unix and windows and they already have a separate `application/zip` which is mapped to `.zip`. So I think this above change shouldn't impact anything. > > That's right, there was a duplicate entry for `.zip` in the Windows properties file only, which I removed. > > I'm not sure if `.z` in the Unix properties file is intentional, but I do have a PR in progress in the same area, which I will link here shortly. FWIW `.z` is the extension of the old Unix `compress` program. ------------- PR: https://git.openjdk.java.net/jdk/pull/5505 From jpai at openjdk.java.net Wed Sep 15 03:16:50 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Wed, 15 Sep 2021 03:16:50 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server In-Reply-To: References: Message-ID: On Wed, 15 Sep 2021 01:54:40 GMT, Florent Guillaume wrote: > FWIW `.z` is the extension of the old Unix `compress` program. Thank you Florent, I wasn't aware of that. ------------- PR: https://git.openjdk.java.net/jdk/pull/5505 From jpai at openjdk.java.net Wed Sep 15 05:48:19 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Wed, 15 Sep 2021 05:48:19 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v16] In-Reply-To: References: Message-ID: > The commit in this PR implements the proposal for enhancement that was discussed in the core-libs-dev mailing list recently[1], for https://bugs.openjdk.java.net/browse/JDK-8231640 > > At a high level - the `store()` APIs in `Properties` have been modified to now look for the `SOURCE_DATE_EPOCH` environment variable[2]. If that env variable is set, then instead of writing out the current date time as a date comment, the `store()` APIs instead will use the value set for this env variable to parse it to a `Date` and write out the string form of such a date. The implementation here uses the `d MMM yyyy HH:mm:ss 'GMT'` date format and `Locale.ROOT` to format and write out such a date. This should provide reproducibility whenever the `SOURCE_DATE_EPOCH` is set. Furthermore, intentionally, no changes in the date format of the "current date" have been done. > > These modified `store()` APIs work in the presence of the `SecurityManager` too. The caller is expected to have a read permission on the `SOURCE_DATE_EPOCH` environment variable. If the caller doesn't have that permission, then the implementation of these `store()` APIs will write out the "current date" and will ignore any value that has been set for the `SOURCE_DATE_EPOCH` env variable. This should allow for backward compatibility of existing applications, where, when they run under a `SecurityManager` and perhaps with an existing restrictive policy file, the presence of `SOURCE_DATE_EPOCH` shouldn't impact their calls to the `store()` APIs. > > The modified `store()` APIs will also ignore any value for `SOURCE_DATE_EPOCH` that cannot be parsed to an `long` value. In such cases, the `store()` APIs will write out the "current date" and ignore the value set for this environment variable. No exceptions will be thrown for such invalid values. This is an additional backward compatibility precaution to prevent any rogue value for `SOURCE_DATE_EPOCH` from breaking applications. > > An additional change in the implementation of these `store()` APIs and unrelated to the date comment, is that these APIs will now write out the property keys in a deterministic order. The keys will be written out in the natural ordering as specified by `java.lang.String#compareTo()` API. > > The combination of the ordering of the property keys when written out and the usage of `SOURCE_DATE_EPOCH` environment value to determine the date comment should together allow for reproducibility of the output generated by these `store()` APIs. > > New jtreg test classes have been introduced to verify these changes. The primary focus of `PropertiesStoreTest` is the ordering aspects of the property keys that are written out. On the other hand `StoreReproducibilityTest` focuses on the reproducibility of the output generated by these APIs. The `StoreReproducibilityTest` runs these tests both in the presence and absence of `SecurityManager`. Plus, in the presence of SecurityManager, it tests both the scenarios where the caller is granted the requisite permission and in other case not granted that permission. > > These new tests and existing tests under `test/jdk/java/util/Properties/` pass with these changes. > > [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-August/080758.html > [2] https://reproducible-builds.org/specs/source-date-epoch/ Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: Address review suggestions: - Switch back to using Date.toString() for writing out the date comment - Update the javadoc to match this change - Update the tests to consistently use DateTimeFormatter while parsing dates ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5372/files - new: https://git.openjdk.java.net/jdk/pull/5372/files/6f5f1be2..7098a2c5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5372&range=15 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5372&range=14-15 Stats: 22 lines in 3 files changed: 2 ins; 8 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/5372.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5372/head:pull/5372 PR: https://git.openjdk.java.net/jdk/pull/5372 From jpai at openjdk.java.net Wed Sep 15 05:56:48 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Wed, 15 Sep 2021 05:56:48 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v15] In-Reply-To: <3KPH5SFn4_3DyV8dmlG5JL6OAV9kTZXhyn1-v6-Q7JY=.56767af0-e971-4059-8d83-4dfa9e612f16@github.com> References: <3KPH5SFn4_3DyV8dmlG5JL6OAV9kTZXhyn1-v6-Q7JY=.56767af0-e971-4059-8d83-4dfa9e612f16@github.com> Message-ID: On Tue, 14 Sep 2021 18:11:00 GMT, Roger Riggs wrote: > Since there is no longer a need to format an arbitrary date, I'd suggest going back to the original Date.toString() code. It removes the need to replicate the format using DateTimeBuilder and is known to be the same as before. Done. I pushed an update to the PR which switches back to using Date.toString() for the date comment. It also does a minor adjustment to the javadoc to clarify this behaviour. > test/jdk/java/util/Properties/StoreReproducibilityTest.java line 429: > >> 427: try { >> 428: parsedDate = new SimpleDateFormat(dateCommentFormat).parse(dateComment); >> 429: } catch (ParseException pe) { > > Its slightly better to use the same date formatting and parsing APIs consistently. > DateTimeFormatter.parse could be used here since DateTimeFormatter was used above. > (Though the pattern uses "yyyy" instead of "uuuu" for the year.) Done. I've updated the tests to use a consistent API for parsing these date comments in the stored files. They now use the DateTimeFormatter APIs along with the right pattern ("uuuu") to match the output of Date.toString(). ------------- PR: https://git.openjdk.java.net/jdk/pull/5372 From alanb at openjdk.java.net Wed Sep 15 06:01:50 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 15 Sep 2021 06:01:50 GMT Subject: RFR: 8273401: Remove JarIndex support in URLClassPath [v2] In-Reply-To: <9FAk9cObH2-NC5fgf7gAE0o4PEhCmja13cwcL0lCrTg=.78759581-f42f-4ed4-a4a3-581ff84451af@github.com> References: <9FAk9cObH2-NC5fgf7gAE0o4PEhCmja13cwcL0lCrTg=.78759581-f42f-4ed4-a4a3-581ff84451af@github.com> Message-ID: On Wed, 15 Sep 2021 01:45:49 GMT, wxiang wrote: > Yes, I will take care of it. Need I create a new PR? Up to you, it's okay to continue with this one if you want, we would just need to change the description here and in JBS. ------------- PR: https://git.openjdk.java.net/jdk/pull/5383 From jpai at openjdk.java.net Wed Sep 15 06:11:23 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Wed, 15 Sep 2021 06:11:23 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v17] In-Reply-To: References: Message-ID: > The commit in this PR implements the proposal for enhancement that was discussed in the core-libs-dev mailing list recently[1], for https://bugs.openjdk.java.net/browse/JDK-8231640 > > At a high level - the `store()` APIs in `Properties` have been modified to now look for the `SOURCE_DATE_EPOCH` environment variable[2]. If that env variable is set, then instead of writing out the current date time as a date comment, the `store()` APIs instead will use the value set for this env variable to parse it to a `Date` and write out the string form of such a date. The implementation here uses the `d MMM yyyy HH:mm:ss 'GMT'` date format and `Locale.ROOT` to format and write out such a date. This should provide reproducibility whenever the `SOURCE_DATE_EPOCH` is set. Furthermore, intentionally, no changes in the date format of the "current date" have been done. > > These modified `store()` APIs work in the presence of the `SecurityManager` too. The caller is expected to have a read permission on the `SOURCE_DATE_EPOCH` environment variable. If the caller doesn't have that permission, then the implementation of these `store()` APIs will write out the "current date" and will ignore any value that has been set for the `SOURCE_DATE_EPOCH` env variable. This should allow for backward compatibility of existing applications, where, when they run under a `SecurityManager` and perhaps with an existing restrictive policy file, the presence of `SOURCE_DATE_EPOCH` shouldn't impact their calls to the `store()` APIs. > > The modified `store()` APIs will also ignore any value for `SOURCE_DATE_EPOCH` that cannot be parsed to an `long` value. In such cases, the `store()` APIs will write out the "current date" and ignore the value set for this environment variable. No exceptions will be thrown for such invalid values. This is an additional backward compatibility precaution to prevent any rogue value for `SOURCE_DATE_EPOCH` from breaking applications. > > An additional change in the implementation of these `store()` APIs and unrelated to the date comment, is that these APIs will now write out the property keys in a deterministic order. The keys will be written out in the natural ordering as specified by `java.lang.String#compareTo()` API. > > The combination of the ordering of the property keys when written out and the usage of `SOURCE_DATE_EPOCH` environment value to determine the date comment should together allow for reproducibility of the output generated by these `store()` APIs. > > New jtreg test classes have been introduced to verify these changes. The primary focus of `PropertiesStoreTest` is the ordering aspects of the property keys that are written out. On the other hand `StoreReproducibilityTest` focuses on the reproducibility of the output generated by these APIs. The `StoreReproducibilityTest` runs these tests both in the presence and absence of `SecurityManager`. Plus, in the presence of SecurityManager, it tests both the scenarios where the caller is granted the requisite permission and in other case not granted that permission. > > These new tests and existing tests under `test/jdk/java/util/Properties/` pass with these changes. > > [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-August/080758.html > [2] https://reproducible-builds.org/specs/source-date-epoch/ Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: - Clarify how overriden Properties#entrySet() method impacts the order of stored properties - Tests to verify subclasses of Properties ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5372/files - new: https://git.openjdk.java.net/jdk/pull/5372/files/7098a2c5..79d10527 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5372&range=16 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5372&range=15-16 Stats: 81 lines in 2 files changed: 65 ins; 1 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/5372.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5372/head:pull/5372 PR: https://git.openjdk.java.net/jdk/pull/5372 From jpai at openjdk.java.net Wed Sep 15 06:14:51 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Wed, 15 Sep 2021 06:14:51 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v15] In-Reply-To: References: <-B-eCk3BMG0dyyc2dQfVgDmR2ruBu4OUpEWg0p_gyzY=.1eb1105e-c68f-44cc-9424-a3303e3aa081@github.com> Message-ID: On Tue, 14 Sep 2021 21:09:34 GMT, Roger Riggs wrote: >> Hmm, so if someone has subclassed `Properties` and overridden `entrySet` for the purpose of ordering entries, that trick will no longer work with the new code. I wonder - should we sort entries only when the `java.util.Properties.storeDate` is also defined and not empty? Or should we simply state in the release notes that such tricks will no longer work? > > I think we want the entries to be sorted by default; that is the most useful to the most people. > Checking for the overloaded method seems like trying too hard. > Changing the entrySet to return them sorted (always) would add overhead in a lot of cases but would allow a subclass to re-sort them as they see fit. > A half measure would be to sort only if the properties instance was not subclassed and spec it that way as an implementation detail. Good catch regarding the possibility of entrySet() being overridden. > I think we want the entries to be sorted by default; that is the most useful to the most people. Agreed > Changing the entrySet to return them sorted (always) would add overhead in a lot of cases but would allow a subclass to re-sort them as they see fit. Agreed - I think changing the implementation of entrySet to return an ordered set is an unnecessary overhead in the context of what's being targeted in this PR. > A half measure would be to sort only if the properties instance was not subclassed and spec it that way as an implementation detail. I think just checking the properties instance type to see if it is subclassed is perhaps too big a penalty for those applications that do subclass java.util.Properties but don't override the entrySet() method. Such applications/subclasses will then never be able to use this new implementation where we write out the properties in the natural order. Perhaps a middle ground would be your other option: > Checking for the overloaded method seems like trying too hard. IMO, I don't think we would be trying too hard to identify this. I have updated this PR to try and articulate this both in terms of the implementation as well as the updated javadoc of this method. Tests have then been introduced to verify this case of Properties subclasses. This https://github.com/openjdk/jdk/pull/5372/commits/79d1052775dd8e98fb7078710eda0fd6dd83b164 is the relevant commit in the updated PR. I understand that we haven't come to an agreement on this aspect yet, but it was easier to show it in terms of code and spec, so I decided to include this commit in the PR. I will of course revert it or change it appropriately depending on how we want to deal with this case. ------------- PR: https://git.openjdk.java.net/jdk/pull/5372 From github.com+741251+turbanoff at openjdk.java.net Wed Sep 15 07:08:09 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Wed, 15 Sep 2021 07:08:09 GMT Subject: RFR: 8273711: Remove redundant stream() call before forEach in jdk.jlink [v2] In-Reply-To: <3ABdvBiCu8znAgbmq2XW3wsWVEPqwIGbPJnmEdW-1jc=.2148d9d8-f14f-49ad-a58f-6f843bba27d3@github.com> References: <3ABdvBiCu8znAgbmq2XW3wsWVEPqwIGbPJnmEdW-1jc=.2148d9d8-f14f-49ad-a58f-6f843bba27d3@github.com> Message-ID: > 8273711: Remove redundant stream() call before forEach in jdk.jlink Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8273711: Remove redundant stream() call before forEach in jdk.jlink use method references where applicable ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5500/files - new: https://git.openjdk.java.net/jdk/pull/5500/files/153a9ea1..c071426b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5500&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5500&range=00-01 Stats: 6 lines in 2 files changed: 0 ins; 3 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5500.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5500/head:pull/5500 PR: https://git.openjdk.java.net/jdk/pull/5500 From mbaesken at openjdk.java.net Wed Sep 15 07:12:45 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Wed, 15 Sep 2021 07:12:45 GMT Subject: RFR: JDK-8273526: Extend the OSContainer API pids controller with pids.current [v3] In-Reply-To: References: Message-ID: On Tue, 14 Sep 2021 18:23:49 GMT, Severin Gehwolf wrote: >> Oh, I misunderstood the test. "no_value_expected" was passed in from `testPids()` in this file, but that's confusing because you are expecting an integer value. Maybe it should be "any_integer"? > >> Maybe it should be "any_integer"? > > +1 > Is "no_value_expected" generated by Docker? I searched the entire HotSpot source code and couldn't find it. I also couldn't find "WARNING: Your kernel does not support pids limit capabilities". > Hi, this warning is showing up on some of our Linux ppc64le machines where the pids limit capabilities is not supported. Best regards, Matthias ------------- PR: https://git.openjdk.java.net/jdk/pull/5437 From mbaesken at openjdk.java.net Wed Sep 15 07:46:34 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Wed, 15 Sep 2021 07:46:34 GMT Subject: RFR: JDK-8273526: Extend the OSContainer API pids controller with pids.current [v4] In-Reply-To: References: Message-ID: > https://bugs.openjdk.java.net/browse/JDK-8266490 > extended the OSContainer API in order to also support the pids controller of cgroups. However only pids.max output was added with 8266490. > There is a second parameter pids.current , see https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#pid > that would be helpful too and can be added to the OSContainer API . > pids.current : > A read-only single value file which exists on all cgroups. > The number of processes currently in the cgroup and its descendants. > > Best regards, Matthias Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Adjust TestPids ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5437/files - new: https://git.openjdk.java.net/jdk/pull/5437/files/afe0efd4..86f3f534 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5437&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5437&range=02-03 Stats: 7 lines in 1 file changed: 3 ins; 1 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5437.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5437/head:pull/5437 PR: https://git.openjdk.java.net/jdk/pull/5437 From rreddy at openjdk.java.net Wed Sep 15 07:52:09 2021 From: rreddy at openjdk.java.net (Ravi Reddy) Date: Wed, 15 Sep 2021 07:52:09 GMT Subject: RFR: 8193682: Infinite loop in ZipOutputStream.close() Message-ID: Hi all, Please review this fix for Infinite loop in ZipOutputStream.close(). The main issue here is when ever there is an exception during close operations on GZip we are not setting the deflator to a finished state which is leading to an infinite loop when we try writing on the same GZip instance( since we use while(!def.finished()) inside the write operation). Thanks, Ravi ------------- Commit messages: - 8193682: Infinite loop in ZipOutputStream.close() Changes: https://git.openjdk.java.net/jdk/pull/5522/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5522&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8193682 Stats: 92 lines in 2 files changed: 87 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/5522.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5522/head:pull/5522 PR: https://git.openjdk.java.net/jdk/pull/5522 From rreddy at openjdk.java.net Wed Sep 15 07:52:09 2021 From: rreddy at openjdk.java.net (Ravi Reddy) Date: Wed, 15 Sep 2021 07:52:09 GMT Subject: RFR: 8193682: Infinite loop in ZipOutputStream.close() In-Reply-To: References: Message-ID: On Wed, 15 Sep 2021 07:40:35 GMT, Ravi Reddy wrote: > Hi all, > > Please review this fix for Infinite loop in ZipOutputStream.close(). > The main issue here is when ever there is an exception during close operations on GZip we are not setting the deflator to a finished state which is leading to an infinite loop when we try writing on the same GZip instance( since we use while(!def.finished()) inside the write operation). > > Thanks, > Ravi Reviewers: @LanceAndersen @coffeys ------------- PR: https://git.openjdk.java.net/jdk/pull/5522 From michaelm at openjdk.java.net Wed Sep 15 07:52:49 2021 From: michaelm at openjdk.java.net (Michael McMahon) Date: Wed, 15 Sep 2021 07:52:49 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server In-Reply-To: References: Message-ID: On Tue, 14 Sep 2021 16:51:40 GMT, Daniel Fuchs wrote: >> src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpHandlers.java line 129: >> >>> 127: * response body bytes are a {@code UTF-8} encoded byte sequence of >>> 128: * {@code body}. The response {@linkplain HttpExchange#sendResponseHeaders(int, long) is sent} >>> 129: * with the given {@code statusCode} and the body bytes' length. The body >> >> That might give the impression that chunked encoding will be used if the body length is 0. I wonder if it should say instead: >> >> >> with the given {@code statusCode} and a {@code Content-Length} field set to the body bytes' length. > > Or maybe - which would be more accurate: > > > with the given {@code statusCode} and the body bytes' length (or {@code -1} if the body is empty). I agree with your second suggestion. It's better not to refer to the 'Content-Length' header at all. ------------- PR: https://git.openjdk.java.net/jdk/pull/5505 From mbaesken at openjdk.java.net Wed Sep 15 08:07:56 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Wed, 15 Sep 2021 08:07:56 GMT Subject: RFR: JDK-8273526: Extend the OSContainer API pids controller with pids.current [v2] In-Reply-To: References: <3PokFyPHsil0S9A15OWUj97Xls1tFpkeXuqHydXnh4o=.64e6daaa-5dc3-438c-b362-ba61775d1403@github.com> Message-ID: On Fri, 10 Sep 2021 12:36:35 GMT, Severin Gehwolf wrote: >> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: >> >> Some simplifications and test adjustment suggested by Severin > > test/hotspot/jtreg/containers/docker/TestPids.java line 101: > >> 99: System.out.println("Found " + lineMarker + " with value: " + ivalue); >> 100: try { >> 101: int ai = Integer.parseInt(ivalue); > > Could you move the debug print line to after line 101, please. It could say: > > `System.out.println("Found " + lineMarker + " with value: " + ai + ". PASS.");` the debug println has been moved down. ------------- PR: https://git.openjdk.java.net/jdk/pull/5437 From mbaesken at openjdk.java.net Wed Sep 15 08:07:55 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Wed, 15 Sep 2021 08:07:55 GMT Subject: RFR: JDK-8273526: Extend the OSContainer API pids controller with pids.current [v3] In-Reply-To: References: Message-ID: <-AS4eYSWQbIT2pnPY1hveJCn4o1h8Aoc66xTHejbLMs=.937d0af0-290e-414a-ad8d-0e38b7e3c775@github.com> On Wed, 15 Sep 2021 07:09:54 GMT, Matthias Baesken wrote: >>> Maybe it should be "any_integer"? >> >> +1 > >> Is "no_value_expected" generated by Docker? I searched the entire HotSpot source code and couldn't find it. I also couldn't find "WARNING: Your kernel does not support pids limit capabilities". >> > > Hi, this warning is showing up on some of our Linux ppc64le machines where the pids limit capabilities is not supported. > > Best regards, Matthias Hello, I adjusted to any_integer, and introduced the "final String warning_kernel_no_pids_support" . I think the message is more related to the kernel features so I did not add the add the 'generated by Docker' comment. Best regards, Matthias ------------- PR: https://git.openjdk.java.net/jdk/pull/5437 From jboes at openjdk.java.net Wed Sep 15 08:14:49 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Wed, 15 Sep 2021 08:14:49 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server In-Reply-To: <31drgqqPbEvMqgrQwn2enoGWQNC-wj-_-mkU5Z-jqko=.5a74059f-49f6-41b7-9d28-ed82a386abe9@github.com> References: <4x6-khhmw9bKpARkEOpSZSk8hfgFtdvuvv5ZIACrAuQ=.bed5405c-c05d-4361-aa97-8f27d10b61de@github.com> <31drgqqPbEvMqgrQwn2enoGWQNC-wj-_-mkU5Z-jqko=.5a74059f-49f6-41b7-9d28-ed82a386abe9@github.com> Message-ID: <9cloqpWS1l522k4R8lgxKx1WZWtn8cvY4T0HTpIjfqo=.844055aa-89d9-4d31-9ff3-ccbeb87bd573@github.com> On Tue, 14 Sep 2021 13:38:27 GMT, Daniel Fuchs wrote: >> src/jdk.httpserver/share/classes/com/sun/net/httpserver/Headers.java line 106: >> >>> 104: var h = headers.entrySet().stream() >>> 105: .collect(Collectors.toUnmodifiableMap( >>> 106: Entry::getKey, e -> new LinkedList<>(e.getValue()))); >> >> I wonder, what the reason of `LinkedList` usages here? >> As I know ArrayList is faster in all real-world scenarios. > > Hi Andrey, IIRC from when I reviewed this code the current implementation of `Headers` already uses `LinkedList` in other places - so this preserves the concrete list implementation class that `Headers` uses (see `Headers::add`). Not that it matters much - but if we wanted to replace `LinkedList` with `ArrayList` I believe we should do it consistently in this class - and probably outside of the realm of this JEP. That's right, it's due to the pre-existing implementation. ------------- PR: https://git.openjdk.java.net/jdk/pull/5505 From jboes at openjdk.java.net Wed Sep 15 08:22:11 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Wed, 15 Sep 2021 08:22:11 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server In-Reply-To: References: <50yuahjxwmeRdrRh1z6VLAbscVU5sJ3w4qddmNMBDJ0=.408e29b1-7644-40c9-83ca-59d3ebba9633@github.com> Message-ID: On Tue, 14 Sep 2021 16:45:08 GMT, Daniel Fuchs wrote: >> Just a rewording, maybe. > > Hmm... Maye that should be "The response headers *are sent*". The non-obvious technical details is that the response headers are sent before the body - as soon as you call `sendResponseHeaders`. The link is here to provide a better understanding of the workings of the new Handler. The headers are sent by calling `sendResponseHeaders` on the HttpExchange. Good point on rephrasing to "The response headers are sent", I'll change that. ------------- PR: https://git.openjdk.java.net/jdk/pull/5505 From jboes at openjdk.java.net Wed Sep 15 08:28:44 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Wed, 15 Sep 2021 08:28:44 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server In-Reply-To: References: Message-ID: On Wed, 15 Sep 2021 07:49:38 GMT, Michael McMahon wrote: >> Or maybe - which would be more accurate: >> >> >> with the given {@code statusCode} and the body bytes' length (or {@code -1} if the body is empty). > > I agree with your second suggestion. It's better not to refer to the 'Content-Length' header at all. Indeed more accurate, I'll update to the second suggestion. ------------- PR: https://git.openjdk.java.net/jdk/pull/5505 From jboes at openjdk.java.net Wed Sep 15 08:45:49 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Wed, 15 Sep 2021 08:45:49 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server In-Reply-To: <50yuahjxwmeRdrRh1z6VLAbscVU5sJ3w4qddmNMBDJ0=.408e29b1-7644-40c9-83ca-59d3ebba9633@github.com> References: <50yuahjxwmeRdrRh1z6VLAbscVU5sJ3w4qddmNMBDJ0=.408e29b1-7644-40c9-83ca-59d3ebba9633@github.com> Message-ID: On Tue, 14 Sep 2021 15:56:28 GMT, Jim Laskey wrote: >> This change implements a simple web server that can be run on the command-line with `java -m jdk.httpserver`. >> >> This is facilitated by adding an entry point for the `jdk.httpserver` module, an implementation class whose main method is run when the above command is executed. This is the first such module entry point in the JDK. >> >> The server is a minimal HTTP server that serves the static files of a given directory, similar to existing alternatives on other platforms and convenient for testing, development, and debugging. >> >> Additionally, a small API is introduced for programmatic creation and customization. >> >> Testing: tier1-3. > > src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpsServer.java line 152: > >> 150: return server; >> 151: } >> 152: > > Too bad we couldn't simplify the setting up a basic certificate for https. That would be nice indeed, but the goal of this JEP is a minimal HTTP-only server, intentionally leaving anything HTTPS aside. `HttpsServer::create` being the exception, added to provide the same convenience as for `HttpServer`. Any HTTPS configuration can be done using the existing API. ------------- PR: https://git.openjdk.java.net/jdk/pull/5505 From shade at openjdk.java.net Wed Sep 15 09:00:57 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 15 Sep 2021 09:00:57 GMT Subject: Integrated: 8273494: Zero: Put libjvm.so into "zero" folder, not "server" In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 10:17:02 GMT, Aleksey Shipilev wrote: > Currently, the build system defaults the libjvm.so location to "server". This makes looking for `libjvm.so` awkward, see JDK-8273487 for example. We need to see if moving the libjvm.so to a proper location breaks anything. > > Additional testing: > - [x] Linux x86_64 Zero build > - [x] Linux x86_64 Zero bootcycle-images > - [x] Linux x86_64 Zero `tier1` This pull request has now been integrated. Changeset: 8fbcc823 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/8fbcc8239a3fc04e56ebbd287c7bb5db731977b7 Stats: 14 lines in 6 files changed: 0 ins; 3 del; 11 mod 8273494: Zero: Put libjvm.so into "zero" folder, not "server" Reviewed-by: ihse, sgehwolf ------------- PR: https://git.openjdk.java.net/jdk/pull/5440 From shade at openjdk.java.net Wed Sep 15 09:00:56 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 15 Sep 2021 09:00:56 GMT Subject: RFR: 8273494: Zero: Put libjvm.so into "zero" folder, not "server" In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 10:17:02 GMT, Aleksey Shipilev wrote: > Currently, the build system defaults the libjvm.so location to "server". This makes looking for `libjvm.so` awkward, see JDK-8273487 for example. We need to see if moving the libjvm.so to a proper location breaks anything. > > Additional testing: > - [x] Linux x86_64 Zero build > - [x] Linux x86_64 Zero bootcycle-images > - [x] Linux x86_64 Zero `tier1` Thank you all! ------------- PR: https://git.openjdk.java.net/jdk/pull/5440 From jboes at openjdk.java.net Wed Sep 15 09:02:05 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Wed, 15 Sep 2021 09:02:05 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v2] In-Reply-To: References: Message-ID: > This change implements a simple web server that can be run on the command-line with `java -m jdk.httpserver`. > > This is facilitated by adding an entry point for the `jdk.httpserver` module, an implementation class whose main method is run when the above command is executed. This is the first such module entry point in the JDK. > > The server is a minimal HTTP server that serves the static files of a given directory, similar to existing alternatives on other platforms and convenient for testing, development, and debugging. > > Additionally, a small API is introduced for programmatic creation and customization. > > Testing: tier1-3. Julia Boes has updated the pull request incrementally with three additional commits since the last revision: - small spec rewording - add module main class to symbolgenerator - remove UnmodifiableHeaders constant ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5505/files - new: https://git.openjdk.java.net/jdk/pull/5505/files/093263d0..f53c59d9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5505&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5505&range=00-01 Stats: 32 lines in 3 files changed: 25 ins; 2 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/5505.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5505/head:pull/5505 PR: https://git.openjdk.java.net/jdk/pull/5505 From jboes at openjdk.java.net Wed Sep 15 09:04:45 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Wed, 15 Sep 2021 09:04:45 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v2] In-Reply-To: References: Message-ID: On Wed, 15 Sep 2021 03:14:04 GMT, Jaikiran Pai wrote: >> FWIW `.z` is the extension of the old Unix `compress` program. > >> FWIW `.z` is the extension of the old Unix `compress` program. > > Thank you Florent, I wasn't aware of that. related PR for reference: https://github.com/openjdk/jdk/pull/5506 ------------- PR: https://git.openjdk.java.net/jdk/pull/5505 From sgehwolf at openjdk.java.net Wed Sep 15 09:35:49 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Wed, 15 Sep 2021 09:35:49 GMT Subject: RFR: JDK-8273526: Extend the OSContainer API pids controller with pids.current [v4] In-Reply-To: References: Message-ID: <-dUrye6VcX6yUG8OlEiGO1-vdojEMY_vY3niClPCF3Y=.4cac75ba-b785-4a13-b511-b3067808b7f7@github.com> On Wed, 15 Sep 2021 07:46:34 GMT, Matthias Baesken wrote: >> https://bugs.openjdk.java.net/browse/JDK-8266490 >> extended the OSContainer API in order to also support the pids controller of cgroups. However only pids.max output was added with 8266490. >> There is a second parameter pids.current , see https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#pid >> that would be helpful too and can be added to the OSContainer API . >> pids.current : >> A read-only single value file which exists on all cgroups. >> The number of processes currently in the cgroup and its descendants. >> >> Best regards, Matthias > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Adjust TestPids Marked as reviewed by sgehwolf (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5437 From github.com+53162078+shiyuexw at openjdk.java.net Wed Sep 15 09:42:12 2021 From: github.com+53162078+shiyuexw at openjdk.java.net (wxiang) Date: Wed, 15 Sep 2021 09:42:12 GMT Subject: RFR: 8273401: Disable JarIndex support in URLClassPath Message-ID: There is a bug for URLClassPath.findResources with JarIndex. Currently, there was agreement on dropping the support from the URLClassLoader implementation but it was suggested that it should be disabled for a release or two before the code is removed. A system property can be used to re-enable JarIndex support in URLClassPath. The PR includes: Disable JarIndex support in URLClassPath by default. Add system property jdk.net.URLClassPath.enableJarIndex to re-enable JarIndex support. ------------- Commit messages: - 8273401: Disable JarIndex support in URLClassPath Changes: https://git.openjdk.java.net/jdk/pull/5524/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5524&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273401 Stats: 13 lines in 3 files changed: 8 ins; 1 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/5524.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5524/head:pull/5524 PR: https://git.openjdk.java.net/jdk/pull/5524 From shade at openjdk.java.net Wed Sep 15 10:11:56 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 15 Sep 2021 10:11:56 GMT Subject: RFR: 8273797: Stop impersonating "server" VM in all VM variants Message-ID: As the follow-up for Zero-specific JDK-8273494, we might want to clean up build system logic for all VM variants: stop impersonating "server" VMs for all of them. This basically leaves "core" and "custom" variants to be handled with this patch. Additional testing: - [x] Linux x86_64 `core` build passes, `libjvm.so` now in `core`, `jvm.cfg` mentions `-core KNOWN` - [x] Linux x86_64 `custom` (+serialgc,+compiler2) build passes, `libjvm.so` now in `custom`, `jvm.cfg` mentions `-custom KNOWN` ------------- Commit messages: - Fix Changes: https://git.openjdk.java.net/jdk/pull/5526/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5526&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273797 Stats: 41 lines in 5 files changed: 3 ins; 33 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/5526.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5526/head:pull/5526 PR: https://git.openjdk.java.net/jdk/pull/5526 From github.com+53162078+shiyuexw at openjdk.java.net Wed Sep 15 10:22:49 2021 From: github.com+53162078+shiyuexw at openjdk.java.net (wxiang) Date: Wed, 15 Sep 2021 10:22:49 GMT Subject: RFR: 8273401: Remove JarIndex support in URLClassPath [v2] In-Reply-To: References: <9FAk9cObH2-NC5fgf7gAE0o4PEhCmja13cwcL0lCrTg=.78759581-f42f-4ed4-a4a3-581ff84451af@github.com> Message-ID: On Wed, 15 Sep 2021 05:59:13 GMT, Alan Bateman wrote: > > Yes, I will take care of it. Need I create a new PR? > > Up to you, it's okay to continue with this one if you want, we would just need to change the description here and in JBS. I created a new PR https://github.com/openjdk/jdk/pull/5524 to disable JarIndex and update the description in JBS. ------------- PR: https://git.openjdk.java.net/jdk/pull/5383 From shade at openjdk.java.net Wed Sep 15 10:26:58 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 15 Sep 2021 10:26:58 GMT Subject: RFR: 8273803: Zero: Handle "zero" variant in CommandLineOptionTest.java Message-ID: This currently manifests if you run Zero with compiler/codecache/cli tests (part of tier1): $ CONF=linux-x86_64-zero-fastdebug make exploded-test TEST=compiler/codecache/cli/ STDERR: java.lang.RuntimeException: Unknown VM mode. at jdk.test.lib.cli.CommandLineOptionTest.getVMTypeOption(CommandLineOptionTest.java:504) at jdk.test.lib.cli.CommandLineOptionTest.verifyOptionValueForSameVM(CommandLineOptionTest.java:397) at compiler.codecache.cli.codeheapsize.GenericCodeHeapSizeRunner.run(GenericCodeHeapSizeRunner.java:42) at compiler.codecache.cli.common.CodeCacheCLITestCase.run(CodeCacheCLITestCase.java:62) at compiler.codecache.cli.common.CodeCacheCLITestBase.runTestCases(CodeCacheCLITestBase.java:58) at compiler.codecache.cli.codeheapsize.TestCodeHeapSizeOptions.main(TestCodeHeapSizeOptions.java:86) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:568) at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312) at java.base/java.lang.Thread.run(Thread.java:833) While these tests are compiler tests, and they should arguably never run with Zero, the problem is in shared code, which can be used in future by other non-compiler tests. Additional testing: - [x] Affected compiler tests now "properly" fail with "no compilers" errors ------------- Commit messages: - Fix Changes: https://git.openjdk.java.net/jdk/pull/5527/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5527&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273803 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5527.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5527/head:pull/5527 PR: https://git.openjdk.java.net/jdk/pull/5527 From shade at openjdk.java.net Wed Sep 15 10:36:06 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 15 Sep 2021 10:36:06 GMT Subject: RFR: 8273804: Platform.isTieredSupported should handle the no-compiler case Message-ID: Happens with Zero tests: $ CONF=linux-x86_64-zero-fastdebug make exploded-test TEST=compiler/codecache/CheckSegmentedCodeCache.java ... java.lang.NullPointerException: Cannot invoke "String.contains(java.lang.CharSequence)" because "jdk.test.lib.Platform.compiler" is null at jdk.test.lib.Platform.isTieredSupported(Platform.java:82) at compiler.codecache.CheckSegmentedCodeCache.verifySegmentedCodeCache(CheckSegmentedCodeCache.java:61) at compiler.codecache.CheckSegmentedCodeCache.main(CheckSegmentedCodeCache.java:108) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:568) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:833) Additional testing: - [x] Linux x86_64 Zero, `compiler/codecache/CheckSegmentedCodeCache.java` now properly fails with "no compilers" error ------------- Commit messages: - Fix Changes: https://git.openjdk.java.net/jdk/pull/5528/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5528&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273804 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5528.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5528/head:pull/5528 PR: https://git.openjdk.java.net/jdk/pull/5528 From github.com+10835776+stsypanov at openjdk.java.net Wed Sep 15 11:14:50 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Wed, 15 Sep 2021 11:14:50 GMT Subject: Integrated: 8273656: Improve java.lang.invoke.MethodType.parameterList() and its usage In-Reply-To: References: Message-ID: On Mon, 13 Sep 2021 11:06:15 GMT, ?????? ??????? wrote: > Currently the method is implemented like > > public List> parameterList() { > return Collections.unmodifiableList(Arrays.asList(ptypes.clone())); > } > > This seems to be excessive, as three objects are allocated here. Instead we can use `List.of(ptypes)` which doesn't allocate anything for empty array and for one of length 1 and 2 it allocates lightweight objects with 2 fields, still copying longer arrays. This is likely to be fruitful as most of methods have 0-2 parameters. > > Also there is a couple of cases when `MethodType.parameterLis()` is called to get its size, which is excessive either as we can use `MethodType.parameterCount()` instead. This pull request has now been integrated. Changeset: 4c673df3 Author: Sergey Tsypanov Committer: Jorn Vernee URL: https://git.openjdk.java.net/jdk/commit/4c673df31e46644b21fefa51e0ea01f7d9b94856 Stats: 7 lines in 2 files changed: 0 ins; 0 del; 7 mod 8273656: Improve java.lang.invoke.MethodType.parameterList() and its usage Reviewed-by: jvernee, vlivanov, mchung ------------- PR: https://git.openjdk.java.net/jdk/pull/5489 From dfuchs at openjdk.java.net Wed Sep 15 11:54:51 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 15 Sep 2021 11:54:51 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v15] In-Reply-To: References: <-B-eCk3BMG0dyyc2dQfVgDmR2ruBu4OUpEWg0p_gyzY=.1eb1105e-c68f-44cc-9424-a3303e3aa081@github.com> Message-ID: On Wed, 15 Sep 2021 06:11:31 GMT, Jaikiran Pai wrote: >> I think we want the entries to be sorted by default; that is the most useful to the most people. >> Checking for the overloaded method seems like trying too hard. >> Changing the entrySet to return them sorted (always) would add overhead in a lot of cases but would allow a subclass to re-sort them as they see fit. >> A half measure would be to sort only if the properties instance was not subclassed and spec it that way as an implementation detail. > > Good catch regarding the possibility of entrySet() being overridden. > >> I think we want the entries to be sorted by default; that is the most useful to the most people. > > Agreed > >> Changing the entrySet to return them sorted (always) would add overhead in a lot of cases but would allow a subclass to re-sort them as they see fit. > > Agreed - I think changing the implementation of entrySet to return an ordered set is an unnecessary overhead in the context of what's being targeted in this PR. > >> A half measure would be to sort only if the properties instance was not subclassed and spec it that way as an implementation detail. > > I think just checking the properties instance type to see if it is subclassed is perhaps too big a penalty for those applications that do subclass java.util.Properties but don't override the entrySet() method. Such applications/subclasses will then never be able to use this new implementation where we write out the properties in the natural order. Perhaps a middle ground would be your other option: > >> Checking for the overloaded method seems like trying too hard. > > IMO, I don't think we would be trying too hard to identify this. I have updated this PR to try and articulate this both in terms of the implementation as well as the updated javadoc of this method. Tests have then been introduced to verify this case of Properties subclasses. This https://github.com/openjdk/jdk/pull/5372/commits/79d1052775dd8e98fb7078710eda0fd6dd83b164 is the relevant commit in the updated PR. I understand that we haven't come to an agreement on this aspect yet, but it was easier to show it in terms of code and spec, so I decided to include this commit in the PR. I will of course revert it or change it appropriately depending on how we want to deal with this case. > > Checking for the overloaded method seems like trying too hard. > > IMO, I don't think we would be trying too hard to identify this. I have updated this PR to try and articulate this both in terms of the implementation as well as the updated javadoc of this method. Tests have then been introduced to verify this case of Properties subclasses. This 79d1052 is the relevant commit in the updated PR. I understand that we haven't come to an agreement on this aspect yet, but it was easier to show it in terms of code and spec, so I decided to include this commit in the PR. I will of course revert it or change it appropriately depending on how we want to deal with this case. Hmm. Interesting idea - it looks like it could work given that properties as a private `EntrySet` class used for its entry set implementation... @RogerRiggs what do you think? ------------- PR: https://git.openjdk.java.net/jdk/pull/5372 From dfuchs at openjdk.java.net Wed Sep 15 12:05:46 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 15 Sep 2021 12:05:46 GMT Subject: RFR: 8273401: Disable JarIndex support in URLClassPath In-Reply-To: References: Message-ID: On Wed, 15 Sep 2021 09:33:10 GMT, wxiang wrote: > There is a bug for URLClassPath.findResources with JarIndex. > Currently, there was agreement on dropping the support from the URLClassLoader implementation but it was suggested that it should be disabled for a release or two before the code is removed. > A system property can be used to re-enable JarIndex support in URLClassPath. > > The PR includes: > Disable JarIndex support in URLClassPath by default. > Add system property jdk.net.URLClassPath.enableJarIndex to re-enable JarIndex support. src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 115: > 113: > 114: p = props.getProperty("jdk.net.URLClassPath.enableJarIndex"); > 115: ENABLE_JAR_INDEX = p != null ? p.equals("true") : false; Maybe this should use the same pattern than the other property above: ENABLE_JAR_INDEX = p != null ? p.equals("true") || p.isEmpty() : false; ------------- PR: https://git.openjdk.java.net/jdk/pull/5524 From dfuchs at openjdk.java.net Wed Sep 15 12:05:46 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 15 Sep 2021 12:05:46 GMT Subject: RFR: 8273401: Disable JarIndex support in URLClassPath In-Reply-To: References: Message-ID: On Wed, 15 Sep 2021 12:00:07 GMT, Daniel Fuchs wrote: >> There is a bug for URLClassPath.findResources with JarIndex. >> Currently, there was agreement on dropping the support from the URLClassLoader implementation but it was suggested that it should be disabled for a release or two before the code is removed. >> A system property can be used to re-enable JarIndex support in URLClassPath. >> >> The PR includes: >> Disable JarIndex support in URLClassPath by default. >> Add system property jdk.net.URLClassPath.enableJarIndex to re-enable JarIndex support. > > src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 115: > >> 113: >> 114: p = props.getProperty("jdk.net.URLClassPath.enableJarIndex"); >> 115: ENABLE_JAR_INDEX = p != null ? p.equals("true") : false; > > Maybe this should use the same pattern than the other property above: > > > ENABLE_JAR_INDEX = p != null ? p.equals("true") || p.isEmpty() : false; Another question is where to document this property. We will obviously need a CSR and releases notes. I also wonder if it should be promoted into a networking property - which would make it possible to document it in the `net.properties` file. @AlanBateman what do you think? ------------- PR: https://git.openjdk.java.net/jdk/pull/5524 From alanb at openjdk.java.net Wed Sep 15 12:12:43 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 15 Sep 2021 12:12:43 GMT Subject: RFR: 8273401: Disable JarIndex support in URLClassPath In-Reply-To: References: Message-ID: <79mwmCOeq_RDHak_jDzMBjAOeCh2onSYpFP3Xe172X8=.1b22b372-d1dd-499c-b2eb-f4360ef18fbb@github.com> On Wed, 15 Sep 2021 12:02:51 GMT, Daniel Fuchs wrote: > Another question is where to document this property. We will obviously need a CSR and releases notes. I also wonder if it should be promoted into a networking property - which would make it possible to document it in the `net.properties` file. @AlanBateman what do you think? jdk.net.URLClassLoader.enableJarIndex is meant to be a temporary property. We could document it in URLClassLoader as an implNote but I'm not sure that it's worth it. I re-worded the CSR to reflect the current proposal and Wang has submitted it. I noted in the CSR that a release note is planned. ------------- PR: https://git.openjdk.java.net/jdk/pull/5524 From dholmes at openjdk.java.net Wed Sep 15 12:59:44 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 15 Sep 2021 12:59:44 GMT Subject: RFR: 8273797: Stop impersonating "server" VM in all VM variants In-Reply-To: References: Message-ID: <0QFo_GvzFhukXte8vYI7hhdCW78fNvaP4UTT0xXmLeY=.7084ef65-9773-452a-8265-c7b68201562f@github.com> On Wed, 15 Sep 2021 10:02:19 GMT, Aleksey Shipilev wrote: > As the follow-up for Zero-specific JDK-8273494, we might want to clean up build system logic for all VM variants: stop impersonating "server" VMs for all of them. This basically leaves "core" and "custom" variants to be handled with this patch. > > Additional testing: > - [x] Linux x86_64 `core` build passes, `libjvm.so` now in `core`, `jvm.cfg` mentions `-core KNOWN` > - [x] Linux x86_64 `custom` (+serialgc,+compiler2) build passes, `libjvm.so` now in `custom`, `jvm.cfg` mentions `-custom KNOWN` >From a purely "mechanical" perspective this is a good simplification and cleanup. Did you test building all variants into one image? Cheers, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5526 From dholmes at openjdk.java.net Wed Sep 15 13:00:53 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 15 Sep 2021 13:00:53 GMT Subject: RFR: 8273803: Zero: Handle "zero" variant in CommandLineOptionTest.java In-Reply-To: References: Message-ID: On Wed, 15 Sep 2021 10:16:36 GMT, Aleksey Shipilev wrote: > This currently manifests if you run Zero with compiler/codecache/cli tests (part of tier1): > > > $ CONF=linux-x86_64-zero-fastdebug make exploded-test TEST=compiler/codecache/cli/ > > STDERR: > java.lang.RuntimeException: Unknown VM mode. > at jdk.test.lib.cli.CommandLineOptionTest.getVMTypeOption(CommandLineOptionTest.java:504) > at jdk.test.lib.cli.CommandLineOptionTest.verifyOptionValueForSameVM(CommandLineOptionTest.java:397) > at compiler.codecache.cli.codeheapsize.GenericCodeHeapSizeRunner.run(GenericCodeHeapSizeRunner.java:42) > at compiler.codecache.cli.common.CodeCacheCLITestCase.run(CodeCacheCLITestCase.java:62) > at compiler.codecache.cli.common.CodeCacheCLITestBase.runTestCases(CodeCacheCLITestBase.java:58) > at compiler.codecache.cli.codeheapsize.TestCodeHeapSizeOptions.main(TestCodeHeapSizeOptions.java:86) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:568) > at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312) > at java.base/java.lang.Thread.run(Thread.java:833) > > > While these tests are compiler tests, and they should arguably never run with Zero, the problem is in shared code, which can be used in future by other non-compiler tests. > > Additional testing: > - [x] Affected compiler tests now "properly" fail with "no compilers" errors Looks fine and trivial. Cheers, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5527 From dholmes at openjdk.java.net Wed Sep 15 13:01:57 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 15 Sep 2021 13:01:57 GMT Subject: RFR: 8273804: Platform.isTieredSupported should handle the no-compiler case In-Reply-To: References: Message-ID: On Wed, 15 Sep 2021 10:29:36 GMT, Aleksey Shipilev wrote: > Happens with Zero tests: > > > $ CONF=linux-x86_64-zero-fastdebug make exploded-test TEST=compiler/codecache/CheckSegmentedCodeCache.java > ... > > java.lang.NullPointerException: Cannot invoke "String.contains(java.lang.CharSequence)" because "jdk.test.lib.Platform.compiler" is null > at jdk.test.lib.Platform.isTieredSupported(Platform.java:82) > at compiler.codecache.CheckSegmentedCodeCache.verifySegmentedCodeCache(CheckSegmentedCodeCache.java:61) > at compiler.codecache.CheckSegmentedCodeCache.main(CheckSegmentedCodeCache.java:108) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:568) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:833) > > > Additional testing: > - [x] Linux x86_64 Zero, `compiler/codecache/CheckSegmentedCodeCache.java` now properly fails with "no compilers" error Looks fine and trivial. Cheers, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5528 From igraves at openjdk.java.net Wed Sep 15 13:12:55 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Wed, 15 Sep 2021 13:12:55 GMT Subject: Integrated: 8273514: java/util/DoubleStreamSums/CompensatedSums.java failure In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 04:19:07 GMT, Ian Graves wrote: > Relaxing some assertion bounds to allow for small error values that still show improvement over previous summation method. This pull request has now been integrated. Changeset: f531b5c7 Author: Ian Graves URL: https://git.openjdk.java.net/jdk/commit/f531b5c79633a12efa56c55366e0b7196350e896 Stats: 18 lines in 1 file changed: 5 ins; 6 del; 7 mod 8273514: java/util/DoubleStreamSums/CompensatedSums.java failure Reviewed-by: rriggs, darcy ------------- PR: https://git.openjdk.java.net/jdk/pull/5430 From asemenyuk at openjdk.java.net Wed Sep 15 13:26:15 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Wed, 15 Sep 2021 13:26:15 GMT Subject: RFR: 8272815: jpackage --type rpm produces an error: Invalid or unsupported type: [null] [v3] In-Reply-To: References: Message-ID: > Fix jpackage error output when "--type" CLI option is missing and jpackage detects that it can't build native packages in the environment. Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: dummy commit ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5512/files - new: https://git.openjdk.java.net/jdk/pull/5512/files/44cf9fde..a7534c7e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5512&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5512&range=01-02 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5512.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5512/head:pull/5512 PR: https://git.openjdk.java.net/jdk/pull/5512 From asemenyuk at openjdk.java.net Wed Sep 15 13:26:16 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Wed, 15 Sep 2021 13:26:16 GMT Subject: Integrated: 8272815: jpackage --type rpm produces an error: Invalid or unsupported type: [null] In-Reply-To: References: Message-ID: <8Rm5vfcZQNrJWa7H3fon2CBImXTYxaR0eH6fkUCai5M=.101fe8fa-f4b8-4105-a527-6fc8dd7f147a@github.com> On Tue, 14 Sep 2021 17:21:29 GMT, Alexey Semenyuk wrote: > Fix jpackage error output when "--type" CLI option is missing and jpackage detects that it can't build native packages in the environment. This pull request has now been integrated. Changeset: a3ca7702 Author: Alexey Semenyuk URL: https://git.openjdk.java.net/jdk/commit/a3ca770227065aecc2df9f9c711687fd8ec5d34e Stats: 18 lines in 2 files changed: 2 ins; 4 del; 12 mod 8272815: jpackage --type rpm produces an error: Invalid or unsupported type: [null] Reviewed-by: herrick, almatvee ------------- PR: https://git.openjdk.java.net/jdk/pull/5512 From shade at openjdk.java.net Wed Sep 15 13:33:05 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 15 Sep 2021 13:33:05 GMT Subject: RFR: 8273797: Stop impersonating "server" VM in all VM variants In-Reply-To: <0QFo_GvzFhukXte8vYI7hhdCW78fNvaP4UTT0xXmLeY=.7084ef65-9773-452a-8265-c7b68201562f@github.com> References: <0QFo_GvzFhukXte8vYI7hhdCW78fNvaP4UTT0xXmLeY=.7084ef65-9773-452a-8265-c7b68201562f@github.com> Message-ID: On Wed, 15 Sep 2021 12:56:34 GMT, David Holmes wrote: > Did you test building all variants into one image? Yes, I did, but I think the build system is confused about the VM feature sets. I have a vague recollection that ether @magicus or someone else at one point suggested eliminating multi-variant builds, maybe that should be the next step in build simplification. ------------- PR: https://git.openjdk.java.net/jdk/pull/5526 From shade at openjdk.java.net Wed Sep 15 14:25:07 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 15 Sep 2021 14:25:07 GMT Subject: RFR: 8273314: Add tier4 test groups [v3] In-Reply-To: References: <6rDioD5KZREYHyzOXol72O0erNDqKHUqb-0k1SwhInA=.90a12492-9e2f-4f0c-bf09-8d67d1d6111f@github.com> Message-ID: <54l9_jkU4qhnz_ULvtN7sQXJ46LIdUhcdvxAkhCmlw4=.4a7adb15-e01c-4a38-bb99-3b577e9e05ca@github.com> On Mon, 6 Sep 2021 13:22:03 GMT, Aleksey Shipilev wrote: >> During the review of JDK-8272914 that added hotspot:tier{2,3} groups, @iignatev suggested to create tier4 groups that capture all tests not in tiers{1,2,3}. I have excluded `vmTestbase` and `hotspot:tier4,` because they take 10+ hours on my highly parallel machine. I have also excluded `applications` from `hotspot:tier4`, because they require test dependencies (e.g. jcstress). >> >> Sample run: >> >> >> ============================== >> Test summary >> ============================== >> TEST TOTAL PASS FAIL ERROR >>>> jtreg:test/hotspot/jtreg:tier4 426 425 1 0 << >>>> jtreg:test/jdk:tier4 2891 2885 4 2 << >> jtreg:test/langtools:tier4 0 0 0 0 >> jtreg:test/jaxp:tier4 0 0 0 0 >> ============================== >> >> real 64m13.994s >> user 1462m1.213s >> sys 39m38.032s >> >> >> There are interesting test failures on my machine, which I would address separately. > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Drop applications and fix the comment Progress: a) `hotspot:tier4` still runs cleanly, and a bit faster due to recent `vmTestbase` parallelism improvements. b) `jdk:tier4` has a lot of failures in headful mode, probably because the tests do not like to run in parallel, see for example #5533. It would take a while to resolve for all GUI tests. If we are in agreement that current `tier4` definition is good, maybe it would be proper to integrate this PR, and then make `tier4` clean for headful mode? ------------- PR: https://git.openjdk.java.net/jdk/pull/5357 From github.com+22913521+1996scarlet at openjdk.java.net Wed Sep 15 14:46:12 2021 From: github.com+22913521+1996scarlet at openjdk.java.net (Remilia Scarlet) Date: Wed, 15 Sep 2021 14:46:12 GMT Subject: RFR: 8273774: jdk.tools.jlink.internal.Platform::is64Bit() should not hard code for x64 and AARCH64 Message-ID: <6UsB0ppKiipNg3JnMjcHSvKCIpFKnRSaii_BO_OAZlo=.1a501d24-2cb1-4f66-8c44-dfa570a89aad@github.com> Currently, the Platform.is64Bit() hard coded for judging whether the target arch is 64-bit. The `classes_nocoops.jsa not found` issue can be found while testing CDSPluginTest.java on 64-bit platform, excluding x64 and AARCH64, like mips64. For solving this issue, we assume that the bits of target UNKNOWN arch is same as the runtime platform. This patch adds the following lines in the Platform.is64Bit() method. ``` java if (arch() == Platform.Architecture.UNKNOWN) { return (System.getProperty("os.arch").indexOf("64") != -1); } Please review this change. Thanks! ------------- Commit messages: - 8273774: jdk.tools.jlink.internal.Platform::is64Bit() should not hard code for x64 and AARCH64 Changes: https://git.openjdk.java.net/jdk/pull/5519/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5519&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273774 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5519.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5519/head:pull/5519 PR: https://git.openjdk.java.net/jdk/pull/5519 From azeller at openjdk.java.net Wed Sep 15 15:16:10 2021 From: azeller at openjdk.java.net (Arno Zeller) Date: Wed, 15 Sep 2021 15:16:10 GMT Subject: RFR: 8247980: Exclusive execution of java/util/stream tests slows down tier1 In-Reply-To: References: Message-ID: <2WF7g-11KvRVl50GuYNlN2zSEgMNdW2ZRiFUbg6zJSg=.bc48f742-2d40-40cf-b373-1d7a6c69876e@github.com> On Thu, 19 Aug 2021 15:15:31 GMT, Aleksey Shipilev wrote: > See the bug report for more details. I would appreciate if people with their corporate testing systems would run this through their systems to avoid surprises. (ping @RealCLanger, @iignatev). I haven't recognized problems I can directly match to this change. But I should also state, that we parallelize not by using several agents in one jtreg tests - we use no agents and do not set concurrency. Currently we split the jtreg test in groups and each group is executed by a jtreg runner with concurrency one. But the runner do run in parallel if the machine is big enough. With this setup I do not expect influence by your change because we still execute the test in serial order - even after this change. At least that is how I understand the effect of exclusiveAccess.dirs . ------------- PR: https://git.openjdk.java.net/jdk/pull/5189 From michaelm at openjdk.java.net Wed Sep 15 15:37:27 2021 From: michaelm at openjdk.java.net (Michael McMahon) Date: Wed, 15 Sep 2021 15:37:27 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v2] In-Reply-To: References: <50yuahjxwmeRdrRh1z6VLAbscVU5sJ3w4qddmNMBDJ0=.408e29b1-7644-40c9-83ca-59d3ebba9633@github.com> Message-ID: On Wed, 15 Sep 2021 08:42:40 GMT, Julia Boes wrote: >> src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpsServer.java line 152: >> >>> 150: return server; >>> 151: } >>> 152: >> >> Too bad we couldn't simplify the setting up a basic certificate for https. > > That would be nice indeed, but the goal of this JEP is a minimal HTTP-only server, intentionally leaving anything HTTPS aside. `HttpsServer::create` being the exception, added to provide the same convenience as for `HttpServer`. Any HTTPS configuration can be done using the existing API. I agree the JEP should focus on a minimal HTTP server and the new API does allow an HTTPS based file server to be setup in one or two lines of code. I don't think there would be much value in providing something like self signed certificates, but it has become a lot easier to obtain real https certificates through services like LetsEncrypt so it might be interesting to write an article for inside.java showing how to set up a HTTPS server from start to finish. ------------- PR: https://git.openjdk.java.net/jdk/pull/5505 From erikj at openjdk.java.net Wed Sep 15 15:43:56 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 15 Sep 2021 15:43:56 GMT Subject: RFR: 8273797: Stop impersonating "server" VM in all VM variants In-Reply-To: References: Message-ID: On Wed, 15 Sep 2021 10:02:19 GMT, Aleksey Shipilev wrote: > As the follow-up for Zero-specific JDK-8273494, we might want to clean up build system logic for all VM variants: stop impersonating "server" VMs for all of them. This basically leaves "core" and "custom" variants to be handled with this patch. > > Additional testing: > - [x] Linux x86_64 `core` build passes, `libjvm.so` now in `core`, `jvm.cfg` mentions `-core KNOWN` > - [x] Linux x86_64 `custom` (+serialgc,+compiler2) build passes, `libjvm.so` now in `custom`, `jvm.cfg` mentions `-custom KNOWN` Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5526 From alanb at openjdk.java.net Wed Sep 15 15:53:49 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 15 Sep 2021 15:53:49 GMT Subject: RFR: 8273401: Disable JarIndex support in URLClassPath In-Reply-To: References: Message-ID: <9r0Xw7RxX1-0J2RvkYXvw5p_qc_ufrZmGDstEo79_GA=.73bb80d6-038c-4dbe-aeab-fba39adc9249@github.com> On Wed, 15 Sep 2021 09:33:10 GMT, wxiang wrote: > There is a bug for URLClassPath.findResources with JarIndex. > Currently, there was agreement on dropping the support from the URLClassLoader implementation but it was suggested that it should be disabled for a release or two before the code is removed. > A system property can be used to re-enable JarIndex support in URLClassPath. > > The PR includes: > Disable JarIndex support in URLClassPath by default. > Add system property jdk.net.URLClassPath.enableJarIndex to re-enable JarIndex support. Thanks @shiyuexw for going through the iterations, I think we have a good proposal now. ------------- PR: https://git.openjdk.java.net/jdk/pull/5524 From alanb at openjdk.java.net Wed Sep 15 15:53:50 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 15 Sep 2021 15:53:50 GMT Subject: RFR: 8273401: Disable JarIndex support in URLClassPath In-Reply-To: <79mwmCOeq_RDHak_jDzMBjAOeCh2onSYpFP3Xe172X8=.1b22b372-d1dd-499c-b2eb-f4360ef18fbb@github.com> References: <79mwmCOeq_RDHak_jDzMBjAOeCh2onSYpFP3Xe172X8=.1b22b372-d1dd-499c-b2eb-f4360ef18fbb@github.com> Message-ID: On Wed, 15 Sep 2021 12:09:31 GMT, Alan Bateman wrote: >> Another question is where to document this property. We will obviously need a CSR and releases notes. I also wonder if it should be promoted into a networking property - which would make it possible to document it in the `net.properties` file. @AlanBateman what do you think? > >> Another question is where to document this property. We will obviously need a CSR and releases notes. I also wonder if it should be promoted into a networking property - which would make it possible to document it in the `net.properties` file. @AlanBateman what do you think? > > jdk.net.URLClassLoader.enableJarIndex is meant to be a temporary property. We could document it in URLClassLoader as an implNote but I'm not sure that it's worth it. I re-worded the CSR to reflect the current proposal and Wang has submitted it. I noted in the CSR that a release note is planned. > Maybe this should use the same pattern than the other property above: > > ``` > ENABLE_JAR_INDEX = p != null ? p.equals("true") || p.isEmpty() : false; > ``` Yes, the intention is that -Djdk.net.URLClassLoader.enableJarIndex will re-enable the feature. ------------- PR: https://git.openjdk.java.net/jdk/pull/5524 From rriggs at openjdk.java.net Wed Sep 15 16:02:49 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 15 Sep 2021 16:02:49 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v17] In-Reply-To: References: Message-ID: On Wed, 15 Sep 2021 06:11:23 GMT, Jaikiran Pai wrote: >> The commit in this PR implements the proposal for enhancement that was discussed in the core-libs-dev mailing list recently[1], for https://bugs.openjdk.java.net/browse/JDK-8231640 >> >> At a high level - the `store()` APIs in `Properties` have been modified to now look for the `SOURCE_DATE_EPOCH` environment variable[2]. If that env variable is set, then instead of writing out the current date time as a date comment, the `store()` APIs instead will use the value set for this env variable to parse it to a `Date` and write out the string form of such a date. The implementation here uses the `d MMM yyyy HH:mm:ss 'GMT'` date format and `Locale.ROOT` to format and write out such a date. This should provide reproducibility whenever the `SOURCE_DATE_EPOCH` is set. Furthermore, intentionally, no changes in the date format of the "current date" have been done. >> >> These modified `store()` APIs work in the presence of the `SecurityManager` too. The caller is expected to have a read permission on the `SOURCE_DATE_EPOCH` environment variable. If the caller doesn't have that permission, then the implementation of these `store()` APIs will write out the "current date" and will ignore any value that has been set for the `SOURCE_DATE_EPOCH` env variable. This should allow for backward compatibility of existing applications, where, when they run under a `SecurityManager` and perhaps with an existing restrictive policy file, the presence of `SOURCE_DATE_EPOCH` shouldn't impact their calls to the `store()` APIs. >> >> The modified `store()` APIs will also ignore any value for `SOURCE_DATE_EPOCH` that cannot be parsed to an `long` value. In such cases, the `store()` APIs will write out the "current date" and ignore the value set for this environment variable. No exceptions will be thrown for such invalid values. This is an additional backward compatibility precaution to prevent any rogue value for `SOURCE_DATE_EPOCH` from breaking applications. >> >> An additional change in the implementation of these `store()` APIs and unrelated to the date comment, is that these APIs will now write out the property keys in a deterministic order. The keys will be written out in the natural ordering as specified by `java.lang.String#compareTo()` API. >> >> The combination of the ordering of the property keys when written out and the usage of `SOURCE_DATE_EPOCH` environment value to determine the date comment should together allow for reproducibility of the output generated by these `store()` APIs. >> >> New jtreg test classes have been introduced to verify these changes. The primary focus of `PropertiesStoreTest` is the ordering aspects of the property keys that are written out. On the other hand `StoreReproducibilityTest` focuses on the reproducibility of the output generated by these APIs. The `StoreReproducibilityTest` runs these tests both in the presence and absence of `SecurityManager`. Plus, in the presence of SecurityManager, it tests both the scenarios where the caller is granted the requisite permission and in other case not granted that permission. >> >> These new tests and existing tests under `test/jdk/java/util/Properties/` pass with these changes. >> >> [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-August/080758.html >> [2] https://reproducible-builds.org/specs/source-date-epoch/ > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > - Clarify how overriden Properties#entrySet() method impacts the order of stored properties > - Tests to verify subclasses of Properties Changes requested by rriggs (Reviewer). src/java.base/share/classes/java/util/Properties.java line 819: > 817: *

> 818: * If the {@systemProperty java.util.Properties.storeDate} is set and > 819: * is non-empty (as determined by {@link String#isEmpty() String.isEmpty}), "is set **on the command line** and non-empty"... Following from a comment on the CSR, it should be clear that the property value used can only be set on the command line. src/java.base/share/classes/java/util/Properties.java line 850: > 848: * the {@code entrySet} method and return a different {@code Set} instance, > 849: * then the property list is written out in the iteration order of > 850: * that returned {@code Set} Rewording a bit: "The keys and elements are written in the natural sort order of the keys in the `Properties.entrySet` unless `entrySet` is overridden by a subclass to return a different instance." "different instance" is a bit hard to implement given that entrySet() returns a new synchronized set each time. typo: missing final "." src/java.base/share/classes/java/util/Properties.java line 932: > 930: if (entries instanceof Collections.SynchronizedSet ss > 931: && ss.c instanceof EntrySet) { > 932: entries = new ArrayList<>(entries); >From the description referring to a 'different instance', I expected to see == or != in this test. Since Properties.entrySet() always returns a new synchronized set of a new EntrySet, specifying that the underlying map is the same instance is more difficult. Perhaps either the SynchronizedSet or the EntrySet instance could be cached and compared. (typo: missing space after period... ".If yes") ------------- PR: https://git.openjdk.java.net/jdk/pull/5372 From dfuchs at openjdk.java.net Wed Sep 15 16:18:51 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 15 Sep 2021 16:18:51 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v17] In-Reply-To: References: Message-ID: <4DMbKbYojvlPFMpMJKJx4Hp-E140T07nia8zpU_KcRo=.c725f3ff-dd42-4c0e-b16b-8f67613e6c2b@github.com> On Wed, 15 Sep 2021 15:31:45 GMT, Roger Riggs wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> - Clarify how overriden Properties#entrySet() method impacts the order of stored properties >> - Tests to verify subclasses of Properties > > src/java.base/share/classes/java/util/Properties.java line 850: > >> 848: * the {@code entrySet} method and return a different {@code Set} instance, >> 849: * then the property list is written out in the iteration order of >> 850: * that returned {@code Set} > > Rewording a bit: > > "The keys and elements are written in the natural sort order of the keys in the `Properties.entrySet` unless `entrySet` is overridden by a subclass to return a different instance." > > "different instance" is a bit hard to implement given that entrySet() returns a new synchronized set each time. > typo: missing final "." yes - maybe we could work on the wording. Perhaps: > The keys and elements are written in the natural sort order of the keys in the Properties.entrySet unless entrySet is overridden by a subclass to return a different set implementation. > src/java.base/share/classes/java/util/Properties.java line 932: > >> 930: if (entries instanceof Collections.SynchronizedSet ss >> 931: && ss.c instanceof EntrySet) { >> 932: entries = new ArrayList<>(entries); > > From the description referring to a 'different instance', I expected to see == or != in this test. > Since Properties.entrySet() always returns a new synchronized set of a new EntrySet, > specifying that the underlying map is the same instance is more difficult. > Perhaps either the SynchronizedSet or the EntrySet instance could be cached and compared. > > (typo: missing space after period... ".If yes") A custom subclass couldn't create an instance of EntrySet directly. Therefore if it wants to reorder the entries, it would have to return a new TreeSet or LinkedHashSet - or some other custom set implementation. If the result of calling entrySet() is an EntrySet wrapped in an UnmodifiableSet it's therefore legitimate to assume that the set hasn't been reordered, and that we can reorder it. Or am I missing something? ------------- PR: https://git.openjdk.java.net/jdk/pull/5372 From iklam at openjdk.java.net Wed Sep 15 16:21:56 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 15 Sep 2021 16:21:56 GMT Subject: RFR: JDK-8273526: Extend the OSContainer API pids controller with pids.current [v4] In-Reply-To: References: Message-ID: <2YWy5hYePGAF37qNzKNWfXOzseN2w2ASotVayUFCfLc=.e3d2be21-a335-4b15-9007-af93865b2afe@github.com> On Wed, 15 Sep 2021 07:46:34 GMT, Matthias Baesken wrote: >> https://bugs.openjdk.java.net/browse/JDK-8266490 >> extended the OSContainer API in order to also support the pids controller of cgroups. However only pids.max output was added with 8266490. >> There is a second parameter pids.current , see https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#pid >> that would be helpful too and can be added to the OSContainer API . >> pids.current : >> A read-only single value file which exists on all cgroups. >> The number of processes currently in the cgroup and its descendants. >> >> Best regards, Matthias > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Adjust TestPids Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5437 From mchung at openjdk.java.net Wed Sep 15 16:57:53 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 15 Sep 2021 16:57:53 GMT Subject: RFR: 8273774: jdk.tools.jlink.internal.Platform::is64Bit() should not hard code for x64 and AARCH64 In-Reply-To: <6UsB0ppKiipNg3JnMjcHSvKCIpFKnRSaii_BO_OAZlo=.1a501d24-2cb1-4f66-8c44-dfa570a89aad@github.com> References: <6UsB0ppKiipNg3JnMjcHSvKCIpFKnRSaii_BO_OAZlo=.1a501d24-2cb1-4f66-8c44-dfa570a89aad@github.com> Message-ID: On Wed, 15 Sep 2021 06:28:25 GMT, Remilia Scarlet wrote: > Currently, the Platform.is64Bit() hard coded for judging whether the target arch is 64-bit. > The `classes_nocoops.jsa not found` issue can be found while testing CDSPluginTest.java on 64-bit platform, excluding x64 and AARCH64, like mips64. > > For solving this issue, we assume that the bits of target UNKNOWN arch is same as the runtime platform. > This patch adds the following lines in the Platform.is64Bit() method. > > ``` java > if (arch() == Platform.Architecture.UNKNOWN) { > return (System.getProperty("os.arch").indexOf("64") != -1); > } > > > Please review this change. Thanks! The test assumes that it always runs on 64-bit platform and `classes_nocoops.jsa` is always created. It's a test bug. The test should only expect `classes_nocoops.jsa` exists if it's running on a supported 64-bit platform. Platform::is64Bit can do better for runtime platform (i.e. `Platform::runtime`) that can determine if it's 64-bit from the `sun.arch.data.model` system property. However, for unknown target platform, it's unknown if it's 64-bit or not. So I think fixing the test to check if `classes_nocoops.jsa` exists only on one of the JDK supported platforms (x64 or aarch64) is a better way to resolve your issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/5519 From lancea at openjdk.java.net Wed Sep 15 18:00:52 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 15 Sep 2021 18:00:52 GMT Subject: RFR: 8153490: Cannot setBytes() if incoming buffer's length is bigger than number of elements we want to insert. [v4] In-Reply-To: References: Message-ID: On Mon, 24 May 2021 11:18:57 GMT, Mitsuru Kariya wrote: >> Fix `SerialBlob.setBytes(long pos, byte[] bytes, int offset, int length)` in the following cases: >> >> 1. `pos - 1 + bytes.length - offset > this.length() && pos - 1 + length <= this.length()` >> The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully. >> (test31) >> >> 2. `pos - 1 + length > this.length()` >> The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully. *1 >> (test32) >> >> 3. `pos == this.length() + 1` >> The original implementation throws `SerialException` but this case should end successfully. *2 >> (test33) >> >> 4. `length < 0` >> The original implementation throws `ArrayIndexOutOfBoundsException` but this case should throw `SerialException`. >> (test34) >> >> 5. `offset + length > Integer.MAX_VALUE` >> The original implementation throws `ArrayIndexOutOfBoundsException` (or `OutOfMemoryError` in most cases) but this case should throw `SerialException`. >> (test35) >> >> Additionally, fix `SerialClob.setString(long pos, String str, int offset, int length)` in the following cases: >> >> 1. `offset > str.length()` >> The original implementaion throws `StringIndexOutOfBoundsException` but this case should throw `SerialException`. >> (test39) >> >> 2. `pos - 1 + str.length() - offset > this.length() && pos - 1 + length <= this.length()` >> The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully. >> (test32) >> >> 3. `pos - 1 + length > this.length()` >> The original implementaion throws `SerialException` but this case should end successfully. *3 >> (test40) >> >> 4. `pos == this.length() + 1` >> The original implementaion throws `SerialException` but this case should end successfully. *4 >> (test41) >> >> 5. `length < 0` >> The original implementation throws `StringIndexOutOfBoundsException` but this case should throw `SerialException`. >> (test42) >> >> 6. `offset + length > Integer.MAX_VALUE` >> The original implementation throws `ArrayIndexOutOfBoundsException` (or `OutOfMemoryError` in most cases) but this case should throw `SerialException`. >> (test43) >> >> >> The javadoc has also been modified according to the above. >> >> *1 The documentation of `Blob.setBytes()` says, "If the end of the Blob value is reached while writing the array of bytes, then the length of the Blob value will be increased to accommodate the extra bytes." >> >> *2 The documentation of `Blob.setBytes()` says, "If the value specified for pos is greater than the length+1 of the BLOB value then the behavior is undefined." >> So, it should work correctly when pos == length+1 of the BLOB value. >> >> *3 The documentation of `Clob.setString()` says, "If the end of the Clob value is eached while writing the given string, then the length of the Clob value will be increased to accommodate the extra characters." >> >> *4 The documentation of `Clob.setString()` says, "If the value specified for pos is greater than the length+1 of the CLOB value then the behavior is undefined." >> So, it should work correctly when pos == length+1 of the CLOB value. > > Mitsuru Kariya has updated the pull request incrementally with one additional commit since the last revision: > > Modify javadoc for consistency src/java.sql.rowset/share/classes/javax/sql/rowset/serial/SerialBlob.java line 337: > 335: * @param bytes the array of bytes to be written to the {@code BLOB} > 336: * value > 337: * @param offset the offset into the array {@code bytes} at which Please change all occurrences of `{@code bytes}` to `{@code byte}s` as this was caught as part of the CSR review. ------------- PR: https://git.openjdk.java.net/jdk/pull/4001 From lancea at openjdk.java.net Wed Sep 15 18:33:54 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 15 Sep 2021 18:33:54 GMT Subject: RFR: 8273401: Disable JarIndex support in URLClassPath In-Reply-To: References: <79mwmCOeq_RDHak_jDzMBjAOeCh2onSYpFP3Xe172X8=.1b22b372-d1dd-499c-b2eb-f4360ef18fbb@github.com> Message-ID: On Wed, 15 Sep 2021 15:48:55 GMT, Alan Bateman wrote: >>> Another question is where to document this property. We will obviously need a CSR and releases notes. I also wonder if it should be promoted into a networking property - which would make it possible to document it in the `net.properties` file. @AlanBateman what do you think? >> >> jdk.net.URLClassLoader.enableJarIndex is meant to be a temporary property. We could document it in URLClassLoader as an implNote but I'm not sure that it's worth it. I re-worded the CSR to reflect the current proposal and Wang has submitted it. I noted in the CSR that a release note is planned. > >> Maybe this should use the same pattern than the other property above: >> >> ``` >> ENABLE_JAR_INDEX = p != null ? p.equals("true") || p.isEmpty() : false; >> ``` > > Yes, the intention is that -Djdk.net.URLClassLoader.enableJarIndex will re-enable the feature. I assume the reason for specifically checking for a value of true or an empty string as you envision allowing the property to be explicitly set to false in the future? Otherwise we could just check if the property is set(regardless of value) to re-enable the feature. ------------- PR: https://git.openjdk.java.net/jdk/pull/5524 From dfuchs at openjdk.java.net Wed Sep 15 19:01:46 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 15 Sep 2021 19:01:46 GMT Subject: RFR: 8273401: Disable JarIndex support in URLClassPath In-Reply-To: References: <79mwmCOeq_RDHak_jDzMBjAOeCh2onSYpFP3Xe172X8=.1b22b372-d1dd-499c-b2eb-f4360ef18fbb@github.com> Message-ID: On Wed, 15 Sep 2021 18:29:44 GMT, Lance Andersen wrote: >>> Maybe this should use the same pattern than the other property above: >>> >>> ``` >>> ENABLE_JAR_INDEX = p != null ? p.equals("true") || p.isEmpty() : false; >>> ``` >> >> Yes, the intention is that -Djdk.net.URLClassLoader.enableJarIndex will re-enable the feature. > > I assume the reason for specifically checking for a value of true or an empty string as you envision allowing the property to be explicitly set to false in the future? > > Otherwise we could just check if the property is set(regardless of value) to re-enable the feature. I would dislike it if `-Djdk.net.URLClassPath.enableJarIndex=false` meant true... ------------- PR: https://git.openjdk.java.net/jdk/pull/5524 From lancea at openjdk.java.net Wed Sep 15 19:43:43 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 15 Sep 2021 19:43:43 GMT Subject: RFR: 8273401: Disable JarIndex support in URLClassPath In-Reply-To: References: <79mwmCOeq_RDHak_jDzMBjAOeCh2onSYpFP3Xe172X8=.1b22b372-d1dd-499c-b2eb-f4360ef18fbb@github.com> Message-ID: On Wed, 15 Sep 2021 18:59:08 GMT, Daniel Fuchs wrote: >> I assume the reason for specifically checking for a value of true or an empty string as you envision allowing the property to be explicitly set to false in the future? >> >> Otherwise we could just check if the property is set(regardless of value) to re-enable the feature. > > I would dislike it if `-Djdk.net.URLClassPath.enableJarIndex=false` meant true... I can appreciate that and that is a fair point. I guess where I was coming from was that the property is temporary and has to be explicitly specified so ignoring the value seemed worth raising/discussing. Assuming the current check is kept(which we should based on your input), it should probably be changed to ignore case. ------------- PR: https://git.openjdk.java.net/jdk/pull/5524 From rriggs at openjdk.java.net Wed Sep 15 20:18:45 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 15 Sep 2021 20:18:45 GMT Subject: RFR: 8272600: (test) Use native "sleep" in Basic.java [v4] In-Reply-To: <50LQP1Xo_qEDnTLxBtjuD8cYq9bBjo6qXijtrySii38=.2d879836-de4f-4c8e-904a-9bd7fc859fc1@github.com> References: <50LQP1Xo_qEDnTLxBtjuD8cYq9bBjo6qXijtrySii38=.2d879836-de4f-4c8e-904a-9bd7fc859fc1@github.com> Message-ID: On Fri, 3 Sep 2021 14:25:53 GMT, Roger Riggs wrote: >> The intermittent test in java/lang/ProcessBuilder/Basic.java has identified unexpected messages from a child Java VM >> as the cause of the test failure. Attempts to control the output of the child VM have failed, the VM is unrepentant . >> >> There is no functionality in the child except to wait long enough for the test to finish and the child is destroyed. >> The fix is to switch from using a Java child to using a native child; a new executable `sleepmillis`. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Revert to using BasicSleep on Windows > Added diagnostic output for a test that sometimes fails on Linux when using /bin/sleep. > Addressed review comments. Are there any other comments on this, or updated reviews? Passes CI tests Tier1..tier3. ------------- PR: https://git.openjdk.java.net/jdk/pull/5239 From smarks at openjdk.java.net Wed Sep 15 21:50:23 2021 From: smarks at openjdk.java.net (Stuart Marks) Date: Wed, 15 Sep 2021 21:50:23 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v17] In-Reply-To: References: Message-ID: On Wed, 15 Sep 2021 15:59:53 GMT, Roger Riggs wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> - Clarify how overriden Properties#entrySet() method impacts the order of stored properties >> - Tests to verify subclasses of Properties > > src/java.base/share/classes/java/util/Properties.java line 819: > >> 817: *

>> 818: * If the {@systemProperty java.util.Properties.storeDate} is set and >> 819: * is non-empty (as determined by {@link String#isEmpty() String.isEmpty}), > > "is set **on the command line** and non-empty"... > > Following from a comment on the CSR, it should be clear that the property value used can only be set on the command line. This is a clever way to detect whether the `entrySet()` method has been overridden to return something other than the entry-set provided by the Properties class... but I'm wondering if it's too clever. Does anyone who overrides entrySet() care about a specific order, or do they simply sort it in order to get reproducible output? If the latter, then sorting by default hasn't really broken anything. Also, it was never specified that the properties are written based on what's returned by a self-call to `entrySet()`. So this was never guaranteed, though we do want to avoid gratuitous breakage. I would also wager that anybody who overrides entrySet() so that they can control the ordering of the entries is probably breaking the contract of Map::entrySet, which says that it's mutable (a mapping can be removed by removing its entry from the entry-set, or the underlying value can be changed by calling setValue on an entry). This is admittedly pretty obscure, but it tells me that trying to customize the output of Properties::store by overriding entrySet() is a pretty fragile hack. If people really need to control the order of output, they need to iterate the properties themselves instead of overriding entrySet(). I think the only difficulty in doing so is properly escaping the keys and values, as performed by saveConvert(). If this is a use case we want to support, then maybe we should expose a suitable API for escaping properties keys and values. That would be a separate enhancement, though. Note some history in this Stack Overflow question and answers: https://stackoverflow.com/questions/10275862/how-to-sort-properties-in-java Basically they mostly describe overriding `keys()`, but we broke that in Java 9, and now the advice is to override `entrySet()`. But the goal is to sort the properties, which we're doing anyway! ------------- PR: https://git.openjdk.java.net/jdk/pull/5372 From dholmes at openjdk.java.net Wed Sep 15 21:51:02 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 15 Sep 2021 21:51:02 GMT Subject: RFR: 8272600: (test) Use native "sleep" in Basic.java [v4] In-Reply-To: <50LQP1Xo_qEDnTLxBtjuD8cYq9bBjo6qXijtrySii38=.2d879836-de4f-4c8e-904a-9bd7fc859fc1@github.com> References: <50LQP1Xo_qEDnTLxBtjuD8cYq9bBjo6qXijtrySii38=.2d879836-de4f-4c8e-904a-9bd7fc859fc1@github.com> Message-ID: <-e1YhkIyZLuLJkSyNm9-XW1e8WbVApqGZo6JNQQWVC4=.ca60bc95-165c-41e6-ac3c-57b9d053e4f4@github.com> On Fri, 3 Sep 2021 14:25:53 GMT, Roger Riggs wrote: >> The intermittent test in java/lang/ProcessBuilder/Basic.java has identified unexpected messages from a child Java VM >> as the cause of the test failure. Attempts to control the output of the child VM have failed, the VM is unrepentant . >> >> There is no functionality in the child except to wait long enough for the test to finish and the child is destroyed. >> The fix is to switch from using a Java child to using a native child; a new executable `sleepmillis`. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Revert to using BasicSleep on Windows > Added diagnostic output for a test that sometimes fails on Linux when using /bin/sleep. > Addressed review comments. test/jdk/java/lang/ProcessBuilder/Basic.java line 2452: > 2450: > 2451: if (p.waitFor(10, TimeUnit.MILLISECONDS)) { > 2452: System.out.println("WaitFor didn't wait long enough: " + (System.nanoTime() - start)); Either the condition or the message seems wrong here. If waitFor returns true then the process has exited and we obviously did wait long enough. ------------- PR: https://git.openjdk.java.net/jdk/pull/5239 From rriggs at openjdk.java.net Wed Sep 15 22:35:51 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 15 Sep 2021 22:35:51 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v17] In-Reply-To: References: Message-ID: <1989DyckUTFBtfkv7GJHqVhWHH2Y-Vtb1V9fQG3OzmU=.93735b89-0d02-48ce-b518-fb95a86721c4@github.com> On Wed, 15 Sep 2021 21:46:59 GMT, Stuart Marks wrote: >> src/java.base/share/classes/java/util/Properties.java line 819: >> >>> 817: *

>>> 818: * If the {@systemProperty java.util.Properties.storeDate} is set and >>> 819: * is non-empty (as determined by {@link String#isEmpty() String.isEmpty}), >> >> "is set **on the command line** and non-empty"... >> >> Following from a comment on the CSR, it should be clear that the property value used can only be set on the command line. > > This is a clever way to detect whether the `entrySet()` method has been overridden to return something other than the entry-set provided by the Properties class... but I'm wondering if it's too clever. Does anyone who overrides entrySet() care about a specific order, or do they simply sort it in order to get reproducible output? If the latter, then sorting by default hasn't really broken anything. > > Also, it was never specified that the properties are written based on what's returned by a self-call to `entrySet()`. So this was never guaranteed, though we do want to avoid gratuitous breakage. > > I would also wager that anybody who overrides entrySet() so that they can control the ordering of the entries is probably breaking the contract of Map::entrySet, which says that it's mutable (a mapping can be removed by removing its entry from the entry-set, or the underlying value can be changed by calling setValue on an entry). This is admittedly pretty obscure, but it tells me that trying to customize the output of Properties::store by overriding entrySet() is a pretty fragile hack. > > If people really need to control the order of output, they need to iterate the properties themselves instead of overriding entrySet(). I think the only difficulty in doing so is properly escaping the keys and values, as performed by saveConvert(). If this is a use case we want to support, then maybe we should expose a suitable API for escaping properties keys and values. That would be a separate enhancement, though. > > Note some history in this Stack Overflow question and answers: > > https://stackoverflow.com/questions/10275862/how-to-sort-properties-in-java > > Basically they mostly describe overriding `keys()`, but we broke that in Java 9, and now the advice is to override `entrySet()`. But the goal is to sort the properties, which we're doing anyway! One part of what store() does is annoying to replicate, the encoding that `saveConvert` does is non-trivial. Other hacks based on returning a different entrySet might be to filter the set either keep some entries or ignore them. Both unlikely, but hacks are frequently fragile. And we've been very cautious in this discussion to avoid breaking things, in part, because there is so little info about how it is used. ------------- PR: https://git.openjdk.java.net/jdk/pull/5372 From rriggs at openjdk.java.net Wed Sep 15 22:39:51 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 15 Sep 2021 22:39:51 GMT Subject: RFR: 8272600: (test) Use native "sleep" in Basic.java [v4] In-Reply-To: <-e1YhkIyZLuLJkSyNm9-XW1e8WbVApqGZo6JNQQWVC4=.ca60bc95-165c-41e6-ac3c-57b9d053e4f4@github.com> References: <50LQP1Xo_qEDnTLxBtjuD8cYq9bBjo6qXijtrySii38=.2d879836-de4f-4c8e-904a-9bd7fc859fc1@github.com> <-e1YhkIyZLuLJkSyNm9-XW1e8WbVApqGZo6JNQQWVC4=.ca60bc95-165c-41e6-ac3c-57b9d053e4f4@github.com> Message-ID: On Wed, 15 Sep 2021 21:47:39 GMT, David Holmes wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert to using BasicSleep on Windows >> Added diagnostic output for a test that sometimes fails on Linux when using /bin/sleep. >> Addressed review comments. > > test/jdk/java/lang/ProcessBuilder/Basic.java line 2452: > >> 2450: >> 2451: if (p.waitFor(10, TimeUnit.MILLISECONDS)) { >> 2452: System.out.println("WaitFor didn't wait long enough: " + (System.nanoTime() - start)); > > Either the condition or the message seems wrong here. If waitFor returns true then the process has exited and we obviously did wait long enough. This code is diagnostic. After switching to native sleep, I had intermittent failures claiming it did not sleep long enough. I was unable to find a specific cause for those failures. Many of the tests fail to check if the sleep processes terminate prematurely and if the executable is not found, it never launched. ------------- PR: https://git.openjdk.java.net/jdk/pull/5239 From dholmes at openjdk.java.net Wed Sep 15 22:58:52 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 15 Sep 2021 22:58:52 GMT Subject: RFR: 8272600: (test) Use native "sleep" in Basic.java [v4] In-Reply-To: References: <50LQP1Xo_qEDnTLxBtjuD8cYq9bBjo6qXijtrySii38=.2d879836-de4f-4c8e-904a-9bd7fc859fc1@github.com> <-e1YhkIyZLuLJkSyNm9-XW1e8WbVApqGZo6JNQQWVC4=.ca60bc95-165c-41e6-ac3c-57b9d053e4f4@github.com> Message-ID: On Wed, 15 Sep 2021 22:36:14 GMT, Roger Riggs wrote: >> test/jdk/java/lang/ProcessBuilder/Basic.java line 2452: >> >>> 2450: >>> 2451: if (p.waitFor(10, TimeUnit.MILLISECONDS)) { >>> 2452: System.out.println("WaitFor didn't wait long enough: " + (System.nanoTime() - start)); >> >> Either the condition or the message seems wrong here. If waitFor returns true then the process has exited and we obviously did wait long enough. > > This code is diagnostic. > After switching to native sleep, I had intermittent failures claiming it did not sleep long enough. > I was unable to find a specific cause for those failures. > Many of the tests fail to check if the sleep processes terminate prematurely and if the executable is not found, it never launched. Okay but my comment still stands. ------------- PR: https://git.openjdk.java.net/jdk/pull/5239 From mchung at openjdk.java.net Wed Sep 15 23:06:48 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 15 Sep 2021 23:06:48 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v8] In-Reply-To: <5V0eAcrG9rS-d9RnyC2oJ5kVo6v84IhyBn40M71mYUg=.5d8c17fe-a23b-49a8-bfef-f670c0f013eb@github.com> References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> <5V0eAcrG9rS-d9RnyC2oJ5kVo6v84IhyBn40M71mYUg=.5d8c17fe-a23b-49a8-bfef-f670c0f013eb@github.com> Message-ID: On Wed, 1 Sep 2021 01:05:32 GMT, Mandy Chung wrote: >> This reimplements core reflection with method handles. >> >> For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. >> >> The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. >> >> The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. >> >> Ran tier1-tier8 tests. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8013527 >> [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > minor cleanup and more test case. Hi Peter, `VarHandles` are not backed by `LambdaForm`. I did an experiment to change the `FieldAccessor` to use `MethodHandle` instead of `VarHandle` [1] applying on top of your patch. MH customization does help improving the performance. The regression is reduced from 82-85% to 43-52%. Perhaps this is more acceptable and see what @cl4es thinks. baseline Benchmark Mode Cnt Score Error Units ReflectionSpeedBenchmark.instanceFieldConst avgt 10 80.557 ? 0.022 ns/op ReflectionSpeedBenchmark.instanceFieldVar avgt 10 73.698 ? 0.458 ns/op ReflectionSpeedBenchmark.staticFieldConst avgt 10 59.393 ? 0.028 ns/op ReflectionSpeedBenchmark.staticFieldPoly avgt 10 102.994 ? 0.205 ns/op ReflectionSpeedBenchmark.staticFieldVar avgt 10 67.911 ? 0.061 ns/op plevart's patch: Benchmark Mode Cnt Score Error Units ReflectionSpeedBenchmark.instanceFieldConst avgt 10 42.429 ? 0.016 ns/op ReflectionSpeedBenchmark.instanceFieldVar avgt 10 133.405 ? 0.087 ns/op ReflectionSpeedBenchmark.staticFieldConst avgt 10 42.468 ? 0.326 ns/op ReflectionSpeedBenchmark.staticFieldPoly avgt 10 188.546 ? 0.073 ns/op ReflectionSpeedBenchmark.staticFieldVar avgt 10 124.686 ? 0.078 ns/op plevart's patch + vh-mh.patch [1] Benchmark Mode Cnt Score Error Units ReflectionSpeedBenchmark.instanceFieldConst avgt 10 42.402 ? 0.022 ns/op ReflectionSpeedBenchmark.instanceFieldVar avgt 10 105.648 ? 0.047 ns/op ReflectionSpeedBenchmark.staticFieldConst avgt 10 42.437 ? 0.033 ns/op ReflectionSpeedBenchmark.staticFieldPoly avgt 10 178.820 ? 0.292 ns/op ReflectionSpeedBenchmark.staticFieldVar avgt 10 102.676 ? 0.081 ns/op [1] http://cr.openjdk.java.net/~mchung/jep416/vh-mh.patch ------------- PR: https://git.openjdk.java.net/jdk/pull/5027 From ecki at zusammenkunft.net Wed Sep 15 23:12:32 2021 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Wed, 15 Sep 2021 23:12:32 +0000 Subject: RFR: 8272600: (test) Use native "sleep" in Basic.java [v4] In-Reply-To: References: <50LQP1Xo_qEDnTLxBtjuD8cYq9bBjo6qXijtrySii38=.2d879836-de4f-4c8e-904a-9bd7fc859fc1@github.com> <-e1YhkIyZLuLJkSyNm9-XW1e8WbVApqGZo6JNQQWVC4=.ca60bc95-165c-41e6-ac3c-57b9d053e4f4@github.com> Message-ID: The message should probably more along the line of be ?external sleep process terminated unexpected early?. But maybe it is better to actually fail the test when true is returned as it should not happen instead of diag output? (And for diag output the exit code would be more helpful than the time) Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: core-libs-dev im Auftrag von David Holmes Gesendet: Donnerstag, September 16, 2021 1:01 AM An: core-libs-dev at openjdk.java.net Betreff: Re: RFR: 8272600: (test) Use native "sleep" in Basic.java [v4] On Wed, 15 Sep 2021 22:36:14 GMT, Roger Riggs wrote: >> test/jdk/java/lang/ProcessBuilder/Basic.java line 2452: >> >>> 2450: >>> 2451: if (p.waitFor(10, TimeUnit.MILLISECONDS)) { >>> 2452: System.out.println("WaitFor didn't wait long enough: " + (System.nanoTime() - start)); >> >> Either the condition or the message seems wrong here. If waitFor returns true then the process has exited and we obviously did wait long enough. > > This code is diagnostic. > After switching to native sleep, I had intermittent failures claiming it did not sleep long enough. > I was unable to find a specific cause for those failures. > Many of the tests fail to check if the sleep processes terminate prematurely and if the executable is not found, it never launched. Okay but my comment still stands. ------------- PR: https://git.openjdk.java.net/jdk/pull/5239 From github.com+53162078+shiyuexw at openjdk.java.net Thu Sep 16 01:29:12 2021 From: github.com+53162078+shiyuexw at openjdk.java.net (wxiang) Date: Thu, 16 Sep 2021 01:29:12 GMT Subject: RFR: 8273401: Disable JarIndex support in URLClassPath [v2] In-Reply-To: References: Message-ID: <7fXVoIjSmGliERuXW2VgnPMcywMRPv_3lhGL01IMRwI=.5d8e4020-8719-4b23-a303-9f311bbc5961@github.com> > There is a bug for URLClassPath.findResources with JarIndex. > Currently, there was agreement on dropping the support from the URLClassLoader implementation but it was suggested that it should be disabled for a release or two before the code is removed. > A system property can be used to re-enable JarIndex support in URLClassPath. > > The PR includes: > Disable JarIndex support in URLClassPath by default. > Add system property jdk.net.URLClassPath.enableJarIndex to re-enable JarIndex support. wxiang has updated the pull request incrementally with one additional commit since the last revision: add isEmpty check ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5524/files - new: https://git.openjdk.java.net/jdk/pull/5524/files/6a6e7b15..8dd17484 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5524&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5524&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5524.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5524/head:pull/5524 PR: https://git.openjdk.java.net/jdk/pull/5524 From github.com+53162078+shiyuexw at openjdk.java.net Thu Sep 16 01:32:48 2021 From: github.com+53162078+shiyuexw at openjdk.java.net (wxiang) Date: Thu, 16 Sep 2021 01:32:48 GMT Subject: RFR: 8273401: Disable JarIndex support in URLClassPath [v2] In-Reply-To: <7fXVoIjSmGliERuXW2VgnPMcywMRPv_3lhGL01IMRwI=.5d8e4020-8719-4b23-a303-9f311bbc5961@github.com> References: <7fXVoIjSmGliERuXW2VgnPMcywMRPv_3lhGL01IMRwI=.5d8e4020-8719-4b23-a303-9f311bbc5961@github.com> Message-ID: <6AgDFIsZRfYJkh78ZdEGInPHOjeJwvJbHopeuEq79Lc=.2e0d84db-85a1-484f-8da9-090878da6a38@github.com> On Thu, 16 Sep 2021 01:29:12 GMT, wxiang wrote: >> There is a bug for URLClassPath.findResources with JarIndex. >> Currently, there was agreement on dropping the support from the URLClassLoader implementation but it was suggested that it should be disabled for a release or two before the code is removed. >> A system property can be used to re-enable JarIndex support in URLClassPath. >> >> The PR includes: >> Disable JarIndex support in URLClassPath by default. >> Add system property jdk.net.URLClassPath.enableJarIndex to re-enable JarIndex support. > > wxiang has updated the pull request incrementally with one additional commit since the last revision: > > add isEmpty check I have changed ENABLE_JAR_INDEX = p != null ? p.equals("true") : false; to ENABLE_JAR_INDEX = p != null ? p.equals("true") || p.isEmpty() : false; Furthemore, in order to maintain consistency in URLClassPath, the property name is "jdk.net.URLClassPath.enableJarIndex" . ------------- PR: https://git.openjdk.java.net/jdk/pull/5524 From jai.forums2013 at gmail.com Thu Sep 16 01:58:48 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Thu, 16 Sep 2021 07:28:48 +0530 Subject: RFR: 8231640: (prop) Canonical property storage [v17] In-Reply-To: <4DMbKbYojvlPFMpMJKJx4Hp-E140T07nia8zpU_KcRo=.c725f3ff-dd42-4c0e-b16b-8f67613e6c2b@github.com> References: <4DMbKbYojvlPFMpMJKJx4Hp-E140T07nia8zpU_KcRo=.c725f3ff-dd42-4c0e-b16b-8f67613e6c2b@github.com> Message-ID: <50b0ff9d-5359-103d-b098-fc19734e113d@gmail.com> On 15/09/21 9:48 pm, Daniel Fuchs wrote: > On Wed, 15 Sep 2021 15:31:45 GMT, Roger Riggs wrote: > >>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >>> >>> - Clarify how overriden Properties#entrySet() method impacts the order of stored properties >>> - Tests to verify subclasses of Properties >> src/java.base/share/classes/java/util/Properties.java line 850: >> >>> 848: * the {@code entrySet} method and return a different {@code Set} instance, >>> 849: * then the property list is written out in the iteration order of >>> 850: * that returned {@code Set} >> Rewording a bit: >> >> "The keys and elements are written in the natural sort order of the keys in the `Properties.entrySet` unless `entrySet` is overridden by a subclass to return a different instance." >> >> "different instance" is a bit hard to implement given that entrySet() returns a new synchronized set each time. >> typo: missing final "." > yes - maybe we could work on the wording. Perhaps: >> The keys and elements are written in the natural sort order of the keys in the Properties.entrySet unless entrySet is overridden by a subclass to return a different set implementation. > Daniel is right - my initial wording wasn't accurate and I couldn't find a better term to express what I meant. Like Daniel notes above, I was actually talking about using the private EntrySet implementation that the Properties class uses to find out if some subclass overrode the entrySet() method. I think Daniel's rewording of that javadoc section above to state "different set implementation" is much more accurate than my initial wording. -Jaikiran From github.com+22913521+1996scarlet at openjdk.java.net Thu Sep 16 03:25:32 2021 From: github.com+22913521+1996scarlet at openjdk.java.net (Remilia Scarlet) Date: Thu, 16 Sep 2021 03:25:32 GMT Subject: RFR: 8273774: jdk.tools.jlink.internal.Platform::is64Bit() should not hard code for x64 and AARCH64 [v2] In-Reply-To: <6UsB0ppKiipNg3JnMjcHSvKCIpFKnRSaii_BO_OAZlo=.1a501d24-2cb1-4f66-8c44-dfa570a89aad@github.com> References: <6UsB0ppKiipNg3JnMjcHSvKCIpFKnRSaii_BO_OAZlo=.1a501d24-2cb1-4f66-8c44-dfa570a89aad@github.com> Message-ID: <9sM3gU5DwVoMcOXFR6A1lDqksIbZMLDoSnQVToe8cR0=.0ced4c4c-b6e5-4c63-9190-b7b768c2ece1@github.com> > Currently, the Platform.is64Bit() hard coded for judging whether the target arch is 64-bit. > The `classes_nocoops.jsa not found` issue can be found while testing CDSPluginTest.java on 64-bit platform, excluding x64 and AARCH64, like mips64. > > For solving this issue, we assume that the bits of target UNKNOWN arch is same as the runtime platform. > This patch adds the following lines in the Platform.is64Bit() method. > > ``` java > if (arch() == Platform.Architecture.UNKNOWN) { > return (System.getProperty("os.arch").indexOf("64") != -1); > } > > > Please review this change. Thanks! Remilia Scarlet 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 two additional commits since the last revision: - Merge branch 'openjdk:master' into JDK-8273774 - 8273774: jdk.tools.jlink.internal.Platform::is64Bit() should not hard code for x64 and AARCH64 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5519/files - new: https://git.openjdk.java.net/jdk/pull/5519/files/d51678ac..125c83e7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5519&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5519&range=00-01 Stats: 364 lines in 45 files changed: 198 ins; 52 del; 114 mod Patch: https://git.openjdk.java.net/jdk/pull/5519.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5519/head:pull/5519 PR: https://git.openjdk.java.net/jdk/pull/5519 From github.com+22913521+1996scarlet at openjdk.java.net Thu Sep 16 03:44:24 2021 From: github.com+22913521+1996scarlet at openjdk.java.net (Remilia Scarlet) Date: Thu, 16 Sep 2021 03:44:24 GMT Subject: RFR: 8273774: CDSPluginTest should only expect classes_nocoops.jsa exists on supported 64-bit platforms [v3] In-Reply-To: <6UsB0ppKiipNg3JnMjcHSvKCIpFKnRSaii_BO_OAZlo=.1a501d24-2cb1-4f66-8c44-dfa570a89aad@github.com> References: <6UsB0ppKiipNg3JnMjcHSvKCIpFKnRSaii_BO_OAZlo=.1a501d24-2cb1-4f66-8c44-dfa570a89aad@github.com> Message-ID: > Currently, the Platform.is64Bit() hard coded for judging whether the target arch is 64-bit. > The `classes_nocoops.jsa not found` issue can be found while testing CDSPluginTest.java on 64-bit platform, excluding x64 and AARCH64, like mips64. > > For solving this issue, we assume that the bits of target UNKNOWN arch is same as the runtime platform. > This patch adds the following lines in the Platform.is64Bit() method. > > ``` java > if (arch() == Platform.Architecture.UNKNOWN) { > return (System.getProperty("os.arch").indexOf("64") != -1); > } > > > Please review this change. Thanks! Remilia Scarlet has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8273774: CDSPluginTest should only expect classes_nocoops.jsa exists on supported 64-bit platforms ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5519/files - new: https://git.openjdk.java.net/jdk/pull/5519/files/125c83e7..5ec04d45 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5519&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5519&range=01-02 Stats: 12 lines in 2 files changed: 6 ins; 4 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5519.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5519/head:pull/5519 PR: https://git.openjdk.java.net/jdk/pull/5519 From jpai at openjdk.java.net Thu Sep 16 03:51:41 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Thu, 16 Sep 2021 03:51:41 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v18] In-Reply-To: References: Message-ID: > The commit in this PR implements the proposal for enhancement that was discussed in the core-libs-dev mailing list recently[1], for https://bugs.openjdk.java.net/browse/JDK-8231640 > > At a high level - the `store()` APIs in `Properties` have been modified to now look for the `SOURCE_DATE_EPOCH` environment variable[2]. If that env variable is set, then instead of writing out the current date time as a date comment, the `store()` APIs instead will use the value set for this env variable to parse it to a `Date` and write out the string form of such a date. The implementation here uses the `d MMM yyyy HH:mm:ss 'GMT'` date format and `Locale.ROOT` to format and write out such a date. This should provide reproducibility whenever the `SOURCE_DATE_EPOCH` is set. Furthermore, intentionally, no changes in the date format of the "current date" have been done. > > These modified `store()` APIs work in the presence of the `SecurityManager` too. The caller is expected to have a read permission on the `SOURCE_DATE_EPOCH` environment variable. If the caller doesn't have that permission, then the implementation of these `store()` APIs will write out the "current date" and will ignore any value that has been set for the `SOURCE_DATE_EPOCH` env variable. This should allow for backward compatibility of existing applications, where, when they run under a `SecurityManager` and perhaps with an existing restrictive policy file, the presence of `SOURCE_DATE_EPOCH` shouldn't impact their calls to the `store()` APIs. > > The modified `store()` APIs will also ignore any value for `SOURCE_DATE_EPOCH` that cannot be parsed to an `long` value. In such cases, the `store()` APIs will write out the "current date" and ignore the value set for this environment variable. No exceptions will be thrown for such invalid values. This is an additional backward compatibility precaution to prevent any rogue value for `SOURCE_DATE_EPOCH` from breaking applications. > > An additional change in the implementation of these `store()` APIs and unrelated to the date comment, is that these APIs will now write out the property keys in a deterministic order. The keys will be written out in the natural ordering as specified by `java.lang.String#compareTo()` API. > > The combination of the ordering of the property keys when written out and the usage of `SOURCE_DATE_EPOCH` environment value to determine the date comment should together allow for reproducibility of the output generated by these `store()` APIs. > > New jtreg test classes have been introduced to verify these changes. The primary focus of `PropertiesStoreTest` is the ordering aspects of the property keys that are written out. On the other hand `StoreReproducibilityTest` focuses on the reproducibility of the output generated by these APIs. The `StoreReproducibilityTest` runs these tests both in the presence and absence of `SecurityManager`. Plus, in the presence of SecurityManager, it tests both the scenarios where the caller is granted the requisite permission and in other case not granted that permission. > > These new tests and existing tests under `test/jdk/java/util/Properties/` pass with these changes. > > [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-August/080758.html > [2] https://reproducible-builds.org/specs/source-date-epoch/ Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: (Only doc/comment changes): - Implement Roger's suggestion to explicitly state that the system property should be set on command line - Change @implNote to @implSpec based on inputs being provided on CSR issue - Use Roger's and Daniel's suggestions to reword the @implSpec text to explain how overridding of entrySet() can impact the order of the written out properties - Improve the internal code comment (meant for maintainers) to be more clear on what kind of check we are doing before deciding the order of properties to write ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5372/files - new: https://git.openjdk.java.net/jdk/pull/5372/files/79d10527..e2effb96 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5372&range=17 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5372&range=16-17 Stats: 12 lines in 1 file changed: 1 ins; 3 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/5372.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5372/head:pull/5372 PR: https://git.openjdk.java.net/jdk/pull/5372 From iklam at openjdk.java.net Thu Sep 16 04:42:54 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 16 Sep 2021 04:42:54 GMT Subject: RFR: 8272600: (test) Use native "sleep" in Basic.java [v4] In-Reply-To: <50LQP1Xo_qEDnTLxBtjuD8cYq9bBjo6qXijtrySii38=.2d879836-de4f-4c8e-904a-9bd7fc859fc1@github.com> References: <50LQP1Xo_qEDnTLxBtjuD8cYq9bBjo6qXijtrySii38=.2d879836-de4f-4c8e-904a-9bd7fc859fc1@github.com> Message-ID: <7CrluRtaKHRB0qsnUFoIVH2S3HGfyK-r2YvMfwdkJNc=.732c3cee-6280-4d81-a06e-0fb78557d7b6@github.com> On Fri, 3 Sep 2021 14:25:53 GMT, Roger Riggs wrote: >> The intermittent test in java/lang/ProcessBuilder/Basic.java has identified unexpected messages from a child Java VM >> as the cause of the test failure. Attempts to control the output of the child VM have failed, the VM is unrepentant . >> >> There is no functionality in the child except to wait long enough for the test to finish and the child is destroyed. >> The fix is to switch from using a Java child to using a native child; a new executable `sleepmillis`. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Revert to using BasicSleep on Windows > Added diagnostic output for a test that sometimes fails on Linux when using /bin/sleep. > Addressed review comments. Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5239 From mbaesken at openjdk.java.net Thu Sep 16 07:11:49 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Thu, 16 Sep 2021 07:11:49 GMT Subject: Integrated: JDK-8273526: Extend the OSContainer API pids controller with pids.current In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 09:21:59 GMT, Matthias Baesken wrote: > https://bugs.openjdk.java.net/browse/JDK-8266490 > extended the OSContainer API in order to also support the pids controller of cgroups. However only pids.max output was added with 8266490. > There is a second parameter pids.current , see https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#pid > that would be helpful too and can be added to the OSContainer API . > pids.current : > A read-only single value file which exists on all cgroups. > The number of processes currently in the cgroup and its descendants. > > Best regards, Matthias This pull request has now been integrated. Changeset: d4546b6b Author: Matthias Baesken URL: https://git.openjdk.java.net/jdk/commit/d4546b6b36f9dc9ff3d626f8cfe62b62daa0de01 Stats: 88 lines in 14 files changed: 85 ins; 0 del; 3 mod 8273526: Extend the OSContainer API pids controller with pids.current Reviewed-by: sgehwolf, iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/5437 From plevart at openjdk.java.net Thu Sep 16 07:12:53 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Thu, 16 Sep 2021 07:12:53 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v8] In-Reply-To: <5V0eAcrG9rS-d9RnyC2oJ5kVo6v84IhyBn40M71mYUg=.5d8c17fe-a23b-49a8-bfef-f670c0f013eb@github.com> References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> <5V0eAcrG9rS-d9RnyC2oJ5kVo6v84IhyBn40M71mYUg=.5d8c17fe-a23b-49a8-bfef-f670c0f013eb@github.com> Message-ID: On Wed, 1 Sep 2021 01:05:32 GMT, Mandy Chung wrote: >> This reimplements core reflection with method handles. >> >> For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. >> >> The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. >> >> The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. >> >> Ran tier1-tier8 tests. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8013527 >> [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > minor cleanup and more test case. Hi Mandy, Yes, you had exactly the same thoughts as me! So this improves the "Var" case for fields. I also ran tests on my PC with your vh-mh patch on top and here are visualized results (combined with previous results): jdk18+9 vs. mandy: https://jmh.morethan.io/?gists=7b2399cea71d12dfd3434701ddeed026,80203847700b9ab8baeb346a02efc804 jdk18+9 vs. peter: https://jmh.morethan.io/?gists=7b2399cea71d12dfd3434701ddeed026,b11842fbd48ebbd9234251fded50d52e jdk18+9 vs. peter+vh2mh: https://jmh.morethan.io/?gists=7b2399cea71d12dfd3434701ddeed026,2a61a99909415f9e0ab53b125628b11d mandy vs. peter: https://jmh.morethan.io/?gists=80203847700b9ab8baeb346a02efc804,b11842fbd48ebbd9234251fded50d52e mandy vs. peter+vh2mh: https://jmh.morethan.io/?gists=80203847700b9ab8baeb346a02efc804,2a61a99909415f9e0ab53b125628b11d peter vs. peter+vh2mh: https://jmh.morethan.io/?gists=b11842fbd48ebbd9234251fded50d52e,2a61a99909415f9e0ab53b125628b11d ------------- PR: https://git.openjdk.java.net/jdk/pull/5027 From plevart at openjdk.java.net Thu Sep 16 07:40:47 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Thu, 16 Sep 2021 07:40:47 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v8] In-Reply-To: <5V0eAcrG9rS-d9RnyC2oJ5kVo6v84IhyBn40M71mYUg=.5d8c17fe-a23b-49a8-bfef-f670c0f013eb@github.com> References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> <5V0eAcrG9rS-d9RnyC2oJ5kVo6v84IhyBn40M71mYUg=.5d8c17fe-a23b-49a8-bfef-f670c0f013eb@github.com> Message-ID: On Wed, 1 Sep 2021 01:05:32 GMT, Mandy Chung wrote: >> This reimplements core reflection with method handles. >> >> For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. >> >> The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. >> >> The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. >> >> Ran tier1-tier8 tests. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8013527 >> [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > minor cleanup and more test case. My opinion is that "Const" and "Poly" are the use cases that matter and "Var" is really very minor case. Unfortunately the "Poly" case for fields has regression comparing to Unsafe accessors in all our patches. The least regression (35%) has peter+vh2mh which also has the best improvement in "Const" use cases for fields and methods (16...45%). I can prepare a real-world test case (JSON serialization framework Jackson for example) to compare results using such benchmark. WDYT? ------------- PR: https://git.openjdk.java.net/jdk/pull/5027 From shade at openjdk.java.net Thu Sep 16 07:54:51 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 16 Sep 2021 07:54:51 GMT Subject: RFR: 8273803: Zero: Handle "zero" variant in CommandLineOptionTest.java In-Reply-To: References: Message-ID: On Wed, 15 Sep 2021 10:16:36 GMT, Aleksey Shipilev wrote: > This currently manifests if you run Zero with compiler/codecache/cli tests (part of tier1): > > > $ CONF=linux-x86_64-zero-fastdebug make exploded-test TEST=compiler/codecache/cli/ > > STDERR: > java.lang.RuntimeException: Unknown VM mode. > at jdk.test.lib.cli.CommandLineOptionTest.getVMTypeOption(CommandLineOptionTest.java:504) > at jdk.test.lib.cli.CommandLineOptionTest.verifyOptionValueForSameVM(CommandLineOptionTest.java:397) > at compiler.codecache.cli.codeheapsize.GenericCodeHeapSizeRunner.run(GenericCodeHeapSizeRunner.java:42) > at compiler.codecache.cli.common.CodeCacheCLITestCase.run(CodeCacheCLITestCase.java:62) > at compiler.codecache.cli.common.CodeCacheCLITestBase.runTestCases(CodeCacheCLITestBase.java:58) > at compiler.codecache.cli.codeheapsize.TestCodeHeapSizeOptions.main(TestCodeHeapSizeOptions.java:86) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:568) > at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312) > at java.base/java.lang.Thread.run(Thread.java:833) > > > While these tests are compiler tests, and they should arguably never run with Zero, the problem is in shared code, which can be used in future by other non-compiler tests. > > Additional testing: > - [x] Affected compiler tests now "properly" fail with "no compilers" errors Thank you! ------------- PR: https://git.openjdk.java.net/jdk/pull/5527 From shade at openjdk.java.net Thu Sep 16 07:54:52 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 16 Sep 2021 07:54:52 GMT Subject: Integrated: 8273803: Zero: Handle "zero" variant in CommandLineOptionTest.java In-Reply-To: References: Message-ID: On Wed, 15 Sep 2021 10:16:36 GMT, Aleksey Shipilev wrote: > This currently manifests if you run Zero with compiler/codecache/cli tests (part of tier1): > > > $ CONF=linux-x86_64-zero-fastdebug make exploded-test TEST=compiler/codecache/cli/ > > STDERR: > java.lang.RuntimeException: Unknown VM mode. > at jdk.test.lib.cli.CommandLineOptionTest.getVMTypeOption(CommandLineOptionTest.java:504) > at jdk.test.lib.cli.CommandLineOptionTest.verifyOptionValueForSameVM(CommandLineOptionTest.java:397) > at compiler.codecache.cli.codeheapsize.GenericCodeHeapSizeRunner.run(GenericCodeHeapSizeRunner.java:42) > at compiler.codecache.cli.common.CodeCacheCLITestCase.run(CodeCacheCLITestCase.java:62) > at compiler.codecache.cli.common.CodeCacheCLITestBase.runTestCases(CodeCacheCLITestBase.java:58) > at compiler.codecache.cli.codeheapsize.TestCodeHeapSizeOptions.main(TestCodeHeapSizeOptions.java:86) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:568) > at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312) > at java.base/java.lang.Thread.run(Thread.java:833) > > > While these tests are compiler tests, and they should arguably never run with Zero, the problem is in shared code, which can be used in future by other non-compiler tests. > > Additional testing: > - [x] Affected compiler tests now "properly" fail with "no compilers" errors This pull request has now been integrated. Changeset: 2d13fb21 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/2d13fb21af783ebbe3dd5c2632aea11347317026 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8273803: Zero: Handle "zero" variant in CommandLineOptionTest.java Reviewed-by: dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/5527 From shade at openjdk.java.net Thu Sep 16 07:56:50 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 16 Sep 2021 07:56:50 GMT Subject: Integrated: 8273804: Platform.isTieredSupported should handle the no-compiler case In-Reply-To: References: Message-ID: On Wed, 15 Sep 2021 10:29:36 GMT, Aleksey Shipilev wrote: > Happens with Zero tests: > > > $ CONF=linux-x86_64-zero-fastdebug make exploded-test TEST=compiler/codecache/CheckSegmentedCodeCache.java > ... > > java.lang.NullPointerException: Cannot invoke "String.contains(java.lang.CharSequence)" because "jdk.test.lib.Platform.compiler" is null > at jdk.test.lib.Platform.isTieredSupported(Platform.java:82) > at compiler.codecache.CheckSegmentedCodeCache.verifySegmentedCodeCache(CheckSegmentedCodeCache.java:61) > at compiler.codecache.CheckSegmentedCodeCache.main(CheckSegmentedCodeCache.java:108) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:568) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:833) > > > Additional testing: > - [x] Linux x86_64 Zero, `compiler/codecache/CheckSegmentedCodeCache.java` now properly fails with "no compilers" error This pull request has now been integrated. Changeset: 46af82e5 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/46af82e5b0d176e340f46125f8a3bb17e56bd7b3 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8273804: Platform.isTieredSupported should handle the no-compiler case Reviewed-by: dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/5528 From shade at openjdk.java.net Thu Sep 16 07:56:50 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 16 Sep 2021 07:56:50 GMT Subject: RFR: 8273804: Platform.isTieredSupported should handle the no-compiler case In-Reply-To: References: Message-ID: On Wed, 15 Sep 2021 10:29:36 GMT, Aleksey Shipilev wrote: > Happens with Zero tests: > > > $ CONF=linux-x86_64-zero-fastdebug make exploded-test TEST=compiler/codecache/CheckSegmentedCodeCache.java > ... > > java.lang.NullPointerException: Cannot invoke "String.contains(java.lang.CharSequence)" because "jdk.test.lib.Platform.compiler" is null > at jdk.test.lib.Platform.isTieredSupported(Platform.java:82) > at compiler.codecache.CheckSegmentedCodeCache.verifySegmentedCodeCache(CheckSegmentedCodeCache.java:61) > at compiler.codecache.CheckSegmentedCodeCache.main(CheckSegmentedCodeCache.java:108) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:568) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:833) > > > Additional testing: > - [x] Linux x86_64 Zero, `compiler/codecache/CheckSegmentedCodeCache.java` now properly fails with "no compilers" error Thank you! ------------- PR: https://git.openjdk.java.net/jdk/pull/5528 From dfuchs at openjdk.java.net Thu Sep 16 09:18:51 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 16 Sep 2021 09:18:51 GMT Subject: RFR: 8273401: Disable JarIndex support in URLClassPath [v2] In-Reply-To: <7fXVoIjSmGliERuXW2VgnPMcywMRPv_3lhGL01IMRwI=.5d8e4020-8719-4b23-a303-9f311bbc5961@github.com> References: <7fXVoIjSmGliERuXW2VgnPMcywMRPv_3lhGL01IMRwI=.5d8e4020-8719-4b23-a303-9f311bbc5961@github.com> Message-ID: On Thu, 16 Sep 2021 01:29:12 GMT, wxiang wrote: >> There is a bug for URLClassPath.findResources with JarIndex. >> Currently, there was agreement on dropping the support from the URLClassLoader implementation but it was suggested that it should be disabled for a release or two before the code is removed. >> A system property can be used to re-enable JarIndex support in URLClassPath. >> >> The PR includes: >> Disable JarIndex support in URLClassPath by default. >> Add system property jdk.net.URLClassPath.enableJarIndex to re-enable JarIndex support. > > wxiang has updated the pull request incrementally with one additional commit since the last revision: > > add isEmpty check Marked as reviewed by dfuchs (Reviewer). Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5524 From dfuchs at openjdk.java.net Thu Sep 16 09:18:51 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 16 Sep 2021 09:18:51 GMT Subject: RFR: 8273401: Disable JarIndex support in URLClassPath [v2] In-Reply-To: References: <79mwmCOeq_RDHak_jDzMBjAOeCh2onSYpFP3Xe172X8=.1b22b372-d1dd-499c-b2eb-f4360ef18fbb@github.com> Message-ID: On Wed, 15 Sep 2021 19:41:11 GMT, Lance Andersen wrote: >> I would dislike it if `-Djdk.net.URLClassPath.enableJarIndex=false` meant true... > > I can appreciate that and that is a fair point. I guess where I was coming from was that the property is temporary and has to be explicitly specified so ignoring the value seemed worth raising/discussing. > > Assuming the current check is kept(which we should based on your input), it should probably be changed to ignore case. Given that there is a precedence in this file: p = props.getProperty("jdk.net.URLClassPath.showIgnoredClassPathEntries"); DEBUG_CP_URL_CHECK = p != null ? p.equals("true") || p.isEmpty() : false; I would tend to let the new property follow the same pattern, especially since it's temporary. ------------- PR: https://git.openjdk.java.net/jdk/pull/5524 From shade at openjdk.java.net Thu Sep 16 09:49:57 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 16 Sep 2021 09:49:57 GMT Subject: RFR: 8236505: Mark jdk/editpad/EditPadTest.java as @headful Message-ID: <_j9LK9SIRBmy-CCoe-OTa5bpqiVYbHUaeTolbqjAcAA=.81c737bb-e4cf-4445-bc3a-28590aeed95b@github.com> This is a GUI test, and it should be `@headful`. Additional testing: - [x] Test still runs in default, and does not run with `!headful` ------------- Commit messages: - Fix Changes: https://git.openjdk.java.net/jdk/pull/5544/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5544&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8236505 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5544.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5544/head:pull/5544 PR: https://git.openjdk.java.net/jdk/pull/5544 From jlahoda at openjdk.java.net Thu Sep 16 09:49:58 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 16 Sep 2021 09:49:58 GMT Subject: RFR: 8236505: Mark jdk/editpad/EditPadTest.java as @headful In-Reply-To: <_j9LK9SIRBmy-CCoe-OTa5bpqiVYbHUaeTolbqjAcAA=.81c737bb-e4cf-4445-bc3a-28590aeed95b@github.com> References: <_j9LK9SIRBmy-CCoe-OTa5bpqiVYbHUaeTolbqjAcAA=.81c737bb-e4cf-4445-bc3a-28590aeed95b@github.com> Message-ID: On Thu, 16 Sep 2021 09:13:15 GMT, Aleksey Shipilev wrote: > This is a GUI test, and it should be `@headful`. > > Additional testing: > - [x] Test still runs in default, and does not run with `!headful` Marking the test headful if OK - but should `headful` also be added to the keys in `test/langtools/TEST.ROOT`? (I am not quite sure how that works.) Ah, right, I thought it is a JShell test, but it is not. Sorry for the noise. ------------- PR: https://git.openjdk.java.net/jdk/pull/5544 From shade at openjdk.java.net Thu Sep 16 09:49:58 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 16 Sep 2021 09:49:58 GMT Subject: RFR: 8236505: Mark jdk/editpad/EditPadTest.java as @headful In-Reply-To: References: <_j9LK9SIRBmy-CCoe-OTa5bpqiVYbHUaeTolbqjAcAA=.81c737bb-e4cf-4445-bc3a-28590aeed95b@github.com> Message-ID: On Thu, 16 Sep 2021 09:39:25 GMT, Jan Lahoda wrote: > Marking the test headful if OK - but should `headful` also be added to the keys in `test/langtools/TEST.ROOT`? (I am not quite sure how that works.) AFAICS, this test is in `jdk`, so it is covered by `jdk/TEST.ROOT`. I tested it with and without `JTREG_KEYWORDS=!headful`, and it behaves as expected. ------------- PR: https://git.openjdk.java.net/jdk/pull/5544 From plevart at openjdk.java.net Thu Sep 16 09:37:00 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Thu, 16 Sep 2021 09:37:00 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v8] In-Reply-To: <5V0eAcrG9rS-d9RnyC2oJ5kVo6v84IhyBn40M71mYUg=.5d8c17fe-a23b-49a8-bfef-f670c0f013eb@github.com> References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> <5V0eAcrG9rS-d9RnyC2oJ5kVo6v84IhyBn40M71mYUg=.5d8c17fe-a23b-49a8-bfef-f670c0f013eb@github.com> Message-ID: On Wed, 1 Sep 2021 01:05:32 GMT, Mandy Chung wrote: >> This reimplements core reflection with method handles. >> >> For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. >> >> The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. >> >> The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. >> >> Ran tier1-tier8 tests. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8013527 >> [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > minor cleanup and more test case. So here's a benchmark that measures the impact on a real-world use case - the Jackson (de)serialization: https://gist.github.com/plevart/3cdc7c366d03822c915a7b3ccd579421 Visualized comparisons: jdk18+9 vs. mandy: https://jmh.morethan.io/?gists=f81f8e67ec74c3a5c8110a60ddbf38d7,e41df754bfb07df65714b113f7ed08f3 jdk18+9 vs. peter+vh2mh: https://jmh.morethan.io/?gists=f81f8e67ec74c3a5c8110a60ddbf38d7,9bf7e119ffb859e498772f47ba68c709 mandy vs. peter+vh2mh: https://jmh.morethan.io/?gists=e41df754bfb07df65714b113f7ed08f3,9bf7e119ffb859e498772f47ba68c709 Not so much of an impact on a real-world case as artificial benchmarks. ------------- PR: https://git.openjdk.java.net/jdk/pull/5027 From github.com+53162078+shiyuexw at openjdk.java.net Thu Sep 16 09:37:00 2021 From: github.com+53162078+shiyuexw at openjdk.java.net (wxiang) Date: Thu, 16 Sep 2021 09:37:00 GMT Subject: RFR: 8273401: Disable JarIndex support in URLClassPath [v2] In-Reply-To: References: <79mwmCOeq_RDHak_jDzMBjAOeCh2onSYpFP3Xe172X8=.1b22b372-d1dd-499c-b2eb-f4360ef18fbb@github.com> Message-ID: On Thu, 16 Sep 2021 09:15:34 GMT, Daniel Fuchs wrote: >> I can appreciate that and that is a fair point. I guess where I was coming from was that the property is temporary and has to be explicitly specified so ignoring the value seemed worth raising/discussing. >> >> Assuming the current check is kept(which we should based on your input), it should probably be changed to ignore case. > > Given that there is a precedence in this file: > > > p = props.getProperty("jdk.net.URLClassPath.showIgnoredClassPathEntries"); > DEBUG_CP_URL_CHECK = p != null ? p.equals("true") || p.isEmpty() : false; > > > I would tend to let the new property follow the same pattern, especially since it's temporary. Yes?I changed the code to follow the same pattern. ------------- PR: https://git.openjdk.java.net/jdk/pull/5524 From jboes at openjdk.java.net Thu Sep 16 10:14:47 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Thu, 16 Sep 2021 10:14:47 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v3] In-Reply-To: References: Message-ID: > This change implements a simple web server that can be run on the command-line with `java -m jdk.httpserver`. > > This is facilitated by adding an entry point for the `jdk.httpserver` module, an implementation class whose main method is run when the above command is executed. This is the first such module entry point in the JDK. > > The server is a minimal HTTP server that serves the static files of a given directory, similar to existing alternatives on other platforms and convenient for testing, development, and debugging. > > Additionally, a small API is introduced for programmatic creation and customization. > > Testing: tier1-3. Julia Boes has updated the pull request incrementally with one additional commit since the last revision: correct path handling ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5505/files - new: https://git.openjdk.java.net/jdk/pull/5505/files/f53c59d9..3084130a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5505&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5505&range=01-02 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5505.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5505/head:pull/5505 PR: https://git.openjdk.java.net/jdk/pull/5505 From lancea at openjdk.java.net Thu Sep 16 10:20:50 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 16 Sep 2021 10:20:50 GMT Subject: RFR: 8273401: Disable JarIndex support in URLClassPath [v2] In-Reply-To: <7fXVoIjSmGliERuXW2VgnPMcywMRPv_3lhGL01IMRwI=.5d8e4020-8719-4b23-a303-9f311bbc5961@github.com> References: <7fXVoIjSmGliERuXW2VgnPMcywMRPv_3lhGL01IMRwI=.5d8e4020-8719-4b23-a303-9f311bbc5961@github.com> Message-ID: On Thu, 16 Sep 2021 01:29:12 GMT, wxiang wrote: >> There is a bug for URLClassPath.findResources with JarIndex. >> Currently, there was agreement on dropping the support from the URLClassLoader implementation but it was suggested that it should be disabled for a release or two before the code is removed. >> A system property can be used to re-enable JarIndex support in URLClassPath. >> >> The PR includes: >> Disable JarIndex support in URLClassPath by default. >> Add system property jdk.net.URLClassPath.enableJarIndex to re-enable JarIndex support. > > wxiang has updated the pull request incrementally with one additional commit since the last revision: > > add isEmpty check Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5524 From lancea at openjdk.java.net Thu Sep 16 10:20:50 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 16 Sep 2021 10:20:50 GMT Subject: RFR: 8273401: Disable JarIndex support in URLClassPath [v2] In-Reply-To: References: <79mwmCOeq_RDHak_jDzMBjAOeCh2onSYpFP3Xe172X8=.1b22b372-d1dd-499c-b2eb-f4360ef18fbb@github.com> Message-ID: On Thu, 16 Sep 2021 09:33:44 GMT, wxiang wrote: >> Given that there is a precedence in this file: >> >> >> p = props.getProperty("jdk.net.URLClassPath.showIgnoredClassPathEntries"); >> DEBUG_CP_URL_CHECK = p != null ? p.equals("true") || p.isEmpty() : false; >> >> >> I would tend to let the new property follow the same pattern, especially since it's temporary. > > Yes?I changed the code to follow the same pattern. > Given that there is a precedence in this file: > > ``` > p = props.getProperty("jdk.net.URLClassPath.showIgnoredClassPathEntries"); > DEBUG_CP_URL_CHECK = p != null ? p.equals("true") || p.isEmpty() : false; > ``` > > I would tend to let the new property follow the same pattern, especially since it's temporary. fair enough :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/5524 From alanb at openjdk.java.net Thu Sep 16 11:11:49 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 16 Sep 2021 11:11:49 GMT Subject: RFR: 8273401: Disable JarIndex support in URLClassPath [v2] In-Reply-To: <7fXVoIjSmGliERuXW2VgnPMcywMRPv_3lhGL01IMRwI=.5d8e4020-8719-4b23-a303-9f311bbc5961@github.com> References: <7fXVoIjSmGliERuXW2VgnPMcywMRPv_3lhGL01IMRwI=.5d8e4020-8719-4b23-a303-9f311bbc5961@github.com> Message-ID: <0dB9Kuj9GxaOwYKqueZfLjf8T5i40BlvN2z1D3w2AIM=.89202971-3e86-4370-a347-15a60746aec8@github.com> On Thu, 16 Sep 2021 01:29:12 GMT, wxiang wrote: >> There is a bug for URLClassPath.findResources with JarIndex. >> Currently, there was agreement on dropping the support from the URLClassLoader implementation but it was suggested that it should be disabled for a release or two before the code is removed. >> A system property can be used to re-enable JarIndex support in URLClassPath. >> >> The PR includes: >> Disable JarIndex support in URLClassPath by default. >> Add system property jdk.net.URLClassPath.enableJarIndex to re-enable JarIndex support. > > wxiang has updated the pull request incrementally with one additional commit since the last revision: > > add isEmpty check src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 949: > 947: return checkResource(name, check, entry); > 948: > 949: if (index == null || !ENABLE_JAR_INDEX) Is this needed? When ENABLE_JAR_INDEX is false then I assume index will always be null. I'm only asking is that it would be nice if ENABLE_JAR_INDEX was checked in one place rather than two. ------------- PR: https://git.openjdk.java.net/jdk/pull/5524 From jpai at openjdk.java.net Thu Sep 16 12:06:50 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Thu, 16 Sep 2021 12:06:50 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v17] In-Reply-To: <1989DyckUTFBtfkv7GJHqVhWHH2Y-Vtb1V9fQG3OzmU=.93735b89-0d02-48ce-b518-fb95a86721c4@github.com> References: <1989DyckUTFBtfkv7GJHqVhWHH2Y-Vtb1V9fQG3OzmU=.93735b89-0d02-48ce-b518-fb95a86721c4@github.com> Message-ID: <2P_1y7ZEdlZc9bTVyGNIX64FrWvz7I9RhjD1hztjjFU=.64afd709-76b4-47d8-aee2-61eed72fb448@github.com> On Wed, 15 Sep 2021 22:32:33 GMT, Roger Riggs wrote: >> This is a clever way to detect whether the `entrySet()` method has been overridden to return something other than the entry-set provided by the Properties class... but I'm wondering if it's too clever. Does anyone who overrides entrySet() care about a specific order, or do they simply sort it in order to get reproducible output? If the latter, then sorting by default hasn't really broken anything. >> >> Also, it was never specified that the properties are written based on what's returned by a self-call to `entrySet()`. So this was never guaranteed, though we do want to avoid gratuitous breakage. >> >> I would also wager that anybody who overrides entrySet() so that they can control the ordering of the entries is probably breaking the contract of Map::entrySet, which says that it's mutable (a mapping can be removed by removing its entry from the entry-set, or the underlying value can be changed by calling setValue on an entry). This is admittedly pretty obscure, but it tells me that trying to customize the output of Properties::store by overriding entrySet() is a pretty fragile hack. >> >> If people really need to control the order of output, they need to iterate the properties themselves instead of overriding entrySet(). I think the only difficulty in doing so is properly escaping the keys and values, as performed by saveConvert(). If this is a use case we want to support, then maybe we should expose a suitable API for escaping properties keys and values. That would be a separate enhancement, though. >> >> Note some history in this Stack Overflow question and answers: >> >> https://stackoverflow.com/questions/10275862/how-to-sort-properties-in-java >> >> Basically they mostly describe overriding `keys()`, but we broke that in Java 9, and now the advice is to override `entrySet()`. But the goal is to sort the properties, which we're doing anyway! > > One part of what store() does is annoying to replicate, the encoding that `saveConvert` does is non-trivial. > Other hacks based on returning a different entrySet might be to filter the set either keep some entries or ignore them. > Both unlikely, but hacks are frequently fragile. And we've been very cautious in this discussion to avoid > breaking things, in part, because there is so little info about how it is used. > "is set **on the command line** and non-empty"... > > Following from a comment on the CSR, it should be clear that the property value used can only be set on the command line. Done. The PR has been updated accordingly. ------------- PR: https://git.openjdk.java.net/jdk/pull/5372 From jpai at openjdk.java.net Thu Sep 16 12:11:51 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Thu, 16 Sep 2021 12:11:51 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v17] In-Reply-To: <4DMbKbYojvlPFMpMJKJx4Hp-E140T07nia8zpU_KcRo=.c725f3ff-dd42-4c0e-b16b-8f67613e6c2b@github.com> References: <4DMbKbYojvlPFMpMJKJx4Hp-E140T07nia8zpU_KcRo=.c725f3ff-dd42-4c0e-b16b-8f67613e6c2b@github.com> Message-ID: <8adxucOlLaVawhhIiUsM76dkeMeg_P5WJz5MFSBbirc=.c7bd6f50-360d-471f-8fb3-f9fd7af8734e@github.com> On Wed, 15 Sep 2021 16:13:56 GMT, Daniel Fuchs wrote: >> src/java.base/share/classes/java/util/Properties.java line 932: >> >>> 930: if (entries instanceof Collections.SynchronizedSet ss >>> 931: && ss.c instanceof EntrySet) { >>> 932: entries = new ArrayList<>(entries); >> >> From the description referring to a 'different instance', I expected to see == or != in this test. >> Since Properties.entrySet() always returns a new synchronized set of a new EntrySet, >> specifying that the underlying map is the same instance is more difficult. >> Perhaps either the SynchronizedSet or the EntrySet instance could be cached and compared. >> >> (typo: missing space after period... ".If yes") > > A custom subclass couldn't create an instance of EntrySet directly. Therefore if it wants to reorder the entries, it would have to return a new TreeSet or LinkedHashSet - or some other custom set implementation. If the result of calling entrySet() is an EntrySet wrapped in an UnmodifiableSet it's therefore legitimate to assume that the set hasn't been reordered, and that we can reorder it. Or am I missing something? I've updated the PR to clarify what this part of the code is doing. I took Daniel's input to reword the javadoc as well as tried to improve the code comment where this check is done. Essentially, we check for the "type" of the returned intstance and if we see that it's a `SynchronizedSet` whose underlying collection is a private class `EntrySet` then we know that it's the one created by Properties.entrySet(). Like Daniel says, subclasses won't be able to create or use this internal private class and if they did override the entrySet() to change the order of the entries they would have to do it by returning us a different "type" from that method. ------------- PR: https://git.openjdk.java.net/jdk/pull/5372 From jai.forums2013 at gmail.com Thu Sep 16 12:45:20 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Thu, 16 Sep 2021 18:15:20 +0530 Subject: RFR: 8231640: (prop) Canonical property storage [v17] In-Reply-To: <1989DyckUTFBtfkv7GJHqVhWHH2Y-Vtb1V9fQG3OzmU=.93735b89-0d02-48ce-b518-fb95a86721c4@github.com> References: <1989DyckUTFBtfkv7GJHqVhWHH2Y-Vtb1V9fQG3OzmU=.93735b89-0d02-48ce-b518-fb95a86721c4@github.com> Message-ID: On 16/09/21 4:05 am, Roger Riggs wrote: > On Wed, 15 Sep 2021 21:46:59 GMT, Stuart Marks wrote: > >>> src/java.base/share/classes/java/util/Properties.java line 819: >>> >>>> 817: *

>>>> 818: * If the {@systemProperty java.util.Properties.storeDate} is set and >>>> 819: * is non-empty (as determined by {@link String#isEmpty() String.isEmpty}), >>> "is set **on the command line** and non-empty"... >>> >>> Following from a comment on the CSR, it should be clear that the property value used can only be set on the command line. >> This is a clever way to detect whether the `entrySet()` method has been overridden to return something other than the entry-set provided by the Properties class... but I'm wondering if it's too clever. Does anyone who overrides entrySet() care about a specific order, or do they simply sort it in order to get reproducible output? If the latter, then sorting by default hasn't really broken anything. >> >> Also, it was never specified that the properties are written based on what's returned by a self-call to `entrySet()`. So this was never guaranteed, though we do want to avoid gratuitous breakage. >> >> I would also wager that anybody who overrides entrySet() so that they can control the ordering of the entries is probably breaking the contract of Map::entrySet, which says that it's mutable (a mapping can be removed by removing its entry from the entry-set, or the underlying value can be changed by calling setValue on an entry). This is admittedly pretty obscure, but it tells me that trying to customize the output of Properties::store by overriding entrySet() is a pretty fragile hack. >> >> If people really need to control the order of output, they need to iterate the properties themselves instead of overriding entrySet(). I think the only difficulty in doing so is properly escaping the keys and values, as performed by saveConvert(). If this is a use case we want to support, then maybe we should expose a suitable API for escaping properties keys and values. That would be a separate enhancement, though. >> >> Note some history in this Stack Overflow question and answers: >> >> https://stackoverflow.com/questions/10275862/how-to-sort-properties-in-java >> >> Basically they mostly describe overriding `keys()`, but we broke that in Java 9, and now the advice is to override `entrySet()`. But the goal is to sort the properties, which we're doing anyway! > One part of what store() does is annoying to replicate, the encoding that `saveConvert` does is non-trivial. > Other hacks based on returning a different entrySet might be to filter the set either keep some entries or ignore them. > Both unlikely, but hacks are frequently fragile. And we've been very cautious in this discussion to avoid > breaking things, in part, because there is so little info about how it is used. To summarize the options that we have discussed for this entrySet() part: - Do nothing specific for subclasses that override entrySet() method. This would mean that the store() method would write out the properties in the natural sort order, but also has a tiny possibility that it will break backward compatibility if some code out there that was returning a differently ordered set. Given how we have tried to prevent backward compatibility issues in this PR plus the fact that we might have a possible way to prevent this, I think we can rule out this option. - Check the Properties object instance type to see if it has been subclassed. If yes, then don't store the properties in the natural sort order. I personally think we should rule this option out because this option prevents this enhancement from being usable by any subclass of Properties even if those subclasses do nothing related to entrySet() and could merely have been subclassed for completely unrelated things. - Detect that the entrySet() method is overridden by the subclass of Properties and might have done something with the returned instance/type. It's just a co-incidence that the Properties.entrySet() already returns a internal private class from that method. This does allow us to introduce a check to decide whether or not to use the new natural sort order for writing the properties. It relies on an internal knowledge plus the internal impl detail of the Property.entrySet() but, IMO, it might be good enough for us to use to be sure that we don't break backward compatibility and yet at the same time, introduce this natural sorted order by default for most of the subclasses out there. The other aspect to consider here is the future maintainability of such check that is being proposed here. What this check would effectively mean is that the implementation in Property.entrySet() and this store() method will have to be closely "held together" so that if we do change the implementation of Property.entrySet() to return something else at a later point, we would still have to return a type which is private to this Properties class (or some internal marker interface type) so that the store() methods can continue to employ a check like this one. IMO, that shouldn't be too hard to do if/when such a change happens in Properties.entrySet(). So I am in favour of this option to get past this entrySet() overridding issue. -Jaikiran From github.com+53162078+shiyuexw at openjdk.java.net Thu Sep 16 13:32:10 2021 From: github.com+53162078+shiyuexw at openjdk.java.net (wxiang) Date: Thu, 16 Sep 2021 13:32:10 GMT Subject: RFR: 8273401: Disable JarIndex support in URLClassPath [v2] In-Reply-To: <0dB9Kuj9GxaOwYKqueZfLjf8T5i40BlvN2z1D3w2AIM=.89202971-3e86-4370-a347-15a60746aec8@github.com> References: <7fXVoIjSmGliERuXW2VgnPMcywMRPv_3lhGL01IMRwI=.5d8e4020-8719-4b23-a303-9f311bbc5961@github.com> <0dB9Kuj9GxaOwYKqueZfLjf8T5i40BlvN2z1D3w2AIM=.89202971-3e86-4370-a347-15a60746aec8@github.com> Message-ID: <-ycv0Ybk2RSi73p88MOroHhftsplWeDwCU6gLhlLuj4=.440aebd1-fdeb-496f-afac-8e3f07d53850@github.com> On Thu, 16 Sep 2021 11:08:17 GMT, Alan Bateman wrote: >> wxiang has updated the pull request incrementally with one additional commit since the last revision: >> >> add isEmpty check > > src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 949: > >> 947: return checkResource(name, check, entry); >> 948: >> 949: if (index == null || !ENABLE_JAR_INDEX) > > Is this needed? When ENABLE_JAR_INDEX is false then I assume index will always be null. I'm only asking is that it would be nice if ENABLE_JAR_INDEX was checked in one place rather than two. Yes, the check is redundant, and I removed it. ------------- PR: https://git.openjdk.java.net/jdk/pull/5524 From alanb at openjdk.java.net Thu Sep 16 13:32:09 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 16 Sep 2021 13:32:09 GMT Subject: RFR: 8273401: Disable JarIndex support in URLClassPath [v3] In-Reply-To: References: Message-ID: On Thu, 16 Sep 2021 13:29:09 GMT, wxiang wrote: >> There is a bug for URLClassPath.findResources with JarIndex. >> Currently, there was agreement on dropping the support from the URLClassLoader implementation but it was suggested that it should be disabled for a release or two before the code is removed. >> A system property can be used to re-enable JarIndex support in URLClassPath. >> >> The PR includes: >> Disable JarIndex support in URLClassPath by default. >> Add system property jdk.net.URLClassPath.enableJarIndex to re-enable JarIndex support. > > wxiang has updated the pull request incrementally with one additional commit since the last revision: > > Remove redundant check Thanks, I think we can finalize the CSR now. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5524 From github.com+53162078+shiyuexw at openjdk.java.net Thu Sep 16 13:32:08 2021 From: github.com+53162078+shiyuexw at openjdk.java.net (wxiang) Date: Thu, 16 Sep 2021 13:32:08 GMT Subject: RFR: 8273401: Disable JarIndex support in URLClassPath [v3] In-Reply-To: References: Message-ID: > There is a bug for URLClassPath.findResources with JarIndex. > Currently, there was agreement on dropping the support from the URLClassLoader implementation but it was suggested that it should be disabled for a release or two before the code is removed. > A system property can be used to re-enable JarIndex support in URLClassPath. > > The PR includes: > Disable JarIndex support in URLClassPath by default. > Add system property jdk.net.URLClassPath.enableJarIndex to re-enable JarIndex support. wxiang has updated the pull request incrementally with one additional commit since the last revision: Remove redundant check ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5524/files - new: https://git.openjdk.java.net/jdk/pull/5524/files/8dd17484..51e169d7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5524&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5524&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5524.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5524/head:pull/5524 PR: https://git.openjdk.java.net/jdk/pull/5524 From jpai at openjdk.java.net Thu Sep 16 14:08:46 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Thu, 16 Sep 2021 14:08:46 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v3] In-Reply-To: References: Message-ID: On Thu, 16 Sep 2021 10:14:47 GMT, Julia Boes wrote: >> This change implements a simple web server that can be run on the command-line with `java -m jdk.httpserver`. >> >> This is facilitated by adding an entry point for the `jdk.httpserver` module, an implementation class whose main method is run when the above command is executed. This is the first such module entry point in the JDK. >> >> The server is a minimal HTTP server that serves the static files of a given directory, similar to existing alternatives on other platforms and convenient for testing, development, and debugging. >> >> Additionally, a small API is introduced for programmatic creation and customization. >> >> Testing: tier1-3. > > Julia Boes has updated the pull request incrementally with one additional commit since the last revision: > > correct path handling src/jdk.httpserver/share/classes/module-info.java line 55: > 53: * [-o none|info|verbose] [-h to show options] > 54: * Options: > 55: * -b, --bind-address - Address to bind to. Default: 0.0.0.0 (all interfaces). I understand that the purpose of this simple server is for development and testing only. But even then, for security considerations, would it be more appropriate to default the bind address to a loopback address instead of making it accessible potentially to entire public? In the past, application servers which used to bind to all interfaces by default have now moved to using the loopback address as a default to avoid such accidental exposing of the server. ------------- PR: https://git.openjdk.java.net/jdk/pull/5505 From shade at openjdk.java.net Thu Sep 16 14:53:44 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 16 Sep 2021 14:53:44 GMT Subject: RFR: 8273797: Stop impersonating "server" VM in all VM variants In-Reply-To: References: Message-ID: On Wed, 15 Sep 2021 10:02:19 GMT, Aleksey Shipilev wrote: > As the follow-up for Zero-specific JDK-8273494, we might want to clean up build system logic for all VM variants: stop impersonating "server" VMs for all of them. This basically leaves "core" and "custom" variants to be handled with this patch. > > Additional testing: > - [x] Linux x86_64 `core` build passes, `libjvm.so` now in `core`, `jvm.cfg` mentions `-core KNOWN` > - [x] Linux x86_64 `custom` (+serialgc,+compiler2) build passes, `libjvm.so` now in `custom`, `jvm.cfg` mentions `-custom KNOWN` @magicus, want to take a look as well? ------------- PR: https://git.openjdk.java.net/jdk/pull/5526 From iignatyev at openjdk.java.net Thu Sep 16 15:12:48 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Thu, 16 Sep 2021 15:12:48 GMT Subject: RFR: 8247980: Exclusive execution of java/util/stream tests slows down tier1 In-Reply-To: References: Message-ID: On Thu, 19 Aug 2021 15:15:31 GMT, Aleksey Shipilev wrote: > See the bug report for more details. I would appreciate if people with their corporate testing systems would run this through their systems to avoid surprises. (ping @RealCLanger, @iignatev). Marked as reviewed by iignatyev (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5189 From shade at openjdk.java.net Thu Sep 16 15:12:48 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 16 Sep 2021 15:12:48 GMT Subject: RFR: 8247980: Exclusive execution of java/util/stream tests slows down tier1 In-Reply-To: <2WF7g-11KvRVl50GuYNlN2zSEgMNdW2ZRiFUbg6zJSg=.bc48f742-2d40-40cf-b373-1d7a6c69876e@github.com> References: <2WF7g-11KvRVl50GuYNlN2zSEgMNdW2ZRiFUbg6zJSg=.bc48f742-2d40-40cf-b373-1d7a6c69876e@github.com> Message-ID: On Wed, 15 Sep 2021 15:09:45 GMT, Arno Zeller wrote: >> See the bug report for more details. I would appreciate if people with their corporate testing systems would run this through their systems to avoid surprises. (ping @RealCLanger, @iignatev). > > I haven't recognized problems I can directly match to this change. > But I should also state, that we parallelize not by using several agents in one jtreg tests - we use no agents and do not set concurrency. Currently we split the jtreg test in groups and each group is executed by a jtreg runner with concurrency one. But the runner do run in parallel if the machine is big enough. > With this setup I do not expect influence by your change because we still execute the test in serial order - even after this change. > At least that is how I understand the effect of exclusiveAccess.dirs . All right, thank you @ArnoZeller! @iignatev, @PaulSandoz, @AlanBateman -- are you good with integrating this? ------------- PR: https://git.openjdk.java.net/jdk/pull/5189 From shade at openjdk.java.net Thu Sep 16 15:21:43 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 16 Sep 2021 15:21:43 GMT Subject: RFR: 8273710: Remove redundant stream() call before forEach in jdk.jdeps In-Reply-To: References: Message-ID: On Mon, 13 Sep 2021 19:57:14 GMT, Andrey Turbanov wrote: > 8273710: Remove redundant stream() call before forEach in jdk.jdeps Marked as reviewed by shade (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5498 From github.com+741251+turbanoff at openjdk.java.net Thu Sep 16 15:21:44 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Thu, 16 Sep 2021 15:21:44 GMT Subject: Integrated: 8273710: Remove redundant stream() call before forEach in jdk.jdeps In-Reply-To: References: Message-ID: On Mon, 13 Sep 2021 19:57:14 GMT, Andrey Turbanov wrote: > 8273710: Remove redundant stream() call before forEach in jdk.jdeps This pull request has now been integrated. Changeset: 7e92abe7 Author: Andrey Turbanov Committer: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/7e92abe7a4bd2840fed19826fbff0285732f1765 Stats: 30 lines in 10 files changed: 0 ins; 5 del; 25 mod 8273710: Remove redundant stream() call before forEach in jdk.jdeps Reviewed-by: dfuchs, shade ------------- PR: https://git.openjdk.java.net/jdk/pull/5498 From rriggs at openjdk.java.net Thu Sep 16 16:11:23 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 16 Sep 2021 16:11:23 GMT Subject: RFR: 8272600: (test) Use native "sleep" in Basic.java [v5] In-Reply-To: References: Message-ID: > The intermittent test in java/lang/ProcessBuilder/Basic.java has identified unexpected messages from a child Java VM > as the cause of the test failure. Attempts to control the output of the child VM have failed, the VM is unrepentant . > > There is no functionality in the child except to wait long enough for the test to finish and the child is destroyed. > The fix is to switch from using a Java child to using a native child; a new executable `sleepmillis`. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Improve diagnostic message to add the exit value of the process. The test will fail if the process has terminated early. (It would have failed anyway due to too short wait). ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5239/files - new: https://git.openjdk.java.net/jdk/pull/5239/files/2a9c33fb..43a54802 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5239&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5239&range=03-04 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5239.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5239/head:pull/5239 PR: https://git.openjdk.java.net/jdk/pull/5239 From mchung at openjdk.java.net Thu Sep 16 17:24:45 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 16 Sep 2021 17:24:45 GMT Subject: RFR: 8273774: CDSPluginTest should only expect classes_nocoops.jsa exists on supported 64-bit platforms [v3] In-Reply-To: References: <6UsB0ppKiipNg3JnMjcHSvKCIpFKnRSaii_BO_OAZlo=.1a501d24-2cb1-4f66-8c44-dfa570a89aad@github.com> Message-ID: <3-yIEZ3no-m3mBEy424lRTAcAPMxWU1ZdEaHI5C1l28=.425257e5-63ad-459c-9101-48b96a9551c9@github.com> On Thu, 16 Sep 2021 03:44:24 GMT, Remilia Scarlet wrote: >> The test assumes that it always runs on 64-bit platform and classes_nocoops.jsa is always created. >> It's a test bug. The test should only expect classes_nocoops.jsa exists if it's running on a supported 64-bit platform. >> However, for unknown target platform, it's unknown if it's 64-bit or not. >> >> This patch fix the test to check if classes_nocoops.jsa exists only on one of the JDK supported platforms (x64 or aarch64) via the sun.arch.data.model system property. >> >> Please review this change. Thanks! > > Remilia Scarlet has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. Thanks for making the change, Remilia. @calvinccheung is the author of CDSPlugin and this test, who should review this fix. My suggestion checking on x64 or aarch64 works for the issue you run into but it would fail again when running on a JDK where CDSPlugin does not support for example `lib/classlist` is not present. There is a method `jdk.test.lib.Platform::isDefaultCDSArchiveSupported` to test if CDS default archive is supported. It may a better fix for CDSPluginTest to simply skip running if default CDS archive is not supported. `isDefaultCDSArchiveSupported` needs to be fixed to include aarch64 but it should be fixed as a separate issue (@calvinccheung can take care of it?) ------------- PR: https://git.openjdk.java.net/jdk/pull/5519 From ccheung at openjdk.java.net Thu Sep 16 17:51:45 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Thu, 16 Sep 2021 17:51:45 GMT Subject: RFR: 8273774: CDSPluginTest should only expect classes_nocoops.jsa exists on supported 64-bit platforms [v3] In-Reply-To: References: <6UsB0ppKiipNg3JnMjcHSvKCIpFKnRSaii_BO_OAZlo=.1a501d24-2cb1-4f66-8c44-dfa570a89aad@github.com> Message-ID: On Thu, 16 Sep 2021 03:44:24 GMT, Remilia Scarlet wrote: >> The test assumes that it always runs on 64-bit platform and classes_nocoops.jsa is always created. >> It's a test bug. The test should only expect classes_nocoops.jsa exists if it's running on a supported 64-bit platform. >> However, for unknown target platform, it's unknown if it's 64-bit or not. >> >> This patch fix the test to check if classes_nocoops.jsa exists only on one of the JDK supported platforms (x64 or aarch64) via the sun.arch.data.model system property. >> >> Please review this change. Thanks! > > Remilia Scarlet has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > 8273774: CDSPluginTest should only expect classes_nocoops.jsa exists on supported 64-bit platforms Marked as reviewed by ccheung (Reviewer). The fix in the test case seems fine to me. We'll file a follow-up bug to fix the `jdk.test.lib.Platform::isDefaultCDSArchiveSupported` method and may re-fix the test case then. ------------- PR: https://git.openjdk.java.net/jdk/pull/5519 From mchung at openjdk.java.net Thu Sep 16 17:56:46 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 16 Sep 2021 17:56:46 GMT Subject: RFR: 8273774: CDSPluginTest should only expect classes_nocoops.jsa exists on supported 64-bit platforms [v3] In-Reply-To: References: <6UsB0ppKiipNg3JnMjcHSvKCIpFKnRSaii_BO_OAZlo=.1a501d24-2cb1-4f66-8c44-dfa570a89aad@github.com> Message-ID: On Thu, 16 Sep 2021 17:48:35 GMT, Calvin Cheung wrote: > The fix in the test case seems fine to me. This test may fail in other cases. We should prepare for those cases in this fix: if (!Platform.isDefaultCDSArchiveSupported() && !Platform.isAArch64())) throw new SkippedException("not a supported platform"); Calvin suggests to throw SkippedException in an offline chat. ------------- PR: https://git.openjdk.java.net/jdk/pull/5519 From mchung at openjdk.java.net Thu Sep 16 18:18:53 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 16 Sep 2021 18:18:53 GMT Subject: RFR: 8273401: Disable JarIndex support in URLClassPath [v3] In-Reply-To: References: Message-ID: <52Vxx2gHT5lpskoh-mud1ZxZjjkF-m_s5nTLllppzdc=.656cb1b9-269e-48b3-b9f5-6476a1ccb83d@github.com> On Thu, 16 Sep 2021 13:32:08 GMT, wxiang wrote: >> There is a bug for URLClassPath.findResources with JarIndex. >> Currently, there was agreement on dropping the support from the URLClassLoader implementation but it was suggested that it should be disabled for a release or two before the code is removed. >> A system property can be used to re-enable JarIndex support in URLClassPath. >> >> The PR includes: >> Disable JarIndex support in URLClassPath by default. >> Add system property jdk.net.URLClassPath.enableJarIndex to re-enable JarIndex support. > > wxiang has updated the pull request incrementally with one additional commit since the last revision: > > Remove redundant check Looks good to me. I agree that this temporary property is not needed to be document in the javadoc. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5524 From ccheung at openjdk.java.net Thu Sep 16 18:23:53 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Thu, 16 Sep 2021 18:23:53 GMT Subject: RFR: 8273774: CDSPluginTest should only expect classes_nocoops.jsa exists on supported 64-bit platforms [v3] In-Reply-To: References: <6UsB0ppKiipNg3JnMjcHSvKCIpFKnRSaii_BO_OAZlo=.1a501d24-2cb1-4f66-8c44-dfa570a89aad@github.com> Message-ID: On Thu, 16 Sep 2021 17:53:25 GMT, Mandy Chung wrote: > > The fix in the test case seems fine to me. > > This test may fail in other cases. We should prepare for those cases in this fix: > > ``` > if (!Platform.isDefaultCDSArchiveSupported() && !Platform.isAArch64())) > throw new SkippedException("not a supported platform"); > ``` I just noticed there was a bug fix [JDK-8269840](https://bugs.openjdk.java.net/browse/JDK-8269840) (Update Platform.isDefaultCDSArchiveSupported() to return true for aarch64 platforms). So the second condition in the above is not necessary. > > Calvin suggests to throw SkippedException in an offline chat. ------------- PR: https://git.openjdk.java.net/jdk/pull/5519 From github.com+10835776+stsypanov at openjdk.java.net Thu Sep 16 19:10:43 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Thu, 16 Sep 2021 19:10:43 GMT Subject: RFR: 8268764: Use Long.hashCode() instead of int-cast where applicable [v4] In-Reply-To: References: Message-ID: On Thu, 1 Jul 2021 12:19:53 GMT, ?????? ??????? wrote: >> In some JDK classes there's still the following hashCode() implementation: >> >> long objNum; >> >> public int hashCode() { >> return (int) objNum; >> } >> >> This outdated expression should be replaced with Long.hashCode(long) as it >> >> - uses all bits of the original value, does not discard any information upfront. For example, depending on how you are generating the IDs, the upper bits could change more frequently (or the opposite). >> >> - does not introduce any bias towards values with more ones (zeros), as it would be the case if the two halves were combined with an OR (AND) operation. >> >> See https://stackoverflow.com/a/4045083 >> >> This is related to https://github.com/openjdk/jdk/pull/4309 > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8268764: Update copy-right year Let's wait, bridgekeeper. ------------- PR: https://git.openjdk.java.net/jdk/pull/4491 From github.com+27751938+amcap1712 at openjdk.java.net Thu Sep 16 19:40:19 2021 From: github.com+27751938+amcap1712 at openjdk.java.net (Kartik Ohri) Date: Thu, 16 Sep 2021 19:40:19 GMT Subject: RFR: 8273681: Add Vector API vs Arrays.mismatch intrinsic benchmark [v2] In-Reply-To: <4KB5kKx9tx7ORFdIm3DvI_A4Udv16Vd-RFSHHIsCZoI=.0a05541b-051a-4009-b198-b4f0a576cb5c@github.com> References: <4KB5kKx9tx7ORFdIm3DvI_A4Udv16Vd-RFSHHIsCZoI=.0a05541b-051a-4009-b198-b4f0a576cb5c@github.com> Message-ID: > Hi all! > > Please review this PR to add a benchmark comparing the performance of Arrays.mismatch intrinsic in the JDK with that of the Vector API. Kindly refer to this [thread] on panama-dev regarding some initial discussion about this benchmark. I have attached the [results] of the full benchmark run along with the [assembly] output of a shorter run I had done while analysing the results. The benchmarks were run against the latest build of panama-vector available from builds.shipilev.net. > > Also, I have not added the copyright header to this file yet as I am an individual contributor (OCA signed) and do not know what to put there. > > [thread]: https://mail.openjdk.java.net/pipermail/panama-dev/2021-September/014839.html > [results]: https://github.com/openjdk/jdk/files/7142452/results.csv > [assembly]: https://github.com/openjdk/jdk/files/7142362/benchmarks.txt > > Regards, > Kartik Kartik Ohri has updated the pull request incrementally with one additional commit since the last revision: Update benchmark according to code review ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5459/files - new: https://git.openjdk.java.net/jdk/pull/5459/files/cf9328a4..b0577807 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5459&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5459&range=00-01 Stats: 54 lines in 1 file changed: 26 ins; 10 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/5459.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5459/head:pull/5459 PR: https://git.openjdk.java.net/jdk/pull/5459 From github.com+43264149+iaroslavski at openjdk.java.net Thu Sep 16 20:38:48 2021 From: github.com+43264149+iaroslavski at openjdk.java.net (iaroslavski) Date: Thu, 16 Sep 2021 20:38:48 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v3] In-Reply-To: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> Message-ID: > Sorting: > > - adopt radix sort for sequential and parallel sorts on int/long/float/double arrays (almost random and length > 6K) > - fix tryMergeRuns() to better handle case when the last run is a single element > - minor javadoc and comment changes > > Testing: > - add new data inputs in tests for sorting > - add min/max/infinity values to float/double testing > - add tests for radix sort iaroslavski 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 five additional commits since the last revision: - Merge remote-tracking branch 'upstream/master' into JDK-8266431-Dual-Pivot-Quicksort-improvements-Radix-sort - JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) Update target version - JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) Testing: - remove @since and @date, otherwise jtreg tag parser fails - JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) Sorting: - move radix sort out from quicksort partitioning - rename radixSort to tryRadixSort - minor javadoc and comment changes Testing: - rename radixSort to tryRadixSort in helper - JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) Sorting: - adopt radix sort for sequential and parallel sorts on int/long/float/double arrays (almost random and length > 6K) - fix tryMergeRuns() to better handle case when the last run is a single element - minor javadoc and comment changes Testing: - add new data inputs in tests for sorting - add min/max/infinity values to float/double testing - add tests for radix sort ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3938/files - new: https://git.openjdk.java.net/jdk/pull/3938/files/189f547a..6003fb69 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3938&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3938&range=01-02 Stats: 781419 lines in 7625 files changed: 627030 ins; 118369 del; 36020 mod Patch: https://git.openjdk.java.net/jdk/pull/3938.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3938/head:pull/3938 PR: https://git.openjdk.java.net/jdk/pull/3938 From ecki at zusammenkunft.net Thu Sep 16 21:51:48 2021 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Thu, 16 Sep 2021 21:51:48 +0000 Subject: RFR: 8272600: (test) Use native "sleep" in Basic.java [v5] In-Reply-To: References: Message-ID: I like it, but I think you don?t Need the %n linebreak (at least the other fail message has none) -- http://bernd.eckenfels.net ________________________________ Von: core-libs-dev im Auftrag von Roger Riggs Gesendet: Donnerstag, September 16, 2021 6:13 PM An: core-libs-dev at openjdk.java.net Betreff: Re: RFR: 8272600: (test) Use native "sleep" in Basic.java [v5] > The intermittent test in java/lang/ProcessBuilder/Basic.java has identified unexpected messages from a child Java VM > as the cause of the test failure. Attempts to control the output of the child VM have failed, the VM is unrepentant . > > There is no functionality in the child except to wait long enough for the test to finish and the child is destroyed. > The fix is to switch from using a Java child to using a native child; a new executable `sleepmillis`. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Improve diagnostic message to add the exit value of the process. The test will fail if the process has terminated early. (It would have failed anyway due to too short wait). ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5239/files - new: https://git.openjdk.java.net/jdk/pull/5239/files/2a9c33fb..43a54802 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5239&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5239&range=03-04 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5239.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5239/head:pull/5239 PR: https://git.openjdk.java.net/jdk/pull/5239 From ecki at zusammenkunft.net Thu Sep 16 22:07:32 2021 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Thu, 16 Sep 2021 22:07:32 +0000 Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v3] In-Reply-To: References: Message-ID: I also wonder if it makes sense to either only serve files with public permissions, or at least Filter some critical files like .ssh/* and *.jks. Those command-line servers are often started ?accidentially? in the home directory. -- http://bernd.eckenfels.net ________________________________ Von: net-dev im Auftrag von Jaikiran Pai Gesendet: Thursday, September 16, 2021 4:08:46 PM An: build-dev at openjdk.java.net ; core-libs-dev at openjdk.java.net ; net-dev at openjdk.java.net Betreff: Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v3] On Thu, 16 Sep 2021 10:14:47 GMT, Julia Boes wrote: >> This change implements a simple web server that can be run on the command-line with `java -m jdk.httpserver`. >> >> This is facilitated by adding an entry point for the `jdk.httpserver` module, an implementation class whose main method is run when the above command is executed. This is the first such module entry point in the JDK. >> >> The server is a minimal HTTP server that serves the static files of a given directory, similar to existing alternatives on other platforms and convenient for testing, development, and debugging. >> >> Additionally, a small API is introduced for programmatic creation and customization. >> >> Testing: tier1-3. > > Julia Boes has updated the pull request incrementally with one additional commit since the last revision: > > correct path handling src/jdk.httpserver/share/classes/module-info.java line 55: > 53: * [-o none|info|verbose] [-h to show options] > 54: * Options: > 55: * -b, --bind-address - Address to bind to. Default: 0.0.0.0 (all interfaces). I understand that the purpose of this simple server is for development and testing only. But even then, for security considerations, would it be more appropriate to default the bind address to a loopback address instead of making it accessible potentially to entire public? In the past, application servers which used to bind to all interfaces by default have now moved to using the loopback address as a default to avoid such accidental exposing of the server. ------------- PR: https://git.openjdk.java.net/jdk/pull/5505 From psandoz at openjdk.java.net Thu Sep 16 22:53:43 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Thu, 16 Sep 2021 22:53:43 GMT Subject: RFR: 8273681: Add Vector API vs Arrays.mismatch intrinsic benchmark [v2] In-Reply-To: References: <4KB5kKx9tx7ORFdIm3DvI_A4Udv16Vd-RFSHHIsCZoI=.0a05541b-051a-4009-b198-b4f0a576cb5c@github.com> Message-ID: On Thu, 16 Sep 2021 19:40:19 GMT, Kartik Ohri wrote: >> Hi all! >> >> Please review this PR to add a benchmark comparing the performance of Arrays.mismatch intrinsic in the JDK with that of the Vector API. Kindly refer to this [thread] on panama-dev regarding some initial discussion about this benchmark. I have attached the [results] of the full benchmark run along with the [assembly] output of a shorter run I had done while analysing the results. The benchmarks were run against the latest build of panama-vector available from builds.shipilev.net. >> >> Also, I have not added the copyright header to this file yet as I am an individual contributor (OCA signed) and do not know what to put there. >> >> [thread]: https://mail.openjdk.java.net/pipermail/panama-dev/2021-September/014839.html >> [results]: https://github.com/openjdk/jdk/files/7142452/results.csv >> [assembly]: https://github.com/openjdk/jdk/files/7142362/benchmarks.txt >> >> Regards, >> Kartik > > Kartik Ohri has updated the pull request incrementally with one additional commit since the last revision: > > Update benchmark according to code review Looks good, just a minor issue (that does not induce incorrect behavior), no need for re-approval to fix that. test/micro/org/openjdk/bench/jdk/incubator/vector/ArrayMismatchBenchmark.java line 103: > 101: doubleData2 = random.doubles(size).toArray(); > 102: > 103: double[] commonDoubles = random.doubles(size).toArray(); Suggestion: double[] commonDoubles = random.doubles(common).toArray(); ------------- Marked as reviewed by psandoz (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5459 From github.com+22913521+1996scarlet at openjdk.java.net Fri Sep 17 01:47:05 2021 From: github.com+22913521+1996scarlet at openjdk.java.net (Remilia Scarlet) Date: Fri, 17 Sep 2021 01:47:05 GMT Subject: RFR: 8273774: CDSPluginTest should only expect classes_nocoops.jsa exists on supported 64-bit platforms [v4] In-Reply-To: <6UsB0ppKiipNg3JnMjcHSvKCIpFKnRSaii_BO_OAZlo=.1a501d24-2cb1-4f66-8c44-dfa570a89aad@github.com> References: <6UsB0ppKiipNg3JnMjcHSvKCIpFKnRSaii_BO_OAZlo=.1a501d24-2cb1-4f66-8c44-dfa570a89aad@github.com> Message-ID: > The test assumes that it always runs on 64-bit platform and classes_nocoops.jsa is always created. > It's a test bug. The test should only expect classes_nocoops.jsa exists if it's running on a supported 64-bit platform. > However, for unknown target platform, it's unknown if it's 64-bit or not. > > This patch fix the test to check if classes_nocoops.jsa exists only on one of the JDK supported platforms (x64 or aarch64) via the sun.arch.data.model system property. > > Please review this change. Thanks! Remilia Scarlet has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8273774: CDSPluginTest should only expect classes_nocoops.jsa exists on supported 64-bit platforms ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5519/files - new: https://git.openjdk.java.net/jdk/pull/5519/files/5ec04d45..587aeecf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5519&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5519&range=02-03 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5519.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5519/head:pull/5519 PR: https://git.openjdk.java.net/jdk/pull/5519 From github.com+22913521+1996scarlet at openjdk.java.net Fri Sep 17 01:55:50 2021 From: github.com+22913521+1996scarlet at openjdk.java.net (Remilia Scarlet) Date: Fri, 17 Sep 2021 01:55:50 GMT Subject: RFR: 8273774: CDSPluginTest should only expect classes_nocoops.jsa exists on supported 64-bit platforms [v4] In-Reply-To: References: <6UsB0ppKiipNg3JnMjcHSvKCIpFKnRSaii_BO_OAZlo=.1a501d24-2cb1-4f66-8c44-dfa570a89aad@github.com> Message-ID: On Fri, 17 Sep 2021 01:47:05 GMT, Remilia Scarlet wrote: >> The test assumes that it always runs on 64-bit platform and classes_nocoops.jsa is always created. >> It's a test bug. The test should only expect classes_nocoops.jsa exists if it's running on a supported 64-bit platform. >> However, for unknown target platform, it's unknown if it's 64-bit or not. >> >> This patch fix the test to check if classes_nocoops.jsa exists only on one of the JDK supported platforms (x64 or aarch64) via the sun.arch.data.model system property. >> >> Please review this change. Thanks! > > Remilia Scarlet has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. Please reexamine the change. Thanks all! ------------- PR: https://git.openjdk.java.net/jdk/pull/5519 From mchung at openjdk.java.net Fri Sep 17 01:55:51 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 17 Sep 2021 01:55:51 GMT Subject: RFR: 8273774: CDSPluginTest should only expect classes_nocoops.jsa exists on supported 64-bit platforms [v4] In-Reply-To: References: <6UsB0ppKiipNg3JnMjcHSvKCIpFKnRSaii_BO_OAZlo=.1a501d24-2cb1-4f66-8c44-dfa570a89aad@github.com> Message-ID: On Fri, 17 Sep 2021 01:47:05 GMT, Remilia Scarlet wrote: >> The test assumes that it always runs on 64-bit platform and classes_nocoops.jsa is always created. >> It's a test bug. The test should only expect classes_nocoops.jsa exists if it's running on a supported 64-bit platform. >> However, for unknown target platform, it's unknown if it's 64-bit or not. >> >> This patch fix the test to check if classes_nocoops.jsa exists only on one of the JDK supported platforms (x64 or aarch64) via the sun.arch.data.model system property. >> >> Please review this change. Thanks! > > Remilia Scarlet has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. test/jdk/tools/jlink/plugins/CDSPluginTest.java line 82: > 80: helper.checkImage(image, module, null, null, > 81: new String[] { subDir + "classes.jsa" }); > 82: } The above change checking 64-bit platform should not be needed. On an unknown platform, `isDefaultCDSArchiveSupported` should return false. It only returns true on 64-bit supported platforms. Can you verfiy? ------------- PR: https://git.openjdk.java.net/jdk/pull/5519 From github.com+22913521+1996scarlet at openjdk.java.net Fri Sep 17 02:11:51 2021 From: github.com+22913521+1996scarlet at openjdk.java.net (Remilia Scarlet) Date: Fri, 17 Sep 2021 02:11:51 GMT Subject: RFR: 8273774: CDSPluginTest should only expect classes_nocoops.jsa exists on supported 64-bit platforms [v4] In-Reply-To: References: <6UsB0ppKiipNg3JnMjcHSvKCIpFKnRSaii_BO_OAZlo=.1a501d24-2cb1-4f66-8c44-dfa570a89aad@github.com> Message-ID: On Fri, 17 Sep 2021 01:52:30 GMT, Mandy Chung wrote: >> Remilia Scarlet has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: >> >> 8273774: CDSPluginTest should only expect classes_nocoops.jsa exists on supported 64-bit platforms > > test/jdk/tools/jlink/plugins/CDSPluginTest.java line 84: > >> 82: } >> 83: >> 84: // Simulate different platforms between current runtime and target image. > > The above change checking 64-bit platform should not be needed. On an unknown platform, `isDefaultCDSArchiveSupported` should return false. It only returns true on 64-bit supported platforms. Can you verfiy? I just try it on LoongArch64 and mips64el. The `Platform.isDefaultCDSArchiveSupported()` returns true. So the above checking can not be removed. Also, I just forgot add `import jtreg.SkippedException`. ------------- PR: https://git.openjdk.java.net/jdk/pull/5519 From github.com+22913521+1996scarlet at openjdk.java.net Fri Sep 17 02:17:09 2021 From: github.com+22913521+1996scarlet at openjdk.java.net (Remilia Scarlet) Date: Fri, 17 Sep 2021 02:17:09 GMT Subject: RFR: 8273774: CDSPluginTest should only expect classes_nocoops.jsa exists on supported 64-bit platforms [v5] In-Reply-To: <6UsB0ppKiipNg3JnMjcHSvKCIpFKnRSaii_BO_OAZlo=.1a501d24-2cb1-4f66-8c44-dfa570a89aad@github.com> References: <6UsB0ppKiipNg3JnMjcHSvKCIpFKnRSaii_BO_OAZlo=.1a501d24-2cb1-4f66-8c44-dfa570a89aad@github.com> Message-ID: > The test assumes that it always runs on 64-bit platform and classes_nocoops.jsa is always created. > It's a test bug. The test should only expect classes_nocoops.jsa exists if it's running on a supported 64-bit platform. > However, for unknown target platform, it's unknown if it's 64-bit or not. > > This patch fix the test to check if classes_nocoops.jsa exists only on one of the JDK supported platforms (x64 or aarch64) via the sun.arch.data.model system property. > > Please review this change. Thanks! Remilia Scarlet has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8273774: CDSPluginTest should only expect classes_nocoops.jsa exists on supported 64-bit platforms ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5519/files - new: https://git.openjdk.java.net/jdk/pull/5519/files/587aeecf..503406b5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5519&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5519&range=03-04 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5519.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5519/head:pull/5519 PR: https://git.openjdk.java.net/jdk/pull/5519 From mchung at openjdk.java.net Fri Sep 17 02:23:46 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 17 Sep 2021 02:23:46 GMT Subject: RFR: 8273774: CDSPluginTest should only expect classes_nocoops.jsa exists on supported 64-bit platforms [v5] In-Reply-To: References: <6UsB0ppKiipNg3JnMjcHSvKCIpFKnRSaii_BO_OAZlo=.1a501d24-2cb1-4f66-8c44-dfa570a89aad@github.com> Message-ID: On Fri, 17 Sep 2021 02:17:09 GMT, Remilia Scarlet wrote: >> The test assumes that it always runs on 64-bit platform and classes_nocoops.jsa is always created. >> It's a test bug. The test should only expect classes_nocoops.jsa exists if it's running on a supported 64-bit platform. >> However, for unknown target platform, it's unknown if it's 64-bit or not. >> >> This patch fix the test to check if classes_nocoops.jsa exists only on one of the JDK supported platforms (x64 or aarch64) via the sun.arch.data.model system property. >> >> Please review this change. Thanks! > > Remilia Scarlet has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. Thanks for the change. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5519 From serb at openjdk.java.net Fri Sep 17 02:42:52 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 17 Sep 2021 02:42:52 GMT Subject: RFR: 8273101: Eliminate the usage of threadgroup sandboxing in the java.util.logging In-Reply-To: References: Message-ID: On Mon, 6 Sep 2021 09:39:58 GMT, Alan Bateman wrote: > No objection to removing this legacy/unused code but I think it would be useful to useful to have the JBS issue or the PR summary provide a bit more context. As I see it, this is just one piece of the overall cleanup and I assume there are more substantive changes to the java.desktop module coming, is that right? I have updated the PR and JBS ------------- PR: https://git.openjdk.java.net/jdk/pull/5326 From jpai at openjdk.java.net Fri Sep 17 03:51:15 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Fri, 17 Sep 2021 03:51:15 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v19] In-Reply-To: References: Message-ID: > The commit in this PR implements the proposal for enhancement that was discussed in the core-libs-dev mailing list recently[1], for https://bugs.openjdk.java.net/browse/JDK-8231640 > > At a high level - the `store()` APIs in `Properties` have been modified to now look for the `SOURCE_DATE_EPOCH` environment variable[2]. If that env variable is set, then instead of writing out the current date time as a date comment, the `store()` APIs instead will use the value set for this env variable to parse it to a `Date` and write out the string form of such a date. The implementation here uses the `d MMM yyyy HH:mm:ss 'GMT'` date format and `Locale.ROOT` to format and write out such a date. This should provide reproducibility whenever the `SOURCE_DATE_EPOCH` is set. Furthermore, intentionally, no changes in the date format of the "current date" have been done. > > These modified `store()` APIs work in the presence of the `SecurityManager` too. The caller is expected to have a read permission on the `SOURCE_DATE_EPOCH` environment variable. If the caller doesn't have that permission, then the implementation of these `store()` APIs will write out the "current date" and will ignore any value that has been set for the `SOURCE_DATE_EPOCH` env variable. This should allow for backward compatibility of existing applications, where, when they run under a `SecurityManager` and perhaps with an existing restrictive policy file, the presence of `SOURCE_DATE_EPOCH` shouldn't impact their calls to the `store()` APIs. > > The modified `store()` APIs will also ignore any value for `SOURCE_DATE_EPOCH` that cannot be parsed to an `long` value. In such cases, the `store()` APIs will write out the "current date" and ignore the value set for this environment variable. No exceptions will be thrown for such invalid values. This is an additional backward compatibility precaution to prevent any rogue value for `SOURCE_DATE_EPOCH` from breaking applications. > > An additional change in the implementation of these `store()` APIs and unrelated to the date comment, is that these APIs will now write out the property keys in a deterministic order. The keys will be written out in the natural ordering as specified by `java.lang.String#compareTo()` API. > > The combination of the ordering of the property keys when written out and the usage of `SOURCE_DATE_EPOCH` environment value to determine the date comment should together allow for reproducibility of the output generated by these `store()` APIs. > > New jtreg test classes have been introduced to verify these changes. The primary focus of `PropertiesStoreTest` is the ordering aspects of the property keys that are written out. On the other hand `StoreReproducibilityTest` focuses on the reproducibility of the output generated by these APIs. The `StoreReproducibilityTest` runs these tests both in the presence and absence of `SecurityManager`. Plus, in the presence of SecurityManager, it tests both the scenarios where the caller is granted the requisite permission and in other case not granted that permission. > > These new tests and existing tests under `test/jdk/java/util/Properties/` pass with these changes. > > [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-August/080758.html > [2] https://reproducible-builds.org/specs/source-date-epoch/ Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: - Implement Mark's suggestion in CSR, to rename java.util.Properties.storeDate system property to java.properties.date - Tests updated accordingly ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5372/files - new: https://git.openjdk.java.net/jdk/pull/5372/files/e2effb96..eb31d287 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5372&range=18 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5372&range=17-18 Stats: 93 lines in 3 files changed: 1 ins; 0 del; 92 mod Patch: https://git.openjdk.java.net/jdk/pull/5372.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5372/head:pull/5372 PR: https://git.openjdk.java.net/jdk/pull/5372 From jpai at openjdk.java.net Fri Sep 17 04:13:33 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Fri, 17 Sep 2021 04:13:33 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v20] In-Reply-To: References: Message-ID: > The commit in this PR implements the proposal for enhancement that was discussed in the core-libs-dev mailing list recently[1], for https://bugs.openjdk.java.net/browse/JDK-8231640 > > At a high level - the `store()` APIs in `Properties` have been modified to now look for the `SOURCE_DATE_EPOCH` environment variable[2]. If that env variable is set, then instead of writing out the current date time as a date comment, the `store()` APIs instead will use the value set for this env variable to parse it to a `Date` and write out the string form of such a date. The implementation here uses the `d MMM yyyy HH:mm:ss 'GMT'` date format and `Locale.ROOT` to format and write out such a date. This should provide reproducibility whenever the `SOURCE_DATE_EPOCH` is set. Furthermore, intentionally, no changes in the date format of the "current date" have been done. > > These modified `store()` APIs work in the presence of the `SecurityManager` too. The caller is expected to have a read permission on the `SOURCE_DATE_EPOCH` environment variable. If the caller doesn't have that permission, then the implementation of these `store()` APIs will write out the "current date" and will ignore any value that has been set for the `SOURCE_DATE_EPOCH` env variable. This should allow for backward compatibility of existing applications, where, when they run under a `SecurityManager` and perhaps with an existing restrictive policy file, the presence of `SOURCE_DATE_EPOCH` shouldn't impact their calls to the `store()` APIs. > > The modified `store()` APIs will also ignore any value for `SOURCE_DATE_EPOCH` that cannot be parsed to an `long` value. In such cases, the `store()` APIs will write out the "current date" and ignore the value set for this environment variable. No exceptions will be thrown for such invalid values. This is an additional backward compatibility precaution to prevent any rogue value for `SOURCE_DATE_EPOCH` from breaking applications. > > An additional change in the implementation of these `store()` APIs and unrelated to the date comment, is that these APIs will now write out the property keys in a deterministic order. The keys will be written out in the natural ordering as specified by `java.lang.String#compareTo()` API. > > The combination of the ordering of the property keys when written out and the usage of `SOURCE_DATE_EPOCH` environment value to determine the date comment should together allow for reproducibility of the output generated by these `store()` APIs. > > New jtreg test classes have been introduced to verify these changes. The primary focus of `PropertiesStoreTest` is the ordering aspects of the property keys that are written out. On the other hand `StoreReproducibilityTest` focuses on the reproducibility of the output generated by these APIs. The `StoreReproducibilityTest` runs these tests both in the presence and absence of `SecurityManager`. Plus, in the presence of SecurityManager, it tests both the scenarios where the caller is granted the requisite permission and in other case not granted that permission. > > These new tests and existing tests under `test/jdk/java/util/Properties/` pass with these changes. > > [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-August/080758.html > [2] https://reproducible-builds.org/specs/source-date-epoch/ Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: Implement Mark's suggestion in CSR to include the java.properties.date in the list of system properties listed in System::getProperties() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5372/files - new: https://git.openjdk.java.net/jdk/pull/5372/files/eb31d287..458c1fd3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5372&range=19 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5372&range=18-19 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5372.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5372/head:pull/5372 PR: https://git.openjdk.java.net/jdk/pull/5372 From github.com+27751938+amcap1712 at openjdk.java.net Fri Sep 17 04:56:11 2021 From: github.com+27751938+amcap1712 at openjdk.java.net (Kartik Ohri) Date: Fri, 17 Sep 2021 04:56:11 GMT Subject: RFR: 8273681: Add Vector API vs Arrays.mismatch intrinsic benchmark [v3] In-Reply-To: <4KB5kKx9tx7ORFdIm3DvI_A4Udv16Vd-RFSHHIsCZoI=.0a05541b-051a-4009-b198-b4f0a576cb5c@github.com> References: <4KB5kKx9tx7ORFdIm3DvI_A4Udv16Vd-RFSHHIsCZoI=.0a05541b-051a-4009-b198-b4f0a576cb5c@github.com> Message-ID: > Hi all! > > Please review this PR to add a benchmark comparing the performance of Arrays.mismatch intrinsic in the JDK with that of the Vector API. Kindly refer to this [thread] on panama-dev regarding some initial discussion about this benchmark. I have attached the [results] of the full benchmark run along with the [assembly] output of a shorter run I had done while analysing the results. The benchmarks were run against the latest build of panama-vector available from builds.shipilev.net. > > Also, I have not added the copyright header to this file yet as I am an individual contributor (OCA signed) and do not know what to put there. > > [thread]: https://mail.openjdk.java.net/pipermail/panama-dev/2021-September/014839.html > [results]: https://github.com/openjdk/jdk/files/7142452/results.csv > [assembly]: https://github.com/openjdk/jdk/files/7142362/benchmarks.txt > > Regards, > Kartik Kartik Ohri has updated the pull request incrementally with one additional commit since the last revision: Fix typo Co-authored-by: Paul Sandoz ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5459/files - new: https://git.openjdk.java.net/jdk/pull/5459/files/b0577807..869e4f2e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5459&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5459&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5459.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5459/head:pull/5459 PR: https://git.openjdk.java.net/jdk/pull/5459 From github.com+27751938+amcap1712 at openjdk.java.net Fri Sep 17 04:56:11 2021 From: github.com+27751938+amcap1712 at openjdk.java.net (Kartik Ohri) Date: Fri, 17 Sep 2021 04:56:11 GMT Subject: RFR: 8273681: Add Vector API vs Arrays.mismatch intrinsic benchmark In-Reply-To: References: <4KB5kKx9tx7ORFdIm3DvI_A4Udv16Vd-RFSHHIsCZoI=.0a05541b-051a-4009-b198-b4f0a576cb5c@github.com> Message-ID: On Mon, 13 Sep 2021 18:05:55 GMT, Paul Sandoz wrote: >> Hi all! >> >> Please review this PR to add a benchmark comparing the performance of Arrays.mismatch intrinsic in the JDK with that of the Vector API. Kindly refer to this [thread] on panama-dev regarding some initial discussion about this benchmark. I have attached the [results] of the full benchmark run along with the [assembly] output of a shorter run I had done while analysing the results. The benchmarks were run against the latest build of panama-vector available from builds.shipilev.net. >> >> Also, I have not added the copyright header to this file yet as I am an individual contributor (OCA signed) and do not know what to put there. >> >> [thread]: https://mail.openjdk.java.net/pipermail/panama-dev/2021-September/014839.html >> [results]: https://github.com/openjdk/jdk/files/7142452/results.csv >> [assembly]: https://github.com/openjdk/jdk/files/7142362/benchmarks.txt >> >> Regards, >> Kartik > > The simplest approach is to copy the license from here https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/jdk/incubator/vector/RotateBenchmark.java Thanks for the review, @PaulSandoz ------------- PR: https://git.openjdk.java.net/jdk/pull/5459 From github.com+27751938+amcap1712 at openjdk.java.net Fri Sep 17 04:56:15 2021 From: github.com+27751938+amcap1712 at openjdk.java.net (Kartik Ohri) Date: Fri, 17 Sep 2021 04:56:15 GMT Subject: RFR: 8273681: Add Vector API vs Arrays.mismatch intrinsic benchmark [v2] In-Reply-To: References: <4KB5kKx9tx7ORFdIm3DvI_A4Udv16Vd-RFSHHIsCZoI=.0a05541b-051a-4009-b198-b4f0a576cb5c@github.com> Message-ID: On Thu, 16 Sep 2021 22:49:38 GMT, Paul Sandoz wrote: >> Kartik Ohri has updated the pull request incrementally with one additional commit since the last revision: >> >> Update benchmark according to code review > > test/micro/org/openjdk/bench/jdk/incubator/vector/ArrayMismatchBenchmark.java line 103: > >> 101: doubleData2 = random.doubles(size).toArray(); >> 102: >> 103: double[] commonDoubles = random.doubles(size).toArray(); > > Suggestion: > > double[] commonDoubles = random.doubles(common).toArray(); Fixed. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/5459 From alanb at openjdk.java.net Fri Sep 17 05:52:46 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 17 Sep 2021 05:52:46 GMT Subject: RFR: 8247980: Exclusive execution of java/util/stream tests slows down tier1 In-Reply-To: References: Message-ID: On Wed, 25 Aug 2021 15:52:06 GMT, Igor Ignatyev wrote: >> See the bug report for more details. I would appreciate if people with their corporate testing systems would run this through their systems to avoid surprises. (ping @RealCLanger, @iignatev). > > the testing in our infra returned green. > @iignatev, @PaulSandoz, @AlanBateman -- are you good with integrating this? No objection from me. If issues arise then I assume it can be discussed again and we can figure out something that works for whatever CI or environment where it is problematic. ------------- PR: https://git.openjdk.java.net/jdk/pull/5189 From shade at openjdk.java.net Fri Sep 17 05:52:46 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 17 Sep 2021 05:52:46 GMT Subject: RFR: 8247980: Exclusive execution of java/util/stream tests slows down tier1 In-Reply-To: References: Message-ID: On Fri, 17 Sep 2021 05:47:20 GMT, Alan Bateman wrote: > No objection from me. If issues arise then I assume it can be discussed again and we can figure out something that works for whatever CI or environment where it is problematic. Yes, I think if tests start to fail, we look into concrete cases. If we see those failures are hard to fix, we revert this patch, and wait a few years again :) ------------- PR: https://git.openjdk.java.net/jdk/pull/5189 From shade at openjdk.java.net Fri Sep 17 06:46:45 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 17 Sep 2021 06:46:45 GMT Subject: RFR: 8236505: Mark jdk/editpad/EditPadTest.java as @headful In-Reply-To: References: <_j9LK9SIRBmy-CCoe-OTa5bpqiVYbHUaeTolbqjAcAA=.81c737bb-e4cf-4445-bc3a-28590aeed95b@github.com> Message-ID: On Thu, 16 Sep 2021 09:47:16 GMT, Jan Lahoda wrote: >> This is a GUI test, and it should be `@headful`. >> >> Additional testing: >> - [x] Test still runs in default, and does not run with `!headful` > > Ah, right, I thought it is a JShell test, but it is not. Sorry for the noise. @lahodaj, would you like to formally ack this PR? ------------- PR: https://git.openjdk.java.net/jdk/pull/5544 From john.r.rose at oracle.com Fri Sep 17 06:55:53 2021 From: john.r.rose at oracle.com (John Rose) Date: Fri, 17 Sep 2021 06:55:53 +0000 Subject: better random numbers In-Reply-To: References: <3DC84A6C-DAB3-42CB-ACF6-0CADB5BE19C1@oracle.com> <45847008-5021-7911-607c-559f8bc4545e@littlepinkcloud.com> <12812f86-8723-27d3-a8b0-09d77aee7baf@gmail.com> Message-ID: <69F2CE77-9734-41C4-9DF6-ADB60E11DBEC@oracle.com> On Sep 7, 2021, at 4:48 AM, Stefan Zobel > wrote: That "influential researcher" is probably Sebastiano Vigna who has indeed harsh words on PCG: https://pcg.di.unimi.it/pcg.php That link can also be found on ONeill?s blog, along with her responses. https://www.pcg-random.org/posts/on-vignas-pcg-critique.html From shade at openjdk.java.net Fri Sep 17 06:59:09 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 17 Sep 2021 06:59:09 GMT Subject: RFR: 8273314: Add tier4 test groups [v4] In-Reply-To: <6rDioD5KZREYHyzOXol72O0erNDqKHUqb-0k1SwhInA=.90a12492-9e2f-4f0c-bf09-8d67d1d6111f@github.com> References: <6rDioD5KZREYHyzOXol72O0erNDqKHUqb-0k1SwhInA=.90a12492-9e2f-4f0c-bf09-8d67d1d6111f@github.com> Message-ID: > During the review of JDK-8272914 that added hotspot:tier{2,3} groups, @iignatev suggested to create tier4 groups that capture all tests not in tiers{1,2,3}. > > Caveats: > - I excluded `applications` from `hotspot:tier4`, because they require test dependencies (e.g. jcstress). > - `jdk:tier4` only runs well with `JTREG_KEYWORDS=!headful` or reduced concurrency with `TEST_JOBS=1`, because headful tests cannot run in parallel > > Sample run with `JTREG_KEYWORDS=!headful`: > > > ============================== > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR >>> jtreg:test/hotspot/jtreg:tier4 3585 3584 0 1 << >>> jtreg:test/jdk:tier4 2893 2887 5 1 << > jtreg:test/langtools:tier4 0 0 0 0 > jtreg:test/jaxp:tier4 0 0 0 0 > ============================== > > real 699m39.462s > user 6626m8.448s > sys 1110m43.704s > > > There are interesting test failures on my machine, which I would address separately. Aleksey Shipilev 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 five additional commits since the last revision: - Merge branch 'master' into JDK-8273314-tier4 - Merge branch 'master' into JDK-8273314-tier4 - Drop applications and fix the comment - Drop exceptions - Add tier4 test groups ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5357/files - new: https://git.openjdk.java.net/jdk/pull/5357/files/160c13c7..a5115a8d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5357&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5357&range=02-03 Stats: 14580 lines in 682 files changed: 9082 ins; 3191 del; 2307 mod Patch: https://git.openjdk.java.net/jdk/pull/5357.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5357/head:pull/5357 PR: https://git.openjdk.java.net/jdk/pull/5357 From shade at openjdk.java.net Fri Sep 17 06:59:10 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 17 Sep 2021 06:59:10 GMT Subject: RFR: 8273314: Add tier4 test groups [v3] In-Reply-To: References: <6rDioD5KZREYHyzOXol72O0erNDqKHUqb-0k1SwhInA=.90a12492-9e2f-4f0c-bf09-8d67d1d6111f@github.com> Message-ID: On Mon, 6 Sep 2021 13:22:03 GMT, Aleksey Shipilev wrote: >> During the review of JDK-8272914 that added hotspot:tier{2,3} groups, @iignatev suggested to create tier4 groups that capture all tests not in tiers{1,2,3}. >> >> Caveats: >> - I excluded `applications` from `hotspot:tier4`, because they require test dependencies (e.g. jcstress). >> - `jdk:tier4` only runs well with `JTREG_KEYWORDS=!headful` or reduced concurrency with `TEST_JOBS=1`, because headful tests cannot run in parallel >> >> Sample run with `JTREG_KEYWORDS=!headful`: >> >> >> ============================== >> Test summary >> ============================== >> TEST TOTAL PASS FAIL ERROR >>>> jtreg:test/hotspot/jtreg:tier4 3585 3584 0 1 << >>>> jtreg:test/jdk:tier4 2893 2887 5 1 << >> jtreg:test/langtools:tier4 0 0 0 0 >> jtreg:test/jaxp:tier4 0 0 0 0 >> ============================== >> >> real 699m39.462s >> user 6626m8.448s >> sys 1110m43.704s >> >> >> There are interesting test failures on my machine, which I would address separately. > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Drop applications and fix the comment All right, I am convinced that current patch is as good as it gets. GUI tests still do not run well with default parallelism, but I see no reason to block this integration before that is resolved. Either run `tier4` in headless mode, or limit the parallelism. @iignatev, @mrserb, @dholmes-ora -- are you good with this? ------------- PR: https://git.openjdk.java.net/jdk/pull/5357 From wuyan at openjdk.java.net Fri Sep 17 07:16:42 2021 From: wuyan at openjdk.java.net (Wu Yan) Date: Fri, 17 Sep 2021 07:16:42 GMT Subject: RFR: 8268231: Aarch64: Use ldp in intrinsics for String.compareTo [v6] In-Reply-To: References: <_XL6WybKwHeJ54kSQnN_q0_NgvR7ib9BFjNJ4HrkO_g=.f82e6cda-b31f-4eee-9185-3e52ebd6b54d@github.com> Message-ID: On Sun, 5 Sep 2021 13:23:21 GMT, Andrew Haley wrote: >> Thanks, I'll fix it. > > It's fine. I don't think it'll affect any real programs, so it's rather pointless. I don't know if that's any reason not to approve it. Andrew, can you help us to approve this? ------------- PR: https://git.openjdk.java.net/jdk/pull/4722 From serb at openjdk.java.net Fri Sep 17 07:17:48 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 17 Sep 2021 07:17:48 GMT Subject: RFR: 8273314: Add tier4 test groups [v4] In-Reply-To: References: <6rDioD5KZREYHyzOXol72O0erNDqKHUqb-0k1SwhInA=.90a12492-9e2f-4f0c-bf09-8d67d1d6111f@github.com> Message-ID: <5Lc2i9bPCfmNRnco-B7Ru5VhREqKDbBrnjTS0YcVo8o=.950bb2c9-76a1-4278-855e-7d506686715c@github.com> On Fri, 17 Sep 2021 06:59:09 GMT, Aleksey Shipilev wrote: >> During the review of JDK-8272914 that added hotspot:tier{2,3} groups, @iignatev suggested to create tier4 groups that capture all tests not in tiers{1,2,3}. >> >> Caveats: >> - I excluded `applications` from `hotspot:tier4`, because they require test dependencies (e.g. jcstress). >> - `jdk:tier4` only runs well with `JTREG_KEYWORDS=!headful` or reduced concurrency with `TEST_JOBS=1`, because headful tests cannot run in parallel >> >> Sample run with `JTREG_KEYWORDS=!headful`: >> >> >> ============================== >> Test summary >> ============================== >> TEST TOTAL PASS FAIL ERROR >>>> jtreg:test/hotspot/jtreg:tier4 3585 3584 0 1 << >>>> jtreg:test/jdk:tier4 2893 2887 5 1 << >> jtreg:test/langtools:tier4 0 0 0 0 >> jtreg:test/jaxp:tier4 0 0 0 0 >> ============================== >> >> real 699m39.462s >> user 6626m8.448s >> sys 1110m43.704s >> >> >> There are interesting test failures on my machine, which I would address separately. > > Aleksey Shipilev 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 five additional commits since the last revision: > > - Merge branch 'master' into JDK-8273314-tier4 > - Merge branch 'master' into JDK-8273314-tier4 > - Drop applications and fix the comment > - Drop exceptions > - Add tier4 test groups It is fine to run headful and headless tests separately. ------------- Marked as reviewed by serb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5357 From myano at openjdk.java.net Fri Sep 17 08:49:43 2021 From: myano at openjdk.java.net (Masanori Yano) Date: Fri, 17 Sep 2021 08:49:43 GMT Subject: RFR: 8233674: JarURLConnection.getJarFile throws Exception if some process is holding the file In-Reply-To: References: Message-ID: On Fri, 10 Sep 2021 09:23:52 GMT, Masanori Yano wrote: > Could you please review the 8233674 bug fixes? > This problem is caused by the antivirus software opening the file for a short time, so CreateFile() should be retried. Thank you for your comment. According to Microsoft KB316609, CreateFile() should be tried again a short time later. I think JarURLConnection should also be retried when antivirus software holds some files. https://www.betaarchive.com/wiki/index.php/Microsoft_KB_Archive/316609 ------------- PR: https://git.openjdk.java.net/jdk/pull/5460 From jboes at openjdk.java.net Fri Sep 17 09:44:51 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Fri, 17 Sep 2021 09:44:51 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v3] In-Reply-To: References: Message-ID: On Thu, 16 Sep 2021 14:05:52 GMT, Jaikiran Pai wrote: >> Julia Boes has updated the pull request incrementally with one additional commit since the last revision: >> >> correct path handling > > src/jdk.httpserver/share/classes/module-info.java line 55: > >> 53: * [-o none|info|verbose] [-h to show options] >> 54: * Options: >> 55: * -b, --bind-address - Address to bind to. Default: 0.0.0.0 (all interfaces). > > I understand that the purpose of this simple server is for development and testing only. But even then, for security considerations, would it be more appropriate to default the bind address to a loopback address instead of making it accessible potentially to entire public? In the past, application servers which used to bind to all interfaces by default have now moved to using the loopback address as a default to avoid such accidental exposing of the server. We did consider defaulting to the loopback address, but this would limit the usefulness of the server too much in the default configuration as it can only be accessed from localhost. The goal of this JEP is an out-of-the-box web server with easy setup, so in this case we favour usability. The purpose of a web server is to make things accessible on the web so it is assumed that the developer is familiar with the terms this comes with. The concern of accidental exposure is alleviated by the informative output printed at start up, e.g. ```~ $ java-sb -m jdk.httpserver Serving /current/directory and subdirectories on 0.0.0.0:8000 http://123.456.7.891:8000/ ... Considering your point though, we can spell out all interfaces and describe the URL more clearly: ```~ $ java-sb -m jdk.httpserver Serving /current/directory and subdirectories on 0.0.0.0 (all interfaces) port 8000 Localhost URL: http://123.456.7.891:8000/ ... ------------- PR: https://git.openjdk.java.net/jdk/pull/5505 From jai.forums2013 at gmail.com Fri Sep 17 09:59:36 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Fri, 17 Sep 2021 15:29:36 +0530 Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v3] In-Reply-To: References: Message-ID: Hello Julia, On 17/09/21 3:14 pm, Julia Boes wrote: > On Thu, 16 Sep 2021 14:05:52 GMT, Jaikiran Pai wrote: > >>> Julia Boes has updated the pull request incrementally with one additional commit since the last revision: >>> >>> correct path handling >> src/jdk.httpserver/share/classes/module-info.java line 55: >> >>> 53: * [-o none|info|verbose] [-h to show options] >>> 54: * Options: >>> 55: * -b, --bind-address - Address to bind to. Default: 0.0.0.0 (all interfaces). >> I understand that the purpose of this simple server is for development and testing only. But even then, for security considerations, would it be more appropriate to default the bind address to a loopback address instead of making it accessible potentially to entire public? In the past, application servers which used to bind to all interfaces by default have now moved to using the loopback address as a default to avoid such accidental exposing of the server. > We did consider defaulting to the loopback address, but this would limit the usefulness of the server too much in the default configuration as it can only be accessed from localhost. The goal of this JEP is an out-of-the-box web server with easy setup, so in this case we favour usability. The purpose of a web server is to make things accessible on the web so it is assumed that the developer is familiar with the terms this comes with. > > The concern of accidental exposure is alleviated by the informative output printed at start up, e.g. > ```~ $ java-sb -m jdk.httpserver > Serving /current/directory and subdirectories on 0.0.0.0:8000 > http://123.456.7.891:8000/ ... I think this is still a really big risk. I say this based on some of my past experience with application servers (JBoss AS) where in older releases it used to do this same thing of binding to 0.0.0.0 by default and how that had lead to numerous (production) instances ending up being vulnerable. In the case there, the management console ended up being exposed and almost anyone over the internet could just access it to shutdown the server (through a JMX MBean). In the case of this simple server being proposed, I think it's a lot more riskier because unlike in the case of the application servers where the server would have preventive measures that wouldn't allow local filesystem access, the current server being proposed will end up exposing the user's local filesystem to the internet. It's my opinion and experience that log messages no matter how much they scream out, won't prevent this default out of the box usage. I'm not saying 0.0.0.0 should be disabled, but instead, IMO it should be the user who should explicitly use -b 0.0.0.0 to do that, so that they are at least responsible and aware of what they are doing. -Jaikiran From jai.forums2013 at gmail.com Fri Sep 17 10:23:55 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Fri, 17 Sep 2021 15:53:55 +0530 Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v3] In-Reply-To: References: Message-ID: <9f86ef7e-f813-595f-2186-eb9a8b257d57@gmail.com> Hello Bernd, On 17/09/21 3:37 am, Bernd Eckenfels wrote: > I also wonder if it makes sense to either only serve files with public permissions, or at least Filter some critical files like .ssh/* and *.jks. FWIW - From what I can see in the proposed implementation as well as the JEP text, hidden files and symbolic links aren't served. So it should prevent listing/serving .ssh/ directory. -Jaikiran From alanb at openjdk.java.net Fri Sep 17 10:30:41 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 17 Sep 2021 10:30:41 GMT Subject: RFR: 8233674: JarURLConnection.getJarFile throws Exception if some process is holding the file In-Reply-To: References: Message-ID: <9ujX6rgJju5iALC4NlYltus3-7ByUQyrBy-KivlN0is=.752f854b-2b30-4808-95cd-373e066de014@github.com> On Fri, 17 Sep 2021 08:46:52 GMT, Masanori Yano wrote: > Thank you for your comment. According to Microsoft KB316609, CreateFile() should be tried again a short time later. I think JarURLConnection should also be retried when antivirus software holds some files. > https://www.betaarchive.com/wiki/index.php/Microsoft_KB_Archive/316609 This seems to be just general advice about dealing with sharing violations. I think it would be useful to hear from the Microsoft folks on whether every application on Windows is expected to retry to workaround interference from virus checkers or whether this is something that should be fixed by the virus checker vendors. If the JDK ends up putting in a workaround then it will require more broader changes, things will work inconsistently if limited to opening zip files and java.io. ------------- PR: https://git.openjdk.java.net/jdk/pull/5460 From coleenp at openjdk.java.net Fri Sep 17 12:05:47 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 17 Sep 2021 12:05:47 GMT Subject: RFR: 8266936: Add a finalization JFR event [v11] In-Reply-To: <3hNX4mQ98TyLNDmCXO4hDz8EMDoQ4ukr1Y1bvX1k8kk=.cc67221c-258a-4cac-a368-09d5fe44f245@github.com> References: <3hNX4mQ98TyLNDmCXO4hDz8EMDoQ4ukr1Y1bvX1k8kk=.cc67221c-258a-4cac-a368-09d5fe44f245@github.com> Message-ID: On Mon, 13 Sep 2021 17:12:49 GMT, Markus Gr?nlund wrote: >> Greetings, >> >> Object.finalize() was deprecated in JDK9. There is an ongoing effort to replace and mitigate Object.finalize() uses in the JDK libraries; please see https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. >> >> We also like to assist users in replacing and mitigating uses in non-JDK code. >> >> Hence, this changeset adds a periodic JFR event to help identify which classes are overriding Object.finalize(). >> >> Thanks >> Markus > > Markus Gr?nlund has updated the pull request incrementally with two additional commits since the last revision: > > - remove rehashing and rely on default grow_hint for table resize > - mtStatistics src/hotspot/share/runtime/mutexLocker.cpp line 323: > 321: > 322: #if INCLUDE_JFR > 323: def(JfrMsg_lock , PaddedMonitor, leaf-1, true, _safepoint_check_always); // -1 because the ConcurrentHashTable resize lock is leaf The ConcurrentHashTable_lock is a lock that doesn't check for safepoints, so if you take this lock out while checking for safepoints, it should assert when called from a JavaThread, which makes me think it's not called from a JavaThread and should be _safepoint_check_never. _resize_lock = new Mutex(Mutex::nosafepoint-2, "ConcurrentHashTableResize_lock", Mutex::_safepoint_check_never); In my change, this is the ranking for ConcurrentHashTableResize_lock, so this should be nosafepoint-3 if you check in after I do. ------------- PR: https://git.openjdk.java.net/jdk/pull/4731 From alanb at openjdk.java.net Fri Sep 17 12:48:46 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 17 Sep 2021 12:48:46 GMT Subject: RFR: 8193682: Infinite loop in ZipOutputStream.close() In-Reply-To: References: Message-ID: On Wed, 15 Sep 2021 07:40:35 GMT, Ravi Reddy wrote: > Hi all, > > Please review this fix for Infinite loop in ZipOutputStream.close(). > The main issue here is when ever there is an exception during close operations on GZip we are not setting the deflator to a finished state which is leading to an infinite loop when we try writing on the same GZip instance( since we use while(!def.finished()) inside the write operation). > > Thanks, > Ravi src/java.base/share/classes/java/util/zip/DeflaterOutputStream.java line 249: > 247: out.close(); > 248: closed = true; > 249: throw ioe; Have you tried using try-finally instead? ------------- PR: https://git.openjdk.java.net/jdk/pull/5522 From jpai at openjdk.java.net Fri Sep 17 12:54:07 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Fri, 17 Sep 2021 12:54:07 GMT Subject: RFR: 8258117: jar tool sets the time stamp of module-info.class entries to the current time [v2] In-Reply-To: References: Message-ID: > The commit here is a potential fix for the issue noted in https://bugs.openjdk.java.net/browse/JDK-8258117. > > The change here repurposes an existing internal interface `ModuleInfoEntry` to keep track of the last modified timestamp of a `module-info.class` descriptor. > > This commit uses the timestamp of the `module-info.class` on the filesystem to set the time on the `JarEntry`. There are a couple of cases to consider here: > > 1. When creating a jar (using `--create`), we use the source `module-info.class` from the filesystem and then add extended info to it (attributes like packages, module version etc...). In such cases, this patch will use the lastmodified timestamp from the filesystem of `module-info.class` even though we might end up updating/extending/modifying (for example by adding a module version) its content while storing it as a `JarEntry`. > > 2. When updating a jar (using `--update`), this patch will use the lastmodified timestamp of `module-info.class` either from the filesystem or from the source jar's entry (depending on whether a new `module-info.class` is being passed to the command). Here too, it's possible that we might end up changing/modifying/extending the `module-info.class` (for example, changing the module version to a new version) that gets written into the updated jar file, but this patch _won't_ use `System.currentTimeMillis()` even in such cases. > > If we do have to track actual changes that might happen to `module-info.class` while extending its info (in `extendedInfoBytes()`) and then decide whether to use current system time as last modified time, then this will require a bigger change and also a discussion on what kind of extending of module-info.class content will require a change to the lastmodifiedtime of that entry. Jaikiran Pai 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 two additional commits since the last revision: - Merge latest from master branch - 8258117: jar tool sets the time stamp of module-info.class entries to the current time ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5486/files - new: https://git.openjdk.java.net/jdk/pull/5486/files/e2193081..d91f02a3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5486&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5486&range=00-01 Stats: 5483 lines in 274 files changed: 3475 ins; 1249 del; 759 mod Patch: https://git.openjdk.java.net/jdk/pull/5486.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5486/head:pull/5486 PR: https://git.openjdk.java.net/jdk/pull/5486 From iignatyev at openjdk.java.net Fri Sep 17 13:32:48 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Fri, 17 Sep 2021 13:32:48 GMT Subject: RFR: 8273314: Add tier4 test groups [v4] In-Reply-To: References: <6rDioD5KZREYHyzOXol72O0erNDqKHUqb-0k1SwhInA=.90a12492-9e2f-4f0c-bf09-8d67d1d6111f@github.com> Message-ID: On Fri, 17 Sep 2021 06:59:09 GMT, Aleksey Shipilev wrote: >> During the review of JDK-8272914 that added hotspot:tier{2,3} groups, @iignatev suggested to create tier4 groups that capture all tests not in tiers{1,2,3}. >> >> Caveats: >> - I excluded `applications` from `hotspot:tier4`, because they require test dependencies (e.g. jcstress). >> - `jdk:tier4` only runs well with `JTREG_KEYWORDS=!headful` or reduced concurrency with `TEST_JOBS=1`, because headful tests cannot run in parallel >> >> Sample run with `JTREG_KEYWORDS=!headful`: >> >> >> ============================== >> Test summary >> ============================== >> TEST TOTAL PASS FAIL ERROR >>>> jtreg:test/hotspot/jtreg:tier4 3585 3584 0 1 << >>>> jtreg:test/jdk:tier4 2893 2887 5 1 << >> jtreg:test/langtools:tier4 0 0 0 0 >> jtreg:test/jaxp:tier4 0 0 0 0 >> ============================== >> >> real 699m39.462s >> user 6626m8.448s >> sys 1110m43.704s >> >> >> There are interesting test failures on my machine, which I would address separately. > > Aleksey Shipilev 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 five additional commits since the last revision: > > - Merge branch 'master' into JDK-8273314-tier4 > - Merge branch 'master' into JDK-8273314-tier4 > - Drop applications and fix the comment > - Drop exceptions > - Add tier4 test groups LGTM ------------- Marked as reviewed by iignatyev (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5357 From mgronlun at openjdk.java.net Fri Sep 17 13:55:45 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Fri, 17 Sep 2021 13:55:45 GMT Subject: RFR: 8266936: Add a finalization JFR event [v11] In-Reply-To: References: <3hNX4mQ98TyLNDmCXO4hDz8EMDoQ4ukr1Y1bvX1k8kk=.cc67221c-258a-4cac-a368-09d5fe44f245@github.com> Message-ID: On Fri, 17 Sep 2021 12:02:32 GMT, Coleen Phillimore wrote: >> Markus Gr?nlund has updated the pull request incrementally with two additional commits since the last revision: >> >> - remove rehashing and rely on default grow_hint for table resize >> - mtStatistics > > src/hotspot/share/runtime/mutexLocker.cpp line 323: > >> 321: >> 322: #if INCLUDE_JFR >> 323: def(JfrMsg_lock , PaddedMonitor, leaf-1, true, _safepoint_check_always); // -1 because the ConcurrentHashTable resize lock is leaf > > The ConcurrentHashTable_lock is a lock that doesn't check for safepoints, so if you take this lock out while checking for safepoints, it should assert when called from a JavaThread, which makes me think it's not called from a JavaThread and should be _safepoint_check_never. > _resize_lock = > new Mutex(Mutex::nosafepoint-2, "ConcurrentHashTableResize_lock", > Mutex::_safepoint_check_never); > In my change, this is the ranking for ConcurrentHashTableResize_lock, so this should be nosafepoint-3 if you check in after I do. Thanks, the JfrMsg_lock is acquired normally with safepoint checks when the JFR system needs to issue synchronous, blocking operations. Asynchronous operations, like message notifications, only attempt a try_lock() to avoid blocking in the case the lock is contended. The ConcurrentHashTable_lock is held during table iteration to prevent resizes from happening. Fortunately, the callback processing will only post asynchronous messages (like "Buffer full") and therefore will not reach the safepoint check. ------------- PR: https://git.openjdk.java.net/jdk/pull/4731 From jboes at openjdk.java.net Fri Sep 17 14:14:50 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Fri, 17 Sep 2021 14:14:50 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v3] In-Reply-To: References: Message-ID: On Thu, 16 Sep 2021 10:14:47 GMT, Julia Boes wrote: >> This change implements a simple web server that can be run on the command-line with `java -m jdk.httpserver`. >> >> This is facilitated by adding an entry point for the `jdk.httpserver` module, an implementation class whose main method is run when the above command is executed. This is the first such module entry point in the JDK. >> >> The server is a minimal HTTP server that serves the static files of a given directory, similar to existing alternatives on other platforms and convenient for testing, development, and debugging. >> >> Additionally, a small API is introduced for programmatic creation and customization. >> >> Testing: tier1-3. > > Julia Boes has updated the pull request incrementally with one additional commit since the last revision: > > correct path handling > _Mailing list message from [Jaikiran Pai](mailto:jai.forums2013 at gmail.com) on [build-dev](mailto:build-dev at mail.openjdk.java.net):_ > > Hello Julia, > > On 17/09/21 3:14 pm, Julia Boes wrote: > > > On Thu, 16 Sep 2021 14:05:52 GMT, Jaikiran Pai wrote: > > > > Julia Boes has updated the pull request incrementally with one additional commit since the last revision: > > > > correct path handling > > > > src/jdk.httpserver/share/classes/module-info.java line 55: > > > > > > > > > > 53: * [-o none|info|verbose] [-h to show options] > > > > 54: * Options: > > > > 55: * -b, --bind-address - Address to bind to. Default: 0.0.0.0 (all interfaces). > > > > I understand that the purpose of this simple server is for development and testing only. But even then, for security considerations, would it be more appropriate to default the bind address to a loopback address instead of making it accessible potentially to entire public? In the past, application servers which used to bind to all interfaces by default have now moved to using the loopback address as a default to avoid such accidental exposing of the server. > > > > We did consider defaulting to the loopback address, but this would limit the usefulness of the server too much in the default configuration as it can only be accessed from localhost. The goal of this JEP is an out-of-the-box web server with easy setup, so in this case we favour usability. The purpose of a web server is to make things accessible on the web so it is assumed that the developer is familiar with the terms this comes with. > > > > > > The concern of accidental exposure is alleviated by the informative output printed at start up, e.g. > > ```~ $ java-sb -m jdk.httpserver > > Serving /current/directory and subdirectories on 0.0.0.0:8000 > > http://123.456.7.891:8000/ ... > > I think this is still a really big risk. I say this based on some of my > past experience with application servers (JBoss AS) where in older > releases it used to do this same thing of binding to 0.0.0.0 by default > and how that had lead to numerous (production) instances ending up being > vulnerable. In the case there, the management console ended up being > exposed and almost anyone over the internet could just access it to > shutdown the server (through a JMX MBean). > > In the case of this simple server being proposed, I think it's a lot > more riskier because unlike in the case of the application servers where > the server would have preventive measures that wouldn't allow local > filesystem access, the current server being proposed will end up > exposing the user's local filesystem to the internet. It's my opinion > and experience that log messages no matter how much they scream out, > won't prevent this default out of the box usage. > > I'm not saying 0.0.0.0 should be disabled, but instead, IMO it should be > the user who should explicitly use -b 0.0.0.0 to do that, so that they > are at least responsible and aware of what they are doing. > > -Jaikiran Thanks for sharing your experience on this, it's appreciated. 0.0.0.0 is common default for Apache httpd [1], Ngnix [2], the Python web server [3]. This being said, I want to make sure we're taking the right decision here so let me seek some further advice on this. [1] http://httpd.apache.org/docs/2.4/bind.html [2] https://docs.nginx.com/nginx/admin-guide/web-server/web-server/ [3] https://github.com/python/cpython/blob/3.4/Lib/http/server.py ------------- PR: https://git.openjdk.java.net/jdk/pull/5505 From jboes at openjdk.java.net Fri Sep 17 14:35:43 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Fri, 17 Sep 2021 14:35:43 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v3] In-Reply-To: References: Message-ID: On Thu, 16 Sep 2021 10:14:47 GMT, Julia Boes wrote: >> This change implements a simple web server that can be run on the command-line with `java -m jdk.httpserver`. >> >> This is facilitated by adding an entry point for the `jdk.httpserver` module, an implementation class whose main method is run when the above command is executed. This is the first such module entry point in the JDK. >> >> The server is a minimal HTTP server that serves the static files of a given directory, similar to existing alternatives on other platforms and convenient for testing, development, and debugging. >> >> Additionally, a small API is introduced for programmatic creation and customization. >> >> Testing: tier1-3. > > Julia Boes has updated the pull request incrementally with one additional commit since the last revision: > > correct path handling > _Mailing list message from [Jaikiran Pai](mailto:jai.forums2013 at gmail.com) on [core-libs-dev](mailto:core-libs-dev at mail.openjdk.java.net):_ > > Hello Bernd, > > On 17/09/21 3:37 am, Bernd Eckenfels wrote: > > > I also wonder if it makes sense to either only serve files with public permissions, or at least Filter some critical files like .ssh/* and *.jks. > > FWIW - From what I can see in the proposed implementation as well as the > JEP text, hidden files and symbolic links aren't served. So it should > prevent listing/serving .ssh/ directory. > > -Jaikiran File system access is checked for the root directory and the requested resource (summarized in the CSR [1]). You're right that hidden files, symbolic links, and not-readable files are not served. Looking at the example of `.ssh/*`, I realize we missed the case where a component of the request path is hidden (or not readable), rather than the requested resource itself. For example, if `/` is the server's root directory, a request of `http://host:port/.ssl/config` would be successful because config is not hidden. A request of `http://host:port/.ssl` would get a 404. I'll update this to apply the isHidden and isReadable checks to the requested resource *as well as* all components of its path. No further group/owner/other permissions are checked - that's a can of worms we didn't want to get in to, given that this server is really not appropriate for serving file hierarchies that contain sensitive information. Again, it's a simple tool for development and testing purposes only. [1] https://bugs.openjdk.java.net/browse/JDK-8272571 ------------- PR: https://git.openjdk.java.net/jdk/pull/5505 From ccheung at openjdk.java.net Fri Sep 17 15:12:43 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 17 Sep 2021 15:12:43 GMT Subject: RFR: 8273774: CDSPluginTest should only expect classes_nocoops.jsa exists on supported 64-bit platforms [v5] In-Reply-To: References: <6UsB0ppKiipNg3JnMjcHSvKCIpFKnRSaii_BO_OAZlo=.1a501d24-2cb1-4f66-8c44-dfa570a89aad@github.com> Message-ID: On Fri, 17 Sep 2021 02:17:09 GMT, Remilia Scarlet wrote: >> The test assumes that it always runs on 64-bit platform and classes_nocoops.jsa is always created. >> It's a test bug. The test should only expect classes_nocoops.jsa exists if it's running on a supported 64-bit platform. >> However, for unknown target platform, it's unknown if it's 64-bit or not. >> >> This patch fix the test to check if classes_nocoops.jsa exists only on one of the JDK supported platforms (x64 or aarch64) via the sun.arch.data.model system property. >> >> Please review this change. Thanks! > > Remilia Scarlet has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > 8273774: CDSPluginTest should only expect classes_nocoops.jsa exists on supported 64-bit platforms Looks good and thanks for fixing this bug. ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5519 From github.com+27751938+amcap1712 at openjdk.java.net Fri Sep 17 15:15:50 2021 From: github.com+27751938+amcap1712 at openjdk.java.net (Kartik Ohri) Date: Fri, 17 Sep 2021 15:15:50 GMT Subject: Integrated: 8273681: Add Vector API vs Arrays.mismatch intrinsic benchmark In-Reply-To: <4KB5kKx9tx7ORFdIm3DvI_A4Udv16Vd-RFSHHIsCZoI=.0a05541b-051a-4009-b198-b4f0a576cb5c@github.com> References: <4KB5kKx9tx7ORFdIm3DvI_A4Udv16Vd-RFSHHIsCZoI=.0a05541b-051a-4009-b198-b4f0a576cb5c@github.com> Message-ID: On Fri, 10 Sep 2021 08:32:02 GMT, Kartik Ohri wrote: > Hi all! > > Please review this PR to add a benchmark comparing the performance of Arrays.mismatch intrinsic in the JDK with that of the Vector API. Kindly refer to this [thread] on panama-dev regarding some initial discussion about this benchmark. I have attached the [results] of the full benchmark run along with the [assembly] output of a shorter run I had done while analysing the results. The benchmarks were run against the latest build of panama-vector available from builds.shipilev.net. > > Also, I have not added the copyright header to this file yet as I am an individual contributor (OCA signed) and do not know what to put there. > > [thread]: https://mail.openjdk.java.net/pipermail/panama-dev/2021-September/014839.html > [results]: https://github.com/openjdk/jdk/files/7142452/results.csv > [assembly]: https://github.com/openjdk/jdk/files/7142362/benchmarks.txt > > Regards, > Kartik This pull request has now been integrated. Changeset: 2f8c2211 Author: Kartik Ohri Committer: Paul Sandoz URL: https://git.openjdk.java.net/jdk/commit/2f8c2211c8c7f9661e283c8df914fde5bda197a6 Stats: 229 lines in 1 file changed: 229 ins; 0 del; 0 mod 8273681: Add Vector API vs Arrays.mismatch intrinsic benchmark Reviewed-by: psandoz ------------- PR: https://git.openjdk.java.net/jdk/pull/5459 From psandoz at openjdk.java.net Fri Sep 17 15:16:40 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Fri, 17 Sep 2021 15:16:40 GMT Subject: RFR: 8247980: Exclusive execution of java/util/stream tests slows down tier1 In-Reply-To: References: Message-ID: On Wed, 25 Aug 2021 15:52:06 GMT, Igor Ignatyev wrote: >> See the bug report for more details. I would appreciate if people with their corporate testing systems would run this through their systems to avoid surprises. (ping @RealCLanger, @iignatev). > > the testing in our infra returned green. > @iignatev, @PaulSandoz, @AlanBateman -- are you good with integrating this? Yes, lets give it a try. ------------- PR: https://git.openjdk.java.net/jdk/pull/5189 From rriggs at openjdk.java.net Fri Sep 17 16:14:46 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 17 Sep 2021 16:14:46 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v7] In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 18:31:43 GMT, Roger Riggs wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> dummy commit to trigger GitHub actions job to try and reproduce an unexplained failure with the new tests that happened around 24 hours back, this time yesterday (rule out any time/date/timezone specific issues) > > src/java.base/share/classes/java/util/Properties.java line 887: > >> 885: * If the value set for {@code SOURCE_DATE_EPOCH} cannot be parsed to a {@code long}, >> 886: * then the current date and time will be written. >> 887: * > > Update to refer to the property and add the {@systemProperty ...} javadoc tag so the property is listed in the system property reference. "different set implementation" as part of the spec may challenge the compatibility test developers to prove or disprove that statement. The type of an instance is frequently understood to be the "implementation". The visible type returned from Properties.entrySet() is SynchronizedSet. Anyone can create one of those. That statement might mislead a subclass into thinking they can not/must not return a SynchronizedSet if they want the built-in sorting. I'm thinking that wording it in other term of the subclass might be better: "...sort order of the keys in the entrySet() unless entrySet() is overridden by a subclass to return a different value than 'super.entrySet'(). " The existing implementation is fine. ------------- PR: https://git.openjdk.java.net/jdk/pull/5372 From naoto at openjdk.java.net Fri Sep 17 16:21:09 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 17 Sep 2021 16:21:09 GMT Subject: RFR: 8273187: jtools tests fail with missing markerName check Message-ID: Fixing failing regression tests caused by the JEP 400: UTF-8 by Default. `JcmdOutputEncodingTest` test case uses `file.encoding=UTF-8` in `C` locale. The output from the agent library is in `UTF-8` so it succeeded before the JEP has been implemented, as System.out used `UTF-8` converter. After the JEP, it started failing because System.out is using `US-ASCII` which generates series of '?', ending up with assertion failure in the test. The proposed fix is to pass `sun.stdout.encoding=UTF-8` as well as `file.encoding` so that tool process' System.out is in `UTF-8` as well. ------------- Commit messages: - Merge branch 'master' into JDK-8273187 - Reverted command encoding, then modified the test case to use sun.stdout.encoding - Used `transferTo()` - Merge branch 'master' into JDK-8273187 - Nuked UTF-8 conversion in tools - Merge branch 'master' into JDK-8273187 - 8273187: jtools tests fail with missing markerName check Changes: https://git.openjdk.java.net/jdk/pull/5539/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5539&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273187 Stats: 10 lines in 3 files changed: 3 ins; 4 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5539.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5539/head:pull/5539 PR: https://git.openjdk.java.net/jdk/pull/5539 From github.com+22913521+1996scarlet at openjdk.java.net Fri Sep 17 16:45:47 2021 From: github.com+22913521+1996scarlet at openjdk.java.net (Remilia Scarlet) Date: Fri, 17 Sep 2021 16:45:47 GMT Subject: Integrated: 8273774: CDSPluginTest should only expect classes_nocoops.jsa exists on supported 64-bit platforms In-Reply-To: <6UsB0ppKiipNg3JnMjcHSvKCIpFKnRSaii_BO_OAZlo=.1a501d24-2cb1-4f66-8c44-dfa570a89aad@github.com> References: <6UsB0ppKiipNg3JnMjcHSvKCIpFKnRSaii_BO_OAZlo=.1a501d24-2cb1-4f66-8c44-dfa570a89aad@github.com> Message-ID: On Wed, 15 Sep 2021 06:28:25 GMT, Remilia Scarlet wrote: > The test assumes that it always runs on 64-bit platform and classes_nocoops.jsa is always created. > It's a test bug. The test should only expect classes_nocoops.jsa exists if it's running on a supported 64-bit platform. > However, for unknown target platform, it's unknown if it's 64-bit or not. > > This patch fix the test to check if classes_nocoops.jsa exists only on one of the JDK supported platforms (x64 or aarch64) via the sun.arch.data.model system property. > > Please review this change. Thanks! This pull request has now been integrated. Changeset: 83020617 Author: sunxu Committer: Calvin Cheung URL: https://git.openjdk.java.net/jdk/commit/83020617e70d40a42029720534af561f8af8bce2 Stats: 13 lines in 1 file changed: 11 ins; 0 del; 2 mod 8273774: CDSPluginTest should only expect classes_nocoops.jsa exists on supported 64-bit platforms Reviewed-by: ccheung, mchung ------------- PR: https://git.openjdk.java.net/jdk/pull/5519 From iris at openjdk.java.net Fri Sep 17 17:24:45 2021 From: iris at openjdk.java.net (Iris Clark) Date: Fri, 17 Sep 2021 17:24:45 GMT Subject: RFR: 8273187: jtools tests fail with missing markerName check In-Reply-To: References: Message-ID: On Thu, 16 Sep 2021 01:08:45 GMT, Naoto Sato wrote: > Fixing failing regression tests caused by the JEP 400: UTF-8 by Default. > > `JcmdOutputEncodingTest` test case uses `file.encoding=UTF-8` in `C` locale. The output from the agent library is in `UTF-8` so it succeeded before the JEP has been implemented, as System.out used `UTF-8` converter. After the JEP, it started failing because System.out is using `US-ASCII` which generates series of '?', ending up with assertion failure in the test. > > The proposed fix is to pass `sun.stdout.encoding=UTF-8` as well as `file.encoding` so that tool process' System.out is in `UTF-8` as well. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5539 From sspitsyn at openjdk.java.net Fri Sep 17 17:42:48 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 17 Sep 2021 17:42:48 GMT Subject: RFR: 8273187: jtools tests fail with missing markerName check In-Reply-To: References: Message-ID: <2igC6NMnbo2GEIUVXjzhQq-gBtbF_QzGh9zlL-9sdRs=.b9d196fe-6e16-4c16-bf55-a217c62be009@github.com> On Thu, 16 Sep 2021 01:08:45 GMT, Naoto Sato wrote: > Fixing failing regression tests caused by the JEP 400: UTF-8 by Default. > > `JcmdOutputEncodingTest` test case uses `file.encoding=UTF-8` in `C` locale. The output from the agent library is in `UTF-8` so it succeeded before the JEP has been implemented, as System.out used `UTF-8` converter. After the JEP, it started failing because System.out is using `US-ASCII` which generates series of '?', ending up with assertion failure in the test. > > The proposed fix is to pass `sun.stdout.encoding=UTF-8` as well as `file.encoding` so that tool process' System.out is in `UTF-8` as well. Marked as reviewed by sspitsyn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5539 From joehw at openjdk.java.net Fri Sep 17 17:47:48 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Fri, 17 Sep 2021 17:47:48 GMT Subject: RFR: 8273187: jtools tests fail with missing markerName check In-Reply-To: References: Message-ID: On Thu, 16 Sep 2021 01:08:45 GMT, Naoto Sato wrote: > Fixing failing regression tests caused by the JEP 400: UTF-8 by Default. > > `JcmdOutputEncodingTest` test case uses `file.encoding=UTF-8` in `C` locale. The output from the agent library is in `UTF-8` so it succeeded before the JEP has been implemented, as System.out used `UTF-8` converter. After the JEP, it started failing because System.out is using `US-ASCII` which generates series of '?', ending up with assertion failure in the test. > > The proposed fix is to pass `sun.stdout.encoding=UTF-8` as well as `file.encoding` so that tool process' System.out is in `UTF-8` as well. Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5539 From jpai at openjdk.java.net Sat Sep 18 03:52:17 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Sat, 18 Sep 2021 03:52:17 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v21] In-Reply-To: References: Message-ID: > The commit in this PR implements the proposal for enhancement that was discussed in the core-libs-dev mailing list recently[1], for https://bugs.openjdk.java.net/browse/JDK-8231640 > > At a high level - the `store()` APIs in `Properties` have been modified to now look for the `SOURCE_DATE_EPOCH` environment variable[2]. If that env variable is set, then instead of writing out the current date time as a date comment, the `store()` APIs instead will use the value set for this env variable to parse it to a `Date` and write out the string form of such a date. The implementation here uses the `d MMM yyyy HH:mm:ss 'GMT'` date format and `Locale.ROOT` to format and write out such a date. This should provide reproducibility whenever the `SOURCE_DATE_EPOCH` is set. Furthermore, intentionally, no changes in the date format of the "current date" have been done. > > These modified `store()` APIs work in the presence of the `SecurityManager` too. The caller is expected to have a read permission on the `SOURCE_DATE_EPOCH` environment variable. If the caller doesn't have that permission, then the implementation of these `store()` APIs will write out the "current date" and will ignore any value that has been set for the `SOURCE_DATE_EPOCH` env variable. This should allow for backward compatibility of existing applications, where, when they run under a `SecurityManager` and perhaps with an existing restrictive policy file, the presence of `SOURCE_DATE_EPOCH` shouldn't impact their calls to the `store()` APIs. > > The modified `store()` APIs will also ignore any value for `SOURCE_DATE_EPOCH` that cannot be parsed to an `long` value. In such cases, the `store()` APIs will write out the "current date" and ignore the value set for this environment variable. No exceptions will be thrown for such invalid values. This is an additional backward compatibility precaution to prevent any rogue value for `SOURCE_DATE_EPOCH` from breaking applications. > > An additional change in the implementation of these `store()` APIs and unrelated to the date comment, is that these APIs will now write out the property keys in a deterministic order. The keys will be written out in the natural ordering as specified by `java.lang.String#compareTo()` API. > > The combination of the ordering of the property keys when written out and the usage of `SOURCE_DATE_EPOCH` environment value to determine the date comment should together allow for reproducibility of the output generated by these `store()` APIs. > > New jtreg test classes have been introduced to verify these changes. The primary focus of `PropertiesStoreTest` is the ordering aspects of the property keys that are written out. On the other hand `StoreReproducibilityTest` focuses on the reproducibility of the output generated by these APIs. The `StoreReproducibilityTest` runs these tests both in the presence and absence of `SecurityManager`. Plus, in the presence of SecurityManager, it tests both the scenarios where the caller is granted the requisite permission and in other case not granted that permission. > > These new tests and existing tests under `test/jdk/java/util/Properties/` pass with these changes. > > [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-August/080758.html > [2] https://reproducible-builds.org/specs/source-date-epoch/ Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: Roger's suggestion to reword the implSpec text ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5372/files - new: https://git.openjdk.java.net/jdk/pull/5372/files/458c1fd3..e350721a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5372&range=20 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5372&range=19-20 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5372.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5372/head:pull/5372 PR: https://git.openjdk.java.net/jdk/pull/5372 From jpai at openjdk.java.net Sat Sep 18 03:52:18 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Sat, 18 Sep 2021 03:52:18 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v7] In-Reply-To: <7B56t7n0aOwS6xwADw4dRcUGx2qQb9TWeOlOI_kdLD0=.351fe9f8-b91b-4611-a9c7-ee50d9c56924@github.com> References: <7B56t7n0aOwS6xwADw4dRcUGx2qQb9TWeOlOI_kdLD0=.351fe9f8-b91b-4611-a9c7-ee50d9c56924@github.com> Message-ID: <1HMIPD5vaBY8cuzsBN0Yp2Z1wUtPb-rSp1138qJR6U4=.109ca67b-4fcc-463b-992b-bb19bb61d5a4@github.com> On Fri, 17 Sep 2021 17:10:10 GMT, Daniel Fuchs wrote: >> "different set implementation" as part of the spec may challenge the compatibility test developers to prove or disprove that statement. >> The type of an instance is frequently understood to be the "implementation". >> The visible type returned from Properties.entrySet() is SynchronizedSet. >> Anyone can create one of those. >> That statement might mislead a subclass into thinking they can not/must not return a SynchronizedSet if they want the built-in sorting. >> I'm thinking that wording it in other term of the subclass might be better: >> "...sort order of the keys in the entrySet() unless entrySet() is overridden by a subclass to return a different value than 'super.entrySet'(). " >> The existing implementation is fine. > > I agree that this is a better formulation than what I suggested :-) Done. I've updated the PR to use Roger's suggested text and yes it's much more precise than what we had so far. ------------- PR: https://git.openjdk.java.net/jdk/pull/5372 From dholmes at openjdk.java.net Sun Sep 19 13:15:51 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Sun, 19 Sep 2021 13:15:51 GMT Subject: RFR: 8273314: Add tier4 test groups [v4] In-Reply-To: References: <6rDioD5KZREYHyzOXol72O0erNDqKHUqb-0k1SwhInA=.90a12492-9e2f-4f0c-bf09-8d67d1d6111f@github.com> Message-ID: On Fri, 17 Sep 2021 06:59:09 GMT, Aleksey Shipilev wrote: >> During the review of JDK-8272914 that added hotspot:tier{2,3} groups, @iignatev suggested to create tier4 groups that capture all tests not in tiers{1,2,3}. >> >> Caveats: >> - I excluded `applications` from `hotspot:tier4`, because they require test dependencies (e.g. jcstress). >> - `jdk:tier4` only runs well with `JTREG_KEYWORDS=!headful` or reduced concurrency with `TEST_JOBS=1`, because headful tests cannot run in parallel >> >> Sample run with `JTREG_KEYWORDS=!headful`: >> >> >> ============================== >> Test summary >> ============================== >> TEST TOTAL PASS FAIL ERROR >>>> jtreg:test/hotspot/jtreg:tier4 3585 3584 0 1 << >>>> jtreg:test/jdk:tier4 2893 2887 5 1 << >> jtreg:test/langtools:tier4 0 0 0 0 >> jtreg:test/jaxp:tier4 0 0 0 0 >> ============================== >> >> real 699m39.462s >> user 6626m8.448s >> sys 1110m43.704s >> >> >> There are interesting test failures on my machine, which I would address separately. > > Aleksey Shipilev 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 five additional commits since the last revision: > > - Merge branch 'master' into JDK-8273314-tier4 > - Merge branch 'master' into JDK-8273314-tier4 > - Drop applications and fix the comment > - Drop exceptions > - Add tier4 test groups I abstain - you have your reviews. Cheers, David ------------- PR: https://git.openjdk.java.net/jdk/pull/5357 From shade at openjdk.java.net Mon Sep 20 07:40:59 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 20 Sep 2021 07:40:59 GMT Subject: RFR: 8273314: Add tier4 test groups [v4] In-Reply-To: References: <6rDioD5KZREYHyzOXol72O0erNDqKHUqb-0k1SwhInA=.90a12492-9e2f-4f0c-bf09-8d67d1d6111f@github.com> Message-ID: On Fri, 17 Sep 2021 06:59:09 GMT, Aleksey Shipilev wrote: >> During the review of JDK-8272914 that added hotspot:tier{2,3} groups, @iignatev suggested to create tier4 groups that capture all tests not in tiers{1,2,3}. >> >> Caveats: >> - I excluded `applications` from `hotspot:tier4`, because they require test dependencies (e.g. jcstress). >> - `jdk:tier4` only runs well with `JTREG_KEYWORDS=!headful` or reduced concurrency with `TEST_JOBS=1`, because headful tests cannot run in parallel >> >> Sample run with `JTREG_KEYWORDS=!headful`: >> >> >> ============================== >> Test summary >> ============================== >> TEST TOTAL PASS FAIL ERROR >>>> jtreg:test/hotspot/jtreg:tier4 3585 3584 0 1 << >>>> jtreg:test/jdk:tier4 2893 2887 5 1 << >> jtreg:test/langtools:tier4 0 0 0 0 >> jtreg:test/jaxp:tier4 0 0 0 0 >> ============================== >> >> real 699m39.462s >> user 6626m8.448s >> sys 1110m43.704s >> >> >> There are interesting test failures on my machine, which I would address separately. > > Aleksey Shipilev 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 five additional commits since the last revision: > > - Merge branch 'master' into JDK-8273314-tier4 > - Merge branch 'master' into JDK-8273314-tier4 > - Drop applications and fix the comment > - Drop exceptions > - Add tier4 test groups All right, there goes. ------------- PR: https://git.openjdk.java.net/jdk/pull/5357 From shade at openjdk.java.net Mon Sep 20 07:41:01 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 20 Sep 2021 07:41:01 GMT Subject: RFR: 8247980: Exclusive execution of java/util/stream tests slows down tier1 In-Reply-To: References: Message-ID: On Thu, 19 Aug 2021 15:15:31 GMT, Aleksey Shipilev wrote: > See the bug report for more details. I would appreciate if people with their corporate testing systems would run this through their systems to avoid surprises. (ping @RealCLanger, @iignatev). Ok, let's try! ------------- PR: https://git.openjdk.java.net/jdk/pull/5189 From adinn at openjdk.java.net Mon Sep 20 09:55:55 2021 From: adinn at openjdk.java.net (Andrew Dinn) Date: Mon, 20 Sep 2021 09:55:55 GMT Subject: RFR: 8268231: Aarch64: Use ldp in intrinsics for String.compareTo [v6] In-Reply-To: References: <_XL6WybKwHeJ54kSQnN_q0_NgvR7ib9BFjNJ4HrkO_g=.f82e6cda-b31f-4eee-9185-3e52ebd6b54d@github.com> Message-ID: <2lOynSpsbUNNtPnEX_vLx2O2n9M1tO3RdBGoKEiOiO0=.fa1caf71-5e7a-4325-b6bd-6745eb0ba668@github.com> On Fri, 17 Sep 2021 07:13:24 GMT, Wu Yan wrote: >> It's fine. I don't think it'll affect any real programs, so it's rather pointless. I don't know if that's any reason not to approve it. > > Andrew, can you help us to approve this? I agree with Andrew Haley that this patch is not going to make an improvement for anything but a very small number of applications. Processing of strings over a few 10s of bytes is rare. On the other hand the doesn't seem to cause any performance drop for the much more common case of processing short strings. so it does no harm. Also, the new and old code are much the same in terms of complexity so that is no reason to prefer one over the other. The only real concern I have is that any change involves the risk of error and the ratio of cases that might benefit to cases that might suffer from an error is very low. I don't think that's a reason to avoid pushing this patch upstream but it does suggest that we should not backport it. ------------- PR: https://git.openjdk.java.net/jdk/pull/4722 From aph at openjdk.java.net Mon Sep 20 10:13:10 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Mon, 20 Sep 2021 10:13:10 GMT Subject: RFR: 8268231: Aarch64: Use ldp in intrinsics for String.compareTo [v7] In-Reply-To: References: Message-ID: On Mon, 30 Aug 2021 06:26:01 GMT, Wang Huang wrote: >> Dear all, >> Can you do me a favor to review this patch. This patch use `ldp` to implement String.compareTo. >> >> * We add a JMH test case >> * Here is the result of this test case >> >> Benchmark |(size)| Mode| Cnt|Score | Error |Units >> ---------------------------------|------|-----|----|------|--------|----- >> StringCompare.compareLL | 64 | avgt| 5 |7.992 | ? 0.005|us/op >> StringCompare.compareLL | 72 | avgt| 5 |15.029| ? 0.006|us/op >> StringCompare.compareLL | 80 | avgt| 5 |14.655| ? 0.011|us/op >> StringCompare.compareLL | 91 | avgt| 5 |16.363| ? 0.12 |us/op >> StringCompare.compareLL | 101 | avgt| 5 |16.966| ? 0.007|us/op >> StringCompare.compareLL | 121 | avgt| 5 |19.276| ? 0.006|us/op >> StringCompare.compareLL | 181 | avgt| 5 |19.002| ? 0.417|us/op >> StringCompare.compareLL | 256 | avgt| 5 |24.707| ? 0.041|us/op >> StringCompare.compareLLWithLdp| 64 | avgt| 5 |8.001 | ? 0.121|us/op >> StringCompare.compareLLWithLdp| 72 | avgt| 5 |11.573| ? 0.003|us/op >> StringCompare.compareLLWithLdp| 80 | avgt| 5 |6.861 | ? 0.004|us/op >> StringCompare.compareLLWithLdp| 91 | avgt| 5 |12.774| ? 0.201|us/op >> StringCompare.compareLLWithLdp| 101 | avgt| 5 |8.691 | ? 0.004|us/op >> StringCompare.compareLLWithLdp| 121 | avgt| 5 |11.091| ? 1.342|us/op >> StringCompare.compareLLWithLdp| 181 | avgt| 5 |14.64 | ? 0.581|us/op >> StringCompare.compareLLWithLdp| 256 | avgt| 5 |25.879| ? 1.775|us/op >> StringCompare.compareUU | 64 | avgt| 5 |13.476| ? 0.01 |us/op >> StringCompare.compareUU | 72 | avgt| 5 |15.078| ? 0.006|us/op >> StringCompare.compareUU | 80 | avgt| 5 |23.512| ? 0.011|us/op >> StringCompare.compareUU | 91 | avgt| 5 |24.284| ? 0.008|us/op >> StringCompare.compareUU | 101 | avgt| 5 |20.707| ? 0.017|us/op >> StringCompare.compareUU | 121 | avgt| 5 |29.302| ? 0.011|us/op >> StringCompare.compareUU | 181 | avgt| 5 |39.31 | ? 0.016|us/op >> StringCompare.compareUU | 256 | avgt| 5 |54.592| ? 0.392|us/op >> StringCompare.compareUUWithLdp| 64 | avgt| 5 |16.389| ? 0.008|us/op >> StringCompare.compareUUWithLdp| 72 | avgt| 5 |10.71 | ? 0.158|us/op >> StringCompare.compareUUWithLdp| 80 | avgt| 5 |11.488| ? 0.024|us/op >> StringCompare.compareUUWithLdp| 91 | avgt| 5 |13.412| ? 0.006|us/op >> StringCompare.compareUUWithLdp| 101 | avgt| 5 |16.245| ? 0.434|us/op >> StringCompare.compareUUWithLdp| 121 | avgt| 5 |16.597| ? 0.016|us/op >> StringCompare.compareUUWithLdp| 181 | avgt| 5 |27.373| ? 0.017|us/op >> StringCompare.compareUUWithLdp| 256 | avgt| 5 |41.74 | ? 3.5 |us/op >> >> From this table, we can see that in most cases, our patch is better than old one. >> >> Thank you for your review. Any suggestions are welcome. > > Wang Huang has updated the pull request incrementally with one additional commit since the last revision: > > fix windows build failed Marked as reviewed by aph (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4722 From aph at openjdk.java.net Mon Sep 20 10:13:10 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Mon, 20 Sep 2021 10:13:10 GMT Subject: RFR: 8268231: Aarch64: Use ldp in intrinsics for String.compareTo [v6] In-Reply-To: <2lOynSpsbUNNtPnEX_vLx2O2n9M1tO3RdBGoKEiOiO0=.fa1caf71-5e7a-4325-b6bd-6745eb0ba668@github.com> References: <_XL6WybKwHeJ54kSQnN_q0_NgvR7ib9BFjNJ4HrkO_g=.f82e6cda-b31f-4eee-9185-3e52ebd6b54d@github.com> <2lOynSpsbUNNtPnEX_vLx2O2n9M1tO3RdBGoKEiOiO0=.fa1caf71-5e7a-4325-b6bd-6745eb0ba668@github.com> Message-ID: On Mon, 20 Sep 2021 09:52:45 GMT, Andrew Dinn wrote: >> Andrew, can you help us to approve this? > > I agree with Andrew Haley that this patch is not going to make an improvement for anything but a very small number of applications. Processing of strings over a few 10s of bytes is rare. On the other hand the doesn't seem to cause any performance drop for the much more common case of processing short strings. so it does no harm. Also, the new and old code are much the same in terms of complexity so that is no reason to prefer one over the other. The only real concern I have is that any change involves the risk of error and the ratio of cases that might benefit to cases that might suffer from an error is very low. I don't think that's a reason to avoid pushing this patch upstream but it does suggest that we should not backport it. OK, thanks. That seems like a sensible compromise. ------------- PR: https://git.openjdk.java.net/jdk/pull/4722 From lancea at openjdk.java.net Mon Sep 20 11:23:21 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 20 Sep 2021 11:23:21 GMT Subject: RFR: 8273935: (zipfs) Files.getFileAttributeView() throws UOE instead of returning null when view not supported Message-ID: Hi all, Please review this patch which addresses the issue where Zip FS will throw a UOE instead of returning null when Files.getFileAttributeView() is invoked and the view not supported. Mach5 tiers1 - tier3 are clean. Best Lance ------------- Commit messages: - Add Cleanup Method - adjust copyright - Files.getFileAttributeView() throws UOE instead of returning null when view not supported Changes: https://git.openjdk.java.net/jdk/pull/5579/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5579&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273935 Stats: 107 lines in 3 files changed: 103 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/5579.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5579/head:pull/5579 PR: https://git.openjdk.java.net/jdk/pull/5579 From ihse at openjdk.java.net Mon Sep 20 11:29:49 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 20 Sep 2021 11:29:49 GMT Subject: RFR: 8273797: Stop impersonating "server" VM in all VM variants In-Reply-To: References: Message-ID: On Wed, 15 Sep 2021 10:02:19 GMT, Aleksey Shipilev wrote: > As the follow-up for Zero-specific JDK-8273494, we might want to clean up build system logic for all VM variants: stop impersonating "server" VMs for all of them. This basically leaves "core" and "custom" variants to be handled with this patch. > > Additional testing: > - [x] Linux x86_64 `core` build passes, `libjvm.so` now in `core`, `jvm.cfg` mentions `-core KNOWN` > - [x] Linux x86_64 `custom` (+serialgc,+compiler2) build passes, `libjvm.so` now in `custom`, `jvm.cfg` mentions `-custom KNOWN` Marked as reviewed by ihse (Reviewer). Looks good. Thanks for waiting for my input; sorry for the delay. ------------- PR: https://git.openjdk.java.net/jdk/pull/5526 From alanb at openjdk.java.net Mon Sep 20 11:33:58 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 20 Sep 2021 11:33:58 GMT Subject: RFR: 8273935: (zipfs) Files.getFileAttributeView() throws UOE instead of returning null when view not supported In-Reply-To: References: Message-ID: <1dFdOqhAEE23RUb_-3dq26cgFAnLlMm5UvBrpt9l2XU=.7c43b1a8-4414-4f9e-8831-9e6791a47e6d@github.com> On Sun, 19 Sep 2021 15:34:44 GMT, Lance Andersen wrote: > Hi all, > > Please review this patch which addresses the issue where Zip FS will throw a UOE instead of returning null when Files.getFileAttributeView() is invoked and the view not supported. > > Mach5 tiers1 - tier3 are clean. > > Best > Lance Marked as reviewed by alanb (Reviewer). src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipPath.java line 716: > 714: return (V)new ZipPosixFileAttributeView(this,true); > 715: } > 716: return (V) null; I assume (V) isn't needed here. test/jdk/jdk/nio/zipfs/testng/test/PosixAttributeViewTest.java line 59: > 57: public void setup() throws IOException { > 58: Files.deleteIfExists(ZIP_FILE); > 59: Entry e0 = Entry.of(ZIP_ENTRY, ZipEntry.DEFLATED, Is there a reason why this is named "e0"? test/jdk/jdk/nio/zipfs/testng/test/PosixAttributeViewTest.java line 82: > 80: return new Object[][]{ > 81: {Map.of()}, > 82: { Map.of("enablePosixFileAttributes", "true")} Minor nit, inconsistent formatting with L81 vs. L82. test/jdk/jdk/nio/zipfs/testng/test/PosixAttributeViewTest.java line 89: > 87: * Verify that Files.getFileAttributeView will not throw > 88: * UnsupportedOperationException when the attribute view > 89: * PosixFileAttributeView is not available Might be clearer to say that it checks that Files.getFileAttributeView does not throw an exception (no need to mention UOE) when PosixFileAttributeView is not supported. test/jdk/jdk/nio/zipfs/testng/test/PosixAttributeViewTest.java line 95: > 93: @Test(dataProvider = "zipfsMap") > 94: public void testPosixAttributeView(Map env) throws Exception { > 95: Spurious blank line. ------------- PR: https://git.openjdk.java.net/jdk/pull/5579 From ihse at openjdk.java.net Mon Sep 20 11:35:08 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 20 Sep 2021 11:35:08 GMT Subject: RFR: 8273797: Stop impersonating "server" VM in all VM variants In-Reply-To: References: Message-ID: On Wed, 15 Sep 2021 10:02:19 GMT, Aleksey Shipilev wrote: > As the follow-up for Zero-specific JDK-8273494, we might want to clean up build system logic for all VM variants: stop impersonating "server" VMs for all of them. This basically leaves "core" and "custom" variants to be handled with this patch. > > Additional testing: > - [x] Linux x86_64 `core` build passes, `libjvm.so` now in `core`, `jvm.cfg` mentions `-core KNOWN` > - [x] Linux x86_64 `custom` (+serialgc,+compiler2) build passes, `libjvm.so` now in `custom`, `jvm.cfg` mentions `-custom KNOWN` As for eliminating multi-JVM builds: yes, that is on my agenda, but as long as I'm still just working part-time it's hard to make any headway in that direction. The next step is to create a `--with-import-jvms=,[,...]`, so that it is possible to simulate a multi-JVM build by e.g. bash configure --with-jvm-variant=zero --with-conf-name=zero-hotspot make hotspot bash configure --with-jvm-variant=server --with-conf-name=combined --with-import-jvms=zero:./build/$PLATFORM/jdk/lib/zero or something like that. When that exists and is working, and all downstream users has had time to adapt, then we can remove multi-JVM build support (and boy am I longing for that day). If you want to help by implementing the `--with-import-jvms` options, you are more than welcome! ------------- PR: https://git.openjdk.java.net/jdk/pull/5526 From rriggs at openjdk.java.net Mon Sep 20 13:01:29 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 20 Sep 2021 13:01:29 GMT Subject: RFR: 8272600: (test) Use native "sleep" in Basic.java [v6] In-Reply-To: References: Message-ID: > The intermittent test in java/lang/ProcessBuilder/Basic.java has identified unexpected messages from a child Java VM > as the cause of the test failure. Attempts to control the output of the child VM have failed, the VM is unrepentant . > > There is no functionality in the child except to wait long enough for the test to finish and the child is destroyed. > The fix is to switch from using a Java child to using a native child; a new executable `sleepmillis`. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: The switch from a Java child to /bin/sleep caused another test to fail on Linux. The cleanup for a test used /usr/bin/pkill "sleep 60". A race between that cleanup and subsequent tests that used sleep 60 or 600 could kill the sleep before the test of waitFor completed. Changing the test using pkill to use 59 seconds makes the test cleanup selective to the sleep spawned for that test. The test that was failing (lines 2626-2624) passes consistently. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5239/files - new: https://git.openjdk.java.net/jdk/pull/5239/files/43a54802..afa932d6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5239&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5239&range=04-05 Stats: 25 lines in 1 file changed: 7 ins; 10 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/5239.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5239/head:pull/5239 PR: https://git.openjdk.java.net/jdk/pull/5239 From dfuchs at openjdk.java.net Mon Sep 20 13:08:01 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Mon, 20 Sep 2021 13:08:01 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v21] In-Reply-To: References: Message-ID: On Sat, 18 Sep 2021 03:52:17 GMT, Jaikiran Pai wrote: >> The commit in this PR implements the proposal for enhancement that was discussed in the core-libs-dev mailing list recently[1], for https://bugs.openjdk.java.net/browse/JDK-8231640 >> >> At a high level - the `store()` APIs in `Properties` have been modified to now look for the `SOURCE_DATE_EPOCH` environment variable[2]. If that env variable is set, then instead of writing out the current date time as a date comment, the `store()` APIs instead will use the value set for this env variable to parse it to a `Date` and write out the string form of such a date. The implementation here uses the `d MMM yyyy HH:mm:ss 'GMT'` date format and `Locale.ROOT` to format and write out such a date. This should provide reproducibility whenever the `SOURCE_DATE_EPOCH` is set. Furthermore, intentionally, no changes in the date format of the "current date" have been done. >> >> These modified `store()` APIs work in the presence of the `SecurityManager` too. The caller is expected to have a read permission on the `SOURCE_DATE_EPOCH` environment variable. If the caller doesn't have that permission, then the implementation of these `store()` APIs will write out the "current date" and will ignore any value that has been set for the `SOURCE_DATE_EPOCH` env variable. This should allow for backward compatibility of existing applications, where, when they run under a `SecurityManager` and perhaps with an existing restrictive policy file, the presence of `SOURCE_DATE_EPOCH` shouldn't impact their calls to the `store()` APIs. >> >> The modified `store()` APIs will also ignore any value for `SOURCE_DATE_EPOCH` that cannot be parsed to an `long` value. In such cases, the `store()` APIs will write out the "current date" and ignore the value set for this environment variable. No exceptions will be thrown for such invalid values. This is an additional backward compatibility precaution to prevent any rogue value for `SOURCE_DATE_EPOCH` from breaking applications. >> >> An additional change in the implementation of these `store()` APIs and unrelated to the date comment, is that these APIs will now write out the property keys in a deterministic order. The keys will be written out in the natural ordering as specified by `java.lang.String#compareTo()` API. >> >> The combination of the ordering of the property keys when written out and the usage of `SOURCE_DATE_EPOCH` environment value to determine the date comment should together allow for reproducibility of the output generated by these `store()` APIs. >> >> New jtreg test classes have been introduced to verify these changes. The primary focus of `PropertiesStoreTest` is the ordering aspects of the property keys that are written out. On the other hand `StoreReproducibilityTest` focuses on the reproducibility of the output generated by these APIs. The `StoreReproducibilityTest` runs these tests both in the presence and absence of `SecurityManager`. Plus, in the presence of SecurityManager, it tests both the scenarios where the caller is granted the requisite permission and in other case not granted that permission. >> >> These new tests and existing tests under `test/jdk/java/util/Properties/` pass with these changes. >> >> [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-August/080758.html >> [2] https://reproducible-builds.org/specs/source-date-epoch/ > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Roger's suggestion to reword the implSpec text Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5372 From mgronlun at openjdk.java.net Mon Sep 20 13:20:59 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 20 Sep 2021 13:20:59 GMT Subject: RFR: 8272515: JFR: Names should only be valid Java identifiers In-Reply-To: References: Message-ID: On Wed, 8 Sep 2021 13:00:17 GMT, Erik Gahlin wrote: > Hi, > > Could I have a review of change that prevents invalid Java identifiers or type names in JFR events. For rationale and compatibility issues see the CSR request. The only change to java.base is making jdk.modules.internal.Checks::isJavaIdentifier(String) public, so it can be reused by the jdk.jfr module. > > Testing: /jdk/jdk/jfr + tier1 + tier2 > > Thanks > Erik Looks good. ------------- Marked as reviewed by mgronlun (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5415 From naoto at openjdk.java.net Mon Sep 20 13:43:01 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 20 Sep 2021 13:43:01 GMT Subject: Integrated: 8273187: jtools tests fail with missing markerName check In-Reply-To: References: Message-ID: On Thu, 16 Sep 2021 01:08:45 GMT, Naoto Sato wrote: > Fixing failing regression tests caused by the JEP 400: UTF-8 by Default. > > `JcmdOutputEncodingTest` test case uses `file.encoding=UTF-8` in `C` locale. The output from the agent library is in `UTF-8` so it succeeded before the JEP has been implemented, as System.out used `UTF-8` converter. After the JEP, it started failing because System.out is using `US-ASCII` which generates series of '?', ending up with assertion failure in the test. > > The proposed fix is to pass `sun.stdout.encoding=UTF-8` as well as `file.encoding` so that tool process' System.out is in `UTF-8` as well. This pull request has now been integrated. Changeset: f71df142 Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/f71df142a97f522b40e90c3105e0e5bd8d5af9a2 Stats: 10 lines in 3 files changed: 3 ins; 4 del; 3 mod 8273187: jtools tests fail with missing markerName check Reviewed-by: iris, sspitsyn, joehw ------------- PR: https://git.openjdk.java.net/jdk/pull/5539 From shade at openjdk.java.net Mon Sep 20 14:07:06 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 20 Sep 2021 14:07:06 GMT Subject: Integrated: 8273314: Add tier4 test groups In-Reply-To: <6rDioD5KZREYHyzOXol72O0erNDqKHUqb-0k1SwhInA=.90a12492-9e2f-4f0c-bf09-8d67d1d6111f@github.com> References: <6rDioD5KZREYHyzOXol72O0erNDqKHUqb-0k1SwhInA=.90a12492-9e2f-4f0c-bf09-8d67d1d6111f@github.com> Message-ID: <2EIwJmplZv9-2ffL0Ye4pf3tgPEsx7HPhu-oM54T8Hk=.129e646b-333d-4ba1-b65d-ddd9ca731d2a@github.com> On Fri, 3 Sep 2021 09:10:20 GMT, Aleksey Shipilev wrote: > During the review of JDK-8272914 that added hotspot:tier{2,3} groups, @iignatev suggested to create tier4 groups that capture all tests not in tiers{1,2,3}. > > Caveats: > - I excluded `applications` from `hotspot:tier4`, because they require test dependencies (e.g. jcstress). > - `jdk:tier4` only runs well with `JTREG_KEYWORDS=!headful` or reduced concurrency with `TEST_JOBS=1`, because headful tests cannot run in parallel > > Sample run with `JTREG_KEYWORDS=!headful`: > > > ============================== > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR >>> jtreg:test/hotspot/jtreg:tier4 3585 3584 0 1 << >>> jtreg:test/jdk:tier4 2893 2887 5 1 << > jtreg:test/langtools:tier4 0 0 0 0 > jtreg:test/jaxp:tier4 0 0 0 0 > ============================== > > real 699m39.462s > user 6626m8.448s > sys 1110m43.704s > > > There are interesting test failures on my machine, which I would address separately. This pull request has now been integrated. Changeset: 1f8af524 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/1f8af524ffe2d2d1469d8f07887b1f61c6e4d7b8 Stats: 20 lines in 4 files changed: 20 ins; 0 del; 0 mod 8273314: Add tier4 test groups Reviewed-by: serb, iignatyev ------------- PR: https://git.openjdk.java.net/jdk/pull/5357 From shade at openjdk.java.net Mon Sep 20 14:09:02 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 20 Sep 2021 14:09:02 GMT Subject: Integrated: 8247980: Exclusive execution of java/util/stream tests slows down tier1 In-Reply-To: References: Message-ID: On Thu, 19 Aug 2021 15:15:31 GMT, Aleksey Shipilev wrote: > See the bug report for more details. I would appreciate if people with their corporate testing systems would run this through their systems to avoid surprises. (ping @RealCLanger, @iignatev). This pull request has now been integrated. Changeset: 544193a3 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/544193a3bb6431ee4bb0bd43cb29cc60c7709b25 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8247980: Exclusive execution of java/util/stream tests slows down tier1 Reviewed-by: iignatyev ------------- PR: https://git.openjdk.java.net/jdk/pull/5189 From turbanoff at gmail.com Mon Sep 20 15:19:39 2021 From: turbanoff at gmail.com (Andrey Turbanov) Date: Mon, 20 Sep 2021 18:19:39 +0300 Subject: Condition is always false in 'ProcessHandleImpl.Info#toString' Message-ID: Hello. I found suspicious code in the method java.lang.ProcessHandleImpl.Info#toString https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/ProcessHandleImpl.java#L645 ``` StringBuilder sb = new StringBuilder(60); sb.append('['); if (user != null) { sb.append("user: "); sb.append(user()); } if (command != null) { if (sb.length() != 0) sb.append(", "); sb.append("cmd: "); sb.append(command); } ``` Opening bracket '[' is added unconditionally to the StringBuilder. But then the code checks "if (sb.length() != 0)" This condition will always be *false*. Looks like comparison with 1 should be used instead. Andrey Turbanov From jboes at openjdk.java.net Mon Sep 20 15:28:05 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Mon, 20 Sep 2021 15:28:05 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v4] In-Reply-To: References: Message-ID: > This change implements a simple web server that can be run on the command-line with `java -m jdk.httpserver`. > > This is facilitated by adding an entry point for the `jdk.httpserver` module, an implementation class whose main method is run when the above command is executed. This is the first such module entry point in the JDK. > > The server is a minimal HTTP server that serves the static files of a given directory, similar to existing alternatives on other platforms and convenient for testing, development, and debugging. > > Additionally, a small API is introduced for programmatic creation and customization. > > Testing: tier1-3. Julia Boes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: - Merge branch 'master' into simpleserver - check isHidden, isSymlink, isReadable for all path segments - add checks for all path segments - Merge branch 'master' into componentcheck - Merge branch 'master' into simpleserver - improve output on startup - correct path handling - small spec rewording - add module main class to symbolgenerator - remove UnmodifiableHeaders constant - ... and 2 more: https://git.openjdk.java.net/jdk/compare/4d95a5d6...10523290 ------------- Changes: https://git.openjdk.java.net/jdk/pull/5505/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5505&range=03 Stats: 7034 lines in 43 files changed: 6998 ins; 15 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/5505.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5505/head:pull/5505 PR: https://git.openjdk.java.net/jdk/pull/5505 From sundararajan.athijegannathan at oracle.com Mon Sep 20 15:31:20 2021 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 20 Sep 2021 15:31:20 +0000 Subject: Condition is always false in 'ProcessHandleImpl.Info#toString' In-Reply-To: References: Message-ID: Thanks for reporting. Filed: https://bugs.openjdk.java.net/browse/JDK-8274003 -Sundar ________________________________ From: core-libs-dev on behalf of Andrey Turbanov Sent: 20 September 2021 20:49 To: core-libs-dev Subject: Condition is always false in 'ProcessHandleImpl.Info#toString' Hello. I found suspicious code in the method java.lang.ProcessHandleImpl.Info#toString https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/ProcessHandleImpl.java#L645 ``` StringBuilder sb = new StringBuilder(60); sb.append('['); if (user != null) { sb.append("user: "); sb.append(user()); } if (command != null) { if (sb.length() != 0) sb.append(", "); sb.append("cmd: "); sb.append(command); } ``` Opening bracket '[' is added unconditionally to the StringBuilder. But then the code checks "if (sb.length() != 0)" This condition will always be *false*. Looks like comparison with 1 should be used instead. Andrey Turbanov From egahlin at openjdk.java.net Mon Sep 20 15:47:56 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Mon, 20 Sep 2021 15:47:56 GMT Subject: Integrated: 8272515: JFR: Names should only be valid Java identifiers In-Reply-To: References: Message-ID: On Wed, 8 Sep 2021 13:00:17 GMT, Erik Gahlin wrote: > Hi, > > Could I have a review of change that prevents invalid Java identifiers or type names in JFR events. For rationale and compatibility issues see the CSR request. The only change to java.base is making jdk.modules.internal.Checks::isJavaIdentifier(String) public, so it can be reused by the jdk.jfr module. > > Testing: /jdk/jdk/jfr + tier1 + tier2 > > Thanks > Erik This pull request has now been integrated. Changeset: 48aff231 Author: Erik Gahlin URL: https://git.openjdk.java.net/jdk/commit/48aff23165db668eb9c06477d16a8e72b6dc6b56 Stats: 308 lines in 11 files changed: 259 ins; 23 del; 26 mod 8272515: JFR: Names should only be valid Java identifiers Reviewed-by: mgronlun ------------- PR: https://git.openjdk.java.net/jdk/pull/5415 From dfuchs at openjdk.java.net Mon Sep 20 16:12:57 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Mon, 20 Sep 2021 16:12:57 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v4] In-Reply-To: References: Message-ID: On Mon, 20 Sep 2021 15:28:05 GMT, Julia Boes wrote: >> This change implements a simple web server that can be run on the command-line with `java -m jdk.httpserver`. >> >> This is facilitated by adding an entry point for the `jdk.httpserver` module, an implementation class whose main method is run when the above command is executed. This is the first such module entry point in the JDK. >> >> The server is a minimal HTTP server that serves the static files of a given directory, similar to existing alternatives on other platforms and convenient for testing, development, and debugging. >> >> Additionally, a small API is introduced for programmatic creation and customization. >> >> Testing: tier1-3. > > Julia Boes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: > > - Merge branch 'master' into simpleserver > - check isHidden, isSymlink, isReadable for all path segments > - add checks for all path segments > - Merge branch 'master' into componentcheck > - Merge branch 'master' into simpleserver > - improve output on startup > - correct path handling > - small spec rewording > - add module main class to symbolgenerator > - remove UnmodifiableHeaders constant > - ... and 2 more: https://git.openjdk.java.net/jdk/compare/4d95a5d6...10523290 src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/FileServerHandler.java line 340: > 338: } > 339: } > 340: return false; This will start checking from the root of the file system. I believe we want to start checking from the root of the FileServerHandler, root excluded. ------------- PR: https://git.openjdk.java.net/jdk/pull/5505 From dfuchs at openjdk.java.net Mon Sep 20 16:19:29 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Mon, 20 Sep 2021 16:19:29 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v4] In-Reply-To: References: Message-ID: On Mon, 20 Sep 2021 16:09:14 GMT, Daniel Fuchs wrote: >> Julia Boes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: >> >> - Merge branch 'master' into simpleserver >> - check isHidden, isSymlink, isReadable for all path segments >> - add checks for all path segments >> - Merge branch 'master' into componentcheck >> - Merge branch 'master' into simpleserver >> - improve output on startup >> - correct path handling >> - small spec rewording >> - add module main class to symbolgenerator >> - remove UnmodifiableHeaders constant >> - ... and 2 more: https://git.openjdk.java.net/jdk/compare/4d95a5d6...10523290 > > src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/FileServerHandler.java line 340: > >> 338: } >> 339: } >> 340: return false; > > This will start checking from the root of the file system. I believe we want to start checking from the root of the FileServerHandler, root excluded. Maybe these checks should be made in `mapToPath` instead since you already walk the path there - and IIRC returning null from `mapToPath` will cause HTTP 404. ------------- PR: https://git.openjdk.java.net/jdk/pull/5505 From sgehwolf at openjdk.java.net Mon Sep 20 17:08:54 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Mon, 20 Sep 2021 17:08:54 GMT Subject: RFR: 8273935: (zipfs) Files.getFileAttributeView() throws UOE instead of returning null when view not supported In-Reply-To: References: Message-ID: On Sun, 19 Sep 2021 15:34:44 GMT, Lance Andersen wrote: > Hi all, > > Please review this patch which addresses the issue where Zip FS will throw a UOE instead of returning null when Files.getFileAttributeView() is invoked and the view not supported. > > Mach5 tiers1 - tier3 are clean. > > Best > Lance test/jdk/jdk/nio/zipfs/testng/test/PosixAttributeViewTest.java line 100: > 98: PosixFileAttributeView view = Files.getFileAttributeView(entry, > 99: PosixFileAttributeView.class); > 100: System.out.printf("View returned: %s%n", view); It might be useful to also print whether the environment is empty: Suggestion: `System.out.printf("View returned: %s, (empty_env=%s)%n", view, env.isEmpty());` ------------- PR: https://git.openjdk.java.net/jdk/pull/5579 From bpb at openjdk.java.net Mon Sep 20 17:13:09 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 20 Sep 2021 17:13:09 GMT Subject: RFR: 8273935: (zipfs) Files.getFileAttributeView() throws UOE instead of returning null when view not supported In-Reply-To: References: Message-ID: On Sun, 19 Sep 2021 15:34:44 GMT, Lance Andersen wrote: > Hi all, > > Please review this patch which addresses the issue where Zip FS will throw a UOE instead of returning null when Files.getFileAttributeView() is invoked and the view not supported. > > Mach5 tiers1 - tier3 are clean. > > Best > Lance Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5579 From lancea at openjdk.java.net Mon Sep 20 18:08:49 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 20 Sep 2021 18:08:49 GMT Subject: RFR: 8273935: (zipfs) Files.getFileAttributeView() throws UOE instead of returning null when view not supported In-Reply-To: <1dFdOqhAEE23RUb_-3dq26cgFAnLlMm5UvBrpt9l2XU=.7c43b1a8-4414-4f9e-8831-9e6791a47e6d@github.com> References: <1dFdOqhAEE23RUb_-3dq26cgFAnLlMm5UvBrpt9l2XU=.7c43b1a8-4414-4f9e-8831-9e6791a47e6d@github.com> Message-ID: On Mon, 20 Sep 2021 11:28:10 GMT, Alan Bateman wrote: >> Hi all, >> >> Please review this patch which addresses the issue where Zip FS will throw a UOE instead of returning null when Files.getFileAttributeView() is invoked and the view not supported. >> >> Mach5 tiers1 - tier3 are clean. >> >> Best >> Lance > > src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipPath.java line 716: > >> 714: return (V)new ZipPosixFileAttributeView(this,true); >> 715: } >> 716: return (V) null; > > I assume (V) isn't needed here. No, it is not and can also probably be removed from open/src/java.base/unix/classes/sun/nio/fs/UnixFileSystemProvider.java at some point > test/jdk/jdk/nio/zipfs/testng/test/PosixAttributeViewTest.java line 59: > >> 57: public void setup() throws IOException { >> 58: Files.deleteIfExists(ZIP_FILE); >> 59: Entry e0 = Entry.of(ZIP_ENTRY, ZipEntry.DEFLATED, > > Is there a reason why this is named "e0"? Not really. Historically that was the variable name format used in some of the Zip FS tests. I changed the name to `entry` > test/jdk/jdk/nio/zipfs/testng/test/PosixAttributeViewTest.java line 82: > >> 80: return new Object[][]{ >> 81: {Map.of()}, >> 82: { Map.of("enablePosixFileAttributes", "true")} > > Minor nit, inconsistent formatting with L81 vs. L82. Fixed, thanks for catching that. > test/jdk/jdk/nio/zipfs/testng/test/PosixAttributeViewTest.java line 89: > >> 87: * Verify that Files.getFileAttributeView will not throw >> 88: * UnsupportedOperationException when the attribute view >> 89: * PosixFileAttributeView is not available > > Might be clearer to say that it checks that Files.getFileAttributeView does not throw an exception (no need to mention UOE) when PosixFileAttributeView is not supported. Updated per your suggestion! > test/jdk/jdk/nio/zipfs/testng/test/PosixAttributeViewTest.java line 95: > >> 93: @Test(dataProvider = "zipfsMap") >> 94: public void testPosixAttributeView(Map env) throws Exception { >> 95: > > Spurious blank line. Removed. ------------- PR: https://git.openjdk.java.net/jdk/pull/5579 From lancea at openjdk.java.net Mon Sep 20 18:08:50 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 20 Sep 2021 18:08:50 GMT Subject: RFR: 8273935: (zipfs) Files.getFileAttributeView() throws UOE instead of returning null when view not supported In-Reply-To: References: Message-ID: <3bWbP-B1UC3dkCFcixhXyVw6IQPmaPsXG2-5MV3qnY0=.a78bd0f5-f3ef-41d7-87c4-caa40b921c40@github.com> On Mon, 20 Sep 2021 17:05:33 GMT, Severin Gehwolf wrote: >> Hi all, >> >> Please review this patch which addresses the issue where Zip FS will throw a UOE instead of returning null when Files.getFileAttributeView() is invoked and the view not supported. >> >> Mach5 tiers1 - tier3 are clean. >> >> Best >> Lance > > test/jdk/jdk/nio/zipfs/testng/test/PosixAttributeViewTest.java line 100: > >> 98: PosixFileAttributeView view = Files.getFileAttributeView(entry, >> 99: PosixFileAttributeView.class); >> 100: System.out.printf("View returned: %s%n", view); > > It might be useful to also print whether the environment is empty: > Suggestion: `System.out.printf("View returned: %s, (empty_env=%s)%n", view, env.isEmpty());` Well, you can see that whether the Map is/is not empty in the jtr file for the test run (based on the DataProvider Properties for a given run). However, per your suggestion, I tweaked the test to dump the Map values. ------------- PR: https://git.openjdk.java.net/jdk/pull/5579 From lancea at openjdk.java.net Mon Sep 20 18:15:33 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 20 Sep 2021 18:15:33 GMT Subject: RFR: 8273935: (zipfs) Files.getFileAttributeView() throws UOE instead of returning null when view not supported [v2] In-Reply-To: References: Message-ID: > Hi all, > > Please review this patch which addresses the issue where Zip FS will throw a UOE instead of returning null when Files.getFileAttributeView() is invoked and the view not supported. > > Mach5 tiers1 - tier3 are clean. > > Best > Lance Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: Updates based on feedback ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5579/files - new: https://git.openjdk.java.net/jdk/pull/5579/files/e814a9f1..6ff49197 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5579&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5579&range=00-01 Stats: 12 lines in 3 files changed: 1 ins; 2 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/5579.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5579/head:pull/5579 PR: https://git.openjdk.java.net/jdk/pull/5579 From lancea at openjdk.java.net Mon Sep 20 18:17:29 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 20 Sep 2021 18:17:29 GMT Subject: RFR: 8273935: (zipfs) Files.getFileAttributeView() throws UOE instead of returning null when view not supported [v3] In-Reply-To: References: Message-ID: > Hi all, > > Please review this patch which addresses the issue where Zip FS will throw a UOE instead of returning null when Files.getFileAttributeView() is invoked and the view not supported. > > Mach5 tiers1 - tier3 are clean. > > Best > Lance Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: fix minor typo ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5579/files - new: https://git.openjdk.java.net/jdk/pull/5579/files/6ff49197..65184a5a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5579&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5579&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5579.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5579/head:pull/5579 PR: https://git.openjdk.java.net/jdk/pull/5579 From mchung at openjdk.java.net Mon Sep 20 18:35:57 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 20 Sep 2021 18:35:57 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v8] In-Reply-To: <5V0eAcrG9rS-d9RnyC2oJ5kVo6v84IhyBn40M71mYUg=.5d8c17fe-a23b-49a8-bfef-f670c0f013eb@github.com> References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> <5V0eAcrG9rS-d9RnyC2oJ5kVo6v84IhyBn40M71mYUg=.5d8c17fe-a23b-49a8-bfef-f670c0f013eb@github.com> Message-ID: On Wed, 1 Sep 2021 01:05:32 GMT, Mandy Chung wrote: >> This reimplements core reflection with method handles. >> >> For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. >> >> The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. >> >> The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. >> >> Ran tier1-tier8 tests. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8013527 >> [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > minor cleanup and more test case. Thanks for doing the Jackson (de)serialization benchmark. I'll follow up with Claes when he returns from vacation end of this week and see if we can agree that performance improvements can be explored as follows-up works. ------------- PR: https://git.openjdk.java.net/jdk/pull/5027 From alanb at openjdk.java.net Mon Sep 20 18:35:56 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 20 Sep 2021 18:35:56 GMT Subject: RFR: 8273935: (zipfs) Files.getFileAttributeView() throws UOE instead of returning null when view not supported [v3] In-Reply-To: References: Message-ID: On Mon, 20 Sep 2021 18:17:29 GMT, Lance Andersen wrote: >> Hi all, >> >> Please review this patch which addresses the issue where Zip FS will throw a UOE instead of returning null when Files.getFileAttributeView() is invoked and the view not supported. >> >> Mach5 tiers1 - tier3 are clean. >> >> Best >> Lance > > Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: > > fix minor typo Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5579 From bpb at openjdk.java.net Mon Sep 20 18:42:57 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 20 Sep 2021 18:42:57 GMT Subject: RFR: 8273935: (zipfs) Files.getFileAttributeView() throws UOE instead of returning null when view not supported [v3] In-Reply-To: References: Message-ID: On Mon, 20 Sep 2021 18:17:29 GMT, Lance Andersen wrote: >> Hi all, >> >> Please review this patch which addresses the issue where Zip FS will throw a UOE instead of returning null when Files.getFileAttributeView() is invoked and the view not supported. >> >> Mach5 tiers1 - tier3 are clean. >> >> Best >> Lance > > Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: > > fix minor typo Marked as reviewed by bpb (Reviewer). Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5579 From swpalmer at gmail.com Mon Sep 20 21:37:18 2021 From: swpalmer at gmail.com (Scott Palmer) Date: Mon, 20 Sep 2021 17:37:18 -0400 Subject: What causes java.lang.InternalError: platform encoding not initialized ? Message-ID: This is likely not the right place to ask this (sorry).. but I'm trying to get info to write a bug report and want to make sure I'm not doing something stupid first. I've created a JRE image from JDK 17 with jlink. I've made an application image with jpackage. I've moved the default location of the runtime in the application image and modified the launcher .cfg file accordingly by adding a line to the [Application] section app.runtime=$APPDIR\..\my_own_folder\where_the_jre_is_deeper\jre My application launches. It shows a JavaFX GUI. It does a bunch of stuff that "works", but then one thread fails with this exception: Exception in thread "Reader-BG-1" java.lang.InternalError: platform encoding not initialized at java.base/java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method) at java.base/java.net.InetAddress$PlatformNameService.lookupAllHostAddr(InetAddress.java:933) at java.base/java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1519) at java.base/java.net.InetAddress$NameServiceAddresses.get(InetAddress.java:852) at java.base/java.net.InetAddress.getAllByName0(InetAddress.java:1509) at java.base/java.net.InetAddress.getAllByName(InetAddress.java:1367) at java.base/java.net.InetAddress.getAllByName(InetAddress.java:1301) at java.base/java.net.InetAddress.getByName(InetAddress.java:1251) at java.base/java.net.InetSocketAddress.(InetSocketAddress.java:229) at java.base/sun.net.NetworkClient.doConnect(NetworkClient.java:178) at java.base/sun.net.www.http.HttpClient.openServer(HttpClient.java:498) at java.base/sun.net.www.http.HttpClient.openServer(HttpClient.java:603) at java.base/sun.net.www.protocol.https.HttpsClient.(HttpsClient.java:266) at java.base/sun.net.www.protocol.https.HttpsClient.New(HttpsClient.java:380) at java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.getNewHttpClient(AbstractDelegateHttpsURLConnection.java:189) at java.base/sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1242) at java.base/sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:1128) at java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:175) at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1665) at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1589) at java.base/java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:529) at java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:308) If I keep the runtime in $APPDIR\runtime, things don't fail in this way. Smells like a bug in the app launcher to me.. but maybe it's in the runtime? Any assistance would be appreciated (including telling me where I should go to ask this, if this list isn't appropriate). Thanks, Scott From kevin.rushforth at oracle.com Mon Sep 20 22:09:29 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 20 Sep 2021 15:09:29 -0700 Subject: What causes java.lang.InternalError: platform encoding not initialized ? In-Reply-To: References: Message-ID: > I've made an > application image with jpackage. I've moved the default location of the > runtime in the application image > ... > If I keep the runtime in $APPDIR\runtime, things don't fail in this way. If it works when using the default location of the Java runtime and no other changes, I'd guess that this is a bug in the jpackage app launcher, or maybe in the code that creates the runtime (e.g., if something isn't copied to the right place when not in the default location). Hopefully Andy or Alexey can comment. -- Kevin On 9/20/2021 2:37 PM, Scott Palmer wrote: > This is likely not the right place to ask this (sorry).. but I'm trying to > get info to write a bug report and want to make sure I'm not doing > something stupid first. > > I've created a JRE image from JDK 17 with jlink. I've made an > application image with jpackage. I've moved the default location of the > runtime in the application image and modified the launcher .cfg file > accordingly by adding a line to the [Application] section > > app.runtime=$APPDIR\..\my_own_folder\where_the_jre_is_deeper\jre > > My application launches. It shows a JavaFX GUI. It does a bunch of stuff > that "works", but then one thread fails with this exception: > > Exception in thread "Reader-BG-1" java.lang.InternalError: platform > encoding not initialized > at java.base/java.net.Inet6AddressImpl.lookupAllHostAddr(Native > Method) > at > java.base/java.net.InetAddress$PlatformNameService.lookupAllHostAddr(InetAddress.java:933) > at > java.base/java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1519) > at > java.base/java.net.InetAddress$NameServiceAddresses.get(InetAddress.java:852) > at > java.base/java.net.InetAddress.getAllByName0(InetAddress.java:1509) > at > java.base/java.net.InetAddress.getAllByName(InetAddress.java:1367) > at > java.base/java.net.InetAddress.getAllByName(InetAddress.java:1301) > at java.base/java.net.InetAddress.getByName(InetAddress.java:1251) > at > java.base/java.net.InetSocketAddress.(InetSocketAddress.java:229) > at java.base/sun.net.NetworkClient.doConnect(NetworkClient.java:178) > at > java.base/sun.net.www.http.HttpClient.openServer(HttpClient.java:498) > at > java.base/sun.net.www.http.HttpClient.openServer(HttpClient.java:603) > at > java.base/sun.net.www.protocol.https.HttpsClient.(HttpsClient.java:266) > at > java.base/sun.net.www.protocol.https.HttpsClient.New(HttpsClient.java:380) > at > java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.getNewHttpClient(AbstractDelegateHttpsURLConnection.java:189) > at > java.base/sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1242) > at > java.base/sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:1128) > at > java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:175) > at > java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1665) > at > java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1589) > at > java.base/java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:529) > at > java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:308) > > If I keep the runtime in $APPDIR\runtime, things don't fail in this way. > > Smells like a bug in the app launcher to me.. but maybe it's in the runtime? > > Any assistance would be appreciated (including telling me where I should go > to ask this, if this list isn't appropriate). > > Thanks, > > Scott From joe.darcy at oracle.com Tue Sep 21 02:00:57 2021 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Mon, 20 Sep 2021 19:00:57 -0700 Subject: Confusing javadoc on a method java.lang.StringBuilder#readObject In-Reply-To: References: Message-ID: <29ab071c-4c2c-6b37-a436-f0f80d4fe72b@oracle.com> On 9/8/2021 1:28 PM, Andrey Turbanov wrote: > Hello. > I found a confusing javadoc of the method java.lang.StringBuilder#readObject: > > "readObject is called to restore the state of the StringBuffer from a stream." > > I believe there should be "StringBuilder" instead of "StringBuffer". Agreed; filed ??? JDK-8274031: Typo in StringBuilder.readObject Thanks, -Joe From darcy at openjdk.java.net Tue Sep 21 02:19:05 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 21 Sep 2021 02:19:05 GMT Subject: RFR: 8274031: Typo in StringBuilder.readObject Message-ID: Fix of a typo in the javadoc of StringBuilder,readObject, as previously reported to core-libs-dev: https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-September/081277.html ------------- Commit messages: - Fix for JDK-8274031. Changes: https://git.openjdk.java.net/jdk/pull/5592/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5592&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274031 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5592.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5592/head:pull/5592 PR: https://git.openjdk.java.net/jdk/pull/5592 From bpb at openjdk.java.net Tue Sep 21 02:22:57 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 21 Sep 2021 02:22:57 GMT Subject: RFR: 8274031: Typo in StringBuilder.readObject In-Reply-To: References: Message-ID: On Tue, 21 Sep 2021 02:06:47 GMT, Joe Darcy wrote: > Fix of a typo in the javadoc of StringBuilder,readObject, as previously reported to core-libs-dev: > > https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-September/081277.html Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5592 From darcy at openjdk.java.net Tue Sep 21 02:27:52 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 21 Sep 2021 02:27:52 GMT Subject: Integrated: 8274031: Typo in StringBuilder.readObject In-Reply-To: References: Message-ID: <2kuiBX6ZNXjQxl95WJVxjo4EuTUrI75HmtUGZ0e3BZI=.42011375-a75e-4ab2-a11c-3a3cb422d121@github.com> On Tue, 21 Sep 2021 02:06:47 GMT, Joe Darcy wrote: > Fix of a typo in the javadoc of StringBuilder,readObject, as previously reported to core-libs-dev: > > https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-September/081277.html This pull request has now been integrated. Changeset: 9c91ff57 Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/9c91ff57e8b4b48e997e0424ff93b29e695ec527 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8274031: Typo in StringBuilder.readObject Reviewed-by: bpb ------------- PR: https://git.openjdk.java.net/jdk/pull/5592 From jpai at openjdk.java.net Tue Sep 21 03:46:54 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 21 Sep 2021 03:46:54 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v21] In-Reply-To: References: Message-ID: On Sat, 18 Sep 2021 03:52:17 GMT, Jaikiran Pai wrote: >> The commit in this PR implements the proposal for enhancement that was discussed in the core-libs-dev mailing list recently[1], for https://bugs.openjdk.java.net/browse/JDK-8231640 >> >> At a high level - the `store()` APIs in `Properties` have been modified to now look for the `SOURCE_DATE_EPOCH` environment variable[2]. If that env variable is set, then instead of writing out the current date time as a date comment, the `store()` APIs instead will use the value set for this env variable to parse it to a `Date` and write out the string form of such a date. The implementation here uses the `d MMM yyyy HH:mm:ss 'GMT'` date format and `Locale.ROOT` to format and write out such a date. This should provide reproducibility whenever the `SOURCE_DATE_EPOCH` is set. Furthermore, intentionally, no changes in the date format of the "current date" have been done. >> >> These modified `store()` APIs work in the presence of the `SecurityManager` too. The caller is expected to have a read permission on the `SOURCE_DATE_EPOCH` environment variable. If the caller doesn't have that permission, then the implementation of these `store()` APIs will write out the "current date" and will ignore any value that has been set for the `SOURCE_DATE_EPOCH` env variable. This should allow for backward compatibility of existing applications, where, when they run under a `SecurityManager` and perhaps with an existing restrictive policy file, the presence of `SOURCE_DATE_EPOCH` shouldn't impact their calls to the `store()` APIs. >> >> The modified `store()` APIs will also ignore any value for `SOURCE_DATE_EPOCH` that cannot be parsed to an `long` value. In such cases, the `store()` APIs will write out the "current date" and ignore the value set for this environment variable. No exceptions will be thrown for such invalid values. This is an additional backward compatibility precaution to prevent any rogue value for `SOURCE_DATE_EPOCH` from breaking applications. >> >> An additional change in the implementation of these `store()` APIs and unrelated to the date comment, is that these APIs will now write out the property keys in a deterministic order. The keys will be written out in the natural ordering as specified by `java.lang.String#compareTo()` API. >> >> The combination of the ordering of the property keys when written out and the usage of `SOURCE_DATE_EPOCH` environment value to determine the date comment should together allow for reproducibility of the output generated by these `store()` APIs. >> >> New jtreg test classes have been introduced to verify these changes. The primary focus of `PropertiesStoreTest` is the ordering aspects of the property keys that are written out. On the other hand `StoreReproducibilityTest` focuses on the reproducibility of the output generated by these APIs. The `StoreReproducibilityTest` runs these tests both in the presence and absence of `SecurityManager`. Plus, in the presence of SecurityManager, it tests both the scenarios where the caller is granted the requisite permission and in other case not granted that permission. >> >> These new tests and existing tests under `test/jdk/java/util/Properties/` pass with these changes. >> >> [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-August/080758.html >> [2] https://reproducible-builds.org/specs/source-date-epoch/ > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Roger's suggestion to reword the implSpec text What would be the next step to move the CSR forward? Should I be changing it's status or do something else? ------------- PR: https://git.openjdk.java.net/jdk/pull/5372 From joe.darcy at oracle.com Tue Sep 21 03:58:17 2021 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Mon, 20 Sep 2021 20:58:17 -0700 Subject: RFR: 8231640: (prop) Canonical property storage [v21] In-Reply-To: References: Message-ID: Hello Jaikiran, The CSR is in Draft state. As discussed in the CSR wiki (https://wiki.openjdk.java.net/display/csr/Main), the request needs to be moved by the assignee to either Finalized or Proposed state to request the CSR review the request. HTH, -Joe On 9/20/2021 8:46 PM, Jaikiran Pai wrote: > On Sat, 18 Sep 2021 03:52:17 GMT, Jaikiran Pai wrote: > >>> The commit in this PR implements the proposal for enhancement that was discussed in the core-libs-dev mailing list recently[1], for https://bugs.openjdk.java.net/browse/JDK-8231640 >>> >>> At a high level - the `store()` APIs in `Properties` have been modified to now look for the `SOURCE_DATE_EPOCH` environment variable[2]. If that env variable is set, then instead of writing out the current date time as a date comment, the `store()` APIs instead will use the value set for this env variable to parse it to a `Date` and write out the string form of such a date. The implementation here uses the `d MMM yyyy HH:mm:ss 'GMT'` date format and `Locale.ROOT` to format and write out such a date. This should provide reproducibility whenever the `SOURCE_DATE_EPOCH` is set. Furthermore, intentionally, no changes in the date format of the "current date" have been done. >>> >>> These modified `store()` APIs work in the presence of the `SecurityManager` too. The caller is expected to have a read permission on the `SOURCE_DATE_EPOCH` environment variable. If the caller doesn't have that permission, then the implementation of these `store()` APIs will write out the "current date" and will ignore any value that has been set for the `SOURCE_DATE_EPOCH` env variable. This should allow for backward compatibility of existing applications, where, when they run under a `SecurityManager` and perhaps with an existing restrictive policy file, the presence of `SOURCE_DATE_EPOCH` shouldn't impact their calls to the `store()` APIs. >>> >>> The modified `store()` APIs will also ignore any value for `SOURCE_DATE_EPOCH` that cannot be parsed to an `long` value. In such cases, the `store()` APIs will write out the "current date" and ignore the value set for this environment variable. No exceptions will be thrown for such invalid values. This is an additional backward compatibility precaution to prevent any rogue value for `SOURCE_DATE_EPOCH` from breaking applications. >>> >>> An additional change in the implementation of these `store()` APIs and unrelated to the date comment, is that these APIs will now write out the property keys in a deterministic order. The keys will be written out in the natural ordering as specified by `java.lang.String#compareTo()` API. >>> >>> The combination of the ordering of the property keys when written out and the usage of `SOURCE_DATE_EPOCH` environment value to determine the date comment should together allow for reproducibility of the output generated by these `store()` APIs. >>> >>> New jtreg test classes have been introduced to verify these changes. The primary focus of `PropertiesStoreTest` is the ordering aspects of the property keys that are written out. On the other hand `StoreReproducibilityTest` focuses on the reproducibility of the output generated by these APIs. The `StoreReproducibilityTest` runs these tests both in the presence and absence of `SecurityManager`. Plus, in the presence of SecurityManager, it tests both the scenarios where the caller is granted the requisite permission and in other case not granted that permission. >>> >>> These new tests and existing tests under `test/jdk/java/util/Properties/` pass with these changes. >>> >>> [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-August/080758.html >>> [2] https://reproducible-builds.org/specs/source-date-epoch/ >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> Roger's suggestion to reword the implSpec text > What would be the next step to move the CSR forward? Should I be changing it's status or do something else? > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/5372 From jai.forums2013 at gmail.com Tue Sep 21 04:04:42 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Tue, 21 Sep 2021 09:34:42 +0530 Subject: RFR: 8231640: (prop) Canonical property storage [v21] In-Reply-To: References: Message-ID: <06172c42-e35d-bc12-9a94-a95d58700ca8@gmail.com> Thank you Joe. That link helped. I have now moved the CSR to the next state. -Jaikiran On 21/09/21 9:28 am, Joseph D. Darcy wrote: > Hello Jaikiran, > > The CSR is in Draft state. As discussed in the CSR wiki > (https://wiki.openjdk.java.net/display/csr/Main), the request needs to > be moved by the assignee to either Finalized or Proposed state to > request the CSR review the request. > > HTH, > > -Joe > > On 9/20/2021 8:46 PM, Jaikiran Pai wrote: >> On Sat, 18 Sep 2021 03:52:17 GMT, Jaikiran Pai wrote: >> >>>> The commit in this PR implements the proposal for enhancement that >>>> was discussed in the core-libs-dev mailing list recently[1], for >>>> https://bugs.openjdk.java.net/browse/JDK-8231640 >>>> >>>> At a high level - the `store()` APIs in `Properties` have been >>>> modified to now look for the `SOURCE_DATE_EPOCH` environment >>>> variable[2]. If that env variable is set, then instead of writing >>>> out the current date time as a date comment, the `store()` APIs >>>> instead will use the value set for this env variable to parse it to >>>> a `Date` and write out the string form of such a date. The >>>> implementation here uses the `d MMM yyyy HH:mm:ss 'GMT'` date >>>> format and `Locale.ROOT` to format and write out such a date. This >>>> should provide reproducibility whenever the `SOURCE_DATE_EPOCH` is >>>> set. Furthermore, intentionally, no changes in the date format of >>>> the "current date" have been done. >>>> >>>> These? modified `store()` APIs work in the presence of the >>>> `SecurityManager` too. The caller is expected to have a read >>>> permission on the `SOURCE_DATE_EPOCH` environment variable. If the >>>> caller doesn't have that permission, then the implementation of >>>> these `store()` APIs will write out the "current date" and will >>>> ignore any value that has been set for the `SOURCE_DATE_EPOCH` env >>>> variable. This should allow for backward compatibility of existing >>>> applications, where, when they run under a `SecurityManager` and >>>> perhaps with an existing restrictive policy file, the presence of >>>> `SOURCE_DATE_EPOCH` shouldn't impact their calls to the `store()` >>>> APIs. >>>> >>>> The modified `store()` APIs will also ignore any value for >>>> `SOURCE_DATE_EPOCH` that? cannot be parsed to an `long` value. In >>>> such cases, the `store()` APIs will write out the "current date" >>>> and ignore the value set for this environment variable. No >>>> exceptions will be thrown for such invalid values. This is an >>>> additional backward compatibility precaution to prevent any rogue >>>> value for `SOURCE_DATE_EPOCH` from breaking applications. >>>> >>>> An additional change in the implementation of these `store()` APIs >>>> and unrelated to the date comment, is that these APIs will now >>>> write out the property keys in a deterministic order. The keys will >>>> be written out in the natural ordering as specified by >>>> `java.lang.String#compareTo()` API. >>>> >>>> The combination of the ordering of the property keys when written >>>> out and the usage of `SOURCE_DATE_EPOCH` environment value to >>>> determine the date comment should together allow for >>>> reproducibility of the output generated by these `store()` APIs. >>>> >>>> New jtreg test classes have been introduced to verify these >>>> changes. The primary focus of `PropertiesStoreTest` is the ordering >>>> aspects of the property keys that are written out. On the other >>>> hand `StoreReproducibilityTest` focuses on the reproducibility of >>>> the output generated by these APIs.? The `StoreReproducibilityTest` >>>> runs these tests both in the presence and absence of >>>> `SecurityManager`. Plus, in the presence of SecurityManager, it >>>> tests both the scenarios where the caller is granted the requisite >>>> permission and in other case not granted that permission. >>>> >>>> These new tests and existing tests under >>>> `test/jdk/java/util/Properties/` pass with these changes. >>>> >>>> [1] >>>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-August/080758.html >>>> [2] https://reproducible-builds.org/specs/source-date-epoch/ >>> Jaikiran Pai has updated the pull request incrementally with one >>> additional commit since the last revision: >>> >>> ?? Roger's suggestion to reword the implSpec text >> What would be the next step to move the CSR forward? Should I be >> changing it's status or do something else? >> >> ------------- >> >> PR: https://git.openjdk.java.net/jdk/pull/5372 From dholmes at openjdk.java.net Tue Sep 21 05:01:49 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 21 Sep 2021 05:01:49 GMT Subject: RFR: 8272600: (test) Use native "sleep" in Basic.java [v6] In-Reply-To: References: Message-ID: <1-B9MAOZK5XtDuFdxsWh3SgFnCk2MRdK-zbBcys1PbU=.1df445ba-dbaa-4480-a7ac-35dd79a7f920@github.com> On Mon, 20 Sep 2021 13:01:29 GMT, Roger Riggs wrote: >> The intermittent test in java/lang/ProcessBuilder/Basic.java has identified unexpected messages from a child Java VM >> as the cause of the test failure. Attempts to control the output of the child VM have failed, the VM is unrepentant . >> >> There is no functionality in the child except to wait long enough for the test to finish and the child is destroyed. >> The fix is to switch from using a Java child to using a native child; a new executable `sleepmillis`. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > The switch from a Java child to /bin/sleep caused another test > to fail on Linux. The cleanup for a test used /usr/bin/pkill "sleep 60". > A race between that cleanup and subsequent tests that used sleep 60 or 600 > could kill the sleep before the test of waitFor completed. > Changing the test using pkill to use 59 seconds makes the test cleanup > selective to the sleep spawned for that test. > The test that was failing (lines 2626-2624) passes consistently. Hi Roger, One suggestion based on your latest change, but that can be handled later. Otherwise this seems fine. Thanks, David test/jdk/java/lang/ProcessBuilder/Basic.java line 2217: > 2215: // A unique (59s) time is needed to avoid killing other sleep processes. > 2216: final String[] cmd = { "/bin/bash", "-c", "(/bin/sleep 59)" }; > 2217: final String[] cmdkill = { "/bin/bash", "-c", "(/usr/bin/pkill -f \"sleep 59\")" }; Maybe future RFE but why do we even need pkill here when we can get the PID of the sleep process we create and kill only that process? ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5239 From shade at openjdk.java.net Tue Sep 21 05:58:53 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 21 Sep 2021 05:58:53 GMT Subject: RFR: 8273797: Stop impersonating "server" VM in all VM variants In-Reply-To: References: Message-ID: On Wed, 15 Sep 2021 10:02:19 GMT, Aleksey Shipilev wrote: > As the follow-up for Zero-specific JDK-8273494, we might want to clean up build system logic for all VM variants: stop impersonating "server" VMs for all of them. This basically leaves "core" and "custom" variants to be handled with this patch. > > Additional testing: > - [x] Linux x86_64 `core` build passes, `libjvm.so` now in `core`, `jvm.cfg` mentions `-core KNOWN` > - [x] Linux x86_64 `custom` (+serialgc,+compiler2) build passes, `libjvm.so` now in `custom`, `jvm.cfg` mentions `-custom KNOWN` Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/5526 From shade at openjdk.java.net Tue Sep 21 06:03:47 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 21 Sep 2021 06:03:47 GMT Subject: Integrated: 8273797: Stop impersonating "server" VM in all VM variants In-Reply-To: References: Message-ID: On Wed, 15 Sep 2021 10:02:19 GMT, Aleksey Shipilev wrote: > As the follow-up for Zero-specific JDK-8273494, we might want to clean up build system logic for all VM variants: stop impersonating "server" VMs for all of them. This basically leaves "core" and "custom" variants to be handled with this patch. > > Additional testing: > - [x] Linux x86_64 `core` build passes, `libjvm.so` now in `core`, `jvm.cfg` mentions `-core KNOWN` > - [x] Linux x86_64 `custom` (+serialgc,+compiler2) build passes, `libjvm.so` now in `custom`, `jvm.cfg` mentions `-custom KNOWN` This pull request has now been integrated. Changeset: f242cb5c Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/f242cb5ce0af3bacf7af51351121f9137db92931 Stats: 41 lines in 5 files changed: 3 ins; 33 del; 5 mod 8273797: Stop impersonating "server" VM in all VM variants Reviewed-by: dholmes, erikj, ihse ------------- PR: https://git.openjdk.java.net/jdk/pull/5526 From sgehwolf at openjdk.java.net Tue Sep 21 08:12:51 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 21 Sep 2021 08:12:51 GMT Subject: RFR: 8273935: (zipfs) Files.getFileAttributeView() throws UOE instead of returning null when view not supported [v3] In-Reply-To: References: Message-ID: <-W3koaB1U4hHdmmpFWH6fhmUFMZ6G-4E1heM0a6_sdY=.8215a059-e0ad-446d-970d-a4e84c5c0815@github.com> On Mon, 20 Sep 2021 18:17:29 GMT, Lance Andersen wrote: >> Hi all, >> >> Please review this patch which addresses the issue where Zip FS will throw a UOE instead of returning null when Files.getFileAttributeView() is invoked and the view not supported. >> >> Mach5 tiers1 - tier3 are clean. >> >> Best >> Lance > > Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: > > fix minor typo Marked as reviewed by sgehwolf (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5579 From kizune at openjdk.java.net Tue Sep 21 09:02:53 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Tue, 21 Sep 2021 09:02:53 GMT Subject: RFR: 8268764: Use Long.hashCode() instead of int-cast where applicable [v4] In-Reply-To: References: Message-ID: On Thu, 1 Jul 2021 12:19:53 GMT, ?????? ??????? wrote: >> In some JDK classes there's still the following hashCode() implementation: >> >> long objNum; >> >> public int hashCode() { >> return (int) objNum; >> } >> >> This outdated expression should be replaced with Long.hashCode(long) as it >> >> - uses all bits of the original value, does not discard any information upfront. For example, depending on how you are generating the IDs, the upper bits could change more frequently (or the opposite). >> >> - does not introduce any bias towards values with more ones (zeros), as it would be the case if the two halves were combined with an OR (AND) operation. >> >> See https://stackoverflow.com/a/4045083 >> >> This is related to https://github.com/openjdk/jdk/pull/4309 > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8268764: Update copy-right year Marked as reviewed by kizune (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4491 From shade at openjdk.java.net Tue Sep 21 09:44:45 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 21 Sep 2021 09:44:45 GMT Subject: RFR: 8236505: Mark jdk/editpad/EditPadTest.java as @headful In-Reply-To: <_j9LK9SIRBmy-CCoe-OTa5bpqiVYbHUaeTolbqjAcAA=.81c737bb-e4cf-4445-bc3a-28590aeed95b@github.com> References: <_j9LK9SIRBmy-CCoe-OTa5bpqiVYbHUaeTolbqjAcAA=.81c737bb-e4cf-4445-bc3a-28590aeed95b@github.com> Message-ID: On Thu, 16 Sep 2021 09:13:15 GMT, Aleksey Shipilev wrote: > This is a GUI test, and it should be `@headful`. > > Additional testing: > - [x] Test still runs in default, and does not run with `!headful` Any takers? ;) ------------- PR: https://git.openjdk.java.net/jdk/pull/5544 From jlahoda at openjdk.java.net Tue Sep 21 09:53:42 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 21 Sep 2021 09:53:42 GMT Subject: RFR: 8236505: Mark jdk/editpad/EditPadTest.java as @headful In-Reply-To: <_j9LK9SIRBmy-CCoe-OTa5bpqiVYbHUaeTolbqjAcAA=.81c737bb-e4cf-4445-bc3a-28590aeed95b@github.com> References: <_j9LK9SIRBmy-CCoe-OTa5bpqiVYbHUaeTolbqjAcAA=.81c737bb-e4cf-4445-bc3a-28590aeed95b@github.com> Message-ID: On Thu, 16 Sep 2021 09:13:15 GMT, Aleksey Shipilev wrote: > This is a GUI test, and it should be `@headful`. > > Additional testing: > - [x] Test still runs in default, and does not run with `!headful` Marked as reviewed by jlahoda (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5544 From redestad at openjdk.java.net Tue Sep 21 11:19:49 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 21 Sep 2021 11:19:49 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v8] In-Reply-To: <5V0eAcrG9rS-d9RnyC2oJ5kVo6v84IhyBn40M71mYUg=.5d8c17fe-a23b-49a8-bfef-f670c0f013eb@github.com> References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> <5V0eAcrG9rS-d9RnyC2oJ5kVo6v84IhyBn40M71mYUg=.5d8c17fe-a23b-49a8-bfef-f670c0f013eb@github.com> Message-ID: On Wed, 1 Sep 2021 01:05:32 GMT, Mandy Chung wrote: >> This reimplements core reflection with method handles. >> >> For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. >> >> The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. >> >> The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. >> >> Ran tier1-tier8 tests. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8013527 >> [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > minor cleanup and more test case. I'm not sure how to assess how minor the "Var" case really is. I wouldn't be surprised if reflection-heavy frameworks hold `Method`s etc in some collection, which means they wouldn't be rooted in a way that allows the JIT to fold through. Thus leaning only on MH customization could be adding some performance risks. Off-list Vladimir Ivanov suggested the "Var" micros have some issues with inlining that make them look worse than they should, though. On balance I think removing class-spinning might mean a better overall story w.r.t. footprint and maintainability. Had we started this review using a patch that looked more like what Peter is suggestion and someone had suggested we spin classes to get a performance edge in a subset of cases I think we'd not be looking favorably at that and instead tried reaching for narrowing those performance gaps via other less intrusive means. So I think I'm in favor of simplifying and filing a follow-up to try and win back some of the performance we might be losing on corner-case micros without the custom class spinning. ------------- PR: https://git.openjdk.java.net/jdk/pull/5027 From shade at openjdk.java.net Tue Sep 21 11:29:44 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 21 Sep 2021 11:29:44 GMT Subject: RFR: 8236505: Mark jdk/editpad/EditPadTest.java as @headful In-Reply-To: <_j9LK9SIRBmy-CCoe-OTa5bpqiVYbHUaeTolbqjAcAA=.81c737bb-e4cf-4445-bc3a-28590aeed95b@github.com> References: <_j9LK9SIRBmy-CCoe-OTa5bpqiVYbHUaeTolbqjAcAA=.81c737bb-e4cf-4445-bc3a-28590aeed95b@github.com> Message-ID: On Thu, 16 Sep 2021 09:13:15 GMT, Aleksey Shipilev wrote: > This is a GUI test, and it should be `@headful`. > > Additional testing: > - [x] Test still runs in default, and does not run with `!headful` Thank you! ------------- PR: https://git.openjdk.java.net/jdk/pull/5544 From shade at openjdk.java.net Tue Sep 21 11:29:44 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 21 Sep 2021 11:29:44 GMT Subject: Integrated: 8236505: Mark jdk/editpad/EditPadTest.java as @headful In-Reply-To: <_j9LK9SIRBmy-CCoe-OTa5bpqiVYbHUaeTolbqjAcAA=.81c737bb-e4cf-4445-bc3a-28590aeed95b@github.com> References: <_j9LK9SIRBmy-CCoe-OTa5bpqiVYbHUaeTolbqjAcAA=.81c737bb-e4cf-4445-bc3a-28590aeed95b@github.com> Message-ID: <3cRbryPR0yvEN3AJaAGouKECvxd5zpNhOls0C7JzgSw=.c94b5f5d-3e3e-4388-b1d4-bd4852ecefc4@github.com> On Thu, 16 Sep 2021 09:13:15 GMT, Aleksey Shipilev wrote: > This is a GUI test, and it should be `@headful`. > > Additional testing: > - [x] Test still runs in default, and does not run with `!headful` This pull request has now been integrated. Changeset: 7acec3f1 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/7acec3f161234b99da76193781296157b98d689c Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8236505: Mark jdk/editpad/EditPadTest.java as @headful Reviewed-by: jlahoda ------------- PR: https://git.openjdk.java.net/jdk/pull/5544 From prappo at openjdk.java.net Tue Sep 21 12:15:17 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 21 Sep 2021 12:15:17 GMT Subject: RFR: 8274071: Clean up java.lang.ref comments and documentation Message-ID: This PR fixes an inline comment typo and reduces "overlinking" in a doc comment in `java.lang.ref.Reference`. Overlinking happens because the `reachabilityFence` method: * Links `package-summary.html#reachability` twice. * Refers to JLS 12.6 twice: once from a block tag and once from an inline tag. ------------- Commit messages: - Initial commit Changes: https://git.openjdk.java.net/jdk/pull/5609/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5609&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274071 Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5609.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5609/head:pull/5609 PR: https://git.openjdk.java.net/jdk/pull/5609 From plevart at openjdk.java.net Tue Sep 21 12:32:53 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Tue, 21 Sep 2021 12:32:53 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v8] In-Reply-To: <5V0eAcrG9rS-d9RnyC2oJ5kVo6v84IhyBn40M71mYUg=.5d8c17fe-a23b-49a8-bfef-f670c0f013eb@github.com> References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> <5V0eAcrG9rS-d9RnyC2oJ5kVo6v84IhyBn40M71mYUg=.5d8c17fe-a23b-49a8-bfef-f670c0f013eb@github.com> Message-ID: On Wed, 1 Sep 2021 01:05:32 GMT, Mandy Chung wrote: >> This reimplements core reflection with method handles. >> >> For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. >> >> The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. >> >> The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. >> >> Ran tier1-tier8 tests. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8013527 >> [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > minor cleanup and more test case. Hi Claes, > I'm not sure how to assess how minor the "Var" case really is. I wouldn't be surprised if reflection-heavy frameworks hold `Method`s etc in some collection, which means they wouldn't be rooted in a way that allows the JIT to fold through. Thus leaning only on MH customization could be adding some performance risks. Off-list Vladimir Ivanov suggested the "Var" micros have some issues with inlining that make them look worse than they should, though. Frameworks that keep Method(s) etc in some collection don't fall into the "Var" category of MH tests presented here, but into the "Poly" category. The test that uses Jackson serialization is one such example. The "Var" class of tests exhibit a use-case where there is a single instance of Method (or Field) object used in a particular call-site (i.e. the Method::invoke invocation in bytecode) but such Method object can't be proved by JIT to be constant (it is not read from static final or @Stable field). I doubt that such use-cases exist in practice. Mostly they would amount to cases that were meant to be "Constant" but are not because the user forgot to use "final" modifier on "static" field... If you look at "Poly" results, spinning MHInvoker/VHInvoker classes for each instance of Method/Field does not help at all. I would try to optimize the "Poly" case further if it was possible. The simplified Method/MethodHandle is practically equivalent in final "Poly" performance with the generated MethodAccessor, but the Field/VarHandle or Field/MethodHandle lags behind Unsafe-based accessor in "Poly" performance. Nothing can beat Unsafe when access to fields is concerned. It doesn't matter where the offset and base are read-from, the access is super-fast. I wish MethodHandles obtained by unreflectGetter/unreflectSetter could be less sensitive to where they are read from (constant vs. not-constant) and optimize better in non-constant case. I think we should search in this direction... to make MethodHandles obtained by unreflectGetter/unreflectSetter more optimal in non-constant case. If Unsafe can be better, why not MethodHandles? > > On balance I think removing class-spinning might mean a better overall story w.r.t. footprint and maintainability. Had we started this review using a patch that looked more like what Peter is suggestion and someone had suggested we spin classes to get a performance edge in a subset of cases I think we'd not be looking favorably at that and instead tried reaching for narrowing those performance gaps via other less intrusive means. So I think I'm in favor of simplifying and filing a follow-up to try and win back some of the performance we might be losing on corner-case micros without the custom class spinning. ------------- PR: https://git.openjdk.java.net/jdk/pull/5027 From prappo at openjdk.java.net Tue Sep 21 12:36:57 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 21 Sep 2021 12:36:57 GMT Subject: RFR: 8274075: Fix miscellaneous typos in java.base Message-ID: <27dIhnD8Wc7kQcxq45Np2Lo68AhZvSgmmoV67fgL8rs=.9d8115bf-5176-4de5-99d8-963dc0d12c8f@github.com> 8274075: Fix miscellaneous typos in java.base ------------- Commit messages: - Initial commit Changes: https://git.openjdk.java.net/jdk/pull/5610/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5610&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274075 Stats: 21 lines in 8 files changed: 0 ins; 0 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/5610.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5610/head:pull/5610 PR: https://git.openjdk.java.net/jdk/pull/5610 From dfuchs at openjdk.java.net Tue Sep 21 12:50:52 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 21 Sep 2021 12:50:52 GMT Subject: RFR: 8274075: Fix miscellaneous typos in java.base In-Reply-To: <27dIhnD8Wc7kQcxq45Np2Lo68AhZvSgmmoV67fgL8rs=.9d8115bf-5176-4de5-99d8-963dc0d12c8f@github.com> References: <27dIhnD8Wc7kQcxq45Np2Lo68AhZvSgmmoV67fgL8rs=.9d8115bf-5176-4de5-99d8-963dc0d12c8f@github.com> Message-ID: On Tue, 21 Sep 2021 12:26:25 GMT, Pavel Rappo wrote: > 8274075: Fix miscellaneous typos in java.base Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5610 From naoto at openjdk.java.net Tue Sep 21 12:56:06 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 21 Sep 2021 12:56:06 GMT Subject: RFR: 8273924: ArrayIndexOutOfBoundsException thrown in java.util.JapaneseImperialCalendar.add() Message-ID: Fixing an AIOOBE on normalizing the month value. ------------- Commit messages: - 8273924: ArrayIndexOutOfBoundsException thrown in java.util.JapaneseImperialCalendar.add() Changes: https://git.openjdk.java.net/jdk/pull/5611/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5611&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273924 Stats: 26 lines in 3 files changed: 24 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5611.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5611/head:pull/5611 PR: https://git.openjdk.java.net/jdk/pull/5611 From rriggs at openjdk.java.net Tue Sep 21 13:15:37 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 21 Sep 2021 13:15:37 GMT Subject: RFR: 8272600: (test) Use native "sleep" in Basic.java [v6] In-Reply-To: <1-B9MAOZK5XtDuFdxsWh3SgFnCk2MRdK-zbBcys1PbU=.1df445ba-dbaa-4480-a7ac-35dd79a7f920@github.com> References: <1-B9MAOZK5XtDuFdxsWh3SgFnCk2MRdK-zbBcys1PbU=.1df445ba-dbaa-4480-a7ac-35dd79a7f920@github.com> Message-ID: On Tue, 21 Sep 2021 04:54:24 GMT, David Holmes wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> The switch from a Java child to /bin/sleep caused another test >> to fail on Linux. The cleanup for a test used /usr/bin/pkill "sleep 60". >> A race between that cleanup and subsequent tests that used sleep 60 or 600 >> could kill the sleep before the test of waitFor completed. >> Changing the test using pkill to use 59 seconds makes the test cleanup >> selective to the sleep spawned for that test. >> The test that was failing (lines 2626-2624) passes consistently. > > test/jdk/java/lang/ProcessBuilder/Basic.java line 2217: > >> 2215: // A unique (59s) time is needed to avoid killing other sleep processes. >> 2216: final String[] cmd = { "/bin/bash", "-c", "(/bin/sleep 59)" }; >> 2217: final String[] cmdkill = { "/bin/bash", "-c", "(/usr/bin/pkill -f \"sleep 59\")" }; > > Maybe future RFE but why do we even need pkill here when we can get the PID of the sleep process we create and kill only that process? I thought of that too, but notice the parens "()" around that /bin/sleep; that creates and extra level of forked processes and its harder to get that pid. There probably is a way to traverse the hierarchy but I'll keep it as is for now. ------------- PR: https://git.openjdk.java.net/jdk/pull/5239 From prappo at openjdk.java.net Tue Sep 21 13:16:02 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 21 Sep 2021 13:16:02 GMT Subject: RFR: 8274075: Fix miscellaneous typos in java.base [v2] In-Reply-To: <27dIhnD8Wc7kQcxq45Np2Lo68AhZvSgmmoV67fgL8rs=.9d8115bf-5176-4de5-99d8-963dc0d12c8f@github.com> References: <27dIhnD8Wc7kQcxq45Np2Lo68AhZvSgmmoV67fgL8rs=.9d8115bf-5176-4de5-99d8-963dc0d12c8f@github.com> Message-ID: > 8274075: Fix miscellaneous typos in java.base Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: Tweak wording for Throwable constructor parameters ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5610/files - new: https://git.openjdk.java.net/jdk/pull/5610/files/2db8525d..19b6f496 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5610&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5610&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5610.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5610/head:pull/5610 PR: https://git.openjdk.java.net/jdk/pull/5610 From andy.herrick at oracle.com Tue Sep 21 13:21:22 2021 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 21 Sep 2021 09:21:22 -0400 Subject: What causes java.lang.InternalError: platform encoding not initialized ? In-Reply-To: References: Message-ID: <397c959b-6a66-f32c-f673-05729dd705e7@oracle.com> I don't see anything wrong with this offhand. the runtime should be able to be anywhere if the cfg files "app.runtime" line points to it. Is this on windows ? Is the the released JDK17 used both for the jlinked runtime and the jpackage tool ? Are there any libraries in $APPDIR (which is added to the $PATH env variable on windows) which could be interfering with encoding initialization ? Can you try the following experiment: manually edit the cfg file line: app.runtime=$APPDIR\..\my_own_folder\where_the_jre_is_deeper\jre to contain the canonical path to ...\my_own_folder\where_the_jre_is_deeper\jre and try again ? /Andy On 9/20/2021 5:37 PM, Scott Palmer wrote: > This is likely not the right place to ask this (sorry).. but I'm trying to > get info to write a bug report and want to make sure I'm not doing > something stupid first. > > I've created a JRE image from JDK 17 with jlink. I've made an > application image with jpackage. I've moved the default location of the > runtime in the application image and modified the launcher .cfg file > accordingly by adding a line to the [Application] section > > app.runtime=$APPDIR\..\my_own_folder\where_the_jre_is_deeper\jre > > My application launches. It shows a JavaFX GUI. It does a bunch of stuff > that "works", but then one thread fails with this exception: > > Exception in thread "Reader-BG-1" java.lang.InternalError: platform > encoding not initialized > at java.base/java.net.Inet6AddressImpl.lookupAllHostAddr(Native > Method) > at > java.base/java.net.InetAddress$PlatformNameService.lookupAllHostAddr(InetAddress.java:933) > at > java.base/java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1519) > at > java.base/java.net.InetAddress$NameServiceAddresses.get(InetAddress.java:852) > at > java.base/java.net.InetAddress.getAllByName0(InetAddress.java:1509) > at > java.base/java.net.InetAddress.getAllByName(InetAddress.java:1367) > at > java.base/java.net.InetAddress.getAllByName(InetAddress.java:1301) > at java.base/java.net.InetAddress.getByName(InetAddress.java:1251) > at > java.base/java.net.InetSocketAddress.(InetSocketAddress.java:229) > at java.base/sun.net.NetworkClient.doConnect(NetworkClient.java:178) > at > java.base/sun.net.www.http.HttpClient.openServer(HttpClient.java:498) > at > java.base/sun.net.www.http.HttpClient.openServer(HttpClient.java:603) > at > java.base/sun.net.www.protocol.https.HttpsClient.(HttpsClient.java:266) > at > java.base/sun.net.www.protocol.https.HttpsClient.New(HttpsClient.java:380) > at > java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.getNewHttpClient(AbstractDelegateHttpsURLConnection.java:189) > at > java.base/sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1242) > at > java.base/sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:1128) > at > java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:175) > at > java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1665) > at > java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1589) > at > java.base/java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:529) > at > java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:308) > > If I keep the runtime in $APPDIR\runtime, things don't fail in this way. > > Smells like a bug in the app launcher to me.. but maybe it's in the runtime? > > Any assistance would be appreciated (including telling me where I should go > to ask this, if this list isn't appropriate). > > Thanks, > > Scott From rriggs at openjdk.java.net Tue Sep 21 13:23:50 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 21 Sep 2021 13:23:50 GMT Subject: RFR: 8274071: Clean up java.lang.ref comments and documentation In-Reply-To: References: Message-ID: On Tue, 21 Sep 2021 12:05:27 GMT, Pavel Rappo wrote: > This PR fixes an inline comment typo and reduces "overlinking" in a doc comment in `java.lang.ref.Reference`. Overlinking happens because the `reachabilityFence` method: > * Links `package-summary.html#reachability` twice. > * Refers to JLS 12.6 twice: once from a block tag and once from an inline tag. Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5609 From rriggs at openjdk.java.net Tue Sep 21 13:23:53 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 21 Sep 2021 13:23:53 GMT Subject: RFR: 8273924: ArrayIndexOutOfBoundsException thrown in java.util.JapaneseImperialCalendar.add() In-Reply-To: References: Message-ID: On Tue, 21 Sep 2021 12:47:00 GMT, Naoto Sato wrote: > Fixing an AIOOBE on normalizing the month value. Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5611 From github.com+741251+turbanoff at openjdk.java.net Tue Sep 21 13:28:26 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Tue, 21 Sep 2021 13:28:26 GMT Subject: RFR: 8274079: Cleanup unnecessary calls to Throwable.initCause() in java.base module Message-ID: Pass "cause" exception as constructor parameter is shorter and easier to read. ------------- Commit messages: - [PATCH] Cleanup unnecessary calls to Throwable.initCause() in java.base module Changes: https://git.openjdk.java.net/jdk/pull/5551/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5551&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274079 Stats: 133 lines in 22 files changed: 0 ins; 77 del; 56 mod Patch: https://git.openjdk.java.net/jdk/pull/5551.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5551/head:pull/5551 PR: https://git.openjdk.java.net/jdk/pull/5551 From Alan.Bateman at oracle.com Tue Sep 21 13:31:14 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 21 Sep 2021 14:31:14 +0100 Subject: What causes java.lang.InternalError: platform encoding not initialized ? In-Reply-To: <397c959b-6a66-f32c-f673-05729dd705e7@oracle.com> References: <397c959b-6a66-f32c-f673-05729dd705e7@oracle.com> Message-ID: On 21/09/2021 14:21, Andy Herrick wrote: > I don't see anything wrong with this offhand. the runtime should be > able to be anywhere if the cfg files "app.runtime" line points to it. > > Is this on windows ? Is the the released JDK17 used both for the > jlinked runtime and the jpackage tool ? > > Are there any libraries in $APPDIR (which is added to the $PATH env > variable on windows) which could be interfering with encoding > initialization ? > > Can you try the following experiment: > > manually edit the cfg file line: > > app.runtime=$APPDIR\..\my_own_folder\where_the_jre_is_deeper\jre > > to contain the canonical path to > ...\my_own_folder\where_the_jre_is_deeper\jre > > and try again ? The exception suggests that something is seriously broken, maybe that early VM initialization didn't execute correctly but I can't see what it didn't fail earlier. It would be great if there are steps to duplicate this. -Alan. From prappo at openjdk.java.net Tue Sep 21 13:57:37 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 21 Sep 2021 13:57:37 GMT Subject: RFR: 8274079: Cleanup unnecessary calls to Throwable.initCause() in java.base module In-Reply-To: References: Message-ID: On Thu, 16 Sep 2021 19:03:26 GMT, Andrey Turbanov wrote: > Pass "cause" exception as constructor parameter is shorter and easier to read. This will need to be thoroughly tested to make sure there were no implicit dependencies on now-removed happens-before edges (`initCause` is synchronized). That said, the idea behind this clean-up looks good. ------------- PR: https://git.openjdk.java.net/jdk/pull/5551 From kbarrett at openjdk.java.net Tue Sep 21 13:59:33 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 21 Sep 2021 13:59:33 GMT Subject: RFR: 8274071: Clean up java.lang.ref comments and documentation In-Reply-To: References: Message-ID: On Tue, 21 Sep 2021 12:05:27 GMT, Pavel Rappo wrote: > This PR fixes an inline comment typo and reduces "overlinking" in a doc comment in `java.lang.ref.Reference`. Overlinking happens because the `reachabilityFence` method: > * Links `package-summary.html#reachability` twice. > * Refers to JLS 12.6 twice: once from a block tag and once from an inline tag. Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5609 From jboes at openjdk.java.net Tue Sep 21 14:09:54 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Tue, 21 Sep 2021 14:09:54 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v5] In-Reply-To: References: Message-ID: <4uCMVxnjarwTD6D9ngFv-pGAf6NjwGPddh7I4_sayCQ=.102746de-2a11-4aa7-82dc-601a6f228671@github.com> > This change implements a simple web server that can be run on the command-line with `java -m jdk.httpserver`. > > This is facilitated by adding an entry point for the `jdk.httpserver` module, an implementation class whose main method is run when the above command is executed. This is the first such module entry point in the JDK. > > The server is a minimal HTTP server that serves the static files of a given directory, similar to existing alternatives on other platforms and convenient for testing, development, and debugging. > > Additionally, a small API is introduced for programmatic creation and customization. > > Testing: tier1-3. Julia Boes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: - Merge branch 'master' into simpleserver - Merge remote-tracking branch 'origin/simpleserver' into simpleserver - Merge branch 'master' into simpleserver - refactor isHidden,isReadable,isSymlink checks and cleanup tests - Merge branch 'master' into simpleserver - check isHidden, isSymlink, isReadable for all path segments - add checks for all path segments - Merge branch 'master' into componentcheck - Merge branch 'master' into simpleserver - improve output on startup - ... and 6 more: https://git.openjdk.java.net/jdk/compare/6d91a3eb...fe059131 ------------- Changes: https://git.openjdk.java.net/jdk/pull/5505/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5505&range=04 Stats: 7162 lines in 42 files changed: 7127 ins; 15 del; 20 mod Patch: https://git.openjdk.java.net/jdk/pull/5505.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5505/head:pull/5505 PR: https://git.openjdk.java.net/jdk/pull/5505 From weijun at openjdk.java.net Tue Sep 21 14:12:31 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 21 Sep 2021 14:12:31 GMT Subject: RFR: 8274079: Cleanup unnecessary calls to Throwable.initCause() in java.base module In-Reply-To: References: Message-ID: On Thu, 16 Sep 2021 19:03:26 GMT, Andrey Turbanov wrote: > Pass "cause" exception as constructor parameter is shorter and easier to read. Looks fine. Thanks. ------------- Marked as reviewed by weijun (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5551 From swpalmer at gmail.com Tue Sep 21 14:17:04 2021 From: swpalmer at gmail.com (Scott Palmer) Date: Tue, 21 Sep 2021 10:17:04 -0400 Subject: What causes java.lang.InternalError: platform encoding not initialized ? In-Reply-To: <397c959b-6a66-f32c-f673-05729dd705e7@oracle.com> References: <397c959b-6a66-f32c-f673-05729dd705e7@oracle.com> Message-ID: This is on Windows 10 Pro. using JDK 17 for jpackage and I'm pretty sure for jimage (though the image was made shortly after 17 GA and is being reused).. There are no libraries directly in $APPDIR, though there are plenty in other sibling folders to the 'app' folder (in addition to those in app\libs) I changed app.runtime to point to the (relative) path without the $APPDIR\.. - same problem. Tried a absolute path, same problem. The exact same runtime folder that was failing for me was simply copied to the default location to make it work. It works if I leave app.runtime out of the .cfg file, or if I point to $APPDIR\..\runtime I did some more experiments and found that if I just rename the 'runtime' folder to 'jre', but leave it at the same depth then the problem appears. I suspected there must be some hardcoded reference to the 'runtime' folder in the app launcher. However, if I have two copies of the runtime, one at the default location, and use app.runtime to point to the other copy it still fails. (i.e. if it is referencing some library from the default location it doesn't help.. I thought it might, being that it is all in the same process.) The application is complex. It has a plugin mechanism that uses an Agent and the Instrument class to augment the classpath at runtime. (Older versions of the plugin mechanism used to hack the System classloader on JDK 8 and switching to an Agent was the fastest way to make it work on later versions in a supported manner. It likely should be using custom classloaders, but classloading issues got messy when I looked into that way back when we started.) I will try to find time later this week to isolate a test case that can reproduce it. For now I can work around the issue by putting the runtime back to the default location for this case. This is a special case of an application that actually includes the JRE itself as one of the plugins so we can upgrade the JRE after the initial deployment or run different jobs with different JREs. I was trying to make a smaller tool/demo that used the JRE from where it would be in our "plugin" folder. Regards, Scott On Tue, Sep 21, 2021 at 9:22 AM Andy Herrick wrote: > I don't see anything wrong with this offhand. the runtime should be able > to be anywhere if the cfg files "app.runtime" line points to it. > > Is this on windows ? Is the the released JDK17 used both for the jlinked > runtime and the jpackage tool ? > > Are there any libraries in $APPDIR (which is added to the $PATH env > variable on windows) which could be interfering with encoding > initialization ? > > Can you try the following experiment: > > manually edit the cfg file line: > > app.runtime=$APPDIR\..\my_own_folder\where_the_jre_is_deeper\jre > > to contain the canonical path to > ...\my_own_folder\where_the_jre_is_deeper\jre > > and try again ? > > > /Andy > > On 9/20/2021 5:37 PM, Scott Palmer wrote: > > This is likely not the right place to ask this (sorry).. but I'm trying > to > > get info to write a bug report and want to make sure I'm not doing > > something stupid first. > > > > I've created a JRE image from JDK 17 with jlink. I've made an > > application image with jpackage. I've moved the default location of the > > runtime in the application image and modified the launcher .cfg file > > accordingly by adding a line to the [Application] section > > > > app.runtime=$APPDIR\..\my_own_folder\where_the_jre_is_deeper\jre > > > > My application launches. It shows a JavaFX GUI. It does a bunch of > stuff > > that "works", but then one thread fails with this exception: > > > > Exception in thread "Reader-BG-1" java.lang.InternalError: platform > > encoding not initialized > > at java.base/java.net.Inet6AddressImpl.lookupAllHostAddr(Native > > Method) > > at > > java.base/java.net > .InetAddress$PlatformNameService.lookupAllHostAddr(InetAddress.java:933) > > at > > java.base/java.net > .InetAddress.getAddressesFromNameService(InetAddress.java:1519) > > at > > java.base/java.net > .InetAddress$NameServiceAddresses.get(InetAddress.java:852) > > at > > java.base/java.net.InetAddress.getAllByName0(InetAddress.java:1509) > > at > > java.base/java.net.InetAddress.getAllByName(InetAddress.java:1367) > > at > > java.base/java.net.InetAddress.getAllByName(InetAddress.java:1301) > > at java.base/java.net > .InetAddress.getByName(InetAddress.java:1251) > > at > > java.base/java.net.InetSocketAddress.(InetSocketAddress.java:229) > > at java.base/sun.net > .NetworkClient.doConnect(NetworkClient.java:178) > > at > > java.base/sun.net.www.http.HttpClient.openServer(HttpClient.java:498) > > at > > java.base/sun.net.www.http.HttpClient.openServer(HttpClient.java:603) > > at > > > java.base/sun.net.www.protocol.https.HttpsClient.(HttpsClient.java:266) > > at > > > java.base/sun.net.www.protocol.https.HttpsClient.New(HttpsClient.java:380) > > at > > > java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.getNewHttpClient(AbstractDelegateHttpsURLConnection.java:189) > > at > > > java.base/sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1242) > > at > > > java.base/sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:1128) > > at > > > java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:175) > > at > > > java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1665) > > at > > > java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1589) > > at > > java.base/java.net > .HttpURLConnection.getResponseCode(HttpURLConnection.java:529) > > at > > > java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:308) > > > > If I keep the runtime in $APPDIR\runtime, things don't fail in this way. > > > > Smells like a bug in the app launcher to me.. but maybe it's in the > runtime? > > > > Any assistance would be appreciated (including telling me where I should > go > > to ask this, if this list isn't appropriate). > > > > Thanks, > > > > Scott > From jboes at openjdk.java.net Tue Sep 21 14:17:36 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Tue, 21 Sep 2021 14:17:36 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v4] In-Reply-To: References: Message-ID: On Mon, 20 Sep 2021 16:16:10 GMT, Daniel Fuchs wrote: >> src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/FileServerHandler.java line 340: >> >>> 338: } >>> 339: } >>> 340: return false; >> >> This will start checking from the root of the file system. I believe we want to start checking from the root of the FileServerHandler, root excluded. > > Maybe these checks should be made in `mapToPath` instead since you already walk the path there - and IIRC returning null from `mapToPath` will cause HTTP 404. Agreed. I refactored the handler to check `!isReadable`, `isHidden` and `isSymbolicLink` for each path segment from the root, excluding the root itself. If any of these conditions is met, a 404 response is sent. A generic 404 response for hides potentially revealing information. The checks are repeated in handle() on line 375, let's keep them in there for reassurance. ------------- PR: https://git.openjdk.java.net/jdk/pull/5505 From andy.herrick at oracle.com Tue Sep 21 14:54:18 2021 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 21 Sep 2021 10:54:18 -0400 Subject: [External] : Re: What causes java.lang.InternalError: platform encoding not initialized ? In-Reply-To: References: <397c959b-6a66-f32c-f673-05729dd705e7@oracle.com> Message-ID: <1ac831b0-9dd1-8c68-775b-0e2c3e58ac21@oracle.com> I found the problem in open/src/jdk.jpackage/windows/native/applauncher/WinLauncher.cpp we call SetDllDirectory() with the path to the bin dir in the default runtime directory, not the actual runtime directory. since on Windows we never use other than the default runtime location - we had not seen a problem, but is bug I will file and fix. Thanks. /Andy On 9/21/2021 10:17 AM, Scott Palmer wrote: > This is on Windows 10 Pro.? using JDK 17 for jpackage and I'm pretty > sure for?jimage? (though the image was made shortly after 17 GA and is > being reused).. > > There are no libraries?directly in $APPDIR, though there are plenty in > other sibling folders to?the 'app' folder (in addition to?those in > app\libs) > > I changed app.runtime to point to the (relative) path without the > $APPDIR\.. - same problem. Tried a absolute path, same problem. > > The exact same runtime folder that was failing for me was?simply > copied to the default location to make it work.? It works if I leave > app.runtime out of the .cfg file, or if I point to $APPDIR\..\runtime > > I did some more experiments and found that if I just?rename the > 'runtime' folder to 'jre', but leave it at the same depth then the > problem appears. > > I suspected there must be some hardcoded?reference to the 'runtime' > folder in the app launcher.? However, if I have two copies of the > runtime, one at the default location, and use app.runtime to point to > the other copy it still fails. (i.e. if it is referencing some library > from the default location it doesn't help.. I thought it might,?being > that it is all in the same process.) > > The application is complex.? It has a plugin mechanism that uses an > Agent and the Instrument class to augment the classpath at runtime. > > (Older versions of the plugin mechanism used to hack the System > classloader on JDK 8 and switching to an Agent was the fastest way to > make it work on later versions in a supported manner. It likely should > be using custom classloaders, but classloading issues got messy when I > looked into that way back when we started.) > > I will try to find time later this week to isolate a test case that > can reproduce it.? For now I can work around the issue by putting the > runtime back to the default location for this case.? This is a special > case of an application that actually includes the JRE itself as one of > the plugins so we can upgrade the JRE after the initial deployment or > run different?jobs with different JREs.? I was trying to make a > smaller tool/demo that used the JRE from where it would be in our > "plugin" folder. > > Regards, > > Scott > > On Tue, Sep 21, 2021 at 9:22 AM Andy Herrick > wrote: > > I don't see anything wrong with this offhand. the runtime should > be able > to be anywhere if the cfg files "app.runtime" line points to it. > > Is this on windows ? Is the the released JDK17 used both for the > jlinked > runtime and the jpackage tool ? > > Are there any libraries in $APPDIR (which is added to the $PATH env > variable on windows) which could be interfering with encoding > initialization ? > > Can you try the following experiment: > > manually edit the cfg file line: > > app.runtime=$APPDIR\..\my_own_folder\where_the_jre_is_deeper\jre > > to contain the canonical path to > ...\my_own_folder\where_the_jre_is_deeper\jre > > and try again ? > > > /Andy > > On 9/20/2021 5:37 PM, Scott Palmer wrote: > > This is likely not the right place to ask this (sorry).. but I'm > trying to > > get info to write a bug report and want to make sure I'm not doing > > something stupid first. > > > > I've created a JRE image from JDK 17 with jlink.? I've made an > > application image with jpackage.? I've moved the default > location of the > > runtime in the application image and modified the launcher .cfg file > > accordingly by adding a line to the [Application] section > > > > app.runtime=$APPDIR\..\my_own_folder\where_the_jre_is_deeper\jre > > > > My application launches.? It shows a JavaFX GUI.? It does a > bunch of stuff > > that "works", but then one thread fails with this exception: > > > > Exception in thread "Reader-BG-1" java.lang.InternalError: platform > > encoding not initialized > >? ? ? ? ? at java.base/java.net > .Inet6AddressImpl.lookupAllHostAddr(Native > > Method) > >? ? ? ? ? at > > java.base/java.net > .InetAddress$PlatformNameService.lookupAllHostAddr(InetAddress.java:933) > >? ? ? ? ? at > > java.base/java.net > .InetAddress.getAddressesFromNameService(InetAddress.java:1519) > >? ? ? ? ? at > > java.base/java.net > .InetAddress$NameServiceAddresses.get(InetAddress.java:852) > >? ? ? ? ? at > > java.base/java.net > .InetAddress.getAllByName0(InetAddress.java:1509) > >? ? ? ? ? at > > java.base/java.net > .InetAddress.getAllByName(InetAddress.java:1367) > >? ? ? ? ? at > > java.base/java.net > .InetAddress.getAllByName(InetAddress.java:1301) > >? ? ? ? ? at java.base/java.net > .InetAddress.getByName(InetAddress.java:1251) > >? ? ? ? ? at > > java.base/java.net > .InetSocketAddress.(InetSocketAddress.java:229) > >? ? ? ? ? at java.base/sun.net > .NetworkClient.doConnect(NetworkClient.java:178) > >? ? ? ? ? at > > > java.base/sun.net.www.http.HttpClient.openServer(HttpClient.java:498) > >? ? ? ? ? at > > > java.base/sun.net.www.http.HttpClient.openServer(HttpClient.java:603) > >? ? ? ? ? at > > > java.base/sun.net.www.protocol.https.HttpsClient.(HttpsClient.java:266) > >? ? ? ? ? at > > > java.base/sun.net.www.protocol.https.HttpsClient.New(HttpsClient.java:380) > >? ? ? ? ? at > > > java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.getNewHttpClient(AbstractDelegateHttpsURLConnection.java:189) > >? ? ? ? ? at > > > java.base/sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1242) > >? ? ? ? ? at > > > java.base/sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:1128) > >? ? ? ? ? at > > > java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:175) > >? ? ? ? ? at > > > java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1665) > >? ? ? ? ? at > > > java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1589) > >? ? ? ? ? at > > java.base/java.net > .HttpURLConnection.getResponseCode(HttpURLConnection.java:529) > >? ? ? ? ? at > > > java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:308) > > > > If I keep the runtime in $APPDIR\runtime, things don't fail in > this way. > > > > Smells like a bug in the app launcher to me.. but maybe it's in > the runtime? > > > > Any assistance would be appreciated (including telling me where > I should go > > to ask this, if this list isn't appropriate). > > > > Thanks, > > > > Scott > From hannesw at openjdk.java.net Tue Sep 21 15:02:41 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Tue, 21 Sep 2021 15:02:41 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v5] In-Reply-To: <4uCMVxnjarwTD6D9ngFv-pGAf6NjwGPddh7I4_sayCQ=.102746de-2a11-4aa7-82dc-601a6f228671@github.com> References: <4uCMVxnjarwTD6D9ngFv-pGAf6NjwGPddh7I4_sayCQ=.102746de-2a11-4aa7-82dc-601a6f228671@github.com> Message-ID: On Tue, 21 Sep 2021 14:09:54 GMT, Julia Boes wrote: >> This change implements a simple web server that can be run on the command-line with `java -m jdk.httpserver`. >> >> This is facilitated by adding an entry point for the `jdk.httpserver` module, an implementation class whose main method is run when the above command is executed. This is the first such module entry point in the JDK. >> >> The server is a minimal HTTP server that serves the static files of a given directory, similar to existing alternatives on other platforms and convenient for testing, development, and debugging. >> >> Additionally, a small API is introduced for programmatic creation and customization. >> >> Testing: tier1-3. > > Julia Boes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Merge branch 'master' into simpleserver > - Merge remote-tracking branch 'origin/simpleserver' into simpleserver > - Merge branch 'master' into simpleserver > - refactor isHidden,isReadable,isSymlink checks and cleanup tests > - Merge branch 'master' into simpleserver > - check isHidden, isSymlink, isReadable for all path segments > - add checks for all path segments > - Merge branch 'master' into componentcheck > - Merge branch 'master' into simpleserver > - improve output on startup > - ... and 6 more: https://git.openjdk.java.net/jdk/compare/6d91a3eb...fe059131 test/jdk/com/sun/net/httpserver/simpleserver/SecurityManagerTest.java line 198: > 196: > 197: static final DateTimeFormatter HTTP_DATE_FORMATTER = > 198: DateTimeFormatter.ofPattern("EEE, dd MMM yyyy HH:mm:ss v"); I think this and other usages of `DateTimeFormatter.ofPattern` need to be called with `Locale.US` (or something similar) as second argument, otherwise the current default locale will be used. I noticed because on my laptop the `Last-modified` header contains a german date. ------------- PR: https://git.openjdk.java.net/jdk/pull/5505 From redestad at openjdk.java.net Tue Sep 21 15:09:59 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 21 Sep 2021 15:09:59 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v8] In-Reply-To: <5V0eAcrG9rS-d9RnyC2oJ5kVo6v84IhyBn40M71mYUg=.5d8c17fe-a23b-49a8-bfef-f670c0f013eb@github.com> References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> <5V0eAcrG9rS-d9RnyC2oJ5kVo6v84IhyBn40M71mYUg=.5d8c17fe-a23b-49a8-bfef-f670c0f013eb@github.com> Message-ID: <_q8hgIBxgjfnYvjHbHb6UtE1qB-n_reC9iY-Q9-WUEQ=.2d5f9a27-8b1e-4019-b4da-51260e37ddb5@github.com> On Wed, 1 Sep 2021 01:05:32 GMT, Mandy Chung wrote: >> This reimplements core reflection with method handles. >> >> For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. >> >> The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. >> >> The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. >> >> Ran tier1-tier8 tests. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8013527 >> [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > minor cleanup and more test case. > Frameworks that keep Method(s) etc in some collection don't fall into the "Var" category of MH tests presented here, but into the "Poly" category. The test that uses Jackson serialization is one such example. The "Var" class of tests exhibit a use-case where there is a single instance of Method (or Field) object used in a particular call-site (i.e. the Method::invoke invocation in bytecode) but such Method object can't be proved by JIT to be constant (it is not read from static final or @stable field). I doubt that such use-cases exist in practice. Mostly they would amount to cases that were meant to be "Constant" but are not because the user forgot to use "final" modifier on "static" field... > > If you look at "Poly" results, spinning MHInvoker/VHInvoker classes for each instance of Method/Field does not help at all. The added indirection in the "Poly" test might cause the code to fall off the inlining cliff, so that any constant folding becomes unlikely to happen. I agree that this might be closer to what happens in a real app, and as a data point it does show that the MHInvoker/VHInvoker optimizations might have been misguided. > > I would try to optimize the "Poly" case further if it was possible. The simplified Method/MethodHandle is practically equivalent in final "Poly" performance with the generated MethodAccessor, but the Field/VarHandle or Field/MethodHandle lags behind Unsafe-based accessor in "Poly" performance. Nothing can beat Unsafe when access to fields is concerned. It doesn't matter where the offset and base are read-from, the access is super-fast. I wish MethodHandles obtained by unreflectGetter/unreflectSetter could be less sensitive to where they are read from (constant vs. not-constant) and optimize better in non-constant case. I think we should search in this direction... to make MethodHandles obtained by unreflectGetter/unreflectSetter more optimal in non-constant case. If Unsafe can be better, why not MethodHandles? Completely agree, and it makes sense to me to try and optimize MH/VH field access to get on par with Unsafe for these use-cases rather than revert the reflective implementation back to raw Unsafe use. ------------- PR: https://git.openjdk.java.net/jdk/pull/5027 From hannesw at openjdk.java.net Tue Sep 21 15:09:59 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Tue, 21 Sep 2021 15:09:59 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v5] In-Reply-To: References: <4uCMVxnjarwTD6D9ngFv-pGAf6NjwGPddh7I4_sayCQ=.102746de-2a11-4aa7-82dc-601a6f228671@github.com> Message-ID: <7knPZhBCZjPeooByk6ak-abopLwM0GP1Ye5DBO4M3Lw=.f9f27843-dd6f-4079-a41a-33c4c3a3b264@github.com> On Tue, 21 Sep 2021 14:59:18 GMT, Hannes Walln?fer wrote: >> Julia Boes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: >> >> - Merge branch 'master' into simpleserver >> - Merge remote-tracking branch 'origin/simpleserver' into simpleserver >> - Merge branch 'master' into simpleserver >> - refactor isHidden,isReadable,isSymlink checks and cleanup tests >> - Merge branch 'master' into simpleserver >> - check isHidden, isSymlink, isReadable for all path segments >> - add checks for all path segments >> - Merge branch 'master' into componentcheck >> - Merge branch 'master' into simpleserver >> - improve output on startup >> - ... and 6 more: https://git.openjdk.java.net/jdk/compare/6d91a3eb...fe059131 > > test/jdk/com/sun/net/httpserver/simpleserver/SecurityManagerTest.java line 198: > >> 196: >> 197: static final DateTimeFormatter HTTP_DATE_FORMATTER = >> 198: DateTimeFormatter.ofPattern("EEE, dd MMM yyyy HH:mm:ss v"); > > I think this and other usages of `DateTimeFormatter.ofPattern` need to be called with `Locale.US` (or something similar) as second argument, otherwise the current default locale will be used. I noticed because on my laptop the `Last-modified` header contains a german date. I just realized I commented on a test file, while the actual culprit is in `FileServerHandler.java`. But I guess it applies to all usages of this class and method. ------------- PR: https://git.openjdk.java.net/jdk/pull/5505 From andy.herrick at oracle.com Tue Sep 21 15:35:03 2021 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 21 Sep 2021 11:35:03 -0400 Subject: [External] : Re: What causes java.lang.InternalError: platform encoding not initialized ? In-Reply-To: <1ac831b0-9dd1-8c68-775b-0e2c3e58ac21@oracle.com> References: <397c959b-6a66-f32c-f673-05729dd705e7@oracle.com> <1ac831b0-9dd1-8c68-775b-0e2c3e58ac21@oracle.com> Message-ID: <797e91b9-e97f-571f-14ee-7fc484074064@oracle.com> I filed: ??? JDK-8274087: Windows DLL path not set correctly. for this, and will work on a fix for JDK18 and backport to JDK17.0.2. /Andy On 9/21/2021 10:54 AM, Andy Herrick wrote: > I found the problem in > open/src/jdk.jpackage/windows/native/applauncher/WinLauncher.cpp > > we call SetDllDirectory() with the path to the bin dir in the default > runtime directory, not the actual runtime directory. > > since on Windows we never use other than the default runtime location > - we had not seen a problem, but is bug I will file and fix. > > Thanks. > > /Andy > > On 9/21/2021 10:17 AM, Scott Palmer wrote: >> This is on Windows 10 Pro.? using JDK 17 for jpackage and I'm pretty >> sure for?jimage? (though the image was made shortly after 17 GA and >> is being reused).. >> >> There are no libraries?directly in $APPDIR, though there are plenty >> in other sibling folders to?the 'app' folder (in addition to?those in >> app\libs) >> >> I changed app.runtime to point to the (relative) path without the >> $APPDIR\.. - same problem. Tried a absolute path, same problem. >> >> The exact same runtime folder that was failing for me was?simply >> copied to the default location to make it work.? It works if I leave >> app.runtime out of the .cfg file, or if I point to $APPDIR\..\runtime >> >> I did some more experiments and found that if I just?rename the >> 'runtime' folder to 'jre', but leave it at the same depth then the >> problem appears. >> >> I suspected there must be some hardcoded?reference to the 'runtime' >> folder in the app launcher.? However, if I have two copies of the >> runtime, one at the default location, and use app.runtime to point to >> the other copy it still fails. (i.e. if it is referencing some >> library from the default location it doesn't help.. I thought it >> might,?being that it is all in the same process.) >> >> The application is complex.? It has a plugin mechanism that uses an >> Agent and the Instrument class to augment the classpath at runtime. >> >> (Older versions of the plugin mechanism used to hack the System >> classloader on JDK 8 and switching to an Agent was the fastest way to >> make it work on later versions in a supported manner. It likely >> should be using custom classloaders, but classloading issues got >> messy when I looked into that way back when we started.) >> >> I will try to find time later this week to isolate a test case that >> can reproduce it.? For now I can work around the issue by putting the >> runtime back to the default location for this case. This is a special >> case of an application that actually includes the JRE itself as one >> of the plugins so we can upgrade the JRE after the initial deployment >> or run different?jobs with different JREs.? I was trying to make a >> smaller tool/demo that used the JRE from where it would be in our >> "plugin" folder. >> >> Regards, >> >> Scott >> >> On Tue, Sep 21, 2021 at 9:22 AM Andy Herrick > > wrote: >> >> ??? I don't see anything wrong with this offhand. the runtime should >> ??? be able >> ??? to be anywhere if the cfg files "app.runtime" line points to it. >> >> ??? Is this on windows ? Is the the released JDK17 used both for the >> ??? jlinked >> ??? runtime and the jpackage tool ? >> >> ??? Are there any libraries in $APPDIR (which is added to the $PATH env >> ??? variable on windows) which could be interfering with encoding >> ??? initialization ? >> >> ??? Can you try the following experiment: >> >> ??? manually edit the cfg file line: >> >> app.runtime=$APPDIR\..\my_own_folder\where_the_jre_is_deeper\jre >> >> ??? to contain the canonical path to >> ??? ...\my_own_folder\where_the_jre_is_deeper\jre >> >> ??? and try again ? >> >> >> ??? /Andy >> >> ??? On 9/20/2021 5:37 PM, Scott Palmer wrote: >> ??? > This is likely not the right place to ask this (sorry).. but I'm >> ??? trying to >> ??? > get info to write a bug report and want to make sure I'm not doing >> ??? > something stupid first. >> ??? > >> ??? > I've created a JRE image from JDK 17 with jlink.? I've made an >> ??? > application image with jpackage.? I've moved the default >> ??? location of the >> ??? > runtime in the application image and modified the launcher .cfg >> file >> ??? > accordingly by adding a line to the [Application] section >> ??? > >> ??? > app.runtime=$APPDIR\..\my_own_folder\where_the_jre_is_deeper\jre >> ??? > >> ??? > My application launches.? It shows a JavaFX GUI.? It does a >> ??? bunch of stuff >> ??? > that "works", but then one thread fails with this exception: >> ??? > >> ??? > Exception in thread "Reader-BG-1" java.lang.InternalError: >> platform >> ??? > encoding not initialized >> ??? >? ? ? ? ? at java.base/java.net >> .Inet6AddressImpl.lookupAllHostAddr(Native >> ??? > Method) >> ??? >? ? ? ? ? at >> ??? > java.base/java.net >> .InetAddress$PlatformNameService.lookupAllHostAddr(InetAddress.java:933) >> ??? >? ? ? ? ? at >> ??? > java.base/java.net >> .InetAddress.getAddressesFromNameService(InetAddress.java:1519) >> ??? >? ? ? ? ? at >> ??? > java.base/java.net >> .InetAddress$NameServiceAddresses.get(InetAddress.java:852) >> ??? >? ? ? ? ? at >> ??? > java.base/java.net >> .InetAddress.getAllByName0(InetAddress.java:1509) >> ??? >? ? ? ? ? at >> ??? > java.base/java.net >> .InetAddress.getAllByName(InetAddress.java:1367) >> ??? >? ? ? ? ? at >> ??? > java.base/java.net >> .InetAddress.getAllByName(InetAddress.java:1301) >> ??? >? ? ? ? ? at java.base/java.net >> .InetAddress.getByName(InetAddress.java:1251) >> ??? >? ? ? ? ? at >> ??? > java.base/java.net >> .InetSocketAddress.(InetSocketAddress.java:229) >> ??? >? ? ? ? ? at java.base/sun.net >> .NetworkClient.doConnect(NetworkClient.java:178) >> ??? >? ? ? ? ? at >> ??? > >> java.base/sun.net.www.http.HttpClient.openServer(HttpClient.java:498) >> ??? >? ? ? ? ? at >> ??? > >> java.base/sun.net.www.http.HttpClient.openServer(HttpClient.java:603) >> ??? >? ? ? ? ? at >> ??? > >> java.base/sun.net.www.protocol.https.HttpsClient.(HttpsClient.java:266) >> ??? >? ? ? ? ? at >> ??? > >> java.base/sun.net.www.protocol.https.HttpsClient.New(HttpsClient.java:380) >> ??? >? ? ? ? ? at >> ??? > >> java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.getNewHttpClient(AbstractDelegateHttpsURLConnection.java:189) >> ??? >? ? ? ? ? at >> ??? > >> java.base/sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1242) >> ??? >? ? ? ? ? at >> ??? > >> java.base/sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:1128) >> ??? >? ? ? ? ? at >> ??? > >> java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:175) >> ??? >? ? ? ? ? at >> ??? > >> java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1665) >> ??? >? ? ? ? ? at >> ??? > >> java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1589) >> ??? >? ? ? ? ? at >> ??? > java.base/java.net >> .HttpURLConnection.getResponseCode(HttpURLConnection.java:529) >> ??? >? ? ? ? ? at >> ??? > >> java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:308) >> ??? > >> ??? > If I keep the runtime in $APPDIR\runtime, things don't fail in >> ??? this way. >> ??? > >> ??? > Smells like a bug in the app launcher to me.. but maybe it's in >> ??? the runtime? >> ??? > >> ??? > Any assistance would be appreciated (including telling me where >> ??? I should go >> ??? > to ask this, if this list isn't appropriate). >> ??? > >> ??? > Thanks, >> ??? > >> ??? > Scott >> From Alan.Bateman at oracle.com Tue Sep 21 15:40:21 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 21 Sep 2021 16:40:21 +0100 Subject: [External] : Re: What causes java.lang.InternalError: platform encoding not initialized ? In-Reply-To: <1ac831b0-9dd1-8c68-775b-0e2c3e58ac21@oracle.com> References: <397c959b-6a66-f32c-f673-05729dd705e7@oracle.com> <1ac831b0-9dd1-8c68-775b-0e2c3e58ac21@oracle.com> Message-ID: <3193c4a3-cb49-8653-cba0-61fa89aab0ee@oracle.com> On 21/09/2021 15:54, Andy Herrick wrote: > > I found the problem in > open/src/jdk.jpackage/windows/native/applauncher/WinLauncher.cpp > > we call SetDllDirectory() with the path to the bin dir in the default > runtime directory, not the actual runtime directory. > > since on Windows we never use other than the default runtime location > - we had not seen a problem, but is bug I will file and fix. > Good to see that you found it quickly. However I'm puzzled as why initializingEncoding wasn't called, I would have expected the VM to blow up during early startup. Would you have cycles to dig into that a bit more in case something has been masked, like for example an exception being swallowed.? Running with -Xlog:exceptions might reveal something. -Alan From plevart at openjdk.java.net Tue Sep 21 15:41:31 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Tue, 21 Sep 2021 15:41:31 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v8] In-Reply-To: <_q8hgIBxgjfnYvjHbHb6UtE1qB-n_reC9iY-Q9-WUEQ=.2d5f9a27-8b1e-4019-b4da-51260e37ddb5@github.com> References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> <5V0eAcrG9rS-d9RnyC2oJ5kVo6v84IhyBn40M71mYUg=.5d8c17fe-a23b-49a8-bfef-f670c0f013eb@github.com> <_q8hgIBxgjfnYvjHbHb6UtE1qB-n_reC9iY-Q9-WUEQ=.2d5f9a27-8b1e-4019-b4da-51260e37ddb5@github.com> Message-ID: On Tue, 21 Sep 2021 15:06:49 GMT, Claes Redestad wrote: > > If you look at "Poly" results, spinning MHInvoker/VHInvoker classes for each instance of Method/Field does not help at all. > > The added indirection in the "Poly" test might cause the code to fall off the inlining cliff, so that any constant folding becomes unlikely to happen. I agree that this might be closer to what happens in a real app, and as a data point it does show that the MHInvoker/VHInvoker optimizations might have been misguided. It is not the added indirection (I can add an indirection in the "Var" case too and benchmark would not change), but the variation of Method/Field instances used at the same call-site. When there is only one instance ("Var" case), delegating invocation of a MH to a MHInvoker somehow optimizes speculatively with a guard that just checks that the same MHInvoker class is used each time and further code is generated with constant MH. Such speculative optimization does not happen with non-constant MHs unfortunately despite the fact that there is only one MH instance. But in "Poly" case, generated MHInvoker classes don't help as there are multiple such classes and the speculative optimization falls apart (or is never even tried). ------------- PR: https://git.openjdk.java.net/jdk/pull/5027 From swpalmer at gmail.com Tue Sep 21 15:43:43 2021 From: swpalmer at gmail.com (Scott Palmer) Date: Tue, 21 Sep 2021 11:43:43 -0400 Subject: [External] : Re: What causes java.lang.InternalError: platform encoding not initialized ? In-Reply-To: <3193c4a3-cb49-8653-cba0-61fa89aab0ee@oracle.com> References: <3193c4a3-cb49-8653-cba0-61fa89aab0ee@oracle.com> Message-ID: <6CFC7D01-E12B-4DC6-9E30-33B4CB89059F@gmail.com> > On Sep 21, 2021, at 11:40 AM, Alan Bateman wrote: > > ?On 21/09/2021 15:54, Andy Herrick wrote: >> >> I found the problem in open/src/jdk.jpackage/windows/native/applauncher/WinLauncher.cpp >> >> we call SetDllDirectory() with the path to the bin dir in the default runtime directory, not the actual runtime directory. >> >> since on Windows we never use other than the default runtime location - we had not seen a problem, but is bug I will file and fix. >> > Good to see that you found it quickly. However I'm puzzled as why initializingEncoding wasn't called, I would have expected the VM to blow up during early startup. Would you have cycles to dig into that a bit more in case something has been masked, like for example an exception being swallowed. Running with -Xlog:exceptions might reveal something. Do you have a case that reproduces the issue? Scott From darcy at openjdk.java.net Tue Sep 21 15:59:34 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 21 Sep 2021 15:59:34 GMT Subject: RFR: 8274075: Fix miscellaneous typos in java.base [v2] In-Reply-To: References: <27dIhnD8Wc7kQcxq45Np2Lo68AhZvSgmmoV67fgL8rs=.9d8115bf-5176-4de5-99d8-963dc0d12c8f@github.com> Message-ID: On Tue, 21 Sep 2021 13:16:02 GMT, Pavel Rappo wrote: >> 8274075: Fix miscellaneous typos in java.base > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Tweak wording for Throwable constructor parameters Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5610 From dfuchs at openjdk.java.net Tue Sep 21 15:59:37 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 21 Sep 2021 15:59:37 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v5] In-Reply-To: <7knPZhBCZjPeooByk6ak-abopLwM0GP1Ye5DBO4M3Lw=.f9f27843-dd6f-4079-a41a-33c4c3a3b264@github.com> References: <4uCMVxnjarwTD6D9ngFv-pGAf6NjwGPddh7I4_sayCQ=.102746de-2a11-4aa7-82dc-601a6f228671@github.com> <7knPZhBCZjPeooByk6ak-abopLwM0GP1Ye5DBO4M3Lw=.f9f27843-dd6f-4079-a41a-33c4c3a3b264@github.com> Message-ID: On Tue, 21 Sep 2021 15:06:09 GMT, Hannes Walln?fer wrote: >> test/jdk/com/sun/net/httpserver/simpleserver/SecurityManagerTest.java line 198: >> >>> 196: >>> 197: static final DateTimeFormatter HTTP_DATE_FORMATTER = >>> 198: DateTimeFormatter.ofPattern("EEE, dd MMM yyyy HH:mm:ss v"); >> >> I think this and other usages of `DateTimeFormatter.ofPattern` need to be called with `Locale.US` (or something similar) as second argument, otherwise the current default locale will be used. I noticed because on my laptop the `Last-modified` header contains a german date. > > I just realized I commented on a test file, while the actual culprit is in `FileServerHandler.java`. But I guess it applies to all usages of this class and method. Hmm... When printing messages on the console don't we want a localized date? Or are you referring to other usages of the date formatter? Worth double checking in any case. ------------- PR: https://git.openjdk.java.net/jdk/pull/5505 From michaelm at openjdk.java.net Tue Sep 21 16:08:39 2021 From: michaelm at openjdk.java.net (Michael McMahon) Date: Tue, 21 Sep 2021 16:08:39 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v5] In-Reply-To: <4uCMVxnjarwTD6D9ngFv-pGAf6NjwGPddh7I4_sayCQ=.102746de-2a11-4aa7-82dc-601a6f228671@github.com> References: <4uCMVxnjarwTD6D9ngFv-pGAf6NjwGPddh7I4_sayCQ=.102746de-2a11-4aa7-82dc-601a6f228671@github.com> Message-ID: On Tue, 21 Sep 2021 14:09:54 GMT, Julia Boes wrote: >> This change implements a simple web server that can be run on the command-line with `java -m jdk.httpserver`. >> >> This is facilitated by adding an entry point for the `jdk.httpserver` module, an implementation class whose main method is run when the above command is executed. This is the first such module entry point in the JDK. >> >> The server is a minimal HTTP server that serves the static files of a given directory, similar to existing alternatives on other platforms and convenient for testing, development, and debugging. >> >> Additionally, a small API is introduced for programmatic creation and customization. >> >> Testing: tier1-3. > > Julia Boes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Merge branch 'master' into simpleserver > - Merge remote-tracking branch 'origin/simpleserver' into simpleserver > - Merge branch 'master' into simpleserver > - refactor isHidden,isReadable,isSymlink checks and cleanup tests > - Merge branch 'master' into simpleserver > - check isHidden, isSymlink, isReadable for all path segments > - add checks for all path segments > - Merge branch 'master' into componentcheck > - Merge branch 'master' into simpleserver > - improve output on startup > - ... and 6 more: https://git.openjdk.java.net/jdk/compare/6d91a3eb...fe059131 test/jdk/com/sun/net/httpserver/FilterTest.java line 330: > 328: var response = client.send(request, HttpResponse.BodyHandlers.ofString()); > 329: assertEquals(response.statusCode(), 200); > 330: assertEquals(inspectedURI.get(), URI.create("/")); Could you make the request URI something like /foo/bar instead of just / here? ------------- PR: https://git.openjdk.java.net/jdk/pull/5505 From dfuchs at openjdk.java.net Tue Sep 21 16:08:37 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 21 Sep 2021 16:08:37 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v5] In-Reply-To: <4uCMVxnjarwTD6D9ngFv-pGAf6NjwGPddh7I4_sayCQ=.102746de-2a11-4aa7-82dc-601a6f228671@github.com> References: <4uCMVxnjarwTD6D9ngFv-pGAf6NjwGPddh7I4_sayCQ=.102746de-2a11-4aa7-82dc-601a6f228671@github.com> Message-ID: On Tue, 21 Sep 2021 14:09:54 GMT, Julia Boes wrote: >> This change implements a simple web server that can be run on the command-line with `java -m jdk.httpserver`. >> >> This is facilitated by adding an entry point for the `jdk.httpserver` module, an implementation class whose main method is run when the above command is executed. This is the first such module entry point in the JDK. >> >> The server is a minimal HTTP server that serves the static files of a given directory, similar to existing alternatives on other platforms and convenient for testing, development, and debugging. >> >> Additionally, a small API is introduced for programmatic creation and customization. >> >> Testing: tier1-3. > > Julia Boes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Merge branch 'master' into simpleserver > - Merge remote-tracking branch 'origin/simpleserver' into simpleserver > - Merge branch 'master' into simpleserver > - refactor isHidden,isReadable,isSymlink checks and cleanup tests > - Merge branch 'master' into simpleserver > - check isHidden, isSymlink, isReadable for all path segments > - add checks for all path segments > - Merge branch 'master' into componentcheck > - Merge branch 'master' into simpleserver > - improve output on startup > - ... and 6 more: https://git.openjdk.java.net/jdk/compare/6d91a3eb...fe059131 src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/FileServerHandler.java line 314: > 312: + "

    \n"); > 313: try (var paths = Files.list(path)) { > 314: paths.filter(p -> !isHiddenOrSymLink(p)) Shouldn't we filter paths that are not readable here too? There's no point in printing a link that will result in 404, is there? ------------- PR: https://git.openjdk.java.net/jdk/pull/5505 From hannesw at openjdk.java.net Tue Sep 21 16:08:39 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Tue, 21 Sep 2021 16:08:39 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v5] In-Reply-To: References: <4uCMVxnjarwTD6D9ngFv-pGAf6NjwGPddh7I4_sayCQ=.102746de-2a11-4aa7-82dc-601a6f228671@github.com> <7knPZhBCZjPeooByk6ak-abopLwM0GP1Ye5DBO4M3Lw=.f9f27843-dd6f-4079-a41a-33c4c3a3b264@github.com> Message-ID: On Tue, 21 Sep 2021 15:27:12 GMT, Daniel Fuchs wrote: >> I just realized I commented on a test file, while the actual culprit is in `FileServerHandler.java`. But I guess it applies to all usages of this class and method. > > Hmm... When printing messages on the console don't we want a localized date? Or are you referring to other usages of the date formatter? Worth double checking in any case. The problem I was referring to was not about printing to the console. I hadn't thought about that, I agree the default locale should be used there. I was referring to `Last-modified` HTTP headers with a non-English date value, e.g.: Last-modified: Di., 21 Sep. 2021 09:56:53 GMT I think browsers will get confused by this. It probably isn't a big deal since I think the server doesn't implement conditional GETs (i.e. use the last-modified date in subsequent requests), but the HTTP spec is [quite strict ][1] about date formats. [1]: https://datatracker.ietf.org/doc/html/rfc2616#section-3.3.1 ------------- PR: https://git.openjdk.java.net/jdk/pull/5505 From andy.herrick at oracle.com Tue Sep 21 16:12:26 2021 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 21 Sep 2021 12:12:26 -0400 Subject: [External] : Re: What causes java.lang.InternalError: platform encoding not initialized ? In-Reply-To: <6CFC7D01-E12B-4DC6-9E30-33B4CB89059F@gmail.com> References: <3193c4a3-cb49-8653-cba0-61fa89aab0ee@oracle.com> <6CFC7D01-E12B-4DC6-9E30-33B4CB89059F@gmail.com> Message-ID: I thought I could create a reproduction scenario by using an app with "-splash:" arg then moving the jre as you did, but I have not yet been able make it fail. /Andy On 9/21/2021 11:43 AM, Scott Palmer wrote: >> On Sep 21, 2021, at 11:40 AM, Alan Bateman wrote: >> >> ?On 21/09/2021 15:54, Andy Herrick wrote: >>> I found the problem in open/src/jdk.jpackage/windows/native/applauncher/WinLauncher.cpp >>> >>> we call SetDllDirectory() with the path to the bin dir in the default runtime directory, not the actual runtime directory. >>> >>> since on Windows we never use other than the default runtime location - we had not seen a problem, but is bug I will file and fix. >>> >> Good to see that you found it quickly. However I'm puzzled as why initializingEncoding wasn't called, I would have expected the VM to blow up during early startup. Would you have cycles to dig into that a bit more in case something has been masked, like for example an exception being swallowed. Running with -Xlog:exceptions might reveal something. > > Do you have a case that reproduces the issue? > > Scott From dfuchs at openjdk.java.net Tue Sep 21 16:24:37 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 21 Sep 2021 16:24:37 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v5] In-Reply-To: References: <4uCMVxnjarwTD6D9ngFv-pGAf6NjwGPddh7I4_sayCQ=.102746de-2a11-4aa7-82dc-601a6f228671@github.com> <7knPZhBCZjPeooByk6ak-abopLwM0GP1Ye5DBO4M3Lw=.f9f27843-dd6f-4079-a41a-33c4c3a3b264@github.com> Message-ID: On Tue, 21 Sep 2021 16:03:28 GMT, Hannes Walln?fer wrote: >> Hmm... When printing messages on the console don't we want a localized date? Or are you referring to other usages of the date formatter? Worth double checking in any case. > > The problem I was referring to was not about printing to the console. I hadn't thought about that, I agree the default locale should be used there. I was referring to `Last-modified` HTTP headers with a non-English date value, e.g.: > > Last-modified: Di., 21 Sep. 2021 09:56:53 GMT > > I think browsers will get confused by this. It probably isn't a big deal since I think the server doesn't implement conditional GETs (i.e. use the last-modified date in subsequent requests), but the HTTP spec is [quite strict ][1] about date formats. > > [1]: https://datatracker.ietf.org/doc/html/rfc2616#section-3.3.1 Thanks for clarifying. Yes the date should be in GMT and should not be localized when sent in a `Last-Modified` / `Date` headers. Good catch! ------------- PR: https://git.openjdk.java.net/jdk/pull/5505 From mchung at openjdk.java.net Tue Sep 21 16:29:35 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 21 Sep 2021 16:29:35 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v8] In-Reply-To: <5V0eAcrG9rS-d9RnyC2oJ5kVo6v84IhyBn40M71mYUg=.5d8c17fe-a23b-49a8-bfef-f670c0f013eb@github.com> References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> <5V0eAcrG9rS-d9RnyC2oJ5kVo6v84IhyBn40M71mYUg=.5d8c17fe-a23b-49a8-bfef-f670c0f013eb@github.com> Message-ID: On Wed, 1 Sep 2021 01:05:32 GMT, Mandy Chung wrote: >> This reimplements core reflection with method handles. >> >> For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. >> >> The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. >> >> The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. >> >> Ran tier1-tier8 tests. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8013527 >> [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > minor cleanup and more test case. > On balance I think removing class-spinning might mean a better overall story w.r.t. footprint and maintainability. > : > So I think I'm in favor of simplifying and filing a follow-up to try and win back some of the performance we might be losing on corner-case micros without the custom class spinning. Great! I'll update the PR with Peter's patch + vh2mh with removal of StaticFieldAccessor/InstanceFieldAccessor inner classes [2] (no significant performance difference between [1] and [2]). > I wish MethodHandles obtained by unreflectGetter/unreflectSetter could be less sensitive to where they are read from (constant vs. not-constant) and optimize better in non-constant case. I think we should search in this direction... to make MethodHandles obtained by unreflectGetter/unreflectSetter more optimal in non-constant case. Yup, that's what the performance opportunity we should explore to improve MH/VH that will benefit all clients of MH/VH as well as core reflection. [1] http://cr.openjdk.java.net/~mchung/jep416/vh-mh.patch [2] http://cr.openjdk.java.net/~mchung/jep416/vh-mh-2.patch ------------- PR: https://git.openjdk.java.net/jdk/pull/5027 From mchung at openjdk.java.net Tue Sep 21 16:36:43 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 21 Sep 2021 16:36:43 GMT Subject: RFR: 8274071: Clean up java.lang.ref comments and documentation In-Reply-To: References: Message-ID: <71CiIkHAXjAldcdwtSgTG060B2_hyXFvrI89RvUDep4=.5803bd19-dbe7-41d6-a402-21d969886e26@github.com> On Tue, 21 Sep 2021 12:05:27 GMT, Pavel Rappo wrote: > This PR fixes an inline comment typo and reduces "overlinking" in a doc comment in `java.lang.ref.Reference`. Overlinking happens because the `reachabilityFence` method: > * Links `package-summary.html#reachability` twice. > * Refers to JLS 12.6 twice: once from a block tag and once from an inline tag. Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5609 From iris at openjdk.java.net Tue Sep 21 16:43:33 2021 From: iris at openjdk.java.net (Iris Clark) Date: Tue, 21 Sep 2021 16:43:33 GMT Subject: RFR: 8274071: Clean up java.lang.ref comments and documentation In-Reply-To: References: Message-ID: <-S0zxl_miyEVzHpd6Nje-8sBen2sJBVPVWX7NY8pU14=.c8597fa2-432c-453c-a375-5733b617864e@github.com> On Tue, 21 Sep 2021 12:05:27 GMT, Pavel Rappo wrote: > This PR fixes an inline comment typo and reduces "overlinking" in a doc comment in `java.lang.ref.Reference`. Overlinking happens because the `reachabilityFence` method: > * Links `package-summary.html#reachability` twice. > * Refers to JLS 12.6 twice: once from a block tag and once from an inline tag. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5609 From iris at openjdk.java.net Tue Sep 21 16:45:31 2021 From: iris at openjdk.java.net (Iris Clark) Date: Tue, 21 Sep 2021 16:45:31 GMT Subject: RFR: 8274075: Fix miscellaneous typos in java.base [v2] In-Reply-To: References: <27dIhnD8Wc7kQcxq45Np2Lo68AhZvSgmmoV67fgL8rs=.9d8115bf-5176-4de5-99d8-963dc0d12c8f@github.com> Message-ID: On Tue, 21 Sep 2021 13:16:02 GMT, Pavel Rappo wrote: >> 8274075: Fix miscellaneous typos in java.base > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Tweak wording for Throwable constructor parameters Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5610 From jboes at openjdk.java.net Tue Sep 21 16:46:37 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Tue, 21 Sep 2021 16:46:37 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v5] In-Reply-To: References: <4uCMVxnjarwTD6D9ngFv-pGAf6NjwGPddh7I4_sayCQ=.102746de-2a11-4aa7-82dc-601a6f228671@github.com> <7knPZhBCZjPeooByk6ak-abopLwM0GP1Ye5DBO4M3Lw=.f9f27843-dd6f-4079-a41a-33c4c3a3b264@github.com> Message-ID: <2Z2AEyYp9xXtnkLAxj3C2z_MoupAPdeKSKBCJ3OrZoc=.b65885e6-966d-47e9-8127-bf14ad286e03@github.com> On Tue, 21 Sep 2021 16:18:54 GMT, Daniel Fuchs wrote: >> The problem I was referring to was not about printing to the console. I hadn't thought about that, I agree the default locale should be used there. I was referring to `Last-modified` HTTP headers with a non-English date value, e.g.: >> >> Last-modified: Di., 21 Sep. 2021 09:56:53 GMT >> >> I think browsers will get confused by this. It probably isn't a big deal since I think the server doesn't implement conditional GETs (i.e. use the last-modified date in subsequent requests), but the HTTP spec is [quite strict ][1] about date formats. >> >> [1]: https://datatracker.ietf.org/doc/html/rfc2616#section-3.3.1 > > Thanks for clarifying. Yes the date should be in GMT and should not be localized when sent in a `Last-Modified` / `Date` headers. Good catch! Good catch indeed, thanks! I'll update to GMT when used in the headers. ------------- PR: https://git.openjdk.java.net/jdk/pull/5505 From michaelm at openjdk.java.net Tue Sep 21 16:46:37 2021 From: michaelm at openjdk.java.net (Michael McMahon) Date: Tue, 21 Sep 2021 16:46:37 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v5] In-Reply-To: <4uCMVxnjarwTD6D9ngFv-pGAf6NjwGPddh7I4_sayCQ=.102746de-2a11-4aa7-82dc-601a6f228671@github.com> References: <4uCMVxnjarwTD6D9ngFv-pGAf6NjwGPddh7I4_sayCQ=.102746de-2a11-4aa7-82dc-601a6f228671@github.com> Message-ID: On Tue, 21 Sep 2021 14:09:54 GMT, Julia Boes wrote: >> This change implements a simple web server that can be run on the command-line with `java -m jdk.httpserver`. >> >> This is facilitated by adding an entry point for the `jdk.httpserver` module, an implementation class whose main method is run when the above command is executed. This is the first such module entry point in the JDK. >> >> The server is a minimal HTTP server that serves the static files of a given directory, similar to existing alternatives on other platforms and convenient for testing, development, and debugging. >> >> Additionally, a small API is introduced for programmatic creation and customization. >> >> Testing: tier1-3. > > Julia Boes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Merge branch 'master' into simpleserver > - Merge remote-tracking branch 'origin/simpleserver' into simpleserver > - Merge branch 'master' into simpleserver > - refactor isHidden,isReadable,isSymlink checks and cleanup tests > - Merge branch 'master' into simpleserver > - check isHidden, isSymlink, isReadable for all path segments > - add checks for all path segments > - Merge branch 'master' into componentcheck > - Merge branch 'master' into simpleserver > - improve output on startup > - ... and 6 more: https://git.openjdk.java.net/jdk/compare/6d91a3eb...fe059131 Changes requested by michaelm (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5505 From iris at openjdk.java.net Tue Sep 21 16:51:35 2021 From: iris at openjdk.java.net (Iris Clark) Date: Tue, 21 Sep 2021 16:51:35 GMT Subject: RFR: 8273924: ArrayIndexOutOfBoundsException thrown in java.util.JapaneseImperialCalendar.add() In-Reply-To: References: Message-ID: On Tue, 21 Sep 2021 12:47:00 GMT, Naoto Sato wrote: > Fixing an AIOOBE on normalizing the month value. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5611 From bpb at openjdk.java.net Tue Sep 21 16:51:35 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 21 Sep 2021 16:51:35 GMT Subject: RFR: 8274075: Fix miscellaneous typos in java.base [v2] In-Reply-To: References: <27dIhnD8Wc7kQcxq45Np2Lo68AhZvSgmmoV67fgL8rs=.9d8115bf-5176-4de5-99d8-963dc0d12c8f@github.com> Message-ID: On Tue, 21 Sep 2021 13:16:02 GMT, Pavel Rappo wrote: >> 8274075: Fix miscellaneous typos in java.base > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Tweak wording for Throwable constructor parameters src/java.base/share/classes/java/lang/Throwable.java line 68: > 66: * Further, doing so would tie the API of the upper layer to the details of > 67: * its implementation, assuming the lower layer's exception was a checked > 68: * exception. Throwing a "wrapping exception" (i.e., an exception containing a Are we sure that this should be "wrapping" and not "wrapped?" See also for example `java.security.cert.CertPathValidatorException.` ------------- PR: https://git.openjdk.java.net/jdk/pull/5610 From lancea at openjdk.java.net Tue Sep 21 17:00:31 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 21 Sep 2021 17:00:31 GMT Subject: RFR: 8274075: Fix miscellaneous typos in java.base [v2] In-Reply-To: References: <27dIhnD8Wc7kQcxq45Np2Lo68AhZvSgmmoV67fgL8rs=.9d8115bf-5176-4de5-99d8-963dc0d12c8f@github.com> Message-ID: <3CAzfIqzIJ33D1yXtmb_kt_0Qm2gl0BJ48VnsUi9JTA=.6dad803d-4330-46ab-bd99-7e5a0a53da22@github.com> On Tue, 21 Sep 2021 13:16:02 GMT, Pavel Rappo wrote: >> 8274075: Fix miscellaneous typos in java.base > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Tweak wording for Throwable constructor parameters Overall looks like a good clean up. just not sure of "wrapping" vs. "wrapped" given the sentence starts with "Throwing". ------------- PR: https://git.openjdk.java.net/jdk/pull/5610 From lancea at openjdk.java.net Tue Sep 21 17:00:32 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 21 Sep 2021 17:00:32 GMT Subject: RFR: 8274075: Fix miscellaneous typos in java.base [v2] In-Reply-To: References: <27dIhnD8Wc7kQcxq45Np2Lo68AhZvSgmmoV67fgL8rs=.9d8115bf-5176-4de5-99d8-963dc0d12c8f@github.com> Message-ID: On Tue, 21 Sep 2021 16:48:53 GMT, Brian Burkhalter wrote: >> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: >> >> Tweak wording for Throwable constructor parameters > > src/java.base/share/classes/java/lang/Throwable.java line 68: > >> 66: * Further, doing so would tie the API of the upper layer to the details of >> 67: * its implementation, assuming the lower layer's exception was a checked >> 68: * exception. Throwing a "wrapping exception" (i.e., an exception containing a > > Are we sure that this should be "wrapping" and not "wrapped?" See also for example `java.security.cert.CertPathValidatorException.` It does seem a bit strange to say "Throwing a wrapping...." ------------- PR: https://git.openjdk.java.net/jdk/pull/5610 From lancea at openjdk.java.net Tue Sep 21 17:01:32 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 21 Sep 2021 17:01:32 GMT Subject: RFR: 8274071: Clean up java.lang.ref comments and documentation In-Reply-To: References: Message-ID: On Tue, 21 Sep 2021 12:05:27 GMT, Pavel Rappo wrote: > This PR fixes an inline comment typo and reduces "overlinking" in a doc comment in `java.lang.ref.Reference`. Overlinking happens because the `reachabilityFence` method: > * Links `package-summary.html#reachability` twice. > * Refers to JLS 12.6 twice: once from a block tag and once from an inline tag. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5609 From prappo at openjdk.java.net Tue Sep 21 17:13:28 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 21 Sep 2021 17:13:28 GMT Subject: RFR: 8274075: Fix miscellaneous typos in java.base [v2] In-Reply-To: References: <27dIhnD8Wc7kQcxq45Np2Lo68AhZvSgmmoV67fgL8rs=.9d8115bf-5176-4de5-99d8-963dc0d12c8f@github.com> Message-ID: On Tue, 21 Sep 2021 16:56:03 GMT, Lance Andersen wrote: >> src/java.base/share/classes/java/lang/Throwable.java line 68: >> >>> 66: * Further, doing so would tie the API of the upper layer to the details of >>> 67: * its implementation, assuming the lower layer's exception was a checked >>> 68: * exception. Throwing a "wrapping exception" (i.e., an exception containing a >> >> Are we sure that this should be "wrapping" and not "wrapped?" See also for example `java.security.cert.CertPathValidatorException.` > > It does seem a bit strange to say "Throwing a wrapping...." If we have two exceptions A and B, such that B is the cause of A, then A is the wrapping exception (the one that wraps or the wrapper) and B is the wrapped exception (the one that is being wrapped or the wrappee). I noticed that the sentence was conflicting: it started with the "wrapped" exception, but then in the "i.e." commentary in parentheses proceeded with the wrappee exception. To resolve that conflict, I proposed to rephrase the first part of that sentence. FWIW, my original suggestion elsewhere was to use "wrapper". ------------- PR: https://git.openjdk.java.net/jdk/pull/5610 From bpb at openjdk.java.net Tue Sep 21 17:13:28 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 21 Sep 2021 17:13:28 GMT Subject: RFR: 8274075: Fix miscellaneous typos in java.base [v2] In-Reply-To: References: <27dIhnD8Wc7kQcxq45Np2Lo68AhZvSgmmoV67fgL8rs=.9d8115bf-5176-4de5-99d8-963dc0d12c8f@github.com> Message-ID: On Tue, 21 Sep 2021 17:07:45 GMT, Pavel Rappo wrote: >> It does seem a bit strange to say "Throwing a wrapping...." > > If we have two exceptions A and B, such that B is the cause of A, then A is the wrapping exception (the one that wraps or the wrapper) and B is the wrapped exception (the one that is being wrapped or the wrappee). > > I noticed that the sentence was conflicting: it started with the "wrapped" exception, but then in the "i.e." commentary in parentheses proceeded with the wrappee exception. To resolve that conflict, I proposed to rephrase the first part of that sentence. FWIW, my original suggestion elsewhere was to use "wrapper". Subjectively, "wrapping exception" would seem to be an exception in the process of wrapping something. ------------- PR: https://git.openjdk.java.net/jdk/pull/5610 From prappo at openjdk.java.net Tue Sep 21 17:17:31 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 21 Sep 2021 17:17:31 GMT Subject: RFR: 8274075: Fix miscellaneous typos in java.base [v2] In-Reply-To: References: <27dIhnD8Wc7kQcxq45Np2Lo68AhZvSgmmoV67fgL8rs=.9d8115bf-5176-4de5-99d8-963dc0d12c8f@github.com> Message-ID: <4_RdSmkMBlUHObLQDGcNhQRytTUvqTjXaqDBsI-awb0=.c387c56b-3724-4271-8293-4db417d6545f@github.com> On Tue, 21 Sep 2021 17:10:02 GMT, Brian Burkhalter wrote: >> If we have two exceptions A and B, such that B is the cause of A, then A is the wrapping exception (the one that wraps or the wrapper) and B is the wrapped exception (the one that is being wrapped or the wrappee). >> >> I noticed that the sentence was conflicting: it started with the "wrapped" exception, but then in the "i.e." commentary in parentheses proceeded with the wrappee exception. To resolve that conflict, I proposed to rephrase the first part of that sentence. FWIW, my original suggestion elsewhere was to use "wrapper". > > Subjectively, "wrapping exception" would seem to be an exception in the process of wrapping something. Would "wrappER" be better? ------------- PR: https://git.openjdk.java.net/jdk/pull/5610 From michaelm at openjdk.java.net Tue Sep 21 17:19:44 2021 From: michaelm at openjdk.java.net (Michael McMahon) Date: Tue, 21 Sep 2021 17:19:44 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v5] In-Reply-To: <4uCMVxnjarwTD6D9ngFv-pGAf6NjwGPddh7I4_sayCQ=.102746de-2a11-4aa7-82dc-601a6f228671@github.com> References: <4uCMVxnjarwTD6D9ngFv-pGAf6NjwGPddh7I4_sayCQ=.102746de-2a11-4aa7-82dc-601a6f228671@github.com> Message-ID: On Tue, 21 Sep 2021 14:09:54 GMT, Julia Boes wrote: >> This change implements a simple web server that can be run on the command-line with `java -m jdk.httpserver`. >> >> This is facilitated by adding an entry point for the `jdk.httpserver` module, an implementation class whose main method is run when the above command is executed. This is the first such module entry point in the JDK. >> >> The server is a minimal HTTP server that serves the static files of a given directory, similar to existing alternatives on other platforms and convenient for testing, development, and debugging. >> >> Additionally, a small API is introduced for programmatic creation and customization. >> >> Testing: tier1-3. > > Julia Boes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Merge branch 'master' into simpleserver > - Merge remote-tracking branch 'origin/simpleserver' into simpleserver > - Merge branch 'master' into simpleserver > - refactor isHidden,isReadable,isSymlink checks and cleanup tests > - Merge branch 'master' into simpleserver > - check isHidden, isSymlink, isReadable for all path segments > - add checks for all path segments > - Merge branch 'master' into componentcheck > - Merge branch 'master' into simpleserver > - improve output on startup > - ... and 6 more: https://git.openjdk.java.net/jdk/compare/6d91a3eb...fe059131 src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/SimpleFileServerImpl.java line 135: > 133: var socketAddr = new InetSocketAddress(addr, port); > 134: var server = SimpleFileServer.createFileServer(socketAddr, root, outputLevel); > 135: server.setExecutor(Executors.newSingleThreadExecutor()); I think this code has the effect of creating one thread for the selector and a second one for the execution of the handlers. If we want to keep thread usage to an absolute minimum then it might be better to not set an executor. Then, the selector thread executes the handlers as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/5505 From prappo at openjdk.java.net Tue Sep 21 17:42:35 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 21 Sep 2021 17:42:35 GMT Subject: RFR: 8274075: Fix miscellaneous typos in java.base [v2] In-Reply-To: <4_RdSmkMBlUHObLQDGcNhQRytTUvqTjXaqDBsI-awb0=.c387c56b-3724-4271-8293-4db417d6545f@github.com> References: <27dIhnD8Wc7kQcxq45Np2Lo68AhZvSgmmoV67fgL8rs=.9d8115bf-5176-4de5-99d8-963dc0d12c8f@github.com> <4_RdSmkMBlUHObLQDGcNhQRytTUvqTjXaqDBsI-awb0=.c387c56b-3724-4271-8293-4db417d6545f@github.com> Message-ID: On Tue, 21 Sep 2021 17:14:31 GMT, Pavel Rappo wrote: >> Subjectively, "wrapping exception" would seem to be an exception in the process of wrapping something. > > Would "wrappER" be better? We can either revert this part of the change or rephrase it. Mind you, rephrasing might prove tricky because of non-local changes it might introduce. There's one more occurrence of "wrapped exception" in this file: https://github.com/openjdk/jdk/blob/19b6f49649a317e6b255aeb810c8d533119b93bb/src/java.base/share/classes/java/lang/Throwable.java#L548-L554 ------------- PR: https://git.openjdk.java.net/jdk/pull/5610 From bpb at openjdk.java.net Tue Sep 21 17:55:30 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 21 Sep 2021 17:55:30 GMT Subject: RFR: 8274075: Fix miscellaneous typos in java.base [v2] In-Reply-To: References: <27dIhnD8Wc7kQcxq45Np2Lo68AhZvSgmmoV67fgL8rs=.9d8115bf-5176-4de5-99d8-963dc0d12c8f@github.com> <4_RdSmkMBlUHObLQDGcNhQRytTUvqTjXaqDBsI-awb0=.c387c56b-3724-4271-8293-4db417d6545f@github.com> Message-ID: On Tue, 21 Sep 2021 17:39:41 GMT, Pavel Rappo wrote: >> Would "wrappER" be better? > > We can either revert this part of the change or rephrase it. Mind you, rephrasing might prove tricky because of non-local changes it might introduce. There's one more occurrence of "wrapped exception" in this file: https://github.com/openjdk/jdk/blob/19b6f49649a317e6b255aeb810c8d533119b93bb/src/java.base/share/classes/java/lang/Throwable.java#L548-L554 Instead of "common case where a wrapped exception is thrown from same method" could one write "common case where an enclosing exception is thrown from the same method"? ------------- PR: https://git.openjdk.java.net/jdk/pull/5610 From rriggs at openjdk.java.net Tue Sep 21 18:21:53 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 21 Sep 2021 18:21:53 GMT Subject: RFR: 8274003: ProcessHandleImpl.Info toString has an if check which is always true Message-ID: Correct the check if any field has been appended to the StringBuilder in ProcessHandleImpl.Info.toString(). ------------- Commit messages: - 8274003: ProcessHandleImpl.Info toString has an if check which is always true Changes: https://git.openjdk.java.net/jdk/pull/5618/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5618&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274003 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/5618.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5618/head:pull/5618 PR: https://git.openjdk.java.net/jdk/pull/5618 From bpb at openjdk.java.net Tue Sep 21 18:34:33 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 21 Sep 2021 18:34:33 GMT Subject: RFR: 8274003: ProcessHandleImpl.Info toString has an if check which is always true In-Reply-To: References: Message-ID: On Tue, 21 Sep 2021 18:14:17 GMT, Roger Riggs wrote: > Correct the check if any field has been appended to the StringBuilder in ProcessHandleImpl.Info.toString(). Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5618 From naoto at openjdk.java.net Tue Sep 21 18:38:33 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 21 Sep 2021 18:38:33 GMT Subject: RFR: 8274003: ProcessHandleImpl.Info toString has an if check which is always true In-Reply-To: References: Message-ID: On Tue, 21 Sep 2021 18:14:17 GMT, Roger Riggs wrote: > Correct the check if any field has been appended to the StringBuilder in ProcessHandleImpl.Info.toString(). Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5618 From iris at openjdk.java.net Tue Sep 21 19:11:30 2021 From: iris at openjdk.java.net (Iris Clark) Date: Tue, 21 Sep 2021 19:11:30 GMT Subject: RFR: 8274003: ProcessHandleImpl.Info toString has an if check which is always true In-Reply-To: References: Message-ID: On Tue, 21 Sep 2021 18:14:17 GMT, Roger Riggs wrote: > Correct the check if any field has been appended to the StringBuilder in ProcessHandleImpl.Info.toString(). Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5618 From lancea at openjdk.java.net Tue Sep 21 19:43:24 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 21 Sep 2021 19:43:24 GMT Subject: Integrated: 8273935: (zipfs) Files.getFileAttributeView() throws UOE instead of returning null when view not supported In-Reply-To: References: Message-ID: <3TtA8XpYByMzr-43PVIR3NZsWd3ZQDOVe_L0ArZwUMI=.2bb90053-4418-40a3-9e04-d5984d86d092@github.com> On Sun, 19 Sep 2021 15:34:44 GMT, Lance Andersen wrote: > Hi all, > > Please review this patch which addresses the issue where Zip FS will throw a UOE instead of returning null when Files.getFileAttributeView() is invoked and the view not supported. > > Mach5 tiers1 - tier3 are clean. > > Best > Lance This pull request has now been integrated. Changeset: 161fdb4a Author: Lance Andersen URL: https://git.openjdk.java.net/jdk/commit/161fdb4afbc6e67cc7580fe753112c4d894a9b6b Stats: 108 lines in 4 files changed: 102 ins; 0 del; 6 mod 8273935: (zipfs) Files.getFileAttributeView() throws UOE instead of returning null when view not supported Reviewed-by: alanb, bpb, sgehwolf ------------- PR: https://git.openjdk.java.net/jdk/pull/5579 From swpalmer at gmail.com Tue Sep 21 19:49:04 2021 From: swpalmer at gmail.com (Scott Palmer) Date: Tue, 21 Sep 2021 15:49:04 -0400 Subject: [External] : Re: What causes java.lang.InternalError: platform encoding not initialized ? In-Reply-To: References: <3193c4a3-cb49-8653-cba0-61fa89aab0ee@oracle.com> <6CFC7D01-E12B-4DC6-9E30-33B4CB89059F@gmail.com> Message-ID: <6D4BA3E6-0A48-4F43-B62D-63F8D356F27A@gmail.com> I have discovered that I have to have my Java Agent configured in the .cfg file for it to happen: [JavaOptions] java-option=-javaagent:$APPDIR\libs\MyAgent.jar The agent is needed in my real app only to get an instance of the Instrumentation interface. In my test code, where I have reproduced this, it is never used. My test app just takes a URL and fetches it via a HttpURLConnection with setInstanceFollowRedirects(false) so I can capture the new location. If you are still having trouble reproducing I will have the code cleaned up for the bug report soon... Regards, Scott > On Sep 21, 2021, at 12:12 PM, Andy Herrick wrote: > > I thought I could create a reproduction scenario by using an app with "-splash:" arg then moving the jre as you did, but I have not yet been able make it fail. > > /Andy > > On 9/21/2021 11:43 AM, Scott Palmer wrote: >>> On Sep 21, 2021, at 11:40 AM, Alan Bateman wrote: >>> >>> ?On 21/09/2021 15:54, Andy Herrick wrote: >>>> I found the problem in open/src/jdk.jpackage/windows/native/applauncher/WinLauncher.cpp >>>> >>>> we call SetDllDirectory() with the path to the bin dir in the default runtime directory, not the actual runtime directory. >>>> >>>> since on Windows we never use other than the default runtime location - we had not seen a problem, but is bug I will file and fix. >>>> >>> Good to see that you found it quickly. However I'm puzzled as why initializingEncoding wasn't called, I would have expected the VM to blow up during early startup. Would you have cycles to dig into that a bit more in case something has been masked, like for example an exception being swallowed. Running with -Xlog:exceptions might reveal something. >> >> Do you have a case that reproduces the issue? >> >> Scott From rriggs at openjdk.java.net Tue Sep 21 20:11:39 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 21 Sep 2021 20:11:39 GMT Subject: RFR: 8269850: Most JDK releases report macOS version 12 as 10.16 instead of 12.0 Message-ID: <9tr2u5U38f-H1rNN3v69B48KsEI3MoZSWBnYgsy9vqw=.0f46fd59-da71-4d69-8da3-3569e4eb4603@github.com> The Mac OS specific code to determine the os.version property in java_props_macosx.c is updated to replace the code extracting the version from the SystemVersion.plist by reading the version using the hidden link: `/System/Library/CoreServices/.SystemVersionPlatform.plist` Its contents are not dependent on the SYSTEM_VERSION_COMPAT environment variable. With this change, 11.5 reports the 11.5.1 minor version and os.version 11.6 is correctly reported. The change can be backported to other versions as needed. ------------- Commit messages: - 8269850: Most JDK releases report macOS version 12 as 10.16 instead of 12.0 Changes: https://git.openjdk.java.net/jdk/pull/5619/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5619&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269850 Stats: 11 lines in 1 file changed: 1 ins; 6 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/5619.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5619/head:pull/5619 PR: https://git.openjdk.java.net/jdk/pull/5619 From bpb at openjdk.java.net Tue Sep 21 20:59:59 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 21 Sep 2021 20:59:59 GMT Subject: RFR: 8269850: Most JDK releases report macOS version 12 as 10.16 instead of 12.0 In-Reply-To: <9tr2u5U38f-H1rNN3v69B48KsEI3MoZSWBnYgsy9vqw=.0f46fd59-da71-4d69-8da3-3569e4eb4603@github.com> References: <9tr2u5U38f-H1rNN3v69B48KsEI3MoZSWBnYgsy9vqw=.0f46fd59-da71-4d69-8da3-3569e4eb4603@github.com> Message-ID: On Tue, 21 Sep 2021 19:33:05 GMT, Roger Riggs wrote: > The Mac OS specific code to determine the os.version property in java_props_macosx.c is updated > to replace the code extracting the version from the SystemVersion.plist by reading the version using the hidden link: > `/System/Library/CoreServices/.SystemVersionPlatform.plist` > > Its contents are not dependent on the SYSTEM_VERSION_COMPAT environment variable. > With this change, 11.5 reports the 11.5.1 minor version and os.version 11.6 is correctly reported. > The change can be backported to other versions as needed. Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5619 From turbanoff at gmail.com Tue Sep 21 21:09:09 2021 From: turbanoff at gmail.com (Andrey Turbanov) Date: Wed, 22 Sep 2021 00:09:09 +0300 Subject: Unused HashMap's in ThaiBuddhistChronology Message-ID: Hello. Today I discovered 3 static HashMap's in ThaiBuddhistChronology class: ERA_NARROW_NAMES, ERA_SHORT_NAMES, ERA_FULL_NAMES static initializer put some values into them. But their content seems unused after that. Do I miss something and they are used somewhere? Andrey Turbanov From roger.riggs at oracle.com Tue Sep 21 21:30:12 2021 From: roger.riggs at oracle.com (Roger Riggs) Date: Tue, 21 Sep 2021 17:30:12 -0400 Subject: Unused HashMap's in ThaiBuddhistChronology In-Reply-To: References: Message-ID: Indeed, they seem unused... Stephen, do you recall their original use? Thanks, Roger On 9/21/21 5:09 PM, Andrey Turbanov wrote: > Hello. > Today I discovered 3 static HashMap's in ThaiBuddhistChronology class: > ERA_NARROW_NAMES, ERA_SHORT_NAMES, ERA_FULL_NAMES > > static initializer put some values into them. But their content seems > unused after that. > Do I miss something and they are used somewhere? > > > Andrey Turbanov From naoto at openjdk.java.net Tue Sep 21 21:56:28 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 21 Sep 2021 21:56:28 GMT Subject: RFR: 8273546: DecimalFormat documentation contains literal HTML character references Message-ID: Simple doc fix. ------------- Commit messages: - 8273546: DecimalFormat documentation contains literal HTML character references Changes: https://git.openjdk.java.net/jdk/pull/5620/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5620&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273546 Stats: 14 lines in 3 files changed: 0 ins; 0 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/5620.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5620/head:pull/5620 PR: https://git.openjdk.java.net/jdk/pull/5620 From dholmes at openjdk.java.net Tue Sep 21 22:03:57 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 21 Sep 2021 22:03:57 GMT Subject: RFR: 8274075: Fix miscellaneous typos in java.base [v2] In-Reply-To: References: <27dIhnD8Wc7kQcxq45Np2Lo68AhZvSgmmoV67fgL8rs=.9d8115bf-5176-4de5-99d8-963dc0d12c8f@github.com> <4_RdSmkMBlUHObLQDGcNhQRytTUvqTjXaqDBsI-awb0=.c387c56b-3724-4271-8293-4db417d6545f@github.com> Message-ID: On Tue, 21 Sep 2021 17:52:31 GMT, Brian Burkhalter wrote: >> We can either revert this part of the change or rephrase it. Mind you, rephrasing might prove tricky because of non-local changes it might introduce. There's one more occurrence of "wrapped exception" in this file: https://github.com/openjdk/jdk/blob/19b6f49649a317e6b255aeb810c8d533119b93bb/src/java.base/share/classes/java/lang/Throwable.java#L548-L554 > > Instead of "common case where a wrapped exception is thrown from same method" could one write "common case where an enclosing exception is thrown from the same method"? Note that we don't throw the "wrapped exception" we throw the exception that wraps it. The "wrapped exception" is the original cause. The wording as presented now is correct in that regard. You could also say "Throwing a wrapper exception (i.e. one that has a cause)" - I think both are grammatically correct. The later text "where a wrapped exception is thrown from the same method" is again incorrect because the wrapped exception (the cause) is not what gets thrown. But I find that whole sentence rather jarring anyway - I'm not certain exactly what it means. ------------- PR: https://git.openjdk.java.net/jdk/pull/5610 From joehw at openjdk.java.net Tue Sep 21 22:09:00 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Tue, 21 Sep 2021 22:09:00 GMT Subject: RFR: 8273924: ArrayIndexOutOfBoundsException thrown in java.util.JapaneseImperialCalendar.add() In-Reply-To: References: Message-ID: <4XI5Sru_mY9hTsoVdcwOHFsGuhwGHpu5JjMrLhQDhgg=.d28210f6-22fd-4844-b663-3ef486535078@github.com> On Tue, 21 Sep 2021 12:47:00 GMT, Naoto Sato wrote: > Fixing an AIOOBE on normalizing the month value. Marked as reviewed by joehw (Reviewer). src/java.base/share/classes/sun/util/calendar/BaseCalendar.java line 281: > 279: month = 13 - (xm % 12); > 280: if (month == 13) { > 281: year ++; Not that it matters, just happen to see it ;-). Is it more common to have no space before the increment operator? Code convention seems to suggest no space before increment and their operands. No update needed should you decide to remove it. ------------- PR: https://git.openjdk.java.net/jdk/pull/5611 From naoto at openjdk.java.net Tue Sep 21 22:18:07 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 21 Sep 2021 22:18:07 GMT Subject: RFR: 8273924: ArrayIndexOutOfBoundsException thrown in java.util.JapaneseImperialCalendar.add() [v2] In-Reply-To: References: Message-ID: > Fixing an AIOOBE on normalizing the month value. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Removed the unnecessary space ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5611/files - new: https://git.openjdk.java.net/jdk/pull/5611/files/92f81963..98612bf5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5611&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5611&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5611.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5611/head:pull/5611 PR: https://git.openjdk.java.net/jdk/pull/5611 From naoto at openjdk.java.net Tue Sep 21 22:18:08 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 21 Sep 2021 22:18:08 GMT Subject: RFR: 8273924: ArrayIndexOutOfBoundsException thrown in java.util.JapaneseImperialCalendar.add() [v2] In-Reply-To: <4XI5Sru_mY9hTsoVdcwOHFsGuhwGHpu5JjMrLhQDhgg=.d28210f6-22fd-4844-b663-3ef486535078@github.com> References: <4XI5Sru_mY9hTsoVdcwOHFsGuhwGHpu5JjMrLhQDhgg=.d28210f6-22fd-4844-b663-3ef486535078@github.com> Message-ID: On Tue, 21 Sep 2021 22:03:30 GMT, Joe Wang wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed the unnecessary space > > src/java.base/share/classes/sun/util/calendar/BaseCalendar.java line 281: > >> 279: month = 13 - (xm % 12); >> 280: if (month == 13) { >> 281: year ++; > > Not that it matters, just happen to see it ;-). Is it more common to have no space before the increment operator? Code convention seems to suggest no space before increment and their operands. > No update needed should you decide to remove it. Thanks. Indeed it was in the coding convention. Removed. ------------- PR: https://git.openjdk.java.net/jdk/pull/5611 From joehw at openjdk.java.net Tue Sep 21 22:23:00 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Tue, 21 Sep 2021 22:23:00 GMT Subject: RFR: 8273924: ArrayIndexOutOfBoundsException thrown in java.util.JapaneseImperialCalendar.add() [v2] In-Reply-To: References: Message-ID: On Tue, 21 Sep 2021 22:18:07 GMT, Naoto Sato wrote: >> Fixing an AIOOBE on normalizing the month value. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Removed the unnecessary space Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5611 From joehw at openjdk.java.net Tue Sep 21 22:24:10 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Tue, 21 Sep 2021 22:24:10 GMT Subject: RFR: 8273546: DecimalFormat documentation contains literal HTML character references In-Reply-To: References: Message-ID: On Tue, 21 Sep 2021 21:45:40 GMT, Naoto Sato wrote: > Simple doc fix. Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5620 From bpb at openjdk.java.net Tue Sep 21 22:34:55 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 21 Sep 2021 22:34:55 GMT Subject: RFR: 8273546: DecimalFormat documentation contains literal HTML character references In-Reply-To: References: Message-ID: On Tue, 21 Sep 2021 21:45:40 GMT, Naoto Sato wrote: > Simple doc fix. Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5620 From iris at openjdk.java.net Tue Sep 21 22:49:00 2021 From: iris at openjdk.java.net (Iris Clark) Date: Tue, 21 Sep 2021 22:49:00 GMT Subject: RFR: 8273546: DecimalFormat documentation contains literal HTML character references In-Reply-To: References: Message-ID: On Tue, 21 Sep 2021 21:45:40 GMT, Naoto Sato wrote: > Simple doc fix. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5620 From iris at openjdk.java.net Tue Sep 21 22:49:59 2021 From: iris at openjdk.java.net (Iris Clark) Date: Tue, 21 Sep 2021 22:49:59 GMT Subject: RFR: 8273924: ArrayIndexOutOfBoundsException thrown in java.util.JapaneseImperialCalendar.add() [v2] In-Reply-To: References: Message-ID: On Tue, 21 Sep 2021 22:18:07 GMT, Naoto Sato wrote: >> Fixing an AIOOBE on normalizing the month value. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Removed the unnecessary space Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5611 From swpalmer at gmail.com Tue Sep 21 23:05:18 2021 From: swpalmer at gmail.com (Scott Palmer) Date: Tue, 21 Sep 2021 19:05:18 -0400 Subject: [External] : Re: What causes java.lang.InternalError: platform encoding not initialized ? In-Reply-To: <6D4BA3E6-0A48-4F43-B62D-63F8D356F27A@gmail.com> References: <3193c4a3-cb49-8653-cba0-61fa89aab0ee@oracle.com> <6CFC7D01-E12B-4DC6-9E30-33B4CB89059F@gmail.com> <6D4BA3E6-0A48-4F43-B62D-63F8D356F27A@gmail.com> Message-ID: I?ve uploaded a project that reproduces the problem to JDK-8274087 Regards, Scott > On Sep 21, 2021, at 3:49 PM, Scott Palmer wrote: > > I have discovered that I have to have my Java Agent configured in the .cfg file for it to happen: > > [JavaOptions] > java-option=-javaagent:$APPDIR\libs\MyAgent.jar > > > The agent is needed in my real app only to get an instance of the Instrumentation interface. In my test code, where I have reproduced this, it is never used. My test app just takes a URL and fetches it via a HttpURLConnection with setInstanceFollowRedirects(false) so I can capture the new location. If you are still having trouble reproducing I will have the code cleaned up for the bug report soon... > > > Regards, > > Scott > > > >> On Sep 21, 2021, at 12:12 PM, Andy Herrick wrote: >> >> I thought I could create a reproduction scenario by using an app with "-splash:" arg then moving the jre as you did, but I have not yet been able make it fail. >> >> /Andy >> >> On 9/21/2021 11:43 AM, Scott Palmer wrote: >>>> On Sep 21, 2021, at 11:40 AM, Alan Bateman wrote: >>>> >>>> ?On 21/09/2021 15:54, Andy Herrick wrote: >>>>> I found the problem in open/src/jdk.jpackage/windows/native/applauncher/WinLauncher.cpp >>>>> >>>>> we call SetDllDirectory() with the path to the bin dir in the default runtime directory, not the actual runtime directory. >>>>> >>>>> since on Windows we never use other than the default runtime location - we had not seen a problem, but is bug I will file and fix. >>>>> >>>> Good to see that you found it quickly. However I'm puzzled as why initializingEncoding wasn't called, I would have expected the VM to blow up during early startup. Would you have cycles to dig into that a bit more in case something has been masked, like for example an exception being swallowed. Running with -Xlog:exceptions might reveal something. >>> >>> Do you have a case that reproduces the issue? >>> >>> Scott > From lancea at openjdk.java.net Tue Sep 21 23:11:57 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 21 Sep 2021 23:11:57 GMT Subject: RFR: 8273546: DecimalFormat documentation contains literal HTML character references In-Reply-To: References: Message-ID: On Tue, 21 Sep 2021 21:45:40 GMT, Naoto Sato wrote: > Simple doc fix. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5620 From dholmes at openjdk.java.net Wed Sep 22 00:06:58 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 22 Sep 2021 00:06:58 GMT Subject: RFR: 8272600: (test) Use native "sleep" in Basic.java [v6] In-Reply-To: References: <1-B9MAOZK5XtDuFdxsWh3SgFnCk2MRdK-zbBcys1PbU=.1df445ba-dbaa-4480-a7ac-35dd79a7f920@github.com> Message-ID: On Tue, 21 Sep 2021 13:10:57 GMT, Roger Riggs wrote: >> test/jdk/java/lang/ProcessBuilder/Basic.java line 2217: >> >>> 2215: // A unique (59s) time is needed to avoid killing other sleep processes. >>> 2216: final String[] cmd = { "/bin/bash", "-c", "(/bin/sleep 59)" }; >>> 2217: final String[] cmdkill = { "/bin/bash", "-c", "(/usr/bin/pkill -f \"sleep 59\")" }; >> >> Maybe future RFE but why do we even need pkill here when we can get the PID of the sleep process we create and kill only that process? > > I thought of that too, but notice the parens "()" around that /bin/sleep; that creates and extra level of forked processes and its harder to get that pid. There probably is a way to traverse the hierarchy but I'll keep it as is for now. Ah right. Begs the question why we need to use bash to execute sleep? Could it be shell script instead of a binary? ------------- PR: https://git.openjdk.java.net/jdk/pull/5239 From john.r.rose at oracle.com Wed Sep 22 00:13:39 2021 From: john.r.rose at oracle.com (John Rose) Date: Wed, 22 Sep 2021 00:13:39 +0000 Subject: RFR: 8273656: Improve java.lang.invoke.MethodType.parameterList() and its usage In-Reply-To: References: Message-ID: <64EF28E9-9562-412A-B146-8928C0109D18@oracle.com> On Sep 13, 2021, at 10:24 AM, Vladimir Ivanov > wrote: BTW it can be improved even further by caching the immutable List view of parameters. I would go further: If I were writing MethodType.java today I would probably use List.of as the backing store for the parameters, instead of the private array. So ptypes should be List> not Class[]. I don?t think the footprint or polymorphism effects would be dealbreakers, and the code would (I think) be simpler overall. But that?s a messy change, since the array representation is dug in. From redestad at openjdk.java.net Wed Sep 22 00:24:59 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 22 Sep 2021 00:24:59 GMT Subject: RFR: 8273656: Improve java.lang.invoke.MethodType.parameterList() and its usage In-Reply-To: References: Message-ID: On Mon, 13 Sep 2021 11:06:15 GMT, ?????? ??????? wrote: > Currently the method is implemented like > > public List> parameterList() { > return Collections.unmodifiableList(Arrays.asList(ptypes.clone())); > } > > This seems to be excessive, as three objects are allocated here. Instead we can use `List.of(ptypes)` which doesn't allocate anything for empty array and for one of length 1 and 2 it allocates lightweight objects with 2 fields, still copying longer arrays. This is likely to be fruitful as most of methods have 0-2 parameters. > > Also there is a couple of cases when `MethodType.parameterLis()` is called to get its size, which is excessive either as we can use `MethodType.parameterCount()` instead. This change introduces a subtle behavior change in that `List.of` produce a `null`-hostile list, for example `list.contains(null)` will throw NPE. Does this need to be spelled out? (FTR I think such null-hostile behavior should be reconsidered) ------------- PR: https://git.openjdk.java.net/jdk/pull/5489 From Alan.Bateman at oracle.com Wed Sep 22 06:34:44 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 22 Sep 2021 07:34:44 +0100 Subject: [External] : Re: What causes java.lang.InternalError: platform encoding not initialized ? In-Reply-To: <6D4BA3E6-0A48-4F43-B62D-63F8D356F27A@gmail.com> References: <3193c4a3-cb49-8653-cba0-61fa89aab0ee@oracle.com> <6CFC7D01-E12B-4DC6-9E30-33B4CB89059F@gmail.com> <6D4BA3E6-0A48-4F43-B62D-63F8D356F27A@gmail.com> Message-ID: <30762465-0ee4-0982-a742-1e0554ff8539@oracle.com> On 21/09/2021 20:49, Scott Palmer wrote: > : > > > The agent is needed in my real app only to get an instance of the Instrumentation interface. As a general point, the Instrumentation object should never be leaked to applications or libraries. I have no idea what the agent does here but you should be able to this applications without the java.instrument module in the runtime image. -Alan From chegar at openjdk.java.net Wed Sep 22 07:54:01 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Wed, 22 Sep 2021 07:54:01 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v5] In-Reply-To: <4uCMVxnjarwTD6D9ngFv-pGAf6NjwGPddh7I4_sayCQ=.102746de-2a11-4aa7-82dc-601a6f228671@github.com> References: <4uCMVxnjarwTD6D9ngFv-pGAf6NjwGPddh7I4_sayCQ=.102746de-2a11-4aa7-82dc-601a6f228671@github.com> Message-ID: On Tue, 21 Sep 2021 14:09:54 GMT, Julia Boes wrote: >> This change implements a simple web server that can be run on the command-line with `java -m jdk.httpserver`. >> >> This is facilitated by adding an entry point for the `jdk.httpserver` module, an implementation class whose main method is run when the above command is executed. This is the first such module entry point in the JDK. >> >> The server is a minimal HTTP server that serves the static files of a given directory, similar to existing alternatives on other platforms and convenient for testing, development, and debugging. >> >> Additionally, a small API is introduced for programmatic creation and customization. >> >> Testing: tier1-3. > > Julia Boes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Merge branch 'master' into simpleserver > - Merge remote-tracking branch 'origin/simpleserver' into simpleserver > - Merge branch 'master' into simpleserver > - refactor isHidden,isReadable,isSymlink checks and cleanup tests > - Merge branch 'master' into simpleserver > - check isHidden, isSymlink, isReadable for all path segments > - add checks for all path segments > - Merge branch 'master' into componentcheck > - Merge branch 'master' into simpleserver > - improve output on startup > - ... and 6 more: https://git.openjdk.java.net/jdk/compare/6d91a3eb...fe059131 Overall, this is a very nice addition. Good work. ------------- Marked as reviewed by chegar (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5505 From github.com+10835776+stsypanov at openjdk.java.net Wed Sep 22 08:45:01 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Wed, 22 Sep 2021 08:45:01 GMT Subject: RFR: 8273656: Improve java.lang.invoke.MethodType.parameterList() and its usage In-Reply-To: References: Message-ID: On Wed, 22 Sep 2021 00:21:01 GMT, Claes Redestad wrote: >> Currently the method is implemented like >> >> public List> parameterList() { >> return Collections.unmodifiableList(Arrays.asList(ptypes.clone())); >> } >> >> This seems to be excessive, as three objects are allocated here. Instead we can use `List.of(ptypes)` which doesn't allocate anything for empty array and for one of length 1 and 2 it allocates lightweight objects with 2 fields, still copying longer arrays. This is likely to be fruitful as most of methods have 0-2 parameters. >> >> Also there is a couple of cases when `MethodType.parameterLis()` is called to get its size, which is excessive either as we can use `MethodType.parameterCount()` instead. > > This change introduces a subtle behavior change in that `List.of` produce a `null`-hostile list, for example `list.contains(null)` will throw NPE. Does this need to be spelled out? (FTR I think such null-hostile behavior should be reconsidered) @cl4es null-issue was the one I was afraid most of all in this case. I think that the initial array `ptypes` never contains null elements due to it's business meaning (we cannot have a param without type). Also we do explicit null-check in `checkPtypes()` method, called from `makeImpl()`. ------------- PR: https://git.openjdk.java.net/jdk/pull/5489 From jboes at openjdk.java.net Wed Sep 22 08:48:00 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Wed, 22 Sep 2021 08:48:00 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v5] In-Reply-To: References: <4uCMVxnjarwTD6D9ngFv-pGAf6NjwGPddh7I4_sayCQ=.102746de-2a11-4aa7-82dc-601a6f228671@github.com> Message-ID: On Tue, 21 Sep 2021 15:23:33 GMT, Michael McMahon wrote: >> Julia Boes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: >> >> - Merge branch 'master' into simpleserver >> - Merge remote-tracking branch 'origin/simpleserver' into simpleserver >> - Merge branch 'master' into simpleserver >> - refactor isHidden,isReadable,isSymlink checks and cleanup tests >> - Merge branch 'master' into simpleserver >> - check isHidden, isSymlink, isReadable for all path segments >> - add checks for all path segments >> - Merge branch 'master' into componentcheck >> - Merge branch 'master' into simpleserver >> - improve output on startup >> - ... and 6 more: https://git.openjdk.java.net/jdk/compare/6d91a3eb...fe059131 > > test/jdk/com/sun/net/httpserver/FilterTest.java line 330: > >> 328: var response = client.send(request, HttpResponse.BodyHandlers.ofString()); >> 329: assertEquals(response.statusCode(), 200); >> 330: assertEquals(inspectedURI.get(), URI.create("/")); > > Could you make the request URI something like /foo/bar instead of just / here? Yes, I'll do that. ------------- PR: https://git.openjdk.java.net/jdk/pull/5505 From jboes at openjdk.java.net Wed Sep 22 08:56:03 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Wed, 22 Sep 2021 08:56:03 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v5] In-Reply-To: References: <4uCMVxnjarwTD6D9ngFv-pGAf6NjwGPddh7I4_sayCQ=.102746de-2a11-4aa7-82dc-601a6f228671@github.com> Message-ID: On Tue, 21 Sep 2021 16:04:21 GMT, Daniel Fuchs wrote: >> Julia Boes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: >> >> - Merge branch 'master' into simpleserver >> - Merge remote-tracking branch 'origin/simpleserver' into simpleserver >> - Merge branch 'master' into simpleserver >> - refactor isHidden,isReadable,isSymlink checks and cleanup tests >> - Merge branch 'master' into simpleserver >> - check isHidden, isSymlink, isReadable for all path segments >> - add checks for all path segments >> - Merge branch 'master' into componentcheck >> - Merge branch 'master' into simpleserver >> - improve output on startup >> - ... and 6 more: https://git.openjdk.java.net/jdk/compare/6d91a3eb...fe059131 > > src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/FileServerHandler.java line 314: > >> 312: + "
      \n"); >> 313: try (var paths = Files.list(path)) { >> 314: paths.filter(p -> !isHiddenOrSymLink(p)) > > Shouldn't we filter paths that are not readable here too? There's no point in printing a link that will result in 404, is there? Totally, thanks for noting! ------------- PR: https://git.openjdk.java.net/jdk/pull/5505 From alanb at openjdk.java.net Wed Sep 22 09:50:02 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 22 Sep 2021 09:50:02 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v21] In-Reply-To: References: Message-ID: On Sat, 18 Sep 2021 03:52:17 GMT, Jaikiran Pai wrote: >> The commit in this PR implements the proposal for enhancement that was discussed in the core-libs-dev mailing list recently[1], for https://bugs.openjdk.java.net/browse/JDK-8231640 >> >> At a high level - the `store()` APIs in `Properties` have been modified to now look for the `SOURCE_DATE_EPOCH` environment variable[2]. If that env variable is set, then instead of writing out the current date time as a date comment, the `store()` APIs instead will use the value set for this env variable to parse it to a `Date` and write out the string form of such a date. The implementation here uses the `d MMM yyyy HH:mm:ss 'GMT'` date format and `Locale.ROOT` to format and write out such a date. This should provide reproducibility whenever the `SOURCE_DATE_EPOCH` is set. Furthermore, intentionally, no changes in the date format of the "current date" have been done. >> >> These modified `store()` APIs work in the presence of the `SecurityManager` too. The caller is expected to have a read permission on the `SOURCE_DATE_EPOCH` environment variable. If the caller doesn't have that permission, then the implementation of these `store()` APIs will write out the "current date" and will ignore any value that has been set for the `SOURCE_DATE_EPOCH` env variable. This should allow for backward compatibility of existing applications, where, when they run under a `SecurityManager` and perhaps with an existing restrictive policy file, the presence of `SOURCE_DATE_EPOCH` shouldn't impact their calls to the `store()` APIs. >> >> The modified `store()` APIs will also ignore any value for `SOURCE_DATE_EPOCH` that cannot be parsed to an `long` value. In such cases, the `store()` APIs will write out the "current date" and ignore the value set for this environment variable. No exceptions will be thrown for such invalid values. This is an additional backward compatibility precaution to prevent any rogue value for `SOURCE_DATE_EPOCH` from breaking applications. >> >> An additional change in the implementation of these `store()` APIs and unrelated to the date comment, is that these APIs will now write out the property keys in a deterministic order. The keys will be written out in the natural ordering as specified by `java.lang.String#compareTo()` API. >> >> The combination of the ordering of the property keys when written out and the usage of `SOURCE_DATE_EPOCH` environment value to determine the date comment should together allow for reproducibility of the output generated by these `store()` APIs. >> >> New jtreg test classes have been introduced to verify these changes. The primary focus of `PropertiesStoreTest` is the ordering aspects of the property keys that are written out. On the other hand `StoreReproducibilityTest` focuses on the reproducibility of the output generated by these APIs. The `StoreReproducibilityTest` runs these tests both in the presence and absence of `SecurityManager`. Plus, in the presence of SecurityManager, it tests both the scenarios where the caller is granted the requisite permission and in other case not granted that permission. >> >> These new tests and existing tests under `test/jdk/java/util/Properties/` pass with these changes. >> >> [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-August/080758.html >> [2] https://reproducible-builds.org/specs/source-date-epoch/ > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Roger's suggestion to reword the implSpec text src/java.base/share/classes/java/util/Properties.java line 928: > 926: // in the natural order of their key. Else, we consider that the subclassed implementation may potentially > 927: // have returned a differently ordered entries and so we just use the iteration order of the returned instance. > 928: if (entries instanceof Collections.SynchronizedSet ss Would it be possible to re-format the comment to keep the lines a bit inconsistent, it's just a bit annoying to have overly long lines just here. ------------- PR: https://git.openjdk.java.net/jdk/pull/5372 From alanb at openjdk.java.net Wed Sep 22 10:08:05 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 22 Sep 2021 10:08:05 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v21] In-Reply-To: References: Message-ID: On Sat, 18 Sep 2021 03:52:17 GMT, Jaikiran Pai wrote: >> The commit in this PR implements the proposal for enhancement that was discussed in the core-libs-dev mailing list recently[1], for https://bugs.openjdk.java.net/browse/JDK-8231640 >> >> At a high level - the `store()` APIs in `Properties` have been modified to now look for the `SOURCE_DATE_EPOCH` environment variable[2]. If that env variable is set, then instead of writing out the current date time as a date comment, the `store()` APIs instead will use the value set for this env variable to parse it to a `Date` and write out the string form of such a date. The implementation here uses the `d MMM yyyy HH:mm:ss 'GMT'` date format and `Locale.ROOT` to format and write out such a date. This should provide reproducibility whenever the `SOURCE_DATE_EPOCH` is set. Furthermore, intentionally, no changes in the date format of the "current date" have been done. >> >> These modified `store()` APIs work in the presence of the `SecurityManager` too. The caller is expected to have a read permission on the `SOURCE_DATE_EPOCH` environment variable. If the caller doesn't have that permission, then the implementation of these `store()` APIs will write out the "current date" and will ignore any value that has been set for the `SOURCE_DATE_EPOCH` env variable. This should allow for backward compatibility of existing applications, where, when they run under a `SecurityManager` and perhaps with an existing restrictive policy file, the presence of `SOURCE_DATE_EPOCH` shouldn't impact their calls to the `store()` APIs. >> >> The modified `store()` APIs will also ignore any value for `SOURCE_DATE_EPOCH` that cannot be parsed to an `long` value. In such cases, the `store()` APIs will write out the "current date" and ignore the value set for this environment variable. No exceptions will be thrown for such invalid values. This is an additional backward compatibility precaution to prevent any rogue value for `SOURCE_DATE_EPOCH` from breaking applications. >> >> An additional change in the implementation of these `store()` APIs and unrelated to the date comment, is that these APIs will now write out the property keys in a deterministic order. The keys will be written out in the natural ordering as specified by `java.lang.String#compareTo()` API. >> >> The combination of the ordering of the property keys when written out and the usage of `SOURCE_DATE_EPOCH` environment value to determine the date comment should together allow for reproducibility of the output generated by these `store()` APIs. >> >> New jtreg test classes have been introduced to verify these changes. The primary focus of `PropertiesStoreTest` is the ordering aspects of the property keys that are written out. On the other hand `StoreReproducibilityTest` focuses on the reproducibility of the output generated by these APIs. The `StoreReproducibilityTest` runs these tests both in the presence and absence of `SecurityManager`. Plus, in the presence of SecurityManager, it tests both the scenarios where the caller is granted the requisite permission and in other case not granted that permission. >> >> These new tests and existing tests under `test/jdk/java/util/Properties/` pass with these changes. >> >> [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-August/080758.html >> [2] https://reproducible-builds.org/specs/source-date-epoch/ > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Roger's suggestion to reword the implSpec text src/java.base/share/classes/java/lang/System.java line 766: > 764: * {@systemProperty java.properties.date} > 765: * Text for the comment that must replace the default date comment > 766: * written out by {@code Properties.store()} methods (optional) To date, the table in getProperties has listed the supported system properties that the runtime makes available to applications. It hasn't historically listed the many other standard properties that can be set on the command line. So I'm sure about adding this one to the table as it opens the door to expanding the table to all the other system properties that are documented elsewhere in the API docs. Note that javadoc creates a table of system properties from usages of `@systemProperty` so there is already a more complete table in the javadoc build. ------------- PR: https://git.openjdk.java.net/jdk/pull/5372 From prappo at openjdk.java.net Wed Sep 22 10:27:09 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Wed, 22 Sep 2021 10:27:09 GMT Subject: RFR: 8274075: Fix miscellaneous typos in java.base [v2] In-Reply-To: References: <27dIhnD8Wc7kQcxq45Np2Lo68AhZvSgmmoV67fgL8rs=.9d8115bf-5176-4de5-99d8-963dc0d12c8f@github.com> <4_RdSmkMBlUHObLQDGcNhQRytTUvqTjXaqDBsI-awb0=.c387c56b-3724-4271-8293-4db417d6545f@github.com> Message-ID: On Tue, 21 Sep 2021 22:00:29 GMT, David Holmes wrote: >> Instead of "common case where a wrapped exception is thrown from same method" could one write "common case where an enclosing exception is thrown from the same method"? > > Note that we don't throw the "wrapped exception" we throw the exception that wraps it. The "wrapped exception" is the original cause. The wording as presented now is correct in that regard. You could also say "Throwing a wrapper exception (i.e. one that has a cause)" - I think both are grammatically correct. > > The later text "where a wrapped exception is thrown from the same method" is again incorrect because the wrapped exception (the cause) is not what gets thrown. But I find that whole sentence rather jarring anyway - I'm not certain exactly what it means. I'm inclined to revert this change on Throwable.java:68, because of the lack of consensus. It clearly is not a simple typo. ------------- PR: https://git.openjdk.java.net/jdk/pull/5610 From jpai at openjdk.java.net Wed Sep 22 10:27:45 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Wed, 22 Sep 2021 10:27:45 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v22] In-Reply-To: References: Message-ID: > The commit in this PR implements the proposal for enhancement that was discussed in the core-libs-dev mailing list recently[1], for https://bugs.openjdk.java.net/browse/JDK-8231640 > > At a high level - the `store()` APIs in `Properties` have been modified to now look for the `SOURCE_DATE_EPOCH` environment variable[2]. If that env variable is set, then instead of writing out the current date time as a date comment, the `store()` APIs instead will use the value set for this env variable to parse it to a `Date` and write out the string form of such a date. The implementation here uses the `d MMM yyyy HH:mm:ss 'GMT'` date format and `Locale.ROOT` to format and write out such a date. This should provide reproducibility whenever the `SOURCE_DATE_EPOCH` is set. Furthermore, intentionally, no changes in the date format of the "current date" have been done. > > These modified `store()` APIs work in the presence of the `SecurityManager` too. The caller is expected to have a read permission on the `SOURCE_DATE_EPOCH` environment variable. If the caller doesn't have that permission, then the implementation of these `store()` APIs will write out the "current date" and will ignore any value that has been set for the `SOURCE_DATE_EPOCH` env variable. This should allow for backward compatibility of existing applications, where, when they run under a `SecurityManager` and perhaps with an existing restrictive policy file, the presence of `SOURCE_DATE_EPOCH` shouldn't impact their calls to the `store()` APIs. > > The modified `store()` APIs will also ignore any value for `SOURCE_DATE_EPOCH` that cannot be parsed to an `long` value. In such cases, the `store()` APIs will write out the "current date" and ignore the value set for this environment variable. No exceptions will be thrown for such invalid values. This is an additional backward compatibility precaution to prevent any rogue value for `SOURCE_DATE_EPOCH` from breaking applications. > > An additional change in the implementation of these `store()` APIs and unrelated to the date comment, is that these APIs will now write out the property keys in a deterministic order. The keys will be written out in the natural ordering as specified by `java.lang.String#compareTo()` API. > > The combination of the ordering of the property keys when written out and the usage of `SOURCE_DATE_EPOCH` environment value to determine the date comment should together allow for reproducibility of the output generated by these `store()` APIs. > > New jtreg test classes have been introduced to verify these changes. The primary focus of `PropertiesStoreTest` is the ordering aspects of the property keys that are written out. On the other hand `StoreReproducibilityTest` focuses on the reproducibility of the output generated by these APIs. The `StoreReproducibilityTest` runs these tests both in the presence and absence of `SecurityManager`. Plus, in the presence of SecurityManager, it tests both the scenarios where the caller is granted the requisite permission and in other case not granted that permission. > > These new tests and existing tests under `test/jdk/java/util/Properties/` pass with these changes. > > [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-August/080758.html > [2] https://reproducible-builds.org/specs/source-date-epoch/ Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision: - Revert "Implement Mark's suggestion in CSR to include the java.properties.date in the list of system properties listed in System::getProperties()" Additional inputs since this specific commit was introduced have leaned towards not listing this property in System::getProperties() This reverts commit 458c1fd37cf1e8e8bd0a60a171d173ce5da12b7c. - reduce the line length of code comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5372/files - new: https://git.openjdk.java.net/jdk/pull/5372/files/e350721a..944cbf1e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5372&range=21 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5372&range=20-21 Stats: 9 lines in 2 files changed: 2 ins; 3 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/5372.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5372/head:pull/5372 PR: https://git.openjdk.java.net/jdk/pull/5372 From jpai at openjdk.java.net Wed Sep 22 10:27:49 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Wed, 22 Sep 2021 10:27:49 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v21] In-Reply-To: References: Message-ID: On Wed, 22 Sep 2021 10:05:04 GMT, Alan Bateman wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> Roger's suggestion to reword the implSpec text > > src/java.base/share/classes/java/lang/System.java line 766: > >> 764: * {@systemProperty java.properties.date} >> 765: * Text for the comment that must replace the default date comment >> 766: * written out by {@code Properties.store()} methods (optional) > > To date, the table in getProperties has listed the supported system properties that the runtime makes available to applications. It hasn't historically listed the many other standard properties that can be set on the command line. So I'm sure about adding this one to the table as it opens the door to expanding the table to all the other system properties that are documented elsewhere in the API docs. Note that javadoc creates a table of system properties from usages of `@systemProperty` so there is already a more complete table in the javadoc build. After this change to include this property in System::getProperties() javadoc was added, there have been inputs (here and on the CSR) which suggest that we probably shouldn't include it here. I've now updated this PR to revert this specific change. > src/java.base/share/classes/java/util/Properties.java line 928: > >> 926: // in the natural order of their key. Else, we consider that the subclassed implementation may potentially >> 927: // have returned a differently ordered entries and so we just use the iteration order of the returned instance. >> 928: if (entries instanceof Collections.SynchronizedSet ss > > Would you mind re-formatting the comment to keep the line length a bit more consistent with the rest of the code, is's just a bit annoying to have it wrapping. Done. I've updated the PR to reduce the line length of that code comment. ------------- PR: https://git.openjdk.java.net/jdk/pull/5372 From andy.herrick at oracle.com Wed Sep 22 11:21:04 2021 From: andy.herrick at oracle.com (Andy Herrick) Date: Wed, 22 Sep 2021 07:21:04 -0400 Subject: [External] : Re: What causes java.lang.InternalError: platform encoding not initialized ? In-Reply-To: References: <3193c4a3-cb49-8653-cba0-61fa89aab0ee@oracle.com> <6CFC7D01-E12B-4DC6-9E30-33B4CB89059F@gmail.com> <6D4BA3E6-0A48-4F43-B62D-63F8D356F27A@gmail.com> Message-ID: <69d21f19-4b69-ebf2-e0ed-a296c938c396@oracle.com> Thanks Scott This will help a lot because I couldn't reproduce this using just a splash screen as I expected I could. I will look at this example this morning. /Andy On 9/21/21 7:05 PM, Scott Palmer wrote: > I?ve uploaded a project that reproduces the problem to JDK-8274087 > > > Regards, > > Scott > >> On Sep 21, 2021, at 3:49 PM, Scott Palmer > > wrote: >> >> I have discovered that I have to have my Java Agent configured ?in >> the .cfg file for it to happen: >> >> [JavaOptions] >> java-option=-javaagent:$APPDIR\libs\MyAgent.jar >> >> >> The agent is needed in my real app only to get an instance of the >> Instrumentation interface. In my test code, where I have reproduced >> this, it is never used. ?My test app just takes a URL and fetches it >> via a HttpURLConnection with setInstanceFollowRedirects(false) so I >> can capture the new location. ?If you are still having trouble >> reproducing I will have the code cleaned up for the bug report soon... >> >> >> Regards, >> >> Scott >> >> >> >>> On Sep 21, 2021, at 12:12 PM, Andy Herrick >> > wrote: >>> >>> I thought I could create a reproduction scenario by using an app >>> with "-splash:" arg then moving the jre as you did, but >>> I have not yet been able make it fail. >>> >>> /Andy >>> >>> On 9/21/2021 11:43 AM, Scott Palmer wrote: >>>>> On Sep 21, 2021, at 11:40 AM, Alan Bateman >>>>> > wrote: >>>>> >>>>> ?On 21/09/2021 15:54, Andy Herrick wrote: >>>>>> I found the problem in >>>>>> open/src/jdk.jpackage/windows/native/applauncher/WinLauncher.cpp >>>>>> >>>>>> we call SetDllDirectory() with the path to the bin dir in the >>>>>> default runtime directory, not the actual runtime directory. >>>>>> >>>>>> since on Windows we never use other than the default runtime >>>>>> location - we had not seen a problem, but is bug I will file and fix. >>>>>> >>>>> Good to see that you found it quickly. However I'm puzzled as why >>>>> initializingEncoding wasn't called, I would have expected the VM >>>>> to blow up during early startup. Would you have cycles to dig into >>>>> that a bit more in case something has been masked, like for >>>>> example an exception being swallowed. ?Running with >>>>> -Xlog:exceptions might reveal something. >>>> >>>> Do you have a case that reproduces the issue? >>>> >>>> Scott >> > From jvernee at openjdk.java.net Wed Sep 22 11:52:54 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 22 Sep 2021 11:52:54 GMT Subject: RFR: 8273656: Improve java.lang.invoke.MethodType.parameterList() and its usage In-Reply-To: References: Message-ID: On Mon, 13 Sep 2021 11:06:15 GMT, ?????? ??????? wrote: > Currently the method is implemented like > > public List> parameterList() { > return Collections.unmodifiableList(Arrays.asList(ptypes.clone())); > } > > This seems to be excessive, as three objects are allocated here. Instead we can use `List.of(ptypes)` which doesn't allocate anything for empty array and for one of length 1 and 2 it allocates lightweight objects with 2 fields, still copying longer arrays. This is likely to be fruitful as most of methods have 0-2 parameters. > > Also there is a couple of cases when `MethodType.parameterLis()` is called to get its size, which is excessive either as we can use `MethodType.parameterCount()` instead. > Mailing list message from John Rose on core-libs-dev: > > On Sep 13, 2021, at 10:24 AM, Vladimir Ivanov > wrote: > > BTW it can be improved even further by caching the immutable List view of parameters. > > I would go further: If I were writing MethodType.java today > I would probably use List.of as the backing store for the > parameters, instead of the private array. So ptypes should > be List> not Class[]. I don?t think the footprint > or polymorphism effects would be dealbreakers, and the > code would (I think) be simpler overall. But that?s a messy > change, since the array representation is dug in. Another thing that makes this change hard is that `MethodType` is mapped directly in HotSpot, so that HotSpot can retrieve for instance the parameter types [1]. The VM already knows how to dig into arrays, but adding support for `List` as well seems more cumbersome, since the list internals can change, and AFAIK most VM code can not just call `List::get`. [1] : https://github.com/openjdk/jdk/blob/master/src/hotspot/share/classfile/javaClasses.cpp#L4135-L4137 ------------- PR: https://git.openjdk.java.net/jdk/pull/5489 From jboes at openjdk.java.net Wed Sep 22 12:45:04 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Wed, 22 Sep 2021 12:45:04 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v5] In-Reply-To: References: <4uCMVxnjarwTD6D9ngFv-pGAf6NjwGPddh7I4_sayCQ=.102746de-2a11-4aa7-82dc-601a6f228671@github.com> Message-ID: <6rqQ4-pJmwjC4k6Xc5vTlmiECH4BdwHXKekK7TVuGbM=.120a5267-b35d-4b61-9428-ad1fc3db1773@github.com> On Tue, 21 Sep 2021 17:16:08 GMT, Michael McMahon wrote: >> Julia Boes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: >> >> - Merge branch 'master' into simpleserver >> - Merge remote-tracking branch 'origin/simpleserver' into simpleserver >> - Merge branch 'master' into simpleserver >> - refactor isHidden,isReadable,isSymlink checks and cleanup tests >> - Merge branch 'master' into simpleserver >> - check isHidden, isSymlink, isReadable for all path segments >> - add checks for all path segments >> - Merge branch 'master' into componentcheck >> - Merge branch 'master' into simpleserver >> - improve output on startup >> - ... and 6 more: https://git.openjdk.java.net/jdk/compare/6d91a3eb...fe059131 > > src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/SimpleFileServerImpl.java line 135: > >> 133: var socketAddr = new InetSocketAddress(addr, port); >> 134: var server = SimpleFileServer.createFileServer(socketAddr, root, outputLevel); >> 135: server.setExecutor(Executors.newSingleThreadExecutor()); > > I think this code has the effect of creating one thread for the selector and a second one for the execution of the handlers. If we want to keep thread usage to an absolute minimum then it might be better to not set an executor. Then, the selector thread executes the handlers as well. I did a quick stress test of both versions (with and without executor specified) and don?t see any difference in how many requests can be handled. Probably good to keep thread usage to a minimum, I'll update that. ------------- PR: https://git.openjdk.java.net/jdk/pull/5505 From prappo at openjdk.java.net Wed Sep 22 13:01:37 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Wed, 22 Sep 2021 13:01:37 GMT Subject: RFR: 8274075: Fix miscellaneous typos in java.base [v2] In-Reply-To: References: <27dIhnD8Wc7kQcxq45Np2Lo68AhZvSgmmoV67fgL8rs=.9d8115bf-5176-4de5-99d8-963dc0d12c8f@github.com> Message-ID: On Tue, 21 Sep 2021 13:16:02 GMT, Pavel Rappo wrote: >> 8274075: Fix miscellaneous typos in java.base > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Tweak wording for Throwable constructor parameters Please re-review this change since I've added two commits. ------------- PR: https://git.openjdk.java.net/jdk/pull/5610 From prappo at openjdk.java.net Wed Sep 22 13:01:34 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Wed, 22 Sep 2021 13:01:34 GMT Subject: RFR: 8274075: Fix miscellaneous typos in java.base [v3] In-Reply-To: <27dIhnD8Wc7kQcxq45Np2Lo68AhZvSgmmoV67fgL8rs=.9d8115bf-5176-4de5-99d8-963dc0d12c8f@github.com> References: <27dIhnD8Wc7kQcxq45Np2Lo68AhZvSgmmoV67fgL8rs=.9d8115bf-5176-4de5-99d8-963dc0d12c8f@github.com> Message-ID: > 8274075: Fix miscellaneous typos in java.base Pavel Rappo has updated the pull request incrementally with two additional commits since the last revision: - Fix "non-white space" JDK predominantly uses "non-whitespace". There's only one more use of "non-white space", in com/sun/tools/javac/tree/DocTreeMaker.java:716, which will go away soon. - Undo "wrapped" -> "wrapping" ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5610/files - new: https://git.openjdk.java.net/jdk/pull/5610/files/19b6f496..05505d97 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5610&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5610&range=01-02 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5610.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5610/head:pull/5610 PR: https://git.openjdk.java.net/jdk/pull/5610 From prappo at openjdk.java.net Wed Sep 22 13:01:39 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Wed, 22 Sep 2021 13:01:39 GMT Subject: RFR: 8274075: Fix miscellaneous typos in java.base [v2] In-Reply-To: References: <27dIhnD8Wc7kQcxq45Np2Lo68AhZvSgmmoV67fgL8rs=.9d8115bf-5176-4de5-99d8-963dc0d12c8f@github.com> <4_RdSmkMBlUHObLQDGcNhQRytTUvqTjXaqDBsI-awb0=.c387c56b-3724-4271-8293-4db417d6545f@github.com> Message-ID: On Wed, 22 Sep 2021 10:24:12 GMT, Pavel Rappo wrote: >> Note that we don't throw the "wrapped exception" we throw the exception that wraps it. The "wrapped exception" is the original cause. The wording as presented now is correct in that regard. You could also say "Throwing a wrapper exception (i.e. one that has a cause)" - I think both are grammatically correct. >> >> The later text "where a wrapped exception is thrown from the same method" is again incorrect because the wrapped exception (the cause) is not what gets thrown. But I find that whole sentence rather jarring anyway - I'm not certain exactly what it means. > > I'm inclined to revert this change on Throwable.java:68, because of the lack of consensus. It clearly is not a simple typo. Reverted in 57b71c5. ------------- PR: https://git.openjdk.java.net/jdk/pull/5610 From lancea at openjdk.java.net Wed Sep 22 13:09:54 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 22 Sep 2021 13:09:54 GMT Subject: RFR: 8274075: Fix miscellaneous typos in java.base [v3] In-Reply-To: References: <27dIhnD8Wc7kQcxq45Np2Lo68AhZvSgmmoV67fgL8rs=.9d8115bf-5176-4de5-99d8-963dc0d12c8f@github.com> Message-ID: On Wed, 22 Sep 2021 13:01:34 GMT, Pavel Rappo wrote: >> 8274075: Fix miscellaneous typos in java.base > > Pavel Rappo has updated the pull request incrementally with two additional commits since the last revision: > > - Fix "non-white space" > > JDK predominantly uses "non-whitespace". There's only one more use of "non-white space", in com/sun/tools/javac/tree/DocTreeMaker.java:716, which will go away soon. > - Undo "wrapped" -> "wrapping" Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5610 From redestad at openjdk.java.net Wed Sep 22 13:17:59 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 22 Sep 2021 13:17:59 GMT Subject: RFR: 8273656: Improve java.lang.invoke.MethodType.parameterList() and its usage In-Reply-To: References: Message-ID: On Wed, 22 Sep 2021 00:21:01 GMT, Claes Redestad wrote: >> Currently the method is implemented like >> >> public List> parameterList() { >> return Collections.unmodifiableList(Arrays.asList(ptypes.clone())); >> } >> >> This seems to be excessive, as three objects are allocated here. Instead we can use `List.of(ptypes)` which doesn't allocate anything for empty array and for one of length 1 and 2 it allocates lightweight objects with 2 fields, still copying longer arrays. This is likely to be fruitful as most of methods have 0-2 parameters. >> >> Also there is a couple of cases when `MethodType.parameterLis()` is called to get its size, which is excessive either as we can use `MethodType.parameterCount()` instead. > > This change introduces a subtle behavior change in that `List.of` produce a `null`-hostile list, for example `list.contains(null)` will throw NPE. Does this need to be spelled out? (FTR I think such null-hostile behavior should be reconsidered) > @cl4es null-issue was the one I was afraid most of all in this case. I think that the initial array `ptypes` never contains null elements due to it's business meaning (we cannot have a param without type). Also we do explicit null-check in `checkPtypes()` method, called from `makeImpl()`. No, on the producer side there's no issue since a parameter type can't be `null`. The compatibility issue I have in mind is only the (very minor) issue that the returned list would now throw NPE if you call `mt.parameterList().contains(null)` where it before would just return `false`. I don't think this is a real issue, but the subtle behavior change might warrant a CSR to document the stricter behavior. ------------- PR: https://git.openjdk.java.net/jdk/pull/5489 From prappo at openjdk.java.net Wed Sep 22 13:46:02 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Wed, 22 Sep 2021 13:46:02 GMT Subject: Integrated: 8274071: Clean up java.lang.ref comments and documentation In-Reply-To: References: Message-ID: On Tue, 21 Sep 2021 12:05:27 GMT, Pavel Rappo wrote: > This PR fixes an inline comment typo and reduces "overlinking" in a doc comment in `java.lang.ref.Reference`. Overlinking happens because the `reachabilityFence` method: > * Links `package-summary.html#reachability` twice. > * Refers to JLS 12.6 twice: once from a block tag and once from an inline tag. This pull request has now been integrated. Changeset: c6df3c95 Author: Pavel Rappo URL: https://git.openjdk.java.net/jdk/commit/c6df3c9571cfa9607f3deffeaa77701dde9fea15 Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod 8274071: Clean up java.lang.ref comments and documentation Reviewed-by: rriggs, kbarrett, mchung, iris, lancea ------------- PR: https://git.openjdk.java.net/jdk/pull/5609 From andy.herrick at oracle.com Wed Sep 22 13:54:20 2021 From: andy.herrick at oracle.com (Andy Herrick) Date: Wed, 22 Sep 2021 09:54:20 -0400 Subject: [External] : Re: What causes java.lang.InternalError: platform encoding not initialized ? In-Reply-To: References: <3193c4a3-cb49-8653-cba0-61fa89aab0ee@oracle.com> <6CFC7D01-E12B-4DC6-9E30-33B4CB89059F@gmail.com> Message-ID: <6e253a70-c961-a37d-b415-212f65734d2a@oracle.com> I can't seem to get your testcase to work with the Oracle JDK configured. I can build, but then when I run $ ./build/application/FetchURL/FetchURL.exe I get: > *** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" > with message c > an't find transform methodID at JPLISAgent.c line: 552 > *** java.lang.instrument ASSERTION FAILED ***: "result" at > JPLISAgent.c line: 400 > > FATAL ERROR in native method: processing of -javaagent failed same behavior if I restore "runtime" directory and fix FetchURL.cfg to remove app.runtime entry. anyway I used your two source files to build the test app without gradle, and the test can download https://linear-89.frequency.stream/dist/localnow/89/hls/master/playlist.m3u8 without any problems. I then moved runtime to jre and added line "app.runtime=$APPDIR/../jre" to cfg file and app still ran fine (downloaded the above) So I still don't have any way to reproduce this problemwith the Oracle jdk. /Andy PS: Although something somewhere else may have changed to counter the problem, it's clear from your description, that since the only place in the code the default runtime path is used (instead of the actual runtime path, which may be different) is the line in WinLauncher.cpp to call SetDllDirectory(). This should be fixed - but would like a way to reproduce the problem it causes first. /Andy On 9/21/2021 12:12 PM, Andy Herrick wrote: > I thought I could create a reproduction scenario by using an app with > "-splash:" arg then moving the jre as you did, but I have > not yet been able make it fail. > > /Andy > > On 9/21/2021 11:43 AM, Scott Palmer wrote: >>> On Sep 21, 2021, at 11:40 AM, Alan Bateman >>> wrote: >>> >>> ?On 21/09/2021 15:54, Andy Herrick wrote: >>>> I found the problem in >>>> open/src/jdk.jpackage/windows/native/applauncher/WinLauncher.cpp >>>> >>>> we call SetDllDirectory() with the path to the bin dir in the >>>> default runtime directory, not the actual runtime directory. >>>> >>>> since on Windows we never use other than the default runtime >>>> location - we had not seen a problem, but is bug I will file and fix. >>>> >>> Good to see that you found it quickly. However I'm puzzled as why >>> initializingEncoding wasn't called, I would have expected the VM to >>> blow up during early startup. Would you have cycles to dig into that >>> a bit more in case something has been masked, like for example an >>> exception being swallowed.? Running with -Xlog:exceptions might >>> reveal something. >> >> Do you have a case that reproduces the issue? >> >> Scott From rriggs at openjdk.java.net Wed Sep 22 13:58:07 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 22 Sep 2021 13:58:07 GMT Subject: RFR: 8272600: (test) Use native "sleep" in Basic.java [v6] In-Reply-To: References: <1-B9MAOZK5XtDuFdxsWh3SgFnCk2MRdK-zbBcys1PbU=.1df445ba-dbaa-4480-a7ac-35dd79a7f920@github.com> Message-ID: On Wed, 22 Sep 2021 00:03:41 GMT, David Holmes wrote: >> I thought of that too, but notice the parens "()" around that /bin/sleep; that creates and extra level of forked processes and its harder to get that pid. There probably is a way to traverse the hierarchy but I'll keep it as is for now. > > Ah right. Begs the question why we need to use bash to execute sleep? Could it be shell script instead of a binary? I think that's the author's prerogative; the test was written in 2010 to test conditions related to deeply inherited file descriptors. ------------- PR: https://git.openjdk.java.net/jdk/pull/5239 From rriggs at openjdk.java.net Wed Sep 22 13:58:10 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 22 Sep 2021 13:58:10 GMT Subject: Integrated: 8272600: (test) Use native "sleep" in Basic.java In-Reply-To: References: Message-ID: On Tue, 24 Aug 2021 15:55:28 GMT, Roger Riggs wrote: > The intermittent test in java/lang/ProcessBuilder/Basic.java has identified unexpected messages from a child Java VM > as the cause of the test failure. Attempts to control the output of the child VM have failed, the VM is unrepentant . > > There is no functionality in the child except to wait long enough for the test to finish and the child is destroyed. > The fix is to switch from using a Java child to using a native child; a new executable `sleepmillis`. This pull request has now been integrated. Changeset: 0a361638 Author: Roger Riggs URL: https://git.openjdk.java.net/jdk/commit/0a361638c5ea4d3e109d950e34a61b4737c8f670 Stats: 174 lines in 2 files changed: 111 ins; 35 del; 28 mod 8272600: (test) Use native "sleep" in Basic.java Reviewed-by: iklam, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/5239 From rriggs at openjdk.java.net Wed Sep 22 14:01:02 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 22 Sep 2021 14:01:02 GMT Subject: Integrated: 8274003: ProcessHandleImpl.Info toString has an if check which is always true In-Reply-To: References: Message-ID: On Tue, 21 Sep 2021 18:14:17 GMT, Roger Riggs wrote: > Correct the check if any field has been appended to the StringBuilder in ProcessHandleImpl.Info.toString(). This pull request has now been integrated. Changeset: 33df388a Author: Roger Riggs URL: https://git.openjdk.java.net/jdk/commit/33df388a24267e868574e4604b2e2ab170dc5a09 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod 8274003: ProcessHandleImpl.Info toString has an if check which is always true Reviewed-by: bpb, naoto, iris ------------- PR: https://git.openjdk.java.net/jdk/pull/5618 From swpalmer at gmail.com Wed Sep 22 14:24:04 2021 From: swpalmer at gmail.com (Scott Palmer) Date: Wed, 22 Sep 2021 10:24:04 -0400 Subject: [External] : Re: What causes java.lang.InternalError: platform encoding not initialized ? In-Reply-To: <6e253a70-c961-a37d-b415-212f65734d2a@oracle.com> References: <3193c4a3-cb49-8653-cba0-61fa89aab0ee@oracle.com> <6CFC7D01-E12B-4DC6-9E30-33B4CB89059F@gmail.com> <6e253a70-c961-a37d-b415-212f65734d2a@oracle.com> Message-ID: <86E52DB1-A0E4-43E5-AC4D-5402591116FD@gmail.com> I reproduced it with the AZUL's distribution of OpenJDK (with JavaFX modules bundled) and I just changed: vendor = JvmVendorSpec.ADOPTOPENJDK And get the same error with that build of OpenJDK as well. ?OpenJDK Runtime Environment Temurin-17+35 (build 17+35)? You can try that, as Gradle should download the JDK for you. I then downloaded the Oracle build of OpenJDK from https://jdk.java.net/17/ (build 17+35-2724) unzipped it to C:\Tools building with: gradlew -Porg.gradle.java.installations.paths=C:\Tools\jdk-17 clean build I still reproduce the error. Though the assertion in native JVM code that you are getting looks like yet another bug! So perhaps it is good that it is discovered as well. Scott > On Sep 22, 2021, at 9:54 AM, Andy Herrick wrote: > > I can't seem to get your testcase to work with the Oracle JDK configured. > > I can build, but then when I run > > $ ./build/application/FetchURL/FetchURL.exe > > I get: > >> *** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with message c >> an't find transform methodID at JPLISAgent.c line: 552 >> *** java.lang.instrument ASSERTION FAILED ***: "result" at JPLISAgent.c line: 400 >> >> FATAL ERROR in native method: processing of -javaagent failed > same behavior if I restore "runtime" directory and fix FetchURL.cfg to remove app.runtime entry. > > anyway I used your two source files to build the test app without gradle, and the test can download https://linear-89.frequency.stream/dist/localnow/89/hls/master/playlist.m3u8 without any problems. > > I then moved runtime to jre and added line "app.runtime=$APPDIR/../jre" to cfg file and app still ran fine (downloaded the above) > > So I still don't have any way to reproduce this problemwith the Oracle jdk. > > /Andy > > > PS: > > Although something somewhere else may have changed to counter the problem, it's clear from your description, that since the only place in the code the default runtime path is used (instead of the actual runtime path, which may be different) is the line in WinLauncher.cpp to call SetDllDirectory(). > > This should be fixed - but would like a way to reproduce the problem it causes first. > > /Andy > > On 9/21/2021 12:12 PM, Andy Herrick wrote: >> I thought I could create a reproduction scenario by using an app with "-splash:" arg then moving the jre as you did, but I have not yet been able make it fail. >> >> /Andy >> >> On 9/21/2021 11:43 AM, Scott Palmer wrote: >>>> On Sep 21, 2021, at 11:40 AM, Alan Bateman wrote: >>>> >>>> ?On 21/09/2021 15:54, Andy Herrick wrote: >>>>> I found the problem in open/src/jdk.jpackage/windows/native/applauncher/WinLauncher.cpp >>>>> >>>>> we call SetDllDirectory() with the path to the bin dir in the default runtime directory, not the actual runtime directory. >>>>> >>>>> since on Windows we never use other than the default runtime location - we had not seen a problem, but is bug I will file and fix. >>>>> >>>> Good to see that you found it quickly. However I'm puzzled as why initializingEncoding wasn't called, I would have expected the VM to blow up during early startup. Would you have cycles to dig into that a bit more in case something has been masked, like for example an exception being swallowed. Running with -Xlog:exceptions might reveal something. >>> >>> Do you have a case that reproduces the issue? >>> >>> Scott From swpalmer at gmail.com Wed Sep 22 14:25:48 2021 From: swpalmer at gmail.com (Scott Palmer) Date: Wed, 22 Sep 2021 10:25:48 -0400 Subject: [External] : Re: What causes java.lang.InternalError: platform encoding not initialized ? In-Reply-To: <86E52DB1-A0E4-43E5-AC4D-5402591116FD@gmail.com> References: <3193c4a3-cb49-8653-cba0-61fa89aab0ee@oracle.com> <6CFC7D01-E12B-4DC6-9E30-33B4CB89059F@gmail.com> <6e253a70-c961-a37d-b415-212f65734d2a@oracle.com> <86E52DB1-A0E4-43E5-AC4D-5402591116FD@gmail.com> Message-ID: <6D33CD2C-F0D2-4299-9711-83BB0D2123F8@gmail.com> Sorry That last build with the Oracle OpenJDK needed the build file changed to have vendor = JvmVendorSpec.ORACLE as well as the command line property pointing to the path to the jdk, Scott > On Sep 22, 2021, at 10:24 AM, Scott Palmer wrote: > > I reproduced it with the AZUL's distribution of OpenJDK (with JavaFX modules bundled) and I just changed: > > vendor = JvmVendorSpec.ADOPTOPENJDK > > And get the same error with that build of OpenJDK as well. ?OpenJDK Runtime Environment Temurin-17+35 (build 17+35)? > You can try that, as Gradle should download the JDK for you. > > I then downloaded the Oracle build of OpenJDK from https://jdk.java.net/17/ (build 17+35-2724) > unzipped it to C:\Tools > building with: > > gradlew -Porg.gradle.java.installations.paths=C:\Tools\jdk-17 clean build > > I still reproduce the error. > > Though the assertion in native JVM code that you are getting looks like yet another bug! So perhaps it is good that it is discovered as well. > > > Scott > >> On Sep 22, 2021, at 9:54 AM, Andy Herrick wrote: >> >> I can't seem to get your testcase to work with the Oracle JDK configured. >> >> I can build, but then when I run >> >> $ ./build/application/FetchURL/FetchURL.exe >> >> I get: >> >>> *** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with message c >>> an't find transform methodID at JPLISAgent.c line: 552 >>> *** java.lang.instrument ASSERTION FAILED ***: "result" at JPLISAgent.c line: 400 >>> >>> FATAL ERROR in native method: processing of -javaagent failed >> same behavior if I restore "runtime" directory and fix FetchURL.cfg to remove app.runtime entry. >> >> anyway I used your two source files to build the test app without gradle, and the test can download https://linear-89.frequency.stream/dist/localnow/89/hls/master/playlist.m3u8 without any problems. >> >> I then moved runtime to jre and added line "app.runtime=$APPDIR/../jre" to cfg file and app still ran fine (downloaded the above) >> >> So I still don't have any way to reproduce this problemwith the Oracle jdk. >> >> /Andy >> >> >> PS: >> >> Although something somewhere else may have changed to counter the problem, it's clear from your description, that since the only place in the code the default runtime path is used (instead of the actual runtime path, which may be different) is the line in WinLauncher.cpp to call SetDllDirectory(). >> >> This should be fixed - but would like a way to reproduce the problem it causes first. >> >> /Andy >> >> On 9/21/2021 12:12 PM, Andy Herrick wrote: >>> I thought I could create a reproduction scenario by using an app with "-splash:" arg then moving the jre as you did, but I have not yet been able make it fail. >>> >>> /Andy >>> >>> On 9/21/2021 11:43 AM, Scott Palmer wrote: >>>>> On Sep 21, 2021, at 11:40 AM, Alan Bateman wrote: >>>>> >>>>> ?On 21/09/2021 15:54, Andy Herrick wrote: >>>>>> I found the problem in open/src/jdk.jpackage/windows/native/applauncher/WinLauncher.cpp >>>>>> >>>>>> we call SetDllDirectory() with the path to the bin dir in the default runtime directory, not the actual runtime directory. >>>>>> >>>>>> since on Windows we never use other than the default runtime location - we had not seen a problem, but is bug I will file and fix. >>>>>> >>>>> Good to see that you found it quickly. However I'm puzzled as why initializingEncoding wasn't called, I would have expected the VM to blow up during early startup. Would you have cycles to dig into that a bit more in case something has been masked, like for example an exception being swallowed. Running with -Xlog:exceptions might reveal something. >>>> >>>> Do you have a case that reproduces the issue? >>>> >>>> Scott > From rriggs at openjdk.java.net Wed Sep 22 14:47:07 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 22 Sep 2021 14:47:07 GMT Subject: Withdrawn: 8269850: Most JDK releases report macOS version 12 as 10.16 instead of 12.0 In-Reply-To: <9tr2u5U38f-H1rNN3v69B48KsEI3MoZSWBnYgsy9vqw=.0f46fd59-da71-4d69-8da3-3569e4eb4603@github.com> References: <9tr2u5U38f-H1rNN3v69B48KsEI3MoZSWBnYgsy9vqw=.0f46fd59-da71-4d69-8da3-3569e4eb4603@github.com> Message-ID: On Tue, 21 Sep 2021 19:33:05 GMT, Roger Riggs wrote: > The Mac OS specific code to determine the os.version property in java_props_macosx.c is updated > to replace the code extracting the version from the SystemVersion.plist by reading the version using the hidden link: > `/System/Library/CoreServices/.SystemVersionPlatform.plist` > > Its contents are not dependent on the SYSTEM_VERSION_COMPAT environment variable. > With this change, 11.5 reports the 11.5.1 minor version and os.version 11.6 is correctly reported. > The change can be backported to other versions as needed. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/5619 From andy.herrick at oracle.com Wed Sep 22 15:22:57 2021 From: andy.herrick at oracle.com (Andy Herrick) Date: Wed, 22 Sep 2021 11:22:57 -0400 Subject: [External] : Re: What causes java.lang.InternalError: platform encoding not initialized ? In-Reply-To: <6D33CD2C-F0D2-4299-9711-83BB0D2123F8@gmail.com> References: <3193c4a3-cb49-8653-cba0-61fa89aab0ee@oracle.com> <6CFC7D01-E12B-4DC6-9E30-33B4CB89059F@gmail.com> <6e253a70-c961-a37d-b415-212f65734d2a@oracle.com> <86E52DB1-A0E4-43E5-AC4D-5402591116FD@gmail.com> <6D33CD2C-F0D2-4299-9711-83BB0D2123F8@gmail.com> Message-ID: I still don't get the error your report.? Is there something else that needs to be set up for using instrumentation ? I do get a different error when I have both runtime and jre directories after "cp -r jre runtime" (in FetchURL/build/application/FetchURL dir) As built (before copy): > $ ./FetchURL > *** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" > with message c > an't find transform methodID at JPLISAgent.c line: 552 > *** java.lang.instrument ASSERTION FAILED ***: "result" at > JPLISAgent.c line: 400 > > FATAL ERROR in native method: processing of -javaagent failed > after copy: > $ ./FetchURL > Exception in thread "main" java.lang.ClassNotFoundException: > io.m3si.utils.ClassL > oaderUtils$Agent > ??????? at > java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClas > sLoader.java:636) > ??????? at > java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(Cl > assLoaders.java:182) > ??????? at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:519) > ??????? at > java.instrument/sun.instrument.InstrumentationImpl.loadClassAndStartAg > ent(InstrumentationImpl.java:433) > ??????? at > java.instrument/sun.instrument.InstrumentationImpl.loadClassAndCallPre > main(InstrumentationImpl.java:527) > *** java.lang.instrument ASSERTION FAILED ***: "result" with message > agent load/p > remain call failed at > t:\workspace\open\src\java.instrument\share\native\libinstr > ument\JPLISAgent.c line: 422 > FATAL ERROR in native method: processing of -javaagent failed, > processJavaStart f > ailed but then with jre removed and line in cfg removed I get the same error: > $ ./FetchURL > Exception in thread "main" java.lang.ClassNotFoundException: > io.m3si.utils.ClassLoaderUt > ils$Agent > ??????? at > java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader > .java:636) > ??????? at > java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoad > ers.java:182) > ??????? at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:519) > ??????? at > java.instrument/sun.instrument.InstrumentationImpl.loadClassAndStartAgent(Ins > trumentationImpl.java:433) > ??????? at > java.instrument/sun.instrument.InstrumentationImpl.loadClassAndCallPremain(In > strumentationImpl.java:527) > *** java.lang.instrument ASSERTION FAILED ***: "result" with message > agent load/premain > call failed at > t:\workspace\open\src\java.instrument\share\native\libinstrument\JPLISAge > nt.c line: 422 > FATAL ERROR in native method: processing of -javaagent failed, > processJavaStart failed note the "t:\workspace" ?? I don't have a t: drive, where is that coming from ? /Andy On 9/22/2021 10:25 AM, Scott Palmer wrote: > Sorry That last build with the Oracle OpenJDK needed the build file changed to have > > vendor = JvmVendorSpec.ORACLE > > as well as the command line property pointing to the path to the jdk, > > Scott > > >> On Sep 22, 2021, at 10:24 AM, Scott Palmer wrote: >> >> I reproduced it with the AZUL's distribution of OpenJDK (with JavaFX modules bundled) and I just changed: >> >> vendor = JvmVendorSpec.ADOPTOPENJDK >> >> And get the same error with that build of OpenJDK as well. ?OpenJDK Runtime Environment Temurin-17+35 (build 17+35)? >> You can try that, as Gradle should download the JDK for you. >> >> I then downloaded the Oracle build of OpenJDK from https://urldefense.com/v3/__https://jdk.java.net/17/__;!!ACWV5N9M2RV99hQ!eG4msXvYMONuZH2PKW1Mddol9UY2VkepPpI36eTZz9c_70fXHLm84-lrbzZBwkTMGA$ (build 17+35-2724) >> unzipped it to C:\Tools >> building with: >> >> gradlew -Porg.gradle.java.installations.paths=C:\Tools\jdk-17 clean build >> >> I still reproduce the error. >> >> Though the assertion in native JVM code that you are getting looks like yet another bug! So perhaps it is good that it is discovered as well. >> >> >> Scott >> >>> On Sep 22, 2021, at 9:54 AM, Andy Herrick wrote: >>> >>> I can't seem to get your testcase to work with the Oracle JDK configured. >>> >>> I can build, but then when I run >>> >>> $ ./build/application/FetchURL/FetchURL.exe >>> >>> I get: >>> >>>> *** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with message c >>>> an't find transform methodID at JPLISAgent.c line: 552 >>>> *** java.lang.instrument ASSERTION FAILED ***: "result" at JPLISAgent.c line: 400 >>>> >>>> FATAL ERROR in native method: processing of -javaagent failed >>> same behavior if I restore "runtime" directory and fix FetchURL.cfg to remove app.runtime entry. >>> >>> anyway I used your two source files to build the test app without gradle, and the test can download https://urldefense.com/v3/__https://linear-89.frequency.stream/dist/localnow/89/hls/master/playlist.m3u8__;!!ACWV5N9M2RV99hQ!eG4msXvYMONuZH2PKW1Mddol9UY2VkepPpI36eTZz9c_70fXHLm84-lrbzbGSGkGog$ without any problems. >>> >>> I then moved runtime to jre and added line "app.runtime=$APPDIR/../jre" to cfg file and app still ran fine (downloaded the above) >>> >>> So I still don't have any way to reproduce this problemwith the Oracle jdk. >>> >>> /Andy >>> >>> >>> PS: >>> >>> Although something somewhere else may have changed to counter the problem, it's clear from your description, that since the only place in the code the default runtime path is used (instead of the actual runtime path, which may be different) is the line in WinLauncher.cpp to call SetDllDirectory(). >>> >>> This should be fixed - but would like a way to reproduce the problem it causes first. >>> >>> /Andy >>> >>> On 9/21/2021 12:12 PM, Andy Herrick wrote: >>>> I thought I could create a reproduction scenario by using an app with "-splash:" arg then moving the jre as you did, but I have not yet been able make it fail. >>>> >>>> /Andy >>>> >>>> On 9/21/2021 11:43 AM, Scott Palmer wrote: >>>>>> On Sep 21, 2021, at 11:40 AM, Alan Bateman wrote: >>>>>> >>>>>> ?On 21/09/2021 15:54, Andy Herrick wrote: >>>>>>> I found the problem in open/src/jdk.jpackage/windows/native/applauncher/WinLauncher.cpp >>>>>>> >>>>>>> we call SetDllDirectory() with the path to the bin dir in the default runtime directory, not the actual runtime directory. >>>>>>> >>>>>>> since on Windows we never use other than the default runtime location - we had not seen a problem, but is bug I will file and fix. >>>>>>> >>>>>> Good to see that you found it quickly. However I'm puzzled as why initializingEncoding wasn't called, I would have expected the VM to blow up during early startup. Would you have cycles to dig into that a bit more in case something has been masked, like for example an exception being swallowed. Running with -Xlog:exceptions might reveal something. >>>>> Do you have a case that reproduces the issue? >>>>> >>>>> Scott From jboes at openjdk.java.net Wed Sep 22 15:26:35 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Wed, 22 Sep 2021 15:26:35 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v3] In-Reply-To: References: Message-ID: On Fri, 17 Sep 2021 14:11:38 GMT, Julia Boes wrote: > Thanks for sharing your experience on this, it's appreciated. 0.0.0.0 is common default for Apache httpd [1], Ngnix [2], the Python web server [3]. This being said, I want to make sure we're taking the right decision here so let me seek some further advice on this. > > [1] http://httpd.apache.org/docs/2.4/bind.html > [2] https://docs.nginx.com/nginx/admin-guide/web-server/web-server/ > [3] https://github.com/python/cpython/blob/3.4/Lib/http/server.py Further review concluded that a default binding to 0.0.0.0 creates too a high level of exposure, particularly for a low-threshold utility like this server. Binding to an unrestricted address is a known way for attackers to launch a Denial-of-Service attack, classified by MITRE as CWE-1327 [1]. We therefore update the default binding to the loopback address and amend the help output with information on how to bind to 0.0.0.0, e.g.: $ java -m jdk.httpserver -h Usage: java -m jdk.httpserver [-b bind address] [-p port] [-d directory] [-o none|info|verbose] [-h to show options] Options: -b, --bind-address - Address to bind to. Default: 127.0.0.1 (loopback). For 0.0.0.0 (all interfaces) use -b 0.0.0.0 or -b ::0. -d, --directory - Directory to serve. Default: current directory. -o, --output - Output format. none|info|verbose. Default: info. -p, --port - Port to listen on. Default: 8000. -h, -?, --help - Print this help message. To stop the server, press Ctrl + C. ``` Thanks again for flagging this, @jaikiran . [1] https://cwe.mitre.org/data/definitions/1327.html ------------- PR: https://git.openjdk.java.net/jdk/pull/5505 From jboes at openjdk.java.net Wed Sep 22 15:26:33 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Wed, 22 Sep 2021 15:26:33 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v6] In-Reply-To: References: Message-ID: > This change implements a simple web server that can be run on the command-line with `java -m jdk.httpserver`. > > This is facilitated by adding an entry point for the `jdk.httpserver` module, an implementation class whose main method is run when the above command is executed. This is the first such module entry point in the JDK. > > The server is a minimal HTTP server that serves the static files of a given directory, similar to existing alternatives on other platforms and convenient for testing, development, and debugging. > > Additionally, a small API is introduced for programmatic creation and customization. > > Testing: tier1-3. Julia Boes has updated the pull request incrementally with two additional commits since the last revision: - change default bind address from anylocal to loopback - address PR comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5505/files - new: https://git.openjdk.java.net/jdk/pull/5505/files/fe059131..639e018a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5505&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5505&range=04-05 Stats: 103 lines in 14 files changed: 22 ins; 38 del; 43 mod Patch: https://git.openjdk.java.net/jdk/pull/5505.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5505/head:pull/5505 PR: https://git.openjdk.java.net/jdk/pull/5505 From rriggs at openjdk.java.net Wed Sep 22 15:29:14 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 22 Sep 2021 15:29:14 GMT Subject: RFR: 8269850: Most JDK releases report macOS version 12 as 10.16 instead of 12.0 Message-ID: The Mac OS specific code to determine the os.version property in java_props_macosx.c is updated to replace the code extracting the version from the SystemVersion.plist by reading the version using t\ he hidden link: ------------- Commit messages: - 8269850: Most JDK releases report macOS version 12 as 10.16 instead of 12.0 Changes: https://git.openjdk.java.net/jdk/pull/5633/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5633&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269850 Stats: 11 lines in 1 file changed: 1 ins; 6 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/5633.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5633/head:pull/5633 PR: https://git.openjdk.java.net/jdk/pull/5633 From jvernee at openjdk.java.net Wed Sep 22 15:34:00 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 22 Sep 2021 15:34:00 GMT Subject: RFR: 8273656: Improve java.lang.invoke.MethodType.parameterList() and its usage In-Reply-To: References: Message-ID: On Mon, 13 Sep 2021 11:06:15 GMT, ?????? ??????? wrote: > Currently the method is implemented like > > public List> parameterList() { > return Collections.unmodifiableList(Arrays.asList(ptypes.clone())); > } > > This seems to be excessive, as three objects are allocated here. Instead we can use `List.of(ptypes)` which doesn't allocate anything for empty array and for one of length 1 and 2 it allocates lightweight objects with 2 fields, still copying longer arrays. This is likely to be fruitful as most of methods have 0-2 parameters. > > Also there is a couple of cases when `MethodType.parameterLis()` is called to get its size, which is excessive either as we can use `MethodType.parameterCount()` instead. The null-hostile-ness of `contains` is not something I thought about. It would have been good to mention that in the PR body as well. FWIW, I did a search on grep.app for `parameterList()` calls in java [1] and don't really see any calls to `contains`. I think process-wise creating a CSR would be good, and shouldn't be too much work. Though, I'm not familiar with the process of filing a CSR after a patch has already been merged. [1] : https://grep.app/search?q=.parameterList%28%29&filter[lang][0]=Java ------------- PR: https://git.openjdk.java.net/jdk/pull/5489 From prappo at openjdk.java.net Wed Sep 22 15:38:33 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Wed, 22 Sep 2021 15:38:33 GMT Subject: RFR: 8274075: Fix miscellaneous typos in java.base [v4] In-Reply-To: <27dIhnD8Wc7kQcxq45Np2Lo68AhZvSgmmoV67fgL8rs=.9d8115bf-5176-4de5-99d8-963dc0d12c8f@github.com> References: <27dIhnD8Wc7kQcxq45Np2Lo68AhZvSgmmoV67fgL8rs=.9d8115bf-5176-4de5-99d8-963dc0d12c8f@github.com> Message-ID: > 8274075: Fix miscellaneous typos in java.base Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: Add missing "the" (Spotted by Brian Burkhalter.) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5610/files - new: https://git.openjdk.java.net/jdk/pull/5610/files/05505d97..fa81cacd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5610&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5610&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5610.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5610/head:pull/5610 PR: https://git.openjdk.java.net/jdk/pull/5610 From lancea at openjdk.java.net Wed Sep 22 15:38:39 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 22 Sep 2021 15:38:39 GMT Subject: RFR: 8274075: Fix miscellaneous typos in java.base [v4] In-Reply-To: References: <27dIhnD8Wc7kQcxq45Np2Lo68AhZvSgmmoV67fgL8rs=.9d8115bf-5176-4de5-99d8-963dc0d12c8f@github.com> Message-ID: On Wed, 22 Sep 2021 15:35:54 GMT, Pavel Rappo wrote: >> 8274075: Fix miscellaneous typos in java.base > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Add missing "the" > > (Spotted by Brian Burkhalter.) Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5610 From swpalmer at gmail.com Wed Sep 22 15:44:43 2021 From: swpalmer at gmail.com (Scott Palmer) Date: Wed, 22 Sep 2021 11:44:43 -0400 Subject: [External] : Re: What causes java.lang.InternalError: platform encoding not initialized ? In-Reply-To: References: <3193c4a3-cb49-8653-cba0-61fa89aab0ee@oracle.com> <6CFC7D01-E12B-4DC6-9E30-33B4CB89059F@gmail.com> <6e253a70-c961-a37d-b415-212f65734d2a@oracle.com> <86E52DB1-A0E4-43E5-AC4D-5402591116FD@gmail.com> <6D33CD2C-F0D2-4299-9711-83BB0D2123F8@gmail.com> Message-ID: <126DDE69-728A-4394-AADD-23C859AAADDF@gmail.com> > On Sep 22, 2021, at 11:22 AM, Andy Herrick wrote: > > I still don't get the error your report. Is there something else that needs to be set up for using instrumentation ? Nothing that I?m aware of. Maybe there is something to do with Visual C/C++ runtime libraries that I have installed globally? -just a wild guess. Ohhh? here?s something? I had JDK 17 ?bin? folder on my PATH (along with many other things) If I clear the PATH env var with: set PATH= Then I get an different error: Error occurred during initialization of VM Could not find agent library instrument on the library path, with error: Can?t find dependent libraries Module java.instrument may be missing from runtime image. All I have to do to et back to the original error is set PATH=C:\Tools\jdk-17\bin So this is definitely related to the DLL search path, and it was just lucky that some libraries were found via PATH in my environment. > > I do get a different error when I have both runtime and jre directories after "cp -r jre runtime" (in FetchURL/build/application/FetchURL dir) > > As built (before copy): > >> $ ./FetchURL >> *** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with message c >> an't find transform methodID at JPLISAgent.c line: 552 >> *** java.lang.instrument ASSERTION FAILED ***: "result" at JPLISAgent.c line: 400 >> >> FATAL ERROR in native method: processing of -javaagent failed >> > after copy: > >> $ ./FetchURL >> Exception in thread "main" java.lang.ClassNotFoundException: io.m3si.utils.ClassL >> oaderUtils$Agent >> at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClas >> sLoader.java:636) >> at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(Cl >> assLoaders.java:182) >> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:519) >> at java.instrument/sun.instrument.InstrumentationImpl.loadClassAndStartAg >> ent(InstrumentationImpl.java:433) >> at java.instrument/sun.instrument.InstrumentationImpl.loadClassAndCallPre >> main(InstrumentationImpl.java:527) >> *** java.lang.instrument ASSERTION FAILED ***: "result" with message agent load/p >> remain call failed at t:\workspace\open\src\java.instrument\share\native\libinstr >> ument\JPLISAgent.c line: 422 >> FATAL ERROR in native method: processing of -javaagent failed, processJavaStart f >> ailed > > but then with jre removed and line in cfg removed I get the same error: > >> $ ./FetchURL >> Exception in thread "main" java.lang.ClassNotFoundException: io.m3si.utils.ClassLoaderUt >> ils$Agent >> at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader >> .java:636) >> at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoad >> ers.java:182) >> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:519) >> at java.instrument/sun.instrument.InstrumentationImpl.loadClassAndStartAgent(Ins >> trumentationImpl.java:433) >> at java.instrument/sun.instrument.InstrumentationImpl.loadClassAndCallPremain(In >> strumentationImpl.java:527) >> *** java.lang.instrument ASSERTION FAILED ***: "result" with message agent load/premain >> call failed at t:\workspace\open\src\java.instrument\share\native\libinstrument\JPLISAge >> nt.c line: 422 >> FATAL ERROR in native method: processing of -javaagent failed, processJavaStart failed > > note the "t:\workspace" ? I don't have a t: drive, where is that coming from ? Must be from how the JDK was built. I don?t have a T: drive either. jar -tvf build\application\FetchURL\app\libs\FetchURL-0.0.01.jar 0 Wed Sep 22 11:16:40 EDT 2021 META-INF/ 248 Wed Sep 22 11:16:40 EDT 2021 META-INF/MANIFEST.MF 0 Wed Sep 22 11:10:30 EDT 2021 io/ 0 Wed Sep 22 11:10:30 EDT 2021 io/m3si/ 0 Wed Sep 22 11:10:30 EDT 2021 io/m3si/utils/ 0 Wed Sep 22 11:10:30 EDT 2021 io/m3si/utils/fetchurl/ 3988 Wed Sep 22 11:10:30 EDT 2021 io/m3si/utils/fetchurl/Main.class 1000 Wed Sep 22 11:10:30 EDT 2021 io/m3si/utils/ClassLoaderUtils$Agent.class 4613 Wed Sep 22 11:10:30 EDT 2021 io/m3si/utils/ClassLoaderUtils.class I extracted MANIFEST.MF just to be sure ? Manifest-Version: 1.0 Implementation-Title: Kayak Plugins Bootstrap Premain-Class: io.m3si.utils.ClassLoaderUtils$Agent Implementation-Version: 1.0.1 Agent-Class: io.m3si.utils.ClassLoaderUtils$Agent Main-Class: io.m3si.utils.fetchurl.Main Looks right to me. Scott > > /Andy > > > On 9/22/2021 10:25 AM, Scott Palmer wrote: >> Sorry That last build with the Oracle OpenJDK needed the build file changed to have >> >> vendor = JvmVendorSpec.ORACLE >> >> as well as the command line property pointing to the path to the jdk, >> >> Scott >> >> >>> On Sep 22, 2021, at 10:24 AM, Scott Palmer wrote: >>> >>> I reproduced it with the AZUL's distribution of OpenJDK (with JavaFX modules bundled) and I just changed: >>> >>> vendor = JvmVendorSpec.ADOPTOPENJDK >>> >>> And get the same error with that build of OpenJDK as well. ?OpenJDK Runtime Environment Temurin-17+35 (build 17+35)? >>> You can try that, as Gradle should download the JDK for you. >>> >>> I then downloaded the Oracle build of OpenJDK from https://urldefense.com/v3/__https://jdk.java.net/17/__;!!ACWV5N9M2RV99hQ!eG4msXvYMONuZH2PKW1Mddol9UY2VkepPpI36eTZz9c_70fXHLm84-lrbzZBwkTMGA$ (build 17+35-2724) >>> unzipped it to C:\Tools >>> building with: >>> >>> gradlew -Porg.gradle.java.installations.paths=C:\Tools\jdk-17 clean build >>> >>> I still reproduce the error. >>> >>> Though the assertion in native JVM code that you are getting looks like yet another bug! So perhaps it is good that it is discovered as well. >>> >>> >>> Scott >>> >>>> On Sep 22, 2021, at 9:54 AM, Andy Herrick > wrote: >>>> >>>> I can't seem to get your testcase to work with the Oracle JDK configured. >>>> >>>> I can build, but then when I run >>>> >>>> $ ./build/application/FetchURL/FetchURL.exe >>>> >>>> I get: >>>> >>>>> *** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with message c >>>>> an't find transform methodID at JPLISAgent.c line: 552 >>>>> *** java.lang.instrument ASSERTION FAILED ***: "result" at JPLISAgent.c line: 400 >>>>> >>>>> FATAL ERROR in native method: processing of -javaagent failed >>>> same behavior if I restore "runtime" directory and fix FetchURL.cfg to remove app.runtime entry. >>>> >>>> anyway I used your two source files to build the test app without gradle, and the test can download https://urldefense.com/v3/__https://linear-89.frequency.stream/dist/localnow/89/hls/master/playlist.m3u8__;!!ACWV5N9M2RV99hQ!eG4msXvYMONuZH2PKW1Mddol9UY2VkepPpI36eTZz9c_70fXHLm84-lrbzbGSGkGog$ without any problems. >>>> >>>> I then moved runtime to jre and added line "app.runtime=$APPDIR/../jre" to cfg file and app still ran fine (downloaded the above) >>>> >>>> So I still don't have any way to reproduce this problemwith the Oracle jdk. >>>> >>>> /Andy >>>> >>>> >>>> PS: >>>> >>>> Although something somewhere else may have changed to counter the problem, it's clear from your description, that since the only place in the code the default runtime path is used (instead of the actual runtime path, which may be different) is the line in WinLauncher.cpp to call SetDllDirectory(). >>>> >>>> This should be fixed - but would like a way to reproduce the problem it causes first. >>>> >>>> /Andy >>>> >>>> On 9/21/2021 12:12 PM, Andy Herrick wrote: >>>>> I thought I could create a reproduction scenario by using an app with "-splash:" arg then moving the jre as you did, but I have not yet been able make it fail. >>>>> >>>>> /Andy >>>>> >>>>> On 9/21/2021 11:43 AM, Scott Palmer wrote: >>>>>>> On Sep 21, 2021, at 11:40 AM, Alan Bateman wrote: >>>>>>> >>>>>>> ?On 21/09/2021 15:54, Andy Herrick wrote: >>>>>>>> I found the problem in open/src/jdk.jpackage/windows/native/applauncher/WinLauncher.cpp >>>>>>>> >>>>>>>> we call SetDllDirectory() with the path to the bin dir in the default runtime directory, not the actual runtime directory. >>>>>>>> >>>>>>>> since on Windows we never use other than the default runtime location - we had not seen a problem, but is bug I will file and fix. >>>>>>>> >>>>>>> Good to see that you found it quickly. However I'm puzzled as why initializingEncoding wasn't called, I would have expected the VM to blow up during early startup. Would you have cycles to dig into that a bit more in case something has been masked, like for example an exception being swallowed. Running with -Xlog:exceptions might reveal something. >>>>>> Do you have a case that reproduces the issue? >>>>>> >>>>>> Scott From naoto at openjdk.java.net Wed Sep 22 15:53:53 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 22 Sep 2021 15:53:53 GMT Subject: Integrated: 8273924: ArrayIndexOutOfBoundsException thrown in java.util.JapaneseImperialCalendar.add() In-Reply-To: References: Message-ID: On Tue, 21 Sep 2021 12:47:00 GMT, Naoto Sato wrote: > Fixing an AIOOBE on normalizing the month value. This pull request has now been integrated. Changeset: d39aad92 Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/d39aad92308fbc28bd2de164e331062ebf62da85 Stats: 26 lines in 3 files changed: 24 ins; 0 del; 2 mod 8273924: ArrayIndexOutOfBoundsException thrown in java.util.JapaneseImperialCalendar.add() Reviewed-by: rriggs, iris, joehw ------------- PR: https://git.openjdk.java.net/jdk/pull/5611 From naoto.sato at oracle.com Wed Sep 22 16:13:40 2021 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 22 Sep 2021 09:13:40 -0700 Subject: Unused HashMap's in ThaiBuddhistChronology In-Reply-To: References: Message-ID: <2a1cc9ec-9551-f8d6-7e70-1f8ec644c3fc@oracle.com> I would think these are some left-overs from the 310 project, as I see the same fields in 310's Hijrah chronology. These should be cleaned up. https://github.com/ThreeTen/threetenbp/blob/master/src/main/java/org/threeten/bp/chrono/HijrahChronology.java BTW, it would be moot once they are gone, but I found a typo: ERA_FULL_NAMES.put(FALLBACK_LANGUAGE, new String[]{"Before Buddhist", "Budhhist Era"}); "Budhhist" -> "Buddhist" Naoto On 9/21/21 2:30 PM, Roger Riggs wrote: > Indeed, they seem unused... > > Stephen, do you recall their original use? > > Thanks, Roger > > > On 9/21/21 5:09 PM, Andrey Turbanov wrote: >> Hello. >> Today I discovered 3 static HashMap's in ThaiBuddhistChronology class: >> ERA_NARROW_NAMES, ERA_SHORT_NAMES, ERA_FULL_NAMES >> >> static initializer put some values into them. But their content seems >> unused after that. >> Do I miss something and they are used somewhere? >> >> >> Andrey Turbanov > From mchung at openjdk.java.net Wed Sep 22 16:18:45 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 22 Sep 2021 16:18:45 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v9] In-Reply-To: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> Message-ID: > This reimplements core reflection with method handles. > > For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. > > The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. > > The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. > > Ran tier1-tier8 tests. > > [1] https://bugs.openjdk.java.net/browse/JDK-8013527 > [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 Mandy Chung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits: - Make MethodAccessor non-volatile. Remove MHInvoker/VHInvoker. - Merge - minor cleanup and more test case. - Rename InvokerBuilder to ReflectionInvokerBuilder - Fix NativeAccessor.c build issue for the renamed classes - Shorten the class name - Rename the accessor classes to make it explicit for method handles - Add a new test for testing methods whose parameter types and return type not visible to the caller - Move the handling of native accessor to the factory method for method/constructor accessor - DirectConstructorAccessorImpl should take the MHInvoker parameter - ... and 17 more: https://git.openjdk.java.net/jdk/compare/161fdb4a...1e68d004 ------------- Changes: https://git.openjdk.java.net/jdk/pull/5027/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5027&range=08 Stats: 6529 lines in 75 files changed: 5990 ins; 327 del; 212 mod Patch: https://git.openjdk.java.net/jdk/pull/5027.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5027/head:pull/5027 PR: https://git.openjdk.java.net/jdk/pull/5027 From github.com+70726043+rgiulietti at openjdk.java.net Wed Sep 22 16:19:57 2021 From: github.com+70726043+rgiulietti at openjdk.java.net (Raffaello Giulietti) Date: Wed, 22 Sep 2021 16:19:57 GMT Subject: Integrated: 8271602: Add Math.ceilDiv() family parallel to Math.floorDiv() family In-Reply-To: <2RZKAf-GYIh36SSVTA-22F4qXJ72qNSwO3ZIO9wl9kE=.b08de4f8-34da-4658-9a05-1eec7bce88f4@github.com> References: <2RZKAf-GYIh36SSVTA-22F4qXJ72qNSwO3ZIO9wl9kE=.b08de4f8-34da-4658-9a05-1eec7bce88f4@github.com> Message-ID: On Wed, 1 Sep 2021 20:13:38 GMT, Raffaello Giulietti wrote: > This PR ideally continues #5285, which has been closed as a consequence of inadvertently removing the branch on my repo. See there for initial discussion. > > Sorry for the mess. This pull request has now been integrated. Changeset: da38ced3 Author: Raffaello Giulietti Committer: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/da38ced3299cbd02f210bea4130990a43f6104bf Stats: 1093 lines in 4 files changed: 1040 ins; 0 del; 53 mod 8271602: Add Math.ceilDiv() family parallel to Math.floorDiv() family Reviewed-by: bpb ------------- PR: https://git.openjdk.java.net/jdk/pull/5341 From bpb at openjdk.java.net Wed Sep 22 16:42:56 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 22 Sep 2021 16:42:56 GMT Subject: RFR: 8274075: Fix miscellaneous typos in java.base [v4] In-Reply-To: References: <27dIhnD8Wc7kQcxq45Np2Lo68AhZvSgmmoV67fgL8rs=.9d8115bf-5176-4de5-99d8-963dc0d12c8f@github.com> Message-ID: On Wed, 22 Sep 2021 15:38:33 GMT, Pavel Rappo wrote: >> 8274075: Fix miscellaneous typos in java.base > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Add missing "the" > > (Spotted by Brian Burkhalter.) Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5610 From naoto at openjdk.java.net Wed Sep 22 17:11:58 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 22 Sep 2021 17:11:58 GMT Subject: RFR: 8269850: Most JDK releases report macOS version 12 as 10.16 instead of 12.0 In-Reply-To: References: Message-ID: On Wed, 22 Sep 2021 15:00:59 GMT, Roger Riggs wrote: > The Mac OS specific code to determine the os.version property in java_props_macosx.c is updated > to replace the code extracting the version from the SystemVersion.plist by reading the version using t\ > he hidden link: src/java.base/macosx/native/libjava/java_props_macosx.c line 270: > 268: @"/System/Library/CoreServices/.SystemVersionPlatform.plist"]; > 269: if (version != NULL) { > 270: NSString *nsVerStr = [version objectForKey : @"ProductVersion"]; Should we check `nsVerStr != NULL` here? ------------- PR: https://git.openjdk.java.net/jdk/pull/5633 From rriggs at openjdk.java.net Wed Sep 22 17:41:18 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 22 Sep 2021 17:41:18 GMT Subject: RFR: 8269850: Most JDK releases report macOS version 12 as 10.16 instead of 12.0 [v2] In-Reply-To: References: Message-ID: > The Mac OS specific code to determine the os.version property in java_props_macosx.c is updated > to replace the code extracting the version from the SystemVersion.plist by reading the version using t\ > he hidden link: Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Check for missing version from SystemVersion plist. Refactor avoid repetition of conversion of NSString to char *. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5633/files - new: https://git.openjdk.java.net/jdk/pull/5633/files/d1e2bd20..f44119d9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5633&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5633&range=00-01 Stats: 16 lines in 1 file changed: 6 ins; 7 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5633.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5633/head:pull/5633 PR: https://git.openjdk.java.net/jdk/pull/5633 From iris at openjdk.java.net Wed Sep 22 18:00:56 2021 From: iris at openjdk.java.net (Iris Clark) Date: Wed, 22 Sep 2021 18:00:56 GMT Subject: RFR: 8274075: Fix miscellaneous typos in java.base [v4] In-Reply-To: References: <27dIhnD8Wc7kQcxq45Np2Lo68AhZvSgmmoV67fgL8rs=.9d8115bf-5176-4de5-99d8-963dc0d12c8f@github.com> Message-ID: On Wed, 22 Sep 2021 15:38:33 GMT, Pavel Rappo wrote: >> 8274075: Fix miscellaneous typos in java.base > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Add missing "the" > > (Spotted by Brian Burkhalter.) Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5610 From naoto at openjdk.java.net Wed Sep 22 18:14:02 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 22 Sep 2021 18:14:02 GMT Subject: RFR: 8269850: Most JDK releases report macOS version 12 as 10.16 instead of 12.0 [v2] In-Reply-To: References: Message-ID: On Wed, 22 Sep 2021 17:41:18 GMT, Roger Riggs wrote: >> The Mac OS specific code to determine the os.version property in java_props_macosx.c is updated >> to replace the code extracting the version from the SystemVersion.plist by reading the version using t\ >> he hidden link: > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Check for missing version from SystemVersion plist. > Refactor avoid repetition of conversion of NSString to char *. Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5633 From dfuchs at openjdk.java.net Wed Sep 22 18:19:59 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 22 Sep 2021 18:19:59 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v6] In-Reply-To: References: Message-ID: <2cOOMOP0cLso2NEH6We251sIZXyDXySnW5uCvqb1zkM=.ec196108-6649-4ffa-a9af-fab8c3f214fd@github.com> On Wed, 22 Sep 2021 15:26:33 GMT, Julia Boes wrote: >> This change implements a simple web server that can be run on the command-line with `java -m jdk.httpserver`. >> >> This is facilitated by adding an entry point for the `jdk.httpserver` module, an implementation class whose main method is run when the above command is executed. This is the first such module entry point in the JDK. >> >> The server is a minimal HTTP server that serves the static files of a given directory, similar to existing alternatives on other platforms and convenient for testing, development, and debugging. >> >> Additionally, a small API is introduced for programmatic creation and customization. >> >> Testing: tier1-3. > > Julia Boes has updated the pull request incrementally with two additional commits since the last revision: > > - change default bind address from anylocal to loopback > - address PR comments When the -b option is not explicitly specified on the command line it would be good to print a message that says that the server is bound to the loopback by default, and print the command line that would be needed to bind to all interfaces instead (or instruct the user to call `java -m jdk.httpserver --help` to learn how to bind to all interfaces). I don't think your latest changes include that. src/jdk.httpserver/share/classes/module-info.java line 55: > 53: * [-o none|info|verbose] [-h to show options] > 54: * Options: > 55: * -b, --bind-address - Address to bind to. Default: 127.0.0.1 (loopback). This assumes that the machine on which the server is run has IPv4 configured. It might not be the case. It can also depend on whether -Djdk.net.preferIPv6Addresses=true is specified on the java command line. Maybe this should be: `127.0.0.1 (or ::1), (loopback).` src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/SimpleFileServerImpl.java line 52: > 50: * > 51: *

      Unless specified as arguments, the default values are:

        > 52: *
      • bind address: 127.0.0.1 (loopback)
        • maybe this should say: `127.0.01 (or ::1), (loopback)` src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/resources/simpleserver.properties line 32: > 30: options=\ > 31: Options:\n\ > 32: -b, --bind-address - Address to bind to. Default: 127.0.0.1 (loopback).\n\ This assumes that the machine on which the server is run has IPv4 configured. It might not be the case. It can also depend on whether -Djdk.net.preferIPv6Addresses=true is specified on the java command line. The actual address of the loopback (as returned by InetAddress.getLoopackeAddress()) should therefore preferably be passed as parameter to any message that talks about the loopback. It is not such an issue for the wildcard - because AFAIU there's no difference between 0.0.0.0 and ::0 at the OS level src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/resources/simpleserver.properties line 42: > 40: opt.bindaddress=\ > 41: \-b, --bind-address - Address to bind to. Default: 127.0.0.1 (loopback).\n\ > 42: \ For 0.0.0.0 (all interfaces) use -b 0.0.0.0 or -b ::0. is `opt.bindaddress` used somewhere? I couldn't find it. Same for the other `opt.*` properties below. ------------- PR: https://git.openjdk.java.net/jdk/pull/5505 From prr at openjdk.java.net Wed Sep 22 23:22:58 2021 From: prr at openjdk.java.net (Phil Race) Date: Wed, 22 Sep 2021 23:22:58 GMT Subject: RFR: 8236505: Mark jdk/editpad/EditPadTest.java as @headful In-Reply-To: <_j9LK9SIRBmy-CCoe-OTa5bpqiVYbHUaeTolbqjAcAA=.81c737bb-e4cf-4445-bc3a-28590aeed95b@github.com> References: <_j9LK9SIRBmy-CCoe-OTa5bpqiVYbHUaeTolbqjAcAA=.81c737bb-e4cf-4445-bc3a-28590aeed95b@github.com> Message-ID: On Thu, 16 Sep 2021 09:13:15 GMT, Aleksey Shipilev wrote: > This is a GUI test, and it should be `@headful`. > > Additional testing: > - [x] Test still runs in default, and does not run with `!headful` Well .. since our test framework doesn't run whatever test group this is in on headful systems, what this change has effectively done is say "don't run this test anymore. ever". You'd need to add it to the desktop test group. ------------- PR: https://git.openjdk.java.net/jdk/pull/5544 From redestad at openjdk.java.net Wed Sep 22 23:53:59 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 22 Sep 2021 23:53:59 GMT Subject: RFR: 8273656: Improve java.lang.invoke.MethodType.parameterList() and its usage In-Reply-To: References: Message-ID: On Mon, 13 Sep 2021 11:06:15 GMT, ?????? ??????? wrote: > Currently the method is implemented like > > public List> parameterList() { > return Collections.unmodifiableList(Arrays.asList(ptypes.clone())); > } > > This seems to be excessive, as three objects are allocated here. Instead we can use `List.of(ptypes)` which doesn't allocate anything for empty array and for one of length 1 and 2 it allocates lightweight objects with 2 fields, still copying longer arrays. This is likely to be fruitful as most of methods have 0-2 parameters. > > Also there is a couple of cases when `MethodType.parameterLis()` is called to get its size, which is excessive either as we can use `MethodType.parameterCount()` instead. I think it's OK and even expected to file a CSRs retroactively when you realize post integration that there's a behavior change. I recall doing so at least once in the past. ------------- PR: https://git.openjdk.java.net/jdk/pull/5489 From jpai at openjdk.java.net Thu Sep 23 05:53:00 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Thu, 23 Sep 2021 05:53:00 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v3] In-Reply-To: References: Message-ID: On Wed, 22 Sep 2021 15:20:21 GMT, Julia Boes wrote: > > Thanks for sharing your experience on this, it's appreciated. 0.0.0.0 is common default for Apache httpd [1], Ngnix [2], the Python web server [3]. This being said, I want to make sure we're taking the right decision here so let me seek some further advice on this. > > [1] http://httpd.apache.org/docs/2.4/bind.html > > [2] https://docs.nginx.com/nginx/admin-guide/web-server/web-server/ > > [3] https://github.com/python/cpython/blob/3.4/Lib/http/server.py > > Further review concluded that a default binding to 0.0.0.0 creates too a high level of exposure, particularly for a low-threshold utility like this server. Binding to an unrestricted address is a known way for attackers to launch a Denial-of-Service attack, classified by MITRE as CWE-1327 [1]. We therefore update the default binding to the loopback address and amend the help output with information on how to bind to 0.0.0.0 Thank you Julia for considering this input and coordinating the change. ------------- PR: https://git.openjdk.java.net/jdk/pull/5505 From jpai at openjdk.java.net Thu Sep 23 06:28:01 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Thu, 23 Sep 2021 06:28:01 GMT Subject: RFR: 8258117: jar tool sets the time stamp of module-info.class entries to the current time [v2] In-Reply-To: References: Message-ID: On Fri, 17 Sep 2021 12:54:07 GMT, Jaikiran Pai wrote: >> The commit here is a potential fix for the issue noted in https://bugs.openjdk.java.net/browse/JDK-8258117. >> >> The change here repurposes an existing internal interface `ModuleInfoEntry` to keep track of the last modified timestamp of a `module-info.class` descriptor. >> >> This commit uses the timestamp of the `module-info.class` on the filesystem to set the time on the `JarEntry`. There are a couple of cases to consider here: >> >> 1. When creating a jar (using `--create`), we use the source `module-info.class` from the filesystem and then add extended info to it (attributes like packages, module version etc...). In such cases, this patch will use the lastmodified timestamp from the filesystem of `module-info.class` even though we might end up updating/extending/modifying (for example by adding a module version) its content while storing it as a `JarEntry`. >> >> 2. When updating a jar (using `--update`), this patch will use the lastmodified timestamp of `module-info.class` either from the filesystem or from the source jar's entry (depending on whether a new `module-info.class` is being passed to the command). Here too, it's possible that we might end up changing/modifying/extending the `module-info.class` (for example, changing the module version to a new version) that gets written into the updated jar file, but this patch _won't_ use `System.currentTimeMillis()` even in such cases. >> >> If we do have to track actual changes that might happen to `module-info.class` while extending its info (in `extendedInfoBytes()`) and then decide whether to use current system time as last modified time, then this will require a bigger change and also a discussion on what kind of extending of module-info.class content will require a change to the lastmodifiedtime of that entry. > > Jaikiran Pai 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 two additional commits since the last revision: > > - Merge latest from master branch > - 8258117: jar tool sets the time stamp of module-info.class entries to the current time Any reviews for this one, please? ------------- PR: https://git.openjdk.java.net/jdk/pull/5486 From prappo at openjdk.java.net Thu Sep 23 08:12:58 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Thu, 23 Sep 2021 08:12:58 GMT Subject: Integrated: 8274075: Fix miscellaneous typos in java.base In-Reply-To: <27dIhnD8Wc7kQcxq45Np2Lo68AhZvSgmmoV67fgL8rs=.9d8115bf-5176-4de5-99d8-963dc0d12c8f@github.com> References: <27dIhnD8Wc7kQcxq45Np2Lo68AhZvSgmmoV67fgL8rs=.9d8115bf-5176-4de5-99d8-963dc0d12c8f@github.com> Message-ID: On Tue, 21 Sep 2021 12:26:25 GMT, Pavel Rappo wrote: > 8274075: Fix miscellaneous typos in java.base This pull request has now been integrated. Changeset: 87998565 Author: Pavel Rappo URL: https://git.openjdk.java.net/jdk/commit/8799856528f5804b616b734caed3fc4ba9811bfa Stats: 26 lines in 9 files changed: 0 ins; 1 del; 25 mod 8274075: Fix miscellaneous typos in java.base Reviewed-by: dfuchs, darcy, iris, lancea, bpb ------------- PR: https://git.openjdk.java.net/jdk/pull/5610 From shade at openjdk.java.net Thu Sep 23 08:58:00 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 23 Sep 2021 08:58:00 GMT Subject: RFR: 8236505: Mark jdk/editpad/EditPadTest.java as @headful In-Reply-To: References: <_j9LK9SIRBmy-CCoe-OTa5bpqiVYbHUaeTolbqjAcAA=.81c737bb-e4cf-4445-bc3a-28590aeed95b@github.com> Message-ID: <43Zb49XQBPKCqJgwxt7JKJR726vM0raQI3ZyN26Oq08=.3e765ce1-ffbb-4cba-b96d-3de275d7a980@github.com> On Wed, 22 Sep 2021 23:19:50 GMT, Phil Race wrote: > You'd need to add it to the desktop test group. Right. See #5648. ------------- PR: https://git.openjdk.java.net/jdk/pull/5544 From shade at openjdk.java.net Thu Sep 23 09:01:06 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 23 Sep 2021 09:01:06 GMT Subject: RFR: 8177814: jdk/editpad is not in jdk TEST.groups Message-ID: @prrace notices this here: https://github.com/openjdk/jdk/pull/5544#issuecomment-925396869. And I think it is the already open issue that this patch is fixing. While the original patch added the test in `jdk_other`, Phil suggests it to be added to `jdk_desktop`. Additional testing: - [x] `jdk_editpad` is passing ------------- Commit messages: - Fix Changes: https://git.openjdk.java.net/jdk/pull/5648/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5648&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8177814 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5648.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5648/head:pull/5648 PR: https://git.openjdk.java.net/jdk/pull/5648 From ihse at openjdk.java.net Thu Sep 23 10:40:08 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 23 Sep 2021 10:40:08 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v22] In-Reply-To: References: Message-ID: On Wed, 22 Sep 2021 10:27:45 GMT, Jaikiran Pai wrote: >> The commit in this PR implements the proposal for enhancement that was discussed in the core-libs-dev mailing list recently[1], for https://bugs.openjdk.java.net/browse/JDK-8231640 >> >> At a high level - the `store()` APIs in `Properties` have been modified to now look for the `SOURCE_DATE_EPOCH` environment variable[2]. If that env variable is set, then instead of writing out the current date time as a date comment, the `store()` APIs instead will use the value set for this env variable to parse it to a `Date` and write out the string form of such a date. The implementation here uses the `d MMM yyyy HH:mm:ss 'GMT'` date format and `Locale.ROOT` to format and write out such a date. This should provide reproducibility whenever the `SOURCE_DATE_EPOCH` is set. Furthermore, intentionally, no changes in the date format of the "current date" have been done. >> >> These modified `store()` APIs work in the presence of the `SecurityManager` too. The caller is expected to have a read permission on the `SOURCE_DATE_EPOCH` environment variable. If the caller doesn't have that permission, then the implementation of these `store()` APIs will write out the "current date" and will ignore any value that has been set for the `SOURCE_DATE_EPOCH` env variable. This should allow for backward compatibility of existing applications, where, when they run under a `SecurityManager` and perhaps with an existing restrictive policy file, the presence of `SOURCE_DATE_EPOCH` shouldn't impact their calls to the `store()` APIs. >> >> The modified `store()` APIs will also ignore any value for `SOURCE_DATE_EPOCH` that cannot be parsed to an `long` value. In such cases, the `store()` APIs will write out the "current date" and ignore the value set for this environment variable. No exceptions will be thrown for such invalid values. This is an additional backward compatibility precaution to prevent any rogue value for `SOURCE_DATE_EPOCH` from breaking applications. >> >> An additional change in the implementation of these `store()` APIs and unrelated to the date comment, is that these APIs will now write out the property keys in a deterministic order. The keys will be written out in the natural ordering as specified by `java.lang.String#compareTo()` API. >> >> The combination of the ordering of the property keys when written out and the usage of `SOURCE_DATE_EPOCH` environment value to determine the date comment should together allow for reproducibility of the output generated by these `store()` APIs. >> >> New jtreg test classes have been introduced to verify these changes. The primary focus of `PropertiesStoreTest` is the ordering aspects of the property keys that are written out. On the other hand `StoreReproducibilityTest` focuses on the reproducibility of the output generated by these APIs. The `StoreReproducibilityTest` runs these tests both in the presence and absence of `SecurityManager`. Plus, in the presence of SecurityManager, it tests both the scenarios where the caller is granted the requisite permission and in other case not granted that permission. >> >> These new tests and existing tests under `test/jdk/java/util/Properties/` pass with these changes. >> >> [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-August/080758.html >> [2] https://reproducible-builds.org/specs/source-date-epoch/ > > Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision: > > - Revert "Implement Mark's suggestion in CSR to include the java.properties.date in the list of system properties listed in System::getProperties()" > > Additional inputs since this specific commit was introduced have leaned towards not listing this property in System::getProperties() > > This reverts commit 458c1fd37cf1e8e8bd0a60a171d173ce5da12b7c. > - reduce the line length of code comment Marked as reviewed by ihse (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5372 From dfuchs at openjdk.java.net Thu Sep 23 10:45:49 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 23 Sep 2021 10:45:49 GMT Subject: RFR: JDK-8262944: Improve exception message when automatic module lists provider class not in JAR file In-Reply-To: References: Message-ID: On Thu, 16 Sep 2021 09:06:20 GMT, Christian Stein wrote: > This commit appends the name of the JAR file to the exception message for when automatic module lists a non-existing provider class. The proposed change looks reasonable to me. ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5543 From jvernee at openjdk.java.net Thu Sep 23 10:51:58 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 23 Sep 2021 10:51:58 GMT Subject: RFR: JDK-8262944: Improve exception message when automatic module lists provider class not in JAR file In-Reply-To: References: Message-ID: <7I6GWx1JkdVfwAgi4Qt613nPwZ95C2RKk4s_BDQia90=.f901ea03-05b5-4e2a-872f-598384af9184@github.com> On Thu, 16 Sep 2021 09:06:20 GMT, Christian Stein wrote: > This commit appends the name of the JAR file to the exception message for when automatic module lists a non-existing provider class. Marked as reviewed by jvernee (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5543 From alanb at openjdk.java.net Thu Sep 23 11:29:56 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 23 Sep 2021 11:29:56 GMT Subject: RFR: JDK-8262944: Improve exception message when automatic module lists provider class not in JAR file In-Reply-To: References: Message-ID: On Thu, 16 Sep 2021 09:06:20 GMT, Christian Stein wrote: > This commit appends the name of the JAR file to the exception message for when automatic module lists a non-existing provider class. src/java.base/share/classes/jdk/internal/module/ModulePath.java line 554: > 552: String pn = packageName(cn); > 553: if (!packages.contains(pn)) { > 554: String msg = "Provider class " + cn + " not in module created for " + fn; "not in module created" isn't quite right as the module cannot be created. Maybe you could change it to "not in JAR file" ------------- PR: https://git.openjdk.java.net/jdk/pull/5543 From alanb at openjdk.java.net Thu Sep 23 11:42:55 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 23 Sep 2021 11:42:55 GMT Subject: RFR: 8273401: Disable JarIndex support in URLClassPath [v2] In-Reply-To: <6AgDFIsZRfYJkh78ZdEGInPHOjeJwvJbHopeuEq79Lc=.2e0d84db-85a1-484f-8da9-090878da6a38@github.com> References: <7fXVoIjSmGliERuXW2VgnPMcywMRPv_3lhGL01IMRwI=.5d8e4020-8719-4b23-a303-9f311bbc5961@github.com> <6AgDFIsZRfYJkh78ZdEGInPHOjeJwvJbHopeuEq79Lc=.2e0d84db-85a1-484f-8da9-090878da6a38@github.com> Message-ID: On Thu, 16 Sep 2021 01:29:41 GMT, wxiang wrote: >> wxiang has updated the pull request incrementally with one additional commit since the last revision: >> >> add isEmpty check > > I have changed > > ENABLE_JAR_INDEX = p != null ? p.equals("true") : false; > > to > > ENABLE_JAR_INDEX = p != null ? p.equals("true") || p.isEmpty() : false; > > > Furthemore, in order to maintain consistency in URLClassPath, the property name is "jdk.net.URLClassPath.enableJarIndex" . @shiyuexw Just a reminder that you need to finalize the CSR. ------------- PR: https://git.openjdk.java.net/jdk/pull/5524 From naoto at openjdk.java.net Thu Sep 23 12:52:03 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 23 Sep 2021 12:52:03 GMT Subject: Integrated: 8273546: DecimalFormat documentation contains literal HTML character references In-Reply-To: References: Message-ID: On Tue, 21 Sep 2021 21:45:40 GMT, Naoto Sato wrote: > Simple doc fix. This pull request has now been integrated. Changeset: c4345285 Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/c43452859d7211f0d6537d71bd0df89412d4ff6f Stats: 14 lines in 3 files changed: 0 ins; 0 del; 14 mod 8273546: DecimalFormat documentation contains literal HTML character references Reviewed-by: joehw, bpb, iris, lancea ------------- PR: https://git.openjdk.java.net/jdk/pull/5620 From clanger at openjdk.java.net Thu Sep 23 13:28:53 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Thu, 23 Sep 2021 13:28:53 GMT Subject: RFR: 8269850: Most JDK releases report macOS version 12 as 10.16 instead of 12.0 [v2] In-Reply-To: References: Message-ID: <2hcAhyzNzSkdYreze0riJO1kCnIJl1oVObpvvWXcOPw=.07ac9de0-115d-4f5e-8e82-9b2b2ec72ac3@github.com> On Wed, 22 Sep 2021 17:41:18 GMT, Roger Riggs wrote: >> The Mac OS specific code to determine the os.version property in java_props_macosx.c is updated >> to replace the code extracting the version from the SystemVersion.plist by reading the version using t\ >> he hidden link: > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Check for missing version from SystemVersion plist. > Refactor avoid repetition of conversion of NSString to char *. Looks good to me. I tested with an Xcode 11.7 build on a MacOS 11.6 and there OsVersionTest fails without the fix and passes with it. ------------- Marked as reviewed by clanger (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5633 From cstein at openjdk.java.net Thu Sep 23 13:33:55 2021 From: cstein at openjdk.java.net (Christian Stein) Date: Thu, 23 Sep 2021 13:33:55 GMT Subject: RFR: JDK-8262944: Improve exception message when automatic module lists provider class not in JAR file In-Reply-To: References: Message-ID: On Thu, 23 Sep 2021 11:26:26 GMT, Alan Bateman wrote: >> This commit appends the name of the JAR file to the exception message for when automatic module lists a non-existing provider class. > > src/java.base/share/classes/jdk/internal/module/ModulePath.java line 554: > >> 552: String pn = packageName(cn); >> 553: if (!packages.contains(pn)) { >> 554: String msg = "Provider class " + cn + " not in module created for " + fn; > > "not in module created" isn't quite right as the module cannot be created. Maybe you could change it to "not in JAR file" Will do so. ------------- PR: https://git.openjdk.java.net/jdk/pull/5543 From cstein at openjdk.java.net Thu Sep 23 13:40:30 2021 From: cstein at openjdk.java.net (Christian Stein) Date: Thu, 23 Sep 2021 13:40:30 GMT Subject: RFR: JDK-8262944: Improve exception message when automatic module lists provider class not in JAR file [v2] In-Reply-To: References: Message-ID: > This commit appends the name of the JAR file to the exception message for when automatic module lists a non-existing provider class. Christian Stein has updated the pull request incrementally with one additional commit since the last revision: Assert that only the name of the JAR file (without its path) is appended ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5543/files - new: https://git.openjdk.java.net/jdk/pull/5543/files/bb9762b8..5afba0bd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5543&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5543&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5543.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5543/head:pull/5543 PR: https://git.openjdk.java.net/jdk/pull/5543 From andy.herrick at oracle.com Thu Sep 23 14:05:40 2021 From: andy.herrick at oracle.com (Andy Herrick) Date: Thu, 23 Sep 2021 10:05:40 -0400 Subject: [External] : Re: What causes java.lang.InternalError: platform encoding not initialized ? In-Reply-To: <126DDE69-728A-4394-AADD-23C859AAADDF@gmail.com> References: <3193c4a3-cb49-8653-cba0-61fa89aab0ee@oracle.com> <6CFC7D01-E12B-4DC6-9E30-33B4CB89059F@gmail.com> <6e253a70-c961-a37d-b415-212f65734d2a@oracle.com> <86E52DB1-A0E4-43E5-AC4D-5402591116FD@gmail.com> <6D33CD2C-F0D2-4299-9711-83BB0D2123F8@gmail.com> <126DDE69-728A-4394-AADD-23C859AAADDF@gmail.com> Message-ID: <2b3235a1-c6d2-1c26-cfc6-6be8b9a31420@oracle.com> I also had a JDK16 bin dir on my path ... I can get the error you show below (Error occurred during initialization of VM) if I clear my PATH, which is different from the error I get when running without moved runtime, so I can reproduce problem and test the fix. I am using a script like: > > ./gradlew.bat clean build > > cp -r build/application build/app2 > mv build/app2/FetchURL/jre build/app2/FetchURL/runtime > cp FetchURLcfg.save build/app2/FetchURL/app/FetchURL.cfg > > export PATH= > > echo "" > echo "RUN as built:" > echo "" > build/application/FetchURL/FetchURL > > echo "" > echo "RUN with default runtime:" > echo "" > build/app2/FetchURL/FetchURL > after fix both runs should have the same behavior and there should be no error like: > Error occurred during initialization of VM > Could not find agent library instrument on the library path, with > error: Can't find dependent libraries > Module java.instrument may be missing from runtime image. /Andy On 9/22/2021 11:44 AM, Scott Palmer wrote: > > >> On Sep 22, 2021, at 11:22 AM, Andy Herrick > > wrote: >> >> I still don't get the error your report.? Is there something else >> that needs to be set up for using instrumentation ? > > Nothing that I?m aware of. ?Maybe there is something to do with Visual > C/C++ runtime libraries that I have installed globally? -just a wild > guess. > > Ohhh? here?s something? > > I had JDK 17 ?bin? folder on my PATH (along with many other things) > If I clear the PATH env var with: > ?set PATH= > > Then I get an different error: > > Error occurred during initialization of VM > Could not find agent library instrument on the library path, with > error: Can?t find dependent libraries > Module java.instrument may be missing from runtime image. > > All I have to do to et back to the original error is > > set PATH=C:\Tools\jdk-17\bin > > So this is definitely related to the DLL search path, and it was just > lucky that some libraries were found via PATH in my environment. > >> >> I do get a different error when I have both runtime and jre >> directories after "cp -r jre runtime" (in >> FetchURL/build/application/FetchURL dir) >> >> As built (before copy): >> >>> $ ./FetchURL >>> *** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" >>> with message c >>> an't find transform methodID at JPLISAgent.c line: 552 >>> *** java.lang.instrument ASSERTION FAILED ***: "result" at >>> JPLISAgent.c line: 400 >>> >>> FATAL ERROR in native method: processing of -javaagent failed >>> >> after copy: >> >>> $ ./FetchURL >>> Exception in thread "main" java.lang.ClassNotFoundException: >>> io.m3si.utils.ClassL >>> oaderUtils$Agent >>> ??????? at >>> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClas >>> sLoader.java:636) >>> ??????? at >>> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(Cl >>> assLoaders.java:182) >>> ??????? at >>> java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:519) >>> ??????? at >>> java.instrument/sun.instrument.InstrumentationImpl.loadClassAndStartAg >>> ent(InstrumentationImpl.java:433) >>> ??????? at >>> java.instrument/sun.instrument.InstrumentationImpl.loadClassAndCallPre >>> main(InstrumentationImpl.java:527) >>> *** java.lang.instrument ASSERTION FAILED ***: "result" with message >>> agent load/p >>> remain call failed at >>> t:\workspace\open\src\java.instrument\share\native\libinstr >>> ument\JPLISAgent.c line: 422 >>> FATAL ERROR in native method: processing of -javaagent failed, >>> processJavaStart f >>> ailed >> >> but then with jre removed and line in cfg removed I get the same error: >> >>> $ ./FetchURL >>> Exception in thread "main" java.lang.ClassNotFoundException: >>> io.m3si.utils.ClassLoaderUt >>> ils$Agent >>> ??????? at >>> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader >>> .java:636) >>> ??????? at >>> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoad >>> ers.java:182) >>> ??????? at >>> java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:519) >>> ??????? at >>> java.instrument/sun.instrument.InstrumentationImpl.loadClassAndStartAgent(Ins >>> trumentationImpl.java:433) >>> ??????? at >>> java.instrument/sun.instrument.InstrumentationImpl.loadClassAndCallPremain(In >>> strumentationImpl.java:527) >>> *** java.lang.instrument ASSERTION FAILED ***: "result" with message >>> agent load/premain >>> call failed at >>> t:\workspace\open\src\java.instrument\share\native\libinstrument\JPLISAge >>> nt.c line: 422 >>> FATAL ERROR in native method: processing of -javaagent failed, >>> processJavaStart failed >> >> note the "t:\workspace" ?? I don't have a t: drive, where is that >> coming from ? > > Must be from how the JDK was built. ?I don?t have a T: drive either. > > jar -tvf build\application\FetchURL\app\libs\FetchURL-0.0.01.jar > ? ? ?0 Wed Sep 22 11:16:40 EDT 2021 META-INF/ > ? ?248 Wed Sep 22 11:16:40 EDT 2021 META-INF/MANIFEST.MF > ? ? ?0 Wed Sep 22 11:10:30 EDT 2021 io/ > ? ? ?0 Wed Sep 22 11:10:30 EDT 2021 io/m3si/ > ? ? ?0 Wed Sep 22 11:10:30 EDT 2021 io/m3si/utils/ > ? ? ?0 Wed Sep 22 11:10:30 EDT 2021 io/m3si/utils/fetchurl/ > ??3988 Wed Sep 22 11:10:30 EDT 2021 io/m3si/utils/fetchurl/Main.class > ??1000 Wed Sep 22 11:10:30 EDT 2021 > io/m3si/utils/ClassLoaderUtils$Agent.class > ??4613 Wed Sep 22 11:10:30 EDT 2021 io/m3si/utils/ClassLoaderUtils.class > > I extracted MANIFEST.MF just to be sure ? > > Manifest-Version: 1.0 > Implementation-Title: Kayak Plugins Bootstrap > Premain-Class: io.m3si.utils.ClassLoaderUtils$Agent > Implementation-Version: 1.0.1 > Agent-Class: io.m3si.utils.ClassLoaderUtils$Agent > Main-Class: io.m3si.utils.fetchurl.Main > > Looks right to me. > > Scott > >> >> /Andy >> >> >> On 9/22/2021 10:25 AM, Scott Palmer wrote: >>> Sorry That last build with the Oracle OpenJDK needed the build file >>> changed to have >>> >>> ???vendor = JvmVendorSpec.ORACLE >>> >>> as well as the command line property pointing to the path to the jdk, >>> >>> Scott >>> >>> >>>> On Sep 22, 2021, at 10:24 AM, Scott Palmer >>> > wrote: >>>> >>>> I reproduced it with the AZUL's distribution of OpenJDK (with >>>> JavaFX modules bundled) and I just changed: >>>> >>>> vendor = JvmVendorSpec.ADOPTOPENJDK >>>> >>>> And get the same error with that build of OpenJDK as well. >>>> ??OpenJDK Runtime Environment Temurin-17+35 (build 17+35)? >>>> You can try that, as Gradle should download the JDK for you. >>>> >>>> I then downloaded the Oracle build of OpenJDK >>>> fromhttps://urldefense.com/v3/__https://jdk.java.net/17/__;!!ACWV5N9M2RV99hQ!eG4msXvYMONuZH2PKW1Mddol9UY2VkepPpI36eTZz9c_70fXHLm84-lrbzZBwkTMGA$ >>>> ????(build >>>> 17+35-2724) >>>> unzipped it to C:\Tools >>>> building with: >>>> >>>> gradlew -Porg.gradle.java.installations.paths=C:\Tools\jdk-17 clean >>>> build >>>> >>>> I still reproduce the error. >>>> >>>> Though the assertion in native JVM code that you are getting looks >>>> like yet another bug! ?So perhaps it is good that it is discovered >>>> as well. >>>> >>>> >>>> Scott >>>> >>>>> On Sep 22, 2021, at 9:54 AM, Andy Herrick >>>> > wrote: >>>>> >>>>> I can't seem to get your testcase to work with the Oracle JDK >>>>> configured. >>>>> >>>>> I can build, but then when I run >>>>> >>>>> $ ./build/application/FetchURL/FetchURL.exe >>>>> >>>>> I get: >>>>> >>>>>> *** java.lang.instrument ASSERTION FAILED ***: >>>>>> "!errorOutstanding" with message c >>>>>> an't find transform methodID at JPLISAgent.c line: 552 >>>>>> *** java.lang.instrument ASSERTION FAILED ***: "result" at >>>>>> JPLISAgent.c line: 400 >>>>>> >>>>>> FATAL ERROR in native method: processing of -javaagent failed >>>>> same behavior if I restore "runtime" directory and fix >>>>> FetchURL.cfg to remove app.runtime entry. >>>>> >>>>> anyway I used your two source files to build the test app without >>>>> gradle, and the test can >>>>> downloadhttps://urldefense.com/v3/__https://linear-89.frequency.stream/dist/localnow/89/hls/master/playlist.m3u8__;!!ACWV5N9M2RV99hQ!eG4msXvYMONuZH2PKW1Mddol9UY2VkepPpI36eTZz9c_70fXHLm84-lrbzbGSGkGog$ >>>>> ?without >>>>> any problems. >>>>> >>>>> I then moved runtime to jre and added line >>>>> "app.runtime=$APPDIR/../jre" to cfg file and app still ran fine >>>>> (downloaded the above) >>>>> >>>>> So I still don't have any way to reproduce this problemwith the >>>>> Oracle jdk. >>>>> >>>>> /Andy >>>>> >>>>> >>>>> PS: >>>>> >>>>> Although something somewhere else may have changed to counter the >>>>> problem, it's clear from your description, that since the only >>>>> place in the code the default runtime path is used (instead of the >>>>> actual runtime path, which may be different) is the line in >>>>> WinLauncher.cpp to call SetDllDirectory(). >>>>> >>>>> This should be fixed - but would like a way to reproduce the >>>>> problem it causes first. >>>>> >>>>> /Andy >>>>> >>>>> On 9/21/2021 12:12 PM, Andy Herrick wrote: >>>>>> I thought I could create a reproduction scenario by using an app >>>>>> with "-splash:" arg then moving the jre as you did, >>>>>> but I have not yet been able make it fail. >>>>>> >>>>>> /Andy >>>>>> >>>>>> On 9/21/2021 11:43 AM, Scott Palmer wrote: >>>>>>>> On Sep 21, 2021, at 11:40 AM, Alan Bateman >>>>>>>> > wrote: >>>>>>>> >>>>>>>> ?On 21/09/2021 15:54, Andy Herrick wrote: >>>>>>>>> I found the problem in >>>>>>>>> open/src/jdk.jpackage/windows/native/applauncher/WinLauncher.cpp >>>>>>>>> >>>>>>>>> we call SetDllDirectory() with the path to the bin dir in the >>>>>>>>> default runtime directory, not the actual runtime directory. >>>>>>>>> >>>>>>>>> since on Windows we never use other than the default runtime >>>>>>>>> location - we had not seen a problem, but is bug I will file >>>>>>>>> and fix. >>>>>>>>> >>>>>>>> Good to see that you found it quickly. However I'm puzzled as >>>>>>>> why initializingEncoding wasn't called, I would have expected >>>>>>>> the VM to blow up during early startup. Would you have cycles >>>>>>>> to dig into that a bit more in case something has been masked, >>>>>>>> like for example an exception being swallowed. ?Running with >>>>>>>> -Xlog:exceptions might reveal something. >>>>>>> Do you have a case that reproduces the issue? >>>>>>> >>>>>>> Scott > From alanb at openjdk.java.net Thu Sep 23 14:06:59 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 23 Sep 2021 14:06:59 GMT Subject: RFR: JDK-8262944: Improve exception message when automatic module lists provider class not in JAR file [v2] In-Reply-To: References: Message-ID: On Thu, 23 Sep 2021 13:40:30 GMT, Christian Stein wrote: >> This commit appends the name of the JAR file to the exception message for when automatic module lists a non-existing provider class. > > Christian Stein has updated the pull request incrementally with one additional commit since the last revision: > > Assert that only the name of the JAR file (without its path) is appended Thanks for the update. For completeness, you may want to add to the list of JBS issues listed at the top of AutomatcModulesTest and you probably should update its copyright year too. ------------- PR: https://git.openjdk.java.net/jdk/pull/5543 From cstein at openjdk.java.net Thu Sep 23 14:53:42 2021 From: cstein at openjdk.java.net (Christian Stein) Date: Thu, 23 Sep 2021 14:53:42 GMT Subject: RFR: JDK-8262944: Improve exception message when automatic module lists provider class not in JAR file [v3] In-Reply-To: References: Message-ID: > This commit appends the name of the JAR file to the exception message for when automatic module lists a non-existing provider class. Christian Stein has updated the pull request incrementally with one additional commit since the last revision: Add JBS issue `8262944` to the `@bug` list and update copyright year ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5543/files - new: https://git.openjdk.java.net/jdk/pull/5543/files/5afba0bd..f8b15c13 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5543&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5543&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5543.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5543/head:pull/5543 PR: https://git.openjdk.java.net/jdk/pull/5543 From rriggs at openjdk.java.net Thu Sep 23 14:54:01 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 23 Sep 2021 14:54:01 GMT Subject: RFR: 8269850: Most JDK releases report macOS version 12 as 10.16 instead of 12.0 [v2] In-Reply-To: References: Message-ID: On Wed, 22 Sep 2021 17:41:18 GMT, Roger Riggs wrote: >> The Mac OS specific code to determine the os.version property in java_props_macosx.c is updated >> to replace the code extracting the version from the SystemVersion.plist by reading the version using t\ >> he hidden link: > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Check for missing version from SystemVersion plist. > Refactor avoid repetition of conversion of NSString to char *. Thanks for testing with Xcode 11.7. and MacOS 11.6. ------------- PR: https://git.openjdk.java.net/jdk/pull/5633 From rriggs at openjdk.java.net Thu Sep 23 15:05:05 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 23 Sep 2021 15:05:05 GMT Subject: Integrated: 8269850: Most JDK releases report macOS version 12 as 10.16 instead of 12.0 In-Reply-To: References: Message-ID: On Wed, 22 Sep 2021 15:00:59 GMT, Roger Riggs wrote: > The Mac OS specific code to determine the os.version property in java_props_macosx.c is updated > to replace the code extracting the version from the SystemVersion.plist by reading the version using t\ > he hidden link: This pull request has now been integrated. Changeset: 3b1b8fc6 Author: Roger Riggs URL: https://git.openjdk.java.net/jdk/commit/3b1b8fc646493eae5f4df828afe29abb75fa5e60 Stats: 25 lines in 1 file changed: 7 ins; 13 del; 5 mod 8269850: Most JDK releases report macOS version 12 as 10.16 instead of 12.0 Reviewed-by: naoto, clanger ------------- PR: https://git.openjdk.java.net/jdk/pull/5633 From lancea at openjdk.java.net Thu Sep 23 15:16:01 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 23 Sep 2021 15:16:01 GMT Subject: RFR: JDK-8262944: Improve exception message when automatic module lists provider class not in JAR file [v3] In-Reply-To: References: Message-ID: On Thu, 23 Sep 2021 14:53:42 GMT, Christian Stein wrote: >> This commit appends the name of the JAR file to the exception message for when automatic module lists a non-existing provider class. > > Christian Stein has updated the pull request incrementally with one additional commit since the last revision: > > Add JBS issue `8262944` to the `@bug` list and update copyright year Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5543 From jlahoda at openjdk.java.net Thu Sep 23 15:38:44 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 23 Sep 2021 15:38:44 GMT Subject: RFR: 8273682: Upgrade Jline to 3.20.0 Message-ID: I'd like to upgrade the internal JLine to 3.20.0, to support the rxvt terminal (see JDK-8270943), and to generally use a newer version of the library. This patch is basically a application of relevant parts of the diff between JLine 3.14.0 and 3.20.0, with merge fixes as needed. Thanks! ------------- Commit messages: - Removing trailing whitespace. - Fixing tests. - Fixing Windows build. - Upgrading JLine to 3.20.0 Changes: https://git.openjdk.java.net/jdk/pull/5655/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5655&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273682 Stats: 2667 lines in 47 files changed: 1830 ins; 473 del; 364 mod Patch: https://git.openjdk.java.net/jdk/pull/5655.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5655/head:pull/5655 PR: https://git.openjdk.java.net/jdk/pull/5655 From mchung at openjdk.java.net Thu Sep 23 16:55:53 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 23 Sep 2021 16:55:53 GMT Subject: RFR: JDK-8262944: Improve exception message when automatic module lists provider class not in JAR file [v3] In-Reply-To: References: Message-ID: <2XIkq7Eh3NNyJN_D97vyfAO9Iuhl_Y25VaHC-TX_PII=.443145b0-f4df-4191-bd9a-a61de80b89c0@github.com> On Thu, 23 Sep 2021 14:53:42 GMT, Christian Stein wrote: >> This commit appends the name of the JAR file to the exception message for when automatic module lists a non-existing provider class. > > Christian Stein has updated the pull request incrementally with one additional commit since the last revision: > > Add JBS issue `8262944` to the `@bug` list and update copyright year Looks good to me. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5543 From alanb at openjdk.java.net Thu Sep 23 17:07:56 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 23 Sep 2021 17:07:56 GMT Subject: RFR: JDK-8262944: Improve exception message when automatic module lists provider class not in JAR file [v3] In-Reply-To: References: Message-ID: On Thu, 23 Sep 2021 14:53:42 GMT, Christian Stein wrote: >> This commit appends the name of the JAR file to the exception message for when automatic module lists a non-existing provider class. > > Christian Stein has updated the pull request incrementally with one additional commit since the last revision: > > Add JBS issue `8262944` to the `@bug` list and update copyright year Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5543 From serb at openjdk.java.net Thu Sep 23 19:27:58 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 23 Sep 2021 19:27:58 GMT Subject: RFR: 8177814: jdk/editpad is not in jdk TEST.groups In-Reply-To: References: Message-ID: On Thu, 23 Sep 2021 08:54:48 GMT, Aleksey Shipilev wrote: > @prrace notices this here: https://github.com/openjdk/jdk/pull/5544#issuecomment-925396869. And I think it is the already open issue that this patch is fixing. While the original patch added the test in `jdk_other`, Phil suggests it to be added to `jdk_desktop`. > > Additional testing: > - [x] `jdk_editpad` is passing There is also one such test in the test/hotspot. @prrace Not sure what is the best fix for this. Probably the test automation should run the headful tests from t1/2/3/etc instead of just jdk_desktop? ------------- PR: https://git.openjdk.java.net/jdk/pull/5648 From github.com+741251+turbanoff at openjdk.java.net Thu Sep 23 19:57:13 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Thu, 23 Sep 2021 19:57:13 GMT Subject: RFR: 8274234: Remove unnecessary boxing via primitive wrapper valueOf(String) methods in java.sql.rowset Message-ID: <7_uJwXELLndgUTnEqOpbH5Ip5dcOACXa-AjCJ4LgwHw=.31093f44-0ac9-4a4d-88ab-830033cdfe40@github.com> Usages of methods Integer.valueOf, Byte.valueOf, Short.valueOf, Float.valueOf, Double.valueOf, Long.valueOf often can be simplified by using their pair methods parseInt/parseLong/parseShort/parseByte/parseFloat. ------------- Commit messages: - [PATCH] Remove unnecessary boxing via primitive wrapper valueOf(String) methods in java.sql.rowset Changes: https://git.openjdk.java.net/jdk/pull/5662/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5662&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274234 Stats: 7 lines in 2 files changed: 0 ins; 1 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/5662.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5662/head:pull/5662 PR: https://git.openjdk.java.net/jdk/pull/5662 From github.com+741251+turbanoff at openjdk.java.net Thu Sep 23 20:03:51 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Thu, 23 Sep 2021 20:03:51 GMT Subject: RFR: 8273261: Replace 'while' cycles with iterator with enhanced-for in java.base In-Reply-To: <_l91WAZVqQeJUgX-ZH5CIgHap5TPzIZzI6zYVskXBjI=.ac99b92f-3270-4044-b0fe-d6d48be9d726@github.com> References: <_l91WAZVqQeJUgX-ZH5CIgHap5TPzIZzI6zYVskXBjI=.ac99b92f-3270-4044-b0fe-d6d48be9d726@github.com> Message-ID: <_e35T5mXP9KYSsJNgNSXAwhj7yHLofOe5gG3PuGe7fs=.6f3c7f2d-b7ac-4bab-a791-c2841248c082@github.com> On Wed, 1 Sep 2021 07:37:53 GMT, Andrey Turbanov wrote: > There are few places in code where manual while loop is used with Iterator to iterate over Collection. > Instead of manual while cycles it's preferred to use enhanced-for cycle instead: it's less verbose, makes code easier to read and it's less error-prone. > It doesn't have any performance impact: java compiler generates similar code when compiling enhanced-for cycle. > > Similar cleanups: > * https://bugs.openjdk.java.net/browse/JDK-8258006 > * https://bugs.openjdk.java.net/browse/JDK-8257912 Can someone sponsor changes, please? I believe we have enough approvals. ------------- PR: https://git.openjdk.java.net/jdk/pull/5328 From github.com+741251+turbanoff at openjdk.java.net Thu Sep 23 20:08:58 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Thu, 23 Sep 2021 20:08:58 GMT Subject: Integrated: 8273261: Replace 'while' cycles with iterator with enhanced-for in java.base In-Reply-To: <_l91WAZVqQeJUgX-ZH5CIgHap5TPzIZzI6zYVskXBjI=.ac99b92f-3270-4044-b0fe-d6d48be9d726@github.com> References: <_l91WAZVqQeJUgX-ZH5CIgHap5TPzIZzI6zYVskXBjI=.ac99b92f-3270-4044-b0fe-d6d48be9d726@github.com> Message-ID: On Wed, 1 Sep 2021 07:37:53 GMT, Andrey Turbanov wrote: > There are few places in code where manual while loop is used with Iterator to iterate over Collection. > Instead of manual while cycles it's preferred to use enhanced-for cycle instead: it's less verbose, makes code easier to read and it's less error-prone. > It doesn't have any performance impact: java compiler generates similar code when compiling enhanced-for cycle. > > Similar cleanups: > * https://bugs.openjdk.java.net/browse/JDK-8258006 > * https://bugs.openjdk.java.net/browse/JDK-8257912 This pull request has now been integrated. Changeset: 56b8b352 Author: Andrey Turbanov Committer: Roger Riggs URL: https://git.openjdk.java.net/jdk/commit/56b8b35286634f2d2224ca445bc9f32ff284ae74 Stats: 93 lines in 11 files changed: 1 ins; 50 del; 42 mod 8273261: Replace 'while' cycles with iterator with enhanced-for in java.base Reviewed-by: dfuchs, rriggs, iris, mullan ------------- PR: https://git.openjdk.java.net/jdk/pull/5328 From herrick at openjdk.java.net Thu Sep 23 20:13:06 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Thu, 23 Sep 2021 20:13:06 GMT Subject: RFR: JDK-8274087: Windows DLL path not set correctly. Message-ID: JDK-8274087: Windows DLL path not set correctly. ------------- Commit messages: - JDK-8274087: Windows DLL path not set correctly. Changes: https://git.openjdk.java.net/jdk/pull/5663/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5663&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274087 Stats: 5 lines in 1 file changed: 2 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5663.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5663/head:pull/5663 PR: https://git.openjdk.java.net/jdk/pull/5663 From almatvee at openjdk.java.net Thu Sep 23 21:15:53 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Thu, 23 Sep 2021 21:15:53 GMT Subject: RFR: JDK-8274087: Windows DLL path not set correctly. In-Reply-To: References: Message-ID: On Thu, 23 Sep 2021 20:03:29 GMT, Andy Herrick wrote: > JDK-8274087: Windows DLL path not set correctly. Marked as reviewed by almatvee (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5663 From lancea at openjdk.java.net Thu Sep 23 21:23:51 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 23 Sep 2021 21:23:51 GMT Subject: RFR: 8274234: Remove unnecessary boxing via primitive wrapper valueOf(String) methods in java.sql.rowset In-Reply-To: <7_uJwXELLndgUTnEqOpbH5Ip5dcOACXa-AjCJ4LgwHw=.31093f44-0ac9-4a4d-88ab-830033cdfe40@github.com> References: <7_uJwXELLndgUTnEqOpbH5Ip5dcOACXa-AjCJ4LgwHw=.31093f44-0ac9-4a4d-88ab-830033cdfe40@github.com> Message-ID: On Thu, 23 Sep 2021 19:47:51 GMT, Andrey Turbanov wrote: > Usages of methods Integer.valueOf, Byte.valueOf, Short.valueOf, Float.valueOf, Double.valueOf, Long.valueOf often can be simplified by using their pair methods parseInt/parseLong/parseShort/parseByte/parseFloat. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5662 From bpb at openjdk.java.net Thu Sep 23 21:41:51 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 23 Sep 2021 21:41:51 GMT Subject: RFR: 8274234: Remove unnecessary boxing via primitive wrapper valueOf(String) methods in java.sql.rowset In-Reply-To: <7_uJwXELLndgUTnEqOpbH5Ip5dcOACXa-AjCJ4LgwHw=.31093f44-0ac9-4a4d-88ab-830033cdfe40@github.com> References: <7_uJwXELLndgUTnEqOpbH5Ip5dcOACXa-AjCJ4LgwHw=.31093f44-0ac9-4a4d-88ab-830033cdfe40@github.com> Message-ID: On Thu, 23 Sep 2021 19:47:51 GMT, Andrey Turbanov wrote: > Usages of methods Integer.valueOf, Byte.valueOf, Short.valueOf, Float.valueOf, Double.valueOf, Long.valueOf often can be simplified by using their pair methods parseInt/parseLong/parseShort/parseByte/parseFloat. Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5662 From asemenyuk at openjdk.java.net Thu Sep 23 22:16:54 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Thu, 23 Sep 2021 22:16:54 GMT Subject: RFR: JDK-8274087: Windows DLL path not set correctly. In-Reply-To: References: Message-ID: On Thu, 23 Sep 2021 20:03:29 GMT, Andy Herrick wrote: > JDK-8274087: Windows DLL path not set correctly. Marked as reviewed by asemenyuk (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5663 From coleenp at openjdk.java.net Thu Sep 23 22:38:52 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 23 Sep 2021 22:38:52 GMT Subject: RFR: 8266936: Add a finalization JFR event [v11] In-Reply-To: <3hNX4mQ98TyLNDmCXO4hDz8EMDoQ4ukr1Y1bvX1k8kk=.cc67221c-258a-4cac-a368-09d5fe44f245@github.com> References: <3hNX4mQ98TyLNDmCXO4hDz8EMDoQ4ukr1Y1bvX1k8kk=.cc67221c-258a-4cac-a368-09d5fe44f245@github.com> Message-ID: On Mon, 13 Sep 2021 17:12:49 GMT, Markus Gr?nlund wrote: >> Greetings, >> >> Object.finalize() was deprecated in JDK9. There is an ongoing effort to replace and mitigate Object.finalize() uses in the JDK libraries; please see https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. >> >> We also like to assist users in replacing and mitigating uses in non-JDK code. >> >> Hence, this changeset adds a periodic JFR event to help identify which classes are overriding Object.finalize(). >> >> Thanks >> Markus > > Markus Gr?nlund has updated the pull request incrementally with two additional commits since the last revision: > > - remove rehashing and rely on default grow_hint for table resize > - mtStatistics src/hotspot/share/jfr/periodic/jfrFinalizerStatisticsEvent.cpp line 26: > 24: > 25: #include "precompiled.hpp" > 26: #if INCLUDE_MANAGEMENT With precompiled headers turned off, this gets a compilation error: error: "INCLUDE_MANAGEMENT" is not defined, evaluates to 0 [-Werror=undef] ------------- PR: https://git.openjdk.java.net/jdk/pull/4731 From github.com+53162078+shiyuexw at openjdk.java.net Fri Sep 24 01:55:52 2021 From: github.com+53162078+shiyuexw at openjdk.java.net (wxiang) Date: Fri, 24 Sep 2021 01:55:52 GMT Subject: RFR: 8273401: Disable JarIndex support in URLClassPath [v2] In-Reply-To: <6AgDFIsZRfYJkh78ZdEGInPHOjeJwvJbHopeuEq79Lc=.2e0d84db-85a1-484f-8da9-090878da6a38@github.com> References: <7fXVoIjSmGliERuXW2VgnPMcywMRPv_3lhGL01IMRwI=.5d8e4020-8719-4b23-a303-9f311bbc5961@github.com> <6AgDFIsZRfYJkh78ZdEGInPHOjeJwvJbHopeuEq79Lc=.2e0d84db-85a1-484f-8da9-090878da6a38@github.com> Message-ID: On Thu, 16 Sep 2021 01:29:41 GMT, wxiang wrote: >> wxiang has updated the pull request incrementally with one additional commit since the last revision: >> >> add isEmpty check > > I have changed > > ENABLE_JAR_INDEX = p != null ? p.equals("true") : false; > > to > > ENABLE_JAR_INDEX = p != null ? p.equals("true") || p.isEmpty() : false; > > > Furthemore, in order to maintain consistency in URLClassPath, the property name is "jdk.net.URLClassPath.enableJarIndex" . > @shiyuexw Just a reminder that you need to finalize the CSR. Thanks a lot. We have finalized the CSR. ------------- PR: https://git.openjdk.java.net/jdk/pull/5524 From amaembo at gmail.com Fri Sep 24 02:13:05 2021 From: amaembo at gmail.com (Tagir Valeev) Date: Fri, 24 Sep 2021 09:13:05 +0700 Subject: How can I trigger a @Serial warning? In-Reply-To: <2f2afdb5-c5a0-0cce-a492-8d589b8f058a@gmail.com> References: <2f2afdb5-c5a0-0cce-a492-8d589b8f058a@gmail.com> Message-ID: Hello, Cay! By the way, in IntelliJ IDEA we have the inspection that warns you about wrong use of Serial: [image: image.png] It also suggests adding this annotation where it's appropriate: [image: image.png] Both inspections are turned on by default. With best regards, Tagir Valeev. On Thu, Sep 9, 2021 at 2:47 PM Cay Horstmann wrote: > I am trying to give an example of the utility of the @Serial annotation. > But the JDK 17 javac doesn't seem to do anything with it. I tried: > > @Serial private void readObject(java.io.ObjectInputStream stream, int > shouldNotHaveThisParam) throws IOException, ClassNotFoundException > @Serial private static final String serialVersionUID = "Fred"; > @Serial public String getName() { ... } > > Is there some flag that I need to use? I tried -Xlint:serial, but it > didn't make a difference. > > Thanks, > > Cay > > -- > > Cay S. Horstmann | http://horstmann.com | mailto:cay at horstmann.com > From mgronlun at openjdk.java.net Fri Sep 24 09:27:05 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Fri, 24 Sep 2021 09:27:05 GMT Subject: RFR: 8266936: Add a finalization JFR event [v11] In-Reply-To: References: <3hNX4mQ98TyLNDmCXO4hDz8EMDoQ4ukr1Y1bvX1k8kk=.cc67221c-258a-4cac-a368-09d5fe44f245@github.com> Message-ID: On Thu, 23 Sep 2021 22:35:26 GMT, Coleen Phillimore wrote: >> Markus Gr?nlund has updated the pull request incrementally with two additional commits since the last revision: >> >> - remove rehashing and rely on default grow_hint for table resize >> - mtStatistics > > src/hotspot/share/jfr/periodic/jfrFinalizerStatisticsEvent.cpp line 26: > >> 24: >> 25: #include "precompiled.hpp" >> 26: #if INCLUDE_MANAGEMENT > > With precompiled headers turned off, this gets a compilation error: > error: "INCLUDE_MANAGEMENT" is not > defined, evaluates to 0 [-Werror=undef] Thanks, I missed submitting a few no-precompiled header builds. Fixed now. ------------- PR: https://git.openjdk.java.net/jdk/pull/4731 From mgronlun at openjdk.java.net Fri Sep 24 09:27:02 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Fri, 24 Sep 2021 09:27:02 GMT Subject: RFR: 8266936: Add a finalization JFR event [v12] In-Reply-To: References: Message-ID: <7qUo6JdWeitC5Tw90sAEdokNLL1B0cp7nU8pBRLFoOc=.9d912b5c-41f6-42cd-a393-85f46daad623@github.com> > Greetings, > > Object.finalize() was deprecated in JDK9. There is an ongoing effort to replace and mitigate Object.finalize() uses in the JDK libraries; please see https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. > > We also like to assist users in replacing and mitigating uses in non-JDK code. > > Hence, this changeset adds a periodic JFR event to help identify which classes are overriding Object.finalize(). > > Thanks > Markus Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: no precompiled headers and mtServiceability nmt classification ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4731/files - new: https://git.openjdk.java.net/jdk/pull/4731/files/62592daf..5759c605 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=10-11 Stats: 9 lines in 4 files changed: 4 ins; 2 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/4731.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4731/head:pull/4731 PR: https://git.openjdk.java.net/jdk/pull/4731 From github.com+10835776+stsypanov at openjdk.java.net Fri Sep 24 10:43:08 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Fri, 24 Sep 2021 10:43:08 GMT Subject: RFR: 8274276: Cache normalizedBase URL in URLClassPath.FileLoader Message-ID: Currently on each invocation of `URLClassPath.FileLoader.getResource()` `normalizedBase` URL is recalculated using same final `baseURL` from parent class. This can be avoided giving significant improvement in memory consumption. Consider the benchmark: @State(Scope.Benchmark) @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) public class URLClassPathBenchmark { private final ClassLoader classLoader = getClass().getClassLoader(); @Benchmark public URL getResource() { return classLoader.getResource("file:./config/application.properties"); } } it demonstrates improvement brought in by this patch: before Benchmark Mode Cnt Score Error Units URLClassPathBenchmark.getResource avgt 50 2840,746 ? 22,206 ns/op URLClassPathBenchmark.getResource:?gc.alloc.rate avgt 50 645,313 ? 8,072 MB/sec URLClassPathBenchmark.getResource:?gc.alloc.rate.norm avgt 50 2403,258 ? 17,639 B/op URLClassPathBenchmark.getResource:?gc.churn.G1_Eden_Space avgt 50 656,624 ? 116,090 MB/sec URLClassPathBenchmark.getResource:?gc.churn.G1_Eden_Space.norm avgt 50 2450,175 ? 440,011 B/op URLClassPathBenchmark.getResource:?gc.churn.G1_Survivor_Space avgt 50 0,123 ? 0,149 MB/sec URLClassPathBenchmark.getResource:?gc.churn.G1_Survivor_Space.norm avgt 50 0,459 ? 0,556 B/op URLClassPathBenchmark.getResource:?gc.count avgt 50 67,000 counts URLClassPathBenchmark.getResource:?gc.time avgt 50 117,000 ms after Benchmark Mode Cnt Score Error Units URLClassPathBenchmark.getResource avgt 100 2596,719 ? 9,786 ns/op URLClassPathBenchmark.getResource:?gc.alloc.rate avgt 100 448,780 ? 1,684 MB/sec URLClassPathBenchmark.getResource:?gc.alloc.rate.norm avgt 100 1528,040 ? 0,005 B/op URLClassPathBenchmark.getResource:?gc.churn.G1_Eden_Space avgt 100 479,905 ? 23,369 MB/sec URLClassPathBenchmark.getResource:?gc.churn.G1_Eden_Space.norm avgt 100 1634,314 ? 79,821 B/op URLClassPathBenchmark.getResource:?gc.churn.G1_Survivor_Space avgt 100 0,101 ? 0,097 MB/sec URLClassPathBenchmark.getResource:?gc.churn.G1_Survivor_Space.norm avgt 100 0,345 ? 0,329 B/op URLClassPathBenchmark.getResource:?gc.count avgt 100 98,000 counts URLClassPathBenchmark.getResource:?gc.time avgt 100 218,000 ms ------------- Commit messages: - 8274276: Cache normalizedBase URL in URLClassPath.FileLoader Changes: https://git.openjdk.java.net/jdk/pull/5677/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5677&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274276 Stats: 4 lines in 1 file changed: 2 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5677.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5677/head:pull/5677 PR: https://git.openjdk.java.net/jdk/pull/5677 From dfuchs at openjdk.java.net Fri Sep 24 11:16:51 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 24 Sep 2021 11:16:51 GMT Subject: RFR: 8274276: Cache normalizedBase URL in URLClassPath.FileLoader In-Reply-To: References: Message-ID: On Fri, 24 Sep 2021 10:35:54 GMT, ?????? ??????? wrote: > Currently on each invocation of `URLClassPath.FileLoader.getResource()` `normalizedBase` URL is recalculated using same final `baseURL` from parent class. This can be avoided giving significant improvement in memory consumption. Consider the benchmark: > > @State(Scope.Benchmark) > @BenchmarkMode(Mode.AverageTime) > @OutputTimeUnit(TimeUnit.NANOSECONDS) > @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) > public class URLClassPathBenchmark { > private final ClassLoader classLoader = getClass().getClassLoader(); > > @Benchmark > public URL getResource() { > return classLoader.getResource("file:./config/application.properties"); > } > } > > it demonstrates improvement brought in by this patch: > > before > Benchmark Mode Cnt Score Error Units > URLClassPathBenchmark.getResource avgt 50 2840,746 ? 22,206 ns/op > URLClassPathBenchmark.getResource:?gc.alloc.rate avgt 50 645,313 ? 8,072 MB/sec > URLClassPathBenchmark.getResource:?gc.alloc.rate.norm avgt 50 2403,258 ? 17,639 B/op > URLClassPathBenchmark.getResource:?gc.churn.G1_Eden_Space avgt 50 656,624 ? 116,090 MB/sec > URLClassPathBenchmark.getResource:?gc.churn.G1_Eden_Space.norm avgt 50 2450,175 ? 440,011 B/op > URLClassPathBenchmark.getResource:?gc.churn.G1_Survivor_Space avgt 50 0,123 ? 0,149 MB/sec > URLClassPathBenchmark.getResource:?gc.churn.G1_Survivor_Space.norm avgt 50 0,459 ? 0,556 B/op > URLClassPathBenchmark.getResource:?gc.count avgt 50 67,000 counts > URLClassPathBenchmark.getResource:?gc.time avgt 50 117,000 ms > > after > Benchmark Mode Cnt Score Error Units > URLClassPathBenchmark.getResource avgt 100 2596,719 ? 9,786 ns/op > URLClassPathBenchmark.getResource:?gc.alloc.rate avgt 100 448,780 ? 1,684 MB/sec > URLClassPathBenchmark.getResource:?gc.alloc.rate.norm avgt 100 1528,040 ? 0,005 B/op > URLClassPathBenchmark.getResource:?gc.churn.G1_Eden_Space avgt 100 479,905 ? 23,369 MB/sec > URLClassPathBenchmark.getResource:?gc.churn.G1_Eden_Space.norm avgt 100 1634,314 ? 79,821 B/op > URLClassPathBenchmark.getResource:?gc.churn.G1_Survivor_Space avgt 100 0,101 ? 0,097 MB/sec > URLClassPathBenchmark.getResource:?gc.churn.G1_Survivor_Space.norm avgt 100 0,345 ? 0,329 B/op > URLClassPathBenchmark.getResource:?gc.count avgt 100 98,000 counts > URLClassPathBenchmark.getResource:?gc.time avgt 100 218,000 ms This is calling an overidable method within a constructor, which might have unforeseen side effects. Can you make `Loader::getBaseURL` final? That would remove the concern. ------------- PR: https://git.openjdk.java.net/jdk/pull/5677 From myano at openjdk.java.net Fri Sep 24 11:36:08 2021 From: myano at openjdk.java.net (Masanori Yano) Date: Fri, 24 Sep 2021 11:36:08 GMT Subject: RFR: 8250678: ModuleDescriptor.Version parsing treats empty segments inconsistently Message-ID: <5FwhmsS85upnfXAKPCBCQTsWorJN17vOBFZXCN6iP8M=.377740a1-6f1e-4e37-9344-25a60ffdd891@github.com> Could you please review the 8250678 bug fixes? 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/jdk18/docs/api/java.base/java/lang/module/ModuleDescriptor.Version.html Therefore, I propose to fix the parsing method of pre and build section in the same way as the version. ------------- Commit messages: - 8250678: ModuleDescriptor.Version parsing treats empty segments inconsistently Changes: https://git.openjdk.java.net/jdk/pull/5679/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5679&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8250678 Stats: 26 lines in 2 files changed: 11 ins; 14 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5679.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5679/head:pull/5679 PR: https://git.openjdk.java.net/jdk/pull/5679 From github.com+10835776+stsypanov at openjdk.java.net Fri Sep 24 11:50:21 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Fri, 24 Sep 2021 11:50:21 GMT Subject: RFR: 8274276: Cache normalizedBase URL in URLClassPath.FileLoader [v2] In-Reply-To: References: Message-ID: > Currently on each invocation of `URLClassPath.FileLoader.getResource()` `normalizedBase` URL is recalculated using same final `baseURL` from parent class. This can be avoided giving significant improvement in memory consumption. Consider the benchmark: > > @State(Scope.Benchmark) > @BenchmarkMode(Mode.AverageTime) > @OutputTimeUnit(TimeUnit.NANOSECONDS) > @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) > public class URLClassPathBenchmark { > private final ClassLoader classLoader = getClass().getClassLoader(); > > @Benchmark > public URL getResource() { > return classLoader.getResource("file:./config/application.properties"); > } > } > > it demonstrates improvement brought in by this patch: > > before > Benchmark Mode Cnt Score Error Units > URLClassPathBenchmark.getResource avgt 50 2840,746 ? 22,206 ns/op > URLClassPathBenchmark.getResource:?gc.alloc.rate avgt 50 645,313 ? 8,072 MB/sec > URLClassPathBenchmark.getResource:?gc.alloc.rate.norm avgt 50 2403,258 ? 17,639 B/op > URLClassPathBenchmark.getResource:?gc.churn.G1_Eden_Space avgt 50 656,624 ? 116,090 MB/sec > URLClassPathBenchmark.getResource:?gc.churn.G1_Eden_Space.norm avgt 50 2450,175 ? 440,011 B/op > URLClassPathBenchmark.getResource:?gc.churn.G1_Survivor_Space avgt 50 0,123 ? 0,149 MB/sec > URLClassPathBenchmark.getResource:?gc.churn.G1_Survivor_Space.norm avgt 50 0,459 ? 0,556 B/op > URLClassPathBenchmark.getResource:?gc.count avgt 50 67,000 counts > URLClassPathBenchmark.getResource:?gc.time avgt 50 117,000 ms > > after > Benchmark Mode Cnt Score Error Units > URLClassPathBenchmark.getResource avgt 100 2596,719 ? 9,786 ns/op > URLClassPathBenchmark.getResource:?gc.alloc.rate avgt 100 448,780 ? 1,684 MB/sec > URLClassPathBenchmark.getResource:?gc.alloc.rate.norm avgt 100 1528,040 ? 0,005 B/op > URLClassPathBenchmark.getResource:?gc.churn.G1_Eden_Space avgt 100 479,905 ? 23,369 MB/sec > URLClassPathBenchmark.getResource:?gc.churn.G1_Eden_Space.norm avgt 100 1634,314 ? 79,821 B/op > URLClassPathBenchmark.getResource:?gc.churn.G1_Survivor_Space avgt 100 0,101 ? 0,097 MB/sec > URLClassPathBenchmark.getResource:?gc.churn.G1_Survivor_Space.norm avgt 100 0,345 ? 0,329 B/op > URLClassPathBenchmark.getResource:?gc.count avgt 100 98,000 counts > URLClassPathBenchmark.getResource:?gc.time avgt 100 218,000 ms ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: 8274276: Make URLClassPath.Loader.getBaseURL() final ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5677/files - new: https://git.openjdk.java.net/jdk/pull/5677/files/dffc3301..937e6aee Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5677&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5677&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5677.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5677/head:pull/5677 PR: https://git.openjdk.java.net/jdk/pull/5677 From github.com+10835776+stsypanov at openjdk.java.net Fri Sep 24 11:50:23 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Fri, 24 Sep 2021 11:50:23 GMT Subject: RFR: 8274276: Cache normalizedBase URL in URLClassPath.FileLoader [v2] In-Reply-To: References: Message-ID: <_lM4ErdqkIRd3iLMZpzlSuHePnLBH3fbWGg5UjTeBoc=.6133dd48-98c3-4b0e-aa6e-0b7fd871ef7f@github.com> On Fri, 24 Sep 2021 11:14:00 GMT, Daniel Fuchs wrote: >> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: >> >> 8274276: Make URLClassPath.Loader.getBaseURL() final > > This is calling an overidable method within a constructor, which might have unforeseen side effects. Can you make `Loader::getBaseURL` final? That would remove the concern. @dfuch Sure, done! ------------- PR: https://git.openjdk.java.net/jdk/pull/5677 From herrick at openjdk.java.net Fri Sep 24 12:47:03 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Fri, 24 Sep 2021 12:47:03 GMT Subject: Integrated: JDK-8274087: Windows DLL path not set correctly. In-Reply-To: References: Message-ID: On Thu, 23 Sep 2021 20:03:29 GMT, Andy Herrick wrote: > JDK-8274087: Windows DLL path not set correctly. This pull request has now been integrated. Changeset: f36a2bbd Author: Andy Herrick URL: https://git.openjdk.java.net/jdk/commit/f36a2bbd15d94d4371c2117ce08b7f04a0d59da4 Stats: 5 lines in 1 file changed: 2 ins; 2 del; 1 mod 8274087: Windows DLL path not set correctly. Reviewed-by: almatvee, asemenyuk ------------- PR: https://git.openjdk.java.net/jdk/pull/5663 From github.com+741251+turbanoff at openjdk.java.net Fri Sep 24 14:12:58 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Fri, 24 Sep 2021 14:12:58 GMT Subject: Integrated: 8274234: Remove unnecessary boxing via primitive wrapper valueOf(String) methods in java.sql.rowset In-Reply-To: <7_uJwXELLndgUTnEqOpbH5Ip5dcOACXa-AjCJ4LgwHw=.31093f44-0ac9-4a4d-88ab-830033cdfe40@github.com> References: <7_uJwXELLndgUTnEqOpbH5Ip5dcOACXa-AjCJ4LgwHw=.31093f44-0ac9-4a4d-88ab-830033cdfe40@github.com> Message-ID: On Thu, 23 Sep 2021 19:47:51 GMT, Andrey Turbanov wrote: > Usages of methods Integer.valueOf, Byte.valueOf, Short.valueOf, Float.valueOf, Double.valueOf, Long.valueOf often can be simplified by using their pair methods parseInt/parseLong/parseShort/parseByte/parseFloat. This pull request has now been integrated. Changeset: f214d6e8 Author: Andrey Turbanov Committer: Lance Andersen URL: https://git.openjdk.java.net/jdk/commit/f214d6e8736a620c8e1b87c30587aa0977cccc4c Stats: 7 lines in 2 files changed: 0 ins; 1 del; 6 mod 8274234: Remove unnecessary boxing via primitive wrapper valueOf(String) methods in java.sql.rowset Reviewed-by: lancea, bpb ------------- PR: https://git.openjdk.java.net/jdk/pull/5662 From github.com+214207+marcphilipp at openjdk.java.net Fri Sep 24 14:42:01 2021 From: github.com+214207+marcphilipp at openjdk.java.net (Marc Philipp) Date: Fri, 24 Sep 2021 14:42:01 GMT Subject: RFR: 8253702: BigSur version number reported as 10.16, should be 11.nn [v3] In-Reply-To: References: Message-ID: On Thu, 11 Feb 2021 19:23:55 GMT, Roger Riggs wrote: >> On Mac Os X, the OSVersionTest detected a difference in the version number reported in the os.version property >> and the version number provided by `sw_vers -productVersion`. >> >> When the java runtime is built with XCode 11.3, the os.version is reported as 10.16 >> though the current version numbering is 11.nnn. >> >> The workaround is to derive the os.version number from the ProductBuildVersion. >> When the toolchain is updated to XCode 12.nnn it can be removed. >> The workaround is enabled only when the environment variable SYSTEM_VERSION_COMPAT is unset. >> When the SYSTEM_VERSION_COMPAT is set in the environment the version number is reported as reported by Mac OS X. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > optimize case of 10.16 and SYSTEM_VERSION_COMPAT is set With macOS 11.6 this fix no longer works. @sormuras will create a proper bug report. ?? ------------- PR: https://git.openjdk.java.net/jdk/pull/2530 From clanger at openjdk.java.net Fri Sep 24 14:42:02 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Fri, 24 Sep 2021 14:42:02 GMT Subject: RFR: 8253702: BigSur version number reported as 10.16, should be 11.nn [v3] In-Reply-To: References: Message-ID: On Thu, 11 Feb 2021 19:23:55 GMT, Roger Riggs wrote: >> On Mac Os X, the OSVersionTest detected a difference in the version number reported in the os.version property >> and the version number provided by `sw_vers -productVersion`. >> >> When the java runtime is built with XCode 11.3, the os.version is reported as 10.16 >> though the current version numbering is 11.nnn. >> >> The workaround is to derive the os.version number from the ProductBuildVersion. >> When the toolchain is updated to XCode 12.nnn it can be removed. >> The workaround is enabled only when the environment variable SYSTEM_VERSION_COMPAT is unset. >> When the SYSTEM_VERSION_COMPAT is set in the environment the version number is reported as reported by Mac OS X. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > optimize case of 10.16 and SYSTEM_VERSION_COMPAT is set Hi Marc, cc @sormuras, not necessary, it was already reported & fixed: https://bugs.openjdk.java.net/browse/JDK-8269850 ?? Cheers Christoph ------------- PR: https://git.openjdk.java.net/jdk/pull/2530 From github.com+214207+marcphilipp at openjdk.java.net Fri Sep 24 14:49:49 2021 From: github.com+214207+marcphilipp at openjdk.java.net (Marc Philipp) Date: Fri, 24 Sep 2021 14:49:49 GMT Subject: RFR: 8253702: BigSur version number reported as 10.16, should be 11.nn [v3] In-Reply-To: References: Message-ID: On Thu, 11 Feb 2021 19:23:55 GMT, Roger Riggs wrote: >> On Mac Os X, the OSVersionTest detected a difference in the version number reported in the os.version property >> and the version number provided by `sw_vers -productVersion`. >> >> When the java runtime is built with XCode 11.3, the os.version is reported as 10.16 >> though the current version numbering is 11.nnn. >> >> The workaround is to derive the os.version number from the ProductBuildVersion. >> When the toolchain is updated to XCode 12.nnn it can be removed. >> The workaround is enabled only when the environment variable SYSTEM_VERSION_COMPAT is unset. >> When the SYSTEM_VERSION_COMPAT is set in the environment the version number is reported as reported by Mac OS X. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > optimize case of 10.16 and SYSTEM_VERSION_COMPAT is set Thanks! I searched the bug tracker but couldn't find it. Will that be backported to JDK 11 and/or 17? ------------- PR: https://git.openjdk.java.net/jdk/pull/2530 From jpai at openjdk.java.net Fri Sep 24 14:49:54 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Fri, 24 Sep 2021 14:49:54 GMT Subject: RFR: 8273790: Potential cyclic dependencies between Gregorian and CalendarSystem Message-ID: Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.java.net/browse/JDK-8273790? As noted in that issue, trying to class load `sun.util.calendar.CalendarSystem` and `sun.util.calendar.Gregorian` concurrently in separate threads can lead to a deadlock because of the cyclic nature of the code in their static initialization. More specifically, consider this case: - Thread T1 initiates a classload on the `sun.util.calendar.CalendarSystem`. - This gives T1 the implicit class init lock on `CalendarSystem`. - Consider thread T2 which at the same time initiates a classload on `sun.util.calendar.Gregorian` class. - This gives T2 a implicit class init lock on `Gregorian`. - T1, still holding a lock on `CalendarSystem` attempts to load `Gregorian` since it wants to create a (singleton) instance of `Gregorian` and assign it to the `static final GREGORIAN_INSTANCE` member. Since T2 is holding a class init lock on `Gregorian`, T1 ends up waiting - T2 on the other hand is still loading the `Gregorian` class. `Gregorian` itself "is a" `CalendarSystem`, so during this loading of `Gregorian` class, T2 starts travelling up the class hierarchy and asks for a lock on `CalendarSystem`. However T1 is holding this lock and as a result T2 ends up waiting on T1 which is waiting on T2. That triggers this deadlock. The linked JBS issue has a thread dump which shows this in action. The commit here delays the instance creation of `Gregorian` by moving that instance creation logic from the static initialization of the `CalendarSystem` class, to the first call to `CalendarSystem#getGregorianCalendar()`. This prevents the `CalendarSystem` from needing a lock on `Gregorian` during its static init (of course, unless some code in this static init flow calls `CalendarSystem#getGregorianCalendar()`, in which case it is back to square one. I have verified, both manually and through the jtreg test, that the code in question doesn't have such calls) A new jtreg test has been introduced to reproduce the issue and verify the fix. The test in addition to loading these 2 classes in question, also additionally loads a few other classes concurrently. These classes have specific static initialization which leads the calls to `CalendarSystem#getGregorianCalendar()` or `CalendarSystem#forName()`. Including these classes in the tests ensures that this deadlock hasn't "moved" to a different location. I have run multiple runs (approximately 25) of this test with the fix and I haven't seen it deadlock anymore. ------------- Commit messages: - 8273790: Potential cyclic dependencies between Gregorian and CalendarSystem Changes: https://git.openjdk.java.net/jdk/pull/5683/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5683&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273790 Stats: 185 lines in 2 files changed: 181 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/5683.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5683/head:pull/5683 PR: https://git.openjdk.java.net/jdk/pull/5683 From clanger at openjdk.java.net Fri Sep 24 14:54:28 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Fri, 24 Sep 2021 14:54:28 GMT Subject: RFR: 8253702: BigSur version number reported as 10.16, should be 11.nn [v3] In-Reply-To: References: Message-ID: <_MT9QlGE4SC6QKh27txQFx1TS8tOHcvLb17B7xfUrLk=.4109de02-b860-4358-b785-2934ab53991d@github.com> On Thu, 11 Feb 2021 19:23:55 GMT, Roger Riggs wrote: >> On Mac Os X, the OSVersionTest detected a difference in the version number reported in the os.version property >> and the version number provided by `sw_vers -productVersion`. >> >> When the java runtime is built with XCode 11.3, the os.version is reported as 10.16 >> though the current version numbering is 11.nnn. >> >> The workaround is to derive the os.version number from the ProductBuildVersion. >> When the toolchain is updated to XCode 12.nnn it can be removed. >> The workaround is enabled only when the environment variable SYSTEM_VERSION_COMPAT is unset. >> When the SYSTEM_VERSION_COMPAT is set in the environment the version number is reported as reported by Mac OS X. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > optimize case of 10.16 and SYSTEM_VERSION_COMPAT is set Yup: https://github.com/openjdk/jdk17u/pull/85 https://github.com/openjdk/jdk11u/pull/12 For OpenJDK 11u I hope to get it into the October Update. Can't speak for 17u as this is maintained by Oracle. Maybe @sormuras can help here :) ------------- PR: https://git.openjdk.java.net/jdk/pull/2530 From redestad at openjdk.java.net Fri Sep 24 16:04:08 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 24 Sep 2021 16:04:08 GMT Subject: RFR: 8274242: Implement fast-path for ASCII-compatible CharsetEncoders on x86 In-Reply-To: References: Message-ID: On Tue, 21 Sep 2021 21:58:48 GMT, Claes Redestad wrote: > This patch extends the `ISO_8859_1.implEncodeISOArray` intrinsic on x86 to work also for ASCII encoding, which makes for example the `UTF_8$Encoder` perform on par with (or outperform) similarly getting charset encoded bytes from a String. The former took a small performance hit in JDK 9, and the latter improved greatly in the same release. > > Extending the `EncodeIsoArray` intrinsics on other platforms should be possible, but I'm unfamiliar with the macro assembler in general and unlike the x86 intrinsic they don't use a simple vectorized mask to implement the latin-1 check. For example aarch64 seem to filter out the low bytes and then check if there's any bits set in the high bytes. Clever, but very different to the 0xFF80 2-byte mask that an ASCII test wants. The current version (cef05f4) copies the ISO_8859_1.implEncodeISOArray intrinsic and adapts it to work on ASCII encoding, which makes the UTF_8$Encoder perform on par with (or outperform) encoding from a String. Using microbenchmarks provided by @carterkozak here: https://github.com/carterkozak/stringbuilder-encoding-performance Baseline: Benchmark (charsetName) (message) (timesToAppend) Mode Cnt Score Error Units EncoderBenchmarks.charsetEncoder UTF-8 This is a simple ASCII message 3 avgt 8 270.237 ? 10.504 ns/op EncoderBenchmarks.charsetEncoder UTF-8 This is a message with unicode ?? 3 avgt 8 568.353 ? 2.331 ns/op EncoderBenchmarks.charsetEncoderWithAllocation UTF-8 This is a simple ASCII message 3 avgt 8 324.889 ? 17.466 ns/op EncoderBenchmarks.charsetEncoderWithAllocation UTF-8 This is a message with unicode ?? 3 avgt 8 633.720 ? 22.703 ns/op EncoderBenchmarks.charsetEncoderWithAllocationWrappingBuilder UTF-8 This is a simple ASCII message 3 avgt 8 1132.436 ? 30.661 ns/op EncoderBenchmarks.charsetEncoderWithAllocationWrappingBuilder UTF-8 This is a message with unicode ?? 3 avgt 8 1379.207 ? 66.982 ns/op EncoderBenchmarks.toStringGetBytes UTF-8 This is a simple ASCII message 3 avgt 8 91.253 ? 3.848 ns/op EncoderBenchmarks.toStringGetBytes UTF-8 This is a message with unicode ?? 3 avgt 8 519.489 ? 12.516 ns/op Patch: Benchmark (charsetName) (message) (timesToAppend) Mode Cnt Score Error Units EncoderBenchmarks.charsetEncoder UTF-8 This is a simple ASCII message 3 avgt 4 82.535 ? 20.310 ns/op EncoderBenchmarks.charsetEncoder UTF-8 This is a message with unicode ?? 3 avgt 4 522.679 ? 13.456 ns/op EncoderBenchmarks.charsetEncoderWithAllocation UTF-8 This is a simple ASCII message 3 avgt 4 127.831 ? 32.612 ns/op EncoderBenchmarks.charsetEncoderWithAllocation UTF-8 This is a message with unicode ?? 3 avgt 4 549.343 ? 59.899 ns/op EncoderBenchmarks.charsetEncoderWithAllocationWrappingBuilder UTF-8 This is a simple ASCII message 3 avgt 4 1182.835 ? 153.735 ns/op EncoderBenchmarks.charsetEncoderWithAllocationWrappingBuilder UTF-8 This is a message with unicode ?? 3 avgt 4 1416.407 ? 130.551 ns/op EncoderBenchmarks.toStringGetBytes UTF-8 This is a simple ASCII message 3 avgt 4 97.770 ? 15.742 ns/op EncoderBenchmarks.toStringGetBytes UTF-8 This is a message with unicode ?? 3 avgt 4 516.351 ? 58.580 ns/op This can probably be simplified further, say by adding a flag to the intrinsic of whether we're encoding ASCII only or ISO-8859-1. It also needs to be implemented and tested on all architectures. (edit: accidentally edit rather than quote-reply, restored original comment) On the JDK-included `CharsetEncodeDecode.encode` microbenchmark, I get these numbers in the baseline (18-b09): Benchmark (size) (type) Mode Cnt Score Error Units CharsetEncodeDecode.encode 16384 UTF-8 avgt 30 39.962 ? 1.703 us/op CharsetEncodeDecode.encode 16384 BIG5 avgt 30 153.282 ? 4.521 us/op CharsetEncodeDecode.encode 16384 ISO-8859-15 avgt 30 192.040 ? 4.543 us/op CharsetEncodeDecode.encode 16384 ASCII avgt 30 40.051 ? 1.210 us/op CharsetEncodeDecode.encode 16384 UTF-16 avgt 30 302.815 ? 9.490 us/op With the proposed patch: Benchmark (size) (type) Mode Cnt Score Error Units CharsetEncodeDecode.encode 16384 UTF-8 avgt 30 4.081 ? 0.182 us/op CharsetEncodeDecode.encode 16384 BIG5 avgt 30 150.374 ? 3.579 us/op CharsetEncodeDecode.encode 16384 ISO-8859-15 avgt 30 4.010 ? 0.179 us/op CharsetEncodeDecode.encode 16384 ASCII avgt 30 3.961 ? 0.176 us/op CharsetEncodeDecode.encode 16384 UTF-16 avgt 30 302.235 ? 11.395 us/op That is: on my system encoding 16K char ASCII data is 10x faster for UTF-8 and ASCII, and roughly 48x faster for ASCII-compatible charsets like ISO-8859-15. On 3rd party microbenchmarks we can assert that performance for non-ASCII input either doesn't change, or improves when messages have an ASCII prefix. ------------- PR: https://git.openjdk.java.net/jdk/pull/5621 From redestad at openjdk.java.net Fri Sep 24 16:04:08 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 24 Sep 2021 16:04:08 GMT Subject: RFR: 8274242: Implement fast-path for ASCII-compatible CharsetEncoders on x86 Message-ID: This patch extends the `ISO_8859_1.implEncodeISOArray` intrinsic on x86 to work also for ASCII encoding, which makes for example the `UTF_8$Encoder` perform on par with (or outperform) similarly getting charset encoded bytes from a String. The former took a small performance hit in JDK 9, and the latter improved greatly in the same release. Extending the `EncodeIsoArray` intrinsics on other platforms should be possible, but I'm unfamiliar with the macro assembler in general and unlike the x86 intrinsic they don't use a simple vectorized mask to implement the latin-1 check. For example aarch64 seem to filter out the low bytes and then check if there's any bits set in the high bytes. Clever, but very different to the 0xFF80 2-byte mask that an ASCII test wants. ------------- Commit messages: - Freshen up CharsetEncodeDecode micro (still only tests ASCII), optimize ASCII-compatible SingleByte (e.g. ISO-8859-15) - Add @bug id to test - Move and adapt defunct Test6896617 test to test more Charsets without using internal APIs; remove adhoc performance tests - Exclude encodeAsciiArray intrinsic on all non-X86 platforms - Fix indentation - Remove EncodeAsciiArray node and instead extend EncodeISOArray with an is_ascii predicate - Merge MacroAssembler methods - Implement intrinsified ASCII fast-path by copying and adapting encodeISOArray intrinsic (currently x86 only) - Enhance UTF_8.Encoder by using StringUTF16.compress for ASCII Changes: https://git.openjdk.java.net/jdk/pull/5621/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5621&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274242 Stats: 763 lines in 20 files changed: 375 ins; 355 del; 33 mod Patch: https://git.openjdk.java.net/jdk/pull/5621.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5621/head:pull/5621 PR: https://git.openjdk.java.net/jdk/pull/5621 From redestad at openjdk.java.net Fri Sep 24 16:04:08 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 24 Sep 2021 16:04:08 GMT Subject: RFR: 8274242: Implement fast-path for ASCII-compatible CharsetEncoders on x86 In-Reply-To: References: Message-ID: On Thu, 23 Sep 2021 00:03:55 GMT, Claes Redestad wrote: > This can probably be simplified further, say by adding a flag to the intrinsic of whether we're encoding ASCII only or ISO-8859-1. Done: Removed the addition of a new C2 Node, merged the macro assembler encode_iso_array and encode_ascii_array and added a predicate to select the behavior. > It also needs to be implemented and tested on all architectures. Implementing this on other hardware is Future Work. The non-x86 intrinsics for implEncodeISOArray all seem to use clever tricks rather than a simple mask that can be easily switched from detecting non-latin-1(0xFF00) to detecting ASCII (0xFF80). Clever tricks make it rather challenging to extend this like I could easily do in the x86 code (most all assembler is foreign to me) ------------- PR: https://git.openjdk.java.net/jdk/pull/5621 From github.com+7837910+xpbob at openjdk.java.net Fri Sep 24 16:27:13 2021 From: github.com+7837910+xpbob at openjdk.java.net (xpbob) Date: Fri, 24 Sep 2021 16:27:13 GMT Subject: RFR: 8274293: Build failure with Xcode 13.0 due to vfork is deprecated Message-ID: remove vfork() on Darwin ------------- Commit messages: - 8274293: Build failure with Xcode 13.0 due to vfork is deprecated Changes: https://git.openjdk.java.net/jdk/pull/5686/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5686&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274293 Stats: 10 lines in 2 files changed: 8 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5686.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5686/head:pull/5686 PR: https://git.openjdk.java.net/jdk/pull/5686 From alanb at openjdk.java.net Fri Sep 24 17:04:49 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 24 Sep 2021 17:04:49 GMT Subject: RFR: 8274293: Build failure with Xcode 13.0 due to vfork is deprecated In-Reply-To: References: Message-ID: On Fri, 24 Sep 2021 16:18:57 GMT, xpbob wrote: > remove vfork() on Darwin src/java.base/unix/native/libjava/ProcessImpl_md.c line 447: > 445: #endif > 446: > 447: /* vfork(2) is deprecated on Solaris and Darwin */ Drive by comment is that we can probably drop "Solaris" from the comment. ------------- PR: https://git.openjdk.java.net/jdk/pull/5686 From naoto at openjdk.java.net Fri Sep 24 18:00:52 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 24 Sep 2021 18:00:52 GMT Subject: RFR: 8273790: Potential cyclic dependencies between Gregorian and CalendarSystem In-Reply-To: References: Message-ID: On Fri, 24 Sep 2021 14:36:07 GMT, Jaikiran Pai wrote: > Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.java.net/browse/JDK-8273790? > > As noted in that issue, trying to class load `sun.util.calendar.CalendarSystem` and `sun.util.calendar.Gregorian` concurrently in separate threads can lead to a deadlock because of the cyclic nature of the code in their static initialization. More specifically, consider this case: > > - Thread T1 initiates a classload on the `sun.util.calendar.CalendarSystem`. > - This gives T1 the implicit class init lock on `CalendarSystem`. > - Consider thread T2 which at the same time initiates a classload on `sun.util.calendar.Gregorian` class. > - This gives T2 a implicit class init lock on `Gregorian`. > - T1, still holding a lock on `CalendarSystem` attempts to load `Gregorian` since it wants to create a (singleton) instance of `Gregorian` and assign it to the `static final GREGORIAN_INSTANCE` member. Since T2 is holding a class init lock on `Gregorian`, T1 ends up waiting > - T2 on the other hand is still loading the `Gregorian` class. `Gregorian` itself "is a" `CalendarSystem`, so during this loading of `Gregorian` class, T2 starts travelling up the class hierarchy and asks for a lock on `CalendarSystem`. However T1 is holding this lock and as a result T2 ends up waiting on T1 which is waiting on T2. That triggers this deadlock. > > The linked JBS issue has a thread dump which shows this in action. > > The commit here delays the instance creation of `Gregorian` by moving that instance creation logic from the static initialization of the `CalendarSystem` class, to the first call to `CalendarSystem#getGregorianCalendar()`. This prevents the `CalendarSystem` from needing a lock on `Gregorian` during its static init (of course, unless some code in this static init flow calls `CalendarSystem#getGregorianCalendar()`, in which case it is back to square one. I have verified, both manually and through the jtreg test, that the code in question doesn't have such calls) > > A new jtreg test has been introduced to reproduce the issue and verify the fix. The test in addition to loading these 2 classes in question, also additionally loads a few other classes concurrently. These classes have specific static initialization which leads the calls to `CalendarSystem#getGregorianCalendar()` or `CalendarSystem#forName()`. Including these classes in the tests ensures that this deadlock hasn't "moved" to a different location. I have run multiple runs (approximately 25) of this test with the fix and I haven't seen it deadlock anymore. Thanks, Jaikiran. Looks good. Some minor comments. src/java.base/share/classes/sun/util/calendar/CalendarSystem.java line 123: > 121: */ > 122: public static Gregorian getGregorianCalendar() { > 123: var gCal = GREGORIAN_INSTANCE; Do we need the local variable `gCal`? test/jdk/sun/util/calendar/CalendarSystemDeadLockTest.java line 43: > 41: * @run main/othervm CalendarSystemDeadLockTest > 42: * @run main/othervm CalendarSystemDeadLockTest > 43: * @run main/othervm CalendarSystemDeadLockTest Just curious, before the fix, how many test instances caused the deadlock? I'd think these 5 runs are arbitrary numbers, Just wanted to have those 5 runs are appropriate. test/jdk/sun/util/calendar/CalendarSystemDeadLockTest.java line 75: > 73: tasks.add(new GetGregorianCalTask(taskTriggerLatch)); > 74: tasks.add(new GetGregorianCalTask(taskTriggerLatch)); > 75: final ExecutorService executor = Executors.newFixedThreadPool(tasks.size()); Asserting `tasks.size() == numTasks` may help here. test/jdk/sun/util/calendar/CalendarSystemDeadLockTest.java line 171: > 169: } > 170: } > 171: } Need a new line at the EOF. ------------- PR: https://git.openjdk.java.net/jdk/pull/5683 From rriggs at openjdk.java.net Fri Sep 24 18:19:52 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 24 Sep 2021 18:19:52 GMT Subject: RFR: 8273790: Potential cyclic dependencies between Gregorian and CalendarSystem In-Reply-To: References: Message-ID: <92tcbP0OzS36W8Yjdyv10e8sggxwSNN94FY6p6e8AYM=.ddeaef14-5d44-479c-b65b-da03740a4936@github.com> On Fri, 24 Sep 2021 14:36:07 GMT, Jaikiran Pai wrote: > Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.java.net/browse/JDK-8273790? > > As noted in that issue, trying to class load `sun.util.calendar.CalendarSystem` and `sun.util.calendar.Gregorian` concurrently in separate threads can lead to a deadlock because of the cyclic nature of the code in their static initialization. More specifically, consider this case: > > - Thread T1 initiates a classload on the `sun.util.calendar.CalendarSystem`. > - This gives T1 the implicit class init lock on `CalendarSystem`. > - Consider thread T2 which at the same time initiates a classload on `sun.util.calendar.Gregorian` class. > - This gives T2 a implicit class init lock on `Gregorian`. > - T1, still holding a lock on `CalendarSystem` attempts to load `Gregorian` since it wants to create a (singleton) instance of `Gregorian` and assign it to the `static final GREGORIAN_INSTANCE` member. Since T2 is holding a class init lock on `Gregorian`, T1 ends up waiting > - T2 on the other hand is still loading the `Gregorian` class. `Gregorian` itself "is a" `CalendarSystem`, so during this loading of `Gregorian` class, T2 starts travelling up the class hierarchy and asks for a lock on `CalendarSystem`. However T1 is holding this lock and as a result T2 ends up waiting on T1 which is waiting on T2. That triggers this deadlock. > > The linked JBS issue has a thread dump which shows this in action. > > The commit here delays the instance creation of `Gregorian` by moving that instance creation logic from the static initialization of the `CalendarSystem` class, to the first call to `CalendarSystem#getGregorianCalendar()`. This prevents the `CalendarSystem` from needing a lock on `Gregorian` during its static init (of course, unless some code in this static init flow calls `CalendarSystem#getGregorianCalendar()`, in which case it is back to square one. I have verified, both manually and through the jtreg test, that the code in question doesn't have such calls) > > A new jtreg test has been introduced to reproduce the issue and verify the fix. The test in addition to loading these 2 classes in question, also additionally loads a few other classes concurrently. These classes have specific static initialization which leads the calls to `CalendarSystem#getGregorianCalendar()` or `CalendarSystem#forName()`. Including these classes in the tests ensures that this deadlock hasn't "moved" to a different location. I have run multiple runs (approximately 25) of this test with the fix and I haven't seen it deadlock anymore. As an alternative, can the Gregorian Instance be moved to a nested (static) class. That will delay initialization until it is needed. This "holder" pattern is used elsewhere to defer initialization and break cycles. ------------- PR: https://git.openjdk.java.net/jdk/pull/5683 From naoto at openjdk.java.net Fri Sep 24 20:42:55 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 24 Sep 2021 20:42:55 GMT Subject: RFR: 8274242: Implement fast-path for ASCII-compatible CharsetEncoders on x86 In-Reply-To: References: Message-ID: On Tue, 21 Sep 2021 21:58:48 GMT, Claes Redestad wrote: > This patch extends the `ISO_8859_1.implEncodeISOArray` intrinsic on x86 to work also for ASCII encoding, which makes for example the `UTF_8$Encoder` perform on par with (or outperform) similarly getting charset encoded bytes from a String. The former took a small performance hit in JDK 9, and the latter improved greatly in the same release. > > Extending the `EncodeIsoArray` intrinsics on other platforms should be possible, but I'm unfamiliar with the macro assembler in general and unlike the x86 intrinsic they don't use a simple vectorized mask to implement the latin-1 check. For example aarch64 seem to filter out the low bytes and then check if there's any bits set in the high bytes. Clever, but very different to the 0xFF80 2-byte mask that an ASCII test wants. core library part of the changes looks good to me. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5621 From mchung at openjdk.java.net Fri Sep 24 22:34:00 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 24 Sep 2021 22:34:00 GMT Subject: RFR: 8266936: Add a finalization JFR event [v12] In-Reply-To: <7qUo6JdWeitC5Tw90sAEdokNLL1B0cp7nU8pBRLFoOc=.9d912b5c-41f6-42cd-a393-85f46daad623@github.com> References: <7qUo6JdWeitC5Tw90sAEdokNLL1B0cp7nU8pBRLFoOc=.9d912b5c-41f6-42cd-a393-85f46daad623@github.com> Message-ID: On Fri, 24 Sep 2021 09:27:02 GMT, Markus Gr?nlund wrote: >> Greetings, >> >> Object.finalize() was deprecated in JDK9. There is an ongoing effort to replace and mitigate Object.finalize() uses in the JDK libraries; please see https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. >> >> We also like to assist users in replacing and mitigating uses in non-JDK code. >> >> Hence, this changeset adds a periodic JFR event to help identify which classes are overriding Object.finalize(). >> >> Thanks >> Markus > > Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: > > no precompiled headers and mtServiceability nmt classification Hi Markus, It's a little surprised to see Finalizer.c to depend JMM interface which is used by `java.management` and `jdk.management` modules only. It's more appropriate for it to be a JVM_* entry point for Finalizer to report completion of the finalization instead. I understand that you want to make FinalizerService to be a conditional feature which is a good idea. Such JVM entry can be made as a nop if not INCLUDE_SERVICES. ------------- PR: https://git.openjdk.java.net/jdk/pull/4731 From sviswanathan at openjdk.java.net Fri Sep 24 23:19:17 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Fri, 24 Sep 2021 23:19:17 GMT Subject: RFR: 8274242: Implement fast-path for ASCII-compatible CharsetEncoders on x86 In-Reply-To: References: Message-ID: On Tue, 21 Sep 2021 21:58:48 GMT, Claes Redestad wrote: > This patch extends the `ISO_8859_1.implEncodeISOArray` intrinsic on x86 to work also for ASCII encoding, which makes for example the `UTF_8$Encoder` perform on par with (or outperform) similarly getting charset encoded bytes from a String. The former took a small performance hit in JDK 9, and the latter improved greatly in the same release. > > Extending the `EncodeIsoArray` intrinsics on other platforms should be possible, but I'm unfamiliar with the macro assembler in general and unlike the x86 intrinsic they don't use a simple vectorized mask to implement the latin-1 check. For example aarch64 seem to filter out the low bytes and then check if there's any bits set in the high bytes. Clever, but very different to the 0xFF80 2-byte mask that an ASCII test wants. x86 part of changes look good. ------------- PR: https://git.openjdk.java.net/jdk/pull/5621 From mchung at openjdk.java.net Fri Sep 24 23:47:01 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 24 Sep 2021 23:47:01 GMT Subject: RFR: JDK-8274311: Make build.tools.jigsaw.GenGraphs more configurable Message-ID: GenGraphs tool generates the module graph. It currently supports the configuration via javadoc-graphs.properties. However, `make/jdk/src/classes/build/tools/jigsaw/javadoc-graphs.properties` only documents two properties. It should be updated to cover all configurable properties. There are a couple other properties not configurable such as nodesep and node margin. This extends the configuration to allow to set additional properties. This also fixes `requiresMandatedColor` in javadoc-graphs.properties to light gray to match the default configuration in the implementation, i.e. the color of the edge to java.base. It seems a bug that was unnoticed until Alex and Iris spotted it. ------------- Commit messages: - JDK-8274311: Make build.tools.jigsaw.GenGraphs more configurable Changes: https://git.openjdk.java.net/jdk/pull/5690/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5690&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274311 Stats: 167 lines in 3 files changed: 100 ins; 33 del; 34 mod Patch: https://git.openjdk.java.net/jdk/pull/5690.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5690/head:pull/5690 PR: https://git.openjdk.java.net/jdk/pull/5690 From github.com+7837910+xpbob at openjdk.java.net Sat Sep 25 01:48:29 2021 From: github.com+7837910+xpbob at openjdk.java.net (xpbob) Date: Sat, 25 Sep 2021 01:48:29 GMT Subject: RFR: 8274293: Build failure with Xcode 13.0 due to vfork is deprecated [v2] In-Reply-To: References: Message-ID: <1gNjEaIKRg3DIqtvehDpCbV_rFH3HJSv2Q0_OfAR9Tg=.438ec9fc-9658-4bb5-819f-2a0f771d5466@github.com> > remove vfork() on Darwin xpbob has updated the pull request incrementally with one additional commit since the last revision: Drop drop "Solaris" from the comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5686/files - new: https://git.openjdk.java.net/jdk/pull/5686/files/89bb9c31..27d19543 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5686&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5686&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5686.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5686/head:pull/5686 PR: https://git.openjdk.java.net/jdk/pull/5686 From jpai at openjdk.java.net Sat Sep 25 03:38:24 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Sat, 25 Sep 2021 03:38:24 GMT Subject: RFR: 8273790: Potential cyclic dependencies between Gregorian and CalendarSystem [v2] In-Reply-To: References: Message-ID: > Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.java.net/browse/JDK-8273790? > > As noted in that issue, trying to class load `sun.util.calendar.CalendarSystem` and `sun.util.calendar.Gregorian` concurrently in separate threads can lead to a deadlock because of the cyclic nature of the code in their static initialization. More specifically, consider this case: > > - Thread T1 initiates a classload on the `sun.util.calendar.CalendarSystem`. > - This gives T1 the implicit class init lock on `CalendarSystem`. > - Consider thread T2 which at the same time initiates a classload on `sun.util.calendar.Gregorian` class. > - This gives T2 a implicit class init lock on `Gregorian`. > - T1, still holding a lock on `CalendarSystem` attempts to load `Gregorian` since it wants to create a (singleton) instance of `Gregorian` and assign it to the `static final GREGORIAN_INSTANCE` member. Since T2 is holding a class init lock on `Gregorian`, T1 ends up waiting > - T2 on the other hand is still loading the `Gregorian` class. `Gregorian` itself "is a" `CalendarSystem`, so during this loading of `Gregorian` class, T2 starts travelling up the class hierarchy and asks for a lock on `CalendarSystem`. However T1 is holding this lock and as a result T2 ends up waiting on T1 which is waiting on T2. That triggers this deadlock. > > The linked JBS issue has a thread dump which shows this in action. > > The commit here delays the instance creation of `Gregorian` by moving that instance creation logic from the static initialization of the `CalendarSystem` class, to the first call to `CalendarSystem#getGregorianCalendar()`. This prevents the `CalendarSystem` from needing a lock on `Gregorian` during its static init (of course, unless some code in this static init flow calls `CalendarSystem#getGregorianCalendar()`, in which case it is back to square one. I have verified, both manually and through the jtreg test, that the code in question doesn't have such calls) > > A new jtreg test has been introduced to reproduce the issue and verify the fix. The test in addition to loading these 2 classes in question, also additionally loads a few other classes concurrently. These classes have specific static initialization which leads the calls to `CalendarSystem#getGregorianCalendar()` or `CalendarSystem#forName()`. Including these classes in the tests ensures that this deadlock hasn't "moved" to a different location. I have run multiple runs (approximately 25) of this test with the fix and I haven't seen it deadlock anymore. Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision: - Minor test adjustments as suggested by Naoto - use a holder instead of volatile, as suggested by Roger ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5683/files - new: https://git.openjdk.java.net/jdk/pull/5683/files/8855f910..8b276d4d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5683&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5683&range=00-01 Stats: 22 lines in 2 files changed: 8 ins; 10 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/5683.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5683/head:pull/5683 PR: https://git.openjdk.java.net/jdk/pull/5683 From jpai at openjdk.java.net Sat Sep 25 03:48:57 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Sat, 25 Sep 2021 03:48:57 GMT Subject: RFR: 8273790: Potential cyclic dependencies between Gregorian and CalendarSystem [v2] In-Reply-To: References: Message-ID: On Fri, 24 Sep 2021 17:53:03 GMT, Naoto Sato wrote: >> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision: >> >> - Minor test adjustments as suggested by Naoto >> - use a holder instead of volatile, as suggested by Roger > > src/java.base/share/classes/sun/util/calendar/CalendarSystem.java line 123: > >> 121: */ >> 122: public static Gregorian getGregorianCalendar() { >> 123: var gCal = GREGORIAN_INSTANCE; > > Do we need the local variable `gCal`? This was there to avoid additional volatile reads in that method. A performance optimization. However, with the change Roger suggested, this is no longer relevant. > test/jdk/sun/util/calendar/CalendarSystemDeadLockTest.java line 43: > >> 41: * @run main/othervm CalendarSystemDeadLockTest >> 42: * @run main/othervm CalendarSystemDeadLockTest >> 43: * @run main/othervm CalendarSystemDeadLockTest > > Just curious, before the fix, how many test instances caused the deadlock? I'd think these 5 runs are arbitrary numbers, Just wanted to have those 5 runs are appropriate. Hello @naotoj, On my setup, without the fix, the test deadlocks almost always right on the first run. There have been cases where it did pass the first time, but running it a second time has always reproduced the failure. The 5 runs that I have in this test is indeed an arbitrary number. Given how quickly this test completes, I decided to use a slightly higher number of 5 instead of maybe 2 or 3. Do you think, we should change the run count to something else? > test/jdk/sun/util/calendar/CalendarSystemDeadLockTest.java line 75: > >> 73: tasks.add(new GetGregorianCalTask(taskTriggerLatch)); >> 74: tasks.add(new GetGregorianCalTask(taskTriggerLatch)); >> 75: final ExecutorService executor = Executors.newFixedThreadPool(tasks.size()); > > Asserting `tasks.size() == numTasks` may help here. Yes, that makes sense. I've updated the test to add this check. > test/jdk/sun/util/calendar/CalendarSystemDeadLockTest.java line 171: > >> 169: } >> 170: } >> 171: } > > Need a new line at the EOF. Done. I've updated this in the latest version of the PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/5683 From jpai at openjdk.java.net Sat Sep 25 03:52:54 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Sat, 25 Sep 2021 03:52:54 GMT Subject: RFR: 8273790: Potential cyclic dependencies between Gregorian and CalendarSystem [v2] In-Reply-To: References: Message-ID: On Sat, 25 Sep 2021 03:38:24 GMT, Jaikiran Pai wrote: >> Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.java.net/browse/JDK-8273790? >> >> As noted in that issue, trying to class load `sun.util.calendar.CalendarSystem` and `sun.util.calendar.Gregorian` concurrently in separate threads can lead to a deadlock because of the cyclic nature of the code in their static initialization. More specifically, consider this case: >> >> - Thread T1 initiates a classload on the `sun.util.calendar.CalendarSystem`. >> - This gives T1 the implicit class init lock on `CalendarSystem`. >> - Consider thread T2 which at the same time initiates a classload on `sun.util.calendar.Gregorian` class. >> - This gives T2 a implicit class init lock on `Gregorian`. >> - T1, still holding a lock on `CalendarSystem` attempts to load `Gregorian` since it wants to create a (singleton) instance of `Gregorian` and assign it to the `static final GREGORIAN_INSTANCE` member. Since T2 is holding a class init lock on `Gregorian`, T1 ends up waiting >> - T2 on the other hand is still loading the `Gregorian` class. `Gregorian` itself "is a" `CalendarSystem`, so during this loading of `Gregorian` class, T2 starts travelling up the class hierarchy and asks for a lock on `CalendarSystem`. However T1 is holding this lock and as a result T2 ends up waiting on T1 which is waiting on T2. That triggers this deadlock. >> >> The linked JBS issue has a thread dump which shows this in action. >> >> The commit here delays the instance creation of `Gregorian` by moving that instance creation logic from the static initialization of the `CalendarSystem` class, to the first call to `CalendarSystem#getGregorianCalendar()`. This prevents the `CalendarSystem` from needing a lock on `Gregorian` during its static init (of course, unless some code in this static init flow calls `CalendarSystem#getGregorianCalendar()`, in which case it is back to square one. I have verified, both manually and through the jtreg test, that the code in question doesn't have such calls) >> >> A new jtreg test has been introduced to reproduce the issue and verify the fix. The test in addition to loading these 2 classes in question, also additionally loads a few other classes concurrently. These classes have specific static initialization which leads the calls to `CalendarSystem#getGregorianCalendar()` or `CalendarSystem#forName()`. Including these classes in the tests ensures that this deadlock hasn't "moved" to a different location. I have run multiple runs (approximately 25) of this test with the fix and I haven't seen it deadlock anymore. > > Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision: > > - Minor test adjustments as suggested by Naoto > - use a holder instead of volatile, as suggested by Roger Hello Roger, > As an alternative, can the Gregorian Instance be moved to a nested (static) class. That will delay initialization until it is needed. This "holder" pattern is used elsewhere to defer initialization and break cycles. I did indeed have that in mind when I started work on this. That was something Chris Hegarty had suggested and we have used in a different (but similar) issue a while back[1]. I was however unsure if that's a common enough technique, so had started off with the volatile approach. I've now updated the PR to use the holder technique instead. [1] https://github.com/openjdk/jdk/pull/2893#issuecomment-797539503 ------------- PR: https://git.openjdk.java.net/jdk/pull/5683 From yyang at openjdk.java.net Sat Sep 25 04:42:55 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Sat, 25 Sep 2021 04:42:55 GMT Subject: RFR: 8273790: Potential cyclic dependencies between Gregorian and CalendarSystem [v2] In-Reply-To: References: Message-ID: <6pR-Ih_NtVSy0j0d_pX_7SBc0EhW1N5bG9jn7mn65Fg=.9f9f1536-64c2-46db-8a29-540bc19e08ac@github.com> On Sat, 25 Sep 2021 03:38:24 GMT, Jaikiran Pai wrote: >> Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.java.net/browse/JDK-8273790? >> >> As noted in that issue, trying to class load `sun.util.calendar.CalendarSystem` and `sun.util.calendar.Gregorian` concurrently in separate threads can lead to a deadlock because of the cyclic nature of the code in their static initialization. More specifically, consider this case: >> >> - Thread T1 initiates a classload on the `sun.util.calendar.CalendarSystem`. >> - This gives T1 the implicit class init lock on `CalendarSystem`. >> - Consider thread T2 which at the same time initiates a classload on `sun.util.calendar.Gregorian` class. >> - This gives T2 a implicit class init lock on `Gregorian`. >> - T1, still holding a lock on `CalendarSystem` attempts to load `Gregorian` since it wants to create a (singleton) instance of `Gregorian` and assign it to the `static final GREGORIAN_INSTANCE` member. Since T2 is holding a class init lock on `Gregorian`, T1 ends up waiting >> - T2 on the other hand is still loading the `Gregorian` class. `Gregorian` itself "is a" `CalendarSystem`, so during this loading of `Gregorian` class, T2 starts travelling up the class hierarchy and asks for a lock on `CalendarSystem`. However T1 is holding this lock and as a result T2 ends up waiting on T1 which is waiting on T2. That triggers this deadlock. >> >> The linked JBS issue has a thread dump which shows this in action. >> >> The commit here delays the instance creation of `Gregorian` by moving that instance creation logic from the static initialization of the `CalendarSystem` class, to the first call to `CalendarSystem#getGregorianCalendar()`. This prevents the `CalendarSystem` from needing a lock on `Gregorian` during its static init (of course, unless some code in this static init flow calls `CalendarSystem#getGregorianCalendar()`, in which case it is back to square one. I have verified, both manually and through the jtreg test, that the code in question doesn't have such calls) >> >> A new jtreg test has been introduced to reproduce the issue and verify the fix. The test in addition to loading these 2 classes in question, also additionally loads a few other classes concurrently. These classes have specific static initialization which leads the calls to `CalendarSystem#getGregorianCalendar()` or `CalendarSystem#forName()`. Including these classes in the tests ensures that this deadlock hasn't "moved" to a different location. I have run multiple runs (approximately 25) of this test with the fix and I haven't seen it deadlock anymore. > > Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision: > > - Minor test adjustments as suggested by Naoto > - use a holder instead of volatile, as suggested by Roger @jaikiran Thanks for fixing this. Delaying instance creation via a static holder class seems reasonable to me. ------------- Marked as reviewed by yyang (Committer). PR: https://git.openjdk.java.net/jdk/pull/5683 From alanb at openjdk.java.net Sat Sep 25 06:56:54 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 25 Sep 2021 06:56:54 GMT Subject: RFR: JDK-8274311: Make build.tools.jigsaw.GenGraphs more configurable In-Reply-To: References: Message-ID: On Fri, 24 Sep 2021 23:07:33 GMT, Mandy Chung wrote: > GenGraphs tool generates the module graph. It currently supports the configuration via javadoc-graphs.properties. However, `make/jdk/src/classes/build/tools/jigsaw/javadoc-graphs.properties` only documents two properties. It should be updated to cover all configurable properties. > > There are a couple other properties not configurable such as nodesep and node margin. This extends the configuration to allow to set additional properties. > > This also fixes `requiresMandatedColor` in javadoc-graphs.properties to light gray to match the default configuration in the implementation, i.e. the color of the edge to java.base. It seems a bug that was unnoticed until Alex and Iris spotted it. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5690 From iris at openjdk.java.net Sat Sep 25 07:51:00 2021 From: iris at openjdk.java.net (Iris Clark) Date: Sat, 25 Sep 2021 07:51:00 GMT Subject: RFR: JDK-8274311: Make build.tools.jigsaw.GenGraphs more configurable In-Reply-To: References: Message-ID: <-n6jGtNCZNaZTuxE9ca3pY-UhaPukDF-uuVadIAZpOs=.9fd7c857-2cf1-4195-805b-c1bc1584b3c6@github.com> On Fri, 24 Sep 2021 23:07:33 GMT, Mandy Chung wrote: > GenGraphs tool generates the module graph. It currently supports the configuration via javadoc-graphs.properties. However, `make/jdk/src/classes/build/tools/jigsaw/javadoc-graphs.properties` only documents two properties. It should be updated to cover all configurable properties. > > There are a couple other properties not configurable such as nodesep and node margin. This extends the configuration to allow to set additional properties. > > This also fixes `requiresMandatedColor` in javadoc-graphs.properties to light gray to match the default configuration in the implementation, i.e. the color of the edge to java.base. It seems a bug that was unnoticed until Alex and Iris spotted it. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5690 From alanb at openjdk.java.net Sat Sep 25 08:24:56 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 25 Sep 2021 08:24:56 GMT Subject: RFR: 8274293: [macos] Build failure with Xcode 13.0 due to vfork is deprecated [v2] In-Reply-To: <1gNjEaIKRg3DIqtvehDpCbV_rFH3HJSv2Q0_OfAR9Tg=.438ec9fc-9658-4bb5-819f-2a0f771d5466@github.com> References: <1gNjEaIKRg3DIqtvehDpCbV_rFH3HJSv2Q0_OfAR9Tg=.438ec9fc-9658-4bb5-819f-2a0f771d5466@github.com> Message-ID: On Sat, 25 Sep 2021 01:48:29 GMT, xpbob wrote: >> remove vfork() on Darwin > > xpbob has updated the pull request incrementally with one additional commit since the last revision: > > Drop drop "Solaris" from the comment I think this looks okay but would be good for @RogerRiggs to also review. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5686 From stuefe at openjdk.java.net Sat Sep 25 10:14:04 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sat, 25 Sep 2021 10:14:04 GMT Subject: RFR: 8274293: Build failure on macOS with Xcode 13.0 as vfork is deprecated [v2] In-Reply-To: <1gNjEaIKRg3DIqtvehDpCbV_rFH3HJSv2Q0_OfAR9Tg=.438ec9fc-9658-4bb5-819f-2a0f771d5466@github.com> References: <1gNjEaIKRg3DIqtvehDpCbV_rFH3HJSv2Q0_OfAR9Tg=.438ec9fc-9658-4bb5-819f-2a0f771d5466@github.com> Message-ID: On Sat, 25 Sep 2021 01:48:29 GMT, xpbob wrote: >> remove vfork() on Darwin > > xpbob has updated the pull request incrementally with one additional commit since the last revision: > > Drop drop "Solaris" from the comment The JDK change is fine. AFAICS we have used posix_spawn by default on MacOS since at least 2015, and vfork was not even an option on MacOS. Wrt the hotspot portion, we now fall back to fork. I wonder what the footprint penalty is compared to vfork. `os::fork_and_exec` gets used mainly by error reporting (`-XX:OnError`=xxx), e.g. in OOM situations. We now may run into situations where error analysis tools are unable to spawn if the parent is too big. Maybe we should change `os::fork_and_exec()` to use posix_spawn instead? ------------- PR: https://git.openjdk.java.net/jdk/pull/5686 From plevart at openjdk.java.net Sat Sep 25 10:23:40 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Sat, 25 Sep 2021 10:23:40 GMT Subject: RFR: 8274299: Make Method/Constructor/Field accessors @Stable Message-ID: This patch improves reflective access speed as shown by the included benchmarks: https://jmh.morethan.io/?gists=902f4b43519c4f96c7abcd14cdc2d27d,ac490481e3001c710d75d6071c10b23a ... and is also a prerequisite to make JEP 416 (Reimplement Core Reflection with Method Handle) perform better in some circumstances. ------------- Commit messages: - Add JMH benchmarks - Make Method/Constructor/Field accessors @Stable Changes: https://git.openjdk.java.net/jdk/pull/5694/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5694&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274299 Stats: 721 lines in 13 files changed: 637 ins; 37 del; 47 mod Patch: https://git.openjdk.java.net/jdk/pull/5694.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5694/head:pull/5694 PR: https://git.openjdk.java.net/jdk/pull/5694 From lance.andersen at oracle.com Sat Sep 25 10:47:20 2021 From: lance.andersen at oracle.com (Lance Andersen) Date: Sat, 25 Sep 2021 10:47:20 +0000 Subject: RFR: 8258117: jar tool sets the time stamp of module-info.class entries to the current time [v2] In-Reply-To: References: Message-ID: On Sep 23, 2021, at 2:28 AM, Jaikiran Pai > wrote: On Fri, 17 Sep 2021 12:54:07 GMT, Jaikiran Pai > wrote: The commit here is a potential fix for the issue noted in https://bugs.openjdk.java.net/browse/JDK-8258117. The change here repurposes an existing internal interface `ModuleInfoEntry` to keep track of the last modified timestamp of a `module-info.class` descriptor. This commit uses the timestamp of the `module-info.class` on the filesystem to set the time on the `JarEntry`. There are a couple of cases to consider here: 1. When creating a jar (using `--create`), we use the source `module-info.class` from the filesystem and then add extended info to it (attributes like packages, module version etc...). In such cases, this patch will use the lastmodified timestamp from the filesystem of `module-info.class` even though we might end up updating/extending/modifying (for example by adding a module version) its content while storing it as a `JarEntry`. 2. When updating a jar (using `--update`), this patch will use the lastmodified timestamp of `module-info.class` either from the filesystem or from the source jar's entry (depending on whether a new `module-info.class` is being passed to the command). Here too, it's possible that we might end up changing/modifying/extending the `module-info.class` (for example, changing the module version to a new version) that gets written into the updated jar file, but this patch _won't_ use `System.currentTimeMillis()` even in such cases. If we do have to track actual changes that might happen to `module-info.class` while extending its info (in `extendedInfoBytes()`) and then decide whether to use current system time as last modified time, then this will require a bigger change and also a discussion on what kind of extending of module-info.class content will require a change to the lastmodifiedtime of that entry. Jaikiran Pai 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 two additional commits since the last revision: - Merge latest from master branch - 8258117: jar tool sets the time stamp of module-info.class entries to the current time Any reviews for this one, please? Hi Jaikiran This is on my todo list, sorry for the delay. Hoping we can get a couple additional eyes on this as well. Best Lance ------------- PR: https://git.openjdk.java.net/jdk/pull/5486 [cid:E1C4E2F0-ECD0-4C9D-ADB4-B16CA7BCB7FC at home] Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From jai.forums2013 at gmail.com Sat Sep 25 12:49:50 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Sat, 25 Sep 2021 18:19:50 +0530 Subject: RFR: 8258117: jar tool sets the time stamp of module-info.class entries to the current time [v2] In-Reply-To: References: Message-ID: <6a8bbc86-b6aa-6099-2aa7-c93c3eb362c0@gmail.com> On 25/09/21 4:17 pm, Lance Andersen wrote: > > Hi Jaikiran > > This is on my todo list, sorry for the delay. > > Hoping we can get a couple additional eyes on this as well. Thank you Lance. Please take your time. -Jaikiran From mgronlun at openjdk.java.net Sat Sep 25 13:34:09 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Sat, 25 Sep 2021 13:34:09 GMT Subject: RFR: 8266936: Add a finalization JFR event [v13] In-Reply-To: References: Message-ID: > Greetings, > > Object.finalize() was deprecated in JDK9. There is an ongoing effort to replace and mitigate Object.finalize() uses in the JDK libraries; please see https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. > > We also like to assist users in replacing and mitigating uses in non-JDK code. > > Hence, this changeset adds a periodic JFR event to help identify which classes are overriding Object.finalize(). > > Thanks > Markus Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: jvm.h and JVM_Entry ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4731/files - new: https://git.openjdk.java.net/jdk/pull/4731/files/5759c605..73091f7c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=12 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=11-12 Stats: 52 lines in 6 files changed: 20 ins; 29 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/4731.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4731/head:pull/4731 PR: https://git.openjdk.java.net/jdk/pull/4731 From mgronlun at openjdk.java.net Sat Sep 25 13:52:56 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Sat, 25 Sep 2021 13:52:56 GMT Subject: RFR: 8266936: Add a finalization JFR event [v12] In-Reply-To: References: <7qUo6JdWeitC5Tw90sAEdokNLL1B0cp7nU8pBRLFoOc=.9d912b5c-41f6-42cd-a393-85f46daad623@github.com> Message-ID: On Fri, 24 Sep 2021 22:31:18 GMT, Mandy Chung wrote: > > > Hi Markus, > > It's a little surprised to see Finalizer.c to depend JMM interface which is used by `java.management` and `jdk.management` modules only. It's more appropriate for it to be a JVM_* entry point for Finalizer to report completion of the finalization instead. I understand that you want to make FinalizerService to be a conditional feature which is a good idea. Such JVM entry can be made as a nop if not INCLUDE_SERVICES. Thanks Mandy, I choose jmm.h over jvm.h because I wanted the FinalizerService to be conditional, like some other services/management implementations in the VM. There is conditional compilation support for the 'management' component of the JVM, i.e. INCLUDE_MANAGMENT. The jvm.h function JVM_GetManagement(JMM_VERSION) returns null if this subsystem is not included in the JVM, making it easier to support this as a conditional feature. In addition, I had hoped to see if I could also expose some of this finalizer statistics information via JMX. I did not get around to that, but a few accessors can now easily be added to jmm.h to get to this information and build on it further, should that be useful. There is also the benefit of not having to perform a VM call every time, which is probably only a small upshot because the code will most often be included. These reasons do not seem strong enough to motivate a move outside of the original classification, so I am ok to put it into jvm.h instead of jmm.h and create a JVM_Entry with a conditionalized body. ------------- PR: https://git.openjdk.java.net/jdk/pull/4731 From mgronlun at openjdk.java.net Sat Sep 25 14:22:28 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Sat, 25 Sep 2021 14:22:28 GMT Subject: RFR: 8266936: Add a finalization JFR event [v14] In-Reply-To: References: Message-ID: > Greetings, > > Object.finalize() was deprecated in JDK9. There is an ongoing effort to replace and mitigate Object.finalize() uses in the JDK libraries; please see https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. > > We also like to assist users in replacing and mitigating uses in non-JDK code. > > Hence, this changeset adds a periodic JFR event to help identify which classes are overriding Object.finalize(). > > Thanks > Markus Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: symbols-unix ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4731/files - new: https://git.openjdk.java.net/jdk/pull/4731/files/73091f7c..4eaad60d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=13 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=12-13 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4731.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4731/head:pull/4731 PR: https://git.openjdk.java.net/jdk/pull/4731 From stuefe at openjdk.java.net Sat Sep 25 16:05:57 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sat, 25 Sep 2021 16:05:57 GMT Subject: RFR: 8274293: Build failure on macOS with Xcode 13.0 as vfork is deprecated [v2] In-Reply-To: <1gNjEaIKRg3DIqtvehDpCbV_rFH3HJSv2Q0_OfAR9Tg=.438ec9fc-9658-4bb5-819f-2a0f771d5466@github.com> References: <1gNjEaIKRg3DIqtvehDpCbV_rFH3HJSv2Q0_OfAR9Tg=.438ec9fc-9658-4bb5-819f-2a0f771d5466@github.com> Message-ID: On Sat, 25 Sep 2021 01:48:29 GMT, xpbob wrote: >> remove vfork() on Darwin > > xpbob has updated the pull request incrementally with one additional commit since the last revision: > > Drop drop "Solaris" from the comment .. I opened https://bugs.openjdk.java.net/browse/JDK-8274320 to track the proposed change of os::fork_and_exec() to posix_spawn. So I am fine with this change. ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5686 From rriggs at openjdk.java.net Sun Sep 26 01:20:04 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Sun, 26 Sep 2021 01:20:04 GMT Subject: RFR: 8274293: Build failure on macOS with Xcode 13.0 as vfork is deprecated [v2] In-Reply-To: <1gNjEaIKRg3DIqtvehDpCbV_rFH3HJSv2Q0_OfAR9Tg=.438ec9fc-9658-4bb5-819f-2a0f771d5466@github.com> References: <1gNjEaIKRg3DIqtvehDpCbV_rFH3HJSv2Q0_OfAR9Tg=.438ec9fc-9658-4bb5-819f-2a0f771d5466@github.com> Message-ID: On Sat, 25 Sep 2021 01:48:29 GMT, xpbob wrote: >> remove vfork() on Darwin > > xpbob has updated the pull request incrementally with one additional commit since the last revision: > > Drop drop "Solaris" from the comment Looks good, vfork is not/was not being used on Mac OS. ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5686 From amaembo at gmail.com Sun Sep 26 09:27:58 2021 From: amaembo at gmail.com (Tagir Valeev) Date: Sun, 26 Sep 2021 16:27:58 +0700 Subject: Discussion: easier Stream closing Message-ID: Hello! With current NIO file API, a very simple problem to get the list of all files in the directory requires some ceremony: List paths; try (Stream stream = Files.list(Path.of("/etc"))) { paths = stream.toList(); } If we skip try-with-resources, we may experience OS file handles leak, so it's desired to keep it. Yet, it requires doing boring stuff. In this sense, classic new File("/etc").list() was somewhat more convenient (despite its awful error handling). I like how this problem is solved in StackWalker API [1]: it limits the lifetime of the Stream by requiring a user-specified function to consume it. After the function is applied, the stream is closed automatically. We could add a similar overload to the Files API. As an additional feature, we could also translate all UncheckedIOException's back to IOException for more uniform exception processing: /** * @param dir The path to the directory * @param function function to apply to the stream of directory files * @param type of the result * @return result of the function * @throws IOException if an I/O error occurs when opening the directory, or * UncheckedIOException is thrown by the supplied function. */ public static T list(Path dir, Function, ? extends T> function) throws IOException { try (Stream stream = Files.list(dir)) { return function.apply(stream); } catch (UncheckedIOException exception) { throw exception.getCause(); } } In this case, getting the List of all files in the directory will be as simple as List paths = Files.list(Path.of("/etc"), Stream::toList); This doesn't limit the flexibility. For example, if we need only file names instead of full paths, we can do this: List paths = Files.list(Path.of("/etc"), s -> s.map(Path::getFileName).toList()); Alternatively, we could enhance the BaseStream interface in a similar way. It won't allow us to translate exceptions, but could be useful for every stream that must be closed after consumption: // in BaseStream: /** * Apply a given function to this stream, then close the stream. * No further operation on the stream will be possible after that. * * @param function function to apply * @param type of the function result * @return result of the function * @see #close() */ default R consumeAndClose(Function function) { try(@SuppressWarnings("unchecked") S s = (S) this) { return function.apply(s); } } The usage would be a little bit longer but still more pleasant than explicit try-with-resources: List list = Files.list(Path.of("/etc")).consumeAndClose(Stream::toList); On the other hand, in this case, we are free to put intermediate operations outside of consumeAndClose, so we won't need to nest everything inside the function. Only terminal operation should be placed inside the consumeAndClose. E.g., if we need file names only, like above, we can do this: List list = Files.list(Path.of("/etc")).map(Path::getFileName).consumeAndClose(Stream::toList); What do you think? [1] https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/StackWalker.html#walk(java.util.function.Function) From forax at univ-mlv.fr Sun Sep 26 11:12:57 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 26 Sep 2021 13:12:57 +0200 (CEST) Subject: Discussion: easier Stream closing In-Reply-To: References: Message-ID: <881605929.3201166.1632654777487.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "Tagir Valeev" > To: "core-libs-dev" > Sent: Dimanche 26 Septembre 2021 11:27:58 > Subject: Discussion: easier Stream closing > Hello! > > With current NIO file API, a very simple problem to get the list of > all files in the directory requires some ceremony: > > List paths; > try (Stream stream = Files.list(Path.of("/etc"))) { > paths = stream.toList(); > } > > If we skip try-with-resources, we may experience OS file handles leak, > so it's desired to keep it. Yet, it requires doing boring stuff. In > this sense, classic new File("/etc").list() was somewhat more > convenient (despite its awful error handling). > > I like how this problem is solved in StackWalker API [1]: it limits > the lifetime of the Stream by requiring a user-specified function to > consume it. After the function is applied, the stream is closed > automatically. We could add a similar overload to the Files API. As an > additional feature, we could also translate all UncheckedIOException's > back to IOException for more uniform exception processing: > > /** > * @param dir The path to the directory > * @param function function to apply to the stream of directory files > * @param type of the result > * @return result of the function > * @throws IOException if an I/O error occurs when opening the directory, or > * UncheckedIOException is thrown by the supplied function. > */ > public static T list(Path dir, Function, ? > extends T> function) throws IOException { > try (Stream stream = Files.list(dir)) { > return function.apply(stream); > } > catch (UncheckedIOException exception) { > throw exception.getCause(); > } > } > > In this case, getting the List of all files in the directory will be > as simple as > > List paths = Files.list(Path.of("/etc"), Stream::toList); > This doesn't limit the flexibility. For example, if we need only file > names instead of full paths, we can do this: > List paths = Files.list(Path.of("/etc"), s -> > s.map(Path::getFileName).toList()); It seems a nice addition, forgetting the try-with-resources is a very common source of bugs in my students code. Part of the issue is that there is no way to easily test if there are still open descriptors during tests. I wonder if the VM can not offer such test using a special flag (-XX:+CheckPendingFileDescriptor) or something like that. > > Alternatively, we could enhance the BaseStream interface in a similar > way. It won't allow us to translate exceptions, but could be useful > for every stream that must be closed after consumption: > > // in BaseStream: > > /** > * Apply a given function to this stream, then close the stream. > * No further operation on the stream will be possible after that. > * > * @param function function to apply > * @param type of the function result > * @return result of the function > * @see #close() > */ > default R consumeAndClose(Function function) { > try(@SuppressWarnings("unchecked") S s = (S) this) { > return function.apply(s); > } > } > > The usage would be a little bit longer but still more pleasant than > explicit try-with-resources: > > List list = Files.list(Path.of("/etc")).consumeAndClose(Stream::toList); > > On the other hand, in this case, we are free to put intermediate > operations outside of consumeAndClose, so we won't need to nest > everything inside the function. Only terminal operation should be > placed inside the consumeAndClose. E.g., if we need file names only, > like above, we can do this: > > List list = > Files.list(Path.of("/etc")).map(Path::getFileName).consumeAndClose(Stream::toList); > > What do you think? This one does not work because if Path::getFileName fails with an exception, close() will not be called. What you are proposing here is equivalent to try(var stream = Files.list(Path.of("/etc")).map(Path::getFileName)) { stream.toList() } instead of try(var stream = Files.list(Path.of("/etc"))) { stream..map(Path::getFileName).toList() } regards, R?mi > > > [1] > https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/StackWalker.html#walk(java.util.function.Function) From github.com+53162078+shiyuexw at openjdk.java.net Sun Sep 26 11:47:04 2021 From: github.com+53162078+shiyuexw at openjdk.java.net (wxiang) Date: Sun, 26 Sep 2021 11:47:04 GMT Subject: Integrated: 8273401: Disable JarIndex support in URLClassPath In-Reply-To: References: Message-ID: On Wed, 15 Sep 2021 09:33:10 GMT, wxiang wrote: > There is a bug for URLClassPath.findResources with JarIndex. > Currently, there was agreement on dropping the support from the URLClassLoader implementation but it was suggested that it should be disabled for a release or two before the code is removed. > A system property can be used to re-enable JarIndex support in URLClassPath. > > The PR includes: > Disable JarIndex support in URLClassPath by default. > Add system property jdk.net.URLClassPath.enableJarIndex to re-enable JarIndex support. This pull request has now been integrated. Changeset: 7700b254 Author: seanwxiang Committer: Hui Shi URL: https://git.openjdk.java.net/jdk/commit/7700b25460b9898060602396fed7bc590ba242b8 Stats: 12 lines in 3 files changed: 8 ins; 1 del; 3 mod 8273401: Disable JarIndex support in URLClassPath Reviewed-by: dfuchs, lancea, alanb, mchung ------------- PR: https://git.openjdk.java.net/jdk/pull/5524 From github.com+7837910+xpbob at openjdk.java.net Sun Sep 26 14:52:01 2021 From: github.com+7837910+xpbob at openjdk.java.net (xpbob) Date: Sun, 26 Sep 2021 14:52:01 GMT Subject: Integrated: 8274293: Build failure on macOS with Xcode 13.0 as vfork is deprecated In-Reply-To: References: Message-ID: On Fri, 24 Sep 2021 16:18:57 GMT, xpbob wrote: > remove vfork() on Darwin This pull request has now been integrated. Changeset: 252aaa92 Author: bobpengxie Committer: Jie Fu URL: https://git.openjdk.java.net/jdk/commit/252aaa9249d8979366b37d59487b5b039d923e35 Stats: 10 lines in 2 files changed: 8 ins; 0 del; 2 mod 8274293: Build failure on macOS with Xcode 13.0 as vfork is deprecated Reviewed-by: alanb, stuefe, rriggs ------------- PR: https://git.openjdk.java.net/jdk/pull/5686 From scolebourne at joda.org Sun Sep 26 16:02:34 2021 From: scolebourne at joda.org (Stephen Colebourne) Date: Sun, 26 Sep 2021 17:02:34 +0100 Subject: Discussion: easier Stream closing In-Reply-To: References: Message-ID: On Sun, 26 Sept 2021 at 10:29, Tagir Valeev wrote: > List list = > Files.list(Path.of("/etc")).map(Path::getFileName).consumeAndClose(Stream::toList); > > What do you think? I fully support this. We have our own utility to do this kind of thing, as bugs with `Files` are common: https://github.com/OpenGamma/Strata/blob/main/modules/collect/src/main/java/com/opengamma/strata/collect/io/SafeFiles.java Stephen From github.com+53162078+shiyuexw at openjdk.java.net Mon Sep 27 01:42:05 2021 From: github.com+53162078+shiyuexw at openjdk.java.net (wxiang) Date: Mon, 27 Sep 2021 01:42:05 GMT Subject: RFR: 8273401: Remove JarIndex support in URLClassPath [v2] In-Reply-To: References: Message-ID: On Wed, 8 Sep 2021 06:22:38 GMT, wxiang wrote: >> There is a bug for URLClassPath.findResources with JarIndex. >> With some discussions about the bug, the current priority is to remove the JAR index support in URLClassPath, >> and don?t need to do anything to the jar tool in the short term, except just to move JarIndex to the jdk.jartool module. >> >> The PR includes: >> 1. remove the JarIndex support in URLClassPath >> 2. move JarIndex into jdk.jartool module. > > wxiang has updated the pull request incrementally with one additional commit since the last revision: > > Some minor changes > > Include: > 1. remove public for INDEX_NAME in JarFile > 2. recover the definition for INDEX_NAME in JarIndex > 3. mv the test case JarIndexMergeTest.java into test/jdk/java/util/jar Firstly, disable JarIndex support in URLClassPath. So close the PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/5383 From github.com+53162078+shiyuexw at openjdk.java.net Mon Sep 27 01:42:05 2021 From: github.com+53162078+shiyuexw at openjdk.java.net (wxiang) Date: Mon, 27 Sep 2021 01:42:05 GMT Subject: Withdrawn: 8273401: Remove JarIndex support in URLClassPath In-Reply-To: References: Message-ID: On Tue, 7 Sep 2021 03:34:27 GMT, wxiang wrote: > There is a bug for URLClassPath.findResources with JarIndex. > With some discussions about the bug, the current priority is to remove the JAR index support in URLClassPath, > and don?t need to do anything to the jar tool in the short term, except just to move JarIndex to the jdk.jartool module. > > The PR includes: > 1. remove the JarIndex support in URLClassPath > 2. move JarIndex into jdk.jartool module. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/5383 From github.com+53162078+shiyuexw at openjdk.java.net Mon Sep 27 01:49:04 2021 From: github.com+53162078+shiyuexw at openjdk.java.net (wxiang) Date: Mon, 27 Sep 2021 01:49:04 GMT Subject: RFR: 6957241: ClassLoader.getResources() returns only 1 instance when using jar indexing In-Reply-To: References: Message-ID: On Tue, 31 Aug 2021 12:11:46 GMT, wxiang wrote: > Using jarIndex for Hibench, there is an unexpected behavior with the exception "Exception in thread "main" org.apache.hadoop.fs.UnsupportedFileSystemException: No FileSystem for scheme "hdfs"". > > After investigating it, it is related to the usage of ServiceLoader with JarIndex. > The below stack shows the issue with JDK11: > > getResource:1016, URLClassPath$JarLoader (jdk.internal.loader) > getResource:937, URLClassPath$JarLoader (jdk.internal.loader) > findResource:912, URLClassPath$JarLoader (jdk.internal.loader) > next:341, URLClassPath$1 (jdk.internal.loader) > hasMoreElements:351, URLClassPath$1 (jdk.internal.loader) > hasNext:355, BuiltinClassLoader$1 (jdk.internal.loader) > hasMoreElements:363, BuiltinClassLoader$1 (jdk.internal.loader) > next:3032, CompoundEnumeration (java.lang) > hasMoreElements:3041, CompoundEnumeration (java.lang) > nextProviderClass:1203, ServiceLoader$LazyClassPathLookupIterator (java.util) > hasNextService:1221, ServiceLoader$LazyClassPathLookupIterator (java.util) > hasNext:1265, ServiceLoader$LazyClassPathLookupIterator (java.util) > hasNext:1300, ServiceLoader$2 (java.util) > hasNext:1385, ServiceLoader$3 (java.util) > > The below API tries to get all the resources with the same name. > > public Enumeration findResources(final String name, > final boolean check) > ``` > After using JarIndex, URLClassPath.findResources only returns 1 URL. > It is the same as the description in JDK-6957241. > > The issue still exists in JDK18. > > Root cause: > > public Enumeration findResources(final String name, > final boolean check) { > return new Enumeration<>() { > private int index = 0; > private URL url = null; > > private boolean next() { > if (url != null) { > return true; > } else { > Loader loader; > while ((loader = getLoader(index++)) != null) { > url = loader.findResource(name, check); > if (url != null) { > return true; > } > } > return false; > } > } > ... > }; > } > > With the JarIndex, there is only one loader which is corresponding to the jar with the index due to the implementation in JarLoader.getResource(final String name, boolean check, Set visited). > > Loaders corresponding to other jar packages will not appear in this while. > So it only returns 1 instance. > > To solve the issue, I change the implementation "private boolean next()". > If the loader has index, traverse the index and get all the resource from the loader. JarIndex support will be deleted. close the PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/5316 From github.com+53162078+shiyuexw at openjdk.java.net Mon Sep 27 01:49:04 2021 From: github.com+53162078+shiyuexw at openjdk.java.net (wxiang) Date: Mon, 27 Sep 2021 01:49:04 GMT Subject: Withdrawn: 6957241: ClassLoader.getResources() returns only 1 instance when using jar indexing In-Reply-To: References: Message-ID: On Tue, 31 Aug 2021 12:11:46 GMT, wxiang wrote: > Using jarIndex for Hibench, there is an unexpected behavior with the exception "Exception in thread "main" org.apache.hadoop.fs.UnsupportedFileSystemException: No FileSystem for scheme "hdfs"". > > After investigating it, it is related to the usage of ServiceLoader with JarIndex. > The below stack shows the issue with JDK11: > > getResource:1016, URLClassPath$JarLoader (jdk.internal.loader) > getResource:937, URLClassPath$JarLoader (jdk.internal.loader) > findResource:912, URLClassPath$JarLoader (jdk.internal.loader) > next:341, URLClassPath$1 (jdk.internal.loader) > hasMoreElements:351, URLClassPath$1 (jdk.internal.loader) > hasNext:355, BuiltinClassLoader$1 (jdk.internal.loader) > hasMoreElements:363, BuiltinClassLoader$1 (jdk.internal.loader) > next:3032, CompoundEnumeration (java.lang) > hasMoreElements:3041, CompoundEnumeration (java.lang) > nextProviderClass:1203, ServiceLoader$LazyClassPathLookupIterator (java.util) > hasNextService:1221, ServiceLoader$LazyClassPathLookupIterator (java.util) > hasNext:1265, ServiceLoader$LazyClassPathLookupIterator (java.util) > hasNext:1300, ServiceLoader$2 (java.util) > hasNext:1385, ServiceLoader$3 (java.util) > > The below API tries to get all the resources with the same name. > > public Enumeration findResources(final String name, > final boolean check) > ``` > After using JarIndex, URLClassPath.findResources only returns 1 URL. > It is the same as the description in JDK-6957241. > > The issue still exists in JDK18. > > Root cause: > > public Enumeration findResources(final String name, > final boolean check) { > return new Enumeration<>() { > private int index = 0; > private URL url = null; > > private boolean next() { > if (url != null) { > return true; > } else { > Loader loader; > while ((loader = getLoader(index++)) != null) { > url = loader.findResource(name, check); > if (url != null) { > return true; > } > } > return false; > } > } > ... > }; > } > > With the JarIndex, there is only one loader which is corresponding to the jar with the index due to the implementation in JarLoader.getResource(final String name, boolean check, Set visited). > > Loaders corresponding to other jar packages will not appear in this while. > So it only returns 1 instance. > > To solve the issue, I change the implementation "private boolean next()". > If the loader has index, traverse the index and get all the resource from the loader. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/5316 From amaembo at gmail.com Mon Sep 27 03:29:08 2021 From: amaembo at gmail.com (Tagir Valeev) Date: Mon, 27 Sep 2021 10:29:08 +0700 Subject: Discussion: easier Stream closing In-Reply-To: <881605929.3201166.1632654777487.JavaMail.zimbra@u-pem.fr> References: <881605929.3201166.1632654777487.JavaMail.zimbra@u-pem.fr> Message-ID: On Sun, Sep 26, 2021 at 6:13 PM Remi Forax wrote: > > > List list = > > Files.list(Path.of("/etc")).map(Path::getFileName).consumeAndClose(Stream::toList); > > > > What do you think? > > This one does not work because if Path::getFileName fails with an exception, close() will not be called. Well, as Path::getFileName is not actually executed here, only linked, there are only a few chances when map(Path::getFileName) may fail. Probably StackOverflowError, OutOfMemoryError, or LinkageError. Probably not so important for properly functioning application. I mean, if something of these happens, leaking file descriptor would be a lesser problem. With best regards, Tagir Valeev. > What you are proposing here is equivalent to > try(var stream = Files.list(Path.of("/etc")).map(Path::getFileName)) { > stream.toList() > } > > instead of > try(var stream = Files.list(Path.of("/etc"))) { > stream..map(Path::getFileName).toList() > } > > regards, > R?mi > > > > > > > [1] > > https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/StackWalker.html#walk(java.util.function.Function) From jpai at openjdk.java.net Mon Sep 27 03:47:02 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Mon, 27 Sep 2021 03:47:02 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v22] In-Reply-To: References: Message-ID: On Wed, 22 Sep 2021 10:27:45 GMT, Jaikiran Pai wrote: >> The commit in this PR implements the proposal for enhancement that was discussed in the core-libs-dev mailing list recently[1], for https://bugs.openjdk.java.net/browse/JDK-8231640 >> >> At a high level - the `store()` APIs in `Properties` have been modified to now look for the `SOURCE_DATE_EPOCH` environment variable[2]. If that env variable is set, then instead of writing out the current date time as a date comment, the `store()` APIs instead will use the value set for this env variable to parse it to a `Date` and write out the string form of such a date. The implementation here uses the `d MMM yyyy HH:mm:ss 'GMT'` date format and `Locale.ROOT` to format and write out such a date. This should provide reproducibility whenever the `SOURCE_DATE_EPOCH` is set. Furthermore, intentionally, no changes in the date format of the "current date" have been done. >> >> These modified `store()` APIs work in the presence of the `SecurityManager` too. The caller is expected to have a read permission on the `SOURCE_DATE_EPOCH` environment variable. If the caller doesn't have that permission, then the implementation of these `store()` APIs will write out the "current date" and will ignore any value that has been set for the `SOURCE_DATE_EPOCH` env variable. This should allow for backward compatibility of existing applications, where, when they run under a `SecurityManager` and perhaps with an existing restrictive policy file, the presence of `SOURCE_DATE_EPOCH` shouldn't impact their calls to the `store()` APIs. >> >> The modified `store()` APIs will also ignore any value for `SOURCE_DATE_EPOCH` that cannot be parsed to an `long` value. In such cases, the `store()` APIs will write out the "current date" and ignore the value set for this environment variable. No exceptions will be thrown for such invalid values. This is an additional backward compatibility precaution to prevent any rogue value for `SOURCE_DATE_EPOCH` from breaking applications. >> >> An additional change in the implementation of these `store()` APIs and unrelated to the date comment, is that these APIs will now write out the property keys in a deterministic order. The keys will be written out in the natural ordering as specified by `java.lang.String#compareTo()` API. >> >> The combination of the ordering of the property keys when written out and the usage of `SOURCE_DATE_EPOCH` environment value to determine the date comment should together allow for reproducibility of the output generated by these `store()` APIs. >> >> New jtreg test classes have been introduced to verify these changes. The primary focus of `PropertiesStoreTest` is the ordering aspects of the property keys that are written out. On the other hand `StoreReproducibilityTest` focuses on the reproducibility of the output generated by these APIs. The `StoreReproducibilityTest` runs these tests both in the presence and absence of `SecurityManager`. Plus, in the presence of SecurityManager, it tests both the scenarios where the caller is granted the requisite permission and in other case not granted that permission. >> >> These new tests and existing tests under `test/jdk/java/util/Properties/` pass with these changes. >> >> [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-August/080758.html >> [2] https://reproducible-builds.org/specs/source-date-epoch/ > > Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision: > > - Revert "Implement Mark's suggestion in CSR to include the java.properties.date in the list of system properties listed in System::getProperties()" > > Additional inputs since this specific commit was introduced have leaned towards not listing this property in System::getProperties() > > This reverts commit 458c1fd37cf1e8e8bd0a60a171d173ce5da12b7c. > - reduce the line length of code comment The CSR for this has been approved and there are no pending changes in this PR. I am thinking of integrating this PR in around 24 hours from now if this looks good. ------------- PR: https://git.openjdk.java.net/jdk/pull/5372 From thartmann at openjdk.java.net Mon Sep 27 06:40:06 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Mon, 27 Sep 2021 06:40:06 GMT Subject: RFR: 8274242: Implement fast-path for ASCII-compatible CharsetEncoders on x86 In-Reply-To: References: Message-ID: <5lVTU7su0xmkfNlex-Pv_yoeuJpnoCyalI42oLSjGzg=.54d143bc-ede4-4ec8-a257-1538f43ea632@github.com> On Tue, 21 Sep 2021 21:58:48 GMT, Claes Redestad wrote: > This patch extends the `ISO_8859_1.implEncodeISOArray` intrinsic on x86 to work also for ASCII encoding, which makes for example the `UTF_8$Encoder` perform on par with (or outperform) similarly getting charset encoded bytes from a String. The former took a small performance hit in JDK 9, and the latter improved greatly in the same release. > > Extending the `EncodeIsoArray` intrinsics on other platforms should be possible, but I'm unfamiliar with the macro assembler in general and unlike the x86 intrinsic they don't use a simple vectorized mask to implement the latin-1 check. For example aarch64 seem to filter out the low bytes and then check if there's any bits set in the high bytes. Clever, but very different to the 0xFF80 2-byte mask that an ASCII test wants. Very nice. The changes look good to me, just added some minor comments. Should we remove the "iso" part from the method/class names? src/hotspot/cpu/x86/x86_32.ad line 12218: > 12216: instruct encode_ascii_array(eSIRegP src, eDIRegP dst, eDXRegI len, > 12217: regD tmp1, regD tmp2, regD tmp3, regD tmp4, > 12218: eCXRegI tmp5, eAXRegI result, eFlagsReg cr) %{ Indentation is wrong. src/hotspot/cpu/x86/x86_32.ad line 12223: > 12221: effect(TEMP tmp1, TEMP tmp2, TEMP tmp3, TEMP tmp4, USE_KILL src, USE_KILL dst, USE_KILL len, KILL tmp5, KILL cr); > 12222: > 12223: format %{ "Encode array $src,$dst,$len -> $result // KILL ECX, EDX, $tmp1, $tmp2, $tmp3, $tmp4, ESI, EDI " %} You might want to change the opto assembly comment to "Encode ascii array" (and to "Encode iso array" above). Same on 64-bit. src/hotspot/share/opto/intrinsicnode.hpp line 171: > 169: > 170: //------------------------------EncodeISOArray-------------------------------- > 171: // encode char[] to byte[] in ISO_8859_1 Comment should be adjusted to `... in ISO_8859_1 or ASCII`. ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5621 From myano at openjdk.java.net Mon Sep 27 07:44:04 2021 From: myano at openjdk.java.net (Masanori Yano) Date: Mon, 27 Sep 2021 07:44:04 GMT Subject: RFR: 8233674: JarURLConnection.getJarFile throws Exception if some process is holding the file In-Reply-To: References: Message-ID: On Fri, 10 Sep 2021 09:23:52 GMT, Masanori Yano wrote: > Could you please review the 8233674 bug fixes? > This problem is caused by the antivirus software opening the file for a short time, so CreateFile() should be retried. It?s a good idea to ask the Microsoft folks about that, but I don't know the way to ask. Could you tell me how to do it? As you say, CreateFile function is used in other parts of the JDK, but it have a significant impact to fix all of that. Therefore, I fixed the problem about opening zip files and jar files which is reported in the JBS. ------------- PR: https://git.openjdk.java.net/jdk/pull/5460 From alanb at openjdk.java.net Mon Sep 27 08:07:53 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 27 Sep 2021 08:07:53 GMT Subject: RFR: 8233674: JarURLConnection.getJarFile throws Exception if some process is holding the file In-Reply-To: References: Message-ID: On Mon, 27 Sep 2021 07:40:26 GMT, Masanori Yano wrote: > It?s a good idea to ask the Microsoft folks about that, but I don't know the way to ask. Could you tell me how to do it? > > As you say, CreateFile function is used in other parts of the JDK, but it have a significant impact to fix all of that. Therefore, I fixed the problem about opening zip files and jar files which is reported in the JBS. I think we need to find out if the issue you are working around is a bug/issue with the virus checker or that Microsoft recommends that all applications should require to work these issues. As regards the patch then it is incomplete. If we are forced to put a workaround into the JDK code then I think it will have to do everywhere, not just for zip/JAR files. ------------- PR: https://git.openjdk.java.net/jdk/pull/5460 From alanb at openjdk.java.net Mon Sep 27 08:25:15 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 27 Sep 2021 08:25:15 GMT Subject: RFR: 8250678: ModuleDescriptor.Version parsing treats empty segments inconsistently In-Reply-To: <5FwhmsS85upnfXAKPCBCQTsWorJN17vOBFZXCN6iP8M=.377740a1-6f1e-4e37-9344-25a60ffdd891@github.com> References: <5FwhmsS85upnfXAKPCBCQTsWorJN17vOBFZXCN6iP8M=.377740a1-6f1e-4e37-9344-25a60ffdd891@github.com> Message-ID: <-RdwCCyA_gS04j8OgqlqsTAnTzGoQduJXjciYuwvh0w=.eb4ae2a2-63c0-4b5e-aca5-513cc3862790@github.com> On Fri, 24 Sep 2021 11:28:09 GMT, Masanori Yano wrote: > Could you please review the 8250678 bug fixes? > > 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/jdk18/docs/api/java.base/java/lang/module/ModuleDescriptor.Version.html > > Therefore, I propose to fix the parsing method of pre and build section in the same way as the version. I thin this is okay, just look unusual to have repeated punctuation creating the case where a component is empty. @mbreinhold may wish to comment on this PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/5679 From github.com+741251+turbanoff at openjdk.java.net Mon Sep 27 09:21:31 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Mon, 27 Sep 2021 09:21:31 GMT Subject: RFR: 8274333: Redundant null comparison after Pattern.split Message-ID: In couple of classes, result part of arrays of Pattern.split is compared with `null`. Pattern.split (and hence String.split) never returns `null` in array elements. Such comparisons are redundant. ------------- Commit messages: - [PATCH] Remove redundant 'null' comparison after Pattern.split Changes: https://git.openjdk.java.net/jdk/pull/5708/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5708&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274333 Stats: 15 lines in 2 files changed: 4 ins; 5 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/5708.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5708/head:pull/5708 PR: https://git.openjdk.java.net/jdk/pull/5708 From darcy at openjdk.java.net Mon Sep 27 09:29:09 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 27 Sep 2021 09:29:09 GMT Subject: RFR: 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields Message-ID: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> This is an initial PR for expanded lint warnings done under two bugs: 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields 8160675: Issue lint warning for non-serializable non-transient instance fields in serializable type to get feedback on the general approach and test strategy before further polishing the implementation. The implementation initially started as an annotation processor I wrote several years ago. The refined version being incorporated into Attr has been refactored, had its checks expanded, and been partially ported to idiomatic javac coding style rather than using the javax.lang.model API from annotation processing. Subsequent versions of this PR are expected to move the implementation closer to idiomatic javac, in particular to use javac flags rather than javax.lang.model.Modifier's. Additional resources keys will be defined for the serialization-related fields and methods not having the expected modifiers, types, etc. The resource keys for the existing checks related to serialVersionUID and reused. Please also review the corresponding CSRs: https://bugs.openjdk.java.net/browse/JDK-8274335 https://bugs.openjdk.java.net/browse/JDK-8274336 Informative serialization-related warning messages must take into account whether a class, interface, annotation, record, and enum is being analyzed. Enum classes and record classes have special handling in serialization. This implementation under review has been augmented with checks for interface types recommended by Chris Hegarty in an attachment on 8202056. The JDK build has the Xlint:serial check enabled. The build did not pass with the augmented checks. For most modules, this PR contains the library changes necessary for the build to pass. I will start separate PRs in those library areas to get the needed SuppressWarning("serial") or other changes in place. For one module, I temporarily disabled the Xlint:serial check. In terms of performance, I have not done benchmarks of the JDK build with and without these changes, but informally the build seems to take about as long as before. ------------- Commit messages: - Appease jcheck - Implement checks chegar recommended for interfaces. - Update comment. - Add tests for instance field checks. - Clean build with instance field checks in place. - Merge branch 'master' into JDK-8202056 - Put Externalizable checks last. - Add checks for constructor access in Serializable classes. - Add no-arg ctor check for Externalizable classes. - Improve Externalization warnings. - ... and 19 more: https://git.openjdk.java.net/jdk/compare/5756385c...d498ff5f Changes: https://git.openjdk.java.net/jdk/pull/5709/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5709&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8202056 Stats: 1519 lines in 79 files changed: 1511 ins; 1 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/5709.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5709/head:pull/5709 PR: https://git.openjdk.java.net/jdk/pull/5709 From simonis at openjdk.java.net Mon Sep 27 09:38:01 2021 From: simonis at openjdk.java.net (Volker Simonis) Date: Mon, 27 Sep 2021 09:38:01 GMT Subject: RFR: 8274242: Implement fast-path for ASCII-compatible CharsetEncoders on x86 In-Reply-To: References: Message-ID: <_Dzhdy1vRupNXlRezru6UpkvEJV3Vlr149pbkryW2I4=.4c6e5e5b-7026-4410-9848-2a8d12aa71f7@github.com> On Tue, 21 Sep 2021 21:58:48 GMT, Claes Redestad wrote: > This patch extends the `ISO_8859_1.implEncodeISOArray` intrinsic on x86 to work also for ASCII encoding, which makes for example the `UTF_8$Encoder` perform on par with (or outperform) similarly getting charset encoded bytes from a String. The former took a small performance hit in JDK 9, and the latter improved greatly in the same release. > > Extending the `EncodeIsoArray` intrinsics on other platforms should be possible, but I'm unfamiliar with the macro assembler in general and unlike the x86 intrinsic they don't use a simple vectorized mask to implement the latin-1 check. For example aarch64 seem to filter out the low bytes and then check if there's any bits set in the high bytes. Clever, but very different to the 0xFF80 2-byte mask that an ASCII test wants. src/hotspot/share/opto/c2compiler.cpp line 222: > 220: #if !defined(X86) > 221: return false; // not yet implemented > 222: #endif It might be a little more work, but I think it's cleaner to move the decision whether the intrinisc is supported into the Matcher like for most other intrinsics and keep this code here platform independent. Otherwise we will get an increasing cascade of ifdefs as people start implementing this for other platforms. ------------- PR: https://git.openjdk.java.net/jdk/pull/5621 From redestad at openjdk.java.net Mon Sep 27 11:26:53 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 27 Sep 2021 11:26:53 GMT Subject: RFR: 8274299: Make Method/Constructor/Field accessors @Stable In-Reply-To: References: Message-ID: On Sat, 25 Sep 2021 10:15:11 GMT, Peter Levart wrote: > This patch improves reflective access speed as shown by the included benchmarks: > > https://jmh.morethan.io/?gists=902f4b43519c4f96c7abcd14cdc2d27d,ac490481e3001c710d75d6071c10b23a > > ... and is also a prerequisite to make JEP 416 (Reimplement Core Reflection with Method Handle) perform better in some circumstances. This looks good, assuming Mandy is OK with extracting and adding to the microbenchmarks from JEP 416 A stray thought is why not most fields in `Field`/`Method`/`Constructor` are `final`, as my IDE suggests. I can't find any hotspot code that injects values to these fields. Experimentally changing most fields in `Field` to final seem to pass at least all the java/lang/reflect tests. Since this is a trusted package `@Stable` should then be pointless. ------------- Marked as reviewed by redestad (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5694 From redestad at openjdk.java.net Mon Sep 27 11:41:34 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 27 Sep 2021 11:41:34 GMT Subject: RFR: 8274242: Implement fast-path for ASCII-compatible CharsetEncoders on x86 [v2] In-Reply-To: References: Message-ID: > This patch extends the `ISO_8859_1.implEncodeISOArray` intrinsic on x86 to work also for ASCII encoding, which makes for example the `UTF_8$Encoder` perform on par with (or outperform) similarly getting charset encoded bytes from a String. The former took a small performance hit in JDK 9, and the latter improved greatly in the same release. > > Extending the `EncodeIsoArray` intrinsics on other platforms should be possible, but I'm unfamiliar with the macro assembler in general and unlike the x86 intrinsic they don't use a simple vectorized mask to implement the latin-1 check. For example aarch64 seem to filter out the low bytes and then check if there's any bits set in the high bytes. Clever, but very different to the 0xFF80 2-byte mask that an ASCII test wants. Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Tobias review ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5621/files - new: https://git.openjdk.java.net/jdk/pull/5621/files/8edc228f..12ab6ff5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5621&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5621&range=00-01 Stats: 10 lines in 3 files changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/5621.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5621/head:pull/5621 PR: https://git.openjdk.java.net/jdk/pull/5621 From redestad at openjdk.java.net Mon Sep 27 12:03:08 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 27 Sep 2021 12:03:08 GMT Subject: RFR: 8274242: Implement fast-path for ASCII-compatible CharsetEncoders on x86 [v2] In-Reply-To: <5lVTU7su0xmkfNlex-Pv_yoeuJpnoCyalI42oLSjGzg=.54d143bc-ede4-4ec8-a257-1538f43ea632@github.com> References: <5lVTU7su0xmkfNlex-Pv_yoeuJpnoCyalI42oLSjGzg=.54d143bc-ede4-4ec8-a257-1538f43ea632@github.com> Message-ID: On Mon, 27 Sep 2021 06:36:50 GMT, Tobias Hartmann wrote: > Should we remove the "iso" part from the method/class names? I'm open to suggestions, but I've not been able to think of anything better. `encodeISOOrASCII` doesn't seem helpful and since ASCII is a subset of the ISO-8859-1 encoding referred to by the "iso" moniker then the ASCII-only variant is technically encoding chars to valid ISO-8859-1. ------------- PR: https://git.openjdk.java.net/jdk/pull/5621 From redestad at openjdk.java.net Mon Sep 27 12:12:05 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 27 Sep 2021 12:12:05 GMT Subject: RFR: 8274242: Implement fast-path for ASCII-compatible CharsetEncoders on x86 [v3] In-Reply-To: References: Message-ID: > This patch extends the `ISO_8859_1.implEncodeISOArray` intrinsic on x86 to work also for ASCII encoding, which makes for example the `UTF_8$Encoder` perform on par with (or outperform) similarly getting charset encoded bytes from a String. The former took a small performance hit in JDK 9, and the latter improved greatly in the same release. > > Extending the `EncodeIsoArray` intrinsics on other platforms should be possible, but I'm unfamiliar with the macro assembler in general and unlike the x86 intrinsic they don't use a simple vectorized mask to implement the latin-1 check. For example aarch64 seem to filter out the low bytes and then check if there's any bits set in the high bytes. Clever, but very different to the 0xFF80 2-byte mask that an ASCII test wants. Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Add Matcher predicate to avoid changing shared code as non-x86 platforms implements support for the _encodeAsciiArray intrinsic ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5621/files - new: https://git.openjdk.java.net/jdk/pull/5621/files/12ab6ff5..9800a99a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5621&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5621&range=01-02 Stats: 17 lines in 6 files changed: 14 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5621.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5621/head:pull/5621 PR: https://git.openjdk.java.net/jdk/pull/5621 From redestad at openjdk.java.net Mon Sep 27 12:14:05 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 27 Sep 2021 12:14:05 GMT Subject: RFR: 8274242: Implement fast-path for ASCII-compatible CharsetEncoders on x86 [v3] In-Reply-To: <_Dzhdy1vRupNXlRezru6UpkvEJV3Vlr149pbkryW2I4=.4c6e5e5b-7026-4410-9848-2a8d12aa71f7@github.com> References: <_Dzhdy1vRupNXlRezru6UpkvEJV3Vlr149pbkryW2I4=.4c6e5e5b-7026-4410-9848-2a8d12aa71f7@github.com> Message-ID: On Mon, 27 Sep 2021 09:34:21 GMT, Volker Simonis wrote: >> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: >> >> Add Matcher predicate to avoid changing shared code as non-x86 platforms implements support for the _encodeAsciiArray intrinsic > > src/hotspot/share/opto/c2compiler.cpp line 222: > >> 220: #if !defined(X86) >> 221: return false; // not yet implemented >> 222: #endif > > It might be a little more work, but I think it's cleaner to move the decision whether the intrinisc is supported into the Matcher like for most other intrinsics and keep this code here platform independent. Otherwise we will get an increasing cascade of ifdefs as people start implementing this for other platforms. Not too much work. I recently introduced platform-specific `matcher_*.hpp` files, so since then adding a boolean constant is easy (no need to muck with the .ad files). ------------- PR: https://git.openjdk.java.net/jdk/pull/5621 From prappo at openjdk.java.net Mon Sep 27 12:15:23 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Mon, 27 Sep 2021 12:15:23 GMT Subject: RFR: 8274367: Re-indent stack-trace examples for Throwable.printStackTrace Message-ID: This PR fixes indentation in the examples in the doc comment for java.lang.Throwable#printStackTrace(). 1. Indentation in stack-trace output is significant. The cause of an exception is output on the same level of indentation as that of the exception. A suppressed exception is output at a deeper level of indentation than that of the containing exception. The last example for Throwable.printStackTrace violates this. 2. Indentation in examples for Throwable.printStackTrace that relate to suppressed exceptions is inconsistent with that of cause exceptions. ------------- Commit messages: - Initial commit Changes: https://git.openjdk.java.net/jdk/pull/5715/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5715&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274367 Stats: 21 lines in 1 file changed: 0 ins; 0 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/5715.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5715/head:pull/5715 PR: https://git.openjdk.java.net/jdk/pull/5715 From thartmann at openjdk.java.net Mon Sep 27 12:30:52 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Mon, 27 Sep 2021 12:30:52 GMT Subject: RFR: 8274242: Implement fast-path for ASCII-compatible CharsetEncoders on x86 [v3] In-Reply-To: References: <5lVTU7su0xmkfNlex-Pv_yoeuJpnoCyalI42oLSjGzg=.54d143bc-ede4-4ec8-a257-1538f43ea632@github.com> Message-ID: On Mon, 27 Sep 2021 11:59:54 GMT, Claes Redestad wrote: > > Should we remove the "iso" part from the method/class names? > > I'm open to suggestions, but I've not been able to think of anything better. `encodeISOOrASCII` doesn't seem helpful and since ASCII is a subset of the ISO-8859-1 encoding referred to by the "iso" moniker then the ASCII-only variant is technically encoding chars to valid ISO-8859-1. Okay, that's fine with me. ------------- PR: https://git.openjdk.java.net/jdk/pull/5621 From erikj at openjdk.java.net Mon Sep 27 13:01:58 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 27 Sep 2021 13:01:58 GMT Subject: RFR: 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields In-Reply-To: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> References: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> Message-ID: On Mon, 27 Sep 2021 01:00:18 GMT, Joe Darcy wrote: > This is an initial PR for expanded lint warnings done under two bugs: > > 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields > 8160675: Issue lint warning for non-serializable non-transient instance fields in serializable type > > to get feedback on the general approach and test strategy before further polishing the implementation. > > The implementation initially started as an annotation processor I wrote several years ago. The refined version being incorporated into Attr has been refactored, had its checks expanded, and been partially ported to idiomatic javac coding style rather than using the javax.lang.model API from annotation processing. > > Subsequent versions of this PR are expected to move the implementation closer to idiomatic javac, in particular to use javac flags rather than javax.lang.model.Modifier's. Additional resources keys will be defined for the serialization-related fields and methods not having the expected modifiers, types, etc. The resource keys for the existing checks related to serialVersionUID and reused. > > Please also review the corresponding CSRs: > > https://bugs.openjdk.java.net/browse/JDK-8274335 > https://bugs.openjdk.java.net/browse/JDK-8274336 > > Informative serialization-related warning messages must take into account whether a class, interface, annotation, record, and enum is being analyzed. Enum classes and record classes have special handling in serialization. This implementation under review has been augmented with checks for interface types recommended by Chris Hegarty in an attachment on 8202056. > > The JDK build has the Xlint:serial check enabled. The build did not pass with the augmented checks. For most modules, this PR contains the library changes necessary for the build to pass. I will start separate PRs in those library areas to get the needed SuppressWarning("serial") or other changes in place. For one module, I temporarily disabled the Xlint:serial check. > > In terms of performance, I have not done benchmarks of the JDK build with and without these changes, but informally the build seems to take about as long as before. Build change looks ok. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5709 From mullan at openjdk.java.net Mon Sep 27 13:18:26 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Mon, 27 Sep 2021 13:18:26 GMT Subject: RFR: 8274333: Redundant null comparison after Pattern.split In-Reply-To: References: Message-ID: On Sun, 26 Sep 2021 15:10:52 GMT, Andrey Turbanov wrote: > In couple of classes, result part of arrays of Pattern.split is compared with `null`. Pattern.split (and hence String.split) never returns `null` in array elements. Such comparisons are redundant. The AlgorithmDecomposer change looks fine to me. ------------- Marked as reviewed by mullan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5708 From rriggs at openjdk.java.net Mon Sep 27 14:17:01 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 27 Sep 2021 14:17:01 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v22] In-Reply-To: References: Message-ID: On Wed, 22 Sep 2021 10:27:45 GMT, Jaikiran Pai wrote: >> The commit in this PR implements the proposal for enhancement that was discussed in the core-libs-dev mailing list recently[1], for https://bugs.openjdk.java.net/browse/JDK-8231640 >> >> At a high level - the `store()` APIs in `Properties` have been modified to now look for the `SOURCE_DATE_EPOCH` environment variable[2]. If that env variable is set, then instead of writing out the current date time as a date comment, the `store()` APIs instead will use the value set for this env variable to parse it to a `Date` and write out the string form of such a date. The implementation here uses the `d MMM yyyy HH:mm:ss 'GMT'` date format and `Locale.ROOT` to format and write out such a date. This should provide reproducibility whenever the `SOURCE_DATE_EPOCH` is set. Furthermore, intentionally, no changes in the date format of the "current date" have been done. >> >> These modified `store()` APIs work in the presence of the `SecurityManager` too. The caller is expected to have a read permission on the `SOURCE_DATE_EPOCH` environment variable. If the caller doesn't have that permission, then the implementation of these `store()` APIs will write out the "current date" and will ignore any value that has been set for the `SOURCE_DATE_EPOCH` env variable. This should allow for backward compatibility of existing applications, where, when they run under a `SecurityManager` and perhaps with an existing restrictive policy file, the presence of `SOURCE_DATE_EPOCH` shouldn't impact their calls to the `store()` APIs. >> >> The modified `store()` APIs will also ignore any value for `SOURCE_DATE_EPOCH` that cannot be parsed to an `long` value. In such cases, the `store()` APIs will write out the "current date" and ignore the value set for this environment variable. No exceptions will be thrown for such invalid values. This is an additional backward compatibility precaution to prevent any rogue value for `SOURCE_DATE_EPOCH` from breaking applications. >> >> An additional change in the implementation of these `store()` APIs and unrelated to the date comment, is that these APIs will now write out the property keys in a deterministic order. The keys will be written out in the natural ordering as specified by `java.lang.String#compareTo()` API. >> >> The combination of the ordering of the property keys when written out and the usage of `SOURCE_DATE_EPOCH` environment value to determine the date comment should together allow for reproducibility of the output generated by these `store()` APIs. >> >> New jtreg test classes have been introduced to verify these changes. The primary focus of `PropertiesStoreTest` is the ordering aspects of the property keys that are written out. On the other hand `StoreReproducibilityTest` focuses on the reproducibility of the output generated by these APIs. The `StoreReproducibilityTest` runs these tests both in the presence and absence of `SecurityManager`. Plus, in the presence of SecurityManager, it tests both the scenarios where the caller is granted the requisite permission and in other case not granted that permission. >> >> These new tests and existing tests under `test/jdk/java/util/Properties/` pass with these changes. >> >> [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-August/080758.html >> [2] https://reproducible-builds.org/specs/source-date-epoch/ > > Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision: > > - Revert "Implement Mark's suggestion in CSR to include the java.properties.date in the list of system properties listed in System::getProperties()" > > Additional inputs since this specific commit was introduced have leaned towards not listing this property in System::getProperties() > > This reverts commit 458c1fd37cf1e8e8bd0a60a171d173ce5da12b7c. > - reduce the line length of code comment Looks good, thanks for the initiative, the followup on the comments, and finding the sweet spot in the goals, compatibility, and implementation constraints. ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5372 From github.com+43264149+iaroslavski at openjdk.java.net Mon Sep 27 16:17:21 2021 From: github.com+43264149+iaroslavski at openjdk.java.net (iaroslavski) Date: Mon, 27 Sep 2021 16:17:21 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v4] In-Reply-To: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> Message-ID: > Sorting: > > - adopt radix sort for sequential and parallel sorts on int/long/float/double arrays (almost random and length > 6K) > - fix tryMergeRuns() to better handle case when the last run is a single element > - minor javadoc and comment changes > > Testing: > - add new data inputs in tests for sorting > - add min/max/infinity values to float/double testing > - add tests for radix sort iaroslavski has updated the pull request incrementally with one additional commit since the last revision: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) Simplified mixed insertion sort ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3938/files - new: https://git.openjdk.java.net/jdk/pull/3938/files/6003fb69..adcc6942 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3938&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3938&range=02-03 Stats: 204 lines in 1 file changed: 52 ins; 96 del; 56 mod Patch: https://git.openjdk.java.net/jdk/pull/3938.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3938/head:pull/3938 PR: https://git.openjdk.java.net/jdk/pull/3938 From rriggs at openjdk.java.net Mon Sep 27 16:42:10 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 27 Sep 2021 16:42:10 GMT Subject: RFR: 8273790: Potential cyclic dependencies between Gregorian and CalendarSystem [v2] In-Reply-To: References: Message-ID: <4ARpOfOEr71m7Kp_h_AE85UzurZLj2KJHV8JhR8M7N4=.550892c2-7c74-4255-b24c-0df9ecc735e7@github.com> On Sat, 25 Sep 2021 03:38:24 GMT, Jaikiran Pai wrote: >> Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.java.net/browse/JDK-8273790? >> >> As noted in that issue, trying to class load `sun.util.calendar.CalendarSystem` and `sun.util.calendar.Gregorian` concurrently in separate threads can lead to a deadlock because of the cyclic nature of the code in their static initialization. More specifically, consider this case: >> >> - Thread T1 initiates a classload on the `sun.util.calendar.CalendarSystem`. >> - This gives T1 the implicit class init lock on `CalendarSystem`. >> - Consider thread T2 which at the same time initiates a classload on `sun.util.calendar.Gregorian` class. >> - This gives T2 a implicit class init lock on `Gregorian`. >> - T1, still holding a lock on `CalendarSystem` attempts to load `Gregorian` since it wants to create a (singleton) instance of `Gregorian` and assign it to the `static final GREGORIAN_INSTANCE` member. Since T2 is holding a class init lock on `Gregorian`, T1 ends up waiting >> - T2 on the other hand is still loading the `Gregorian` class. `Gregorian` itself "is a" `CalendarSystem`, so during this loading of `Gregorian` class, T2 starts travelling up the class hierarchy and asks for a lock on `CalendarSystem`. However T1 is holding this lock and as a result T2 ends up waiting on T1 which is waiting on T2. That triggers this deadlock. >> >> The linked JBS issue has a thread dump which shows this in action. >> >> The commit here delays the instance creation of `Gregorian` by moving that instance creation logic from the static initialization of the `CalendarSystem` class, to the first call to `CalendarSystem#getGregorianCalendar()`. This prevents the `CalendarSystem` from needing a lock on `Gregorian` during its static init (of course, unless some code in this static init flow calls `CalendarSystem#getGregorianCalendar()`, in which case it is back to square one. I have verified, both manually and through the jtreg test, that the code in question doesn't have such calls) >> >> A new jtreg test has been introduced to reproduce the issue and verify the fix. The test in addition to loading these 2 classes in question, also additionally loads a few other classes concurrently. These classes have specific static initialization which leads the calls to `CalendarSystem#getGregorianCalendar()` or `CalendarSystem#forName()`. Including these classes in the tests ensures that this deadlock hasn't "moved" to a different location. I have run multiple runs (approximately 25) of this test with the fix and I haven't seen it deadlock anymore. > > Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision: > > - Minor test adjustments as suggested by Naoto > - use a holder instead of volatile, as suggested by Roger ?? ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5683 From naoto at openjdk.java.net Mon Sep 27 16:42:09 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 27 Sep 2021 16:42:09 GMT Subject: RFR: 8273790: Potential cyclic dependencies between Gregorian and CalendarSystem [v2] In-Reply-To: References: Message-ID: On Sat, 25 Sep 2021 03:38:24 GMT, Jaikiran Pai wrote: >> Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.java.net/browse/JDK-8273790? >> >> As noted in that issue, trying to class load `sun.util.calendar.CalendarSystem` and `sun.util.calendar.Gregorian` concurrently in separate threads can lead to a deadlock because of the cyclic nature of the code in their static initialization. More specifically, consider this case: >> >> - Thread T1 initiates a classload on the `sun.util.calendar.CalendarSystem`. >> - This gives T1 the implicit class init lock on `CalendarSystem`. >> - Consider thread T2 which at the same time initiates a classload on `sun.util.calendar.Gregorian` class. >> - This gives T2 a implicit class init lock on `Gregorian`. >> - T1, still holding a lock on `CalendarSystem` attempts to load `Gregorian` since it wants to create a (singleton) instance of `Gregorian` and assign it to the `static final GREGORIAN_INSTANCE` member. Since T2 is holding a class init lock on `Gregorian`, T1 ends up waiting >> - T2 on the other hand is still loading the `Gregorian` class. `Gregorian` itself "is a" `CalendarSystem`, so during this loading of `Gregorian` class, T2 starts travelling up the class hierarchy and asks for a lock on `CalendarSystem`. However T1 is holding this lock and as a result T2 ends up waiting on T1 which is waiting on T2. That triggers this deadlock. >> >> The linked JBS issue has a thread dump which shows this in action. >> >> The commit here delays the instance creation of `Gregorian` by moving that instance creation logic from the static initialization of the `CalendarSystem` class, to the first call to `CalendarSystem#getGregorianCalendar()`. This prevents the `CalendarSystem` from needing a lock on `Gregorian` during its static init (of course, unless some code in this static init flow calls `CalendarSystem#getGregorianCalendar()`, in which case it is back to square one. I have verified, both manually and through the jtreg test, that the code in question doesn't have such calls) >> >> A new jtreg test has been introduced to reproduce the issue and verify the fix. The test in addition to loading these 2 classes in question, also additionally loads a few other classes concurrently. These classes have specific static initialization which leads the calls to `CalendarSystem#getGregorianCalendar()` or `CalendarSystem#forName()`. Including these classes in the tests ensures that this deadlock hasn't "moved" to a different location. I have run multiple runs (approximately 25) of this test with the fix and I haven't seen it deadlock anymore. > > Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision: > > - Minor test adjustments as suggested by Naoto > - use a holder instead of volatile, as suggested by Roger Looks good. Thank you for the fix! ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5683 From mchung at openjdk.java.net Mon Sep 27 17:00:10 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 27 Sep 2021 17:00:10 GMT Subject: Integrated: JDK-8274311: Make build.tools.jigsaw.GenGraphs more configurable In-Reply-To: References: Message-ID: On Fri, 24 Sep 2021 23:07:33 GMT, Mandy Chung wrote: > GenGraphs tool generates the module graph. It currently supports the configuration via javadoc-graphs.properties. However, `make/jdk/src/classes/build/tools/jigsaw/javadoc-graphs.properties` only documents two properties. It should be updated to cover all configurable properties. > > There are a couple other properties not configurable such as nodesep and node margin. This extends the configuration to allow to set additional properties. > > This also fixes `requiresMandatedColor` in javadoc-graphs.properties to light gray to match the default configuration in the implementation, i.e. the color of the edge to java.base. It seems a bug that was unnoticed until Alex and Iris spotted it. This pull request has now been integrated. Changeset: daaa47e2 Author: Mandy Chung URL: https://git.openjdk.java.net/jdk/commit/daaa47e2005cfa1d72f94a32e7756255f24c4d1f Stats: 167 lines in 3 files changed: 100 ins; 33 del; 34 mod 8274311: Make build.tools.jigsaw.GenGraphs more configurable Reviewed-by: alanb, iris ------------- PR: https://git.openjdk.java.net/jdk/pull/5690 From mchung at openjdk.java.net Mon Sep 27 17:04:58 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 27 Sep 2021 17:04:58 GMT Subject: RFR: 8274299: Make Method/Constructor/Field accessors @Stable In-Reply-To: References: Message-ID: On Sat, 25 Sep 2021 10:15:11 GMT, Peter Levart wrote: > This patch improves reflective access speed as shown by the included benchmarks: > > https://jmh.morethan.io/?gists=902f4b43519c4f96c7abcd14cdc2d27d,ac490481e3001c710d75d6071c10b23a > > ... and is also a prerequisite to make JEP 416 (Reimplement Core Reflection with Method Handle) perform better in some circumstances. Adding to Peter's description - separating this patch from JEP 416 will give some bake time on this change of the existing core reflection implementation. When JEP 416 is integrated, it will switch the new implementation and the changes in `*AccessorImpl` will not be exercised. In addition, this will make the backport easier if desirable. ------------- PR: https://git.openjdk.java.net/jdk/pull/5694 From dfuchs at openjdk.java.net Mon Sep 27 17:08:06 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Mon, 27 Sep 2021 17:08:06 GMT Subject: RFR: 8274276: Cache normalizedBase URL in URLClassPath.FileLoader [v2] In-Reply-To: References: Message-ID: On Fri, 24 Sep 2021 11:50:21 GMT, ?????? ??????? wrote: >> Currently on each invocation of `URLClassPath.FileLoader.getResource()` `normalizedBase` URL is recalculated using same final `baseURL` from parent class. This can be avoided giving significant improvement in memory consumption. Consider the benchmark: >> >> @State(Scope.Benchmark) >> @BenchmarkMode(Mode.AverageTime) >> @OutputTimeUnit(TimeUnit.NANOSECONDS) >> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) >> public class URLClassPathBenchmark { >> private final ClassLoader classLoader = getClass().getClassLoader(); >> >> @Benchmark >> public URL getResource() { >> return classLoader.getResource("file:./config/application.properties"); >> } >> } >> >> it demonstrates improvement brought in by this patch: >> >> before >> Benchmark Mode Cnt Score Error Units >> URLClassPathBenchmark.getResource avgt 50 2840,746 ? 22,206 ns/op >> URLClassPathBenchmark.getResource:?gc.alloc.rate avgt 50 645,313 ? 8,072 MB/sec >> URLClassPathBenchmark.getResource:?gc.alloc.rate.norm avgt 50 2403,258 ? 17,639 B/op >> URLClassPathBenchmark.getResource:?gc.churn.G1_Eden_Space avgt 50 656,624 ? 116,090 MB/sec >> URLClassPathBenchmark.getResource:?gc.churn.G1_Eden_Space.norm avgt 50 2450,175 ? 440,011 B/op >> URLClassPathBenchmark.getResource:?gc.churn.G1_Survivor_Space avgt 50 0,123 ? 0,149 MB/sec >> URLClassPathBenchmark.getResource:?gc.churn.G1_Survivor_Space.norm avgt 50 0,459 ? 0,556 B/op >> URLClassPathBenchmark.getResource:?gc.count avgt 50 67,000 counts >> URLClassPathBenchmark.getResource:?gc.time avgt 50 117,000 ms >> >> after >> Benchmark Mode Cnt Score Error Units >> URLClassPathBenchmark.getResource avgt 100 2596,719 ? 9,786 ns/op >> URLClassPathBenchmark.getResource:?gc.alloc.rate avgt 100 448,780 ? 1,684 MB/sec >> URLClassPathBenchmark.getResource:?gc.alloc.rate.norm avgt 100 1528,040 ? 0,005 B/op >> URLClassPathBenchmark.getResource:?gc.churn.G1_Eden_Space avgt 100 479,905 ? 23,369 MB/sec >> URLClassPathBenchmark.getResource:?gc.churn.G1_Eden_Space.norm avgt 100 1634,314 ? 79,821 B/op >> URLClassPathBenchmark.getResource:?gc.churn.G1_Survivor_Space avgt 100 0,101 ? 0,097 MB/sec >> URLClassPathBenchmark.getResource:?gc.churn.G1_Survivor_Space.norm avgt 100 0,345 ? 0,329 B/op >> URLClassPathBenchmark.getResource:?gc.count avgt 100 98,000 counts >> URLClassPathBenchmark.getResource:?gc.time avgt 100 218,000 ms > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8274276: Make URLClassPath.Loader.getBaseURL() final OK - LGTM. I have run tier1 and tier2 on your changes in our CI and nothing unexpected came up. ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5677 From mchung at openjdk.java.net Mon Sep 27 17:23:59 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 27 Sep 2021 17:23:59 GMT Subject: RFR: 8274299: Make Method/Constructor/Field accessors @Stable In-Reply-To: References: Message-ID: On Mon, 27 Sep 2021 11:23:43 GMT, Claes Redestad wrote: > This looks good, assuming Mandy is OK with extracting and adding to the microbenchmarks from JEP 416 I'm okay to include these microbenchmarks in this patch. I will merge the change with JEP 416. > A stray thought is why not most fields in `Field`/`Method`/`Constructor` are `final`, as my IDE suggests. I can't find any hotspot code that injects values to these fields. See `Reflection::new_method` and `Reflection::new_field`. > Experimentally changing most fields in `Field` to final seem to pass at least all the java/lang/reflect tests. Since this is a trusted package `@Stable` should then be pointless. This reminds to double check [1] and realized that `java.lang.reflect` is not in the list of trusted packages for `@Stable`. I'll add that in JEP 416. [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/ci/ciField.cpp#L219 ------------- PR: https://git.openjdk.java.net/jdk/pull/5694 From mchung at openjdk.java.net Mon Sep 27 17:35:20 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 27 Sep 2021 17:35:20 GMT Subject: RFR: 8274299: Make Method/Constructor/Field accessors @Stable In-Reply-To: References: Message-ID: On Sat, 25 Sep 2021 10:15:11 GMT, Peter Levart wrote: > This patch improves reflective access speed as shown by the included benchmarks: > > https://jmh.morethan.io/?gists=902f4b43519c4f96c7abcd14cdc2d27d,ac490481e3001c710d75d6071c10b23a > > ... and is also a prerequisite to make JEP 416 (Reimplement Core Reflection with Method Handle) perform better in some circumstances. Looks good to me. Very nice performance improvement. One minor comment: I think the change in `UnsafeFieldAccessorImpl.java` and `UnsafeStaticFieldAccessorImpl.java` isn't necessary since they're final fields. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5694 From mchung at openjdk.java.net Mon Sep 27 17:42:57 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 27 Sep 2021 17:42:57 GMT Subject: RFR: 8274367: Re-indent stack-trace examples for Throwable.printStackTrace In-Reply-To: References: Message-ID: On Mon, 27 Sep 2021 12:04:48 GMT, Pavel Rappo wrote: > This PR fixes indentation in the examples in the doc comment for java.lang.Throwable#printStackTrace(). > > 1. Indentation in stack-trace output is significant. The cause of an exception is output on the same level of indentation as that of the exception. A suppressed exception is output at a deeper level of indentation than that of the containing exception. The last example for Throwable.printStackTrace violates this. > > 2. Indentation in examples for Throwable.printStackTrace that relate to suppressed exceptions is inconsistent with that of cause exceptions. Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5715 From iris at openjdk.java.net Mon Sep 27 17:52:13 2021 From: iris at openjdk.java.net (Iris Clark) Date: Mon, 27 Sep 2021 17:52:13 GMT Subject: RFR: 8274367: Re-indent stack-trace examples for Throwable.printStackTrace In-Reply-To: References: Message-ID: On Mon, 27 Sep 2021 12:04:48 GMT, Pavel Rappo wrote: > This PR fixes indentation in the examples in the doc comment for java.lang.Throwable#printStackTrace(). > > 1. Indentation in stack-trace output is significant. The cause of an exception is output on the same level of indentation as that of the exception. A suppressed exception is output at a deeper level of indentation than that of the containing exception. The last example for Throwable.printStackTrace violates this. > > 2. Indentation in examples for Throwable.printStackTrace that relate to suppressed exceptions is inconsistent with that of cause exceptions. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5715 From darcy at openjdk.java.net Mon Sep 27 18:55:18 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 27 Sep 2021 18:55:18 GMT Subject: RFR: 8274391: Suppress more warnings on non-serializable non-transient instance fields in java.util.concurrent Message-ID: Follow-up change to JDK-8232230, augmentations to javac's Xlint:serial checking are out for review (https://github.com/openjdk/jdk/pull/5709) and java.util.concurrent would need some changes to pass under the expanded checks. The changes are to suppress warnings where non-transient fields in serializable types are not declared with a type statically known to be serializable. That isn't necessarily a correctness issues, but it does merit further scrutiny. In ForkJoinTask, the SuppressWarnings annotation previously applied in JDK-8232230, seems to have been misplaced to a different field; this change corrects it. ------------- Commit messages: - 8274391: Suppress more warnings on non-serializable non-transient instance fields in java.util.concurrent Changes: https://git.openjdk.java.net/jdk/pull/5718/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5718&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274391 Stats: 3 lines in 2 files changed: 2 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5718.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5718/head:pull/5718 PR: https://git.openjdk.java.net/jdk/pull/5718 From darcy at openjdk.java.net Mon Sep 27 19:03:23 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 27 Sep 2021 19:03:23 GMT Subject: RFR: 8274392: Suppress more warnings on non-serializable non-transient instance fields in java.sql.rowset Message-ID: Follow-up change to JDK-8231442, augmentations to javac's Xlint:serial checking are out for review (#5709) and java.sql.rowset would need some changes to pass under the expanded checks. The changes are to suppress warnings where non-transient fields in serializable types are not declared with a type statically known to be serializable. That isn't necessarily a correctness issues, but it does merit further scrutiny. ------------- Commit messages: - 8274392: Suppress more warnings on non-serializable non-transient instance fields in java.sql.rowset Changes: https://git.openjdk.java.net/jdk/pull/5719/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5719&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274392 Stats: 13 lines in 7 files changed: 13 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5719.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5719/head:pull/5719 PR: https://git.openjdk.java.net/jdk/pull/5719 From lancea at openjdk.java.net Mon Sep 27 19:06:56 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 27 Sep 2021 19:06:56 GMT Subject: RFR: 8274391: Suppress more warnings on non-serializable non-transient instance fields in java.util.concurrent In-Reply-To: References: Message-ID: On Mon, 27 Sep 2021 18:40:10 GMT, Joe Darcy wrote: > Follow-up change to JDK-8232230, augmentations to javac's Xlint:serial checking are out for review (https://github.com/openjdk/jdk/pull/5709) and java.util.concurrent would need some changes to pass under the expanded checks. > > The changes are to suppress warnings where non-transient fields in serializable types are not declared with a type statically known to be serializable. That isn't necessarily a correctness issues, but it does merit further scrutiny. > > In ForkJoinTask, the SuppressWarnings annotation previously applied in JDK-8232230, seems to have been misplaced to a different field; this change corrects it. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5718 From bpb at openjdk.java.net Mon Sep 27 19:12:54 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 27 Sep 2021 19:12:54 GMT Subject: RFR: 8274391: Suppress more warnings on non-serializable non-transient instance fields in java.util.concurrent In-Reply-To: References: Message-ID: <019n3vYHKb-TPg9uMel5PNzz5JGnfmXYEyQgaMJdlBs=.15caa751-4139-4852-aa4b-5f54a4b6c66e@github.com> On Mon, 27 Sep 2021 18:40:10 GMT, Joe Darcy wrote: > Follow-up change to JDK-8232230, augmentations to javac's Xlint:serial checking are out for review (https://github.com/openjdk/jdk/pull/5709) and java.util.concurrent would need some changes to pass under the expanded checks. > > The changes are to suppress warnings where non-transient fields in serializable types are not declared with a type statically known to be serializable. That isn't necessarily a correctness issues, but it does merit further scrutiny. > > In ForkJoinTask, the SuppressWarnings annotation previously applied in JDK-8232230, seems to have been misplaced to a different field; this change corrects it. Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5718 From bpb at openjdk.java.net Mon Sep 27 19:14:17 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 27 Sep 2021 19:14:17 GMT Subject: RFR: 8274392: Suppress more warnings on non-serializable non-transient instance fields in java.sql.rowset In-Reply-To: References: Message-ID: On Mon, 27 Sep 2021 18:51:37 GMT, Joe Darcy wrote: > Follow-up change to JDK-8231442, augmentations to javac's Xlint:serial checking are out for review (#5709) and java.sql.rowset would need some changes to pass under the expanded checks. > > The changes are to suppress warnings where non-transient fields in serializable types are not declared with a type statically known to be serializable. That isn't necessarily a correctness issues, but it does merit further scrutiny. Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5719 From mchung at openjdk.java.net Mon Sep 27 19:21:05 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 27 Sep 2021 19:21:05 GMT Subject: RFR: 8266936: Add a finalization JFR event [v14] In-Reply-To: References: Message-ID: On Sat, 25 Sep 2021 14:22:28 GMT, Markus Gr?nlund wrote: >> Greetings, >> >> Object.finalize() was deprecated in JDK9. There is an ongoing effort to replace and mitigate Object.finalize() uses in the JDK libraries; please see https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. >> >> We also like to assist users in replacing and mitigating uses in non-JDK code. >> >> Hence, this changeset adds a periodic JFR event to help identify which classes are overriding Object.finalize(). >> >> Thanks >> Markus > > Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: > > symbols-unix I reviewed the change in java.base that looks good. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4731 From lancea at openjdk.java.net Mon Sep 27 19:30:55 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 27 Sep 2021 19:30:55 GMT Subject: RFR: 8274392: Suppress more warnings on non-serializable non-transient instance fields in java.sql.rowset In-Reply-To: References: Message-ID: On Mon, 27 Sep 2021 18:51:37 GMT, Joe Darcy wrote: > Follow-up change to JDK-8231442, augmentations to javac's Xlint:serial checking are out for review (#5709) and java.sql.rowset would need some changes to pass under the expanded checks. > > The changes are to suppress warnings where non-transient fields in serializable types are not declared with a type statically known to be serializable. That isn't necessarily a correctness issues, but it does merit further scrutiny. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5719 From github.com+741251+turbanoff at openjdk.java.net Mon Sep 27 19:41:50 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Mon, 27 Sep 2021 19:41:50 GMT Subject: RFR: 8274394: Use Optional.isEmpty instead of !Optional.isPresent in jdk.jlink Message-ID: <7v27BGJ2oB6FbGGeNP0pibG52dTr4A1k87eTrQjf5ZQ=.dc5298db-07bd-45b5-85f4-38e87c4e6309@github.com> I propose to replace usages of !Optional.isPresent() with Optional.isEmpty method. It's makes code a bit easier to read. Noticing negation before long chain of method calls is hard. ------------- Commit messages: - [PATCH] Use Optional.isEmpty instead of !Optional.isPresent in jdk.jlink Changes: https://git.openjdk.java.net/jdk/pull/5707/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5707&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274394 Stats: 8 lines in 5 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/5707.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5707/head:pull/5707 PR: https://git.openjdk.java.net/jdk/pull/5707 From darcy at openjdk.java.net Mon Sep 27 19:56:10 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 27 Sep 2021 19:56:10 GMT Subject: RFR: 8274392: Suppress more warnings on non-serializable non-transient instance fields in java.sql.rowset [v2] In-Reply-To: References: Message-ID: <_PV3DCzcSyt8w9R6ri5yS2JNDk1oeBYuVSZ59CkWTIg=.1d58505e-be42-4c30-ad90-f2acfb8dfaf8@github.com> > Follow-up change to JDK-8231442, augmentations to javac's Xlint:serial checking are out for review (#5709) and java.sql.rowset would need some changes to pass under the expanded checks. > > The changes are to suppress warnings where non-transient fields in serializable types are not declared with a type statically known to be serializable. That isn't necessarily a correctness issues, but it does merit further scrutiny. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Update copyrights. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5719/files - new: https://git.openjdk.java.net/jdk/pull/5719/files/70747989..f0faf468 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5719&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5719&range=00-01 Stats: 5 lines in 5 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/5719.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5719/head:pull/5719 PR: https://git.openjdk.java.net/jdk/pull/5719 From darcy at openjdk.java.net Mon Sep 27 20:01:05 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 27 Sep 2021 20:01:05 GMT Subject: Integrated: 8274392: Suppress more warnings on non-serializable non-transient instance fields in java.sql.rowset In-Reply-To: References: Message-ID: On Mon, 27 Sep 2021 18:51:37 GMT, Joe Darcy wrote: > Follow-up change to JDK-8231442, augmentations to javac's Xlint:serial checking are out for review (#5709) and java.sql.rowset would need some changes to pass under the expanded checks. > > The changes are to suppress warnings where non-transient fields in serializable types are not declared with a type statically known to be serializable. That isn't necessarily a correctness issues, but it does merit further scrutiny. This pull request has now been integrated. Changeset: 5b660f33 Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/5b660f3347917201902d501f371530a97c768977 Stats: 18 lines in 7 files changed: 13 ins; 0 del; 5 mod 8274392: Suppress more warnings on non-serializable non-transient instance fields in java.sql.rowset Reviewed-by: bpb, lancea ------------- PR: https://git.openjdk.java.net/jdk/pull/5719 From mchung at openjdk.java.net Mon Sep 27 20:02:12 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 27 Sep 2021 20:02:12 GMT Subject: RFR: 8274299: Make Method/Constructor/Field accessors @Stable In-Reply-To: References: Message-ID: <9r_Kwce_uft46hoiysojJLNfJH2rtF20WB-B3XqNwsA=.b6820b8d-ad31-44cc-99d6-d53b92e1c8ee@github.com> On Mon, 27 Sep 2021 11:23:43 GMT, Claes Redestad wrote: > A stray thought is why not most fields in `Field`/`Method`/`Constructor` are `final`, as my IDE suggests. I can't find any hotspot code that injects values to these fields. Experimentally changing most fields in `Field` to final seem to pass at least all the java/lang/reflect tests. Since this is a trusted package `@Stable` should then be pointless. This is a good observation. I took another look. The only place to set those fields are in `Reflection:new_field/new_method/new_constructor`. Making the fields that set by the Method/Field/Constructor constructor be final is a good idea! Those final fields don't need to be `@Stable`. One thing I'm puzzling is why the performance result is better but `java.lang.reflect` is not in the TNSFF package list. ------------- PR: https://git.openjdk.java.net/jdk/pull/5694 From redestad at openjdk.java.net Mon Sep 27 20:13:02 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 27 Sep 2021 20:13:02 GMT Subject: RFR: 8274299: Make Method/Constructor/Field accessors @Stable In-Reply-To: <9r_Kwce_uft46hoiysojJLNfJH2rtF20WB-B3XqNwsA=.b6820b8d-ad31-44cc-99d6-d53b92e1c8ee@github.com> References: <9r_Kwce_uft46hoiysojJLNfJH2rtF20WB-B3XqNwsA=.b6820b8d-ad31-44cc-99d6-d53b92e1c8ee@github.com> Message-ID: On Mon, 27 Sep 2021 19:59:00 GMT, Mandy Chung wrote: > One thing I'm puzzling is why the performance result is better but `java.lang.reflect` is not in the TNSFF package list. I think for deciding if a field can be treated as constant, `@Stable` has equal weight as a final in a TNSFF package, see https://github.com/openjdk/jdk/blob/master/src/hotspot/share/ci/ciField.cpp#L287 Adding java/lang/reflect to the trusted package list seem reasonable, though. ------------- PR: https://git.openjdk.java.net/jdk/pull/5694 From redestad at openjdk.java.net Mon Sep 27 20:17:02 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 27 Sep 2021 20:17:02 GMT Subject: RFR: 8274299: Make Method/Constructor/Field accessors @Stable In-Reply-To: References: Message-ID: <3unf6L57x1L8auo2OZg3Qwdo_zG4Cw5puBQ7ijvA7vU=.c157a5e7-fe06-42d6-8a02-2cfab4dd0375@github.com> On Mon, 27 Sep 2021 17:21:09 GMT, Mandy Chung wrote: > This reminds to double check [1] and realized that `java.lang.reflect` is not in the list of trusted packages for `@Stable`. I'll add that in JEP 416. > > [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/ci/ciField.cpp#L219 Gotcha, I misremembered it as-if all packages under java/lang were already considered to be in that list. ------------- PR: https://git.openjdk.java.net/jdk/pull/5694 From brian.goetz at oracle.com Mon Sep 27 20:41:00 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 27 Sep 2021 16:41:00 -0400 Subject: Discussion: easier Stream closing In-Reply-To: References: Message-ID: <2606ed74-927c-3c57-aa40-a8811f20883f@oracle.com> In Java 8, I think we were reluctant to lean on the idiom of "pass me a lambda and I'll pass it the confined data"), because Java developers were already struggling to understand lambdas.? But now that we're mostly over that hurdle, API points that accept Consumer are a powerful way to gain confinement (as we've seen in StackWalker, and also in the explorations of ScopeLocal in Loom.)? So I have no objection to this idiom. I have some concern that putting these side-by-side with existing Files.walk(...) methods will be a source of confusion, creating two different ways to do the same thing. I would rather not add anything new to BaseStream; it was a mistake to expose at all, and I'd rather see it deprecated than add more to it.? However, adding it individually to the Stream implementations is equivalent, and doesn't have this problem. The consumeAndClose approach is clever, in that it adds one API point that works for all streams, rather than having to add a new API point for every factory of a closeable stream; on the other hand, it is dramatically less discoverable, and so requires more education to get people to use it (and, as you say, has the exception problem.) On 9/26/2021 5:27 AM, Tagir Valeev wrote: > Hello! > > With current NIO file API, a very simple problem to get the list of > all files in the directory requires some ceremony: > > List paths; > try (Stream stream = Files.list(Path.of("/etc"))) { > paths = stream.toList(); > } > > If we skip try-with-resources, we may experience OS file handles leak, > so it's desired to keep it. Yet, it requires doing boring stuff. In > this sense, classic new File("/etc").list() was somewhat more > convenient (despite its awful error handling). > > I like how this problem is solved in StackWalker API [1]: it limits > the lifetime of the Stream by requiring a user-specified function to > consume it. After the function is applied, the stream is closed > automatically. We could add a similar overload to the Files API. As an > additional feature, we could also translate all UncheckedIOException's > back to IOException for more uniform exception processing: > > /** > * @param dir The path to the directory > * @param function function to apply to the stream of directory files > * @param type of the result > * @return result of the function > * @throws IOException if an I/O error occurs when opening the directory, or > * UncheckedIOException is thrown by the supplied function. > */ > public static T list(Path dir, Function, ? > extends T> function) throws IOException { > try (Stream stream = Files.list(dir)) { > return function.apply(stream); > } > catch (UncheckedIOException exception) { > throw exception.getCause(); > } > } > > In this case, getting the List of all files in the directory will be > as simple as > > List paths = Files.list(Path.of("/etc"), Stream::toList); > This doesn't limit the flexibility. For example, if we need only file > names instead of full paths, we can do this: > List paths = Files.list(Path.of("/etc"), s -> > s.map(Path::getFileName).toList()); > > Alternatively, we could enhance the BaseStream interface in a similar > way. It won't allow us to translate exceptions, but could be useful > for every stream that must be closed after consumption: > > // in BaseStream: > > /** > * Apply a given function to this stream, then close the stream. > * No further operation on the stream will be possible after that. > * > * @param function function to apply > * @param type of the function result > * @return result of the function > * @see #close() > */ > default R consumeAndClose(Function function) { > try(@SuppressWarnings("unchecked") S s = (S) this) { > return function.apply(s); > } > } > > The usage would be a little bit longer but still more pleasant than > explicit try-with-resources: > > List list = Files.list(Path.of("/etc")).consumeAndClose(Stream::toList); > > On the other hand, in this case, we are free to put intermediate > operations outside of consumeAndClose, so we won't need to nest > everything inside the function. Only terminal operation should be > placed inside the consumeAndClose. E.g., if we need file names only, > like above, we can do this: > > List list = > Files.list(Path.of("/etc")).map(Path::getFileName).consumeAndClose(Stream::toList); > > What do you think? > > > [1] https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/StackWalker.html#walk(java.util.function.Function) From prr at openjdk.java.net Mon Sep 27 21:20:47 2021 From: prr at openjdk.java.net (Phil Race) Date: Mon, 27 Sep 2021 21:20:47 GMT Subject: RFR: 8274397: [macOS] Stop setting env. var JAVA_MAIN_CLASS_ in launcher code Message-ID: <8j-vMsDYbF5100Dpc1DP_JGNV5V0W0D7i2fP7QnXCpU=.9169a246-f866-49c5-99fb-04f9fb946b9e@github.com> macOS launcher code sets JAVA_MAIN_CLASS_ which is read by AWT to set the name of the application in the system menu bar. Because this set shortly after the VM is running, it causes a thread safety issue described in https://bugs.openjdk.java.net/browse/JDK-8270549 Since the AWT already looks for the system property "apple.awt.application.name" for this same purpose, we can set that instead of the env. var and avoid the threading issue. This trades the JAVA_MAIN_CLASS_ pollution of the environment for setting a system property which is visible to apps as well but it seems a reasonable trade-off since we already (implicitly) support this variable anyway in preference to the env. var. ------------- Commit messages: - 8274397: [macOS] Stop setting env. var JAVA_MAIN_CLASS_ in launcher code - 8274397: [macOS] Stop setting env. var JAVA_MAIN_CLASS_ in launcher code Changes: https://git.openjdk.java.net/jdk/pull/5724/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5724&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274397 Stats: 75 lines in 2 files changed: 33 ins; 33 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/5724.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5724/head:pull/5724 PR: https://git.openjdk.java.net/jdk/pull/5724 From ihse at openjdk.java.net Mon Sep 27 21:24:06 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 27 Sep 2021 21:24:06 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v22] In-Reply-To: References: Message-ID: On Wed, 22 Sep 2021 10:27:45 GMT, Jaikiran Pai wrote: >> The commit in this PR implements the proposal for enhancement that was discussed in the core-libs-dev mailing list recently[1], for https://bugs.openjdk.java.net/browse/JDK-8231640 >> >> At a high level - the `store()` APIs in `Properties` have been modified to now look for the `SOURCE_DATE_EPOCH` environment variable[2]. If that env variable is set, then instead of writing out the current date time as a date comment, the `store()` APIs instead will use the value set for this env variable to parse it to a `Date` and write out the string form of such a date. The implementation here uses the `d MMM yyyy HH:mm:ss 'GMT'` date format and `Locale.ROOT` to format and write out such a date. This should provide reproducibility whenever the `SOURCE_DATE_EPOCH` is set. Furthermore, intentionally, no changes in the date format of the "current date" have been done. >> >> These modified `store()` APIs work in the presence of the `SecurityManager` too. The caller is expected to have a read permission on the `SOURCE_DATE_EPOCH` environment variable. If the caller doesn't have that permission, then the implementation of these `store()` APIs will write out the "current date" and will ignore any value that has been set for the `SOURCE_DATE_EPOCH` env variable. This should allow for backward compatibility of existing applications, where, when they run under a `SecurityManager` and perhaps with an existing restrictive policy file, the presence of `SOURCE_DATE_EPOCH` shouldn't impact their calls to the `store()` APIs. >> >> The modified `store()` APIs will also ignore any value for `SOURCE_DATE_EPOCH` that cannot be parsed to an `long` value. In such cases, the `store()` APIs will write out the "current date" and ignore the value set for this environment variable. No exceptions will be thrown for such invalid values. This is an additional backward compatibility precaution to prevent any rogue value for `SOURCE_DATE_EPOCH` from breaking applications. >> >> An additional change in the implementation of these `store()` APIs and unrelated to the date comment, is that these APIs will now write out the property keys in a deterministic order. The keys will be written out in the natural ordering as specified by `java.lang.String#compareTo()` API. >> >> The combination of the ordering of the property keys when written out and the usage of `SOURCE_DATE_EPOCH` environment value to determine the date comment should together allow for reproducibility of the output generated by these `store()` APIs. >> >> New jtreg test classes have been introduced to verify these changes. The primary focus of `PropertiesStoreTest` is the ordering aspects of the property keys that are written out. On the other hand `StoreReproducibilityTest` focuses on the reproducibility of the output generated by these APIs. The `StoreReproducibilityTest` runs these tests both in the presence and absence of `SecurityManager`. Plus, in the presence of SecurityManager, it tests both the scenarios where the caller is granted the requisite permission and in other case not granted that permission. >> >> These new tests and existing tests under `test/jdk/java/util/Properties/` pass with these changes. >> >> [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-August/080758.html >> [2] https://reproducible-builds.org/specs/source-date-epoch/ > > Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision: > > - Revert "Implement Mark's suggestion in CSR to include the java.properties.date in the list of system properties listed in System::getProperties()" > > Additional inputs since this specific commit was introduced have leaned towards not listing this property in System::getProperties() > > This reverts commit 458c1fd37cf1e8e8bd0a60a171d173ce5da12b7c. > - reduce the line length of code comment I agree with Roger. It's hard to understand the amount of work you have put into this when you only look at the small, resulting patch. Thank you for pulling this through! ------------- PR: https://git.openjdk.java.net/jdk/pull/5372 From igraves at openjdk.java.net Mon Sep 27 21:26:25 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Mon, 27 Sep 2021 21:26:25 GMT Subject: RFR: 8217501: Matcher.hitEnd returns false for incomplete surrogate pairs Message-ID: <_TCTxYX6dwrAWayE754OcOG8WvO2WMpMeF_NtSMlRMw=.7bb2ac10-0ff1-423b-9e47-b6bdf5303ebd@github.com> Fixing a bug where character matcher doesn't mark hitEnd as true if it's a code point with more than one character. ------------- Commit messages: - 8217501: Matcher.hitEnd returns false for incomplete surrogate pairs Changes: https://git.openjdk.java.net/jdk/pull/5725/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5725&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8217501 Stats: 26 lines in 2 files changed: 26 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5725.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5725/head:pull/5725 PR: https://git.openjdk.java.net/jdk/pull/5725 From darcy at openjdk.java.net Mon Sep 27 21:39:59 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 27 Sep 2021 21:39:59 GMT Subject: RFR: 8274367: Re-indent stack-trace examples for Throwable.printStackTrace In-Reply-To: References: Message-ID: <__BvVauaMTruVthun8NqwMjzsRSSVhcW42_NRnbSQDA=.bb88bdf0-f806-4774-9591-a6c13f67ea30@github.com> On Mon, 27 Sep 2021 12:04:48 GMT, Pavel Rappo wrote: > This PR fixes indentation in the examples in the doc comment for java.lang.Throwable#printStackTrace(). > > 1. Indentation in stack-trace output is significant. The cause of an exception is output on the same level of indentation as that of the exception. A suppressed exception is output at a deeper level of indentation than that of the containing exception. The last example for Throwable.printStackTrace violates this. > > 2. Indentation in examples for Throwable.printStackTrace that relate to suppressed exceptions is inconsistent with that of cause exceptions. Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5715 From bpb at openjdk.java.net Mon Sep 27 22:00:06 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 27 Sep 2021 22:00:06 GMT Subject: RFR: 8274367: Re-indent stack-trace examples for Throwable.printStackTrace In-Reply-To: References: Message-ID: On Mon, 27 Sep 2021 12:04:48 GMT, Pavel Rappo wrote: > This PR fixes indentation in the examples in the doc comment for java.lang.Throwable#printStackTrace(). > > 1. Indentation in stack-trace output is significant. The cause of an exception is output on the same level of indentation as that of the exception. A suppressed exception is output at a deeper level of indentation than that of the containing exception. The last example for Throwable.printStackTrace violates this. > > 2. Indentation in examples for Throwable.printStackTrace that relate to suppressed exceptions is inconsistent with that of cause exceptions. Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5715 From prappo at openjdk.java.net Mon Sep 27 22:36:09 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Mon, 27 Sep 2021 22:36:09 GMT Subject: Integrated: 8274367: Re-indent stack-trace examples for Throwable.printStackTrace In-Reply-To: References: Message-ID: On Mon, 27 Sep 2021 12:04:48 GMT, Pavel Rappo wrote: > This PR fixes indentation in the examples in the doc comment for java.lang.Throwable#printStackTrace(). > > 1. Indentation in stack-trace output is significant. The cause of an exception is output on the same level of indentation as that of the exception. A suppressed exception is output at a deeper level of indentation than that of the containing exception. The last example for Throwable.printStackTrace violates this. > > 2. Indentation in examples for Throwable.printStackTrace that relate to suppressed exceptions is inconsistent with that of cause exceptions. This pull request has now been integrated. Changeset: c880b87a Author: Pavel Rappo URL: https://git.openjdk.java.net/jdk/commit/c880b87a205cc9611fe88cb29f506293dfebf946 Stats: 21 lines in 1 file changed: 0 ins; 0 del; 21 mod 8274367: Re-indent stack-trace examples for Throwable.printStackTrace Reviewed-by: mchung, iris, darcy, bpb ------------- PR: https://git.openjdk.java.net/jdk/pull/5715 From prr at openjdk.java.net Mon Sep 27 23:50:38 2021 From: prr at openjdk.java.net (Phil Race) Date: Mon, 27 Sep 2021 23:50:38 GMT Subject: RFR: 8274397: [macOS] Stop setting env. var JAVA_MAIN_CLASS_ in launcher code [v2] In-Reply-To: <8j-vMsDYbF5100Dpc1DP_JGNV5V0W0D7i2fP7QnXCpU=.9169a246-f866-49c5-99fb-04f9fb946b9e@github.com> References: <8j-vMsDYbF5100Dpc1DP_JGNV5V0W0D7i2fP7QnXCpU=.9169a246-f866-49c5-99fb-04f9fb946b9e@github.com> Message-ID: > macOS launcher code sets JAVA_MAIN_CLASS_ which is read by AWT to set the name of the application in the system menu bar. > > Because this set shortly after the VM is running, it causes a thread safety issue described in https://bugs.openjdk.java.net/browse/JDK-8270549 > > Since the AWT already looks for the system property "apple.awt.application.name" for this same purpose, > we can set that instead of the env. var and avoid the threading issue. > > This trades the JAVA_MAIN_CLASS_ pollution of the environment for setting a system property which is visible to apps as well but it seems a reasonable trade-off since we already (implicitly) support this variable anyway in preference to the env. var. Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8274397: [macOS] Stop setting env. var JAVA_MAIN_CLASS_ in launcher code ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5724/files - new: https://git.openjdk.java.net/jdk/pull/5724/files/232bfae4..93108c59 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5724&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5724&range=00-01 Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5724.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5724/head:pull/5724 PR: https://git.openjdk.java.net/jdk/pull/5724 From github.com+78814694+tatwaichong at openjdk.java.net Tue Sep 28 02:06:03 2021 From: github.com+78814694+tatwaichong at openjdk.java.net (TatWai Chong) Date: Tue, 28 Sep 2021 02:06:03 GMT Subject: RFR: 8269559: AArch64: Implement string_compare intrinsic in SVE [v2] In-Reply-To: References: Message-ID: On Mon, 23 Aug 2021 21:48:01 GMT, TatWai Chong wrote: >> This patch implements string_compare intrinsic in SVE. >> It supports all LL, LU, UL and UU comparisons. >> >> As we haven't found an existing benchmark to measure performance impact, >> we created a benchmark derived from the test [1] for this evaluation. >> This benchmark is attached to this patch. >> >> Besides, remove the unused temporary register `vtmp3` from the existing >> match rules for StrCmp. >> >> The result below shows all varients can be benefited largely. >> Command: make exploded-test TEST="micro:StringCompareToDifferentLength" >> >> Benchmark (size) Mode Cnt Score Speedup Units >> compareToLL 24 avgt 10 1.0x ms/op >> compareToLL 36 avgt 10 1.0x ms/op >> compareToLL 72 avgt 10 1.0x ms/op >> compareToLL 128 avgt 10 1.4x ms/op >> compareToLL 256 avgt 10 1.8x ms/op >> compareToLL 512 avgt 10 2.7x ms/op >> compareToLU 24 avgt 10 1.6x ms/op >> compareToLU 36 avgt 10 1.8x ms/op >> compareToLU 72 avgt 10 2.3x ms/op >> compareToLU 128 avgt 10 3.8x ms/op >> compareToLU 256 avgt 10 4.7x ms/op >> compareToLU 512 avgt 10 6.3x ms/op >> compareToUL 24 avgt 10 1.6x ms/op >> compareToUL 36 avgt 10 1.7x ms/op >> compareToUL 72 avgt 10 2.2x ms/op >> compareToUL 128 avgt 10 3.3x ms/op >> compareToUL 256 avgt 10 4.4x ms/op >> compareToUL 512 avgt 10 6.1x ms/op >> compareToUU 24 avgt 10 1.0x ms/op >> compareToUU 36 avgt 10 1.0x ms/op >> compareToUU 72 avgt 10 1.4x ms/op >> compareToUU 128 avgt 10 2.2x ms/op >> compareToUU 256 avgt 10 2.6x ms/op >> compareToUU 512 avgt 10 3.7x ms/op >> >> [1] https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/compiler/intrinsics/string/TestStringCompareToDifferentLength.java > > TatWai Chong has updated the pull request incrementally with one additional commit since the last revision: > > Restore the removal of vtmp3 (=V2) as it is still used by the non-SVE compare-long-strings stub. > > And remove the assertion in `string_compare` since it won't help as the registers > used in the stub are fixed. @theRealAph Hello, Andrew. I'm wondering are you interested in reviewing this patch? I believe your feedback and comment are useful to it. ------------- PR: https://git.openjdk.java.net/jdk/pull/5129 From lzang at openjdk.java.net Tue Sep 28 03:14:10 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Tue, 28 Sep 2021 03:14:10 GMT Subject: RFR: 4890732: GZIPOutputStream doesn't support optional GZIP fields [v12] In-Reply-To: References: Message-ID: On Mon, 6 Sep 2021 07:20:11 GMT, Lin Zang wrote: >> 4890732: GZIPOutputStream doesn't support optional GZIP fields > > Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: > > - Merge branch 'master' into gzip-field > - delete trailing spaces > - refine code > - Merge branch 'master' into gzip-field > - change since version to 18 > - Merge branch 'master' into gzip-field > - Merge branch 'master' into gzip-field > - Add api in GZIPInputStream to get header data > - Merge remote-tracking branch 'upstream/master' into gzip-field > - remove trailing spaces > - ... and 7 more: https://git.openjdk.java.net/jdk/compare/c640fe42...196caedb Dear All? This PR has been pending there for quite a long time. I am wondering maybe this PR is not so interesting? I would like to leave this PR open for a while more, and if no new update, I would let it close automatically by timeout. Thanks! Lin ------------- PR: https://git.openjdk.java.net/jdk/pull/3072 From github.com+7806504+liach at openjdk.java.net Tue Sep 28 03:41:08 2021 From: github.com+7806504+liach at openjdk.java.net (liach) Date: Tue, 28 Sep 2021 03:41:08 GMT Subject: RFR: 4890732: GZIPOutputStream doesn't support optional GZIP fields [v12] In-Reply-To: References: Message-ID: On Mon, 6 Sep 2021 07:20:11 GMT, Lin Zang wrote: >> 4890732: GZIPOutputStream doesn't support optional GZIP fields > > Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: > > - Merge branch 'master' into gzip-field > - delete trailing spaces > - refine code > - Merge branch 'master' into gzip-field > - change since version to 18 > - Merge branch 'master' into gzip-field > - Merge branch 'master' into gzip-field > - Add api in GZIPInputStream to get header data > - Merge remote-tracking branch 'upstream/master' into gzip-field > - remove trailing spaces > - ... and 7 more: https://git.openjdk.java.net/jdk/compare/c640fe42...196caedb src/java.base/share/classes/java/util/zip/GZIPHeaderBuilder.java line 65: > 63: * Add extra field in GZIP file header. > 64: * This method verifies the extra fileds layout per RFC-1952. > 65: * See comments of {@code verifyExtraFieldLayout} You should specify the layout here than refer to a private method, as private methods don't appear in generated online javadocs src/java.base/share/classes/java/util/zip/GZIPHeaderBuilder.java line 186: > 184: * @since 18 > 185: */ > 186: public byte[] generateBytes(byte cm, Is there any reason to leave this public? If this is just an implementation detail, this should be kept private as public apis are maintenance burdens that are risky to change (hence csrs) src/java.base/share/classes/java/util/zip/GZIPHeaderBuilder.java line 247: > 245: * +=========================================+ > 246: */ > 247: byte[] filenameBytes = filename.getBytes("ISO-8859-1"); Should use [`StandardCharsets.ISO_8859_1`](https://github.com/openjdk/jdk/blob/8876eae42993d4425ba9886dde94b08f6101a257/src/java.base/share/classes/java/nio/charset/StandardCharsets.java#L55) than string names. Using the charset object is significantly faster than looking up charsets by string names, see https://bugs.openjdk.java.net/browse/JDK-8272120 src/java.base/share/classes/java/util/zip/GZIPHeaderBuilder.java line 328: > 326: String fileComment, > 327: int headerCRC16, > 328: byte[] headerBytes) { Need to override the getter for byte array fields to return copies than original arrays to prevent modifications. For the extraFieldBytes one, the call to copy needs a null check too. src/java.base/share/classes/java/util/zip/GZIPHeaderBuilder.java line 359: > 357: private static final int FEXTRA = 4; // Extra field > 358: private static final int FNAME = 8; // File name > 359: private static final int FCOMMENT = 16; // File comment Since the `flags` record component is public, These probably should be left public as well to benefit users, especially given checking the flags can replace null checks for `extraFieldBytes`, `filename`, and `fileContent`. ------------- PR: https://git.openjdk.java.net/jdk/pull/3072 From jpai at openjdk.java.net Tue Sep 28 05:05:59 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 28 Sep 2021 05:05:59 GMT Subject: RFR: 8273790: Potential cyclic dependencies between Gregorian and CalendarSystem [v2] In-Reply-To: References: Message-ID: On Sat, 25 Sep 2021 03:38:24 GMT, Jaikiran Pai wrote: >> Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.java.net/browse/JDK-8273790? >> >> As noted in that issue, trying to class load `sun.util.calendar.CalendarSystem` and `sun.util.calendar.Gregorian` concurrently in separate threads can lead to a deadlock because of the cyclic nature of the code in their static initialization. More specifically, consider this case: >> >> - Thread T1 initiates a classload on the `sun.util.calendar.CalendarSystem`. >> - This gives T1 the implicit class init lock on `CalendarSystem`. >> - Consider thread T2 which at the same time initiates a classload on `sun.util.calendar.Gregorian` class. >> - This gives T2 a implicit class init lock on `Gregorian`. >> - T1, still holding a lock on `CalendarSystem` attempts to load `Gregorian` since it wants to create a (singleton) instance of `Gregorian` and assign it to the `static final GREGORIAN_INSTANCE` member. Since T2 is holding a class init lock on `Gregorian`, T1 ends up waiting >> - T2 on the other hand is still loading the `Gregorian` class. `Gregorian` itself "is a" `CalendarSystem`, so during this loading of `Gregorian` class, T2 starts travelling up the class hierarchy and asks for a lock on `CalendarSystem`. However T1 is holding this lock and as a result T2 ends up waiting on T1 which is waiting on T2. That triggers this deadlock. >> >> The linked JBS issue has a thread dump which shows this in action. >> >> The commit here delays the instance creation of `Gregorian` by moving that instance creation logic from the static initialization of the `CalendarSystem` class, to the first call to `CalendarSystem#getGregorianCalendar()`. This prevents the `CalendarSystem` from needing a lock on `Gregorian` during its static init (of course, unless some code in this static init flow calls `CalendarSystem#getGregorianCalendar()`, in which case it is back to square one. I have verified, both manually and through the jtreg test, that the code in question doesn't have such calls) >> >> A new jtreg test has been introduced to reproduce the issue and verify the fix. The test in addition to loading these 2 classes in question, also additionally loads a few other classes concurrently. These classes have specific static initialization which leads the calls to `CalendarSystem#getGregorianCalendar()` or `CalendarSystem#forName()`. Including these classes in the tests ensures that this deadlock hasn't "moved" to a different location. I have run multiple runs (approximately 25) of this test with the fix and I haven't seen it deadlock anymore. > > Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision: > > - Minor test adjustments as suggested by Naoto > - use a holder instead of volatile, as suggested by Roger Thank you Roger, Naoto and Yi Yang for the reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/5683 From jpai at openjdk.java.net Tue Sep 28 05:06:02 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 28 Sep 2021 05:06:02 GMT Subject: Integrated: 8273790: Potential cyclic dependencies between Gregorian and CalendarSystem In-Reply-To: References: Message-ID: <7Z6OSZMJfziq2kZyz68yzST4yq4OjyalBdgq1gi2o1A=.1073dbe4-d2c1-4d7b-a691-54b22b02f1f9@github.com> On Fri, 24 Sep 2021 14:36:07 GMT, Jaikiran Pai wrote: > Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.java.net/browse/JDK-8273790? > > As noted in that issue, trying to class load `sun.util.calendar.CalendarSystem` and `sun.util.calendar.Gregorian` concurrently in separate threads can lead to a deadlock because of the cyclic nature of the code in their static initialization. More specifically, consider this case: > > - Thread T1 initiates a classload on the `sun.util.calendar.CalendarSystem`. > - This gives T1 the implicit class init lock on `CalendarSystem`. > - Consider thread T2 which at the same time initiates a classload on `sun.util.calendar.Gregorian` class. > - This gives T2 a implicit class init lock on `Gregorian`. > - T1, still holding a lock on `CalendarSystem` attempts to load `Gregorian` since it wants to create a (singleton) instance of `Gregorian` and assign it to the `static final GREGORIAN_INSTANCE` member. Since T2 is holding a class init lock on `Gregorian`, T1 ends up waiting > - T2 on the other hand is still loading the `Gregorian` class. `Gregorian` itself "is a" `CalendarSystem`, so during this loading of `Gregorian` class, T2 starts travelling up the class hierarchy and asks for a lock on `CalendarSystem`. However T1 is holding this lock and as a result T2 ends up waiting on T1 which is waiting on T2. That triggers this deadlock. > > The linked JBS issue has a thread dump which shows this in action. > > The commit here delays the instance creation of `Gregorian` by moving that instance creation logic from the static initialization of the `CalendarSystem` class, to the first call to `CalendarSystem#getGregorianCalendar()`. This prevents the `CalendarSystem` from needing a lock on `Gregorian` during its static init (of course, unless some code in this static init flow calls `CalendarSystem#getGregorianCalendar()`, in which case it is back to square one. I have verified, both manually and through the jtreg test, that the code in question doesn't have such calls) > > A new jtreg test has been introduced to reproduce the issue and verify the fix. The test in addition to loading these 2 classes in question, also additionally loads a few other classes concurrently. These classes have specific static initialization which leads the calls to `CalendarSystem#getGregorianCalendar()` or `CalendarSystem#forName()`. Including these classes in the tests ensures that this deadlock hasn't "moved" to a different location. I have run multiple runs (approximately 25) of this test with the fix and I haven't seen it deadlock anymore. This pull request has now been integrated. Changeset: ddc26274 Author: Jaikiran Pai URL: https://git.openjdk.java.net/jdk/commit/ddc262746aea99050b9a6484f51c7ddb8f4bc991 Stats: 183 lines in 2 files changed: 179 ins; 0 del; 4 mod 8273790: Potential cyclic dependencies between Gregorian and CalendarSystem Reviewed-by: naoto, yyang, rriggs ------------- PR: https://git.openjdk.java.net/jdk/pull/5683 From jpai at openjdk.java.net Tue Sep 28 05:18:02 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 28 Sep 2021 05:18:02 GMT Subject: RFR: 8231640: (prop) Canonical property storage [v22] In-Reply-To: References: Message-ID: <0-Loesd_uDK2HokWvCkJkZmaV0tjo-ANqJqWgWRxzaE=.8df52cf6-6472-492e-ae10-42bb7341af32@github.com> On Wed, 22 Sep 2021 10:27:45 GMT, Jaikiran Pai wrote: >> The commit in this PR implements the proposal for enhancement that was discussed in the core-libs-dev mailing list recently[1], for https://bugs.openjdk.java.net/browse/JDK-8231640 >> >> At a high level - the `store()` APIs in `Properties` have been modified to now look for the `SOURCE_DATE_EPOCH` environment variable[2]. If that env variable is set, then instead of writing out the current date time as a date comment, the `store()` APIs instead will use the value set for this env variable to parse it to a `Date` and write out the string form of such a date. The implementation here uses the `d MMM yyyy HH:mm:ss 'GMT'` date format and `Locale.ROOT` to format and write out such a date. This should provide reproducibility whenever the `SOURCE_DATE_EPOCH` is set. Furthermore, intentionally, no changes in the date format of the "current date" have been done. >> >> These modified `store()` APIs work in the presence of the `SecurityManager` too. The caller is expected to have a read permission on the `SOURCE_DATE_EPOCH` environment variable. If the caller doesn't have that permission, then the implementation of these `store()` APIs will write out the "current date" and will ignore any value that has been set for the `SOURCE_DATE_EPOCH` env variable. This should allow for backward compatibility of existing applications, where, when they run under a `SecurityManager` and perhaps with an existing restrictive policy file, the presence of `SOURCE_DATE_EPOCH` shouldn't impact their calls to the `store()` APIs. >> >> The modified `store()` APIs will also ignore any value for `SOURCE_DATE_EPOCH` that cannot be parsed to an `long` value. In such cases, the `store()` APIs will write out the "current date" and ignore the value set for this environment variable. No exceptions will be thrown for such invalid values. This is an additional backward compatibility precaution to prevent any rogue value for `SOURCE_DATE_EPOCH` from breaking applications. >> >> An additional change in the implementation of these `store()` APIs and unrelated to the date comment, is that these APIs will now write out the property keys in a deterministic order. The keys will be written out in the natural ordering as specified by `java.lang.String#compareTo()` API. >> >> The combination of the ordering of the property keys when written out and the usage of `SOURCE_DATE_EPOCH` environment value to determine the date comment should together allow for reproducibility of the output generated by these `store()` APIs. >> >> New jtreg test classes have been introduced to verify these changes. The primary focus of `PropertiesStoreTest` is the ordering aspects of the property keys that are written out. On the other hand `StoreReproducibilityTest` focuses on the reproducibility of the output generated by these APIs. The `StoreReproducibilityTest` runs these tests both in the presence and absence of `SecurityManager`. Plus, in the presence of SecurityManager, it tests both the scenarios where the caller is granted the requisite permission and in other case not granted that permission. >> >> These new tests and existing tests under `test/jdk/java/util/Properties/` pass with these changes. >> >> [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-August/080758.html >> [2] https://reproducible-builds.org/specs/source-date-epoch/ > > Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision: > > - Revert "Implement Mark's suggestion in CSR to include the java.properties.date in the list of system properties listed in System::getProperties()" > > Additional inputs since this specific commit was introduced have leaned towards not listing this property in System::getProperties() > > This reverts commit 458c1fd37cf1e8e8bd0a60a171d173ce5da12b7c. > - reduce the line length of code comment It was a pleasure working on this one due to the timely and valuable reviews, inputs and suggestions. Thanks to everyone for helping in getting this done. ------------- PR: https://git.openjdk.java.net/jdk/pull/5372 From jpai at openjdk.java.net Tue Sep 28 05:21:07 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 28 Sep 2021 05:21:07 GMT Subject: Integrated: 8231640: (prop) Canonical property storage In-Reply-To: References: Message-ID: On Sat, 4 Sep 2021 15:25:59 GMT, Jaikiran Pai wrote: > The commit in this PR implements the proposal for enhancement that was discussed in the core-libs-dev mailing list recently[1], for https://bugs.openjdk.java.net/browse/JDK-8231640 > > At a high level - the `store()` APIs in `Properties` have been modified to now look for the `SOURCE_DATE_EPOCH` environment variable[2]. If that env variable is set, then instead of writing out the current date time as a date comment, the `store()` APIs instead will use the value set for this env variable to parse it to a `Date` and write out the string form of such a date. The implementation here uses the `d MMM yyyy HH:mm:ss 'GMT'` date format and `Locale.ROOT` to format and write out such a date. This should provide reproducibility whenever the `SOURCE_DATE_EPOCH` is set. Furthermore, intentionally, no changes in the date format of the "current date" have been done. > > These modified `store()` APIs work in the presence of the `SecurityManager` too. The caller is expected to have a read permission on the `SOURCE_DATE_EPOCH` environment variable. If the caller doesn't have that permission, then the implementation of these `store()` APIs will write out the "current date" and will ignore any value that has been set for the `SOURCE_DATE_EPOCH` env variable. This should allow for backward compatibility of existing applications, where, when they run under a `SecurityManager` and perhaps with an existing restrictive policy file, the presence of `SOURCE_DATE_EPOCH` shouldn't impact their calls to the `store()` APIs. > > The modified `store()` APIs will also ignore any value for `SOURCE_DATE_EPOCH` that cannot be parsed to an `long` value. In such cases, the `store()` APIs will write out the "current date" and ignore the value set for this environment variable. No exceptions will be thrown for such invalid values. This is an additional backward compatibility precaution to prevent any rogue value for `SOURCE_DATE_EPOCH` from breaking applications. > > An additional change in the implementation of these `store()` APIs and unrelated to the date comment, is that these APIs will now write out the property keys in a deterministic order. The keys will be written out in the natural ordering as specified by `java.lang.String#compareTo()` API. > > The combination of the ordering of the property keys when written out and the usage of `SOURCE_DATE_EPOCH` environment value to determine the date comment should together allow for reproducibility of the output generated by these `store()` APIs. > > New jtreg test classes have been introduced to verify these changes. The primary focus of `PropertiesStoreTest` is the ordering aspects of the property keys that are written out. On the other hand `StoreReproducibilityTest` focuses on the reproducibility of the output generated by these APIs. The `StoreReproducibilityTest` runs these tests both in the presence and absence of `SecurityManager`. Plus, in the presence of SecurityManager, it tests both the scenarios where the caller is granted the requisite permission and in other case not granted that permission. > > These new tests and existing tests under `test/jdk/java/util/Properties/` pass with these changes. > > [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-August/080758.html > [2] https://reproducible-builds.org/specs/source-date-epoch/ This pull request has now been integrated. Changeset: af50772d Author: Jaikiran Pai URL: https://git.openjdk.java.net/jdk/commit/af50772d39a063652895e79d474da6ebb992cae0 Stats: 837 lines in 4 files changed: 822 ins; 0 del; 15 mod 8231640: (prop) Canonical property storage Reviewed-by: rriggs, smarks, dfuchs, ihse ------------- PR: https://git.openjdk.java.net/jdk/pull/5372 From amaembo at gmail.com Tue Sep 28 05:56:34 2021 From: amaembo at gmail.com (Tagir Valeev) Date: Tue, 28 Sep 2021 12:56:34 +0700 Subject: Discussion: easier Stream closing In-Reply-To: <2606ed74-927c-3c57-aa40-a8811f20883f@oracle.com> References: <2606ed74-927c-3c57-aa40-a8811f20883f@oracle.com> Message-ID: Hello, Brian! Thanks for your thoughts. > The consumeAndClose approach is clever, in that it adds one API point that works for all streams, rather than having to add a new API point for every factory of a closeable stream; on the other hand, it is dramatically less discoverable, and so requires more education to get people to use it (and, as you say, has the exception problem.) I think this could be solved via IDE/static analysis features. It looks quite easy to statically rewrite the try-catch statement to consumeAndClose. And, of course, static analyzers may recommend consumeAndClose when no resource management is used at all on the stream that is known to hold the resource. I filed https://bugs.openjdk.java.net/browse/JDK-8274412 to move this forward. From darcy at openjdk.java.net Tue Sep 28 07:17:32 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 28 Sep 2021 07:17:32 GMT Subject: RFR: 8274415: Suppress warnings on non-serializable non-transient instance fields in java.xml Message-ID: Augmentations to javac's Xlint:serial checking are out for review (#5709) and the java.xml module would need some changes to pass under the expanded checks. The changes are to suppress warnings where non-transient fields in serializable types are not declared with a type statically known to be serializable. That isn't necessarily a correctness issues, but it does merit further scrutiny. I'll run a script to update the copyright years before pushing. ------------- Commit messages: - 8274415: Suppress warnings on non-serializable non-transient instance fields in java.xml Changes: https://git.openjdk.java.net/jdk/pull/5730/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5730&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274415 Stats: 45 lines in 27 files changed: 45 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5730.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5730/head:pull/5730 PR: https://git.openjdk.java.net/jdk/pull/5730 From alanb at openjdk.java.net Tue Sep 28 07:45:01 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 28 Sep 2021 07:45:01 GMT Subject: RFR: 8274391: Suppress more warnings on non-serializable non-transient instance fields in java.util.concurrent In-Reply-To: References: Message-ID: On Mon, 27 Sep 2021 18:40:10 GMT, Joe Darcy wrote: > Follow-up change to JDK-8232230, augmentations to javac's Xlint:serial checking are out for review (https://github.com/openjdk/jdk/pull/5709) and java.util.concurrent would need some changes to pass under the expanded checks. > > The changes are to suppress warnings where non-transient fields in serializable types are not declared with a type statically known to be serializable. That isn't necessarily a correctness issues, but it does merit further scrutiny. > > In ForkJoinTask, the SuppressWarnings annotation previously applied in JDK-8232230, seems to have been misplaced to a different field; this change corrects it. Looks okay but will need to go to the jsr166 cvs too (@DougLea). ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5718 From alanb at openjdk.java.net Tue Sep 28 07:46:49 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 28 Sep 2021 07:46:49 GMT Subject: RFR: 8274394: Use Optional.isEmpty instead of !Optional.isPresent in jdk.jlink In-Reply-To: <7v27BGJ2oB6FbGGeNP0pibG52dTr4A1k87eTrQjf5ZQ=.dc5298db-07bd-45b5-85f4-38e87c4e6309@github.com> References: <7v27BGJ2oB6FbGGeNP0pibG52dTr4A1k87eTrQjf5ZQ=.dc5298db-07bd-45b5-85f4-38e87c4e6309@github.com> Message-ID: On Sun, 26 Sep 2021 13:58:35 GMT, Andrey Turbanov wrote: > I propose to replace usages of !Optional.isPresent() with Optional.isEmpty method. > It's makes code a bit easier to read. > Noticing negation before long chain of method calls is hard. Looks okay, this code pre-dates the isEmpty method. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5707 From plevart at openjdk.java.net Tue Sep 28 08:12:56 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Tue, 28 Sep 2021 08:12:56 GMT Subject: RFR: 8274299: Make Method/Constructor/Field accessors @Stable In-Reply-To: References: Message-ID: On Mon, 27 Sep 2021 17:31:50 GMT, Mandy Chung wrote: > Looks good to me. Very nice performance improvement. > > One minor comment: I think the change in `UnsafeFieldAccessorImpl.java` and `UnsafeStaticFieldAccessorImpl.java` isn't necessary since they're final fields. It can be reverted. There are two changes in `UnsafeFieldAccessorImpl.java` and `UnsafeStaticFieldAccessorImpl.java`. One is making `fieldOffset` and `base` (for static fields) @Stable and the other is moving `field` one level up to `FieldAccessorImpl` and making it @Stable. This later change is not necessary for this patch, but I noticed that you did that in JEP 416 so that `field` is common to all subclasses of `FieldAccessorImpl` including those that you are adding in JEP 416. I can undo this later change. But making fields @Stable does improve performance since `jdk.internal.reflect` and `java.lang.reflect` are not final-field-trusted packages as you noted above. If JEP 416 makes them trusted, it can also remove the @Stable annotations. But for backporting, they better stay there. WDYT? ------------- PR: https://git.openjdk.java.net/jdk/pull/5694 From plevart at openjdk.java.net Tue Sep 28 08:25:17 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Tue, 28 Sep 2021 08:25:17 GMT Subject: RFR: 8274299: Make Method/Constructor/Field accessors @Stable [v2] In-Reply-To: References: Message-ID: > This patch improves reflective access speed as shown by the included benchmarks: > > https://jmh.morethan.io/?gists=902f4b43519c4f96c7abcd14cdc2d27d,ac490481e3001c710d75d6071c10b23a > > ... and is also a prerequisite to make JEP 416 (Reimplement Core Reflection with Method Handle) perform better in some circumstances. Peter Levart has updated the pull request incrementally with one additional commit since the last revision: Make Method/Constructor/Field instance fields initialized in the constructors final ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5694/files - new: https://git.openjdk.java.net/jdk/pull/5694/files/0298253e..1f273e9a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5694&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5694&range=00-01 Stats: 28 lines in 3 files changed: 0 ins; 0 del; 28 mod Patch: https://git.openjdk.java.net/jdk/pull/5694.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5694/head:pull/5694 PR: https://git.openjdk.java.net/jdk/pull/5694 From plevart at openjdk.java.net Tue Sep 28 08:26:29 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Tue, 28 Sep 2021 08:26:29 GMT Subject: RFR: 8274299: Make Method/Constructor/Field accessors @Stable [v2] In-Reply-To: <9r_Kwce_uft46hoiysojJLNfJH2rtF20WB-B3XqNwsA=.b6820b8d-ad31-44cc-99d6-d53b92e1c8ee@github.com> References: <9r_Kwce_uft46hoiysojJLNfJH2rtF20WB-B3XqNwsA=.b6820b8d-ad31-44cc-99d6-d53b92e1c8ee@github.com> Message-ID: On Mon, 27 Sep 2021 19:59:00 GMT, Mandy Chung wrote: > A stray thought is why not most fields in `Field`/`Method`/`Constructor` are `final`, as my IDE suggests. I can't find any hotspot code that injects values to these fields. Experimentally changing most fields in `Field` to final seem to pass at least all the java/lang/reflect tests. Since this is a trusted package `@Stable` should then be pointless. I made them final in newly added patch now. So we can either merge this or previous commit if desired. ------------- PR: https://git.openjdk.java.net/jdk/pull/5694 From aph at openjdk.java.net Tue Sep 28 08:31:09 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Tue, 28 Sep 2021 08:31:09 GMT Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v2] In-Reply-To: References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com> Message-ID: On Fri, 16 Apr 2021 11:30:32 GMT, Raffaello Giulietti wrote: >> Hello, >> >> here's a PR for a patch submitted on March 2020 [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a thing. >> >> The patch has been edited to adhere to OpenJDK code conventions about multi-line (block) comments. Nothing in the code proper has changed, except for the addition of redundant but clarifying parentheses in some expressions. >> >> >> Greetings >> Raffaello > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > 4511638: Double.toString(double) sometimes produces incorrect results My turn to keep this PR alive. If we'd had any actual face-to-face contributors' meetings this year I would have raised this stuck PR as an issue with our processes. ------------- PR: https://git.openjdk.java.net/jdk/pull/3402 From alanb at openjdk.java.net Tue Sep 28 09:24:53 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 28 Sep 2021 09:24:53 GMT Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v2] In-Reply-To: References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com> Message-ID: <0aAgmrmRCJfD8BuJxVtRWa4hO_F5PNtmwvhgxH3kT4w=.03eb2613-47d2-4e33-ad6a-be182d836e2f@github.com> On Tue, 28 Sep 2021 08:27:22 GMT, Andrew Haley wrote: > My turn to keep this PR alive. If we'd had any actual face-to-face contributors' meetings this year I would have raised this stuck PR as an issue with our processes. I believe that the previous discussion on this topic had an AI to reach out to @GuySteele to ask for comment on the "The Schubfach way to render doubles? paper. ------------- PR: https://git.openjdk.java.net/jdk/pull/3402 From github.com+70726043+rgiulietti at openjdk.java.net Tue Sep 28 09:30:07 2021 From: github.com+70726043+rgiulietti at openjdk.java.net (Raffaello Giulietti) Date: Tue, 28 Sep 2021 09:30:07 GMT Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v2] In-Reply-To: References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com> Message-ID: On Fri, 16 Apr 2021 11:30:32 GMT, Raffaello Giulietti wrote: >> Hello, >> >> here's a PR for a patch submitted on March 2020 [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a thing. >> >> The patch has been edited to adhere to OpenJDK code conventions about multi-line (block) comments. Nothing in the code proper has changed, except for the addition of redundant but clarifying parentheses in some expressions. >> >> >> Greetings >> Raffaello > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > 4511638: Double.toString(double) sometimes produces incorrect results Thanks for helping me keeping this PR alive. I was pondering whether to propose adding a launch-time option on the command line to choose between the current and the proposed implementation for some time, so to help the community gaining confidence in the new algorithm and still have the current one as a fallback, just in case. (AFAIU, a launch-time option can be constant folded by the JIT compiler to help it eliminate dead code, right?) On the one hand, this adds complexity. On the other hand, it could help revive this dormant PR. What do you think? Would this be a viable option? Greetings Raffaello ------------- PR: https://git.openjdk.java.net/jdk/pull/3402 From redestad at openjdk.java.net Tue Sep 28 09:53:57 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 28 Sep 2021 09:53:57 GMT Subject: RFR: 8274299: Make Method/Constructor/Field accessors @Stable [v2] In-Reply-To: References: Message-ID: On Tue, 28 Sep 2021 08:25:17 GMT, Peter Levart wrote: >> This patch improves reflective access speed as shown by the included benchmarks: >> >> https://jmh.morethan.io/?gists=902f4b43519c4f96c7abcd14cdc2d27d,ac490481e3001c710d75d6071c10b23a >> >> ... and is also a prerequisite to make JEP 416 (Reimplement Core Reflection with Method Handle) perform better in some circumstances. > > Peter Levart has updated the pull request incrementally with one additional commit since the last revision: > > Make Method/Constructor/Field instance fields initialized in the constructors final Does `Reflection::new_method/...` (which are natively implemented constructors) need any special treatment for them to follow the same semantics as a Java-based constructor w.r.t. final field writes? Or could they be rewritten to call the equivalent java constructor in each case? We lack a microbenchmark for `Constructor`, but I suspect it might be a similar improvement to annotate the same fields in `Constructor` with `@Stable`. If not else it seems prudent to be consistent. ------------- PR: https://git.openjdk.java.net/jdk/pull/5694 From redestad at openjdk.java.net Tue Sep 28 10:05:05 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 28 Sep 2021 10:05:05 GMT Subject: RFR: 8274242: Implement fast-path for ASCII-compatible CharsetEncoders on x86 [v3] In-Reply-To: References: <_Dzhdy1vRupNXlRezru6UpkvEJV3Vlr149pbkryW2I4=.4c6e5e5b-7026-4410-9848-2a8d12aa71f7@github.com> Message-ID: <8nRoQznW3BlIXu7y0t9HhBgX1vMgFQAb6yoROtWQ7kA=.caa9857b-5c1c-4c68-ad15-05aaf02afc93@github.com> On Mon, 27 Sep 2021 12:11:22 GMT, Claes Redestad wrote: >> src/hotspot/share/opto/c2compiler.cpp line 222: >> >>> 220: #if !defined(X86) >>> 221: return false; // not yet implemented >>> 222: #endif >> >> It might be a little more work, but I think it's cleaner to move the decision whether the intrinisc is supported into the Matcher like for most other intrinsics and keep this code here platform independent. Otherwise we will get an increasing cascade of ifdefs as people start implementing this for other platforms. > > Not too much work. I recently introduced platform-specific `matcher_*.hpp` files, so since then adding a boolean constant is easy (no need to muck with the .ad files). Does the changes in 9800a99 resolve your concerns? ------------- PR: https://git.openjdk.java.net/jdk/pull/5621 From jboes at openjdk.java.net Tue Sep 28 10:08:29 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Tue, 28 Sep 2021 10:08:29 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v7] In-Reply-To: References: Message-ID: > This change implements a simple web server that can be run on the command-line with `java -m jdk.httpserver`. > > This is facilitated by adding an entry point for the `jdk.httpserver` module, an implementation class whose main method is run when the above command is executed. This is the first such module entry point in the JDK. > > The server is a minimal HTTP server that serves the static files of a given directory, similar to existing alternatives on other platforms and convenient for testing, development, and debugging. > > Additionally, a small API is introduced for programmatic creation and customization. > > Testing: tier1-3. Julia Boes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: - use ipv4/ipv6 specific loopback address and add add how-to output for all interfaces - Merge branch 'master' into simpleserver - change default bind address from anylocal to loopback - address PR comments - Merge branch 'master' into simpleserver - Merge remote-tracking branch 'origin/simpleserver' into simpleserver - Merge branch 'master' into simpleserver - refactor isHidden,isReadable,isSymlink checks and cleanup tests - Merge branch 'master' into simpleserver - check isHidden, isSymlink, isReadable for all path segments - ... and 10 more: https://git.openjdk.java.net/jdk/compare/87998565...7f994476 ------------- Changes: https://git.openjdk.java.net/jdk/pull/5505/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5505&range=06 Stats: 7181 lines in 42 files changed: 7146 ins; 15 del; 20 mod Patch: https://git.openjdk.java.net/jdk/pull/5505.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5505/head:pull/5505 PR: https://git.openjdk.java.net/jdk/pull/5505 From redestad at openjdk.java.net Tue Sep 28 10:11:36 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 28 Sep 2021 10:11:36 GMT Subject: RFR: 8274242: Implement fast-path for ASCII-compatible CharsetEncoders on x86 [v4] In-Reply-To: References: Message-ID: > This patch extends the `ISO_8859_1.implEncodeISOArray` intrinsic on x86 to work also for ASCII encoding, which makes for example the `UTF_8$Encoder` perform on par with (or outperform) similarly getting charset encoded bytes from a String. The former took a small performance hit in JDK 9, and the latter improved greatly in the same release. > > Extending the `EncodeIsoArray` intrinsics on other platforms should be possible, but I'm unfamiliar with the macro assembler in general and unlike the x86 intrinsic they don't use a simple vectorized mask to implement the latin-1 check. For example aarch64 seem to filter out the low bytes and then check if there's any bits set in the high bytes. Clever, but very different to the 0xFF80 2-byte mask that an ASCII test wants. Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Fix logic error ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5621/files - new: https://git.openjdk.java.net/jdk/pull/5621/files/9800a99a..47633cba Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5621&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5621&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5621.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5621/head:pull/5621 PR: https://git.openjdk.java.net/jdk/pull/5621 From jboes at openjdk.java.net Tue Sep 28 10:13:03 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Tue, 28 Sep 2021 10:13:03 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v7] In-Reply-To: References: Message-ID: On Tue, 28 Sep 2021 10:08:29 GMT, Julia Boes wrote: >> This change implements a simple web server that can be run on the command-line with `java -m jdk.httpserver`. >> >> This is facilitated by adding an entry point for the `jdk.httpserver` module, an implementation class whose main method is run when the above command is executed. This is the first such module entry point in the JDK. >> >> The server is a minimal HTTP server that serves the static files of a given directory, similar to existing alternatives on other platforms and convenient for testing, development, and debugging. >> >> Additionally, a small API is introduced for programmatic creation and customization. >> >> Testing: tier1-3. > > Julia Boes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: > > - use ipv4/ipv6 specific loopback address and add add how-to output for all interfaces > - Merge branch 'master' into simpleserver > - change default bind address from anylocal to loopback > - address PR comments > - Merge branch 'master' into simpleserver > - Merge remote-tracking branch 'origin/simpleserver' into simpleserver > - Merge branch 'master' into simpleserver > - refactor isHidden,isReadable,isSymlink checks and cleanup tests > - Merge branch 'master' into simpleserver > - check isHidden, isSymlink, isReadable for all path segments > - ... and 10 more: https://git.openjdk.java.net/jdk/compare/87998565...7f994476 7f99447 updates the output to: - use the ipv4/ipv6 specific loopback address, - include a line on how to bind to all interfaces if no bind address is specified, - include the option help text in the case where an argument is missing. ------------- PR: https://git.openjdk.java.net/jdk/pull/5505 From dfuchs at openjdk.java.net Tue Sep 28 10:20:11 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 28 Sep 2021 10:20:11 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v7] In-Reply-To: References: Message-ID: On Tue, 28 Sep 2021 10:08:29 GMT, Julia Boes wrote: >> This change implements a simple web server that can be run on the command-line with `java -m jdk.httpserver`. >> >> This is facilitated by adding an entry point for the `jdk.httpserver` module, an implementation class whose main method is run when the above command is executed. This is the first such module entry point in the JDK. >> >> The server is a minimal HTTP server that serves the static files of a given directory, similar to existing alternatives on other platforms and convenient for testing, development, and debugging. >> >> Additionally, a small API is introduced for programmatic creation and customization. >> >> Testing: tier1-3. > > Julia Boes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: > > - use ipv4/ipv6 specific loopback address and add add how-to output for all interfaces > - Merge branch 'master' into simpleserver > - change default bind address from anylocal to loopback > - address PR comments > - Merge branch 'master' into simpleserver > - Merge remote-tracking branch 'origin/simpleserver' into simpleserver > - Merge branch 'master' into simpleserver > - refactor isHidden,isReadable,isSymlink checks and cleanup tests > - Merge branch 'master' into simpleserver > - check isHidden, isSymlink, isReadable for all path segments > - ... and 10 more: https://git.openjdk.java.net/jdk/compare/87998565...7f994476 Thanks Julia, the new changes look good to me. ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5505 From ecki at zusammenkunft.net Tue Sep 28 10:28:50 2021 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Tue, 28 Sep 2021 10:28:50 +0000 Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v7] In-Reply-To: References: Message-ID: Just a nit, but how about: * For all interfaces use ?-b ???0.0.0.0? (IPv4) or ?-b ::? (IPv6) Instead of: * For 0.0.0.0 (all interfaces) use -b 0.0.0.0 or -b ::0 In the usage? (I think ?::? is canon?) Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: net-dev im Auftrag von Daniel Fuchs Gesendet: Tuesday, September 28, 2021 12:20:11 PM An: build-dev at openjdk.java.net ; core-libs-dev at openjdk.java.net ; net-dev at openjdk.java.net Betreff: Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v7] On Tue, 28 Sep 2021 10:08:29 GMT, Julia Boes wrote: >> This change implements a simple web server that can be run on the command-line with `java -m jdk.httpserver`. >> >> This is facilitated by adding an entry point for the `jdk.httpserver` module, an implementation class whose main method is run when the above command is executed. This is the first such module entry point in the JDK. >> >> The server is a minimal HTTP server that serves the static files of a given directory, similar to existing alternatives on other platforms and convenient for testing, development, and debugging. >> >> Additionally, a small API is introduced for programmatic creation and customization. >> >> Testing: tier1-3. > > Julia Boes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: > > - use ipv4/ipv6 specific loopback address and add add how-to output for all interfaces > - Merge branch 'master' into simpleserver > - change default bind address from anylocal to loopback > - address PR comments > - Merge branch 'master' into simpleserver > - Merge remote-tracking branch 'origin/simpleserver' into simpleserver > - Merge branch 'master' into simpleserver > - refactor isHidden,isReadable,isSymlink checks and cleanup tests > - Merge branch 'master' into simpleserver > - check isHidden, isSymlink, isReadable for all path segments > - ... and 10 more: https://git.openjdk.java.net/jdk/compare/87998565...7f994476 Thanks Julia, the new changes look good to me. ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5505 From dl at openjdk.java.net Tue Sep 28 11:32:01 2021 From: dl at openjdk.java.net (Doug Lea) Date: Tue, 28 Sep 2021 11:32:01 GMT Subject: RFR: 8274391: Suppress more warnings on non-serializable non-transient instance fields in java.util.concurrent In-Reply-To: References: Message-ID: On Mon, 27 Sep 2021 18:40:10 GMT, Joe Darcy wrote: > Follow-up change to JDK-8232230, augmentations to javac's Xlint:serial checking are out for review (https://github.com/openjdk/jdk/pull/5709) and java.util.concurrent would need some changes to pass under the expanded checks. > > The changes are to suppress warnings where non-transient fields in serializable types are not declared with a type statically known to be serializable. That isn't necessarily a correctness issues, but it does merit further scrutiny. > > In ForkJoinTask, the SuppressWarnings annotation previously applied in JDK-8232230, seems to have been misplaced to a different field; this change corrects it. Just to be sure, does this include only the conditionally serializable annotations in ForkJoinPool and ForkJoinTask in: https://github.com/openjdk/jdk/pull/5718/files/a20d9afbd7b49b452b3c9bdc9f2d56442b5e2fc6 If so, this looks OK to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/5718 From redestad at openjdk.java.net Tue Sep 28 11:49:29 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 28 Sep 2021 11:49:29 GMT Subject: RFR: 8274242: Implement fast-path for ASCII-compatible CharsetEncoders on x86 [v5] In-Reply-To: References: Message-ID: > This patch extends the `ISO_8859_1.implEncodeISOArray` intrinsic on x86 to work also for ASCII encoding, which makes for example the `UTF_8$Encoder` perform on par with (or outperform) similarly getting charset encoded bytes from a String. The former took a small performance hit in JDK 9, and the latter improved greatly in the same release. > > Extending the `EncodeIsoArray` intrinsics on other platforms should be possible, but I'm unfamiliar with the macro assembler in general and unlike the x86 intrinsic they don't use a simple vectorized mask to implement the latin-1 check. For example aarch64 seem to filter out the low bytes and then check if there's any bits set in the high bytes. Clever, but very different to the 0xFF80 2-byte mask that an ASCII test wants. Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Add fail-safe predicate to all encode_iso_array to only match non-ASCII EncodeISOArrayNodes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5621/files - new: https://git.openjdk.java.net/jdk/pull/5621/files/47633cba..b4a5d105 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5621&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5621&range=03-04 Stats: 3 lines in 3 files changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5621.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5621/head:pull/5621 PR: https://git.openjdk.java.net/jdk/pull/5621 From simonis at openjdk.java.net Tue Sep 28 11:53:22 2021 From: simonis at openjdk.java.net (Volker Simonis) Date: Tue, 28 Sep 2021 11:53:22 GMT Subject: RFR: 8274242: Implement fast-path for ASCII-compatible CharsetEncoders on x86 [v5] In-Reply-To: <8nRoQznW3BlIXu7y0t9HhBgX1vMgFQAb6yoROtWQ7kA=.caa9857b-5c1c-4c68-ad15-05aaf02afc93@github.com> References: <_Dzhdy1vRupNXlRezru6UpkvEJV3Vlr149pbkryW2I4=.4c6e5e5b-7026-4410-9848-2a8d12aa71f7@github.com> <8nRoQznW3BlIXu7y0t9HhBgX1vMgFQAb6yoROtWQ7kA=.caa9857b-5c1c-4c68-ad15-05aaf02afc93@github.com> Message-ID: On Tue, 28 Sep 2021 10:01:43 GMT, Claes Redestad wrote: >> Not too much work. I recently introduced platform-specific `matcher_*.hpp` files, so since then adding a boolean constant is easy (no need to muck with the .ad files). > > Does the changes in 9800a99 resolve your concerns? In principle yes, but shouldn't the condition read: if (!Matcher::match_rule_supported(Op_EncodeISOArray) || !Matcher::supports_encode_ascii_array) return false; I.e. the intrinisc is supported if both conditions are true and not supported if either one of them is false? ------------- PR: https://git.openjdk.java.net/jdk/pull/5621 From plevart at openjdk.java.net Tue Sep 28 12:22:11 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Tue, 28 Sep 2021 12:22:11 GMT Subject: RFR: 8274299: Make Method/Constructor/Field accessors @Stable [v2] In-Reply-To: References: Message-ID: <4wmpcY07FjHQMLZqJIBJi_oEs8MHk3ILBE_uFEeXPOI=.f15af486-d013-48a2-a7f6-8379e5b96666@github.com> On Tue, 28 Sep 2021 09:50:45 GMT, Claes Redestad wrote: > Does `Reflection::new_method/...` (which are natively implemented constructors) need any special treatment for them to follow the same semantics as a Java-based constructor w.r.t. final field writes? Or could they be rewritten to call the equivalent java constructor in each case? > I don't think they need special treatment currently. The Method/Constructor/Field instances created by native code and returned via native methods are always the `root` objects that are never handed to user code. They are used internally in the caches and are published to other threads via volatile field write/read (see `java.lang.Class.ReflectionData`). User code only sees copies of those objects which are performed using constructors. ------------- PR: https://git.openjdk.java.net/jdk/pull/5694 From claes.redestad at oracle.com Tue Sep 28 12:39:54 2021 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 28 Sep 2021 12:39:54 +0000 Subject: RFR: 8274242: Implement fast-path for ASCII-compatible CharsetEncoders on x86 [v5] In-Reply-To: References: <_Dzhdy1vRupNXlRezru6UpkvEJV3Vlr149pbkryW2I4=.4c6e5e5b-7026-4410-9848-2a8d12aa71f7@github.com> <8nRoQznW3BlIXu7y0t9HhBgX1vMgFQAb6yoROtWQ7kA=.caa9857b-5c1c-4c68-ad15-05aaf02afc93@github.com> Message-ID: Yes, this was spotted and fixed already. Annoyingly the test I added didn't detect this so GHA was green, but it failed some tier2 tests on aarch64. I added extra safeguards by predicating matching the encode_iso_array instructions on the node being !ascii, which will cause C2 to report an error rather than silently using the iso variant for ascii-only nodes. H?mta Outlook f?r Android ________________________________ From: core-libs-dev on behalf of Volker Simonis Sent: Tuesday, September 28, 2021 1:53:22 PM To: core-libs-dev at openjdk.java.net ; hotspot-compiler-dev at openjdk.java.net ; nio-dev at openjdk.java.net Subject: Re: RFR: 8274242: Implement fast-path for ASCII-compatible CharsetEncoders on x86 [v5] On Tue, 28 Sep 2021 10:01:43 GMT, Claes Redestad wrote: >> Not too much work. I recently introduced platform-specific `matcher_*.hpp` files, so since then adding a boolean constant is easy (no need to muck with the .ad files). > > Does the changes in 9800a99 resolve your concerns? In principle yes, but shouldn't the condition read: if (!Matcher::match_rule_supported(Op_EncodeISOArray) || !Matcher::supports_encode_ascii_array) return false; I.e. the intrinisc is supported if both conditions are true and not supported if either one of them is false? ------------- PR: https://git.openjdk.java.net/jdk/pull/5621 From rriggs at openjdk.java.net Tue Sep 28 14:27:47 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 28 Sep 2021 14:27:47 GMT Subject: RFR: 8274397: [macOS] Stop setting env. var JAVA_MAIN_CLASS_ in launcher code [v2] In-Reply-To: References: <8j-vMsDYbF5100Dpc1DP_JGNV5V0W0D7i2fP7QnXCpU=.9169a246-f866-49c5-99fb-04f9fb946b9e@github.com> Message-ID: <0wQ3AZRHlfAHg6hZ7deEV7849Db3jxxUoK6NTZwIF9M=.abd0b563-50a5-4d53-99b9-d2bd7cd899cc@github.com> On Mon, 27 Sep 2021 23:50:38 GMT, Phil Race wrote: >> macOS launcher code sets JAVA_MAIN_CLASS_ which is read by AWT to set the name of the application in the system menu bar. >> >> Because this set shortly after the VM is running, it causes a thread safety issue described in https://bugs.openjdk.java.net/browse/JDK-8270549 >> >> Since the AWT already looks for the system property "apple.awt.application.name" for this same purpose, >> we can set that instead of the env. var and avoid the threading issue. >> >> This trades the JAVA_MAIN_CLASS_ pollution of the environment for setting a system property which is visible to apps as well but it seems a reasonable trade-off since we already (implicitly) support this variable anyway in preference to the env. var. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8274397: [macOS] Stop setting env. var JAVA_MAIN_CLASS_ in launcher code LGTM ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5724 From darcy at openjdk.java.net Tue Sep 28 15:05:29 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 28 Sep 2021 15:05:29 GMT Subject: RFR: 8274391: Suppress more warnings on non-serializable non-transient instance fields in java.util.concurrent In-Reply-To: References: Message-ID: On Tue, 28 Sep 2021 11:28:42 GMT, Doug Lea
        wrote: > > > Just to be sure, does this include only the conditionally serializable annotations in ForkJoinPool and ForkJoinTask in: https://github.com/openjdk/jdk/pull/5718/files/a20d9afbd7b49b452b3c9bdc9f2d56442b5e2fc6 If so, this looks OK to me. Yes, for java.util.concurrent, those are the only two changes needed to compile under the in-progress javac checks. ------------- PR: https://git.openjdk.java.net/jdk/pull/5718 From thartmann at openjdk.java.net Tue Sep 28 15:14:42 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Tue, 28 Sep 2021 15:14:42 GMT Subject: RFR: 8274242: Implement fast-path for ASCII-compatible CharsetEncoders on x86 [v5] In-Reply-To: References: Message-ID: On Tue, 28 Sep 2021 11:49:29 GMT, Claes Redestad wrote: >> This patch extends the `ISO_8859_1.implEncodeISOArray` intrinsic on x86 to work also for ASCII encoding, which makes for example the `UTF_8$Encoder` perform on par with (or outperform) similarly getting charset encoded bytes from a String. The former took a small performance hit in JDK 9, and the latter improved greatly in the same release. >> >> Extending the `EncodeIsoArray` intrinsics on other platforms should be possible, but I'm unfamiliar with the macro assembler in general and unlike the x86 intrinsic they don't use a simple vectorized mask to implement the latin-1 check. For example aarch64 seem to filter out the low bytes and then check if there's any bits set in the high bytes. Clever, but very different to the 0xFF80 2-byte mask that an ASCII test wants. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Add fail-safe predicate to all encode_iso_array to only match non-ASCII EncodeISOArrayNodes The latest version looks good to me. ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5621 From dnsimon at openjdk.java.net Tue Sep 28 15:44:35 2021 From: dnsimon at openjdk.java.net (Doug Simon) Date: Tue, 28 Sep 2021 15:44:35 GMT Subject: RFR: 8274397: [macOS] Stop setting env. var JAVA_MAIN_CLASS_ in launcher code [v2] In-Reply-To: References: <8j-vMsDYbF5100Dpc1DP_JGNV5V0W0D7i2fP7QnXCpU=.9169a246-f866-49c5-99fb-04f9fb946b9e@github.com> Message-ID: On Mon, 27 Sep 2021 23:50:38 GMT, Phil Race wrote: >> macOS launcher code sets JAVA_MAIN_CLASS_ which is read by AWT to set the name of the application in the system menu bar. >> >> Because this set shortly after the VM is running, it causes a thread safety issue described in https://bugs.openjdk.java.net/browse/JDK-8270549 >> >> Since the AWT already looks for the system property "apple.awt.application.name" for this same purpose, >> we can set that instead of the env. var and avoid the threading issue. >> >> This trades the JAVA_MAIN_CLASS_ pollution of the environment for setting a system property which is visible to apps as well but it seems a reasonable trade-off since we already (implicitly) support this variable anyway in preference to the env. var. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8274397: [macOS] Stop setting env. var JAVA_MAIN_CLASS_ in launcher code src/java.base/macosx/native/libjli/java_md_macosx.m line 842: > 840: * of the app as it appears in the system menu bar. > 841: * > 842: * Not idea if how much external code ever sets it, but use it if set, else "Not idea if" -> "No idea of" ------------- PR: https://git.openjdk.java.net/jdk/pull/5724 From iris at openjdk.java.net Tue Sep 28 16:37:32 2021 From: iris at openjdk.java.net (Iris Clark) Date: Tue, 28 Sep 2021 16:37:32 GMT Subject: RFR: 8274391: Suppress more warnings on non-serializable non-transient instance fields in java.util.concurrent In-Reply-To: References: Message-ID: On Mon, 27 Sep 2021 18:40:10 GMT, Joe Darcy wrote: > Follow-up change to JDK-8232230, augmentations to javac's Xlint:serial checking are out for review (https://github.com/openjdk/jdk/pull/5709) and java.util.concurrent would need some changes to pass under the expanded checks. > > The changes are to suppress warnings where non-transient fields in serializable types are not declared with a type statically known to be serializable. That isn't necessarily a correctness issues, but it does merit further scrutiny. > > In ForkJoinTask, the SuppressWarnings annotation previously applied in JDK-8232230, seems to have been misplaced to a different field; this change corrects it. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5718 From joehw at openjdk.java.net Tue Sep 28 16:46:27 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Tue, 28 Sep 2021 16:46:27 GMT Subject: RFR: 8274415: Suppress warnings on non-serializable non-transient instance fields in java.xml In-Reply-To: References: Message-ID: On Tue, 28 Sep 2021 07:07:37 GMT, Joe Darcy wrote: > Augmentations to javac's Xlint:serial checking are out for review (#5709) and the java.xml module would need some changes to pass under the expanded checks. > > The changes are to suppress warnings where non-transient fields in serializable types are not declared with a type statically known to be serializable. That isn't necessarily a correctness issues, but it does merit further scrutiny. > > I'll run a script to update the copyright years before pushing. Marked as reviewed by joehw (Reviewer). src/java.xml/share/classes/com/sun/org/apache/xerces/internal/dom/PSVIAttrNSImpl.java line 63: > 61: > 62: /** attribute declaration */ > 63: @SuppressWarnings("serial") // Type of field is not Serializable For the classes that contain a number of these fields, do we want to put the annotation at the class level? ------------- PR: https://git.openjdk.java.net/jdk/pull/5730 From mchung at openjdk.java.net Tue Sep 28 17:01:32 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 28 Sep 2021 17:01:32 GMT Subject: RFR: 8274394: Use Optional.isEmpty instead of !Optional.isPresent in jdk.jlink In-Reply-To: <7v27BGJ2oB6FbGGeNP0pibG52dTr4A1k87eTrQjf5ZQ=.dc5298db-07bd-45b5-85f4-38e87c4e6309@github.com> References: <7v27BGJ2oB6FbGGeNP0pibG52dTr4A1k87eTrQjf5ZQ=.dc5298db-07bd-45b5-85f4-38e87c4e6309@github.com> Message-ID: On Sun, 26 Sep 2021 13:58:35 GMT, Andrey Turbanov wrote: > I propose to replace usages of !Optional.isPresent() with Optional.isEmpty method. > It's makes code a bit easier to read. > Noticing negation before long chain of method calls is hard. LGTM ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5707 From github.com+10835776+stsypanov at openjdk.java.net Tue Sep 28 17:22:39 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Tue, 28 Sep 2021 17:22:39 GMT Subject: Integrated: 8274276: Cache normalizedBase URL in URLClassPath.FileLoader In-Reply-To: References: Message-ID: On Fri, 24 Sep 2021 10:35:54 GMT, ?????? ??????? wrote: > Currently on each invocation of `URLClassPath.FileLoader.getResource()` `normalizedBase` URL is recalculated using same final `baseURL` from parent class. This can be avoided giving significant improvement in memory consumption. Consider the benchmark: > > @State(Scope.Benchmark) > @BenchmarkMode(Mode.AverageTime) > @OutputTimeUnit(TimeUnit.NANOSECONDS) > @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) > public class URLClassPathBenchmark { > private final ClassLoader classLoader = getClass().getClassLoader(); > > @Benchmark > public URL getResource() { > return classLoader.getResource("file:./config/application.properties"); > } > } > > it demonstrates improvement brought in by this patch: > > before > Benchmark Mode Cnt Score Error Units > URLClassPathBenchmark.getResource avgt 50 2840,746 ? 22,206 ns/op > URLClassPathBenchmark.getResource:?gc.alloc.rate avgt 50 645,313 ? 8,072 MB/sec > URLClassPathBenchmark.getResource:?gc.alloc.rate.norm avgt 50 2403,258 ? 17,639 B/op > URLClassPathBenchmark.getResource:?gc.churn.G1_Eden_Space avgt 50 656,624 ? 116,090 MB/sec > URLClassPathBenchmark.getResource:?gc.churn.G1_Eden_Space.norm avgt 50 2450,175 ? 440,011 B/op > URLClassPathBenchmark.getResource:?gc.churn.G1_Survivor_Space avgt 50 0,123 ? 0,149 MB/sec > URLClassPathBenchmark.getResource:?gc.churn.G1_Survivor_Space.norm avgt 50 0,459 ? 0,556 B/op > URLClassPathBenchmark.getResource:?gc.count avgt 50 67,000 counts > URLClassPathBenchmark.getResource:?gc.time avgt 50 117,000 ms > > after > Benchmark Mode Cnt Score Error Units > URLClassPathBenchmark.getResource avgt 100 2596,719 ? 9,786 ns/op > URLClassPathBenchmark.getResource:?gc.alloc.rate avgt 100 448,780 ? 1,684 MB/sec > URLClassPathBenchmark.getResource:?gc.alloc.rate.norm avgt 100 1528,040 ? 0,005 B/op > URLClassPathBenchmark.getResource:?gc.churn.G1_Eden_Space avgt 100 479,905 ? 23,369 MB/sec > URLClassPathBenchmark.getResource:?gc.churn.G1_Eden_Space.norm avgt 100 1634,314 ? 79,821 B/op > URLClassPathBenchmark.getResource:?gc.churn.G1_Survivor_Space avgt 100 0,101 ? 0,097 MB/sec > URLClassPathBenchmark.getResource:?gc.churn.G1_Survivor_Space.norm avgt 100 0,345 ? 0,329 B/op > URLClassPathBenchmark.getResource:?gc.count avgt 100 98,000 counts > URLClassPathBenchmark.getResource:?gc.time avgt 100 218,000 ms This pull request has now been integrated. Changeset: 94f5e807 Author: Sergey Tsypanov Committer: Daniel Fuchs URL: https://git.openjdk.java.net/jdk/commit/94f5e807c91674cf79e543a66cff1819206a790b Stats: 5 lines in 1 file changed: 2 ins; 1 del; 2 mod 8274276: Cache normalizedBase URL in URLClassPath.FileLoader Reviewed-by: dfuchs ------------- PR: https://git.openjdk.java.net/jdk/pull/5677 From github.com+741251+turbanoff at openjdk.java.net Tue Sep 28 17:25:33 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Tue, 28 Sep 2021 17:25:33 GMT Subject: Integrated: 8274394: Use Optional.isEmpty instead of !Optional.isPresent in jdk.jlink In-Reply-To: <7v27BGJ2oB6FbGGeNP0pibG52dTr4A1k87eTrQjf5ZQ=.dc5298db-07bd-45b5-85f4-38e87c4e6309@github.com> References: <7v27BGJ2oB6FbGGeNP0pibG52dTr4A1k87eTrQjf5ZQ=.dc5298db-07bd-45b5-85f4-38e87c4e6309@github.com> Message-ID: On Sun, 26 Sep 2021 13:58:35 GMT, Andrey Turbanov wrote: > I propose to replace usages of !Optional.isPresent() with Optional.isEmpty method. > It's makes code a bit easier to read. > Noticing negation before long chain of method calls is hard. This pull request has now been integrated. Changeset: 6f4cefbc Author: Andrey Turbanov Committer: Mandy Chung URL: https://git.openjdk.java.net/jdk/commit/6f4cefbcbaad38dcacd4e047c6c232a0a7a2c19c Stats: 8 lines in 5 files changed: 0 ins; 0 del; 8 mod 8274394: Use Optional.isEmpty instead of !Optional.isPresent in jdk.jlink Reviewed-by: alanb, mchung ------------- PR: https://git.openjdk.java.net/jdk/pull/5707 From mchung at openjdk.java.net Tue Sep 28 17:58:31 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 28 Sep 2021 17:58:31 GMT Subject: RFR: 8274299: Make Method/Constructor/Field accessors @Stable [v2] In-Reply-To: References: Message-ID: On Tue, 28 Sep 2021 08:25:17 GMT, Peter Levart wrote: >> This patch improves reflective access speed as shown by the included benchmarks: >> >> https://jmh.morethan.io/?gists=902f4b43519c4f96c7abcd14cdc2d27d,ac490481e3001c710d75d6071c10b23a >> >> ... and is also a prerequisite to make JEP 416 (Reimplement Core Reflection with Method Handle) perform better in some circumstances. > > Peter Levart has updated the pull request incrementally with one additional commit since the last revision: > > Make Method/Constructor/Field instance fields initialized in the constructors final > making fields @stable does improve performance since `jdk.internal.reflect` and `java.lang.reflect` are not final-field-trusted packages as you noted above. If JEP 416 makes them trusted, it can also remove the @stable annotations. But for backporting, they better stay there. WDYT? Thanks for clarifying it. Okay to keep those changes. > I made them final in newly added patch now. So we can either merge this or previous commit if desired. I would suggest to use the previous commit so that this patch focuses on this specific change - making the accessor @Stable. We can make the fields final together with adding `jdk.internal.reflect` and `java.lang.reflect` in the trusted packages for TNSFF in JEP 416. ------------- PR: https://git.openjdk.java.net/jdk/pull/5694 From weijun at openjdk.java.net Tue Sep 28 18:31:36 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 28 Sep 2021 18:31:36 GMT Subject: RFR: 8270380: Change the default value of the java.security.manager system property to disallow In-Reply-To: References: Message-ID: On Tue, 31 Aug 2021 02:05:06 GMT, Weijun Wang wrote: >> This change modifies the default value of the `java.security.manager` system property from "allow" to "disallow". This means unless it's explicitly set to "allow", any call to `System.setSecurityManager()` would throw an UOE. >> >> The `AllowSecurityManager.java` and `SecurityManagerWarnings.java` tests are updated to confirm this behavior change. Two other tests are updated because they were added after JDK-8267184 and do not have `-Djava.security.manager=allow` on its `@run` line even it they need to install a `SecurityManager` at runtime. >> >> Please note that this code change requires jtreg to be upgraded to 6.1, where a security manager [will not be set](https://bugs.openjdk.java.net/browse/CODETOOLS-7902990). > > New commit pushed. Sections added. > @wangweij This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration! Still waiting for jtreg upgraded to 6.1. ------------- PR: https://git.openjdk.java.net/jdk/pull/5204 From darcy at openjdk.java.net Tue Sep 28 21:04:25 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 28 Sep 2021 21:04:25 GMT Subject: RFR: 8274415: Suppress warnings on non-serializable non-transient instance fields in java.xml [v2] In-Reply-To: References: Message-ID: > Augmentations to javac's Xlint:serial checking are out for review (#5709) and the java.xml module would need some changes to pass under the expanded checks. > > The changes are to suppress warnings where non-transient fields in serializable types are not declared with a type statically known to be serializable. That isn't necessarily a correctness issues, but it does merit further scrutiny. > > I'll run a script to update the copyright years before pushing. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Update copyrights. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5730/files - new: https://git.openjdk.java.net/jdk/pull/5730/files/7f31bfdc..5af64c98 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5730&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5730&range=00-01 Stats: 18 lines in 18 files changed: 0 ins; 0 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/5730.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5730/head:pull/5730 PR: https://git.openjdk.java.net/jdk/pull/5730 From darcy at openjdk.java.net Tue Sep 28 21:04:27 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 28 Sep 2021 21:04:27 GMT Subject: RFR: 8274415: Suppress warnings on non-serializable non-transient instance fields in java.xml [v2] In-Reply-To: References: Message-ID: On Tue, 28 Sep 2021 16:42:49 GMT, Joe Wang wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> Update copyrights. > > src/java.xml/share/classes/com/sun/org/apache/xerces/internal/dom/PSVIAttrNSImpl.java line 63: > >> 61: >> 62: /** attribute declaration */ >> 63: @SuppressWarnings("serial") // Type of field is not Serializable > > For the classes that contain a number of these fields, do we want to put the annotation at the class level? It is more precise to just annotate the fields in question. Putting the annotation at the class level would disable all serial checking for the class so I think it is preferable to label the fields. ------------- PR: https://git.openjdk.java.net/jdk/pull/5730 From darcy at openjdk.java.net Tue Sep 28 21:05:25 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 28 Sep 2021 21:05:25 GMT Subject: Integrated: 8274415: Suppress warnings on non-serializable non-transient instance fields in java.xml In-Reply-To: References: Message-ID: On Tue, 28 Sep 2021 07:07:37 GMT, Joe Darcy wrote: > Augmentations to javac's Xlint:serial checking are out for review (#5709) and the java.xml module would need some changes to pass under the expanded checks. > > The changes are to suppress warnings where non-transient fields in serializable types are not declared with a type statically known to be serializable. That isn't necessarily a correctness issues, but it does merit further scrutiny. > > I'll run a script to update the copyright years before pushing. This pull request has now been integrated. Changeset: 6a477bda Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/6a477bda856d051904551995539e6c6bab1fa7da Stats: 63 lines in 27 files changed: 45 ins; 0 del; 18 mod 8274415: Suppress warnings on non-serializable non-transient instance fields in java.xml Reviewed-by: joehw ------------- PR: https://git.openjdk.java.net/jdk/pull/5730 From github.com+741251+turbanoff at openjdk.java.net Tue Sep 28 21:18:43 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Tue, 28 Sep 2021 21:18:43 GMT Subject: RFR: 8274464: Remove redundant stream() call before forEach in java.* modules Message-ID: 8274464: Remove redundant stream() call before forEach in java.* modules ------------- Commit messages: - [PATCH] Remove redundant stream() call before forEach in java.* modules Changes: https://git.openjdk.java.net/jdk/pull/5520/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5520&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274464 Stats: 8 lines in 4 files changed: 0 ins; 3 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/5520.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5520/head:pull/5520 PR: https://git.openjdk.java.net/jdk/pull/5520 From darcy at openjdk.java.net Tue Sep 28 21:25:36 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 28 Sep 2021 21:25:36 GMT Subject: Integrated: 8274391: Suppress more warnings on non-serializable non-transient instance fields in java.util.concurrent In-Reply-To: References: Message-ID: On Mon, 27 Sep 2021 18:40:10 GMT, Joe Darcy wrote: > Follow-up change to JDK-8232230, augmentations to javac's Xlint:serial checking are out for review (https://github.com/openjdk/jdk/pull/5709) and java.util.concurrent would need some changes to pass under the expanded checks. > > The changes are to suppress warnings where non-transient fields in serializable types are not declared with a type statically known to be serializable. That isn't necessarily a correctness issues, but it does merit further scrutiny. > > In ForkJoinTask, the SuppressWarnings annotation previously applied in JDK-8232230, seems to have been misplaced to a different field; this change corrects it. This pull request has now been integrated. Changeset: 2072bc77 Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/2072bc77b4541c283adaa7eb51a38adcaf711fff Stats: 3 lines in 2 files changed: 2 ins; 1 del; 0 mod 8274391: Suppress more warnings on non-serializable non-transient instance fields in java.util.concurrent Reviewed-by: lancea, bpb, alanb, iris ------------- PR: https://git.openjdk.java.net/jdk/pull/5718 From redestad at openjdk.java.net Tue Sep 28 22:44:35 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 28 Sep 2021 22:44:35 GMT Subject: RFR: 8274299: Make Method/Constructor/Field accessors @Stable [v2] In-Reply-To: References: Message-ID: On Tue, 28 Sep 2021 08:25:17 GMT, Peter Levart wrote: >> This patch improves reflective access speed as shown by the included benchmarks: >> >> https://jmh.morethan.io/?gists=902f4b43519c4f96c7abcd14cdc2d27d,ac490481e3001c710d75d6071c10b23a >> >> ... and is also a prerequisite to make JEP 416 (Reimplement Core Reflection with Method Handle) perform better in some circumstances. > > Peter Levart has updated the pull request incrementally with one additional commit since the last revision: > > Make Method/Constructor/Field instance fields initialized in the constructors final I'm fine with going back to the previous iteration. I'd add `@Stable` to the same fields in `Constructor`, too, though. ------------- PR: https://git.openjdk.java.net/jdk/pull/5694 From joe.darcy at oracle.com Wed Sep 29 01:01:03 2021 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Tue, 28 Sep 2021 18:01:03 -0700 Subject: RFR: 8273656: Improve java.lang.invoke.MethodType.parameterList() and its usage In-Reply-To: References: Message-ID: <4d8e796a-5b6c-3284-f440-37475e03a221@oracle.com> On 9/22/2021 4:53 PM, Claes Redestad wrote: > On Mon, 13 Sep 2021 11:06:15 GMT, ?????? ??????? wrote: > >> Currently the method is implemented like >> >> public List> parameterList() { >> return Collections.unmodifiableList(Arrays.asList(ptypes.clone())); >> } >> >> This seems to be excessive, as three objects are allocated here. Instead we can use `List.of(ptypes)` which doesn't allocate anything for empty array and for one of length 1 and 2 it allocates lightweight objects with 2 fields, still copying longer arrays. This is likely to be fruitful as most of methods have 0-2 parameters. >> >> Also there is a couple of cases when `MethodType.parameterLis()` is called to get its size, which is excessive either as we can use `MethodType.parameterCount()` instead. > I think it's OK and even expected to file a CSRs retroactively when you realize post integration that there's a behavior change. I recall doing so at least once in the past. This scenario is discussed in the CSR FAQ: > Q: Timing wise, when do I need to file a CSR request? > A: A CSR request needs to be filed and approved /before/ the > corresponding change is pushed to a JDK release line of development. > In exceptional circumstances, the need for a CSR review may be > recognized only after a push has already occurred. In such cases, a > retroactive CSR review can be conducted. The results of such a > retroactive review may require updates to the change, up to and > including complete removal of the change. https://wiki.openjdk.java.net/display/csr/CSR+FAQs For the change in question, are there any interactions with class file redefinition effects? -Joe From serb at openjdk.java.net Wed Sep 29 01:49:37 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Wed, 29 Sep 2021 01:49:37 GMT Subject: RFR: 8274397: [macOS] Stop setting env. var JAVA_MAIN_CLASS_ in launcher code [v2] In-Reply-To: References: <8j-vMsDYbF5100Dpc1DP_JGNV5V0W0D7i2fP7QnXCpU=.9169a246-f866-49c5-99fb-04f9fb946b9e@github.com> Message-ID: On Mon, 27 Sep 2021 23:50:38 GMT, Phil Race wrote: >> macOS launcher code sets JAVA_MAIN_CLASS_ which is read by AWT to set the name of the application in the system menu bar. >> >> Because this set shortly after the VM is running, it causes a thread safety issue described in https://bugs.openjdk.java.net/browse/JDK-8270549 >> >> Since the AWT already looks for the system property "apple.awt.application.name" for this same purpose, >> we can set that instead of the env. var and avoid the threading issue. >> >> This trades the JAVA_MAIN_CLASS_ pollution of the environment for setting a system property which is visible to apps as well but it seems a reasonable trade-off since we already (implicitly) support this variable anyway in preference to the env. var. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8274397: [macOS] Stop setting env. var JAVA_MAIN_CLASS_ in launcher code src/java.base/macosx/native/libjli/java_md_macosx.m line 879: > 877: } > 878: > 879: (*env)->DeleteLocalRef(env, jKey); I am not sure about error handling, the jkey is not removed when NULL_CHECK is used. Also an exceptions are not cleared in case of NULL_CHECK like in other cases, is it intentional? ------------- PR: https://git.openjdk.java.net/jdk/pull/5724 From prr at openjdk.java.net Wed Sep 29 03:12:39 2021 From: prr at openjdk.java.net (Phil Race) Date: Wed, 29 Sep 2021 03:12:39 GMT Subject: RFR: 8274397: [macOS] Stop setting env. var JAVA_MAIN_CLASS_ in launcher code [v2] In-Reply-To: References: <8j-vMsDYbF5100Dpc1DP_JGNV5V0W0D7i2fP7QnXCpU=.9169a246-f866-49c5-99fb-04f9fb946b9e@github.com> Message-ID: On Wed, 29 Sep 2021 01:46:32 GMT, Sergey Bylokhov wrote: >> Phil Race has updated the pull request incrementally with one additional commit since the last revision: >> >> 8274397: [macOS] Stop setting env. var JAVA_MAIN_CLASS_ in launcher code > > src/java.base/macosx/native/libjli/java_md_macosx.m line 879: > >> 877: } >> 878: >> 879: (*env)->DeleteLocalRef(env, jKey); > > I am not sure about error handling, the jkey is not removed when NULL_CHECK is used. Also an exceptions are not cleared in case of NULL_CHECK like in other cases, is it intentional? Well .. they aren't removed by the existing code either. And this is the launcher. So far as I can tell if we error out of here (as I found when I made a typo in a method signature) the VM exits very rapidly. So if I do anything here, it would be to remove DeleteLocalRef since it really doesn't matter to clean up local refs when you are either bailing from native .. or the entire process .. cleaning up when you are continuing on (as the code does) is perhaps more important since you might need more local refs before you are done. Or file a separate bug against the launcher and JNI clean up after error handling. java.base/share/native/libjli/java.c is a good example of where the same pattern exists. ------------- PR: https://git.openjdk.java.net/jdk/pull/5724 From prr at openjdk.java.net Wed Sep 29 03:39:09 2021 From: prr at openjdk.java.net (Phil Race) Date: Wed, 29 Sep 2021 03:39:09 GMT Subject: RFR: 8274397: [macOS] Stop setting env. var JAVA_MAIN_CLASS_ in launcher code [v3] In-Reply-To: <8j-vMsDYbF5100Dpc1DP_JGNV5V0W0D7i2fP7QnXCpU=.9169a246-f866-49c5-99fb-04f9fb946b9e@github.com> References: <8j-vMsDYbF5100Dpc1DP_JGNV5V0W0D7i2fP7QnXCpU=.9169a246-f866-49c5-99fb-04f9fb946b9e@github.com> Message-ID: > macOS launcher code sets JAVA_MAIN_CLASS_ which is read by AWT to set the name of the application in the system menu bar. > > Because this set shortly after the VM is running, it causes a thread safety issue described in https://bugs.openjdk.java.net/browse/JDK-8270549 > > Since the AWT already looks for the system property "apple.awt.application.name" for this same purpose, > we can set that instead of the env. var and avoid the threading issue. > > This trades the JAVA_MAIN_CLASS_ pollution of the environment for setting a system property which is visible to apps as well but it seems a reasonable trade-off since we already (implicitly) support this variable anyway in preference to the env. var. Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8274397: Stop setting env. var JAVA_MAIN_CLASS_ in launcher code ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5724/files - new: https://git.openjdk.java.net/jdk/pull/5724/files/93108c59..96a5590c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5724&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5724&range=01-02 Stats: 24 lines in 1 file changed: 23 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5724.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5724/head:pull/5724 PR: https://git.openjdk.java.net/jdk/pull/5724 From prr at openjdk.java.net Wed Sep 29 03:41:40 2021 From: prr at openjdk.java.net (Phil Race) Date: Wed, 29 Sep 2021 03:41:40 GMT Subject: RFR: 8274397: [macOS] Stop setting env. var JAVA_MAIN_CLASS_ in launcher code [v2] In-Reply-To: References: <8j-vMsDYbF5100Dpc1DP_JGNV5V0W0D7i2fP7QnXCpU=.9169a246-f866-49c5-99fb-04f9fb946b9e@github.com> Message-ID: On Mon, 27 Sep 2021 23:50:38 GMT, Phil Race wrote: >> macOS launcher code sets JAVA_MAIN_CLASS_ which is read by AWT to set the name of the application in the system menu bar. >> >> Because this set shortly after the VM is running, it causes a thread safety issue described in https://bugs.openjdk.java.net/browse/JDK-8270549 >> >> Since the AWT already looks for the system property "apple.awt.application.name" for this same purpose, >> we can set that instead of the env. var and avoid the threading issue. >> >> This trades the JAVA_MAIN_CLASS_ pollution of the environment for setting a system property which is visible to apps as well but it seems a reasonable trade-off since we already (implicitly) support this variable anyway in preference to the env. var. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8274397: [macOS] Stop setting env. var JAVA_MAIN_CLASS_ in launcher code I've added code in the launcher part that strips the package name from what is seen. This was previously done in the AWT code for MAIN_CLASS_ since it was presumably the only code setting that but I didn't do it because before because I didn't want to interfere with what an app might have set as the system property .. but .. if the app didn't set it and we derived it, then I realised we probably should be consistent with what happened before and only the launcher code knows whether it was set by itself or the app ------------- PR: https://git.openjdk.java.net/jdk/pull/5724 From prr at openjdk.java.net Wed Sep 29 03:50:32 2021 From: prr at openjdk.java.net (Phil Race) Date: Wed, 29 Sep 2021 03:50:32 GMT Subject: RFR: 8274397: [macOS] Stop setting env. var JAVA_MAIN_CLASS_ in launcher code [v3] In-Reply-To: References: <8j-vMsDYbF5100Dpc1DP_JGNV5V0W0D7i2fP7QnXCpU=.9169a246-f866-49c5-99fb-04f9fb946b9e@github.com> Message-ID: On Wed, 29 Sep 2021 03:39:09 GMT, Phil Race wrote: >> macOS launcher code sets JAVA_MAIN_CLASS_ which is read by AWT to set the name of the application in the system menu bar. >> >> Because this set shortly after the VM is running, it causes a thread safety issue described in https://bugs.openjdk.java.net/browse/JDK-8270549 >> >> Since the AWT already looks for the system property "apple.awt.application.name" for this same purpose, >> we can set that instead of the env. var and avoid the threading issue. >> >> This trades the JAVA_MAIN_CLASS_ pollution of the environment for setting a system property which is visible to apps as well but it seems a reasonable trade-off since we already (implicitly) support this variable anyway in preference to the env. var. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8274397: Stop setting env. var JAVA_MAIN_CLASS_ in launcher code And, oh, the env. var test code I needed to delete was checking not for a useful value but just that the env var was there. I wrote a simple jtreg test or the new code that set the system property and tested the expected value (default or set) but it seems jtreg makes MainWrapper the main class that is found regardless of main/othervm so I am currently grumbling quietly to myself about whether to add a test which is equivalent to the previous one which just tests the property has a value, or to (I suppose) write a more sophisticated test that has to exec another VM where it *should* be able to properly verify it. ------------- PR: https://git.openjdk.java.net/jdk/pull/5724 From lzang at openjdk.java.net Wed Sep 29 07:35:09 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Wed, 29 Sep 2021 07:35:09 GMT Subject: RFR: 4890732: GZIPOutputStream doesn't support optional GZIP fields [v13] In-Reply-To: References: Message-ID: <_gdLoSBFDcFp0n3op9AeftK1I7fIeC1s5mGXeWBg6ro=.f80f2080-c2df-41d5-a99d-aaf97c3f5159@github.com> > 4890732: GZIPOutputStream doesn't support optional GZIP fields Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: - remove trailing whitespaces - fix build warnings - Merge branch 'master' into gzip-field - code refactor - Merge branch 'master' into gzip-field - delete trailing spaces - refine code - Merge branch 'master' into gzip-field - change since version to 18 - Merge branch 'master' into gzip-field - ... and 11 more: https://git.openjdk.java.net/jdk/compare/756d22c3...128e7ff4 ------------- Changes: https://git.openjdk.java.net/jdk/pull/3072/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3072&range=12 Stats: 657 lines in 4 files changed: 607 ins; 26 del; 24 mod Patch: https://git.openjdk.java.net/jdk/pull/3072.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3072/head:pull/3072 PR: https://git.openjdk.java.net/jdk/pull/3072 From lzang at openjdk.java.net Wed Sep 29 07:35:12 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Wed, 29 Sep 2021 07:35:12 GMT Subject: RFR: 4890732: GZIPOutputStream doesn't support optional GZIP fields [v12] In-Reply-To: References: Message-ID: On Mon, 6 Sep 2021 07:20:11 GMT, Lin Zang wrote: >> 4890732: GZIPOutputStream doesn't support optional GZIP fields > > Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: > > - Merge branch 'master' into gzip-field > - delete trailing spaces > - refine code > - Merge branch 'master' into gzip-field > - change since version to 18 > - Merge branch 'master' into gzip-field > - Merge branch 'master' into gzip-field > - Add api in GZIPInputStream to get header data > - Merge remote-tracking branch 'upstream/master' into gzip-field > - remove trailing spaces > - ... and 7 more: https://git.openjdk.java.net/jdk/compare/c640fe42...196caedb Hi @liach? Thanks for your review! I updated the change based on your comments. BRs, Lin ------------- PR: https://git.openjdk.java.net/jdk/pull/3072 From jboes at openjdk.java.net Wed Sep 29 08:35:36 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Wed, 29 Sep 2021 08:35:36 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server In-Reply-To: References: Message-ID: On Tue, 28 Sep 2021 10:30:21 GMT, Bernd Eckenfels wrote: > * For all interfaces use "-b 0.0.0.0" (IPv4) or "-b ::" (IPv6) > > Instead of: > > * For 0.0.0.0 (all interfaces) use -b 0.0.0.0 or -b ::0 > > In the usage? > > (I think ?::? is canon?) Good point, "::" is recommended, e.g. in RFC5952 [1]. I think IPv4/IPv6 is obvious though, so I suggest: `* For all interfaces use "-b 0.0.0.0" or "-b ::"` [1] https://datatracker.ietf.org/doc/html/rfc5952 ------------- PR: https://git.openjdk.java.net/jdk/pull/5505 From dfuchs at openjdk.java.net Wed Sep 29 10:08:34 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 29 Sep 2021 10:08:34 GMT Subject: RFR: 8274464: Remove redundant stream() call before forEach in java.* modules In-Reply-To: References: Message-ID: On Wed, 15 Sep 2021 07:12:25 GMT, Andrey Turbanov wrote: > 8274464: Remove redundant stream() call before forEach in java.* modules LGTM ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5520 From jboes at openjdk.java.net Wed Sep 29 11:02:05 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Wed, 29 Sep 2021 11:02:05 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v8] In-Reply-To: References: Message-ID: > This change implements a simple web server that can be run on the command-line with `java -m jdk.httpserver`. > > This is facilitated by adding an entry point for the `jdk.httpserver` module, an implementation class whose main method is run when the above command is executed. This is the first such module entry point in the JDK. > > The server is a minimal HTTP server that serves the static files of a given directory, similar to existing alternatives on other platforms and convenient for testing, development, and debugging. > > Additionally, a small API is introduced for programmatic creation and customization. > > Testing: tier1-3. Julia Boes has updated the pull request incrementally with one additional commit since the last revision: update output for all interfaces ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5505/files - new: https://git.openjdk.java.net/jdk/pull/5505/files/7f994476..a7ce5b2c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5505&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5505&range=06-07 Stats: 12 lines in 4 files changed: 0 ins; 0 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/5505.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5505/head:pull/5505 PR: https://git.openjdk.java.net/jdk/pull/5505 From dfuchs at openjdk.java.net Wed Sep 29 11:06:41 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 29 Sep 2021 11:06:41 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v8] In-Reply-To: References: Message-ID: <4VFt3zf3W_0HTZMFgE3USo6_AGWr10lSPyvfFWnl6TE=.76509a4a-9f8b-4f2b-8f4d-f8a622ce45c6@github.com> On Wed, 29 Sep 2021 11:02:05 GMT, Julia Boes wrote: >> This change implements a simple web server that can be run on the command-line with `java -m jdk.httpserver`. >> >> This is facilitated by adding an entry point for the `jdk.httpserver` module, an implementation class whose main method is run when the above command is executed. This is the first such module entry point in the JDK. >> >> The server is a minimal HTTP server that serves the static files of a given directory, similar to existing alternatives on other platforms and convenient for testing, development, and debugging. >> >> Additionally, a small API is introduced for programmatic creation and customization. >> >> Testing: tier1-3. > > Julia Boes has updated the pull request incrementally with one additional commit since the last revision: > > update output for all interfaces Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5505 From github.com+741251+turbanoff at openjdk.java.net Wed Sep 29 11:17:34 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Wed, 29 Sep 2021 11:17:34 GMT Subject: RFR: 8273435: Remove redundant zero-length check in ClassDesc.of In-Reply-To: References: Message-ID: On Wed, 18 Aug 2021 07:28:57 GMT, Andrey Turbanov wrote: > After [JDK-8215510](https://bugs.openjdk.java.net/browse/JDK-8215510) (eed3a536c0) this condition is always `false`. Empty package name is handled separately. > Found by IntelliJ inspection. Can someone sponsor changes, please? ------------- PR: https://git.openjdk.java.net/jdk/pull/5157 From redestad at openjdk.java.net Wed Sep 29 12:36:23 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 29 Sep 2021 12:36:23 GMT Subject: RFR: 8274242: Implement fast-path for ASCII-compatible CharsetEncoders on x86 [v6] In-Reply-To: References: Message-ID: > This patch extends the `ISO_8859_1.implEncodeISOArray` intrinsic on x86 to work also for ASCII encoding, which makes for example the `UTF_8$Encoder` perform on par with (or outperform) similarly getting charset encoded bytes from a String. The former took a small performance hit in JDK 9, and the latter improved greatly in the same release. > > Extending the `EncodeIsoArray` intrinsics on other platforms should be possible, but I'm unfamiliar with the macro assembler in general and unlike the x86 intrinsic they don't use a simple vectorized mask to implement the latin-1 check. For example aarch64 seem to filter out the low bytes and then check if there's any bits set in the high bytes. Clever, but very different to the 0xFF80 2-byte mask that an ASCII test wants. Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Clean up and make TestEncodeIntrinsics fail on the particular scenario where the ISO intrinsic was used in place of the ASCII-only intrinsic ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5621/files - new: https://git.openjdk.java.net/jdk/pull/5621/files/b4a5d105..4ad9c08a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5621&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5621&range=04-05 Stats: 8 lines in 1 file changed: 1 ins; 1 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/5621.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5621/head:pull/5621 PR: https://git.openjdk.java.net/jdk/pull/5621 From redestad at openjdk.java.net Wed Sep 29 12:41:40 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 29 Sep 2021 12:41:40 GMT Subject: RFR: 8274242: Implement fast-path for ASCII-compatible CharsetEncoders on x86 [v6] In-Reply-To: References: <5lVTU7su0xmkfNlex-Pv_yoeuJpnoCyalI42oLSjGzg=.54d143bc-ede4-4ec8-a257-1538f43ea632@github.com> Message-ID: On Mon, 27 Sep 2021 12:27:32 GMT, Tobias Hartmann wrote: >>> Should we remove the "iso" part from the method/class names? >> >> I'm open to suggestions, but I've not been able to think of anything better. `encodeISOOrASCII` doesn't seem helpful and since ASCII is a subset of the ISO-8859-1 encoding referred to by the "iso" moniker then the ASCII-only variant is technically encoding chars to valid ISO-8859-1. > >> > Should we remove the "iso" part from the method/class names? >> >> I'm open to suggestions, but I've not been able to think of anything better. `encodeISOOrASCII` doesn't seem helpful and since ASCII is a subset of the ISO-8859-1 encoding referred to by the "iso" moniker then the ASCII-only variant is technically encoding chars to valid ISO-8859-1. > > Okay, that's fine with me. Thanks for reviewing, @TobiHartmann I also cleaned up the test and made sure it fails when there's a logic bug like the one I introduced in 9800a99 where the ISO array intrinsic would be matched for a case requiring the ASCII-only array intrinsic. The test was (in)conveniently never testing out-of-range characters in the 0x80-0xFF range, which is precisely where the two intrinsics would produce different results. I hope this doesn't require another 24 hour grace period. ?? ------------- PR: https://git.openjdk.java.net/jdk/pull/5621 From thartmann at openjdk.java.net Wed Sep 29 12:45:34 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Wed, 29 Sep 2021 12:45:34 GMT Subject: RFR: 8274242: Implement fast-path for ASCII-compatible CharsetEncoders on x86 [v6] In-Reply-To: References: Message-ID: On Wed, 29 Sep 2021 12:36:23 GMT, Claes Redestad wrote: >> This patch extends the `ISO_8859_1.implEncodeISOArray` intrinsic on x86 to work also for ASCII encoding, which makes for example the `UTF_8$Encoder` perform on par with (or outperform) similarly getting charset encoded bytes from a String. The former took a small performance hit in JDK 9, and the latter improved greatly in the same release. >> >> Extending the `EncodeIsoArray` intrinsics on other platforms should be possible, but I'm unfamiliar with the macro assembler in general and unlike the x86 intrinsic they don't use a simple vectorized mask to implement the latin-1 check. For example aarch64 seem to filter out the low bytes and then check if there's any bits set in the high bytes. Clever, but very different to the 0xFF80 2-byte mask that an ASCII test wants. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Clean up and make TestEncodeIntrinsics fail on the particular scenario where the ISO intrinsic was used in place of the ASCII-only intrinsic The incremental change looks good and trivial to me. ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5621 From redestad at openjdk.java.net Wed Sep 29 12:53:24 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 29 Sep 2021 12:53:24 GMT Subject: RFR: 8274242: Implement fast-path for ASCII-compatible CharsetEncoders on x86 [v7] In-Reply-To: References: Message-ID: > This patch extends the `ISO_8859_1.implEncodeISOArray` intrinsic on x86 to work also for ASCII encoding, which makes for example the `UTF_8$Encoder` perform on par with (or outperform) similarly getting charset encoded bytes from a String. The former took a small performance hit in JDK 9, and the latter improved greatly in the same release. > > Extending the `EncodeIsoArray` intrinsics on other platforms should be possible, but I'm unfamiliar with the macro assembler in general and unlike the x86 intrinsic they don't use a simple vectorized mask to implement the latin-1 check. For example aarch64 seem to filter out the low bytes and then check if there's any bits set in the high bytes. Clever, but very different to the 0xFF80 2-byte mask that an ASCII test wants. Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Clean up some stale test comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5621/files - new: https://git.openjdk.java.net/jdk/pull/5621/files/4ad9c08a..ebe509ef Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5621&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5621&range=05-06 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5621.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5621/head:pull/5621 PR: https://git.openjdk.java.net/jdk/pull/5621 From redestad at openjdk.java.net Wed Sep 29 12:58:33 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 29 Sep 2021 12:58:33 GMT Subject: RFR: 8274242: Implement fast-path for ASCII-compatible CharsetEncoders on x86 [v7] In-Reply-To: References: <_Dzhdy1vRupNXlRezru6UpkvEJV3Vlr149pbkryW2I4=.4c6e5e5b-7026-4410-9848-2a8d12aa71f7@github.com> <8nRoQznW3BlIXu7y0t9HhBgX1vMgFQAb6yoROtWQ7kA=.caa9857b-5c1c-4c68-ad15-05aaf02afc93@github.com> Message-ID: On Tue, 28 Sep 2021 11:49:28 GMT, Volker Simonis wrote: >> Does the changes in 9800a99 resolve your concerns? > > In principle yes, but shouldn't the condition read: > > if (!Matcher::match_rule_supported(Op_EncodeISOArray) || !Matcher::supports_encode_ascii_array) return false; > > I.e. the intrinisc is supported if both conditions are true and not supported if either one of them is false? Resolved in 47633cb ------------- PR: https://git.openjdk.java.net/jdk/pull/5621 From sgehwolf at openjdk.java.net Wed Sep 29 12:58:44 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Wed, 29 Sep 2021 12:58:44 GMT Subject: RFR: 8274506: TestPids.java and TestPidsLimit.java fail with podman run as root Message-ID: Please review this test fix to work around a podman issue[1]. `podman` expects for the "unlimited" option of `--pids-limit` to be `0` whereas `docker` wants `-1`. See the JBS bug for details. Thoughts? Testing: hotspot/jdk container tests with docker and podman. Two pids tests used to fail and pass with the patch. [1] https://github.com/containers/podman/issues/11782 ------------- Commit messages: - 8274506: TestPids.java and TestPidsLimit.java fail with podman run as root Changes: https://git.openjdk.java.net/jdk/pull/5750/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5750&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274506 Stats: 12 lines in 2 files changed: 10 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5750.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5750/head:pull/5750 PR: https://git.openjdk.java.net/jdk/pull/5750 From redestad at openjdk.java.net Wed Sep 29 13:02:05 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 29 Sep 2021 13:02:05 GMT Subject: Integrated: 8274242: Implement fast-path for ASCII-compatible CharsetEncoders on x86 In-Reply-To: References: Message-ID: On Tue, 21 Sep 2021 21:58:48 GMT, Claes Redestad wrote: > This patch extends the `ISO_8859_1.implEncodeISOArray` intrinsic on x86 to work also for ASCII encoding, which makes for example the `UTF_8$Encoder` perform on par with (or outperform) similarly getting charset encoded bytes from a String. The former took a small performance hit in JDK 9, and the latter improved greatly in the same release. > > Extending the `EncodeIsoArray` intrinsics on other platforms should be possible, but I'm unfamiliar with the macro assembler in general and unlike the x86 intrinsic they don't use a simple vectorized mask to implement the latin-1 check. For example aarch64 seem to filter out the low bytes and then check if there's any bits set in the high bytes. Clever, but very different to the 0xFF80 2-byte mask that an ASCII test wants. This pull request has now been integrated. Changeset: aaa36cc0 Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/aaa36cc0069043e34b47e89769eb9eba39e5362a Stats: 783 lines in 28 files changed: 392 ins; 355 del; 36 mod 8274242: Implement fast-path for ASCII-compatible CharsetEncoders on x86 Reviewed-by: naoto, thartmann ------------- PR: https://git.openjdk.java.net/jdk/pull/5621 From mbaesken at openjdk.java.net Wed Sep 29 13:02:39 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Wed, 29 Sep 2021 13:02:39 GMT Subject: RFR: 8274506: TestPids.java and TestPidsLimit.java fail with podman run as root In-Reply-To: References: Message-ID: On Wed, 29 Sep 2021 12:51:00 GMT, Severin Gehwolf wrote: > Please review this test fix to work around a podman issue[1]. `podman` expects for the "unlimited" option of `--pids-limit` to be `0` whereas `docker` wants `-1`. See the JBS bug for details. Thoughts? > > Testing: hotspot/jdk container tests with docker and podman. Two pids tests used to fail and pass with the patch. > > [1] https://github.com/containers/podman/issues/11782 Hello Severin, the test fix looks good to me. Best regards, Matthias ------------- Marked as reviewed by mbaesken (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5750 From rreddy at openjdk.java.net Wed Sep 29 15:47:36 2021 From: rreddy at openjdk.java.net (Ravi Reddy) Date: Wed, 29 Sep 2021 15:47:36 GMT Subject: RFR: 8193682: Infinite loop in ZipOutputStream.close() In-Reply-To: References: Message-ID: <7nbxzHPGAq3RDt9jnot7Q4G7uLQjy4-21J0bLqGwRCU=.db1e2c51-f864-44ec-ab0b-0d2ed95e9d6d@github.com> On Fri, 17 Sep 2021 12:45:29 GMT, Alan Bateman wrote: >> Hi all, >> >> Please review this fix for Infinite loop in ZipOutputStream.close(). >> The main issue here is when ever there is an exception during close operations on GZip we are not setting the deflator to a finished state which is leading to an infinite loop when we try writing on the same GZip instance( since we use while(!def.finished()) inside the write operation). >> >> Thanks, >> Ravi > > src/java.base/share/classes/java/util/zip/DeflaterOutputStream.java line 249: > >> 247: out.close(); >> 248: closed = true; >> 249: throw ioe; > > Have you tried using try-finally instead? Hi Alan , Sorry for the delayed response , I was out of office for 3 weeks. I haven't tried with try-finally , I'm reworking on the fix as , if we directly use zip.finish() , we are facing the same issue. I will update here once the fix is ready.Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/5522 From sgehwolf at openjdk.java.net Wed Sep 29 16:59:38 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Wed, 29 Sep 2021 16:59:38 GMT Subject: RFR: 8274506: TestPids.java and TestPidsLimit.java fail with podman run as root In-Reply-To: References: Message-ID: On Wed, 29 Sep 2021 12:51:00 GMT, Severin Gehwolf wrote: > Please review this test fix to work around a podman issue[1]. `podman` expects for the "unlimited" option of `--pids-limit` to be `0` whereas `docker` wants `-1`. See the JBS bug for details. Thoughts? > > Testing: hotspot/jdk container tests with docker and podman. Two pids tests used to fail and pass with the patch. > > [1] https://github.com/containers/podman/issues/11782 Thanks for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/5750 From shade at openjdk.java.net Wed Sep 29 17:58:44 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 29 Sep 2021 17:58:44 GMT Subject: RFR: 8274522: java/lang/management/ManagementFactory/MXBeanException.java test fails with Shenandoah Message-ID: Fails like this: $ CONF=linux-x86_64-server-fastdebug make run-test TEST=java/lang/management/ManagementFactory/MXBeanException.java TEST_VM_OPTS="-XX:+UseShenandoahGC" ... java.lang.NullPointerException: Cannot invoke "java.lang.management.MemoryPoolMXBean.setUsageThreshold(long)" because "MXBeanException.pool" is null This test tries to find the pool that is `!p.isUsageThresholdSupported()`, and for Shenandoah there is no such pool. Likewise with ZGC, which is already filtered. Additional testing: - [x] Affected test is now skipped for Shenandoah - [x] Affected test is still skipped for Z - [x] Affected test is still passing for G1 ------------- Commit messages: - Fix Changes: https://git.openjdk.java.net/jdk/pull/5757/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5757&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274522 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5757.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5757/head:pull/5757 PR: https://git.openjdk.java.net/jdk/pull/5757 From shade at openjdk.java.net Wed Sep 29 18:06:47 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 29 Sep 2021 18:06:47 GMT Subject: RFR: 8274523: java/lang/management/MemoryMXBean/MemoryTest.java test should handle Shenandoah Message-ID: Currently it fails with: $ CONF=linux-x86_64-server-fastdebug make run-test TEST=java/lang/management/MemoryMXBean/MemoryTest.java STDERR: java.lang.RuntimeException: TEST FAILED: Number of heap pools = 1 but expected <= 3 and >= 3 Z already handles it with a special configuration, Shenandoah should do the same. Additional testing: - [x] Affected test now works for Shenandoah - [x] Affected test still works for Z - [x] Affected test still works for G1 ------------- Commit messages: - Fix Changes: https://git.openjdk.java.net/jdk/pull/5758/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5758&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274523 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5758.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5758/head:pull/5758 PR: https://git.openjdk.java.net/jdk/pull/5758 From mchung at openjdk.java.net Wed Sep 29 18:25:35 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 29 Sep 2021 18:25:35 GMT Subject: RFR: 8274523: java/lang/management/MemoryMXBean/MemoryTest.java test should handle Shenandoah In-Reply-To: References: Message-ID: On Wed, 29 Sep 2021 17:56:00 GMT, Aleksey Shipilev wrote: > Currently it fails with: > > > $ CONF=linux-x86_64-server-fastdebug make run-test TEST=java/lang/management/MemoryMXBean/MemoryTest.java > > STDERR: > java.lang.RuntimeException: TEST FAILED: Number of heap pools = 1 but expected <= 3 and >= 3 > > > Z already handles it with a special configuration, Shenandoah should do the same. > > Additional testing: > - [x] Affected test now works for Shenandoah > - [x] Affected test still works for Z > - [x] Affected test still works for G1 Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5758 From cjplummer at openjdk.java.net Wed Sep 29 18:43:34 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 29 Sep 2021 18:43:34 GMT Subject: RFR: 8274506: TestPids.java and TestPidsLimit.java fail with podman run as root In-Reply-To: References: Message-ID: On Wed, 29 Sep 2021 12:51:00 GMT, Severin Gehwolf wrote: > Please review this test fix to work around a podman issue[1]. `podman` expects for the "unlimited" option of `--pids-limit` to be `0` whereas `docker` wants `-1`. See the JBS bug for details. Thoughts? > > Testing: hotspot/jdk container tests with docker and podman. Two pids tests used to fail and pass with the patch. > > [1] https://github.com/containers/podman/issues/11782 Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5750 From cjplummer at openjdk.java.net Wed Sep 29 18:54:33 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 29 Sep 2021 18:54:33 GMT Subject: RFR: 8274523: java/lang/management/MemoryMXBean/MemoryTest.java test should handle Shenandoah In-Reply-To: References: Message-ID: On Wed, 29 Sep 2021 17:56:00 GMT, Aleksey Shipilev wrote: > Currently it fails with: > > > $ CONF=linux-x86_64-server-fastdebug make run-test TEST=java/lang/management/MemoryMXBean/MemoryTest.java > > STDERR: > java.lang.RuntimeException: TEST FAILED: Number of heap pools = 1 but expected <= 3 and >= 3 > > > Z already handles it with a special configuration, Shenandoah should do the same. > > Additional testing: > - [x] Affected test now works for Shenandoah > - [x] Affected test still works for Z > - [x] Affected test still works for G1 Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5758 From amenkov at openjdk.java.net Wed Sep 29 19:02:35 2021 From: amenkov at openjdk.java.net (Alex Menkov) Date: Wed, 29 Sep 2021 19:02:35 GMT Subject: RFR: 8274464: Remove redundant stream() call before forEach in java.* modules In-Reply-To: References: Message-ID: On Wed, 15 Sep 2021 07:12:25 GMT, Andrey Turbanov wrote: > 8274464: Remove redundant stream() call before forEach in java.* modules Marked as reviewed by amenkov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5520 From serb at openjdk.java.net Wed Sep 29 20:09:36 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Wed, 29 Sep 2021 20:09:36 GMT Subject: RFR: 8273101: Eliminate the usage of threadgroup sandboxing in the java.util.logging In-Reply-To: References: Message-ID: <0CGQo0Xsjz8WEKH4AonQJMAhYK3Bhc4wqrIQCSawfJk=.f414c9ed-bf36-4eae-bc37-372ccc8bcee1@github.com> On Wed, 1 Sep 2021 06:31:16 GMT, Sergey Bylokhov wrote: > At the time Java supported applets and webstart, a special mechanism for launching various applications in one JVM was used to reduce memory usage and each application was isolated from each other. > > This isolation was implemented via ThreadGroups where each application created its own thread group and all data for the application was stored in the context of its own group. > > Some parts of the JDK used ThreadGroups directly, others used special classes like sun.awt.AppContext. > > Such sandboxing became useless since the plugin and webstart are no longer supported and were removed in jdk11. > > Note that this is just a first step for the overall cleanup, here is my plan: > 1. Cleanup the usage of AppContext in the ?java.util.logging.LogManager" class in the java.base module. > 2. Cleanup the usage of TheadGroup in the JavaSound > 3. Cleanup the usage of TheadGroup in the JavaBeans > 4. Cleanup the usage of AppContext in the Swing > 5. Cleanup the usage of AppContext in the AWT > 6. Delete the AppContext class. > > The current PR is for the first step. So this is the request to delete the usage of AppContext in the LogManager and related tests. > > Tested by tier1/tier2/tier3 and jdk_desktop tests. Does anybody have any other suggestions? ------------- PR: https://git.openjdk.java.net/jdk/pull/5326 From github.com+741251+turbanoff at openjdk.java.net Wed Sep 29 19:51:01 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Wed, 29 Sep 2021 19:51:01 GMT Subject: RFR: 8274525: Replace uses of StringBuffer with StringBuilder in java.xml Message-ID: StringBuffer is a legacy synchronized class. There are more modern alternatives which perform better: 1. Plain String concatenation should be preferred 2. StringBuilder is a direct replacement to StringBuffer which generally have better performance ------------- Commit messages: - [PATCH] Cleanup usages of StringBuffer in java.xml Changes: https://git.openjdk.java.net/jdk/pull/5759/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5759&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274525 Stats: 32 lines in 5 files changed: 0 ins; 11 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/5759.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5759/head:pull/5759 PR: https://git.openjdk.java.net/jdk/pull/5759 From github.com+741251+turbanoff at openjdk.java.net Wed Sep 29 23:11:44 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Wed, 29 Sep 2021 23:11:44 GMT Subject: Integrated: 8273435: Remove redundant zero-length check in ClassDesc.of In-Reply-To: References: Message-ID: On Wed, 18 Aug 2021 07:28:57 GMT, Andrey Turbanov wrote: > After [JDK-8215510](https://bugs.openjdk.java.net/browse/JDK-8215510) (eed3a536c0) this condition is always `false`. Empty package name is handled separately. > Found by IntelliJ inspection. This pull request has now been integrated. Changeset: 355356c4 Author: Andrey Turbanov Committer: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/355356c405adb9287b786b0b045c2eb974d2ffca Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8273435: Remove redundant zero-length check in ClassDesc.of Reviewed-by: rriggs ------------- PR: https://git.openjdk.java.net/jdk/pull/5157 From vtewari at openjdk.java.net Thu Sep 30 05:01:33 2021 From: vtewari at openjdk.java.net (Vyom Tewari) Date: Thu, 30 Sep 2021 05:01:33 GMT Subject: RFR: 8274464: Remove redundant stream() call before forEach in java.* modules In-Reply-To: References: Message-ID: <4Dr78xXY2h3mNV3-y__VcjZ5QmnA03mx1EHJ7HT3gsE=.a2f96a23-7c12-4f52-94a2-e57f401a75d6@github.com> On Wed, 15 Sep 2021 07:12:25 GMT, Andrey Turbanov wrote: > 8274464: Remove redundant stream() call before forEach in java.* modules Looks good to me. ------------- Marked as reviewed by vtewari (Committer). PR: https://git.openjdk.java.net/jdk/pull/5520 From shade at openjdk.java.net Thu Sep 30 06:57:35 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 30 Sep 2021 06:57:35 GMT Subject: Integrated: 8274523: java/lang/management/MemoryMXBean/MemoryTest.java test should handle Shenandoah In-Reply-To: References: Message-ID: On Wed, 29 Sep 2021 17:56:00 GMT, Aleksey Shipilev wrote: > Currently it fails with: > > > $ CONF=linux-x86_64-server-fastdebug make run-test TEST=java/lang/management/MemoryMXBean/MemoryTest.java > > STDERR: > java.lang.RuntimeException: TEST FAILED: Number of heap pools = 1 but expected <= 3 and >= 3 > > > Z already handles it with a special configuration, Shenandoah should do the same. > > Additional testing: > - [x] Affected test now works for Shenandoah > - [x] Affected test still works for Z > - [x] Affected test still works for G1 This pull request has now been integrated. Changeset: f8415a9b Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/f8415a9b2f610ed431e6948c8174f6d982e5b31f Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8274523: java/lang/management/MemoryMXBean/MemoryTest.java test should handle Shenandoah Reviewed-by: mchung, cjplummer ------------- PR: https://git.openjdk.java.net/jdk/pull/5758 From shade at openjdk.java.net Thu Sep 30 06:57:34 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 30 Sep 2021 06:57:34 GMT Subject: RFR: 8274523: java/lang/management/MemoryMXBean/MemoryTest.java test should handle Shenandoah In-Reply-To: References: Message-ID: On Wed, 29 Sep 2021 17:56:00 GMT, Aleksey Shipilev wrote: > Currently it fails with: > > > $ CONF=linux-x86_64-server-fastdebug make run-test TEST=java/lang/management/MemoryMXBean/MemoryTest.java > > STDERR: > java.lang.RuntimeException: TEST FAILED: Number of heap pools = 1 but expected <= 3 and >= 3 > > > Z already handles it with a special configuration, Shenandoah should do the same. > > Additional testing: > - [x] Affected test now works for Shenandoah > - [x] Affected test still works for Z > - [x] Affected test still works for G1 Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/5758 From sgehwolf at openjdk.java.net Thu Sep 30 08:56:41 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Thu, 30 Sep 2021 08:56:41 GMT Subject: Integrated: 8274506: TestPids.java and TestPidsLimit.java fail with podman run as root In-Reply-To: References: Message-ID: On Wed, 29 Sep 2021 12:51:00 GMT, Severin Gehwolf wrote: > Please review this test fix to work around a podman issue[1]. `podman` expects for the "unlimited" option of `--pids-limit` to be `0` whereas `docker` wants `-1`. See the JBS bug for details. Thoughts? > > Testing: hotspot/jdk container tests with docker and podman. Two pids tests used to fail and pass with the patch. > > [1] https://github.com/containers/podman/issues/11782 This pull request has now been integrated. Changeset: 94e31e5c Author: Severin Gehwolf URL: https://git.openjdk.java.net/jdk/commit/94e31e5ca51d1c4c253cf7ac5acd950d10c22267 Stats: 12 lines in 2 files changed: 10 ins; 0 del; 2 mod 8274506: TestPids.java and TestPidsLimit.java fail with podman run as root Reviewed-by: mbaesken, cjplummer ------------- PR: https://git.openjdk.java.net/jdk/pull/5750 From itakiguchi at openjdk.java.net Thu Sep 30 09:46:45 2021 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Thu, 30 Sep 2021 09:46:45 GMT Subject: RFR: 8274544: Langtools command's usage were grabled on Japanese Windows Message-ID: JEP-400 (UTF-8 by Default) was eabled on JDK18-b13. After JDK18-b13, javac and some other langtool command's usage were garbled on Japanese Windows. These commands use PrintWriter instead of standard out/err with PrintStream. ------------- Commit messages: - Langtools command's usage were grabled on Japanese Windows Changes: https://git.openjdk.java.net/jdk/pull/5771/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5771&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274544 Stats: 35 lines in 2 files changed: 34 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5771.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5771/head:pull/5771 PR: https://git.openjdk.java.net/jdk/pull/5771 From itakiguchi at openjdk.java.net Thu Sep 30 10:13:32 2021 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Thu, 30 Sep 2021 10:13:32 GMT Subject: RFR: 8274544: Langtools command's usage were grabled on Japanese Windows In-Reply-To: References: Message-ID: On Thu, 30 Sep 2021 09:36:34 GMT, Ichiroh Takiguchi wrote: > JEP-400 (UTF-8 by Default) was eabled on JDK18-b13. > After JDK18-b13, javac and some other langtool command's usage were garbled on Japanese Windows. > These commands use PrintWriter instead of standard out/err with PrintStream. Screenshot ![javac-screenshot](https://user-images.githubusercontent.com/33543753/135429041-0ed22b36-0b1e-4626-92ca-8b58acf8872d.png) javac does not use PrintStream for standard out/err, it uses PrintWriter. I put some codes on src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java * Using native.encoding system property. But test/langtools/tools/javac/diags/CheckResourceKeys.java was failed. * Use java.io.Console, like Console cons = System.console() and cons.charset(), but "javac 2>&1 | more" does not work as expected because System.console() returns null. So I added -Dfile.encoding=COMPAT expect java and javaw commands on launcher. jshell does not work as expected on b12 >jdk-18-b12\bin\jshell.exe | JShell????? -- ?????18-ea | ??????????????????: /help intro jshell> "\u3042".getBytes() $1 ==> byte[2] { -126, -96 } on b13 >jdk-18-b13\bin\jshell.exe | JShell????? -- ?????18-ea | ??????????????????: /help intro jshell> "\u3042".getBytes() $1 ==> byte[3] { -29, -127, -126 } It's UTF-8, not native encoding. I think backend java process should use same fine.encoding system property setting. I don't think it's good fix, so please give me some advices. ------------- PR: https://git.openjdk.java.net/jdk/pull/5771 From aph at openjdk.java.net Thu Sep 30 10:17:35 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 30 Sep 2021 10:17:35 GMT Subject: RFR: 8269559: AArch64: Implement string_compare intrinsic in SVE [v2] In-Reply-To: References: Message-ID: <5VvW1K-Ztaa2vyC-7p_xl2T1NUNc4Ay-0ez-RWPGVSM=.fa3e94cf-d761-412b-a2be-185256dee393@github.com> On Mon, 23 Aug 2021 21:48:01 GMT, TatWai Chong wrote: >> This patch implements string_compare intrinsic in SVE. >> It supports all LL, LU, UL and UU comparisons. >> >> As we haven't found an existing benchmark to measure performance impact, >> we created a benchmark derived from the test [1] for this evaluation. >> This benchmark is attached to this patch. >> >> Besides, remove the unused temporary register `vtmp3` from the existing >> match rules for StrCmp. >> >> The result below shows all varients can be benefited largely. >> Command: make exploded-test TEST="micro:StringCompareToDifferentLength" >> >> Benchmark (size) Mode Cnt Score Speedup Units >> compareToLL 24 avgt 10 1.0x ms/op >> compareToLL 36 avgt 10 1.0x ms/op >> compareToLL 72 avgt 10 1.0x ms/op >> compareToLL 128 avgt 10 1.4x ms/op >> compareToLL 256 avgt 10 1.8x ms/op >> compareToLL 512 avgt 10 2.7x ms/op >> compareToLU 24 avgt 10 1.6x ms/op >> compareToLU 36 avgt 10 1.8x ms/op >> compareToLU 72 avgt 10 2.3x ms/op >> compareToLU 128 avgt 10 3.8x ms/op >> compareToLU 256 avgt 10 4.7x ms/op >> compareToLU 512 avgt 10 6.3x ms/op >> compareToUL 24 avgt 10 1.6x ms/op >> compareToUL 36 avgt 10 1.7x ms/op >> compareToUL 72 avgt 10 2.2x ms/op >> compareToUL 128 avgt 10 3.3x ms/op >> compareToUL 256 avgt 10 4.4x ms/op >> compareToUL 512 avgt 10 6.1x ms/op >> compareToUU 24 avgt 10 1.0x ms/op >> compareToUU 36 avgt 10 1.0x ms/op >> compareToUU 72 avgt 10 1.4x ms/op >> compareToUU 128 avgt 10 2.2x ms/op >> compareToUU 256 avgt 10 2.6x ms/op >> compareToUU 512 avgt 10 3.7x ms/op >> >> [1] https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/compiler/intrinsics/string/TestStringCompareToDifferentLength.java > > TatWai Chong has updated the pull request incrementally with one additional commit since the last revision: > > Restore the removal of vtmp3 (=V2) as it is still used by the non-SVE compare-long-strings stub. > > And remove the assertion in `string_compare` since it won't help as the registers > used in the stub are fixed. Marked as reviewed by aph (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5129 From myano at openjdk.java.net Thu Sep 30 11:29:39 2021 From: myano at openjdk.java.net (Masanori Yano) Date: Thu, 30 Sep 2021 11:29:39 GMT Subject: RFR: 8250678: ModuleDescriptor.Version parsing treats empty segments inconsistently In-Reply-To: <5FwhmsS85upnfXAKPCBCQTsWorJN17vOBFZXCN6iP8M=.377740a1-6f1e-4e37-9344-25a60ffdd891@github.com> References: <5FwhmsS85upnfXAKPCBCQTsWorJN17vOBFZXCN6iP8M=.377740a1-6f1e-4e37-9344-25a60ffdd891@github.com> Message-ID: On Fri, 24 Sep 2021 11:28:09 GMT, Masanori Yano wrote: > Could you please review the 8250678 bug fixes? > > 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/jdk18/docs/api/java.base/java/lang/module/ModuleDescriptor.Version.html > > Therefore, I propose to fix the parsing method of pre and build section in the same way as the version. @mbreinhold Could you comment on this pull request? ------------- PR: https://git.openjdk.java.net/jdk/pull/5679 From akasko at openjdk.java.net Thu Sep 30 18:40:56 2021 From: akasko at openjdk.java.net (Alex Kasko) Date: Thu, 30 Sep 2021 18:40:56 GMT Subject: RFR: 8274606: Fix jaxp/javax/xml/jaxp/unittest/transform/SurrogateTest.java test Message-ID: I was working on backporting JDK-8268457 and found minor problems with the test introduced there: 1. `compareWith*` helper methods are used without `Assert.assertTrue()` wrapping, so they are effectively ignored 2. `this.getClass().getResourceAsStream()` is used to load test input data, it actually returns null in test run, so transformation is done without input data Note, that SurrogateTest.zip reproducer attached to JDK-8268457 is valid and fully functional, problems likely were introduced when it was adapted into test. The change is to the test only, it wraps `compareWith*` helpers and loads data the same way as XSL is loaded. Additionally `compareStringWithGold` was changed to `compareLinesWithGold` to exclude possible line endings problems. Testing: checked that the test fails when JDK-8268457 code fix is reverted, checked that is passes on master. ------------- Commit messages: - 8274606: Fix jaxp/javax/xml/jaxp/unittest/transform/SurrogateTest.java test Changes: https://git.openjdk.java.net/jdk/pull/5779/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5779&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274606 Stats: 10 lines in 1 file changed: 3 ins; 1 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/5779.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5779/head:pull/5779 PR: https://git.openjdk.java.net/jdk/pull/5779 From lancea at openjdk.java.net Thu Sep 30 19:03:34 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 30 Sep 2021 19:03:34 GMT Subject: RFR: 4890732: GZIPOutputStream doesn't support optional GZIP fields [v12] In-Reply-To: References: Message-ID: On Tue, 28 Sep 2021 03:10:33 GMT, Lin Zang wrote: > Dear All? This PR has been pending there for quite a long time. I am wondering maybe this PR is not so interesting? I would like to leave this PR open for a while more, and if no new update, I would let it close automatically by timeout. Thanks! > > Lin Hi Lin, Thank you for your continued work on this. I think we need to flush out the API more. Alan made a great point in his [comment regarding the mutability of GZIPHeaderData](https://github.com/openjdk/jdk/pull/3072#issuecomment-887629007 ): due to the inclusion of an array element within a record definition. This still needs to be addressed. We should also decide the best location for the header flag constants. I will try to spend a bit more time on this next week. ------------- PR: https://git.openjdk.java.net/jdk/pull/3072 From joehw at openjdk.java.net Thu Sep 30 19:54:41 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Thu, 30 Sep 2021 19:54:41 GMT Subject: RFR: 8274525: Replace uses of StringBuffer with StringBuilder in java.xml In-Reply-To: References: Message-ID: <4ADPtTekFprw8Pl-_UQDt0WxsMbwkxn9bbOv8dp-1KA=.1bd56ad7-8d89-4c96-abf9-d631ed3ee787@github.com> On Wed, 29 Sep 2021 17:56:49 GMT, Andrey Turbanov wrote: > StringBuffer is a legacy synchronized class. There are more modern alternatives which perform better: > 1. Plain String concatenation should be preferred > 2. StringBuilder is a direct replacement to StringBuffer which generally have better performance > > Similar cleanups: > 1. [JDK-8264029](https://bugs.openjdk.java.net/browse/JDK-8264029) java.base > 2. [JDK-8264428](https://bugs.openjdk.java.net/browse/JDK-8264428) java.desktop > 3. [JDK-8264484](https://bugs.openjdk.java.net/browse/JDK-8264484) jdk.hotspot.agent Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5759 From joehw at openjdk.java.net Thu Sep 30 20:55:35 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Thu, 30 Sep 2021 20:55:35 GMT Subject: RFR: 8274606: Fix jaxp/javax/xml/jaxp/unittest/transform/SurrogateTest.java test In-Reply-To: References: Message-ID: On Thu, 30 Sep 2021 18:32:17 GMT, Alex Kasko wrote: > I was working on backporting JDK-8268457 and found minor problems with the test introduced there: > > 1. `compareWith*` helper methods are used without `Assert.assertTrue()` wrapping, so they are effectively ignored > > 2. `this.getClass().getResourceAsStream()` is used to load test input data, it actually returns null in test run, so transformation is done without input data > > Note, that SurrogateTest.zip reproducer attached to JDK-8268457 is valid and fully functional, problems likely were introduced when it was adapted into test. > > The change is to the test only, it wraps `compareWith*` helpers and loads data the same way as XSL is loaded. Additionally `compareStringWithGold` was changed to `compareLinesWithGold` to exclude possible line endings problems. > > Testing: checked that the test fails when JDK-8268457 code fix is reverted, checked that is passes on master. Marked as reviewed by joehw (Reviewer). Good catch! Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/5779 From naoto at openjdk.java.net Thu Sep 30 21:48:27 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 30 Sep 2021 21:48:27 GMT Subject: RFR: 8274544: Langtools command's usage were grabled on Japanese Windows In-Reply-To: References: Message-ID: On Thu, 30 Sep 2021 10:10:31 GMT, Ichiroh Takiguchi wrote: > * Using native.encoding system property. But test/langtools/tools/javac/diags/CheckResourceKeys.java was failed. What was the cause of the failure? > * Use java.io.Console, like Console cons = System.console() and cons.charset(), but "javac 2>&1 | more" does not work as expected because System.console() returns null. > > So I added -Dfile.encoding=COMPAT expect java and javaw commands on launcher. I think we should fix the root cause of this, instead of specifying `file.encoding=COMPAT` > > jshell does not work as expected on b12 Do you mean `b13`? > > ``` > >jdk-18-b12\bin\jshell.exe > | JShell????? -- ?????18-ea > | ??????????????????: /help intro > > jshell> "\u3042".getBytes() > $1 ==> byte[2] { -126, -96 } > ``` > > on b13 > > ``` > >jdk-18-b13\bin\jshell.exe > | JShell????? -- ?????18-ea > | ??????????????????: /help intro > > jshell> "\u3042".getBytes() > $1 ==> byte[3] { -29, -127, -126 } > ``` > > It's UTF-8, not native encoding. I think backend java process should use same fine.encoding system property setting. No it should not. `file.encoding` should not be inherited. Naoto ------------- PR: https://git.openjdk.java.net/jdk/pull/5771 From iris at openjdk.java.net Thu Sep 30 22:11:40 2021 From: iris at openjdk.java.net (Iris Clark) Date: Thu, 30 Sep 2021 22:11:40 GMT Subject: RFR: 8274525: Replace uses of StringBuffer with StringBuilder in java.xml In-Reply-To: References: Message-ID: On Wed, 29 Sep 2021 17:56:49 GMT, Andrey Turbanov wrote: > StringBuffer is a legacy synchronized class. There are more modern alternatives which perform better: > 1. Plain String concatenation should be preferred > 2. StringBuilder is a direct replacement to StringBuffer which generally have better performance > > Similar cleanups: > 1. [JDK-8264029](https://bugs.openjdk.java.net/browse/JDK-8264029) java.base > 2. [JDK-8264428](https://bugs.openjdk.java.net/browse/JDK-8264428) java.desktop > 3. [JDK-8264484](https://bugs.openjdk.java.net/browse/JDK-8264484) jdk.hotspot.agent Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5759 From naoto at openjdk.java.net Thu Sep 30 23:02:33 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 30 Sep 2021 23:02:33 GMT Subject: RFR: 8274525: Replace uses of StringBuffer with StringBuilder in java.xml In-Reply-To: References: Message-ID: On Wed, 29 Sep 2021 17:56:49 GMT, Andrey Turbanov wrote: > StringBuffer is a legacy synchronized class. There are more modern alternatives which perform better: > 1. Plain String concatenation should be preferred > 2. StringBuilder is a direct replacement to StringBuffer which generally have better performance > > Similar cleanups: > 1. [JDK-8264029](https://bugs.openjdk.java.net/browse/JDK-8264029) java.base > 2. [JDK-8264428](https://bugs.openjdk.java.net/browse/JDK-8264428) java.desktop > 3. [JDK-8264484](https://bugs.openjdk.java.net/browse/JDK-8264484) jdk.hotspot.agent Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5759