From smarks at openjdk.org Wed Mar 1 00:24:09 2023 From: smarks at openjdk.org (Stuart Marks) Date: Wed, 1 Mar 2023 00:24:09 GMT Subject: RFR: 8298939: Refactor open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.sh to jtreg java test [v5] In-Reply-To: <-i8qOy1y9YRztD9fUlf9uDn1hxk-Een_bssvoJOGm6M=.0d8b70c5-8a72-4eaa-b2b5-095d687a7760@github.com> References: <-i8qOy1y9YRztD9fUlf9uDn1hxk-Een_bssvoJOGm6M=.0d8b70c5-8a72-4eaa-b2b5-095d687a7760@github.com> Message-ID: On Mon, 27 Feb 2023 14:04:42 GMT, Matthew Donovan wrote: >> Removed SSLSocketParametersTest.sh script (which just called a Java file) and configured the java code to run directly with jtreg > > Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision: > > cleaned up exception handling Marked as reviewed by smarks (Reviewer). OK, I think this is pretty good as it stands. It achieves the original goal of converting the shell script test to a regular Java jtreg test; the shell script is removed entirely, and the Java code is cleaned up and is 20% shorter. Hooray! So I think this can go in as it stands. Optionally, if you're game to continue working on this, there are some additional cleanups that can be done. This is now digging into the Java code that was already in the test before you got involved. Specifically: 1) The `HelloImpl` and `HelloClient` classes aren't adding much value and can pretty much be deleted if the object is exported with something like: Hello stub = (Hello) UnicastRemoteObject.exportObject(new HelloImpl(), port, csf, ssf); or similar. 2) The `ClientFactory` and `ServerFactory` classes aren't adding much value. They override the create methods and print a message, but otherwise don't do anything beyond what's done in their respective superclasses. 3) The exception handling is now fairly simple, but one still needs to read through the code to figure out what is actually being tested. The `expectedException` boolean also makes things a little harder to read since it can invert the logic. I observe that the various test frameworks (such as Test-NG or JUnit) have APIs for this such as `assertThrows` or `expectThrows` which return the caught exception, allowing additional assertions to be made over it, and failing the test if the expected exception type isn't thrown. I think this would improve the test cases where an exception is expected, but it might not be worth the effort of converting to one of the frameworks. It's up to you (and your project lead) as to how to proceed. You could continue here, or in another PR, or just consider this done and move onto the next thing. ------------- PR: https://git.openjdk.org/jdk/pull/11910 From jlu at openjdk.org Wed Mar 1 00:30:55 2023 From: jlu at openjdk.org (Justin Lu) Date: Wed, 1 Mar 2023 00:30:55 GMT Subject: RFR: 8303405: fix @returnss typo in ReflectionFactory Message-ID: <-0G_v0gBCIwZzCJrCns71VpiwaLRpNvbpmRYVUm_k4U=.3f2f80b3-5c8d-4134-9c0a-79a94ce8678e@github.com> The following typo: `@returnss` was reported on line _482 of Reflection Factory.java_. In addition to fixing that, I have replaced multiple instances of `@returns` with `@return` in the same file. ------------- Commit messages: - @return tag fix for methods Changes: https://git.openjdk.org/jdk/pull/12794/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12794&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303405 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/12794.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12794/head:pull/12794 PR: https://git.openjdk.org/jdk/pull/12794 From bpb at openjdk.org Wed Mar 1 00:32:05 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 1 Mar 2023 00:32:05 GMT Subject: RFR: 8303175: (fs) Deprecate com.sun.nio.file.SensitivityWatchEventModifier for removal [v2] In-Reply-To: <_d6lgOAEF0u6NsSe2BmzHVwvqVAiivndlFN8c5Z5pYI=.5bcbc290-ceab-431a-b54b-756789770014@github.com> References: <_d6lgOAEF0u6NsSe2BmzHVwvqVAiivndlFN8c5Z5pYI=.5bcbc290-ceab-431a-b54b-756789770014@github.com> Message-ID: On Tue, 28 Feb 2023 17:10:51 GMT, Brian Burkhalter wrote: >> src/jdk.unsupported/share/classes/com/sun/nio/file/SensitivityWatchEventModifier.java line 40: >> >>> 38: * {@code WatchService} is used only on macOS and likely to be removed >>> 39: * in a future release when a version based on the native file event >>> 40: * notification facility becomes available. >> >> I agree it's time to deprecate this extension but I think the reasoning will need a few rounds to get right. As background, JDK-8285956 changed the default sensitivity from medium to high in JDK 19 so the need to bump the sensitivity level (and thus reducing the polling interval) has mostly gone away. So maybe we should thinking about changing PollingWatchService it to ignore the these modifiers (like it is done with the native implementations). If we did that then it would be easy to word the deprecation text as it could just say that the modifier originally provided a hint to polling based WatchService implementations but is no longer used. > > Should the suggested change to PollingWatchService be addressed in the context of this PR or separately? JDK-8303413 was created to track this change (#12795). ------------- PR: https://git.openjdk.org/jdk/pull/12746 From jlu at openjdk.org Wed Mar 1 00:39:22 2023 From: jlu at openjdk.org (Justin Lu) Date: Wed, 1 Mar 2023 00:39:22 GMT Subject: Integrated: 8282319: java.util.Locale method to stream available Locales In-Reply-To: References: Message-ID: On Fri, 27 Jan 2023 21:48:26 GMT, Justin Lu wrote: > This PR adds a new method to java.util.Locale which returns Stream > > The contents of the Stream are composed of the same underlying elements as Locale.getAvailableLocales(). > > This method allows streaming of the Locale array without creating a defensive copy. This pull request has now been integrated. Changeset: 7e47d51e Author: Justin Lu Committer: Naoto Sato URL: https://git.openjdk.org/jdk/commit/7e47d51e10eef7b3bead636d20ff392e7b1dd185 Stats: 116 lines in 3 files changed: 113 ins; 1 del; 2 mod 8282319: java.util.Locale method to stream available Locales Reviewed-by: stsypanov, naoto, lancea, rriggs ------------- PR: https://git.openjdk.org/jdk/pull/12269 From smarks at openjdk.org Wed Mar 1 00:52:07 2023 From: smarks at openjdk.org (Stuart Marks) Date: Wed, 1 Mar 2023 00:52:07 GMT Subject: RFR: 8303266: Prefer ArrayList to LinkedList in JImageTask In-Reply-To: References: Message-ID: On Mon, 27 Feb 2023 11:33:38 GMT, Andrey Turbanov wrote: > `LinkedList` is used as a field `jdk.tools.jimage.JImageTask.OptionsValues#jimages` > It's created, filled (with `add`) and then iterated. No removes from the head or something like this. `ArrayList` should be preferred as more efficient and widely used (more chances for JIT) collection. I guess I should weigh in because I'm mentioned here by tweet. The main point of "stop using LinkedList" (from the tweet) is in new code. If you're writing new code and get bogged down thinking, "Hm, should I use a LinkedList or ArrayList here?" then you should probably just use ArrayList and move on. There are few use cases where LinkedList is preferable to ArrayList, and most people won't ever see them. That doesn't justify replacing existing usages of ArrayList with LinkedList. The proximate question to ask here is, "Does this change improve the JDK?" I don't see any such justification here. Functionally the replacement is intended to be the same, so this doesn't fix any actual bug. The performance is supposedly better, but it's unclear whether this **actually** matters in this case. However, there are risks and costs associated with such changes, including the possibility of unforeseen behavioral changes that result in test failures, and the cost of reviewer time. The only benefit mentioned is that people look at the JDK and see LinkedList being used so they think it's OK to use LinkedList in their own code. This is quite tenuous. If you want people to stop using LinkedList, it will be much more effective to get to say "use ArrayList instead of LinkedList" instead of trying to remove uses of it from the JDK. ------------- PR: https://git.openjdk.org/jdk/pull/12760 From lmesnik at openjdk.org Wed Mar 1 00:54:15 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 1 Mar 2023 00:54:15 GMT Subject: Integrated: 8303133: Update ProcessTools.startProcess(...) to exit early if process exit before linePredicate is printed. In-Reply-To: References: Message-ID: On Fri, 24 Feb 2023 22:15:18 GMT, Leonid Mesnik wrote: > The solution proposed by Stefan K > > The startProcess() might wait forever for the expected line if the process exits (failed to start). It makes sense to just fail earlier in such cases. > > The fix also move > 'output = new OutputAnalyzer(this.process);' > in method xrun() to be able to try to print them in waitFor is failed/interrupted. This pull request has now been integrated. Changeset: 1fdaf252 Author: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/1fdaf252b6375773072e665fd5d4cfb509e98f4c Stats: 29 lines in 2 files changed: 16 ins; 3 del; 10 mod 8303133: Update ProcessTools.startProcess(...) to exit early if process exit before linePredicate is printed. Reviewed-by: dholmes, rriggs ------------- PR: https://git.openjdk.org/jdk/pull/12751 From jpai at openjdk.org Wed Mar 1 00:55:02 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 1 Mar 2023 00:55:02 GMT Subject: RFR: 8303405: fix @returnss typo in ReflectionFactory In-Reply-To: <-0G_v0gBCIwZzCJrCns71VpiwaLRpNvbpmRYVUm_k4U=.3f2f80b3-5c8d-4134-9c0a-79a94ce8678e@github.com> References: <-0G_v0gBCIwZzCJrCns71VpiwaLRpNvbpmRYVUm_k4U=.3f2f80b3-5c8d-4134-9c0a-79a94ce8678e@github.com> Message-ID: On Wed, 1 Mar 2023 00:24:31 GMT, Justin Lu wrote: > The following typo: `@returnss` was reported on line _482 of Reflection Factory.java_. > > In addition to fixing that, I have replaced multiple instances of `@returns` with `@return` in the same file. Marked as reviewed by jpai (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12794 From mchung at openjdk.org Wed Mar 1 00:55:03 2023 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 1 Mar 2023 00:55:03 GMT Subject: RFR: 8303405: fix @returnss typo in ReflectionFactory In-Reply-To: <-0G_v0gBCIwZzCJrCns71VpiwaLRpNvbpmRYVUm_k4U=.3f2f80b3-5c8d-4134-9c0a-79a94ce8678e@github.com> References: <-0G_v0gBCIwZzCJrCns71VpiwaLRpNvbpmRYVUm_k4U=.3f2f80b3-5c8d-4134-9c0a-79a94ce8678e@github.com> Message-ID: On Wed, 1 Mar 2023 00:24:31 GMT, Justin Lu wrote: > The following typo: `@returnss` was reported on line _482 of Reflection Factory.java_. > > In addition to fixing that, I have replaced multiple instances of `@returns` with `@return` in the same file. The change is okay. This is an internal class and no javadoc is generated for it. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.org/jdk/pull/12794 From martin at openjdk.org Wed Mar 1 01:09:03 2023 From: martin at openjdk.org (Martin Buchholz) Date: Wed, 1 Mar 2023 01:09:03 GMT Subject: RFR: 8303405: fix @returnss typo in ReflectionFactory In-Reply-To: <-0G_v0gBCIwZzCJrCns71VpiwaLRpNvbpmRYVUm_k4U=.3f2f80b3-5c8d-4134-9c0a-79a94ce8678e@github.com> References: <-0G_v0gBCIwZzCJrCns71VpiwaLRpNvbpmRYVUm_k4U=.3f2f80b3-5c8d-4134-9c0a-79a94ce8678e@github.com> Message-ID: <9xgAHXez7hXVH8LIBAbiAZ-XzfCQ-dWAhpAIFmi84Eo=.da18301c-8083-4a85-8acc-38126f4d77da@github.com> On Wed, 1 Mar 2023 00:24:31 GMT, Justin Lu wrote: > The following typo: `@returnss` was reported on line _482 of Reflection Factory.java_. > > In addition to fixing that, I have replaced multiple instances of `@returns` with `@return` in the same file. Marked as reviewed by martin (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12794 From rriggs at openjdk.org Wed Mar 1 01:35:03 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 1 Mar 2023 01:35:03 GMT Subject: RFR: 8303266: Prefer ArrayList to LinkedList in JImageTask In-Reply-To: References: Message-ID: On Mon, 27 Feb 2023 11:33:38 GMT, Andrey Turbanov wrote: > `LinkedList` is used as a field `jdk.tools.jimage.JImageTask.OptionsValues#jimages` > It's created, filled (with `add`) and then iterated. No removes from the head or something like this. `ArrayList` should be preferred as more efficient and widely used (more chances for JIT) collection. I should have expounded on the rationale for making only changes that are worth the time of the author and the reviewers. Stuart filled more of the reasons I was thinking in my terse comment. For this PR, go ahead and integrate, since we've already spent the budget for reviewing it. In choosing how you spend your time, make your efforts and the efforts of the reviewers count for something. ------------- PR: https://git.openjdk.org/jdk/pull/12760 From iris at openjdk.org Wed Mar 1 02:17:02 2023 From: iris at openjdk.org (Iris Clark) Date: Wed, 1 Mar 2023 02:17:02 GMT Subject: RFR: 8303405: fix @returnss typo in ReflectionFactory In-Reply-To: <-0G_v0gBCIwZzCJrCns71VpiwaLRpNvbpmRYVUm_k4U=.3f2f80b3-5c8d-4134-9c0a-79a94ce8678e@github.com> References: <-0G_v0gBCIwZzCJrCns71VpiwaLRpNvbpmRYVUm_k4U=.3f2f80b3-5c8d-4134-9c0a-79a94ce8678e@github.com> Message-ID: On Wed, 1 Mar 2023 00:24:31 GMT, Justin Lu wrote: > The following typo: `@returnss` was reported on line _482 of Reflection Factory.java_. > > In addition to fixing that, I have replaced multiple instances of `@returns` with `@return` in the same file. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12794 From xgong at openjdk.org Wed Mar 1 02:36:07 2023 From: xgong at openjdk.org (Xiaohong Gong) Date: Wed, 1 Mar 2023 02:36:07 GMT Subject: RFR: 8303401: Add a Vector API equalsIgnoreCase micro benchmark [v3] In-Reply-To: References: Message-ID: On Tue, 28 Feb 2023 23:08:29 GMT, Eirik Bjorsnos wrote: >> This PR suggests we add a vectorized equalsIgnoreCase benchmark to the set of benchmarks in `org.openjdk.bench.jdk.incubator.vector`. This benchmark serves as an example of how vectorization can be useful also in the area of text processing. It takes advantage of the fact that ASCII and Latin-1 were designed to optimize case-twiddling operations. >> >> The code came about during the work on #12632, where vectorization was deemed out of scope. >> >> Benchmark results: >> >> >> Benchmark (size) Mode Cnt Score Error Units >> EqualsIgnoreCaseBenchmark.scalar 16 avgt 15 20.671 ? 0.718 ns/op >> EqualsIgnoreCaseBenchmark.scalar 32 avgt 15 46.155 ? 3.258 ns/op >> EqualsIgnoreCaseBenchmark.scalar 64 avgt 15 68.248 ? 1.767 ns/op >> EqualsIgnoreCaseBenchmark.scalar 128 avgt 15 148.948 ? 0.890 ns/op >> EqualsIgnoreCaseBenchmark.scalar 1024 avgt 15 1090.708 ? 7.540 ns/op >> EqualsIgnoreCaseBenchmark.vectorized 16 avgt 15 21.872 ? 0.232 ns/op >> EqualsIgnoreCaseBenchmark.vectorized 32 avgt 15 11.378 ? 0.097 ns/op >> EqualsIgnoreCaseBenchmark.vectorized 64 avgt 15 13.703 ? 0.135 ns/op >> EqualsIgnoreCaseBenchmark.vectorized 128 avgt 15 21.632 ? 0.735 ns/op >> EqualsIgnoreCaseBenchmark.vectorized 1024 avgt 15 105.509 ? 7.493 ns/op > > Eirik Bjorsnos has updated the pull request incrementally with two additional commits since the last revision: > > - Uppercase Thorn is 0xDE > - Update 'a' to 'A' and 'z' to 'Z' in comments test/micro/org/openjdk/bench/jdk/incubator/vector/EqualsIgnoreCaseBenchmark.java line 61: > 59: len = a.length; > 60: } > 61: @Benchmark Style: Insert one blank line between line 60-61? test/micro/org/openjdk/bench/jdk/incubator/vector/EqualsIgnoreCaseBenchmark.java line 124: > 122: } > 123: > 124: public boolean scalarEqualsIgnoreCase(byte[] a, byte[] b, int len) { Style: remove one more space between "`public boolean`" please? test/micro/org/openjdk/bench/jdk/incubator/vector/EqualsIgnoreCaseBenchmark.java line 147: > 145: return false; // Low ASCII > 146: } > 147: return ( U <= 'Z' // In range A-Z Style: remove one more space between `( U` please? ------------- PR: https://git.openjdk.org/jdk/pull/12790 From smarks at openjdk.org Wed Mar 1 03:07:02 2023 From: smarks at openjdk.org (Stuart Marks) Date: Wed, 1 Mar 2023 03:07:02 GMT Subject: RFR: 8303266: Prefer ArrayList to LinkedList in JImageTask In-Reply-To: References: Message-ID: <4Ep3JC25Qiy9p8GFl3nhjb4qVwv53XYnW_QfBZ1ESjE=.ec15a64e-d0f0-4602-84af-b5f920f4d4a0@github.com> On Wed, 1 Mar 2023 01:32:39 GMT, Roger Riggs wrote: > For this PR, go ahead and integrate, since we've already spent the budget for reviewing it. I'm ok with this, as Roger said, since we've all already looked at it. I'm not really interested in seeing 234 followup changes removing LinkedList from all over the JDK though. ------------- PR: https://git.openjdk.org/jdk/pull/12760 From stuart.marks at oracle.com Wed Mar 1 03:41:01 2023 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 28 Feb 2023 19:41:01 -0800 Subject: 8281301: Map.of() calls with null argument should throw more contextual information. In-Reply-To: References: Message-ID: <5ba8b22b-4a09-1ee0-6fb2-51b25c186c9e@oracle.com> Sorry, it appears that you have fallen into a thicket of issues. [*] I'm usually fairly skeptical of these kinds of changes, as they often have more overhead than is apparent. Java requires all arguments to be /evaluated/ before the method is invoked. Evaluating a lambda includes loading and running the lambda metafactory, spinning bytecodes, and loading another class into the JVM. This is done even if the lambda is never /invoked/. The unmodifiable collections are used a lot at startup time, so this means this extra work will be done on critical code paths even before main() is called. Also, most of this is run in interpretive mode, so we can't rely on the benefit of JIT compilation. But there are other reasons to avoid using lambdas in critical startup code like this. Just for grins I applied your patch at ran it, and the result was this: $ java -version Error occurred during initialization of VM java.lang.ExceptionInInitializerError at java.lang.invoke.MethodHandleNatives.findMethodHandleType(java.base/MethodHandleNatives.java:411) at java.util.ImmutableCollections$MapN.(java.base/ImmutableCollections.java:1186) at java.util.Map.of(java.base/Map.java:1584) at jdk.internal.reflect.Reflection.(java.base/Reflection.java:55) at java.security.AccessController.doPrivileged(java.base/AccessController.java:319) at java.lang.reflect.AccessibleObject.(java.base/AccessibleObject.java:524) Caused by: java.lang.NullPointerException at java.lang.invoke.MethodType$ConcurrentWeakInternSet.(java.base/MethodType.java:1406) at java.lang.invoke.MethodType.(java.base/MethodType.java:231) at java.lang.invoke.MethodHandleNatives.findMethodHandleType(java.base/MethodHandleNatives.java:411) at java.util.ImmutableCollections$MapN.(java.base/ImmutableCollections.java:1186) at java.util.Map.of(java.base/Map.java:1584) at jdk.internal.reflect.Reflection.(java.base/Reflection.java:55) at java.security.AccessController.doPrivileged(java.base/AccessController.java:319) at java.lang.reflect.AccessibleObject.(java.base/AccessibleObject.java:524) Essentially the JVM crashed even before it got to print out the version message. I don't know exactly what happened, but this kind of error often occurs if lambdas are used "too early" during initialization. The reason is that lambdas use a bunch of runtime infrastructure in java.lang.invoke that's written in Java. This Java code in turn uses a variety of collections. If collections code were to use lambdas that are evaluated at startup time, this would cause problems like initialization circularities, references to uninitialized data, or other inexplicable errors. That's what's happening here. We could try to work around this by using explicit classes instead of lambdas for the messageSupplier, but this would still mean more classes loaded and initialized and bytecodes executed at startup time, which I'm fairly uncomfortable with given the reasons above. s'marks [*] Fortunately, it seems unlikely that you will be eaten by a grue. :-) On 2/28/23 1:14 PM, Sage Vaillancourt wrote: > Hi there. It's my first time posting to the development list, so > please forgive any formatting errors. > > My proposed change is pretty small. Basically, a pattern I see with > some frequency is calling Objects.requireNonNull(object, "objectName") > before (or within) Map.of(), because otherwise there's not much of a > way to tell _which_ parameter caused the exception. Even just an index > and key/value hint would make tracking down these types of errors > easier without that bit of boilerplate. > > I'd expect that any performance impact to be negligible, already being > off the happy path, here. > > Diff as I'm imagining it, but very open to suggestions: > > diff --git a/src/java.base/share/classes/java/util/ImmutableCollections.java > b/src/java.base/share/classes/java/util/ImmutableCollections.java > index 3de7e1d5eae..814c1a9ec1b 100644 > --- a/src/java.base/share/classes/java/util/ImmutableCollections.java > +++ b/src/java.base/share/classes/java/util/ImmutableCollections.java > @@ -1103,8 +1103,8 @@ class ImmutableCollections { > private final V v0; > > Map1(K k0, V v0) { > - this.k0 = Objects.requireNonNull(k0); > - this.v0 = Objects.requireNonNull(v0); > + this.k0 = Objects.requireNonNull(k0, () -> "Key in map > entry was null"); > + this.v0 = Objects.requireNonNull(v0, () -> "Value in map > entry was null"); > } > > @Override > @@ -1183,9 +1183,9 @@ class ImmutableCollections { > > for (int i = 0; i < input.length; i += 2) { > @SuppressWarnings("unchecked") > - K k = Objects.requireNonNull((K)input[i]); > + K k = Objects.requireNonNull((K)input[i], () -> > "Key for map entry " + (i / 2) + " was null"); > @SuppressWarnings("unchecked") > - V v = Objects.requireNonNull((V)input[i+1]); > + V v = Objects.requireNonNull((V)input[i+1], () -> > "Value for map entry " + (i / 2) + " was null"); > int idx = probe(k); > if (idx >= 0) { > throw new IllegalArgumentException("duplicate key: " + k); > From dholmes at openjdk.org Wed Mar 1 04:23:12 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 1 Mar 2023 04:23:12 GMT Subject: RFR: 8303133: Update ProcessTools.startProcess(...) to exit early if process exit before linePredicate is printed. [v5] In-Reply-To: References: Message-ID: On Mon, 27 Feb 2023 23:11:27 GMT, Leonid Mesnik wrote: >> The solution proposed by Stefan K >> >> The startProcess() might wait forever for the expected line if the process exits (failed to start). It makes sense to just fail earlier in such cases. >> >> The fix also move >> 'output = new OutputAnalyzer(this.process);' >> in method xrun() to be able to try to print them in waitFor is failed/interrupted. > > Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision: > > - latch != updated > - message improved We are seeing large numbers of failures after this change was integrated, so it will likely need to be backed out. ------------- PR: https://git.openjdk.org/jdk/pull/12751 From mdoerr at openjdk.org Wed Mar 1 05:31:34 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 1 Mar 2023 05:31:34 GMT Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function & Memory API (Preview) [v4] In-Reply-To: References: Message-ID: > Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification". > > This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `` (2.2.4 Variable Argument Lists). > > Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only. > > There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. > > The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests. > > I had to make changes to shared code and code for other platforms: > 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons: > - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that. > - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64. > - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian! > 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: HFA: Add support for nested structures. See JDK-8300294. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12708/files - new: https://git.openjdk.org/jdk/pull/12708/files/a4d844f7..b461d80c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=02-03 Stats: 37 lines in 2 files changed: 24 ins; 0 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/12708.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12708/head:pull/12708 PR: https://git.openjdk.org/jdk/pull/12708 From duke at openjdk.org Wed Mar 1 05:39:06 2023 From: duke at openjdk.org (Glavo) Date: Wed, 1 Mar 2023 05:39:06 GMT Subject: RFR: 8299807: newStringNoRepl should avoid copying arrays for ASCII compatible charsets [v4] In-Reply-To: References: Message-ID: <9nLBuYhrY9dC1XHA_jj2SkGoRsX8T80_t53vH2jJlFc=.27e7a20c-27c1-4b58-85b5-2b219a23b005@github.com> On Sat, 28 Jan 2023 19:54:32 GMT, Glavo wrote: >> This is the javadoc of `JavaLangAccess::newStringNoRepl`: >> >> >> /** >> * Constructs a new {@code String} by decoding the specified subarray of >> * bytes using the specified {@linkplain java.nio.charset.Charset charset}. >> * >> * The caller of this method shall relinquish and transfer the ownership of >> * the byte array to the callee since the later will not make a copy. >> * >> * @param bytes the byte array source >> * @param cs the Charset >> * @return the newly created string >> * @throws CharacterCodingException for malformed or unmappable bytes >> */ >> >> >> It is recorded in the document that it should be able to directly construct strings with parameter byte array to reduce array allocation. >> >> However, at present, `newStringNoRepl` always copies arrays for UTF-8 or other ASCII compatible charsets. >> >> This PR fixes this problem. > > Glavo has updated the pull request incrementally with one additional commit since the last revision: > > update Does anyone review this PR again? ------------- PR: https://git.openjdk.org/jdk/pull/12119 From darcy at openjdk.org Wed Mar 1 06:03:52 2023 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 1 Mar 2023 06:03:52 GMT Subject: RFR: JDK-8302027: Port fdlibm trig functions (sin, cos, tan) to Java Message-ID: Last and certainly not least in the port of FDLIBM to Java, the transcendental methods for sin, cos, and tan. Some more tests are to be written in the StrictMath directory to verify that the StrictMath algorihtm for sin/cos/tan is being used rather than a different one. However, I wanted to get the rest of the change out for review first. The sin/cos/tan methods are grouped together since they share the same argument reduction logic. Argument reduction is the process of mapping an argument of a function to an argument in a restricted range (and possibly returning some function of the reduced argument). For sin, cos, and tan, since they are fundamentally periodic with respect to a multiple of pi, argument reduction is done to find the remainder of the original argument with respect to pi/2. ------------- Commit messages: - Appease jcheck. - Add tests. - Checkpoint Fdlibm.java - Merge branch 'master' into JDK-8302027 - Updates. - Initial port attempt for sin, cos, tan; not working yet. Changes: https://git.openjdk.org/jdk/pull/12800/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12800&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8302027 Stats: 1976 lines in 6 files changed: 1954 ins; 12 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/12800.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12800/head:pull/12800 PR: https://git.openjdk.org/jdk/pull/12800 From darcy at openjdk.org Wed Mar 1 06:03:53 2023 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 1 Mar 2023 06:03:53 GMT Subject: RFR: JDK-8302027: Port fdlibm trig functions (sin, cos, tan) to Java In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 05:28:34 GMT, Joe Darcy wrote: > Last and certainly not least in the port of FDLIBM to Java, the transcendental methods for sin, cos, and tan. > > Some more tests are to be written in the StrictMath directory to verify that the StrictMath algorihtm for sin/cos/tan is being used rather than a different one. However, I wanted to get the rest of the change out for review first. > > The sin/cos/tan methods are grouped together since they share the same argument reduction logic. Argument reduction is the process of mapping an argument of a function to an argument in a restricted range (and possibly returning some function of the reduced argument). For sin, cos, and tan, since they are fundamentally periodic with respect to a multiple of pi, argument reduction is done to find the remainder of the original argument with respect to pi/2. The "exhausting" test comparing the results on every float argument passes for: * the transliteration port compared to the existing C code (i.e. exhausting test run with a JDK 20 build) * the java.lang.Fdlibm.java port compared to the transliteration port ------------- PR: https://git.openjdk.org/jdk/pull/12800 From darcy at openjdk.org Wed Mar 1 06:09:03 2023 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 1 Mar 2023 06:09:03 GMT Subject: RFR: JDK-8302027: Port fdlibm trig functions (sin, cos, tan) to Java In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 05:28:34 GMT, Joe Darcy wrote: > Last and certainly not least in the port of FDLIBM to Java, the transcendental methods for sin, cos, and tan. > > Some more tests are to be written in the StrictMath directory to verify that the StrictMath algorihtm for sin/cos/tan is being used rather than a different one. However, I wanted to get the rest of the change out for review first. > > The sin/cos/tan methods are grouped together since they share the same argument reduction logic. Argument reduction is the process of mapping an argument of a function to an argument in a restricted range (and possibly returning some function of the reduced argument). For sin, cos, and tan, since they are fundamentally periodic with respect to a multiple of pi, argument reduction is done to find the remainder of the original argument with respect to pi/2. Various diffs to aid the review: $ diff -w Sin.c Sin.translit.java 1c1 < /* sin(x) --- > /** sin(x) 31,41c31,34 < < #include "fdlibm.h" < < #ifdef __STDC__ < double sin(double x) < #else < double sin(x) < double x; < #endif < { < double y[2],z=0.0; --- > static class Sin { > static double compute(double x) { > double[] y = new double[2]; > double z=0.0; 56c49 < n = __ieee754_rem_pio2(x,y); --- > n = RemPio2.__ieee754_rem_pio2(x,y); 58,60c51,53 < case 0: return __kernel_sin(y[0],y[1],1); < case 1: return __kernel_cos(y[0],y[1]); < case 2: return -__kernel_sin(y[0],y[1],1); --- > case 0: return Sin.__kernel_sin(y[0],y[1],1); > case 1: return Cos.__kernel_cos(y[0],y[1]); > case 2: return -Sin.__kernel_sin(y[0],y[1],1); 62c55 < return -__kernel_cos(y[0],y[1]); --- > return -Cos.__kernel_cos(y[0],y[1]); 66c59,60 < /* __kernel_sin( x, y, iy) --- > > /** __kernel_sin( x, y, iy) 93,100c87 < < #include "fdlibm.h" < < #ifdef __STDC__ < static const double < #else < static double < #endif --- > private static final double 109,115c96 < #ifdef __STDC__ < double __kernel_sin(double x, double y, int iy) < #else < double __kernel_sin(x, y, iy) < double x,y; int iy; /* iy=0 if y is zero */ < #endif < { --- > static double __kernel_sin(double x, double y, int iy) { 126a108 > } $ diff -w Sin.translit.java Sin.fdlibm.java 31a32,33 > private Sin() {throw new UnsupportedOperationException();} > 37c39 < /* High word of x. */ --- > // High word of x. 40,48c42,48 < /* |x| ~< pi/4 */ < ix &= 0x7fffffff; < if(ix <= 0x3fe921fb) return __kernel_sin(x,z,0); < < /* sin(Inf or NaN) is NaN */ < else if (ix>=0x7ff00000) return x-x; < < /* argument reduction needed */ < else { --- > // |x| ~< pi/4 > ix &= 0x7fff_ffff; > if (ix <= 0x3fe9_21fb) { > return __kernel_sin(x, z, 0); > } else if (ix>=0x7ff0_0000) { // sin(Inf or NaN) is NaN > return x - x; > } else { // argument reduction needed 88,94c88,93 < half = 5.00000000000000000000e-01, /* 0x3FE00000, 0x00000000 */ < S1 = -1.66666666666666324348e-01, /* 0xBFC55555, 0x55555549 */ < S2 = 8.33333333332248946124e-03, /* 0x3F811111, 0x1110F8A6 */ < S3 = -1.98412698298579493134e-04, /* 0xBF2A01A0, 0x19C161D5 */ < S4 = 2.75573137070700676789e-06, /* 0x3EC71DE3, 0x57B1FE7D */ < S5 = -2.50507602534068634195e-08, /* 0xBE5AE5E6, 0x8A2B9CEB */ < S6 = 1.58969099521155010221e-10; /* 0x3DE5D93A, 0x5ACFD57C */ --- > S1 = -0x1.5555555555549p-3, // -1.66666666666666324348e-01 > S2 = 0x1.111111110f8a6p-7, // 8.33333333332248946124e-03 > S3 = -0x1.a01a019c161d5p-13, // -1.98412698298579493134e-04 > S4 = 0x1.71de357b1fe7dp-19, // 2.75573137070700676789e-06 > S5 = -0x1.ae5e68a2b9cebp-26, // -2.50507602534068634195e-08 > S6 = 0x1.5d93a5acfd57cp-33; // 1.58969099521155010221e-10 99,101c98,102 < ix = __HI(x)&0x7fffffff; /* high word of x */ < if(ix<0x3e400000) /* |x| < 2**-27 */ < {if((int)x==0) return x;} /* generate inexact */ --- > ix = __HI(x) & 0x7fff_ffff; // high word of x > if (ix < 0x3e40_0000) { // |x| < 2**-27 > if ((int)x == 0) // generate inexact > return x; > } 105,106c106,110 < if(iy==0) return x+v*(S1+z*r); < else return x-((z*(half*y-v*r)-y)-v*S1); --- > if (iy == 0) { > return x + v*(S1 + z*r); > } else { > return x - ((z*(0.5*y - v*r) - y) - v*S1); > } ------------- PR: https://git.openjdk.org/jdk/pull/12800 From mdoerr at openjdk.org Wed Mar 1 06:12:54 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 1 Mar 2023 06:12:54 GMT Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function & Memory API (Preview) [v5] In-Reply-To: References: Message-ID: <3kCGyBFd4OIVzBcT_6KQIvJIFCGVRTRq2dy3qKP0Piw=.ef00d405-43e7-402a-a1d3-1ebaed3b7830@github.com> > Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification". > > This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `` (2.2.4 Variable Argument Lists). > > Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only. > > There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. > > The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests. > > I had to make changes to shared code and code for other platforms: > 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons: > - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that. > - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64. > - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian! > 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: Minor cleanup. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12708/files - new: https://git.openjdk.org/jdk/pull/12708/files/b461d80c..75b5c78f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=03-04 Stats: 6 lines in 3 files changed: 0 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/12708.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12708/head:pull/12708 PR: https://git.openjdk.org/jdk/pull/12708 From mdoerr at openjdk.org Wed Mar 1 06:12:59 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 1 Mar 2023 06:12:59 GMT Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function & Memory API (Preview) [v3] In-Reply-To: References: <8b3vVrV22RuhdRoRYacXV0ZeghFGgKkC8S_z-iMrzAQ=.dd84b743-8b51-4281-8f5f-f9eff6207bc7@github.com> Message-ID: On Tue, 28 Feb 2023 16:54:50 GMT, Jorn Vernee wrote: >> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove size restriction for structs. Add TODO for Big Endian. > > src/hotspot/cpu/ppc/downcallLinker_ppc.cpp line 343: > >> 341: >> 342: __ flush(); >> 343: // Disassembler::decode((u_char*)start, (u_char*)__ pc(), tty); > > Leftover commented code? > > (note that the stub can also be disassembled with `-Xlog:foreign+downcall=trace` now) Removed. Thanks for the hint! > src/hotspot/cpu/ppc/upcallLinker_ppc.cpp line 356: > >> 354: } >> 355: #endif >> 356: //blob->print_on(tty); > > Leftover commented code? Removed. ------------- PR: https://git.openjdk.org/jdk/pull/12708 From mdoerr at openjdk.org Wed Mar 1 06:13:03 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 1 Mar 2023 06:13:03 GMT Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function & Memory API (Preview) [v5] In-Reply-To: References: <8b3vVrV22RuhdRoRYacXV0ZeghFGgKkC8S_z-iMrzAQ=.dd84b743-8b51-4281-8f5f-f9eff6207bc7@github.com> Message-ID: On Wed, 22 Feb 2023 20:25:07 GMT, Jorn Vernee wrote: >> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: >> >> Minor cleanup. > > src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/CallArranger.java line 81: > >> 79: new VMStorage[] { f1, f2, f3, f4, f5, f6, f7, f8 }, // FP output >> 80: new VMStorage[] { r0, r2, r3, r4, r5, r6, r7, r8, r9, r10, r11, r12 }, // volatile GP >> 81: new VMStorage[] { f0, f1, f2, f3, f4, f5, f6, f7, f8, f9, f10, f11, f12, f13 }, // volatile FP > > Note that argument registers are assumed volatile, so they don't have to be duplicated here. Removed. > src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/linux/LinuxPPC64CallArranger.java line 33: > >> 31: * PPC64 CallArranger specialized for Linux ABI. >> 32: */ >> 33: public class LinuxPPC64CallArranger extends CallArranger { > > I don't really see the point in having a separate subclass with `CallArranger` being abstract, unless you are planning to add other implementations later? > > (edit: see also later comment in CallArranger https://github.com/openjdk/jdk/pull/12708#discussion_r1120753657) AIX support will need to get implemented, yet. I guess @backwaterred will work on it. ------------- PR: https://git.openjdk.org/jdk/pull/12708 From darcy at openjdk.org Wed Mar 1 06:15:07 2023 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 1 Mar 2023 06:15:07 GMT Subject: RFR: JDK-8302027: Port fdlibm trig functions (sin, cos, tan) to Java In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 05:28:34 GMT, Joe Darcy wrote: > Last and certainly not least in the port of FDLIBM to Java, the transcendental methods for sin, cos, and tan. > > Some more tests are to be written in the StrictMath directory to verify that the StrictMath algorihtm for sin/cos/tan is being used rather than a different one. However, I wanted to get the rest of the change out for review first. > > The sin/cos/tan methods are grouped together since they share the same argument reduction logic. Argument reduction is the process of mapping an argument of a function to an argument in a restricted range (and possibly returning some function of the reduced argument). For sin, cos, and tan, since they are fundamentally periodic with respect to a multiple of pi, argument reduction is done to find the remainder of the original argument with respect to pi/2. And for cos: $ diff -w Cos.c Cos.translit.java 1c1 < /* cos(x) --- > /** cos(x) 31,41c31,34 < < #include "fdlibm.h" < < #ifdef __STDC__ < double cos(double x) < #else < double cos(x) < double x; < #endif < { < double y[2],z=0.0; --- > static class Cos { > static double compute(double x) { > double[] y = new double[2]; > double z=0.0; 56c49 < n = __ieee754_rem_pio2(x,y); --- > n = RemPio2.__ieee754_rem_pio2(x,y); 58,60c51,53 < case 0: return __kernel_cos(y[0],y[1]); < case 1: return -__kernel_sin(y[0],y[1],1); < case 2: return -__kernel_cos(y[0],y[1]); --- > case 0: return Cos.__kernel_cos(y[0],y[1]); > case 1: return -Sin.__kernel_sin(y[0],y[1],1); > case 2: return -Cos.__kernel_cos(y[0],y[1]); 62c55 < return __kernel_sin(y[0],y[1],1); --- > return Sin.__kernel_sin(y[0],y[1],1); 66c59,60 < /* --- > > /** 100,107c94 < < #include "fdlibm.h" < < #ifdef __STDC__ < static const double < #else < static double < #endif --- > private static final double 116,123c103,104 < #ifdef __STDC__ < double __kernel_cos(double x, double y) < #else < double __kernel_cos(x, y) < double x,y; < #endif < { < double a,hz,z,r,qx; --- > static double __kernel_cos(double x, double y) { > double a,hz,z,r,qx = 0.0; 137,138c118,121 < __HI(qx) = ix-0x00200000; /* x/4 */ < __LO(qx) = 0; --- > //__HI(qx) = ix-0x00200000; /* x/4 */ > qx = __HI(qx, ix-0x00200000); > // __LO(qx) = 0; > qx = __LO(qx, 0); 144a128 > } $ diff -w Cos.translit.java Cos.fdlibm.java 31a32,33 > private Cos() {throw new UnsupportedOperationException();} > 37c39 < /* High word of x. */ --- > // High word of x. 40,48c42,48 < /* |x| ~< pi/4 */ < ix &= 0x7fffffff; < if(ix <= 0x3fe921fb) return __kernel_cos(x,z); < < /* cos(Inf or NaN) is NaN */ < else if (ix>=0x7ff00000) return x-x; < < /* argument reduction needed */ < else { --- > // |x| ~< pi/4 > ix &= 0x7fff_ffff; > if (ix <= 0x3fe9_21fb) { > return __kernel_cos(x, z); > } else if (ix >= 0x7ff0_0000) { // cos(Inf or NaN) is NaN > return x-x; > } else { // argument reduction needed 95,101c95,100 < one = 1.00000000000000000000e+00, /* 0x3FF00000, 0x00000000 */ < C1 = 4.16666666666666019037e-02, /* 0x3FA55555, 0x5555554C */ < C2 = -1.38888888888741095749e-03, /* 0xBF56C16C, 0x16C15177 */ < C3 = 2.48015872894767294178e-05, /* 0x3EFA01A0, 0x19CB1590 */ < C4 = -2.75573143513906633035e-07, /* 0xBE927E4F, 0x809C52AD */ < C5 = 2.08757232129817482790e-09, /* 0x3E21EE9E, 0xBDB4B1C4 */ < C6 = -1.13596475577881948265e-11; /* 0xBDA8FAE9, 0xBE8838D4 */ --- > C1 = 0x1.555555555554cp-5, // 4.16666666666666019037e-02 > C2 = -0x1.6c16c16c15177p-10, // -1.38888888888741095749e-03 > C3 = 0x1.a01a019cb159p-16, // 2.48015872894767294178e-05 > C4 = -0x1.27e4f809c52adp-22, // -2.75573143513906633035e-07 > C5 = 0x1.1ee9ebdb4b1c4p-29, // 2.08757232129817482790e-09 > C6 = -0x1.8fae9be8838d4p-37; // -1.13596475577881948265e-11 106,108c105,109 < ix = __HI(x)&0x7fffffff; /* ix = |x|'s high word*/ < if(ix<0x3e400000) { /* if x < 2**27 */ < if(((int)x)==0) return one; /* generate inexact */ --- > ix = __HI(x) & 0x7fff_ffff; // ix = |x|'s high word > if (ix < 0x3e40_0000) { // if x < 2**27 > if (((int)x) == 0) { // generate inexact > return 1.0; > } 112,115c113,116 < if(ix < 0x3FD33333) /* if |x| < 0.3 */ < return one - (0.5*z - (z*r - x*y)); < else { < if(ix > 0x3fe90000) { /* x > 0.78125 */ --- > if (ix < 0x3FD3_3333) { // if |x| < 0.3 > return 1.0 - (0.5*z - (z*r - x*y)); > } else { > if (ix > 0x3fe9_0000) { // x > 0.78125 118,121c119 < //__HI(qx) = ix-0x00200000; /* x/4 */ < qx = __HI(qx, ix-0x00200000); < // __LO(qx) = 0; < qx = __LO(qx, 0); --- > qx = __HI_LO(ix - 0x0020_0000, 0); 124c122 < a = one-qx; --- > a = 1.0 - qx; And tan: $ diff -w Tan.c Tan.translit.java 1c1 < /* tan(x) --- > /** tan(x) 30,40c30,33 < < #include "fdlibm.h" < < #ifdef __STDC__ < double tan(double x) < #else < double tan(x) < double x; < #endif < { < double y[2],z=0.0; --- > static class Tan { > static double compute(double x) { > double[] y= new double[2]; > double z=0.0; 55c48 < n = __ieee754_rem_pio2(x,y); --- > n = RemPio2.__ieee754_rem_pio2(x,y); 60c53,54 < /* __kernel_tan( x, y, k ) --- > > /** __kernel_tan( x, y, k ) 93,99c87 < < #include "fdlibm.h" < #ifdef __STDC__ < static const double < #else < static double < #endif --- > private static final double 119,125c107 < #ifdef __STDC__ < double __kernel_tan(double x, double y, int iy) < #else < double __kernel_tan(x, y, iy) < double x,y; int iy; < #endif < { --- > static double __kernel_tan(double x, double y, int iy) { 133c115 < return one / fabs(x); --- > return one / Math.abs(x); 141c123,124 < __LO(z) = 0; --- > // __LO(z) = 0; > z= __LO(z, 0); 144c127,128 < __LO(t) = 0; --- > //__LO(t) = 0; > t = __LO(t, 0); 179c163,164 < __LO(z) = 0; --- > // __LO(z) = 0; > z = __LO(z, 0); 182c167,168 < __LO(t) = 0; --- > // __LO(t) = 0; > t = __LO(t, 0); 186a173 > } $ diff -w Tan.translit.java Tan.fdlibm.java 30a31,32 > private Tan() {throw new UnsupportedOperationException();} > 36c38 < /* High word of x. */ --- > // High word of x. 39,47c41,47 < /* |x| ~< pi/4 */ < ix &= 0x7fffffff; < if(ix <= 0x3fe921fb) return __kernel_tan(x,z,1); < < /* tan(Inf or NaN) is NaN */ < else if (ix>=0x7ff00000) return x-x; /* NaN */ < < /* argument reduction needed */ < else { --- > // |x| ~< pi/4 > ix &= 0x7fff_ffff; > if (ix <= 0x3fe9_21fb) { > return __kernel_tan(x, z, 1); > } else if (ix >= 0x7ff0_0000) { // tan(Inf or NaN) is NaN > return x-x; // NaN > } else { // argument reduction needed 49,50c49 < return __kernel_tan(y[0],y[1],1-((n&1)<<1)); /* 1 -- n even < -1 -- n odd */ --- > return __kernel_tan(y[0], y[1], 1 - ((n & 1) << 1)); // 1 -- n even; -1 -- n odd 88,90c87,88 < one = 1.00000000000000000000e+00, /* 0x3FF00000, 0x00000000 */ < pio4 = 7.85398163397448278999e-01, /* 0x3FE921FB, 0x54442D18 */ < pio4lo= 3.06161699786838301793e-17, /* 0x3C81A626, 0x33145C07 */ --- > pio4 = 0x1.921fb54442d18p-1, // 7.85398163397448278999e-01 > pio4lo= 0x1.1a62633145c07p-55, // 3.06161699786838301793e-17 92,104c90,102 < 3.33333333333334091986e-01, /* 0x3FD55555, 0x55555563 */ < 1.33333333333201242699e-01, /* 0x3FC11111, 0x1110FE7A */ < 5.39682539762260521377e-02, /* 0x3FABA1BA, 0x1BB341FE */ < 2.18694882948595424599e-02, /* 0x3F9664F4, 0x8406D637 */ < 8.86323982359930005737e-03, /* 0x3F8226E3, 0xE96E8493 */ < 3.59207910759131235356e-03, /* 0x3F6D6D22, 0xC9560328 */ < 1.45620945432529025516e-03, /* 0x3F57DBC8, 0xFEE08315 */ < 5.88041240820264096874e-04, /* 0x3F4344D8, 0xF2F26501 */ < 2.46463134818469906812e-04, /* 0x3F3026F7, 0x1A8D1068 */ < 7.81794442939557092300e-05, /* 0x3F147E88, 0xA03792A6 */ < 7.14072491382608190305e-05, /* 0x3F12B80F, 0x32F0A7E9 */ < -1.85586374855275456654e-05, /* 0xBEF375CB, 0xDB605373 */ < 2.59073051863633712884e-05, /* 0x3EFB2A70, 0x74BF7AD4 */ --- > 0x1.5555555555563p-2, // 3.33333333333334091986e-01 > 0x1.111111110fe7ap-3, // 1.33333333333201242699e-01 > 0x1.ba1ba1bb341fep-5, // 5.39682539762260521377e-02 > 0x1.664f48406d637p-6, // 2.18694882948595424599e-02 > 0x1.226e3e96e8493p-7, // 8.86323982359930005737e-03 > 0x1.d6d22c9560328p-9, // 3.59207910759131235356e-03 > 0x1.7dbc8fee08315p-10, // 1.45620945432529025516e-03 > 0x1.344d8f2f26501p-11, // 5.88041240820264096874e-04 > 0x1.026f71a8d1068p-12, // 2.46463134818469906812e-04 > 0x1.47e88a03792a6p-14, // 7.81794442939557092300e-05 > 0x1.2b80f32f0a7e9p-14, // 7.14072491382608190305e-05 > -0x1.375cbdb605373p-16, // -1.85586374855275456654e-05 > 0x1.b2a7074bf7ad4p-16, // 2.59073051863633712884e-05 110,117c108,115 < hx = __HI(x); /* high word of x */ < ix = hx&0x7fffffff; /* high word of |x| */ < if(ix<0x3e300000) { /* x < 2**-28 */ < if((int)x==0) { /* generate inexact */ < if (((ix | __LO(x)) | (iy + 1)) == 0) < return one / Math.abs(x); < else { < if (iy == 1) --- > hx = __HI(x); // high word of x > ix = hx&0x7fff_ffff; // high word of |x| > if (ix < 0x3e30_0000) { // x < 2**-28 > if ((int)x == 0) { // generate inexact > if (((ix | __LO(x)) | (iy + 1)) == 0) { > return 1.0 / Math.abs(x); > } else { > if (iy == 1) { 119c117 < else { /* compute -1 / (x+y) carefully */ --- > } else { // compute -1 / (x+y) carefully 123d120 < // __LO(z) = 0; 126,127c123 < t = a = -one / w; < //__LO(t) = 0; --- > t = a = -1.0 / w; 129c125 < s = one + t * z; --- > s = 1.0 + t * z; 135,136c131,135 < if(ix>=0x3FE59428) { /* |x|>=0.6744 */ < if(hx<0) {x = -x; y = -y;} --- > if (ix >= 0x3FE5_9428) { // |x| >= 0.6744 > if ( hx < 0) { > x = -x; > y = -y; > } 139c138,139 < x = z+w; y = 0.0; --- > x = z + w; > y = 0.0; 153c153 < if(ix>=0x3FE59428) { --- > if (ix >= 0x3FE5_9428) { 157,160c157,161 < if(iy==1) return w; < else { /* if allow error up to 2 ulp, < simply return -1.0/(x+r) here */ < /* compute -1.0/(x+r) accurately */ --- > if (iy == 1) { > return w; > } else { /* if were to allow error up to 2 ulp, > could simply return -1.0/(x + r) here */ > // compute -1.0/(x + r) accurately 163d163 < // __LO(z) = 0; 165,167c165,166 < v = r-(z - x); /* z+v = r+x */ < t = a = -1.0/w; /* a = -1.0/w */ < // __LO(t) = 0; --- > v = r - (z - x); // z + v = r + x > t = a = -1.0/w; // a = -1.0/w ------------- PR: https://git.openjdk.org/jdk/pull/12800 From mdoerr at openjdk.org Wed Mar 1 06:20:11 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 1 Mar 2023 06:20:11 GMT Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function & Memory API (Preview) [v3] In-Reply-To: References: <8b3vVrV22RuhdRoRYacXV0ZeghFGgKkC8S_z-iMrzAQ=.dd84b743-8b51-4281-8f5f-f9eff6207bc7@github.com> Message-ID: On Tue, 28 Feb 2023 19:45:28 GMT, Jorn Vernee wrote: >> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove size restriction for structs. Add TODO for Big Endian. > > src/hotspot/cpu/ppc/downcallLinker_ppc.cpp line 133: > >> 131: Register callerSP = R2, // C/C++ uses R2 as TOC, but we can reuse it here >> 132: tmp = R11_scratch1, // same as shuffle_reg >> 133: call_target_address = R12_scratch2; // same as _abi._scratch2 (ABIv2 requires this reg!) > > Do I understand correctly that the ABI requires the register to be used for the call to be `R12`? How does that make a difference? I guess in some cases the callee might want to know the address through which it is called? (so it looks at `R12`) ABI v2 requires R12 to point to the function entry point. It is used to access constants relative to it. > src/hotspot/cpu/ppc/downcallLinker_ppc.cpp line 154: > >> 152: // (abi_reg_args is abi_minframe plus space for 8 argument register spill slots) >> 153: assert(_abi._shadow_space_bytes == frame::abi_minframe_size, "expected space according to ABI"); >> 154: int allocated_frame_size = frame::abi_minframe_size + MAX2(_input_registers.length(), 8) * BytesPerWord; > > This is hard-coding an assumption about the ABI that's being called. Ok for now. > > If it needs to be addressed in the future, it could be done by adding another field to `ABIDescriptor` like `min_stack_arg_bytes`, or something like that (which is set to zero for other ABIs). It seems to be different from `shadow_space` since it's also used by the caller to put stack arguments. Yeah, I think this should be done on demand. > src/hotspot/cpu/ppc/foreignGlobals_ppc.cpp line 229: > >> 227: >> 228: void ArgumentShuffle::pd_generate(MacroAssembler* masm, VMStorage tmp, int in_stk_bias, int out_stk_bias, const StubLocations& locs) const { >> 229: Register callerSP = as_Register(tmp); // preset > > It looks like `tmp` is being used to hold the caller's SP. I'm guessing this can not be computed the same way as we do on x86 and aarch64? (based on `RBP`, `RFP_BIAS`) > > If you want, you could add another register argument to `pd_generate` that is just invalid/unused on other platforms. That way you could use `tmp` for the shuffling instead of having to go through the stack. (looks like `R0` is already used in some cases as a temp register) There's no BP register. It could get loaded from the back chain, but would still need a register. R0 is always available as scratch reg, so there's no need to pass it. (Note that I'm not going through stack because of the lack of registers.) Yeah, maybe passing callerSP separately would make it better readable on PPC64. Not sure if it's worth changing. > src/hotspot/cpu/ppc/upcallLinker_ppc.cpp line 137: > >> 135: ArgumentShuffle arg_shuffle(in_sig_bt, total_in_args, out_sig_bt, total_out_args, &in_conv, &out_conv, shuffle_reg); >> 136: // The Java call uses the JIT ABI, but we also call C. >> 137: int out_arg_area = MAX2(frame::jit_out_preserve_size + arg_shuffle.out_arg_bytes(), (int)frame::abi_reg_args_size); > > We need `frame::abi_reg_args_size` since we call `on_entry`/`on_exit` which require the stack space I guess? Correct. C functions are allowed to write into the space which is part of the caller's frame. ------------- PR: https://git.openjdk.org/jdk/pull/12708 From darcy at openjdk.org Wed Mar 1 06:24:04 2023 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 1 Mar 2023 06:24:04 GMT Subject: RFR: JDK-8302027: Port fdlibm trig functions (sin, cos, tan) to Java In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 05:28:34 GMT, Joe Darcy wrote: > Last and certainly not least in the port of FDLIBM to Java, the transcendental methods for sin, cos, and tan. > > Some more tests are to be written in the StrictMath directory to verify that the StrictMath algorihtm for sin/cos/tan is being used rather than a different one. However, I wanted to get the rest of the change out for review first. > > The sin/cos/tan methods are grouped together since they share the same argument reduction logic. Argument reduction is the process of mapping an argument of a function to an argument in a restricted range (and possibly returning some function of the reduced argument). For sin, cos, and tan, since they are fundamentally periodic with respect to a multiple of pi, argument reduction is done to find the remainder of the original argument with respect to pi/2. And the shared remainder-pi-over-2 code: $ diff -w RemPio2.c RemPio2.translit.java 1c1 < /* __ieee754_rem_pio2(x,y) --- > /** __ieee754_rem_pio2(x,y) 6,8c6 < < #include "fdlibm.h" < --- > static class RemPio2 { 12,16c10 < #ifdef __STDC__ < static const int two_over_pi[] = { < #else < static int two_over_pi[] = { < #endif --- > private static final int[] two_over_pi = { 30,34c24 < #ifdef __STDC__ < static const int npio2_hw[] = { < #else < static int npio2_hw[] = { < #endif --- > private static final int[] npio2_hw = { 53,57c43 < #ifdef __STDC__ < static const double < #else < static double < #endif --- > private static final double 69,77c55,57 < #ifdef __STDC__ < int __ieee754_rem_pio2(double x, double *y) < #else < int __ieee754_rem_pio2(x,y) < double x,y[]; < #endif < { < double z,w,t,r,fn; < double tx[3]; --- > static int __ieee754_rem_pio2(double x, double[] y) { > double z = 0.0,w,t,r,fn; > double[] tx = new double[3]; 110c90 < t = fabs(x); --- > t = Math.abs(x); 148c128,129 < __LO(z) = __LO(x); --- > // __LO(z) = __LO(x); > z = __LO(z, __LO(x)); 150c131,132 < __HI(z) = ix - (e0<<20); --- > // __HI(z) = ix - (e0<<20); > z = __HI(z, ix - (e0<<20)); 158c140 < n = __kernel_rem_pio2(tx,y,e0,nx,2,two_over_pi); --- > n = KernelRemPio2.__kernel_rem_pio2(tx,y,e0,nx,2,two_over_pi); 162c144,147 < /* --- > > } > > /** 268,269c253 < < --- > static class KernelRemPio2 { 278c262 < #include "fdlibm.h" --- > private static final int[] init_jk = {2,3,4,6}; /* initial value for jk */ 280,290c264 < #ifdef __STDC__ < static const int init_jk[] = {2,3,4,6}; /* initial value for jk */ < #else < static int init_jk[] = {2,3,4,6}; < #endif < < #ifdef __STDC__ < static const double PIo2[] = { < #else < static double PIo2[] = { < #endif --- > private static final double[] PIo2 = { 300,305c274 < < #ifdef __STDC__ < static const double < #else < static double < #endif --- > static final double 311,319c280,286 < #ifdef __STDC__ < int __kernel_rem_pio2(double *x, double *y, int e0, int nx, int prec, const int *ipio2) < #else < int __kernel_rem_pio2(x,y,e0,nx,prec,ipio2) < double x[], y[]; int e0,nx,prec; int ipio2[]; < #endif < { < int jz,jx,jv,jp,jk,carry,n,iq[20],i,j,k,m,q0,ih; < double z,fw,f[20],fq[20],q[20]; --- > static int __kernel_rem_pio2(double[] x, double[] y, int e0, int nx, int prec, final int[] ipio2) { > int jz,jx,jv,jp,jk,carry,n,i,j,k,m,q0,ih; > int[] iq = new int[20]; > double z,fw; > double [] f = new double[20]; > double [] fq= new double[20]; > double [] q = new double[20]; 341c308 < recompute: --- > while(true) { 350,351c317,318 < z = scalbn(z,q0); /* actual value of z */ < z -= 8.0*floor(z*0.125); /* trim off integer >= 8 */ --- > z = Math.scalb(z,q0); /* actual value of z */ > z -= 8.0*Math.floor(z*0.125); /* trim off integer >= 8 */ 383c350 < if(carry!=0) z -= scalbn(one,q0); --- > if(carry!=0) z -= Math.scalb(one,q0); 400,401c367,369 < goto recompute; < } --- > continue; > } else { break;} > } else {break;} 409c377 < z = scalbn(z,-q0); --- > z = Math.scalb(z,-q0); 419c387 < fw = scalbn(one,q0); --- > fw = Math.scalb(one,q0); 465a434 > } Yes, dear reader, the original C code contained a goto to implement a looping contract. To maintain close code correspondence, I wrapped with code in question with a "while(true){...}" and then "break"-ed or "continue"-d to iterate or exit the loop. $ diff -w RemPio2.translit.java RemPio2.fdlibm.java 44,53c44,50 < zero = 0.00000000000000000000e+00, /* 0x00000000, 0x00000000 */ < half = 5.00000000000000000000e-01, /* 0x3FE00000, 0x00000000 */ < two24 = 1.67772160000000000000e+07, /* 0x41700000, 0x00000000 */ < invpio2 = 6.36619772367581382433e-01, /* 0x3FE45F30, 0x6DC9C883 */ < pio2_1 = 1.57079632673412561417e+00, /* 0x3FF921FB, 0x54400000 */ < pio2_1t = 6.07710050650619224932e-11, /* 0x3DD0B461, 0x1A626331 */ < pio2_2 = 6.07710050630396597660e-11, /* 0x3DD0B461, 0x1A600000 */ < pio2_2t = 2.02226624879595063154e-21, /* 0x3BA3198A, 0x2E037073 */ < pio2_3 = 2.02226624871116645580e-21, /* 0x3BA3198A, 0x2E000000 */ < pio2_3t = 8.47842766036889956997e-32; /* 0x397B839A, 0x252049C1 */ --- > invpio2 = 0x1.45f306dc9c883p-1, // 6.36619772367581382433e-01 > pio2_1 = 0x1.921fb544p0, // 1.57079632673412561417e+00 > pio2_1t = 0x1.0b4611a626331p-34, // 6.07710050650619224932e-11 > pio2_2 = 0x1.0b4611a6p-34, // 6.07710050630396597660e-11 > pio2_2t = 0x1.3198a2e037073p-69, // 2.02226624879595063154e-21 > pio2_3 = 0x1.3198a2ep-69, // 2.02226624871116645580e-21 > pio2_3t = 0x1.b839a252049c1p-104; // 8.47842766036889956997e-32 60,64c57,64 < hx = __HI(x); /* high word of x */ < ix = hx&0x7fffffff; < if(ix<=0x3fe921fb) /* |x| ~<= pi/4 , no need for reduction */ < {y[0] = x; y[1] = 0; return 0;} < if(ix<0x4002d97c) { /* |x| < 3pi/4, special case with n=+-1 */ --- > hx = __HI(x); // high word of x > ix = hx & 0x7fff_ffff; > if (ix <= 0x3fe9_21fb) { // |x| ~<= pi/4 , no need for reduction > y[0] = x; > y[1] = 0; > return 0; > } > if (ix < 0x4002_d97c) { // |x| < 3pi/4, special case with n=+-1 67c67 < if(ix!=0x3ff921fb) { /* 33+53 bit pi is good enough */ --- > if (ix != 0x3ff9_21fb) { // 33+53 bit pi is good enough 70c70 < } else { /* near pi/2, use 33+33+53 bit pi */ --- > } else { // near pi/2, use 33+33+53 bit pi 76c76 < } else { /* negative x */ --- > } else { // negative x 78c78 < if(ix!=0x3ff921fb) { /* 33+53 bit pi is good enough */ --- > if (ix != 0x3ff_921fb) { // 33+53 bit pi is good enough 81c81 < } else { /* near pi/2, use 33+33+53 bit pi */ --- > } else { // near pi/2, use 33+33+53 bit pi 89c89 < if(ix<=0x413921fb) { /* |x| ~<= 2^19*(pi/2), medium size */ --- > if (ix <= 0x4139_21fb) { // |x| ~<= 2^19*(pi/2), medium size 91c91 < n = (int) (t*invpio2+half); --- > n = (int) (t*invpio2 + 0.5); 94c94 < w = fn*pio2_1t; /* 1st round good to 85 bit */ --- > w = fn*pio2_1t; // 1st round good to 85 bit 96c96 < y[0] = r-w; /* quick check no cancellation */ --- > y[0] = r - w; // quick check no cancellation 101c101 < if(i>16) { /* 2nd iteration needed, good to 118 */ --- > if (i > 16) { // 2nd iteration needed, good to 118 108,109c108,109 < if(i>49) { /* 3rd iteration need, 151 bits acc */ < t = r; /* will cover all possible cases */ --- > if (i > 49) { // 3rd iteration need, 151 bits acc > t = r; // will cover all possible cases 118,119c118,124 < if(hx<0) {y[0] = -y[0]; y[1] = -y[1]; return -n;} < else return n; --- > if (hx < 0) { > y[0] = -y[0]; > y[1] = -y[1]; > return -n; > } else { > return n; > } 124,125c129,131 < if(ix>=0x7ff00000) { /* x is inf or NaN */ < y[0]=y[1]=x-x; return 0; --- > if (ix >= 0x7ff0_0000) { // x is inf or NaN > y[0] = y[1] = x - x; > return 0; 127,128c133 < /* set z = scalbn(|x|,ilogb(x)-23) */ < // __LO(z) = __LO(x); --- > // set z = scalbn(|x|,ilogb(x)-23) 131d135 < // __HI(z) = ix - (e0<<20); 135c139 < z = (z-tx[i])*two24; --- > z = (z - tx[i])*TWO24; 139c143,145 < while(tx[nx-1]==zero) nx--; /* skip zero term */ --- > while (tx[nx - 1] == 0.0) { // skip zero term > nx--; > } 141c147,151 < if(hx<0) {y[0] = -y[0]; y[1] = -y[1]; return -n;} --- > if (hx < 0) { > y[0] = -y[0]; > y[1] = -y[1]; > return -n; > } 144d153 < 262c271 < private static final int[] init_jk = {2,3,4,6}; /* initial value for jk */ --- > private static final int init_jk[] = {2, 3, 4, 6}; // initial value for jk 264,272c273,281 < private static final double[] PIo2 = { < 1.57079625129699707031e+00, /* 0x3FF921FB, 0x40000000 */ < 7.54978941586159635335e-08, /* 0x3E74442D, 0x00000000 */ < 5.39030252995776476554e-15, /* 0x3CF84698, 0x80000000 */ < 3.28200341580791294123e-22, /* 0x3B78CC51, 0x60000000 */ < 1.27065575308067607349e-29, /* 0x39F01B83, 0x80000000 */ < 1.22933308981111328932e-36, /* 0x387A2520, 0x40000000 */ < 2.73370053816464559624e-44, /* 0x36E38222, 0x80000000 */ < 2.16741683877804819444e-51, /* 0x3569F31D, 0x00000000 */ --- > private static final double PIo2[] = { > 0x1.921fb4p0, // 1.57079625129699707031e+00 > 0x1.4442dp-24, // 7.54978941586159635335e-08 > 0x1.846988p-48, // 5.39030252995776476554e-15 > 0x1.8cc516p-72, // 3.28200341580791294123e-22 > 0x1.01b838p-96, // 1.27065575308067607349e-29 > 0x1.a25204p-120, // 1.22933308981111328932e-36 > 0x1.382228p-145, // 2.73370053816464559624e-44 > 0x1.9f31dp-169, // 2.16741683877804819444e-51 273a283 > 275,278c285 < zero = 0.0, < one = 1.0, < two24 = 1.67772160000000000000e+07, /* 0x41700000, 0x00000000 */ < twon24 = 5.96046447753906250000e-08; /* 0x3E700000, 0x00000000 */ --- > twon24 = 0x1.0p-24; // 5.96046447753906250000e-08 288c295 < /* initialize jk*/ --- > // initialize jk 292c299 < /* determine jx,jv,q0, note that 3>q0 */ --- > // determine jx, jv, q0, note that 3 > q0 294c301,304 < jv = (e0-3)/24; if(jv<0) jv=0; --- > jv = (e0 - 3)/24; > if (jv < 0) { > jv = 0; > } 297,299c307,312 < /* set up f[0] to f[jx+jk] where f[jx+jk] = ipio2[jv+jk] */ < j = jv-jx; m = jx+jk; < for(i=0;i<=m;i++,j++) f[i] = (j<0)? zero : (double) ipio2[j]; --- > // set up f[0] to f[jx+jk] where f[jx+jk] = ipio2[jv+jk] > j = jv - jx; > m = jx + jk; > for (i = 0; i <= m; i++, j++) { > f[i] = (j < 0) ? 0.0 : (double) ipio2[j]; > } 301c314 < /* compute q[0],q[1],...q[jk] */ --- > // compute q[0],q[1],...q[jk] 303c316,318 < for(j=0,fw=0.0;j<=jx;j++) fw += x[j]*f[jx+i-j]; --- > for(j = 0, fw = 0.0; j <= jx; j++) { > fw += x[j]*f[jx + i - j]; > } 309c324 < /* distill q[] into iq[] reversingly */ --- > // distill q[] into iq[] reversingly 312c327 < iq[i] = (int)(z-two24*fw); --- > iq[i] = (int)(z - TWO24*fw); 316,318c331,333 < /* compute n */ < z = Math.scalb(z,q0); /* actual value of z */ < z -= 8.0*Math.floor(z*0.125); /* trim off integer >= 8 */ --- > // compute n > z = Math.scalb(z, q0); // actual value of z > z -= 8.0*Math.floor(z*0.125); // trim off integer >= 8 322,323c337,339 < if(q0>0) { /* need iq[jz-1] to determine n */ < i = (iq[jz-1]>>(24-q0)); n += i; --- > if (q0 > 0) { // need iq[jz - 1] to determine n > i = (iq[jz - 1] >> (24 - q0)); > n += i; 325a342,345 > } else if (q0 == 0) { > ih = iq[jz-1]>>23; > } else if (z >= 0.5) { > ih=2; 327,328d346 < else if(q0==0) ih = iq[jz-1]>>23; < else if(z>=0.5) ih=2; 330,332c348,351 < if(ih>0) { /* q > 0.5 */ < n += 1; carry = 0; < for(i=0;i if ( ih > 0) { // q > 0.5 > n += 1; > carry = 0; > for (i=0; i < jz; i++) { // compute 1-q 336c355,356 < carry = 1; iq[i] = 0x1000000- j; --- > carry = 1; > iq[i] = 0x100_0000 - j; 338c358,359 < } else iq[i] = 0xffffff - j; --- > } else { > iq[i] = 0xff_ffff - j; 340c361,362 < if(q0>0) { /* rare case: chance is 1 in 12 */ --- > } > if (q0 > 0) { // rare case: chance is 1 in 12 343c365,366 < iq[jz-1] &= 0x7fffff; break; --- > iq[jz-1] &= 0x7f_ffff; > break; 345c368,369 < iq[jz-1] &= 0x3fffff; break; --- > iq[jz-1] &= 0x3f_ffff; > break; 349,350c373,376 < z = one - z; < if(carry!=0) z -= Math.scalb(one,q0); --- > z = 1.0 - z; > if (carry != 0) { > z -= Math.scalb(1.0, q0); > } 354,355c380,381 < /* check if recomputation is needed */ < if(z==zero) { --- > // check if recomputation is needed > if (z == 0.0) { 357,359c383,387 < for (i=jz-1;i>=jk;i--) j |= iq[i]; < if(j==0) { /* need recomputation */ < for(k=1;iq[jk-k]==0;k++); /* k = no. of terms needed */ --- > for (i = jz - 1; i >= jk; i--) { > j |= iq[i]; > } > if (j == 0) { // need recomputation > for(k=1; iq[jk - k] == 0; k++); // k = no. of terms needed 361c389 < for(i=jz+1;i<=jz+k;i++) { /* add q[jz+1] to q[jz+k] */ --- > for(i = jz + 1; i <= jz + k; i++) { // add q[jz+1] to q[jz+k] 363c391,393 < for(j=0,fw=0.0;j<=jx;j++) fw += x[j]*f[jx+i-j]; --- > for (j=0, fw = 0.0; j <= jx; j++) { > fw += x[j]*f[jx + i - j]; > } 368,369c398,403 < } else { break;} < } else {break;} --- > } else { > break; > } > } else { > break; > } 372c406 < /* chop off zero terms */ --- > // chop off zero terms 374,376c408,414 < jz -= 1; q0 -= 24; < while(iq[jz]==0) { jz--; q0-=24;} < } else { /* break z into 24-bit if necessary */ --- > jz -= 1; > q0 -= 24; > while (iq[jz] == 0) { > jz--; > q0-=24; > } > } else { // break z into 24-bit if necessary 378c416 < if(z>=two24) { --- > if (z >= TWO24) { 380,381c418,420 < iq[jz] = (int)(z-two24*fw); < jz += 1; q0 += 24; --- > iq[jz] = (int)(z - TWO24*fw); > jz += 1; > q0 += 24; 383c422,424 < } else iq[jz] = (int) z ; --- > } else { > iq[jz] = (int) z; > } 386,387c427,428 < /* convert integer "bit" chunk to floating-point value */ < fw = Math.scalb(one,q0); --- > // convert integer "bit" chunk to floating-point value > fw = Math.scalb(1.0, q0); 389c430,431 < q[i] = fw*(double)iq[i]; fw*=twon24; --- > q[i] = fw*(double)iq[i]; > fw *= twon24; 392c434 < /* compute PIo2[0,...,jp]*q[jz,...,0] */ --- > // compute PIo2[0,...,jp]*q[jz,...,0] 394c436,438 < for(fw=0.0,k=0;k<=jp&&k<=jz-i;k++) fw += PIo2[k]*q[i+k]; --- > for (fw = 0.0, k = 0; k <= jp && k <= jz-i; k++) { > fw += PIo2[k]*q[i + k]; > } 398c442 < /* compress fq[] into y[] */ --- > // compress fq[] into y[] 402c446,448 < for (i=jz;i>=0;i--) fw += fq[i]; --- > for (i = jz; i >=0; i--) { > fw += fq[i]; > } 408c454,456 < for (i=jz;i>=0;i--) fw += fq[i]; --- > for (i = jz; i>=0; i--) { > fw += fq[i]; > } 411c459,461 < for (i=1;i<=jz;i++) fw += fq[i]; --- > for (i = 1; i <= jz; i++) { > fw += fq[i]; > } 414c464 < case 3: /* painful */ --- > case 3: // painful 425c475,477 < for (fw=0.0,i=jz;i>=2;i--) fw += fq[i]; --- > for (fw = 0.0, i = jz; i >= 2; i--) { > fw += fq[i]; > } 427c479,481 < y[0] = fq[0]; y[1] = fq[1]; y[2] = fw; --- > y[0] = fq[0]; > y[1] = fq[1]; > y[2] = fw; 429c483,485 < y[0] = -fq[0]; y[1] = -fq[1]; y[2] = -fw; --- > y[0] = -fq[0]; > y[1] = -fq[1]; > y[2] = -fw; ------------- PR: https://git.openjdk.org/jdk/pull/12800 From mdoerr at openjdk.org Wed Mar 1 06:28:12 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 1 Mar 2023 06:28:12 GMT Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function & Memory API (Preview) [v3] In-Reply-To: References: <8b3vVrV22RuhdRoRYacXV0ZeghFGgKkC8S_z-iMrzAQ=.dd84b743-8b51-4281-8f5f-f9eff6207bc7@github.com> Message-ID: On Tue, 28 Feb 2023 20:00:15 GMT, Jorn Vernee wrote: >> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove size restriction for structs. Add TODO for Big Endian. > > src/hotspot/cpu/ppc/upcallLinker_ppc.cpp line 240: > >> 238: __ ld(call_target_address, in_bytes(Method::from_compiled_offset()), R19_method); >> 239: __ mtctr(call_target_address); >> 240: __ bctrl(); > > Ok, I see. I guess there is some special purpose register called `CTR` which we are moving to for `bctrl` here. Does ABIv2 require that move to always come from `R12`? (from the comment in downcallLinker). > > (I'm trying to understand the requirements for possibly tweaking shared code). There's no instruction which can use a GP reg as branch target directly. That's why we use CTR. In this case, using R12 is not required since we call Java and our PPC64 VM code does not rely on it. If we were calling C, using R12 would be required by ABI v2. > src/hotspot/cpu/ppc/upcallLinker_ppc.cpp line 347: > >> 345: FunctionDescriptor* fd = (FunctionDescriptor*)fd_addr; >> 346: fd->set_entry(fd_addr + sizeof(FunctionDescriptor)); >> 347: #endif > > Had to do a double take. Looks like we're not the only one who are using the name `FunctionDescriptor` :) Yeah, ABI v1 (Big Endian) treats function pointers as pointers to a structure called `FunctionDescriptor` which contains the entry point plus additional information like a pointer to a constant table. > src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/CallArranger.java line 286: > >> 284: // "no partial DW rule": Mark first stack slot to get filled. >> 285: // Note: Can only happen with forArguments = true. >> 286: VMStorage overlappingReg = null; > > `overlappingReg` is initialized along all branches, so it's not needed to assign `null` here (and then javac will check it is actually assigned before use) Removed. > src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/TypeClass.java line 66: > >> 64: } >> 65: >> 66: static boolean isHomogeneousFloatAggregate(MemoryLayout type, boolean useABIv2) { > > Note that we had to make some changes to this routine on AArch64, since it didn't properly account for nested structs/unions and arrays. See: https://github.com/openjdk/panama-foreign/pull/780 > > Just as a heads up, in case PPC needs changes too. Thanks for the hint! I just added the code since it is known to be needed, small and doesn't break any of the existing tests. I'll need to test and possibly debug the various cases, yet. ------------- PR: https://git.openjdk.org/jdk/pull/12708 From duke at openjdk.org Wed Mar 1 06:34:20 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Wed, 1 Mar 2023 06:34:20 GMT Subject: RFR: 8303401: Add a Vector API equalsIgnoreCase micro benchmark [v4] In-Reply-To: References: Message-ID: <5oJ3HxFmKNnnvE2pZgWJaUQT1_g6HruzFCAp26KLc1g=.001057ce-1a44-4c53-83e1-acd8e8f61c5b@github.com> > This PR suggests we add a vectorized equalsIgnoreCase benchmark to the set of benchmarks in `org.openjdk.bench.jdk.incubator.vector`. This benchmark serves as an example of how vectorization can be useful also in the area of text processing. It takes advantage of the fact that ASCII and Latin-1 were designed to optimize case-twiddling operations. > > The code came about during the work on #12632, where vectorization was deemed out of scope. > > Benchmark results: > > > Benchmark (size) Mode Cnt Score Error Units > EqualsIgnoreCaseBenchmark.scalar 16 avgt 15 20.671 ? 0.718 ns/op > EqualsIgnoreCaseBenchmark.scalar 32 avgt 15 46.155 ? 3.258 ns/op > EqualsIgnoreCaseBenchmark.scalar 64 avgt 15 68.248 ? 1.767 ns/op > EqualsIgnoreCaseBenchmark.scalar 128 avgt 15 148.948 ? 0.890 ns/op > EqualsIgnoreCaseBenchmark.scalar 1024 avgt 15 1090.708 ? 7.540 ns/op > EqualsIgnoreCaseBenchmark.vectorized 16 avgt 15 21.872 ? 0.232 ns/op > EqualsIgnoreCaseBenchmark.vectorized 32 avgt 15 11.378 ? 0.097 ns/op > EqualsIgnoreCaseBenchmark.vectorized 64 avgt 15 13.703 ? 0.135 ns/op > EqualsIgnoreCaseBenchmark.vectorized 128 avgt 15 21.632 ? 0.735 ns/op > EqualsIgnoreCaseBenchmark.vectorized 1024 avgt 15 105.509 ? 7.493 ns/op Eirik Bjorsnos has updated the pull request incrementally with two additional commits since the last revision: - Adjust whitespace as suggested in review - Replace Blackhold.consume with return values ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12790/files - new: https://git.openjdk.org/jdk/pull/12790/files/6bc04db0..00253baa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12790&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12790&range=02-03 Stats: 7 lines in 1 file changed: 1 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/12790.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12790/head:pull/12790 PR: https://git.openjdk.org/jdk/pull/12790 From duke at openjdk.org Wed Mar 1 06:34:23 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Wed, 1 Mar 2023 06:34:23 GMT Subject: RFR: 8303401: Add a Vector API equalsIgnoreCase micro benchmark [v4] In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 02:32:23 GMT, Xiaohong Gong wrote: >> Eirik Bjorsnos has updated the pull request incrementally with two additional commits since the last revision: >> >> - Adjust whitespace as suggested in review >> - Replace Blackhold.consume with return values > > test/micro/org/openjdk/bench/jdk/incubator/vector/EqualsIgnoreCaseBenchmark.java line 61: > >> 59: len = a.length; >> 60: } >> 61: @Benchmark > > Style: Insert one blank line between line 60-61? I have inserted a new line. Thanks for your close reading! > test/micro/org/openjdk/bench/jdk/incubator/vector/EqualsIgnoreCaseBenchmark.java line 124: > >> 122: } >> 123: >> 124: public boolean scalarEqualsIgnoreCase(byte[] a, byte[] b, int len) { > > Style: remove one more space between "`public boolean`" please? Extra space removed. > test/micro/org/openjdk/bench/jdk/incubator/vector/EqualsIgnoreCaseBenchmark.java line 147: > >> 145: return false; // Low ASCII >> 146: } >> 147: return ( U <= 'Z' // In range A-Z > > Style: remove one more space between `( U` please? Thanks, removed the extra space. ------------- PR: https://git.openjdk.org/jdk/pull/12790 From duke at openjdk.org Wed Mar 1 06:34:27 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Wed, 1 Mar 2023 06:34:27 GMT Subject: RFR: 8303401: Add a Vector API equalsIgnoreCase micro benchmark [v3] In-Reply-To: <9-AO2GbDnVHYorecmrS9E_taG8k1cSDlKh1EkP9pyGI=.ac709e82-647c-4684-915b-fd783441200c@github.com> References: <9-AO2GbDnVHYorecmrS9E_taG8k1cSDlKh1EkP9pyGI=.ac709e82-647c-4684-915b-fd783441200c@github.com> Message-ID: <0yiOKutQGYnYmt78DkGqEE3hCUlTmHNxVs4f6Fw4U7w=.7cb522ca-a866-4e56-87d2-993a07948cdb@github.com> On Tue, 28 Feb 2023 23:55:52 GMT, Paul Sandoz wrote: >> Eirik Bjorsnos has updated the pull request incrementally with two additional commits since the last revision: >> >> - Uppercase Thorn is 0xDE >> - Update 'a' to 'A' and 'z' to 'Z' in comments > > test/micro/org/openjdk/bench/jdk/incubator/vector/EqualsIgnoreCaseBenchmark.java line 67: > >> 65: public void scalar(Blackhole blackhole) { >> 66: blackhole.consume(scalarEqualsIgnoreCase(a, b, len)); >> 67: } > > If you like there is no need to explicitly use a black hole, instead declare the benchmark method to return `boolean` and return the result of the call. JMH will do the right thing. I find that a little more concise and easier to read. This was much cleaner, thank you! ------------- PR: https://git.openjdk.org/jdk/pull/12790 From mdoerr at openjdk.org Wed Mar 1 06:41:09 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 1 Mar 2023 06:41:09 GMT Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function & Memory API (Preview) [v3] In-Reply-To: References: <8b3vVrV22RuhdRoRYacXV0ZeghFGgKkC8S_z-iMrzAQ=.dd84b743-8b51-4281-8f5f-f9eff6207bc7@github.com> Message-ID: On Fri, 24 Feb 2023 07:17:30 GMT, Jorn Vernee wrote: >> Some more remarks about other issues: >> - Uploaded my simple reproducer to [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017) >> - Using oversized load / stores is problematic. Don't forget that OpenJDK still supports Big Endian platforms (AIX, s390x). >> - The result of `NativeCallingConvention::calling_convention` is interpreted as size, but it returns the max offset. That's off by one slot. Should I file a bug for that? (PPC64 is not affected because it doesn't use the result.) >> - Since the membar on the return path was mentioned: I think it would be good to enable UseSystemMemoryBarrier by default on operating systems which support it. Maybe we should discuss this with @robehn. > >> * Uploaded my simple reproducer to [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017) > > Thanks! > >> * Using oversized load / stores is problematic. Don't forget that OpenJDK still supports Big Endian platforms (AIX, s390x). > > You're right. I realized that it's also problematic for heap segments, for which we can't do oversized accesses. I am working on another solution that splits up the loads/stores into power-of-two sized chunks: https://github.com/openjdk/panama-foreign/compare/foreign-memaccess+abi...JornVernee:panama-foreign:OOB That patch is just a POC at this point though. Also, I don't think it works for BE at the moment (need to flip the offset for BE, I think. Just like we do in Unsafe). > >> * The result of `NativeCallingConvention::calling_convention` is interpreted as size, but it returns the max offset. That's off by one slot. Should I file a bug for that? (PPC64 is not affected because it doesn't use the result.) > > I'm not sure there's an issue there. Note that the 'max offset' is computed as `reg.offset() + reg.stack_size()`, so that should get us the size we need to allocate for the stack arguments. (e.g. 2 ints being passed at offset 0 and 4, would make max offset 4 + 4 = 8, which gives the size needed for the 2 ints). Computing the max offset instead of just summing the sizes of the stack arguments is needed since stack arguments can be sparsely placed in some cases on Mac/AArch64. > >> * Since the membar on the return path was mentioned: I think it would be good to enable UseSystemMemoryBarrier by default on operating systems which support it. Maybe we should discuss this with @robehn. > > ~I don't think we've done that much testing with UseSystemMemoryBarrier since it was added~. I'm a bit nervous about turning it on by default since it's currently also used for JNI. Let's see what Robbin thinks. @JornVernee: Thanks a lot for your detailed review! I have quite a few TODOs which include: - Include my tests for the HFA corner cases. - Try to improve handling of the overlapping registers as you suggested. - Check nesting of HFA. There will surely be more when looking into Big Endian support after merging with your recent work on https://github.com/openjdk/panama-foreign/compare/foreign-memaccess+abi...JornVernee:panama-foreign:OOB We should get rid of oversized accesses on PPC64, too. Thanks for sharing your plans to intrisify `linkToNative` in C2 later. I guess we should do more preparation work on all platforms when that gets addressed. ------------- PR: https://git.openjdk.org/jdk/pull/12708 From duke at openjdk.org Wed Mar 1 06:43:05 2023 From: duke at openjdk.org (Xiaowei Lu) Date: Wed, 1 Mar 2023 06:43:05 GMT Subject: RFR: 8302204: Optimize BigDecimal.divide In-Reply-To: References: <33muq0xW2ZRW13PAjRpOFAMFC2e1iZ_pR_4SXupx7pk=.02db719e-4919-43b8-a6ca-b87e115007f9@github.com> Message-ID: On Fri, 17 Feb 2023 15:24:26 GMT, Raffaello Giulietti wrote: >>> After making sure that `intVal` is even, and before attempting a division by a power of 10, it might help to check if 5 divides `intVal` in the first place. If it doesn't, there no point in performing the division. >>> >>> It can be shown that 5 divides `intVal` if and only if it divides the `long` sum of all `int`s in the `mag` array of `intVal`. >>> >>> I didn't try out if this contributes to improve the overall performance, but it might be worth giving a try. >> >> Unfortunately, it seems this division by 5 doesn't give an obvious performance improvement. Maybe previous lowest bit check has filtered some cases. > >> > After making sure that `intVal` is even, and before attempting a division by a power of 10, it might help to check if 5 divides `intVal` in the first place. If it doesn't, there no point in performing the division. >> > It can be shown that 5 divides `intVal` if and only if it divides the `long` sum of all `int`s in the `mag` array of `intVal`. >> > I didn't try out if this contributes to improve the overall performance, but it might be worth giving a try. >> >> Unfortunately, it seems this division by 5 doesn't give an obvious performance improvement. Maybe previous lowest bit check has filtered some cases. > > Thanks for trying out. @rgiulietti Hi, could you please review this pr ------------- PR: https://git.openjdk.org/jdk/pull/12509 From duke at openjdk.org Wed Mar 1 07:08:24 2023 From: duke at openjdk.org (Ravali Yatham) Date: Wed, 1 Mar 2023 07:08:24 GMT Subject: RFR: 8302791: Add specific ClassLoader object to Proxy IllegalArgumentException message [v2] In-Reply-To: References: Message-ID: > Added specific class loader object to proxy IllegalArgumentException from which the class was not visible > > The bug report for the same: https://bugs.openjdk.org/browse/JDK-8302791 Ravali Yatham has updated the pull request incrementally with one additional commit since the last revision: Use classloaderName if not Null otherwise Objects.toIdentityString(ld) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12641/files - new: https://git.openjdk.org/jdk/pull/12641/files/1ed3c72d..2682d88c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12641&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12641&range=00-01 Stats: 9 lines in 1 file changed: 8 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12641.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12641/head:pull/12641 PR: https://git.openjdk.org/jdk/pull/12641 From duke at openjdk.org Wed Mar 1 07:13:41 2023 From: duke at openjdk.org (Ravali Yatham) Date: Wed, 1 Mar 2023 07:13:41 GMT Subject: RFR: 8302791: Add specific ClassLoader object to Proxy IllegalArgumentException message [v3] In-Reply-To: References: Message-ID: > Added specific class loader object to proxy IllegalArgumentException from which the class was not visible > > The bug report for the same: https://bugs.openjdk.org/browse/JDK-8302791 Ravali Yatham has updated the pull request incrementally with one additional commit since the last revision: Fix Indentation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12641/files - new: https://git.openjdk.org/jdk/pull/12641/files/2682d88c..c2516408 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12641&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12641&range=01-02 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/12641.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12641/head:pull/12641 PR: https://git.openjdk.org/jdk/pull/12641 From duke at openjdk.org Wed Mar 1 07:16:07 2023 From: duke at openjdk.org (Ravali Yatham) Date: Wed, 1 Mar 2023 07:16:07 GMT Subject: RFR: 8302791: Add specific ClassLoader object to Proxy IllegalArgumentException message [v3] In-Reply-To: References: Message-ID: On Wed, 22 Feb 2023 07:24:48 GMT, Alan Bateman wrote: >> Ravali Yatham has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix Indentation > > src/java.base/share/classes/java/lang/reflect/Proxy.java line 881: > >> 879: if (type != c) { >> 880: throw new IllegalArgumentException(c.getName() + >> 881: " referenced from a method is not visible from class loader: " + ld); > > The ClassLoader string representation may or may not be useful here. One suggestion is to use the class loader name (ld.getName()) if not null, otherwise Objects.toIdentityString(ld). @AlanBateman @mlchung - Thanks for reviewing. I've incorporated review comments wherein using `@` if not null, otherwise `Objects.toIdentityString(ld)`. PTAL. ------------- PR: https://git.openjdk.org/jdk/pull/12641 From duke at openjdk.org Wed Mar 1 08:25:47 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Wed, 1 Mar 2023 08:25:47 GMT Subject: RFR: 8303401: Add a Vector API equalsIgnoreCase micro benchmark [v5] In-Reply-To: References: Message-ID: > This PR suggests we add a vectorized equalsIgnoreCase benchmark to the set of benchmarks in `org.openjdk.bench.jdk.incubator.vector`. This benchmark serves as an example of how vectorization can be useful also in the area of text processing. It takes advantage of the fact that ASCII and Latin-1 were designed to optimize case-twiddling operations. > > The code came about during the work on #12632, where vectorization was deemed out of scope. > > Benchmark results: > > > Benchmark (size) Mode Cnt Score Error Units > EqualsIgnoreCaseBenchmark.scalar 16 avgt 15 20.671 ? 0.718 ns/op > EqualsIgnoreCaseBenchmark.scalar 32 avgt 15 46.155 ? 3.258 ns/op > EqualsIgnoreCaseBenchmark.scalar 64 avgt 15 68.248 ? 1.767 ns/op > EqualsIgnoreCaseBenchmark.scalar 128 avgt 15 148.948 ? 0.890 ns/op > EqualsIgnoreCaseBenchmark.scalar 1024 avgt 15 1090.708 ? 7.540 ns/op > EqualsIgnoreCaseBenchmark.vectorized 16 avgt 15 21.872 ? 0.232 ns/op > EqualsIgnoreCaseBenchmark.vectorized 32 avgt 15 11.378 ? 0.097 ns/op > EqualsIgnoreCaseBenchmark.vectorized 64 avgt 15 13.703 ? 0.135 ns/op > EqualsIgnoreCaseBenchmark.vectorized 128 avgt 15 21.632 ? 0.735 ns/op > EqualsIgnoreCaseBenchmark.vectorized 1024 avgt 15 105.509 ? 7.493 ns/op Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision: The equal.allTrue() condition is already checked at the beginning of the loop, we could simplify equalsIgnoreCase to not consider this. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12790/files - new: https://git.openjdk.org/jdk/pull/12790/files/00253baa..0e549caa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12790&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12790&range=03-04 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/12790.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12790/head:pull/12790 PR: https://git.openjdk.org/jdk/pull/12790 From duke at openjdk.org Wed Mar 1 08:27:09 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Wed, 1 Mar 2023 08:27:09 GMT Subject: RFR: 8303401: Add a Vector API equalsIgnoreCase micro benchmark [v4] In-Reply-To: <5oJ3HxFmKNnnvE2pZgWJaUQT1_g6HruzFCAp26KLc1g=.001057ce-1a44-4c53-83e1-acd8e8f61c5b@github.com> References: <5oJ3HxFmKNnnvE2pZgWJaUQT1_g6HruzFCAp26KLc1g=.001057ce-1a44-4c53-83e1-acd8e8f61c5b@github.com> Message-ID: <6JfhoRKVnkIf-T96zZKFOmXyB_E7u3zo09fc-R0nmTw=.63b654d3-bfca-47d6-a23d-4670f59f30ed@github.com> On Wed, 1 Mar 2023 06:34:20 GMT, Eirik Bjorsnos wrote: >> This PR suggests we add a vectorized equalsIgnoreCase benchmark to the set of benchmarks in `org.openjdk.bench.jdk.incubator.vector`. This benchmark serves as an example of how vectorization can be useful also in the area of text processing. It takes advantage of the fact that ASCII and Latin-1 were designed to optimize case-twiddling operations. >> >> The code came about during the work on #12632, where vectorization was deemed out of scope. >> >> Benchmark results: >> >> >> Benchmark (size) Mode Cnt Score Error Units >> EqualsIgnoreCaseBenchmark.scalar 16 avgt 15 20.671 ? 0.718 ns/op >> EqualsIgnoreCaseBenchmark.scalar 32 avgt 15 46.155 ? 3.258 ns/op >> EqualsIgnoreCaseBenchmark.scalar 64 avgt 15 68.248 ? 1.767 ns/op >> EqualsIgnoreCaseBenchmark.scalar 128 avgt 15 148.948 ? 0.890 ns/op >> EqualsIgnoreCaseBenchmark.scalar 1024 avgt 15 1090.708 ? 7.540 ns/op >> EqualsIgnoreCaseBenchmark.vectorized 16 avgt 15 21.872 ? 0.232 ns/op >> EqualsIgnoreCaseBenchmark.vectorized 32 avgt 15 11.378 ? 0.097 ns/op >> EqualsIgnoreCaseBenchmark.vectorized 64 avgt 15 13.703 ? 0.135 ns/op >> EqualsIgnoreCaseBenchmark.vectorized 128 avgt 15 21.632 ? 0.735 ns/op >> EqualsIgnoreCaseBenchmark.vectorized 1024 avgt 15 105.509 ? 7.493 ns/op > > Eirik Bjorsnos has updated the pull request incrementally with two additional commits since the last revision: > > - Adjust whitespace as suggested in review > - Replace Blackhold.consume with return values I realized that the `equal.allTrue()` condition is checked early in the loop, so there is no need to include the `equal` in the `equalsIgnoreCase` towards the end the loop. Removing it also gives a small performance improvement: Before: Benchmark (size) Mode Cnt Score Error Units EqualsIgnoreCaseBenchmark.vectorized 1024 avgt 15 123.753 ? 1.405 ns/op After: Benchmark (size) Mode Cnt Score Error Units EqualsIgnoreCaseBenchmark.vectorized 1024 avgt 15 118.578 ? 1.960 ns/op ------------- PR: https://git.openjdk.org/jdk/pull/12790 From aturbanov at openjdk.org Wed Mar 1 08:53:11 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Wed, 1 Mar 2023 08:53:11 GMT Subject: RFR: JDK-8302027: Port fdlibm trig functions (sin, cos, tan) to Java In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 05:28:34 GMT, Joe Darcy wrote: > Last and certainly not least in the port of FDLIBM to Java, the transcendental methods for sin, cos, and tan. > > Some more tests are to be written in the StrictMath directory to verify that the StrictMath algorihtm for sin/cos/tan is being used rather than a different one. However, I wanted to get the rest of the change out for review first. > > The sin/cos/tan methods are grouped together since they share the same argument reduction logic. Argument reduction is the process of mapping an argument of a function to an argument in a restricted range (and possibly returning some function of the reduced argument). For sin, cos, and tan, since they are fundamentally periodic with respect to a multiple of pi, argument reduction is done to find the remainder of the original argument with respect to pi/2. src/java.base/share/classes/java/lang/FdLibm.java line 519: > 517: // compute -1.0/(x + r) accurately > 518: double a,t; > 519: z = w; Suggestion: z = w; src/java.base/share/classes/java/lang/FdLibm.java line 521: > 519: z = w; > 520: z = __LO(z, 0); > 521: v = r - (z - x); // z + v = r + x Suggestion: v = r - (z - x); // z + v = r + x src/java.base/share/classes/java/lang/FdLibm.java line 524: > 522: t = a = -1.0/w; // a = -1.0/w > 523: t = __LO(t, 0); > 524: s = 1.0 + t*z; Suggestion: s = 1.0 + t*z; src/java.base/share/classes/java/lang/FdLibm.java line 641: > 639: w = fn*pio2_3; > 640: r = t - w; > 641: w = fn*pio2_3t - ((t - r) - w); let's either align assignments with following `y[0] = r - w;` or remove redundant space before `=` src/java.base/share/classes/java/lang/FdLibm.java line 664: > 662: // set z = scalbn(|x|,ilogb(x)-23) > 663: z = __LO(z, __LO(x)); > 664: e0 = (ix >> 20) - 1046; /* e0 = ilogb(z)-23; */ Suggestion: e0 = (ix >> 20) - 1046; /* e0 = ilogb(z)-23; */ ------------- PR: https://git.openjdk.org/jdk/pull/12800 From duke at openjdk.org Wed Mar 1 09:10:47 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Wed, 1 Mar 2023 09:10:47 GMT Subject: RFR: 8303401: Add a Vector API equalsIgnoreCase micro benchmark [v6] In-Reply-To: References: Message-ID: > This PR suggests we add a vectorized equalsIgnoreCase benchmark to the set of benchmarks in `org.openjdk.bench.jdk.incubator.vector`. This benchmark serves as an example of how vectorization can be useful also in the area of text processing. It takes advantage of the fact that ASCII and Latin-1 were designed to optimize case-twiddling operations. > > The code came about during the work on #12632, where vectorization was deemed out of scope. > > Benchmark results: > > > Benchmark (size) Mode Cnt Score Error Units > EqualsIgnoreCaseBenchmark.scalar 16 avgt 15 20.671 ? 0.718 ns/op > EqualsIgnoreCaseBenchmark.scalar 32 avgt 15 46.155 ? 3.258 ns/op > EqualsIgnoreCaseBenchmark.scalar 64 avgt 15 68.248 ? 1.767 ns/op > EqualsIgnoreCaseBenchmark.scalar 128 avgt 15 148.948 ? 0.890 ns/op > EqualsIgnoreCaseBenchmark.scalar 1024 avgt 15 1090.708 ? 7.540 ns/op > EqualsIgnoreCaseBenchmark.vectorized 16 avgt 15 21.872 ? 0.232 ns/op > EqualsIgnoreCaseBenchmark.vectorized 32 avgt 15 11.378 ? 0.097 ns/op > EqualsIgnoreCaseBenchmark.vectorized 64 avgt 15 13.703 ? 0.135 ns/op > EqualsIgnoreCaseBenchmark.vectorized 128 avgt 15 21.632 ? 0.735 ns/op > EqualsIgnoreCaseBenchmark.vectorized 1024 avgt 15 105.509 ? 7.493 ns/op Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision: The equal.allTrue check early if the loop does not cover cases where some bytes are equal, but not all. Reverting this change. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12790/files - new: https://git.openjdk.org/jdk/pull/12790/files/0e549caa..0272740c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12790&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12790&range=04-05 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/12790.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12790/head:pull/12790 PR: https://git.openjdk.org/jdk/pull/12790 From duke at openjdk.org Wed Mar 1 09:32:28 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Wed, 1 Mar 2023 09:32:28 GMT Subject: RFR: 8303401: Add a Vector API equalsIgnoreCase micro benchmark [v6] In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 09:10:47 GMT, Eirik Bjorsnos wrote: >> This PR suggests we add a vectorized equalsIgnoreCase benchmark to the set of benchmarks in `org.openjdk.bench.jdk.incubator.vector`. This benchmark serves as an example of how vectorization can be useful also in the area of text processing. It takes advantage of the fact that ASCII and Latin-1 were designed to optimize case-twiddling operations. >> >> The code came about during the work on #12632, where vectorization was deemed out of scope. >> >> Benchmark results: >> >> >> Benchmark (size) Mode Cnt Score Error Units >> EqualsIgnoreCaseBenchmark.scalar 16 avgt 15 20.671 ? 0.718 ns/op >> EqualsIgnoreCaseBenchmark.scalar 32 avgt 15 46.155 ? 3.258 ns/op >> EqualsIgnoreCaseBenchmark.scalar 64 avgt 15 68.248 ? 1.767 ns/op >> EqualsIgnoreCaseBenchmark.scalar 128 avgt 15 148.948 ? 0.890 ns/op >> EqualsIgnoreCaseBenchmark.scalar 1024 avgt 15 1090.708 ? 7.540 ns/op >> EqualsIgnoreCaseBenchmark.vectorized 16 avgt 15 21.872 ? 0.232 ns/op >> EqualsIgnoreCaseBenchmark.vectorized 32 avgt 15 11.378 ? 0.097 ns/op >> EqualsIgnoreCaseBenchmark.vectorized 64 avgt 15 13.703 ? 0.135 ns/op >> EqualsIgnoreCaseBenchmark.vectorized 128 avgt 15 21.632 ? 0.735 ns/op >> EqualsIgnoreCaseBenchmark.vectorized 1024 avgt 15 105.509 ? 7.493 ns/op > > Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision: > > The equal.allTrue check early if the loop does not cover cases where some bytes are equal, but not all. Reverting this change. While using the compare method with the GT/GE/NE operators allows for cleaner code, it also seems to come with a significant performance penalty. Is this to be expected? Before, using lt, not: Benchmark (size) Mode Cnt Score Error Units EqualsIgnoreCaseBenchmark.vectorized 1024 avgt 15 98.903 ? 1.508 ns/op After, using compare with LE, GE, NE: Benchmark (size) Mode Cnt Score Error Units EqualsIgnoreCaseBenchmark.vectorized 1024 avgt 15 119.723 ? 2.903 ns/op The lt, not version: // Determine which bytes represent ASCII or Latin-1 letters: VectorMask asciiLetter = upperA.lt((byte) '[').and(upperA.lt((byte) '@').not()); VectorMask lat1Letter = upperA .lt((byte) 0xDF) // <= Thorn .and(upperA.lt((byte) 0XBF).not()) // >= A-grave .and(upperA.eq((byte) 0xD7).not()); // Excluding multiplication And the LE, GE, NE version: // Determine which bytes represent ASCII or Latin-1 letters: VectorMask asciiLetter = upperA.compare(GE, (byte) 'A') // >= 'A' .and(upperA.compare(LE, (byte) 'Z')); // <= 'Z' VectorMask lat1Letter = upperA.compare(GE, (byte) 0XC0) // >= A-grave .and(upperA.compare(LE, (byte) 0xDE)) // <= Thorn .and(upperA.compare(NE, (byte) 0xD7)); // Excluding multiplication ------------- PR: https://git.openjdk.org/jdk/pull/12790 From asotona at openjdk.org Wed Mar 1 09:33:32 2023 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 1 Mar 2023 09:33:32 GMT Subject: RFR: 8294982: Implementation of Classfile API [v29] In-Reply-To: References: Message-ID: > This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. > > Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. > > Classfile API development is tracked at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch > > Development branch of consolidated JDK class files parsing, generating, and transforming is at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch > > Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. > > Please take you time to review this non-trivial JDK addition. > > Thank you, > Adam Adam Sotona has updated the pull request incrementally with three additional commits since the last revision: - LabelImpl get/setContextInfo renamed to get/setBCI - removed default constructor from AttributeHolder - InstructionData content moved to CodeImpl ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10982/files - new: https://git.openjdk.org/jdk/pull/10982/files/58c9d2c0..f6c65616 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=28 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=27-28 Stats: 257 lines in 6 files changed: 62 ins; 168 del; 27 mod Patch: https://git.openjdk.org/jdk/pull/10982.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982 PR: https://git.openjdk.org/jdk/pull/10982 From asotona at openjdk.org Wed Mar 1 09:53:31 2023 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 1 Mar 2023 09:53:31 GMT Subject: RFR: 8294982: Implementation of Classfile API [v30] In-Reply-To: References: Message-ID: > This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. > > Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. > > Classfile API development is tracked at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch > > Development branch of consolidated JDK class files parsing, generating, and transforming is at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch > > Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. > > Please take you time to review this non-trivial JDK addition. > > Thank you, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: javadoc fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10982/files - new: https://git.openjdk.org/jdk/pull/10982/files/f6c65616..212bb04e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=29 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=28-29 Stats: 48 lines in 1 file changed: 17 ins; 0 del; 31 mod Patch: https://git.openjdk.org/jdk/pull/10982.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982 PR: https://git.openjdk.org/jdk/pull/10982 From asotona at openjdk.org Wed Mar 1 09:53:34 2023 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 1 Mar 2023 09:53:34 GMT Subject: RFR: 8294982: Implementation of Classfile API [v20] In-Reply-To: References: Message-ID: On Thu, 16 Feb 2023 11:34:28 GMT, Maurizio Cimadamore wrote: >> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: >> >> added 4-byte Unicode text to Utf8EntryTest > > src/java.base/share/classes/jdk/internal/classfile/components/package-info.java line 97: > >> 95: * {@snippet lang="java" class="PackageSnippets" region="classInstrumentation"} >> 96: */ >> 97: package jdk.internal.classfile.components; > > watch out for newline fixed, thanks. > src/java.base/share/classes/jdk/internal/classfile/impl/TargetInfoImpl.java line 34: > >> 32: >> 33: /** >> 34: * > > Empty javadoc? fixed, thanks. ------------- PR: https://git.openjdk.org/jdk/pull/10982 From asotona at openjdk.org Wed Mar 1 10:04:50 2023 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 1 Mar 2023 10:04:50 GMT Subject: RFR: 8294982: Implementation of Classfile API [v20] In-Reply-To: <01V72lRVYH7rB1NrPpkVKhvj1mksmrelMMTMrHFQ2hk=.4b2c22f3-d9c6-4778-be53-1fb055969f6a@github.com> References: <01V72lRVYH7rB1NrPpkVKhvj1mksmrelMMTMrHFQ2hk=.4b2c22f3-d9c6-4778-be53-1fb055969f6a@github.com> Message-ID: <_XhlEBFkBw3DRlABgN9-H2W_lNkRJY5QdYcxaQPvTp0=.1e46fd7f-9d8a-4da3-91d6-c1658f014f92@github.com> On Thu, 16 Feb 2023 14:58:21 GMT, Maurizio Cimadamore wrote: >> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: >> >> added 4-byte Unicode text to Utf8EntryTest > > src/java.base/share/classes/jdk/internal/classfile/impl/TransformImpl.java line 51: > >> 49: * TransformImpl >> 50: */ >> 51: public class TransformImpl { > > Understanding check: a transform implementation is made up of two runnable (start/end handlers) and a consumer. The consumer can be used e.g. to iterate and transform all the contents of a compound element (e.g. all the instruction in a code attribute). > > User-defined transforms can be "resolved" that is, we can "bind" them to a specific builder, which effectively turns them into consumers (and into a concrete transform implementation that can be used). > > When two transforms T1 and T2 are composed (so that T1 runs before T2), we need to implement the `resolve` method of the resulting transform so that: > * We resolve T2 against the provided builder - this gives us a "downstream" consumer; > * We create a new "chained" builder which wraps the provided builder, and whose `with` method calls the downstream consumer; > * We then resolve T1 against the chained builder, and return the resulting consumer > > This means that when we call `accept` on the resulting consumer, we will transform (using T1) and call `with` (passing the transformed element) on the chained builder, which will end up calling `accept` on the downstream consumer, which will apply T2 and finally add the resulting element to the provided builder. > > Correct? (Phew) Yes, this is how it is designed and implemented. Actually we have only a few real use cases testing this concept, one is a prototype of jdk.jfr class instrumentation at: https://github.com/openjdk/jdk/blob/212bb04e9491badb17c110787727ea19842d1528/test/jdk/jdk/classfile/AdvancedTransformationsTest.java#L293 ------------- PR: https://git.openjdk.org/jdk/pull/10982 From asotona at openjdk.org Wed Mar 1 10:09:06 2023 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 1 Mar 2023 10:09:06 GMT Subject: RFR: 8294982: Implementation of Classfile API [v20] In-Reply-To: <01V72lRVYH7rB1NrPpkVKhvj1mksmrelMMTMrHFQ2hk=.4b2c22f3-d9c6-4778-be53-1fb055969f6a@github.com> References: <01V72lRVYH7rB1NrPpkVKhvj1mksmrelMMTMrHFQ2hk=.4b2c22f3-d9c6-4778-be53-1fb055969f6a@github.com> Message-ID: <579H8pxWFy80yT9bwFjhQNp6UqWhPDIoQM3ykkneoHY=.53f8cf38-6682-483d-8c3b-44a8529533f6@github.com> On Thu, 16 Feb 2023 14:19:12 GMT, Maurizio Cimadamore wrote: >> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: >> >> added 4-byte Unicode text to Utf8EntryTest > > src/java.base/share/classes/jdk/internal/classfile/impl/ChainedFieldBuilder.java line 48: > >> 46: this.consumer = consumer; >> 47: FieldBuilder b = downstream; >> 48: while (b instanceof ChainedFieldBuilder cb) > > I'm probably missing something - but if `b` is another chained builder, instead of using a loop, can't we just skip to its `terminal` field? Also, the `downstream` field seems unused. (same considerations apply for `ChainedMethodBuilder` and `ChainedClassBuilder`). > > I note that `NonTerminalCodeBuilder` seems to be already doing what I suggest here (e.g. skip to `terminal`). I would have to test possible side-effects of the proposed shortcut to give you answer. Thanks for pointing it out. ------------- PR: https://git.openjdk.org/jdk/pull/10982 From duke at openjdk.org Wed Mar 1 10:10:12 2023 From: duke at openjdk.org (Ravali Yatham) Date: Wed, 1 Mar 2023 10:10:12 GMT Subject: RFR: 8302791: Add specific ClassLoader object to Proxy IllegalArgumentException message [v4] In-Reply-To: References: Message-ID: <0jQQEOJWyqjmAP3UgPGk7V1muce0Yx14nWIlBnkOgas=.095d14d8-ee3c-4089-bb62-6f7d1c0100d5@github.com> > Added specific class loader object to proxy IllegalArgumentException from which the class was not visible > > The bug report for the same: https://bugs.openjdk.org/browse/JDK-8302791 Ravali Yatham has updated the pull request incrementally with one additional commit since the last revision: Add comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12641/files - new: https://git.openjdk.org/jdk/pull/12641/files/c2516408..ae442098 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12641&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12641&range=02-03 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/12641.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12641/head:pull/12641 PR: https://git.openjdk.org/jdk/pull/12641 From kasperni at gmail.com Wed Mar 1 10:59:54 2023 From: kasperni at gmail.com (Kasper Nielsen) Date: Wed, 1 Mar 2023 10:59:54 +0000 Subject: 8281301: Map.of() calls with null argument should throw more contextual information. In-Reply-To: <5ba8b22b-4a09-1ee0-6fb2-51b25c186c9e@oracle.com> References: <5ba8b22b-4a09-1ee0-6fb2-51b25c186c9e@oracle.com> Message-ID: I've been in situations as well where a bit more context would have been very useful for some collection NPEs. While lambdas are overkill. I do think there are some more low-level solutions. requireNonNull(k0) can be replaced with with requireNonNull(k0, "key is null"); For the indexed versions we could introduce: public static T requireIndexedNonNull(T obj, int index, String message) { if (obj == null) throw new NullPointerException(message + " is null at index " + index); return obj; } and uses that wherever applicable. /Kasper On Wed, 1 Mar 2023 at 03:41, Stuart Marks wrote: > > > My proposed change is pretty small. Basically, a pattern I see with > > some frequency is calling Objects.requireNonNull(object, "objectName") > > before (or within) Map.of(), because otherwise there's not much of a > > way to tell _which_ parameter caused the exception. Even just an index > > and key/value hint would make tracking down these types of errors > > easier without that bit of boilerplate. > > From rgiulietti at openjdk.org Wed Mar 1 11:02:12 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 1 Mar 2023 11:02:12 GMT Subject: RFR: 8302204: Optimize BigDecimal.divide In-Reply-To: References: <33muq0xW2ZRW13PAjRpOFAMFC2e1iZ_pR_4SXupx7pk=.02db719e-4919-43b8-a6ca-b87e115007f9@github.com> Message-ID: On Wed, 1 Mar 2023 06:40:01 GMT, Xiaowei Lu wrote: >>> > After making sure that `intVal` is even, and before attempting a division by a power of 10, it might help to check if 5 divides `intVal` in the first place. If it doesn't, there no point in performing the division. >>> > It can be shown that 5 divides `intVal` if and only if it divides the `long` sum of all `int`s in the `mag` array of `intVal`. >>> > I didn't try out if this contributes to improve the overall performance, but it might be worth giving a try. >>> >>> Unfortunately, it seems this division by 5 doesn't give an obvious performance improvement. Maybe previous lowest bit check has filtered some cases. >> >> Thanks for trying out. > > @rgiulietti Hi, could you please review this pr @weixlu I'm not an official [reviewer](https://openjdk.org/bylaws#reviewer) ------------- PR: https://git.openjdk.org/jdk/pull/12509 From jpai at openjdk.org Wed Mar 1 11:06:03 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 1 Mar 2023 11:06:03 GMT Subject: RFR: 8303198: System and Runtime.exit() resilience to logging errors In-Reply-To: References: Message-ID: On Mon, 27 Feb 2023 15:41:01 GMT, Roger Riggs wrote: > Consolidate logging and handle exceptions by printing to standard error and ignoring the exception. > Exceptions while logging will not interfere with Runtime.exit. src/java.base/share/classes/java/lang/Shutdown.java line 186: > 184: try { > 185: // Exceptions from the Logger are printed but do not prevent exit > 186: System.err.println("Runtime.exit() logging failed: " + throwable.getMessage()); Hello Roger, do you think including the exit code in this System.err.println message would be useful too? That would then mean that if the Logger failed for whatever reason, this fallback message would at least include the exit code to provide some hints on what might have triggered the exit. ------------- PR: https://git.openjdk.org/jdk/pull/12770 From lancea at openjdk.org Wed Mar 1 11:24:05 2023 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 1 Mar 2023 11:24:05 GMT Subject: RFR: 8303405: fix @returnss typo in ReflectionFactory In-Reply-To: <-0G_v0gBCIwZzCJrCns71VpiwaLRpNvbpmRYVUm_k4U=.3f2f80b3-5c8d-4134-9c0a-79a94ce8678e@github.com> References: <-0G_v0gBCIwZzCJrCns71VpiwaLRpNvbpmRYVUm_k4U=.3f2f80b3-5c8d-4134-9c0a-79a94ce8678e@github.com> Message-ID: <7QfsXM6vZ4dBIauQviv1fsftLMqoLlJLDHuxnVYJBG4=.2d92b184-3fc8-4991-99dc-99ba2e9eed63@github.com> On Wed, 1 Mar 2023 00:24:31 GMT, Justin Lu wrote: > The following typo: `@returnss` was reported on line _482 of Reflection Factory.java_. > > In addition to fixing that, I have replaced multiple instances of `@returns` with `@return` in the same file. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12794 From brett.okken.os at gmail.com Wed Mar 1 12:50:20 2023 From: brett.okken.os at gmail.com (Brett Okken) Date: Wed, 1 Mar 2023 06:50:20 -0600 Subject: UUID creation performance Message-ID: Is there any interest in updating the static UUID.randomUUID() and UUID.nameUUIDFromBytes(byte[]) factory methods to use either a ByteBuffer or byteArrayViewVarHandle to convert the byte[] to 2 long values then do the bit twiddling? These methods are really dominated by time to create/populate the byte[], but this does reduce the time to create the 2 long values by at least half. It would also allow the removal of the private UUID(byte[] data). public static UUID randomUUID() { SecureRandom ng = Holder.numberGenerator; byte[] randomBytes = new byte[16]; ng.nextBytes(randomBytes); final ByteBuffer bb = ByteBuffer.wrap(randomBytes); bb.order(ByteOrder.nativeOrder()); long msb = bb.getLong(); long lsb = bb.getLong(); msb &= 0xFFFFFFFFFFFF0FFFL; /* clear version */ msb |= 0x4000L; /* set to version 4 */ lsb &= 0x3FFFFFFFFFFFFFFFL; /* clear variant */ lsb |= 0x8000000000000000L; /* set to IETF variant */ return new UUID(msb, lsb); } public static UUID nameUUIDFromBytes(byte[] name) { MessageDigest md; try { md = MessageDigest.getInstance("MD5"); } catch (NoSuchAlgorithmException nsae) { throw new InternalError("MD5 not supported", nsae); } byte[] md5Bytes = md.digest(name); // default byte order is BIG_ENDIAN final ByteBuffer bb = ByteBuffer.wrap(md5Bytes); long msb = bb.getLong(); long lsb = bb.getLong(); msb &= 0xFFFFFFFFFFFF0FFFL; /* clear version */ msb |= 0x3000L; /* set to version 3 */ lsb &= 0x3FFFFFFFFFFFFFFFL; /* clear variant */ lsb |= 0x8000000000000000L; /* set to IETF variant */ return new UUID(msb, lsb); } Benchmark Mode Cnt Score Error Units UUIDBenchmark.jdk_name avgt 3 11.885 ? 4.025 ns/op UUIDBenchmark.jdk_random avgt 3 11.656 ? 0.987 ns/op UUIDBenchmark.longs avgt 3 7.618 ? 1.047 ns/op UUIDBenchmark.longs_bb avgt 3 7.755 ? 1.643 ns/op UUIDBenchmark.longs_name avgt 3 8.467 ? 1.784 ns/op UUIDBenchmark.longs_name_bb avgt 3 8.455 ? 1.662 ns/op UUIDBenchmark.randomBytes avgt 3 6.132 ? 0.447 ns/op @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) @Warmup(iterations = 3, time = 2, timeUnit = TimeUnit.SECONDS) @Measurement(iterations = 3, time = 2, timeUnit = TimeUnit.SECONDS) @Fork(1) @State(Scope.Benchmark) public class UUIDBenchmark { private static final VarHandle LONGS_ACCESS = MethodHandles.byteArrayViewVarHandle(long[].class, ByteOrder.nativeOrder()); private static final VarHandle BE_LONGS_ACCESS = MethodHandles.byteArrayViewVarHandle(long[].class, ByteOrder.BIG_ENDIAN); @Benchmark public byte[] randomBytes() { final byte[] bytes = new byte[16]; randomBytes(bytes); return bytes; } @Benchmark public void jdk_random(Blackhole bh) { final byte[] data = new byte[16]; randomBytes(data); data[6] &= 0x0f; /* clear version */ data[6] |= 0x40; /* set to version 4 */ data[8] &= 0x3f; /* clear variant */ data[8] |= 0x80; /* set to IETF variant */ long msb = 0; long lsb = 0; assert data.length == 16 : "data must be 16 bytes in length"; for (int i=0; i<8; i++) msb = (msb << 8) | (data[i] & 0xff); for (int i=8; i<16; i++) lsb = (lsb << 8) | (data[i] & 0xff); bh.consume(msb); bh.consume(lsb); } @Benchmark public void jdk_name(Blackhole bh) { final byte[] md5Bytes = new byte[16]; randomBytes(md5Bytes); md5Bytes[6] &= 0x0f; /* clear version */ md5Bytes[6] |= 0x30; /* set to version 3 */ md5Bytes[8] &= 0x3f; /* clear variant */ md5Bytes[8] |= 0x80; /* set to IETF variant */ long msb = 0; long lsb = 0; assert md5Bytes.length == 16 : "data must be 16 bytes in length"; for (int i=0; i<8; i++) msb = (msb << 8) | (md5Bytes[i] & 0xff); for (int i=8; i<16; i++) lsb = (lsb << 8) | (md5Bytes[i] & 0xff); bh.consume(msb); bh.consume(lsb); } @Benchmark public void longs(Blackhole bh) { final byte[] data = new byte[16]; randomBytes(data); long msb = (long) LONGS_ACCESS.get(data, 0); long lsb = (long) LONGS_ACCESS.get(data, 8); msb &= 0xFFFFFFFFFFFF0FFFL; msb |= 0x4000L; lsb &= 0x3FFFFFFFFFFFFFFFL; lsb |= 0x8000000000000000L; bh.consume(msb); bh.consume(lsb); } @Benchmark public void longs_name(Blackhole bh) { final byte[] data = new byte[16]; randomBytes(data); long msb = (long) BE_LONGS_ACCESS.get(data, 0); long lsb = (long) BE_LONGS_ACCESS.get(data, 8); msb &= 0xFFFFFFFFFFFF0FFFL; msb |= 0x3000L; lsb &= 0x3FFFFFFFFFFFFFFFL; lsb |= 0x8000000000000000L; bh.consume(msb); bh.consume(lsb); } @Benchmark public void longs_bb(Blackhole bh) { final byte[] data = new byte[16]; randomBytes(data); final ByteBuffer bb = ByteBuffer.wrap(data); bb.order(ByteOrder.nativeOrder()); long msb = bb.getLong(); long lsb = bb.getLong(); msb &= 0xFFFFFFFFFFFF0FFFL; msb |= 0x4000L; lsb &= 0x3FFFFFFFFFFFFFFFL; lsb |= 0x8000000000000000L; bh.consume(msb); bh.consume(lsb); } @Benchmark public void longs_name_bb(Blackhole bh) { final byte[] data = new byte[16]; randomBytes(data); final ByteBuffer bb = ByteBuffer.wrap(data); // bb.order(ByteOrder.BIG_ENDIAN); long msb = bb.getLong(); long lsb = bb.getLong(); msb &= 0xFFFFFFFFFFFF0FFFL; msb |= 0x3000L; lsb &= 0x3FFFFFFFFFFFFFFFL; lsb |= 0x8000000000000000L; bh.consume(msb); bh.consume(lsb); } static void randomBytes(byte[] bytes) { ThreadLocalRandom tlr = ThreadLocalRandom.current(); LONGS_ACCESS.set(bytes, 0, tlr.nextLong()); LONGS_ACCESS.set(bytes, 8, tlr.nextLong()); } } From jlaskey at openjdk.org Wed Mar 1 12:54:44 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 1 Mar 2023 12:54:44 GMT Subject: RFR: JDK-8302323 Add repeat methods to StringBuilder/StringBuffer [v5] In-Reply-To: References: Message-ID: > Add the ability to repeatedly append char and CharSequence data to StringBuilder/StringBuffer. Jim Laskey has updated the pull request incrementally with two additional commits since the last revision: - Move @since in subclasses - Move @since ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12728/files - new: https://git.openjdk.org/jdk/pull/12728/files/9a157ce7..34c7948c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12728&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12728&range=03-04 Stats: 18 lines in 3 files changed: 12 ins; 6 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12728.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12728/head:pull/12728 PR: https://git.openjdk.org/jdk/pull/12728 From jlaskey at openjdk.org Wed Mar 1 12:54:44 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 1 Mar 2023 12:54:44 GMT Subject: RFR: JDK-8302323 Add repeat methods to StringBuilder/StringBuffer [v4] In-Reply-To: <3IXNL5BRGeGHKKECeqqMLc3YBCzz-KjbYSJuNVGkAbI=.15d558ef-047e-41a2-a290-e82479ef19c1@github.com> References: <_xWE2kNbPX4koybMJrD8UQDGjU0qX5LVCzKo_o2V-Vs=.aa3615ee-9786-41b5-b2fa-d2da40c35482@github.com> <3IXNL5BRGeGHKKECeqqMLc3YBCzz-KjbYSJuNVGkAbI=.15d558ef-047e-41a2-a290-e82479ef19c1@github.com> Message-ID: <73sFub-j3plFaPP6S8hW-GClt5hpiaCBEVSOiMVlY9M=.d8edf8b4-ac5e-4f46-a320-0056170ba898@github.com> On Tue, 28 Feb 2023 22:08:34 GMT, Roger Riggs wrote: >> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision: >> >> - Remove @throws IndexOutOfBoundsException >> - Change error report to use "is negative" > > src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1835: > >> 1833: * @return a reference to this object. >> 1834: * >> 1835: * @since 21 > > @since should be last / after \throws; here and in the other method added. Changed > src/java.base/share/classes/java/lang/StringBuffer.java line 713: > >> 711: /** >> 712: * @since 21 >> 713: * @throws IllegalArgumentException {@inheritDoc} > > @throws comes before @since here and in StringBuilder. Changed ------------- PR: https://git.openjdk.org/jdk/pull/12728 From jvernee at openjdk.org Wed Mar 1 13:06:09 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 1 Mar 2023 13:06:09 GMT Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function & Memory API (Preview) [v3] In-Reply-To: References: <8b3vVrV22RuhdRoRYacXV0ZeghFGgKkC8S_z-iMrzAQ=.dd84b743-8b51-4281-8f5f-f9eff6207bc7@github.com> Message-ID: On Wed, 1 Mar 2023 06:37:45 GMT, Martin Doerr wrote: > There will surely be more when looking into Big Endian support after merging with your recent work on https://github.com/openjdk/panama-foreign/compare/foreign-memaccess+abi...JornVernee:panama-foreign:OOB I will try to move this into the mainline ahead of the JEP PR (process allowing). As well as another testing coverage patch for nested structs/unions: https://github.com/openjdk/panama-foreign/pull/780. > Thanks for sharing your plans to intrisify linkToNative in C2 later. I guess we should do more preparation work on all platforms when that gets addressed. WRT this: we had intrinsification in the past as well (https://github.com/openjdk/panama-foreign/pull/609), but it was removed since we also removed 'trivial' calls at some point (and then the intrinsics were not used). Now that trivial calls are back on the menu, it might be interesting to look at re-adding intrinsics as well. ------------- PR: https://git.openjdk.org/jdk/pull/12708 From mdoerr at openjdk.org Wed Mar 1 13:06:13 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 1 Mar 2023 13:06:13 GMT Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function & Memory API (Preview) [v3] In-Reply-To: References: <8b3vVrV22RuhdRoRYacXV0ZeghFGgKkC8S_z-iMrzAQ=.dd84b743-8b51-4281-8f5f-f9eff6207bc7@github.com> Message-ID: On Tue, 28 Feb 2023 20:51:50 GMT, Jorn Vernee wrote: >> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove size restriction for structs. Add TODO for Big Endian. > > src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/CallArranger.java line 68: > >> 66: public abstract class CallArranger { >> 67: // Linux PPC64 Little Endian uses ABI v2. >> 68: private static final boolean useABIv2 = ByteOrder.nativeOrder() == ByteOrder.LITTLE_ENDIAN; > > Now that I'm here. This could be a potentially interesting case for having 2 subclasses of CallArranger: one for `useABIv2 == true` and one for `false`. Yeah, let's wait until we know what changes we need for AIX (and Big Endian linux). > src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/CallArranger.java line 293: > >> 291: } else { >> 292: overlappingReg = new VMStorage(StorageType.STACK_AND_FLOAT, >> 293: (short) STACK_SLOT_SIZE, (int) stackOffset - 4); > > I think you could remove the mixed VMStorage types here relatively easily by returning a `VMStorage[][]`, where each element is a single element array, but then for the `needOverlapping` case add another element to the array for the extra store (instead of replacing the existing one). > > Then when unboxing a `STRUCT_HFA`, `dup` the result of the `bufferLoad` and then do 2 `vmStore`s (one for each element). > > For boxing, you could just ignore the extra storage, and just `vmLoad` the first one (or, whichever one you like :)) Thanks! I need to find extra time for this. Sounds like a good idea and I may be able to get rid of some nasty code. ------------- PR: https://git.openjdk.org/jdk/pull/12708 From stsypanov at openjdk.org Wed Mar 1 13:37:07 2023 From: stsypanov at openjdk.org (Sergey Tsypanov) Date: Wed, 1 Mar 2023 13:37:07 GMT Subject: RFR: 8301492: Modernize equals() method of ResourceBundle.CacheKey and Bundles.CacheKey [v3] In-Reply-To: References: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com> Message-ID: <5WPSbOxpK4B9suNeRfrL93MSbq8wABAMB_fhI1raCiU=.f15f94e2-811a-4501-a11c-15560a3dabb8@github.com> On Wed, 1 Feb 2023 10:36:12 GMT, Sergey Tsypanov wrote: >> `ResourceBundle.CacheKey.equals()` and `Bundles.CacheKey.equals()` are quire outdated. This simple clean-up modernizes them. > > Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision: > > Restore logic Let's wait ------------- PR: https://git.openjdk.org/jdk/pull/12328 From duke at openjdk.org Wed Mar 1 14:22:17 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Wed, 1 Mar 2023 14:22:17 GMT Subject: RFR: 8303401: Add a Vector API equalsIgnoreCase micro benchmark [v6] In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 09:10:47 GMT, Eirik Bjorsnos wrote: >> This PR suggests we add a vectorized equalsIgnoreCase benchmark to the set of benchmarks in `org.openjdk.bench.jdk.incubator.vector`. This benchmark serves as an example of how vectorization can be useful also in the area of text processing. It takes advantage of the fact that ASCII and Latin-1 were designed to optimize case-twiddling operations. >> >> The code came about during the work on #12632, where vectorization was deemed out of scope. >> >> Benchmark results: >> >> >> Benchmark (size) Mode Cnt Score Error Units >> EqualsIgnoreCaseBenchmark.scalar 16 avgt 15 20.671 ? 0.718 ns/op >> EqualsIgnoreCaseBenchmark.scalar 32 avgt 15 46.155 ? 3.258 ns/op >> EqualsIgnoreCaseBenchmark.scalar 64 avgt 15 68.248 ? 1.767 ns/op >> EqualsIgnoreCaseBenchmark.scalar 128 avgt 15 148.948 ? 0.890 ns/op >> EqualsIgnoreCaseBenchmark.scalar 1024 avgt 15 1090.708 ? 7.540 ns/op >> EqualsIgnoreCaseBenchmark.vectorized 16 avgt 15 21.872 ? 0.232 ns/op >> EqualsIgnoreCaseBenchmark.vectorized 32 avgt 15 11.378 ? 0.097 ns/op >> EqualsIgnoreCaseBenchmark.vectorized 64 avgt 15 13.703 ? 0.135 ns/op >> EqualsIgnoreCaseBenchmark.vectorized 128 avgt 15 21.632 ? 0.735 ns/op >> EqualsIgnoreCaseBenchmark.vectorized 1024 avgt 15 105.509 ? 7.493 ns/op > > Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision: > > The equal.allTrue check early if the loop does not cover cases where some bytes are equal, but not all. Reverting this change. We can narrow down this performance difference to the following observations: - `compare(LT, (byte) 0xDF)` is faster than `compare(LE, (byte) 0xDE)` - `compare(GT, (byte) 0XBF)` is faster than `compare(GE, (byte) 0XC0)` - `compare(EQ, (byte) 0xD7).not()` is faster than `compare(NE, (byte) 0xD7)` LT, GT, EQ: Benchmark (size) Mode Cnt Score Error Units EqualsIgnoreCaseBenchmark.vectorized 1024 avgt 15 91.796 ? 1.083 ns/op LE, GE, NE: Benchmark (size) Mode Cnt Score Error Units EqualsIgnoreCaseBenchmark.vectorized 1024 avgt 15 118.898 ? 5.480 ns/op Code: VectorMask asciiLetter = upperA.compare(GT, (byte) '@').and(upperA.compare(LT, (byte) '[')); VectorMask lat1Letter = upperA .compare(LT, (byte) 0xDF) // <= Thorn .and(upperA.compare(GT, (byte) 0XBF)) // >= A-grave .and(upperA.compare(EQ, (byte) 0xD7).not()); // Excluding multiplication vs. VectorMask asciiLetter = upperA.compare(GE, (byte) 'A').and(upperA.compare(LE, (byte) 'Z')); VectorMask lat1Letter = upperA .compare(LE, (byte) 0xDE) // <= Thorn .and(upperA.compare(GE, (byte) 0XC0)) // >= A-grave .and(upperA.compare(NE, (byte) 0xD7)); // Excluding multiplication ------------- PR: https://git.openjdk.org/jdk/pull/12790 From duke at openjdk.org Wed Mar 1 14:28:55 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Wed, 1 Mar 2023 14:28:55 GMT Subject: RFR: 8303401: Add a Vector API equalsIgnoreCase micro benchmark [v7] In-Reply-To: References: Message-ID: > This PR suggests we add a vectorized equalsIgnoreCase benchmark to the set of benchmarks in `org.openjdk.bench.jdk.incubator.vector`. This benchmark serves as an example of how vectorization can be useful also in the area of text processing. It takes advantage of the fact that ASCII and Latin-1 were designed to optimize case-twiddling operations. > > The code came about during the work on #12632, where vectorization was deemed out of scope. > > Benchmark results: > > > Benchmark (size) Mode Cnt Score Error Units > EqualsIgnoreCaseBenchmark.scalar 16 avgt 15 20.671 ? 0.718 ns/op > EqualsIgnoreCaseBenchmark.scalar 32 avgt 15 46.155 ? 3.258 ns/op > EqualsIgnoreCaseBenchmark.scalar 64 avgt 15 68.248 ? 1.767 ns/op > EqualsIgnoreCaseBenchmark.scalar 128 avgt 15 148.948 ? 0.890 ns/op > EqualsIgnoreCaseBenchmark.scalar 1024 avgt 15 1090.708 ? 7.540 ns/op > EqualsIgnoreCaseBenchmark.vectorized 16 avgt 15 21.872 ? 0.232 ns/op > EqualsIgnoreCaseBenchmark.vectorized 32 avgt 15 11.378 ? 0.097 ns/op > EqualsIgnoreCaseBenchmark.vectorized 64 avgt 15 13.703 ? 0.135 ns/op > EqualsIgnoreCaseBenchmark.vectorized 128 avgt 15 21.632 ? 0.735 ns/op > EqualsIgnoreCaseBenchmark.vectorized 1024 avgt 15 105.509 ? 7.493 ns/op Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision: Use GT, LT, EQ operations since they seem to outperform GE, LE, NE. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12790/files - new: https://git.openjdk.org/jdk/pull/12790/files/0272740c..29b213c3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12790&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12790&range=05-06 Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/12790.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12790/head:pull/12790 PR: https://git.openjdk.org/jdk/pull/12790 From aturbanov at openjdk.org Wed Mar 1 14:40:37 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Wed, 1 Mar 2023 14:40:37 GMT Subject: RFR: JDK-8302027: Port fdlibm trig functions (sin, cos, tan) to Java In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 05:28:34 GMT, Joe Darcy wrote: > Last and certainly not least in the port of FDLIBM to Java, the transcendental methods for sin, cos, and tan. > > Some more tests are to be written in the StrictMath directory to verify that the StrictMath algorihtm for sin/cos/tan is being used rather than a different one. However, I wanted to get the rest of the change out for review first. > > The sin/cos/tan methods are grouped together since they share the same argument reduction logic. Argument reduction is the process of mapping an argument of a function to an argument in a restricted range (and possibly returning some function of the reduced argument). For sin, cos, and tan, since they are fundamentally periodic with respect to a multiple of pi, argument reduction is done to find the remainder of the original argument with respect to pi/2. src/java.base/share/classes/java/lang/FdLibm.java line 166: > 164: } else { // argument reduction needed > 165: n = RemPio2.__ieee754_rem_pio2(x, y); > 166: switch(n & 3) { Suggestion: switch (n & 3) { src/java.base/share/classes/java/lang/FdLibm.java line 209: > 207: S4 = 0x1.71de357b1fe7dp-19, // 2.75573137070700676789e-06 > 208: S5 = -0x1.ae5e68a2b9cebp-26, // -2.50507602534068634195e-08 > 209: S6 = 0x1.5d93a5acfd57cp-33; // 1.58969099521155010221e-10 Suggestion: S1 = -0x1.5555555555549p-3, // -1.66666666666666324348e-01 S2 = 0x1.111111110f8a6p-7, // 8.33333333332248946124e-03 S3 = -0x1.a01a019c161d5p-13, // -1.98412698298579493134e-04 S4 = 0x1.71de357b1fe7dp-19, // 2.75573137070700676789e-06 S5 = -0x1.ae5e68a2b9cebp-26, // -2.50507602534068634195e-08 S6 = 0x1.5d93a5acfd57cp-33; // 1.58969099521155010221e-10 src/java.base/share/classes/java/lang/FdLibm.java line 221: > 219: z = x*x; > 220: v = z*x; > 221: r = S2 + z*(S3 + z*(S4 + z*(S5 + z*S6))); Suggestion: z = x*x; v = z*x; r = S2 + z*(S3 + z*(S4 + z*(S5 + z*S6))); src/java.base/share/classes/java/lang/FdLibm.java line 341: > 339: } > 340: z = x*x; > 341: r = z*(C1 + z*(C2 + z*(C3 + z*(C4 + z*(C5 + z*C6))))); Suggestion: z = x*x; r = z*(C1 + z*(C2 + z*(C3 + z*(C4 + z*(C5 + z*C6))))); src/java.base/share/classes/java/lang/FdLibm.java line 444: > 442: private static final double > 443: pio4 = 0x1.921fb54442d18p-1, // 7.85398163397448278999e-01 > 444: pio4lo= 0x1.1a62633145c07p-55, // 3.06161699786838301793e-17 Suggestion: pio4 = 0x1.921fb54442d18p-1, // 7.85398163397448278999e-01 pio4lo = 0x1.1a62633145c07p-55, // 3.06161699786838301793e-17 src/java.base/share/classes/java/lang/FdLibm.java line 445: > 443: pio4 = 0x1.921fb54442d18p-1, // 7.85398163397448278999e-01 > 444: pio4lo= 0x1.1a62633145c07p-55, // 3.06161699786838301793e-17 > 445: T[] = { Suggestion: T[] = { src/java.base/share/classes/java/lang/FdLibm.java line 498: > 496: } > 497: z = x*x; > 498: w = z*z; Suggestion: z = x*x; w = z*z; src/java.base/share/classes/java/lang/FdLibm.java line 579: > 577: pio2_2t = 0x1.3198a2e037073p-69, // 2.02226624879595063154e-21 > 578: pio2_3 = 0x1.3198a2ep-69, // 2.02226624871116645580e-21 > 579: pio2_3t = 0x1.b839a252049c1p-104; // 8.47842766036889956997e-32 Suggestion: invpio2 = 0x1.45f306dc9c883p-1, // 6.36619772367581382433e-01 pio2_1 = 0x1.921fb544p0, // 1.57079632673412561417e+00 pio2_1t = 0x1.0b4611a626331p-34, // 6.07710050650619224932e-11 pio2_2 = 0x1.0b4611a6p-34, // 6.07710050630396597660e-11 pio2_2t = 0x1.3198a2e037073p-69, // 2.02226624879595063154e-21 pio2_3 = 0x1.3198a2ep-69, // 2.02226624871116645580e-21 pio2_3t = 0x1.b839a252049c1p-104; // 8.47842766036889956997e-32 src/java.base/share/classes/java/lang/FdLibm.java line 627: > 625: y[0] = r - w; // quick check no cancellation > 626: } else { > 627: j = ix >> 20; Suggestion: j = ix >> 20; src/java.base/share/classes/java/lang/FdLibm.java line 634: > 632: w = fn*pio2_2; > 633: r = t - w; > 634: w = fn*pio2_2t - ((t - r) - w); Suggestion: t = r; w = fn*pio2_2; r = t - w; w = fn*pio2_2t - ((t - r) - w); src/java.base/share/classes/java/lang/FdLibm.java line 675: > 673: nx--; > 674: } > 675: n = KernelRemPio2.__kernel_rem_pio2(tx, y, e0, nx, 2, two_over_pi); Suggestion: n = KernelRemPio2.__kernel_rem_pio2(tx, y, e0, nx, 2, two_over_pi); src/java.base/share/classes/java/lang/FdLibm.java line 814: > 812: > 813: static final double > 814: twon24 = 0x1.0p-24; // 5.96046447753906250000e-08 Suggestion: twon24 = 0x1.0p-24; // 5.96046447753906250000e-08 src/java.base/share/classes/java/lang/FdLibm.java line 829: > 827: > 828: // determine jx, jv, q0, note that 3 > q0 > 829: jx = nx - 1; Suggestion: jx = nx - 1; src/java.base/share/classes/java/lang/FdLibm.java line 834: > 832: jv = 0; > 833: } > 834: q0 = e0 - 24*(jv + 1); Suggestion: q0 = e0 - 24*(jv + 1); src/java.base/share/classes/java/lang/FdLibm.java line 852: > 850: > 851: jz = jk; > 852: while(true) { Suggestion: while (true) { src/java.base/share/classes/java/lang/FdLibm.java line 877: > 875: } > 876: > 877: if ( ih > 0) { // q > 0.5 Suggestion: if (ih > 0) { // q > 0.5 src/java.base/share/classes/java/lang/FdLibm.java line 882: > 880: for (i=0; i < jz; i++) { // compute 1-q > 881: j = iq[i]; > 882: if(carry == 0) { Suggestion: if (carry == 0) { src/java.base/share/classes/java/lang/FdLibm.java line 892: > 890: } > 891: if (q0 > 0) { // rare case: chance is 1 in 12 > 892: switch(q0) { Suggestion: switch (q0) { src/java.base/share/classes/java/lang/FdLibm.java line 958: > 956: // convert integer "bit" chunk to floating-point value > 957: fw = Math.scalb(1.0, q0); > 958: for(i = jz; i>=0; i--) { Suggestion: for (i = jz; i>=0; i--) { src/java.base/share/classes/java/lang/FdLibm.java line 964: > 962: > 963: // compute PIo2[0,...,jp]*q[jz,...,0] > 964: for(i = jz; i>=0; i--) { Suggestion: for (i = jz; i>=0; i--) { src/java.base/share/classes/java/lang/FdLibm.java line 972: > 970: > 971: // compress fq[] into y[] > 972: switch(prec) { Suggestion: switch (prec) { src/java.base/share/classes/java/lang/FdLibm.java line 997: > 995: fw = fq[i - 1] + fq[i]; > 996: fq[i] += fq[i - 1] - fw; > 997: fq[i - 1] = fw; Suggestion: fw = fq[i - 1] + fq[i]; fq[i] += fq[i - 1] - fw; fq[i - 1] = fw; ------------- PR: https://git.openjdk.org/jdk/pull/12800 From asotona at openjdk.org Wed Mar 1 15:00:41 2023 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 1 Mar 2023 15:00:41 GMT Subject: RFR: 8294982: Implementation of Classfile API [v31] In-Reply-To: References: Message-ID: > This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. > > Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. > > Classfile API development is tracked at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch > > Development branch of consolidated JDK class files parsing, generating, and transforming is at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch > > Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. > > Please take you time to review this non-trivial JDK addition. > > Thank you, > Adam Adam Sotona has updated the pull request incrementally with four additional commits since the last revision: - renamed all remaining ConcreteXyzEntry to XyzEntryImpl - abstract implementations of RefEntry, RefsEntry and NamedEntry renamed to AbstractRefEntry, AbstractRefsEntry and AbstractNamedEntry - renamed ConcreteBootstrapMethodEntry to BootstrapMethodEntryImpl - ConcreteEntry renamed to AbstractPoolEntry ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10982/files - new: https://git.openjdk.org/jdk/pull/10982/files/212bb04e..1e95e508 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=30 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=29-30 Stats: 2758 lines in 32 files changed: 1283 ins; 1285 del; 190 mod Patch: https://git.openjdk.org/jdk/pull/10982.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982 PR: https://git.openjdk.org/jdk/pull/10982 From roger.riggs at oracle.com Wed Mar 1 15:07:20 2023 From: roger.riggs at oracle.com (Roger Riggs) Date: Wed, 1 Mar 2023 10:07:20 -0500 Subject: UUID creation performance In-Reply-To: References: Message-ID: <608c81ee-cb3d-d142-c8fa-a1bcd9551975@oracle.com> Hi, That's an interesting idea.? Recently VarHandle access methods were created by JDK-8300236 [1] [2] in the jdk.internal.util package. See the ByteArray and ByteArrayLittleEndian classes. See how that would affect performance and leverage existing VarHandles. Thanks, Roger [1] https://bugs.openjdk.org/browse/JDK-8300236 [2] https://github.com/openjdk/jdk/pull/12076 On 3/1/23 7:50 AM, Brett Okken wrote: > Is there any interest in updating the static UUID.randomUUID() and > UUID.nameUUIDFromBytes(byte[]) factory methods to use either a > ByteBuffer or byteArrayViewVarHandle to convert the byte[] to 2 long > values then do the bit twiddling? > These methods are really dominated by time to create/populate the > byte[], but this does reduce the time to create the 2 long values by > at least half. > It would also allow the removal of the private UUID(byte[] data). > > public static UUID randomUUID() { > SecureRandom ng = Holder.numberGenerator; > > byte[] randomBytes = new byte[16]; > ng.nextBytes(randomBytes); > final ByteBuffer bb = ByteBuffer.wrap(randomBytes); > bb.order(ByteOrder.nativeOrder()); > > long msb = bb.getLong(); > long lsb = bb.getLong(); > > msb &= 0xFFFFFFFFFFFF0FFFL; /* clear version */ > msb |= 0x4000L; /* set to version 4 */ > > lsb &= 0x3FFFFFFFFFFFFFFFL; /* clear variant */ > lsb |= 0x8000000000000000L; /* set to IETF variant */ > > return new UUID(msb, lsb); > } > > public static UUID nameUUIDFromBytes(byte[] name) { > MessageDigest md; > try { > md = MessageDigest.getInstance("MD5"); > } catch (NoSuchAlgorithmException nsae) { > throw new InternalError("MD5 not supported", nsae); > } > byte[] md5Bytes = md.digest(name); > > // default byte order is BIG_ENDIAN > final ByteBuffer bb = ByteBuffer.wrap(md5Bytes); > > long msb = bb.getLong(); > long lsb = bb.getLong(); > > msb &= 0xFFFFFFFFFFFF0FFFL; /* clear version */ > msb |= 0x3000L; /* set to version 3 */ > > lsb &= 0x3FFFFFFFFFFFFFFFL; /* clear variant */ > lsb |= 0x8000000000000000L; /* set to IETF variant */ > > return new UUID(msb, lsb); > } > > Benchmark Mode Cnt Score Error Units > UUIDBenchmark.jdk_name avgt 3 11.885 ? 4.025 ns/op > UUIDBenchmark.jdk_random avgt 3 11.656 ? 0.987 ns/op > UUIDBenchmark.longs avgt 3 7.618 ? 1.047 ns/op > UUIDBenchmark.longs_bb avgt 3 7.755 ? 1.643 ns/op > UUIDBenchmark.longs_name avgt 3 8.467 ? 1.784 ns/op > UUIDBenchmark.longs_name_bb avgt 3 8.455 ? 1.662 ns/op > UUIDBenchmark.randomBytes avgt 3 6.132 ? 0.447 ns/op > > > @BenchmarkMode(Mode.AverageTime) > @OutputTimeUnit(TimeUnit.NANOSECONDS) > @Warmup(iterations = 3, time = 2, timeUnit = TimeUnit.SECONDS) > @Measurement(iterations = 3, time = 2, timeUnit = TimeUnit.SECONDS) > @Fork(1) > @State(Scope.Benchmark) > public class UUIDBenchmark { > > private static final VarHandle LONGS_ACCESS = > MethodHandles.byteArrayViewVarHandle(long[].class, > ByteOrder.nativeOrder()); > > private static final VarHandle BE_LONGS_ACCESS = > MethodHandles.byteArrayViewVarHandle(long[].class, > ByteOrder.BIG_ENDIAN); > > @Benchmark > public byte[] randomBytes() { > final byte[] bytes = new byte[16]; > randomBytes(bytes); > return bytes; > } > > @Benchmark > public void jdk_random(Blackhole bh) { > final byte[] data = new byte[16]; > randomBytes(data); > data[6] &= 0x0f; /* clear version */ > data[6] |= 0x40; /* set to version 4 */ > data[8] &= 0x3f; /* clear variant */ > data[8] |= 0x80; /* set to IETF variant */ > long msb = 0; > long lsb = 0; > assert data.length == 16 : "data must be 16 bytes in length"; > for (int i=0; i<8; i++) > msb = (msb << 8) | (data[i] & 0xff); > for (int i=8; i<16; i++) > lsb = (lsb << 8) | (data[i] & 0xff); > bh.consume(msb); > bh.consume(lsb); > } > > @Benchmark > public void jdk_name(Blackhole bh) > { > final byte[] md5Bytes = new byte[16]; > randomBytes(md5Bytes); > md5Bytes[6] &= 0x0f; /* clear version */ > md5Bytes[6] |= 0x30; /* set to version 3 */ > md5Bytes[8] &= 0x3f; /* clear variant */ > md5Bytes[8] |= 0x80; /* set to IETF variant */ > long msb = 0; > long lsb = 0; > assert md5Bytes.length == 16 : "data must be 16 bytes in length"; > for (int i=0; i<8; i++) > msb = (msb << 8) | (md5Bytes[i] & 0xff); > for (int i=8; i<16; i++) > lsb = (lsb << 8) | (md5Bytes[i] & 0xff); > bh.consume(msb); > bh.consume(lsb); > } > > @Benchmark > public void longs(Blackhole bh) { > final byte[] data = new byte[16]; > randomBytes(data); > > long msb = (long) LONGS_ACCESS.get(data, 0); > long lsb = (long) LONGS_ACCESS.get(data, 8); > > msb &= 0xFFFFFFFFFFFF0FFFL; > msb |= 0x4000L; > > lsb &= 0x3FFFFFFFFFFFFFFFL; > lsb |= 0x8000000000000000L; > > bh.consume(msb); > bh.consume(lsb); > } > > @Benchmark > public void longs_name(Blackhole bh) { > final byte[] data = new byte[16]; > randomBytes(data); > > long msb = (long) BE_LONGS_ACCESS.get(data, 0); > long lsb = (long) BE_LONGS_ACCESS.get(data, 8); > > msb &= 0xFFFFFFFFFFFF0FFFL; > msb |= 0x3000L; > > lsb &= 0x3FFFFFFFFFFFFFFFL; > lsb |= 0x8000000000000000L; > > bh.consume(msb); > bh.consume(lsb); > } > > @Benchmark > public void longs_bb(Blackhole bh) { > final byte[] data = new byte[16]; > randomBytes(data); > > final ByteBuffer bb = ByteBuffer.wrap(data); > bb.order(ByteOrder.nativeOrder()); > > long msb = bb.getLong(); > long lsb = bb.getLong(); > > msb &= 0xFFFFFFFFFFFF0FFFL; > msb |= 0x4000L; > > lsb &= 0x3FFFFFFFFFFFFFFFL; > lsb |= 0x8000000000000000L; > > bh.consume(msb); > bh.consume(lsb); > } > > @Benchmark > public void longs_name_bb(Blackhole bh) { > final byte[] data = new byte[16]; > randomBytes(data); > > final ByteBuffer bb = ByteBuffer.wrap(data); > // bb.order(ByteOrder.BIG_ENDIAN); > > long msb = bb.getLong(); > long lsb = bb.getLong(); > > msb &= 0xFFFFFFFFFFFF0FFFL; > msb |= 0x3000L; > > lsb &= 0x3FFFFFFFFFFFFFFFL; > lsb |= 0x8000000000000000L; > > bh.consume(msb); > bh.consume(lsb); > } > > static void randomBytes(byte[] bytes) { > ThreadLocalRandom tlr = ThreadLocalRandom.current(); > LONGS_ACCESS.set(bytes, 0, tlr.nextLong()); > LONGS_ACCESS.set(bytes, 8, tlr.nextLong()); > } > } From alanb at openjdk.org Wed Mar 1 15:11:16 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 1 Mar 2023 15:11:16 GMT Subject: RFR: 8302791: Add specific ClassLoader object to Proxy IllegalArgumentException message [v4] In-Reply-To: <0jQQEOJWyqjmAP3UgPGk7V1muce0Yx14nWIlBnkOgas=.095d14d8-ee3c-4089-bb62-6f7d1c0100d5@github.com> References: <0jQQEOJWyqjmAP3UgPGk7V1muce0Yx14nWIlBnkOgas=.095d14d8-ee3c-4089-bb62-6f7d1c0100d5@github.com> Message-ID: On Wed, 1 Mar 2023 10:10:12 GMT, Ravali Yatham wrote: >> Added specific class loader object to proxy IllegalArgumentException from which the class was not visible >> >> The bug report for the same: https://bugs.openjdk.org/browse/JDK-8302791 > > Ravali Yatham has updated the pull request incrementally with one additional commit since the last revision: > > Add comments src/java.base/share/classes/java/lang/reflect/Proxy.java line 889: > 887: : Objects.toIdentityString(ld); > 888: throw new IllegalArgumentException(c.getName() + > 889: " referenced from a method is not visible from class loader: " + nid); Thanks for the update, this looks much better. A passing thought is that you might want to use "/" instead of "@" as the separator so that someone looking at the exception message will be able to distinguish a class name from a class loader name. Also you might want to re-format L886 to avoid the really long line as it's a bit inconsistent with the code in this source file. ------------- PR: https://git.openjdk.org/jdk/pull/12641 From rriggs at openjdk.org Wed Mar 1 15:16:20 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 1 Mar 2023 15:16:20 GMT Subject: RFR: 8303198: System and Runtime.exit() resilience to logging errors In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 11:03:39 GMT, Jaikiran Pai wrote: >> Consolidate logging and handle exceptions by printing to standard error and ignoring the exception. >> Exceptions while logging will not interfere with Runtime.exit. > > src/java.base/share/classes/java/lang/Shutdown.java line 186: > >> 184: try { >> 185: // Exceptions from the Logger are printed but do not prevent exit >> 186: System.err.println("Runtime.exit() logging failed: " + throwable.getMessage()); > > Hello Roger, do you think including the exit code in this System.err.println message would be useful too? That would then mean that if the Logger failed for whatever reason, this fallback message would at least include the exit code to provide some hints on what might have triggered the exit. Including the status is simple enough, but has little/nothing to do with why the logging call failed. ------------- PR: https://git.openjdk.org/jdk/pull/12770 From jpai at openjdk.org Wed Mar 1 15:19:41 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 1 Mar 2023 15:19:41 GMT Subject: RFR: 8303198: System and Runtime.exit() resilience to logging errors In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 15:13:06 GMT, Roger Riggs wrote: >> src/java.base/share/classes/java/lang/Shutdown.java line 186: >> >>> 184: try { >>> 185: // Exceptions from the Logger are printed but do not prevent exit >>> 186: System.err.println("Runtime.exit() logging failed: " + throwable.getMessage()); >> >> Hello Roger, do you think including the exit code in this System.err.println message would be useful too? That would then mean that if the Logger failed for whatever reason, this fallback message would at least include the exit code to provide some hints on what might have triggered the exit. > > Including the status is simple enough, but has little/nothing to do with why the logging call failed. Agreed - the exit code in the System.err.println fallback would merely be a last resort to provide some possible hint on what code might have triggered an exit. ------------- PR: https://git.openjdk.org/jdk/pull/12770 From duke at openjdk.org Wed Mar 1 15:25:07 2023 From: duke at openjdk.org (Matthew Donovan) Date: Wed, 1 Mar 2023 15:25:07 GMT Subject: RFR: 8298939: Refactor open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.sh to jtreg java test [v6] In-Reply-To: References: Message-ID: > Removed SSLSocketParametersTest.sh script (which just called a Java file) and configured the java code to run directly with jtreg Matthew Donovan 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 eight additional commits since the last revision: - Merge branch 'master' into rmi-sslparams - cleaned up exception handling - added System.exit when exceptions are thrown and refactored for clarity - Merge branch 'master' into rmi-sslparams - added default switch case and additional refactoring - added exceptions for cases 4 and 5 - clarified cases 4 and 5 - 8298939: Refactor open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.sh to jtreg java test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11910/files - new: https://git.openjdk.org/jdk/pull/11910/files/44b3ffcb..59e30816 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11910&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11910&range=04-05 Stats: 14186 lines in 623 files changed: 9214 ins; 2750 del; 2222 mod Patch: https://git.openjdk.org/jdk/pull/11910.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11910/head:pull/11910 PR: https://git.openjdk.org/jdk/pull/11910 From rgiulietti at openjdk.org Wed Mar 1 16:16:17 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 1 Mar 2023 16:16:17 GMT Subject: RFR: JDK-8302027: Port fdlibm trig functions (sin, cos, tan) to Java In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 14:27:09 GMT, Andrey Turbanov wrote: >> Last and certainly not least in the port of FDLIBM to Java, the transcendental methods for sin, cos, and tan. >> >> Some more tests are to be written in the StrictMath directory to verify that the StrictMath algorihtm for sin/cos/tan is being used rather than a different one. However, I wanted to get the rest of the change out for review first. >> >> The sin/cos/tan methods are grouped together since they share the same argument reduction logic. Argument reduction is the process of mapping an argument of a function to an argument in a restricted range (and possibly returning some function of the reduced argument). For sin, cos, and tan, since they are fundamentally periodic with respect to a multiple of pi, argument reduction is done to find the remainder of the original argument with respect to pi/2. > > src/java.base/share/classes/java/lang/FdLibm.java line 814: > >> 812: >> 813: static final double >> 814: twon24 = 0x1.0p-24; // 5.96046447753906250000e-08 > > Suggestion: > > twon24 = 0x1.0p-24; // 5.96046447753906250000e-08 Would it be worthwhile to declare this as a compile time constant, similarly to `TWO24`? If it's used only here, then probably not. ------------- PR: https://git.openjdk.org/jdk/pull/12800 From rgiulietti at openjdk.org Wed Mar 1 16:16:22 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 1 Mar 2023 16:16:22 GMT Subject: RFR: JDK-8302027: Port fdlibm trig functions (sin, cos, tan) to Java In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 05:28:34 GMT, Joe Darcy wrote: > Last and certainly not least in the port of FDLIBM to Java, the transcendental methods for sin, cos, and tan. > > Some more tests are to be written in the StrictMath directory to verify that the StrictMath algorihtm for sin/cos/tan is being used rather than a different one. However, I wanted to get the rest of the change out for review first. > > The sin/cos/tan methods are grouped together since they share the same argument reduction logic. Argument reduction is the process of mapping an argument of a function to an argument in a restricted range (and possibly returning some function of the reduced argument). For sin, cos, and tan, since they are fundamentally periodic with respect to a multiple of pi, argument reduction is done to find the remainder of the original argument with respect to pi/2. src/java.base/share/classes/java/lang/FdLibm.java line 816: > 814: twon24 = 0x1.0p-24; // 5.96046447753906250000e-08 > 815: > 816: static int __kernel_rem_pio2(double[] x, double[] y, int e0, int nx, int prec, final int[] ipio2) { See comment on translit about the value of `final` here. src/java.base/share/classes/java/lang/FdLibm.java line 852: > 850: > 851: jz = jk; > 852: while(true) { See comment in translit. test/jdk/java/lang/StrictMath/FdlibmTranslit.java line 839: > 837: twon24 = 5.96046447753906250000e-08; /* 0x3E700000, 0x00000000 */ > 838: > 839: static int __kernel_rem_pio2(double[] x, double[] y, int e0, int nx, int prec, final int[] ipio2) { `final int[]` in Java has a different semantics than `const int*` in C. The latter denotes a pointer to constant `int`s. I don't think that the `final` keywords conveys any benefit here. test/jdk/java/lang/StrictMath/FdlibmTranslit.java line 867: > 865: > 866: jz = jk; > 867: while(true) { Would it be worthwhile to add some remarks about how the C `goto` + label has been "translitted"? Or even add the `recompute:` label explicitly and adapt the `continue` and `break` statements inside the `while`? ------------- PR: https://git.openjdk.org/jdk/pull/12800 From rgiulietti at openjdk.org Wed Mar 1 16:24:46 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 1 Mar 2023 16:24:46 GMT Subject: RFR: 8302590: Add String.indexOf(int ch, int fromIndex, int toIndex) [v4] In-Reply-To: References: Message-ID: > Add an `indexOf()` variant allowing to specify both a lower and an upper bound on the search. Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: 8302590: Add String.indexOf(int ch, int fromIndex, int toIndex) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12600/files - new: https://git.openjdk.org/jdk/pull/12600/files/d627e558..1eca562b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12600&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12600&range=02-03 Stats: 176 lines in 4 files changed: 35 ins; 78 del; 63 mod Patch: https://git.openjdk.org/jdk/pull/12600.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12600/head:pull/12600 PR: https://git.openjdk.org/jdk/pull/12600 From rgiulietti at openjdk.org Wed Mar 1 16:25:30 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 1 Mar 2023 16:25:30 GMT Subject: RFR: 8302590: Add String.indexOf(int ch, int fromIndex, int toIndex) [v3] In-Reply-To: References: Message-ID: On Tue, 28 Feb 2023 13:31:56 GMT, Raffaello Giulietti wrote: >> Add an `indexOf()` variant allowing to specify both a lower and an upper bound on the search. > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > 8302590: Add String.indexOf(int ch, int fromIndex, int toIndex) The proposed `indexOf()` method now throws a `StringIndexOutOfBoundsException` on illegal indices. The [CSR](https://bugs.openjdk.org/browse/JDK-8302680) has been updated. ------------- PR: https://git.openjdk.org/jdk/pull/12600 From naoto at openjdk.org Wed Mar 1 16:55:06 2023 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 1 Mar 2023 16:55:06 GMT Subject: RFR: 8303405: fix @returnss typo in ReflectionFactory In-Reply-To: <-0G_v0gBCIwZzCJrCns71VpiwaLRpNvbpmRYVUm_k4U=.3f2f80b3-5c8d-4134-9c0a-79a94ce8678e@github.com> References: <-0G_v0gBCIwZzCJrCns71VpiwaLRpNvbpmRYVUm_k4U=.3f2f80b3-5c8d-4134-9c0a-79a94ce8678e@github.com> Message-ID: <3A3Eycv7w86Pt3GORE5z8ahc86h8jITMuzyqLxW9RSw=.a170ae5b-251a-43ab-9762-1901c6c3c3dc@github.com> On Wed, 1 Mar 2023 00:24:31 GMT, Justin Lu wrote: > The following typo: `@returnss` was reported on line _482 of Reflection Factory.java_. > > In addition to fixing that, I have replaced multiple instances of `@returns` with `@return` in the same file. Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12794 From rriggs at openjdk.org Wed Mar 1 16:59:51 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 1 Mar 2023 16:59:51 GMT Subject: RFR: 8303198: System and Runtime.exit() resilience to logging errors [v2] In-Reply-To: References: Message-ID: > Consolidate logging and handle exceptions by printing to standard error and ignoring the exception. > Exceptions while logging will not interfere with Runtime.exit. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Add exit status to output when the logging fails with an exception. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12770/files - new: https://git.openjdk.org/jdk/pull/12770/files/ed5d16e7..363ccbc2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12770&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12770&range=00-01 Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/12770.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12770/head:pull/12770 PR: https://git.openjdk.org/jdk/pull/12770 From chegar at openjdk.org Wed Mar 1 17:17:12 2023 From: chegar at openjdk.org (Chris Hegarty) Date: Wed, 1 Mar 2023 17:17:12 GMT Subject: RFR: 8303198: System and Runtime.exit() resilience to logging errors [v2] In-Reply-To: References: Message-ID: On Tue, 28 Feb 2023 14:09:50 GMT, Alan Bateman wrote: >> But does that logging include the thread identity? If multiple threads can race to exit and all log, then the developer/user needs to know which logging came from which thread. > >> But does that logging include the thread identity? If multiple threads can race to exit and all log, then the developer/user needs to know which logging came from which thread. > > That's really up to the Logger and its configuration. If j.u.logging is used then formatters can be configured to put the thread ID into the log records. With 3rd party logging libraries there seems to be several choices, like %t for the thread name. > > The main usage for this logging is to be able to find code in tests, plugins, etc. that is calling System.exit and causing the test runner or container to exit. So I think it's less about "which thread" and more about "which code". System.Logger is a facade for arbitrary user-code, commonly the log4J bridge. I routinely observe log4J throwing SecurityException's from deep within its implementation (since it is only partially implemented to handle the security manager) ------------- PR: https://git.openjdk.org/jdk/pull/12770 From duke at openjdk.org Wed Mar 1 17:52:36 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Wed, 1 Mar 2023 17:52:36 GMT Subject: RFR: 8303401: Add a Vector API equalsIgnoreCase micro benchmark [v8] In-Reply-To: References: Message-ID: > This PR suggests we add a vectorized equalsIgnoreCase benchmark to the set of benchmarks in `org.openjdk.bench.jdk.incubator.vector`. This benchmark serves as an example of how vectorization can be useful also in the area of text processing. It takes advantage of the fact that ASCII and Latin-1 were designed to optimize case-twiddling operations. > > The code came about during the work on #12632, where vectorization was deemed out of scope. > > Benchmark results: > > > Benchmark (size) Mode Cnt Score Error Units > EqualsIgnoreCaseBenchmark.scalar 16 avgt 15 21.575 ? 0.365 ns/op > EqualsIgnoreCaseBenchmark.scalar 32 avgt 15 43.199 ? 2.786 ns/op > EqualsIgnoreCaseBenchmark.scalar 64 avgt 15 71.389 ? 0.891 ns/op > EqualsIgnoreCaseBenchmark.scalar 128 avgt 15 146.827 ? 1.115 ns/op > EqualsIgnoreCaseBenchmark.scalar 1024 avgt 15 1062.759 ? 9.331 ns/op > EqualsIgnoreCaseBenchmark.vectorized 16 avgt 15 21.483 ? 0.121 ns/op > EqualsIgnoreCaseBenchmark.vectorized 32 avgt 15 10.538 ? 0.125 ns/op > EqualsIgnoreCaseBenchmark.vectorized 64 avgt 15 13.182 ? 0.177 ns/op > EqualsIgnoreCaseBenchmark.vectorized 128 avgt 15 19.192 ? 0.421 ns/op > EqualsIgnoreCaseBenchmark.vectorized 1024 avgt 15 92.521 ? 3.494 ns/op Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision: Add whitespace after if ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12790/files - new: https://git.openjdk.org/jdk/pull/12790/files/29b213c3..d4802538 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12790&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12790&range=06-07 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12790.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12790/head:pull/12790 PR: https://git.openjdk.org/jdk/pull/12790 From psandoz at openjdk.org Wed Mar 1 17:52:36 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Wed, 1 Mar 2023 17:52:36 GMT Subject: RFR: 8303401: Add a Vector API equalsIgnoreCase micro benchmark [v8] In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 17:48:46 GMT, Eirik Bjorsnos wrote: >> This PR suggests we add a vectorized equalsIgnoreCase benchmark to the set of benchmarks in `org.openjdk.bench.jdk.incubator.vector`. This benchmark serves as an example of how vectorization can be useful also in the area of text processing. It takes advantage of the fact that ASCII and Latin-1 were designed to optimize case-twiddling operations. >> >> The code came about during the work on #12632, where vectorization was deemed out of scope. >> >> Benchmark results: >> >> >> Benchmark (size) Mode Cnt Score Error Units >> EqualsIgnoreCaseBenchmark.scalar 16 avgt 15 21.575 ? 0.365 ns/op >> EqualsIgnoreCaseBenchmark.scalar 32 avgt 15 43.199 ? 2.786 ns/op >> EqualsIgnoreCaseBenchmark.scalar 64 avgt 15 71.389 ? 0.891 ns/op >> EqualsIgnoreCaseBenchmark.scalar 128 avgt 15 146.827 ? 1.115 ns/op >> EqualsIgnoreCaseBenchmark.scalar 1024 avgt 15 1062.759 ? 9.331 ns/op >> EqualsIgnoreCaseBenchmark.vectorized 16 avgt 15 21.483 ? 0.121 ns/op >> EqualsIgnoreCaseBenchmark.vectorized 32 avgt 15 10.538 ? 0.125 ns/op >> EqualsIgnoreCaseBenchmark.vectorized 64 avgt 15 13.182 ? 0.177 ns/op >> EqualsIgnoreCaseBenchmark.vectorized 128 avgt 15 19.192 ? 0.421 ns/op >> EqualsIgnoreCaseBenchmark.vectorized 1024 avgt 15 92.521 ? 3.494 ns/op > > Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision: > > Add whitespace after if Marked as reviewed by psandoz (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12790 From psandoz at openjdk.org Wed Mar 1 17:52:37 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Wed, 1 Mar 2023 17:52:37 GMT Subject: RFR: 8303401: Add a Vector API equalsIgnoreCase micro benchmark [v7] In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 14:28:55 GMT, Eirik Bjorsnos wrote: >> This PR suggests we add a vectorized equalsIgnoreCase benchmark to the set of benchmarks in `org.openjdk.bench.jdk.incubator.vector`. This benchmark serves as an example of how vectorization can be useful also in the area of text processing. It takes advantage of the fact that ASCII and Latin-1 were designed to optimize case-twiddling operations. >> >> The code came about during the work on #12632, where vectorization was deemed out of scope. >> >> Benchmark results: >> >> >> Benchmark (size) Mode Cnt Score Error Units >> EqualsIgnoreCaseBenchmark.scalar 16 avgt 15 21.575 ? 0.365 ns/op >> EqualsIgnoreCaseBenchmark.scalar 32 avgt 15 43.199 ? 2.786 ns/op >> EqualsIgnoreCaseBenchmark.scalar 64 avgt 15 71.389 ? 0.891 ns/op >> EqualsIgnoreCaseBenchmark.scalar 128 avgt 15 146.827 ? 1.115 ns/op >> EqualsIgnoreCaseBenchmark.scalar 1024 avgt 15 1062.759 ? 9.331 ns/op >> EqualsIgnoreCaseBenchmark.vectorized 16 avgt 15 21.483 ? 0.121 ns/op >> EqualsIgnoreCaseBenchmark.vectorized 32 avgt 15 10.538 ? 0.125 ns/op >> EqualsIgnoreCaseBenchmark.vectorized 64 avgt 15 13.182 ? 0.177 ns/op >> EqualsIgnoreCaseBenchmark.vectorized 128 avgt 15 19.192 ? 0.421 ns/op >> EqualsIgnoreCaseBenchmark.vectorized 1024 avgt 15 92.521 ? 3.494 ns/op > > Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision: > > Use GT, LT, EQ operations since they seem to outperform GE, LE, NE. Benchmark looks good. I think you need to look at the generated code and perf data to get more insight into the differences you are observing. Sometimes array alignment can add variance to the results (which may not be the case here), and to rule that out i sometimes run vector tests with the HotSpot option `-XX:ObjectAlignmentInBytes` e.g. `-XX:ObjectAlignmentInBytes=32`. test/micro/org/openjdk/bench/jdk/incubator/vector/EqualsIgnoreCaseBenchmark.java line 111: > 109: .or(letter.and(upperA.eq(upperB))); > 110: > 111: if(equalsIgnoreCase.allTrue()) { Suggestion: if (equalsIgnoreCase.allTrue()) { ------------- PR: https://git.openjdk.org/jdk/pull/12790 From duke at openjdk.org Wed Mar 1 17:52:37 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Wed, 1 Mar 2023 17:52:37 GMT Subject: RFR: 8303401: Add a Vector API equalsIgnoreCase micro benchmark [v7] In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 17:42:16 GMT, Paul Sandoz wrote: >> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision: >> >> Use GT, LT, EQ operations since they seem to outperform GE, LE, NE. > > test/micro/org/openjdk/bench/jdk/incubator/vector/EqualsIgnoreCaseBenchmark.java line 111: > >> 109: .or(letter.and(upperA.eq(upperB))); >> 110: >> 111: if(equalsIgnoreCase.allTrue()) { > > Suggestion: > > if (equalsIgnoreCase.allTrue()) { Fixed. ------------- PR: https://git.openjdk.org/jdk/pull/12790 From duke at openjdk.org Wed Mar 1 17:55:17 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Wed, 1 Mar 2023 17:55:17 GMT Subject: RFR: 8303401: Add a Vector API equalsIgnoreCase micro benchmark [v7] In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 17:47:45 GMT, Paul Sandoz wrote: > Benchmark looks good. > > I think you need to look at the generated code and perf data to get more insight into the differences you are observing. > > Sometimes array alignment can add variance to the results (which may not be the case here), and to rule that out i sometimes run vector tests with the HotSpot option `-XX:ObjectAlignmentInBytes` e.g. `-XX:ObjectAlignmentInBytes=32`. Thanks for the review and also your suggestions on how to get to the bottom of this. If I choose to investigate this further, it will be outside this PR. ------------- PR: https://git.openjdk.org/jdk/pull/12790 From darcy at openjdk.org Wed Mar 1 18:04:54 2023 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 1 Mar 2023 18:04:54 GMT Subject: RFR: JDK-8302027: Port fdlibm trig functions (sin, cos, tan) to Java [v2] In-Reply-To: References: Message-ID: > Last and certainly not least in the port of FDLIBM to Java, the transcendental methods for sin, cos, and tan. > > Some more tests are to be written in the StrictMath directory to verify that the StrictMath algorihtm for sin/cos/tan is being used rather than a different one. However, I wanted to get the rest of the change out for review first. > > The sin/cos/tan methods are grouped together since they share the same argument reduction logic. Argument reduction is the process of mapping an argument of a function to an argument in a restricted range (and possibly returning some function of the reduced argument). For sin, cos, and tan, since they are fundamentally periodic with respect to a multiple of pi, argument reduction is done to find the remainder of the original argument with respect to pi/2. Joe Darcy has updated the pull request incrementally with 10 additional commits since the last revision: - Update src/java.base/share/classes/java/lang/FdLibm.java Co-authored-by: Andrey Turbanov - Update src/java.base/share/classes/java/lang/FdLibm.java Co-authored-by: Andrey Turbanov - Update src/java.base/share/classes/java/lang/FdLibm.java Co-authored-by: Andrey Turbanov - Update src/java.base/share/classes/java/lang/FdLibm.java Co-authored-by: Andrey Turbanov - Update src/java.base/share/classes/java/lang/FdLibm.java Co-authored-by: Andrey Turbanov - Update src/java.base/share/classes/java/lang/FdLibm.java Co-authored-by: Andrey Turbanov - Update src/java.base/share/classes/java/lang/FdLibm.java Co-authored-by: Andrey Turbanov - Update src/java.base/share/classes/java/lang/FdLibm.java Co-authored-by: Andrey Turbanov - Update src/java.base/share/classes/java/lang/FdLibm.java Co-authored-by: Andrey Turbanov - Update src/java.base/share/classes/java/lang/FdLibm.java Co-authored-by: Andrey Turbanov ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12800/files - new: https://git.openjdk.org/jdk/pull/12800/files/6e3567f7..321a66cd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12800&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12800&range=00-01 Stats: 10 lines in 1 file changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/12800.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12800/head:pull/12800 PR: https://git.openjdk.org/jdk/pull/12800 From rriggs at openjdk.org Wed Mar 1 18:12:16 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 1 Mar 2023 18:12:16 GMT Subject: RFR: 8302590: Add String.indexOf(int ch, int fromIndex, int toIndex) [v4] In-Reply-To: References: Message-ID: <28egP-6EyVP6cYpgmjVlVA3kp01EYS_6hAzuSVjM4G8=.ef9df799-eacc-4420-a85a-317d9c602532@github.com> On Wed, 1 Mar 2023 16:24:46 GMT, Raffaello Giulietti wrote: >> Add an `indexOf()` variant allowing to specify both a lower and an upper bound on the search. > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > 8302590: Add String.indexOf(int ch, int fromIndex, int toIndex) This is looking good. When the single char version settles, a separate issue/PR should consider adding `indexOf(String str, int fromIndex, int toIndex)` providing the similar index checking variant for finding strings. ------------- PR: https://git.openjdk.org/jdk/pull/12600 From jlu at openjdk.org Wed Mar 1 18:17:17 2023 From: jlu at openjdk.org (Justin Lu) Date: Wed, 1 Mar 2023 18:17:17 GMT Subject: Integrated: 8303232: java.util.Date.parse(String) and java.util.Date(String) don't declare thrown IllegalArgumentException In-Reply-To: <6S1UF7DvwvaGLJJhkX8DlBiV57SImGBxyDMLYohzfwU=.1937701d-8be4-4a1f-85e8-c6ad19ccc72a@github.com> References: <6S1UF7DvwvaGLJJhkX8DlBiV57SImGBxyDMLYohzfwU=.1937701d-8be4-4a1f-85e8-c6ad19ccc72a@github.com> Message-ID: On Tue, 28 Feb 2023 00:07:05 GMT, Justin Lu wrote: > The method `java.util.Date.parse(String)` and as a result, constructor `java.util.Date(String)` throw an `IllegalArgumentException`. This exception is not properly referenced in the javadoc, and this PR simply adds the throws javadoc tag to make it apparent. This pull request has now been integrated. Changeset: 05faa732 Author: Justin Lu Committer: Naoto Sato URL: https://git.openjdk.org/jdk/commit/05faa7321bc076794048d3d069fa36b14f42ca70 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod 8303232: java.util.Date.parse(String) and java.util.Date(String) don't declare thrown IllegalArgumentException Reviewed-by: jpai, lancea, naoto ------------- PR: https://git.openjdk.org/jdk/pull/12779 From bhuang at openjdk.org Wed Mar 1 18:18:20 2023 From: bhuang at openjdk.org (Bill Huang) Date: Wed, 1 Mar 2023 18:18:20 GMT Subject: RFR: JDK-8295859: Update Manual Test Groups [v6] In-Reply-To: References: Message-ID: <7agOByrqq6SNFqU0uUgstYRvIsHyiM1XPMbYYfy5sfQ=.66036225-0daf-4c6d-b32f-4e92612bada0@github.com> > This task is created to update the manual test groups. Bill Huang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: - Merge branch 'JDK-8295859' of gh:bwhuang-us/jdk into JDK-8295859 - Added missing manual tests from :jdk_core. - Removed performance tests from the jdk_core_manual group as they have been covered in the client-atr test groups - Merge master - Merge branch 'master' into JDK-8295859 - Updated Manual Test Groups - Moved Compatibility.java back to jdk_core_manual_no_input_security. - Removed unwanted backslash. - Added missing manual tests from :jdk_core. - Removed performance tests from the jdk_core_manual group as they have been covered in the client-atr test groups - ... and 1 more: https://git.openjdk.org/jdk/compare/4ce493f0...479c2eac ------------- Changes: https://git.openjdk.org/jdk/pull/10864/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10864&range=05 Stats: 24 lines in 1 file changed: 16 ins; 3 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/10864.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10864/head:pull/10864 PR: https://git.openjdk.org/jdk/pull/10864 From bhuang at openjdk.org Wed Mar 1 18:18:22 2023 From: bhuang at openjdk.org (Bill Huang) Date: Wed, 1 Mar 2023 18:18:22 GMT Subject: Withdrawn: JDK-8295859: Update Manual Test Groups In-Reply-To: References: Message-ID: On Tue, 25 Oct 2022 23:10:53 GMT, Bill Huang wrote: > This task is created to update the manual test groups. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/10864 From duke at openjdk.org Wed Mar 1 18:19:08 2023 From: duke at openjdk.org (Glavo) Date: Wed, 1 Mar 2023 18:19:08 GMT Subject: RFR: 8299807: newStringNoRepl should avoid copying arrays for ASCII compatible charsets In-Reply-To: References: Message-ID: On Fri, 27 Jan 2023 16:04:41 GMT, Roger Riggs wrote: >> This is the javadoc of `JavaLangAccess::newStringNoRepl`: >> >> >> /** >> * Constructs a new {@code String} by decoding the specified subarray of >> * bytes using the specified {@linkplain java.nio.charset.Charset charset}. >> * >> * The caller of this method shall relinquish and transfer the ownership of >> * the byte array to the callee since the later will not make a copy. >> * >> * @param bytes the byte array source >> * @param cs the Charset >> * @return the newly created string >> * @throws CharacterCodingException for malformed or unmappable bytes >> */ >> >> >> It is recorded in the document that it should be able to directly construct strings with parameter byte array to reduce array allocation. >> >> However, at present, `newStringNoRepl` always copies arrays for UTF-8 or other ASCII compatible charsets. >> >> This PR fixes this problem. > > It seems odd that the benchmark seems slower for smaller files; can you suggest why that might be? > I'd expect the size distribution for Files.readString to be biased toward the smaller files. > Can you repeat the benchmark using the default file system. OS file caching should eliminate the disk speed effects. @RogerRiggs I have revised it according to your suggestion. Can you have a look again? ------------- PR: https://git.openjdk.org/jdk/pull/12119 From rgiulietti at openjdk.org Wed Mar 1 18:21:14 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 1 Mar 2023 18:21:14 GMT Subject: RFR: 8302590: Add String.indexOf(int ch, int fromIndex, int toIndex) [v4] In-Reply-To: <28egP-6EyVP6cYpgmjVlVA3kp01EYS_6hAzuSVjM4G8=.ef9df799-eacc-4420-a85a-317d9c602532@github.com> References: <28egP-6EyVP6cYpgmjVlVA3kp01EYS_6hAzuSVjM4G8=.ef9df799-eacc-4420-a85a-317d9c602532@github.com> Message-ID: On Wed, 1 Mar 2023 18:09:32 GMT, Roger Riggs wrote: >> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: >> >> 8302590: Add String.indexOf(int ch, int fromIndex, int toIndex) > > This is looking good. > When the single char version settles, a separate issue/PR should consider adding `indexOf(String str, int fromIndex, int toIndex)` providing the similar index checking variant for finding strings. @RogerRiggs Yes, now that we settled on the "throwing" behavior, it is simpler to have a similar behavior with a future `indexOf(String str, int fromIndex, int toIndex)` ------------- PR: https://git.openjdk.org/jdk/pull/12600 From joe.darcy at oracle.com Wed Mar 1 18:21:07 2023 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Wed, 1 Mar 2023 10:21:07 -0800 Subject: RFR: JDK-8302027: Port fdlibm trig functions (sin, cos, tan) to Java In-Reply-To: References: Message-ID: On 3/1/2023 8:16 AM, Raffaello Giulietti wrote: > On Wed, 1 Mar 2023 14:27:09 GMT, Andrey Turbanov wrote: > >>> Last and certainly not least in the port of FDLIBM to Java, the transcendental methods for sin, cos, and tan. >>> >>> Some more tests are to be written in the StrictMath directory to verify that the StrictMath algorihtm for sin/cos/tan is being used rather than a different one. However, I wanted to get the rest of the change out for review first. >>> >>> The sin/cos/tan methods are grouped together since they share the same argument reduction logic. Argument reduction is the process of mapping an argument of a function to an argument in a restricted range (and possibly returning some function of the reduced argument). For sin, cos, and tan, since they are fundamentally periodic with respect to a multiple of pi, argument reduction is done to find the remainder of the original argument with respect to pi/2. >> src/java.base/share/classes/java/lang/FdLibm.java line 814: >> >>> 812: >>> 813: static final double >>> 814: twon24 = 0x1.0p-24; // 5.96046447753906250000e-08 >> Suggestion: >> >> twon24 = 0x1.0p-24; // 5.96046447753906250000e-08 > Would it be worthwhile to declare this as a compile time constant, similarly to `TWO24`? If it's used only here, then probably not. That particular constant is only used to implement one method. Since? TWO24 is used in two of the methods being ported in this PR, I pulled it out. (As I may have mentioned before, once all the FDLIBM methods are ported, I plan to make a few cleanup passes over the code, including pulling out any other common constants, etc.) -Joe From duke at openjdk.org Wed Mar 1 18:22:23 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Wed, 1 Mar 2023 18:22:23 GMT Subject: Integrated: 8303401: Add a Vector API equalsIgnoreCase micro benchmark In-Reply-To: References: Message-ID: On Tue, 28 Feb 2023 15:59:26 GMT, Eirik Bjorsnos wrote: > This PR suggests we add a vectorized equalsIgnoreCase benchmark to the set of benchmarks in `org.openjdk.bench.jdk.incubator.vector`. This benchmark serves as an example of how vectorization can be useful also in the area of text processing. It takes advantage of the fact that ASCII and Latin-1 were designed to optimize case-twiddling operations. > > The code came about during the work on #12632, where vectorization was deemed out of scope. > > Benchmark results: > > > Benchmark (size) Mode Cnt Score Error Units > EqualsIgnoreCaseBenchmark.scalar 16 avgt 15 21.575 ? 0.365 ns/op > EqualsIgnoreCaseBenchmark.scalar 32 avgt 15 43.199 ? 2.786 ns/op > EqualsIgnoreCaseBenchmark.scalar 64 avgt 15 71.389 ? 0.891 ns/op > EqualsIgnoreCaseBenchmark.scalar 128 avgt 15 146.827 ? 1.115 ns/op > EqualsIgnoreCaseBenchmark.scalar 1024 avgt 15 1062.759 ? 9.331 ns/op > EqualsIgnoreCaseBenchmark.vectorized 16 avgt 15 21.483 ? 0.121 ns/op > EqualsIgnoreCaseBenchmark.vectorized 32 avgt 15 10.538 ? 0.125 ns/op > EqualsIgnoreCaseBenchmark.vectorized 64 avgt 15 13.182 ? 0.177 ns/op > EqualsIgnoreCaseBenchmark.vectorized 128 avgt 15 19.192 ? 0.421 ns/op > EqualsIgnoreCaseBenchmark.vectorized 1024 avgt 15 92.521 ? 3.494 ns/op This pull request has now been integrated. Changeset: 9fc518ff Author: Eirik Bjorsnos Committer: Sandhya Viswanathan URL: https://git.openjdk.org/jdk/commit/9fc518ff8cadbbb731a016d8f53ed065b3561a7c Stats: 157 lines in 1 file changed: 157 ins; 0 del; 0 mod 8303401: Add a Vector API equalsIgnoreCase micro benchmark Reviewed-by: ecaspole, sviswanathan, psandoz ------------- PR: https://git.openjdk.org/jdk/pull/12790 From bpb at openjdk.org Wed Mar 1 18:23:43 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 1 Mar 2023 18:23:43 GMT Subject: RFR: 8303175: (fs) Deprecate com.sun.nio.file.SensitivityWatchEventModifier for removal [v4] In-Reply-To: References: Message-ID: > Deprecate `SensitivityWatchEventModifier` for now instead of directly removing it as proposed in #12626. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8303175: Change @deprecated verbiage in SensitivityWatchEventModifier ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12746/files - new: https://git.openjdk.org/jdk/pull/12746/files/f00174e5..45d63422 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12746&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12746&range=02-03 Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/12746.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12746/head:pull/12746 PR: https://git.openjdk.org/jdk/pull/12746 From dnsimon at openjdk.org Wed Mar 1 18:38:19 2023 From: dnsimon at openjdk.org (Doug Simon) Date: Wed, 1 Mar 2023 18:38:19 GMT Subject: RFR: 8303431: [JVMCI] libgraal annotation API Message-ID: This PR extends JVMCI with new API (`jdk.vm.ci.meta.Annotated`) for accessing annotations. The main differences from `java.lang.reflect.AnnotatedElement` are: * Each `Annotated` method explicitly specifies the annotation type(s) for which it wants annotation data. That is, there is no direct equivalent of `AnnotatedElement.getAnnotations()`. * Annotation data is returned in a map-like object (of type `jdk.vm.ci.meta.AnnotationData`) instead of in an `Annotation` object. This works better for libgraal as it avoids the need for annotation types to be loaded and included in libgraal. To demonstrate the new API, here's an example in terms `java.lang.reflect.AnnotatedElement` (which `ResolvedJavaType` implements): ResolvedJavaMethod method = ...; ExplodeLoop a = method.getAnnotation(ExplodeLoop.class); return switch (a.kind()) { case FULL_UNROLL -> LoopExplosionKind.FULL_UNROLL; case FULL_UNROLL_UNTIL_RETURN -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN; ... } The same code using the new API: ResolvedJavaMethod method = ...; ResolvedJavaType explodeLoopType = ...; AnnotationData a = method.getAnnotationDataFor(explodeLoopType); return switch (a.getEnum("kind").getName()) { case "FULL_UNROLL" -> LoopExplosionKind.FULL_UNROLL; case "FULL_UNROLL_UNTIL_RETURN" -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN; ... } The implementation relies on new methods in `jdk.internal.vm.VMSupport` for parsing annotations and serializing/deserializing to/from a byte array. This allows the annotation data to be passed from the HotSpot heap to the libgraal heap. ------------- Commit messages: - made AnnotationDataDecoder package-private - add annotation API to JVMCI Changes: https://git.openjdk.org/jdk/pull/12810/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12810&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303431 Stats: 2666 lines in 33 files changed: 2614 ins; 24 del; 28 mod Patch: https://git.openjdk.org/jdk/pull/12810.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12810/head:pull/12810 PR: https://git.openjdk.org/jdk/pull/12810 From prappo at openjdk.org Wed Mar 1 18:55:57 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Wed, 1 Mar 2023 18:55:57 GMT Subject: RFR: 8303473: Add implied {@code} in java.lang.invoke.MethodHandles Message-ID: Please review this trivial fix for _comments_. While some affected comments aren't doc comments and none of the affected comments partake in the API Documentation, it seems reasonable to be consistent. ------------- Commit messages: - Initial commit Changes: https://git.openjdk.org/jdk/pull/12811/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12811&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303473 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/12811.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12811/head:pull/12811 PR: https://git.openjdk.org/jdk/pull/12811 From jjg at openjdk.org Wed Mar 1 18:55:59 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Wed, 1 Mar 2023 18:55:59 GMT Subject: RFR: 8303473: Add implied {@code} in java.lang.invoke.MethodHandles In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 18:47:14 GMT, Pavel Rappo wrote: > Please review this trivial fix for _comments_. While some affected comments aren't doc comments and none of the affected comments partake in the API Documentation, it seems reasonable to be consistent. Marked as reviewed by jjg (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12811 From alanb at openjdk.org Wed Mar 1 18:57:24 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 1 Mar 2023 18:57:24 GMT Subject: RFR: 8302590: Add String.indexOf(int ch, int fromIndex, int toIndex) [v4] In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 16:24:46 GMT, Raffaello Giulietti wrote: >> Add an `indexOf()` variant allowing to specify both a lower and an upper bound on the search. > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > 8302590: Add String.indexOf(int ch, int fromIndex, int toIndex) src/java.base/share/classes/java/lang/String.java line 2435: > 2433: * @apiNote > 2434: * An invocation of this method returns -1 when {@code fromIndex} happens > 2435: * to be too large. The result is thus indistinguishable from a genuine Adding an apiNote to the existing indexOf(int, int) is good but I think it will need a bit word smithing, e.g. "happens to be too large" is a bit too casual. I think I would start with saying the method returns -1 if fromFrom is negative or >= the string length, it does not throw an exception if called with an out of range index. src/java.base/share/classes/java/lang/String.java line 2484: > 2482: * is negative, or {@code toIndex} is larger than the length of > 2483: * this {@code String} object, or {@code fromIndex} is larger than > 2484: * {@code toIndex}. Thanks for the update, I think you've got to a good place. ------------- PR: https://git.openjdk.org/jdk/pull/12600 From prappo at openjdk.org Wed Mar 1 19:07:40 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Wed, 1 Mar 2023 19:07:40 GMT Subject: RFR: 8303473: Add implied {@code} in java.lang.invoke.MethodHandles [v2] In-Reply-To: References: Message-ID: > Please review this trivial fix for _comments_. While some affected comments aren't doc comments and none of the affected comments partake in the API Documentation, it seems reasonable to be consistent. Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: fix!: mistyped {@code} ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12811/files - new: https://git.openjdk.org/jdk/pull/12811/files/656177c4..17d9c07d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12811&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12811&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12811.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12811/head:pull/12811 PR: https://git.openjdk.org/jdk/pull/12811 From lancea at openjdk.org Wed Mar 1 19:07:40 2023 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 1 Mar 2023 19:07:40 GMT Subject: RFR: 8303473: Add implied {@code} in java.lang.invoke.MethodHandles [v2] In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 19:03:32 GMT, Pavel Rappo wrote: >> Please review this trivial fix for _comments_. While some affected comments aren't doc comments and none of the affected comments partake in the API Documentation, it seems reasonable to be consistent. > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > fix!: mistyped {@code} Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12811 From prappo at openjdk.org Wed Mar 1 19:07:40 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Wed, 1 Mar 2023 19:07:40 GMT Subject: RFR: 8303473: Add implied {@code} in java.lang.invoke.MethodHandles In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 18:47:14 GMT, Pavel Rappo wrote: > Please review this trivial fix for _comments_. While some affected comments aren't doc comments and none of the affected comments partake in the API Documentation, it seems reasonable to be consistent. Inadvertently found one more typo and fixed it in 17d9c07. Unlike other typos in this PR, that one crept into JDK Documentation. Please (re)review this PR. ------------- PR: https://git.openjdk.org/jdk/pull/12811 From lancea at openjdk.org Wed Mar 1 19:12:05 2023 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 1 Mar 2023 19:12:05 GMT Subject: RFR: 8303473: Add implied {@code} in java.lang.invoke.MethodHandles [v2] In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 19:07:40 GMT, Pavel Rappo wrote: >> Please review this trivial fix for _comments_. While some affected comments aren't doc comments and none of the affected comments partake in the API Documentation, it seems reasonable to be consistent. > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > fix!: mistyped {@code} Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12811 From rgiulietti at openjdk.org Wed Mar 1 19:35:48 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 1 Mar 2023 19:35:48 GMT Subject: RFR: 8302590: Add String.indexOf(int ch, int fromIndex, int toIndex) [v5] In-Reply-To: References: Message-ID: <2oVKdfKGoshG_2qazy_WoHY6Qsz7bMnmLm4pzevsdZg=.06ef869b-4efb-400b-b2f3-2fabfafc8a1e@github.com> > Add an `indexOf()` variant allowing to specify both a lower and an upper bound on the search. Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: 8302590: Add String.indexOf(int ch, int fromIndex, int toIndex) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12600/files - new: https://git.openjdk.org/jdk/pull/12600/files/1eca562b..de297ef1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12600&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12600&range=03-04 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/12600.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12600/head:pull/12600 PR: https://git.openjdk.org/jdk/pull/12600 From rgiulietti at openjdk.org Wed Mar 1 19:37:16 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 1 Mar 2023 19:37:16 GMT Subject: RFR: 8302590: Add String.indexOf(int ch, int fromIndex, int toIndex) [v4] In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 18:54:09 GMT, Alan Bateman wrote: >> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: >> >> 8302590: Add String.indexOf(int ch, int fromIndex, int toIndex) > > src/java.base/share/classes/java/lang/String.java line 2435: > >> 2433: * @apiNote >> 2434: * An invocation of this method returns -1 when {@code fromIndex} happens >> 2435: * to be too large. The result is thus indistinguishable from a genuine > > Adding an apiNote to the existing indexOf(int, int) is good but I think it will need a bit word smithing, e.g. "happens to be too large" is a bit too casual. I think I would start with saying the method returns -1 if fromFrom is negative or >= the string length, it does not throw an exception if called with an out of range index. Done. (A negative `fromIndex` does not necessarily result in -1, though.) > src/java.base/share/classes/java/lang/String.java line 2484: > >> 2482: * is negative, or {@code toIndex} is larger than the length of >> 2483: * this {@code String} object, or {@code fromIndex} is larger than >> 2484: * {@code toIndex}. > > Thanks for the update, I think you've got to a good place. @stuart-marks was quite convincing ;-) ------------- PR: https://git.openjdk.org/jdk/pull/12600 From naoto at openjdk.org Wed Mar 1 19:59:05 2023 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 1 Mar 2023 19:59:05 GMT Subject: RFR: 8303039: Utilize `coverageLevels.txt` Message-ID: This is a pre-requisite for supporting CLDR v43, where they combine `seeds` locales with `common` locales (https://cldr.unicode.org/index/downloads/cldr-43#h.7s25aqdv767e). In order to have the same coverage level of locales, CLDRConverter tool needs to comb through the locale files based on the `coverageLevels.txt` file, (and the ones we already included as of v42). Confirmed the same set of locales is generated before and after this modification. ------------- Commit messages: - 8303039: Utilize `coverageLevels.txt` Changes: https://git.openjdk.org/jdk/pull/12812/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12812&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303039 Stats: 318 lines in 4 files changed: 314 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/12812.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12812/head:pull/12812 PR: https://git.openjdk.org/jdk/pull/12812 From aturbanov at openjdk.org Wed Mar 1 20:23:13 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Wed, 1 Mar 2023 20:23:13 GMT Subject: RFR: 8303266: Prefer ArrayList to LinkedList in JImageTask In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 01:32:39 GMT, Roger Riggs wrote: >In choosing how you spend your time, make your efforts and the efforts of the reviewers count for something. It's one of the reasons, why I don't create PRs with massive replacements. I carefully choose places in the code, where I think replacement is 100% safe. In this case we have a `final` field which has only 3 simple usages. Reviewing such small PR shouldn't take more than like 15 minutes. >If you want people to stop using LinkedList, it will be much more effective to get to say "use ArrayList instead of LinkedList" Not sure I agree with this one. Even presence issues/PRs like this in JDK, could be used as an argument between developers, who need to choose what's better. ------------- PR: https://git.openjdk.org/jdk/pull/12760 From psandoz at openjdk.org Wed Mar 1 20:36:05 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Wed, 1 Mar 2023 20:36:05 GMT Subject: RFR: 8294982: Implementation of Classfile API [v31] In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 15:00:41 GMT, Adam Sotona wrote: >> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. >> >> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. >> >> Classfile API development is tracked at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch >> >> Development branch of consolidated JDK class files parsing, generating, and transforming is at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch >> >> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. >> >> Please take you time to review this non-trivial JDK addition. >> >> Thank you, >> Adam > > Adam Sotona has updated the pull request incrementally with four additional commits since the last revision: > > - renamed all remaining ConcreteXyzEntry to XyzEntryImpl > - abstract implementations of RefEntry, RefsEntry and NamedEntry renamed to AbstractRefEntry, AbstractRefsEntry and AbstractNamedEntry > - renamed ConcreteBootstrapMethodEntry to BootstrapMethodEntryImpl > - ConcreteEntry renamed to AbstractPoolEntry src/java.base/share/classes/jdk/internal/classfile/snippet-files/PackageSnippets.java line 111: > 109: Set dependencies = cm.elementStream() > 110: .filter(ce -> ce instanceof MethodModel) > 111: .flatMap(ce -> ((MethodModel) ce).elementStream()) You could potentially collapse this into a single `flatMap` and avoid the cast: .flatMap(ce -> ce instanceof MethodMethod mm ? mm.elementStream() : Stream.empty()) ------------- PR: https://git.openjdk.org/jdk/pull/10982 From mchung at openjdk.org Wed Mar 1 20:39:27 2023 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 1 Mar 2023 20:39:27 GMT Subject: RFR: 8303473: Add implied {@code} in java.lang.invoke.MethodHandles [v2] In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 19:07:40 GMT, Pavel Rappo wrote: >> Please review this trivial fix for _comments_. While some affected comments aren't doc comments and none of the affected comments partake in the API Documentation, it seems reasonable to be consistent. > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > fix!: mistyped {@code} Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12811 From jjg at openjdk.org Wed Mar 1 20:49:06 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Wed, 1 Mar 2023 20:49:06 GMT Subject: RFR: 8303473: Add implied {@code} in java.lang.invoke.MethodHandles [v2] In-Reply-To: References: Message-ID: <3rsEVGHuJ7sz1g1GyJnUrIuDaNAncIpcsElVnQGtLFk=.156586cd-46f3-48b4-90bf-73d7a35e2b17@github.com> On Wed, 1 Mar 2023 19:07:40 GMT, Pavel Rappo wrote: >> Please review this trivial fix for _comments_. While some affected comments aren't doc comments and none of the affected comments partake in the API Documentation, it seems reasonable to be consistent. > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > fix!: mistyped {@code} Marked as reviewed by jjg (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12811 From lmesnik at openjdk.org Wed Mar 1 20:58:02 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 1 Mar 2023 20:58:02 GMT Subject: RFR: 8303486: [REDO] Update ProcessTools.startProcess(...) to exit early if process exit before linePredicate is printed. Message-ID: It is the 2nd attempt to fix [JDK-8303133](https://bugs.openjdk.org/browse/JDK-8303133) Update ProcessTools.startProcess(...) to exit early if the process exit before linePredicate is printed. The first fix failed because it runs Utils.waitForCondition(BooleanSupplier condition, long timeout, long sleepTime) { ..} with 0 as no timeout and not -1 as required. ------------- Commit messages: - the additional fix - Revert "8303421: [BACKOUT] 8303133: Update ProcessTools.startProcess(...) to exit early if process exit before linePredicate is printed." Changes: https://git.openjdk.org/jdk/pull/12815/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12815&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303486 Stats: 31 lines in 2 files changed: 18 ins; 3 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/12815.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12815/head:pull/12815 PR: https://git.openjdk.org/jdk/pull/12815 From psandoz at openjdk.org Wed Mar 1 21:39:39 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Wed, 1 Mar 2023 21:39:39 GMT Subject: RFR: 8294982: Implementation of Classfile API [v31] In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 15:00:41 GMT, Adam Sotona wrote: >> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. >> >> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. >> >> Classfile API development is tracked at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch >> >> Development branch of consolidated JDK class files parsing, generating, and transforming is at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch >> >> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. >> >> Please take you time to review this non-trivial JDK addition. >> >> Thank you, >> Adam > > Adam Sotona has updated the pull request incrementally with four additional commits since the last revision: > > - renamed all remaining ConcreteXyzEntry to XyzEntryImpl > - abstract implementations of RefEntry, RefsEntry and NamedEntry renamed to AbstractRefEntry, AbstractRefsEntry and AbstractNamedEntry > - renamed ConcreteBootstrapMethodEntry to BootstrapMethodEntryImpl > - ConcreteEntry renamed to AbstractPoolEntry src/java.base/share/classes/jdk/internal/classfile/constantpool/ClassEntry.java line 48: > 46: default ConstantDesc constantValue() { > 47: return asSymbol(); > 48: } It seems possible to use this pattern consistently for `ConstantDynamicEntry`, `MethodHandleEntry`, and `MethodTypeEntry`? At first i thought why not make `asSymbol` a covariant override of `constantValue`, but its not the same thing, since there are constant values (subtypes of `ConstantValueEntry`) that are not symbols. ------------- PR: https://git.openjdk.org/jdk/pull/10982 From psandoz at openjdk.org Wed Mar 1 22:02:40 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Wed, 1 Mar 2023 22:02:40 GMT Subject: RFR: 8294982: Implementation of Classfile API [v31] In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 15:00:41 GMT, Adam Sotona wrote: >> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. >> >> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. >> >> Classfile API development is tracked at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch >> >> Development branch of consolidated JDK class files parsing, generating, and transforming is at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch >> >> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. >> >> Please take you time to review this non-trivial JDK addition. >> >> Thank you, >> Adam > > Adam Sotona has updated the pull request incrementally with four additional commits since the last revision: > > - renamed all remaining ConcreteXyzEntry to XyzEntryImpl > - abstract implementations of RefEntry, RefsEntry and NamedEntry renamed to AbstractRefEntry, AbstractRefsEntry and AbstractNamedEntry > - renamed ConcreteBootstrapMethodEntry to BootstrapMethodEntryImpl > - ConcreteEntry renamed to AbstractPoolEntry src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java line 376: > 374: } else if (o instanceof Utf8Entry u) { > 375: return equalsString(u.stringValue()); > 376: } Dead branch? since there is only one concrete implementation of `Utf8Entry`. ------------- PR: https://git.openjdk.org/jdk/pull/10982 From jlu at openjdk.org Wed Mar 1 22:03:57 2023 From: jlu at openjdk.org (Justin Lu) Date: Wed, 1 Mar 2023 22:03:57 GMT Subject: RFR: 8303275: Use {@Return and @linkplain in Locale and related classes Message-ID: <9XzLdPaTCaYpzrJStx2riu1ZTMIYEgZOkPIy_CgK5jk=.0ec33845-108e-4651-9e6e-6be6c7cc3ef4@github.com> This PR modifies the javadoc of methods in Locale, LocaleServiceProvider, and LocaleServiceProviderPool to use {@return and @linkplain. ------------- Commit messages: - fix conflicts - Locale copyright - Use @linkplain and {@return in Locale - Use {@return and spacing in LSPP - Use {@return and @linkplain in LSP Changes: https://git.openjdk.org/jdk/pull/12780/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12780&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303275 Stats: 107 lines in 3 files changed: 11 ins; 19 del; 77 mod Patch: https://git.openjdk.org/jdk/pull/12780.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12780/head:pull/12780 PR: https://git.openjdk.org/jdk/pull/12780 From jlu at openjdk.org Wed Mar 1 22:04:12 2023 From: jlu at openjdk.org (Justin Lu) Date: Wed, 1 Mar 2023 22:04:12 GMT Subject: RFR: 8303275: Use {@Return and @linkplain in Locale and related classes In-Reply-To: <9XzLdPaTCaYpzrJStx2riu1ZTMIYEgZOkPIy_CgK5jk=.0ec33845-108e-4651-9e6e-6be6c7cc3ef4@github.com> References: <9XzLdPaTCaYpzrJStx2riu1ZTMIYEgZOkPIy_CgK5jk=.0ec33845-108e-4651-9e6e-6be6c7cc3ef4@github.com> Message-ID: On Tue, 28 Feb 2023 00:09:45 GMT, Justin Lu wrote: > This PR modifies the javadoc of methods in Locale, LocaleServiceProvider, and LocaleServiceProviderPool to use {@return and @linkplain. src/java.base/share/classes/java/util/Locale.java line 1200: > 1198: > 1199: /** > 1200: * {@return an array of installed locales} Same as above, differs with "all" src/java.base/share/classes/java/util/Locale.java line 1239: > 1237: > 1238: /** > 1239: * {@return a {@code Set} of ISO3166 country codes for the specified type} This and other instances will have the Returns ... and @return ... differ by a single word. Such as _Returns a {@code Set} of ISO3166 country..._ vs _ at return a {@code Set} of ISO country..._ {@return is used when the Returns ... and @return ... are identical. I want to double check that using {@return for these instances is acceptable (even though they are technically not identical), if not I can revert them. src/java.base/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java line 151: > 149: > 150: /** > 151: * {@return an array of the available locales for all the provider classes} Same as above, differs with "the" src/java.base/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java line 161: > 159: > 160: /** > 161: * {@return an array of the available locales} Same as above, differs with "the" ------------- PR: https://git.openjdk.org/jdk/pull/12780 From jlu at openjdk.org Wed Mar 1 22:06:13 2023 From: jlu at openjdk.org (Justin Lu) Date: Wed, 1 Mar 2023 22:06:13 GMT Subject: RFR: 8303472: Display name for region TR Message-ID: This PR changes the English name for the region `TR`, from `Turkey` to `T?rkiye`. Although this change is included in the upcoming CLDR v43, it should be applied as a spot change so that it can be back-ported properly (As it is a common English region name). This change targets both the CLDR and COMPAT data. ------------- Commit messages: - Spot change TR for COMPAT - Spot change TR region name Changes: https://git.openjdk.org/jdk/pull/12816/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12816&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303472 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/12816.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12816/head:pull/12816 PR: https://git.openjdk.org/jdk/pull/12816 From psandoz at openjdk.org Wed Mar 1 22:19:39 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Wed, 1 Mar 2023 22:19:39 GMT Subject: RFR: 8294982: Implementation of Classfile API [v31] In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 15:00:41 GMT, Adam Sotona wrote: >> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. >> >> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. >> >> Classfile API development is tracked at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch >> >> Development branch of consolidated JDK class files parsing, generating, and transforming is at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch >> >> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. >> >> Please take you time to review this non-trivial JDK addition. >> >> Thank you, >> Adam > > Adam Sotona has updated the pull request incrementally with four additional commits since the last revision: > > - renamed all remaining ConcreteXyzEntry to XyzEntryImpl > - abstract implementations of RefEntry, RefsEntry and NamedEntry renamed to AbstractRefEntry, AbstractRefsEntry and AbstractNamedEntry > - renamed ConcreteBootstrapMethodEntry to BootstrapMethodEntryImpl > - ConcreteEntry renamed to AbstractPoolEntry src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPool.java line 49: > 47: import static jdk.internal.classfile.Classfile.TAG_STRING; > 48: import static jdk.internal.classfile.Classfile.TAG_UTF8; > 49: Unused imports, perhaps sweep through all classes (i think it can be done over multiple packages with IntelliJ). ------------- PR: https://git.openjdk.org/jdk/pull/10982 From psandoz at openjdk.org Wed Mar 1 22:23:42 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Wed, 1 Mar 2023 22:23:42 GMT Subject: RFR: 8294982: Implementation of Classfile API [v31] In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 15:00:41 GMT, Adam Sotona wrote: >> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. >> >> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. >> >> Classfile API development is tracked at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch >> >> Development branch of consolidated JDK class files parsing, generating, and transforming is at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch >> >> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. >> >> Please take you time to review this non-trivial JDK addition. >> >> Thank you, >> Adam > > Adam Sotona has updated the pull request incrementally with four additional commits since the last revision: > > - renamed all remaining ConcreteXyzEntry to XyzEntryImpl > - abstract implementations of RefEntry, RefsEntry and NamedEntry renamed to AbstractRefEntry, AbstractRefsEntry and AbstractNamedEntry > - renamed ConcreteBootstrapMethodEntry to BootstrapMethodEntryImpl > - ConcreteEntry renamed to AbstractPoolEntry src/java.base/share/classes/jdk/internal/classfile/constantpool/ClassEntry.java line 71: > 69: * @return the combined {@link List} > 70: */ > 71: static List adding(List base, List additions) { This and all the other following static methods seem more like implementation details rather than part of the public API? ------------- PR: https://git.openjdk.org/jdk/pull/10982 From psandoz at openjdk.org Wed Mar 1 22:33:40 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Wed, 1 Mar 2023 22:33:40 GMT Subject: RFR: 8294982: Implementation of Classfile API [v31] In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 15:00:41 GMT, Adam Sotona wrote: >> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. >> >> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. >> >> Classfile API development is tracked at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch >> >> Development branch of consolidated JDK class files parsing, generating, and transforming is at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch >> >> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. >> >> Please take you time to review this non-trivial JDK addition. >> >> Thank you, >> Adam > > Adam Sotona has updated the pull request incrementally with four additional commits since the last revision: > > - renamed all remaining ConcreteXyzEntry to XyzEntryImpl > - abstract implementations of RefEntry, RefsEntry and NamedEntry renamed to AbstractRefEntry, AbstractRefsEntry and AbstractNamedEntry > - renamed ConcreteBootstrapMethodEntry to BootstrapMethodEntryImpl > - ConcreteEntry renamed to AbstractPoolEntry src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPoolBuilder.java line 222: > 220: * @param typeEntry the member field or method descriptor > 221: */ > 222: NameAndTypeEntry natEntry(Utf8Entry nameEntry, Utf8Entry typeEntry); I would be inclined to rename more literally as `nameAndTypeEntry`, which is consistent with the naming convention in all other cases in this interface AFAICT (edit: almost i also see `bsm`) . (FWIW i keep reading nat as "not a type"!) ------------- PR: https://git.openjdk.org/jdk/pull/10982 From rgiulietti at openjdk.org Wed Mar 1 22:36:00 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 1 Mar 2023 22:36:00 GMT Subject: RFR: 8302590: Add String.indexOf(int ch, int fromIndex, int toIndex) [v6] In-Reply-To: References: Message-ID: > Add an `indexOf()` variant allowing to specify both a lower and an upper bound on the search. Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: 8302590: Add String.indexOf(int ch, int fromIndex, int toIndex) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12600/files - new: https://git.openjdk.org/jdk/pull/12600/files/de297ef1..dfd953f9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12600&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12600&range=04-05 Stats: 11 lines in 1 file changed: 4 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/12600.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12600/head:pull/12600 PR: https://git.openjdk.org/jdk/pull/12600 From psandoz at openjdk.org Wed Mar 1 22:47:51 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Wed, 1 Mar 2023 22:47:51 GMT Subject: RFR: 8294982: Implementation of Classfile API [v31] In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 15:00:41 GMT, Adam Sotona wrote: >> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. >> >> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. >> >> Classfile API development is tracked at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch >> >> Development branch of consolidated JDK class files parsing, generating, and transforming is at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch >> >> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. >> >> Please take you time to review this non-trivial JDK addition. >> >> Thank you, >> Adam > > Adam Sotona has updated the pull request incrementally with four additional commits since the last revision: > > - renamed all remaining ConcreteXyzEntry to XyzEntryImpl > - abstract implementations of RefEntry, RefsEntry and NamedEntry renamed to AbstractRefEntry, AbstractRefsEntry and AbstractNamedEntry > - renamed ConcreteBootstrapMethodEntry to BootstrapMethodEntryImpl > - ConcreteEntry renamed to AbstractPoolEntry src/java.base/share/classes/jdk/internal/classfile/impl/SplitConstantPool.java line 167: > 165: buf.patchInt(pos + 2, 4, attrLen - 6); > 166: buf.patchInt(pos + 6, 2, bsmSize); > 167: return true; The if and else branch return true, factor out at the end of the method? src/java.base/share/classes/jdk/internal/classfile/impl/SplitConstantPool.java line 339: > 337: } > 338: > 339: private AbstractPoolEntry.Utf8EntryImpl tryFindUtf8(int hash, String target) { Unused type variable `T` src/java.base/share/classes/jdk/internal/classfile/impl/SplitConstantPool.java line 488: > 486: return methodHandleEntry(refKind, reference); > 487: } > 488: return internalAdd(new AbstractPoolEntry.MethodHandleEntryImpl(this, size, hash, refKind, (AbstractPoolEntry.AbstractMemberRefEntry) reference), hash); Break the long line (same for two following methods). src/java.base/share/classes/jdk/internal/classfile/impl/TemporaryConstantPool.java line 56: > 54: public final class TemporaryConstantPool implements ConstantPoolBuilder { > 55: > 56: private TemporaryConstantPool() {}; Suggestion: private TemporaryConstantPool() {} ------------- PR: https://git.openjdk.org/jdk/pull/10982 From smarks at openjdk.org Wed Mar 1 22:51:12 2023 From: smarks at openjdk.org (Stuart Marks) Date: Wed, 1 Mar 2023 22:51:12 GMT Subject: RFR: 8303266: Prefer ArrayList to LinkedList in JImageTask In-Reply-To: References: Message-ID: On Mon, 27 Feb 2023 11:33:38 GMT, Andrey Turbanov wrote: > `LinkedList` is used as a field `jdk.tools.jimage.JImageTask.OptionsValues#jimages` > It's created, filled (with `add`) and then iterated. No removes from the head or something like this. `ArrayList` should be preferred as more efficient and widely used (more chances for JIT) collection. Sorry, there was a markup error in my earlier comment. What I meant it to say was this: ? If you want people to stop using LinkedList, it will be much more effective to get _your favorite tutorial site_ to say "use ArrayList instead of LinkedList" instead of trying to remove uses of it from the JDK. ? (I had put the italicized text in angle brackets, which I guess were interpreted as malformed markup and so the text was simply dropped.) I might as well name names here. If you do a web search for "java LinkedList" you will get hits on the usual top tutorial sites. One of them is this: https://www.w3schools.com/java/java_linkedlist.asp The whole discussion of "ArrayList vs. LinkedList" here is incredibly superficial. The summary is this: > Use an ArrayList for storing and accessing data, and LinkedList to manipulate data. This sort of statement is a lot more influential in getting Java developers to use LinkedList than anything the JDK does. Orders of magnitude more Java developers look at these tutorial sites than look at obscure corners of the JDK source code. If you want people to stop using LinkedList, it would be better to try to get those tutorial sites changed than to try to eradicate LinkedList from the JDK. ------------- PR: https://git.openjdk.org/jdk/pull/12760 From naoto at openjdk.org Wed Mar 1 22:58:22 2023 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 1 Mar 2023 22:58:22 GMT Subject: RFR: 8303472: Display name for region TR In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 21:58:00 GMT, Justin Lu wrote: > This PR changes the English name for the region `TR`, from `Turkey` to `T?rkiye`. Although this change is included in the upcoming CLDR v43, it should be applied as a spot change so that it can be back-ported properly (As it is a common English region name). > > > > This change targets both the CLDR and COMPAT data. Please supply test cases with these changes (`sun/text/resources/LocaleDataTest.java`), also copyright year changes for COMPAT properties. Otherwise LGTM src/java.base/share/classes/sun/util/resources/LocaleNames.properties line 1097: > 1095: TN=Tunisia > 1096: TO=Tonga > 1097: TR=T?rkiye I believe this is fine, but please confirm that this ends up correct u-umlaut when you get the text. It is somewhat a rare case where ISO-8859-1 has the character and the byte sequence differs between ISO-8859-1 and UTF-8. ------------- PR: https://git.openjdk.org/jdk/pull/12816 From psandoz at openjdk.org Wed Mar 1 23:02:38 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Wed, 1 Mar 2023 23:02:38 GMT Subject: RFR: 8294982: Implementation of Classfile API [v31] In-Reply-To: References: Message-ID: <4jPs8a8ZF09ZrN9zwZuBsgyZd43I6IJSDZetUdGkPyc=.7164a3c0-584f-41a7-a543-83bbbcbf9639@github.com> On Wed, 1 Mar 2023 15:00:41 GMT, Adam Sotona wrote: >> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. >> >> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. >> >> Classfile API development is tracked at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch >> >> Development branch of consolidated JDK class files parsing, generating, and transforming is at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch >> >> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. >> >> Please take you time to review this non-trivial JDK addition. >> >> Thank you, >> Adam > > Adam Sotona has updated the pull request incrementally with four additional commits since the last revision: > > - renamed all remaining ConcreteXyzEntry to XyzEntryImpl > - abstract implementations of RefEntry, RefsEntry and NamedEntry renamed to AbstractRefEntry, AbstractRefsEntry and AbstractNamedEntry > - renamed ConcreteBootstrapMethodEntry to BootstrapMethodEntryImpl > - ConcreteEntry renamed to AbstractPoolEntry src/java.base/share/classes/jdk/internal/classfile/ClassReader.java line 270: > 268: int classReaderOffset, > 269: int length); > 270: } Suggestion: } src/java.base/share/classes/jdk/internal/classfile/impl/ClassReaderImpl.java line 90: > 88: private BootstrapMethodsAttribute bootstrapMethodsAttribute; > 89: > 90: @SuppressWarnings("unchecked") Is this needed? src/java.base/share/classes/jdk/internal/classfile/impl/ClassReaderImpl.java line 115: > 113: > 114: // 4 > 115: case TAG_CONSTANTDYNAMIC, TAG_FIELDREF, TAG_FLOAT, TAG_INTEGER, TAG_INTERFACEMETHODREF, TAG_INVOKEDYNAMIC, TAG_METHODREF, TAG_NAMEANDTYPE -> p += 4; Break the line src/java.base/share/classes/jdk/internal/classfile/impl/ClassReaderImpl.java line 132: > 130: this.cp = new PoolEntry[constantPoolCount]; > 131: > 132: p = metadataStart; Redundant assignment (see line 127). ------------- PR: https://git.openjdk.org/jdk/pull/10982 From psandoz at openjdk.org Wed Mar 1 23:10:45 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Wed, 1 Mar 2023 23:10:45 GMT Subject: RFR: 8294982: Implementation of Classfile API [v31] In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 15:00:41 GMT, Adam Sotona wrote: >> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. >> >> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. >> >> Classfile API development is tracked at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch >> >> Development branch of consolidated JDK class files parsing, generating, and transforming is at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch >> >> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. >> >> Please take you time to review this non-trivial JDK addition. >> >> Thank you, >> Adam > > Adam Sotona has updated the pull request incrementally with four additional commits since the last revision: > > - renamed all remaining ConcreteXyzEntry to XyzEntryImpl > - abstract implementations of RefEntry, RefsEntry and NamedEntry renamed to AbstractRefEntry, AbstractRefsEntry and AbstractNamedEntry > - renamed ConcreteBootstrapMethodEntry to BootstrapMethodEntryImpl > - ConcreteEntry renamed to AbstractPoolEntry src/java.base/share/classes/jdk/internal/classfile/ClassReader.java line 144: > 142: * constant pool size, or zero > 143: * @throws ClassCastException if the index does not correspond to > 144: * a module entry Throwing `ClassCastException` is certainly convenient from an implementation perspective, but I think it is better to throw `IllegalArgumentException`. ------------- PR: https://git.openjdk.org/jdk/pull/10982 From duke at openjdk.org Wed Mar 1 23:14:06 2023 From: duke at openjdk.org (Steven R. Loomis) Date: Wed, 1 Mar 2023 23:14:06 GMT Subject: RFR: 8303039: Utilize `coverageLevels.txt` In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 19:50:56 GMT, Naoto Sato wrote: > This is a pre-requisite for supporting CLDR v43, where they combine `seeds` locales with `common` locales (https://cldr.unicode.org/index/downloads/cldr-43#h.7s25aqdv767e). In order to have the same coverage level of locales, CLDRConverter tool needs to comb through the locale files based on the `coverageLevels.txt` file, (and the ones we already included as of v42). Confirmed the same set of locales is generated before and after this modification. Marked as reviewed by srl295 at github.com (no known OpenJDK username). make/data/cldr/common/properties/coverageLevels.txt line 2: > 1: # coverageLevels.txt > 2: # Copyright ? 2022 Unicode, Inc. older version? make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java line 1212: > 1210: a -> Locale.forLanguageTag(a[0].trim().replaceAll("_", "-")), > 1211: a -> a[1].trim(), > 1212: (v1, v2) -> v2, this will grab all listed entries. Right now, that will get you basic and above. Ideally you would include if `v1` is one of `(basic|moderate|modern|comprehensive)` ??I'm proposing to add `core` or maybe even `undefined` locales in this list (though no consensus yet) make/jdk/src/classes/build/tools/cldrconverter/OtherCommonLocales.properties line 140: > 138: > 139: # Not listed, but existed > 140: sr-Latn=Serbian (Latin) [CLDR-16449](https://unicode-org.atlassian.net/browse/CLDR-16449) ------------- PR: https://git.openjdk.org/jdk/pull/12812 From duke at openjdk.org Wed Mar 1 23:14:09 2023 From: duke at openjdk.org (Steven R. Loomis) Date: Wed, 1 Mar 2023 23:14:09 GMT Subject: RFR: 8303039: Utilize `coverageLevels.txt` In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 23:02:06 GMT, Steven R. Loomis wrote: >> This is a pre-requisite for supporting CLDR v43, where they combine `seeds` locales with `common` locales (https://cldr.unicode.org/index/downloads/cldr-43#h.7s25aqdv767e). In order to have the same coverage level of locales, CLDRConverter tool needs to comb through the locale files based on the `coverageLevels.txt` file, (and the ones we already included as of v42). Confirmed the same set of locales is generated before and after this modification. > > make/data/cldr/common/properties/coverageLevels.txt line 2: > >> 1: # coverageLevels.txt >> 2: # Copyright ? 2022 Unicode, Inc. > > older version? is this from the alpha2 drop? or v42's? > make/jdk/src/classes/build/tools/cldrconverter/OtherCommonLocales.properties line 140: > >> 138: >> 139: # Not listed, but existed >> 140: sr-Latn=Serbian (Latin) > > [CLDR-16449](https://unicode-org.atlassian.net/browse/CLDR-16449) you might want to give yourself a task to periodically review this file. ------------- PR: https://git.openjdk.org/jdk/pull/12812 From duke at openjdk.org Wed Mar 1 23:17:06 2023 From: duke at openjdk.org (Steven R. Loomis) Date: Wed, 1 Mar 2023 23:17:06 GMT Subject: RFR: 8303039: Utilize `coverageLevels.txt` In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 19:50:56 GMT, Naoto Sato wrote: > This is a pre-requisite for supporting CLDR v43, where they combine `seeds` locales with `common` locales (https://cldr.unicode.org/index/downloads/cldr-43#h.7s25aqdv767e). In order to have the same coverage level of locales, CLDRConverter tool needs to comb through the locale files based on the `coverageLevels.txt` file, (and the ones we already included as of v42). Confirmed the same set of locales is generated before and after this modification. my openjdk name should be `srl` ???i'm still there https://openjdk.org/census#srl ------------- PR: https://git.openjdk.org/jdk/pull/12812 From duke at openjdk.org Wed Mar 1 23:21:18 2023 From: duke at openjdk.org (Saint Wesonga) Date: Wed, 1 Mar 2023 23:21:18 GMT Subject: RFR: 8303409: Add Windows AArch64 ABI support to the Foreign Function & Memory API Message-ID: There are 2 primary differences between the Windows ARM64 ABI and the macOS/Linux ARM64 ABI: variadic floating point arguments are passed in general purpose registers on Windows (instead of the vector registers). In addition to this, up to 64 bytes of a struct being passed to a variadic function can be placed in general purpose registers. This happens regardless of the type of struct (HFA or other generic struct). This means that a struct can be split across registers and the stack when invoking a variadic function. The Windows ARM64 ABI conventions are documented at https://learn.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions For details about the Foreign Function & Memory API, see JEP 434 at https://openjdk.org/jeps/434 This change is a cherry pick of https://github.com/openjdk/panama-foreign/commit/d379ca1c and https://github.com/openjdk/panama-foreign/commit/08225e4f from https://github.com/openjdk/panama-foreign/pull/754 and includes an additional commit that introduces a VaList implementation for Windows on AArch64. ------------- Commit messages: - Add Windows AArch64 VaList implementation - 8295290: Add Windows ARM64 ABI support to the Foreign Function & Memory API - Move Linux & MacOs CallArranger tests into separate files Changes: https://git.openjdk.org/jdk/pull/12773/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12773&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303409 Stats: 2135 lines in 20 files changed: 1445 ins; 650 del; 40 mod Patch: https://git.openjdk.org/jdk/pull/12773.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12773/head:pull/12773 PR: https://git.openjdk.org/jdk/pull/12773 From jvernee at openjdk.org Wed Mar 1 23:21:18 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 1 Mar 2023 23:21:18 GMT Subject: RFR: 8303409: Add Windows AArch64 ABI support to the Foreign Function & Memory API In-Reply-To: References: Message-ID: On Mon, 27 Feb 2023 17:04:28 GMT, Saint Wesonga wrote: > There are 2 primary differences between the Windows ARM64 ABI and the macOS/Linux ARM64 ABI: variadic floating point arguments are passed in general purpose registers on Windows (instead of the vector registers). In addition to this, up to 64 bytes of a struct being passed to a variadic function can be placed in general purpose registers. This happens regardless of the type of struct (HFA or other generic struct). This means that a struct can be split across registers and the stack when invoking a variadic function. The Windows ARM64 ABI conventions are documented at https://learn.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions > > For details about the Foreign Function & Memory API, see JEP 434 at https://openjdk.org/jeps/434 > > This change is a cherry pick of https://github.com/openjdk/panama-foreign/commit/d379ca1c and https://github.com/openjdk/panama-foreign/commit/08225e4f from https://github.com/openjdk/panama-foreign/pull/754 and includes an additional commit that introduces a VaList implementation for Windows on AArch64. All still looks good (including the VaList impl, though that is less important now since we plan to remove VaList in 21) I'm running tier 1-4 before giving a checkmark. Tests came back green @swesonga I've filed a new issue here: https://bugs.openjdk.org/browse/JDK-8303409 Please use that issue number in the PR title (the name should already be correct). ------------- PR: https://git.openjdk.org/jdk/pull/12773Marked as reviewed by jvernee (Reviewer). From naoto at openjdk.org Wed Mar 1 23:23:13 2023 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 1 Mar 2023 23:23:13 GMT Subject: RFR: 8303039: Utilize `coverageLevels.txt` In-Reply-To: References: Message-ID: <4_1vLEFwWP1R-W4kolNqlOnjvB8dvkNam6dCd-Pb8i8=.dc93be58-f4f2-4edc-843f-d8eea2c1377f@github.com> On Wed, 1 Mar 2023 23:02:33 GMT, Steven R. Loomis wrote: >> make/data/cldr/common/properties/coverageLevels.txt line 2: >> >>> 1: # coverageLevels.txt >>> 2: # Copyright ? 2022 Unicode, Inc. >> >> older version? > > is this from the alpha2 drop? or v42's? Yes, this is the file from the released CLDR v42. We have not integrated v43 yet. >> make/jdk/src/classes/build/tools/cldrconverter/OtherCommonLocales.properties line 140: >> >>> 138: >>> 139: # Not listed, but existed >>> 140: sr-Latn=Serbian (Latin) >> >> [CLDR-16449](https://unicode-org.atlassian.net/browse/CLDR-16449) > > you might want to give yourself a task to periodically review this file. Thanks! ------------- PR: https://git.openjdk.org/jdk/pull/12812 From duke at openjdk.org Wed Mar 1 23:23:14 2023 From: duke at openjdk.org (Steven R. Loomis) Date: Wed, 1 Mar 2023 23:23:14 GMT Subject: RFR: 8303039: Utilize `coverageLevels.txt` In-Reply-To: <4_1vLEFwWP1R-W4kolNqlOnjvB8dvkNam6dCd-Pb8i8=.dc93be58-f4f2-4edc-843f-d8eea2c1377f@github.com> References: <4_1vLEFwWP1R-W4kolNqlOnjvB8dvkNam6dCd-Pb8i8=.dc93be58-f4f2-4edc-843f-d8eea2c1377f@github.com> Message-ID: On Wed, 1 Mar 2023 23:18:59 GMT, Naoto Sato wrote: >> is this from the alpha2 drop? or v42's? > > Yes, this is the file from the released CLDR v42. We have not integrated v43 yet. this is great groundwork. ------------- PR: https://git.openjdk.org/jdk/pull/12812 From naoto at openjdk.org Wed Mar 1 23:23:16 2023 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 1 Mar 2023 23:23:16 GMT Subject: RFR: 8303039: Utilize `coverageLevels.txt` In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 23:06:10 GMT, Steven R. Loomis wrote: >> This is a pre-requisite for supporting CLDR v43, where they combine `seeds` locales with `common` locales (https://cldr.unicode.org/index/downloads/cldr-43#h.7s25aqdv767e). In order to have the same coverage level of locales, CLDRConverter tool needs to comb through the locale files based on the `coverageLevels.txt` file, (and the ones we already included as of v42). Confirmed the same set of locales is generated before and after this modification. > > make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java line 1212: > >> 1210: a -> Locale.forLanguageTag(a[0].trim().replaceAll("_", "-")), >> 1211: a -> a[1].trim(), >> 1212: (v1, v2) -> v2, > > this will grab all listed entries. Right now, that will get you basic and above. Ideally you would include if `v1` is one of `(basic|moderate|modern|comprehensive)` ??I'm proposing to add `core` or maybe even `undefined` locales in this list (though no consensus yet) OK, will filter explicitly for those levels. ------------- PR: https://git.openjdk.org/jdk/pull/12812 From duke at openjdk.org Wed Mar 1 23:23:17 2023 From: duke at openjdk.org (Steven R. Loomis) Date: Wed, 1 Mar 2023 23:23:17 GMT Subject: RFR: 8303039: Utilize `coverageLevels.txt` In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 23:19:01 GMT, Naoto Sato wrote: >> make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java line 1212: >> >>> 1210: a -> Locale.forLanguageTag(a[0].trim().replaceAll("_", "-")), >>> 1211: a -> a[1].trim(), >>> 1212: (v1, v2) -> v2, >> >> this will grab all listed entries. Right now, that will get you basic and above. Ideally you would include if `v1` is one of `(basic|moderate|modern|comprehensive)` ??I'm proposing to add `core` or maybe even `undefined` locales in this list (though no consensus yet) > > OK, will filter explicitly for those levels. the whole set is `undetermined|core|basic|moderate|modern|comprehensive` you could use an enum and then you can select just one. ------------- PR: https://git.openjdk.org/jdk/pull/12812 From bpb at openjdk.org Wed Mar 1 23:44:15 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 1 Mar 2023 23:44:15 GMT Subject: RFR: 8294137: Review running times of java.math tests Message-ID: <-dxso8siPUKzTOOKkoA5_2EAn7ACb_XJSYdQ_Af-4_I=.2e9f8478-f224-491e-a299-c59f9f373ff2@github.com> Break up `BigIntegerTest` and `SymmetricRangeTests` into subsets which are run quasi-randomly as a function of second within the minute at the time the test is running. `LargeValueExceptions` does not appear amenable to this treatment. ------------- Commit messages: - 8294137: Review running times of java.math tests Changes: https://git.openjdk.org/jdk/pull/12819/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12819&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294137 Stats: 126 lines in 3 files changed: 50 ins; 5 del; 71 mod Patch: https://git.openjdk.org/jdk/pull/12819.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12819/head:pull/12819 PR: https://git.openjdk.org/jdk/pull/12819 From bpb at openjdk.org Wed Mar 1 23:44:17 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 1 Mar 2023 23:44:17 GMT Subject: RFR: 8294137: Review running times of java.math tests In-Reply-To: <-dxso8siPUKzTOOKkoA5_2EAn7ACb_XJSYdQ_Af-4_I=.2e9f8478-f224-491e-a299-c59f9f373ff2@github.com> References: <-dxso8siPUKzTOOKkoA5_2EAn7ACb_XJSYdQ_Af-4_I=.2e9f8478-f224-491e-a299-c59f9f373ff2@github.com> Message-ID: <6RGxqSzy2HXre786uvdf2VF_vzYWmA052XrArNtdlE4=.f3a7cf75-2d3b-4e09-9f77-bcfd0ea9ac54@github.com> On Wed, 1 Mar 2023 23:36:04 GMT, Brian Burkhalter wrote: > Break up `BigIntegerTest` and `SymmetricRangeTests` into subsets which are run quasi-randomly as a function of second within the minute at the time the test is running. `LargeValueExceptions` does not appear amenable to this treatment. The full running time of `BigIntegerTest` was measured using `time` to be `24.983s`. The running times of its subsets were measured to be | subset | run time (s) | |--------|--------------| | 1 | 14.379 | | 2 | 10.946 | | 3 | 18.033 | The full running time of `SymmetricRangeTests` was measured using `time` to be `42.191s`. The running times of its subsets were measured to be | subset | run time (s) | |--------|--------------| | 1 | 16.997 | | 2 | 16.838 | | 3 | 16.047 | | 4 | 19.276 | Note that in both cases the overhead of each subset is probably about the same as that of the full test. ------------- PR: https://git.openjdk.org/jdk/pull/12819 From jlu at openjdk.org Wed Mar 1 23:45:47 2023 From: jlu at openjdk.org (Justin Lu) Date: Wed, 1 Mar 2023 23:45:47 GMT Subject: RFR: 8303472: Display name for region TR [v2] In-Reply-To: References: Message-ID: > This PR changes the English name for the region `TR`, from `Turkey` to `T?rkiye`. Although this change is included in the upcoming CLDR v43, it should be applied as a spot change so that it can be back-ported properly (As it is a common English region name). > > > > This change targets both the CLDR and COMPAT data. Justin Lu has updated the pull request incrementally with two additional commits since the last revision: - Supply test with changes, use unicode escapes to be consistent - copyright year ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12816/files - new: https://git.openjdk.org/jdk/pull/12816/files/c996ca27..5bedc6a0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12816&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12816&range=00-01 Stats: 9 lines in 4 files changed: 6 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/12816.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12816/head:pull/12816 PR: https://git.openjdk.org/jdk/pull/12816 From jlu at openjdk.org Wed Mar 1 23:45:49 2023 From: jlu at openjdk.org (Justin Lu) Date: Wed, 1 Mar 2023 23:45:49 GMT Subject: RFR: 8303472: Display name for region TR [v2] In-Reply-To: References: Message-ID: <8qco8EfF_4-QLAxJa-u95-6VA0pdna680KVGBkVxCxk=.66dbfadc-294b-4b0c-819b-64be6f831d18@github.com> On Wed, 1 Mar 2023 22:52:09 GMT, Naoto Sato wrote: >> Justin Lu has updated the pull request incrementally with two additional commits since the last revision: >> >> - Supply test with changes, use unicode escapes to be consistent >> - copyright year > > src/java.base/share/classes/sun/util/resources/LocaleNames.properties line 1097: > >> 1095: TN=Tunisia >> 1096: TO=Tonga >> 1097: TR=T?rkiye > > I believe this is fine, but please confirm that this ends up correct u-umlaut when you get the text. It is somewhat a rare case where ISO-8859-1 has the character and the byte sequence differs between ISO-8859-1 and UTF-8. Thanks for pointing that out, I switched it to just be a unicode escaped ?, as that would be more consistent with the rest of the file. I also added the changes to the test files like you suggested. ------------- PR: https://git.openjdk.org/jdk/pull/12816 From psandoz at openjdk.org Wed Mar 1 23:47:42 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Wed, 1 Mar 2023 23:47:42 GMT Subject: RFR: 8294982: Implementation of Classfile API [v31] In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 15:00:41 GMT, Adam Sotona wrote: >> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. >> >> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. >> >> Classfile API development is tracked at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch >> >> Development branch of consolidated JDK class files parsing, generating, and transforming is at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch >> >> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. >> >> Please take you time to review this non-trivial JDK addition. >> >> Thank you, >> Adam > > Adam Sotona has updated the pull request incrementally with four additional commits since the last revision: > > - renamed all remaining ConcreteXyzEntry to XyzEntryImpl > - abstract implementations of RefEntry, RefsEntry and NamedEntry renamed to AbstractRefEntry, AbstractRefsEntry and AbstractNamedEntry > - renamed ConcreteBootstrapMethodEntry to BootstrapMethodEntryImpl > - ConcreteEntry renamed to AbstractPoolEntry src/java.base/share/classes/jdk/internal/classfile/attribute/CodeAttribute.java line 56: > 54: * @param label a marker for a position within this {@code CodeAttribute} > 55: * @return position of the {@code Label} in the {@code codeArray} > 56: */ Suggestion: /** * {@return the position of the {@code Label} in the {@code codeArray}} * @param label a marker for a position within this {@code CodeAttribute} */ Throws IAE if the label is not positioned in the code array? ------------- PR: https://git.openjdk.org/jdk/pull/10982 From psandoz at openjdk.org Thu Mar 2 00:01:46 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 2 Mar 2023 00:01:46 GMT Subject: RFR: 8294982: Implementation of Classfile API [v13] In-Reply-To: References: Message-ID: <2nbxm42RWgHdKnlYOUL4AI3cIJsidHjP5LUpMbOEbrs=.25776a2b-7aed-4719-904e-fd9f4a013d5a@github.com> On Wed, 8 Feb 2023 11:00:14 GMT, Adam Sotona wrote: >> src/java.base/share/classes/jdk/internal/classfile/attribute/StackMapTableAttribute.java line 68: >> >>> 66: * A simple stack value. >>> 67: */ >>> 68: public enum SimpleVerificationTypeInfo implements VerificationTypeInfo { >> >> I note that in this class we have made the decision to model all the innards (XYZInfo) as nested classes - while in all the other cases XYZInfo are toplevel types. Moving forward, we should pick something consistent. > > Every case has been considered individually, evaluated on use cases and pros and cons have been weighted. Unified approach across the whole API would be nice, however not so simple and not the highest priority. I had the same observation as Maurizio. ------------- PR: https://git.openjdk.org/jdk/pull/10982 From psandoz at openjdk.org Thu Mar 2 00:13:54 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 2 Mar 2023 00:13:54 GMT Subject: RFR: 8294982: Implementation of Classfile API [v12] In-Reply-To: References: <2dfIIfnZwgc-wezRVH81l9b5VjLjP02k7PjU64wjAww=.5c9e7ba6-4254-46cd-a6c0-553dcea7dc3b@github.com> Message-ID: <2n9y4o3NlO7XOCCizxTfda8q7apSxZ0gjutt8RWuyE4=.40ed51d9-13ab-42f0-bca1-e1d6a4d75efb@github.com> On Mon, 6 Feb 2023 13:50:07 GMT, Adam Sotona wrote: >> Actually, we also have a ClassfileVersion class, so that could be a better place for version numbers? > > There were several iterations of "where to store numeric constants". > It is hard to find them when spread across many classes and duplicities appear instantly. > Dedicated "Constants" would be another bikeshed with conflicting name. > Co-location in Classfile was the latest decission as it is not just a central bikeshed, but it also reflect connection with classfile specification. > Please raise that discussion at classfile-api-dev at openjdk.org if necessary. At least for versions its easier to have a singular location because every six months the code needs to be updated. ------------- PR: https://git.openjdk.org/jdk/pull/10982 From psandoz at openjdk.org Thu Mar 2 01:00:50 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 2 Mar 2023 01:00:50 GMT Subject: RFR: 8294982: Implementation of Classfile API [v31] In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 15:00:41 GMT, Adam Sotona wrote: >> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. >> >> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. >> >> Classfile API development is tracked at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch >> >> Development branch of consolidated JDK class files parsing, generating, and transforming is at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch >> >> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. >> >> Please take you time to review this non-trivial JDK addition. >> >> Thank you, >> Adam > > Adam Sotona has updated the pull request incrementally with four additional commits since the last revision: > > - renamed all remaining ConcreteXyzEntry to XyzEntryImpl > - abstract implementations of RefEntry, RefsEntry and NamedEntry renamed to AbstractRefEntry, AbstractRefsEntry and AbstractNamedEntry > - renamed ConcreteBootstrapMethodEntry to BootstrapMethodEntryImpl > - ConcreteEntry renamed to AbstractPoolEntry src/java.base/share/classes/jdk/internal/classfile/ClassModel.java line 86: > 84: * {@snippet lang=java : > 85: * Classfile.build(thisClass(), ConstantPoolBuilder.of(this), > 86: * b -> b.transform(this, transform); Suggestion: * Classfile.build(thisClass(), ConstantPoolBuilder.of(this), * b -> b.transform(this, transform)); ------------- PR: https://git.openjdk.org/jdk/pull/10982 From naoto at openjdk.org Thu Mar 2 01:03:20 2023 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 2 Mar 2023 01:03:20 GMT Subject: RFR: 8303039: Utilize `coverageLevels.txt` [v2] In-Reply-To: References: Message-ID: > This is a pre-requisite for supporting CLDR v43, where they combine `seeds` locales with `common` locales (https://cldr.unicode.org/index/downloads/cldr-43#h.7s25aqdv767e). In order to have the same coverage level of locales, CLDRConverter tool needs to comb through the locale files based on the `coverageLevels.txt` file, (and the ones we already included as of v42). Confirmed the same set of locales is generated before and after this modification. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Explicitly filter coverage levels ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12812/files - new: https://git.openjdk.org/jdk/pull/12812/files/2d0f16f3..8ae9ba61 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12812&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12812&range=00-01 Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/12812.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12812/head:pull/12812 PR: https://git.openjdk.org/jdk/pull/12812 From duke at openjdk.org Thu Mar 2 01:11:05 2023 From: duke at openjdk.org (Steven R. Loomis) Date: Thu, 2 Mar 2023 01:11:05 GMT Subject: RFR: 8303039: Utilize `coverageLevels.txt` [v2] In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 01:03:20 GMT, Naoto Sato wrote: >> This is a pre-requisite for supporting CLDR v43, where they combine `seeds` locales with `common` locales (https://cldr.unicode.org/index/downloads/cldr-43#h.7s25aqdv767e). In order to have the same coverage level of locales, CLDRConverter tool needs to comb through the locale files based on the `coverageLevels.txt` file, (and the ones we already included as of v42). Confirmed the same set of locales is generated before and after this modification. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Explicitly filter coverage levels Marked as reviewed by srl295 at github.com (no known OpenJDK username). ------------- PR: https://git.openjdk.org/jdk/pull/12812 From jpai at openjdk.org Thu Mar 2 01:18:05 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 2 Mar 2023 01:18:05 GMT Subject: RFR: 8303039: Utilize `coverageLevels.txt` In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 23:13:55 GMT, Steven R. Loomis wrote: > my openjdk name should be `srl` ? i'm still there https://openjdk.org/census#srl Hello Steven, please follow the instructions here to have your github account linked to the OpenJDK id https://wiki.openjdk.org/display/SKARA/Skara#Skara-AssociatingyourGitHubaccountandyourOpenJDKusername. ------------- PR: https://git.openjdk.org/jdk/pull/12812 From martin at openjdk.org Thu Mar 2 02:07:14 2023 From: martin at openjdk.org (Martin Buchholz) Date: Thu, 2 Mar 2023 02:07:14 GMT Subject: RFR: JDK-8297605 DelayQueue javadoc is confusing In-Reply-To: References: Message-ID: <3sC0ll4wZ6mBKGu6Gs2t5GHcr_JBqPDBgvvhyW5xQBk=.f9937235-271d-4d4e-9fcd-dfafe47f4315@github.com> On Mon, 27 Feb 2023 20:09:12 GMT, Martin Buchholz wrote: > I wonder if there's now a way to override javadoc for remove() without creating a new method body. I thought recent javadoc features might have been useful here, but I scanned the results from this jql: subcomponent in ( "javadoc(tool)", "doclet" ) AND (resolution in ( Fixed, Approved ) ) AND issuetype in (JEP, Enhancement) ORDER BY resolved DESC and came up empty ------------- PR: https://git.openjdk.org/jdk/pull/12729 From duke at openjdk.org Thu Mar 2 03:35:15 2023 From: duke at openjdk.org (duke) Date: Thu, 2 Mar 2023 03:35:15 GMT Subject: Withdrawn: JDK-8295756 Improve NonLocalRegistry Manual Test Process In-Reply-To: References: Message-ID: On Fri, 21 Oct 2022 21:45:30 GMT, Bill Huang wrote: > The current non local registry tests require a manual process that runs rmiregitrty on a different machine and changes the -Dregistry.host property in the source before running the tests on the local machine. This task is created to improve this manual process and provide a clearer instruction to the test engineer about the test requirement. > > Tests include: > java/rmi/registry/nonLocalRegistry/NonLocalSkeletonTest.java > java/rmi/registry/nonLocalRegistry/NonLocalRegistryTest.java > javax/management/remote/nonLocalAccess/NonLocalJMXRemoteTest.java This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/10825 From darcy at openjdk.org Thu Mar 2 06:02:10 2023 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 2 Mar 2023 06:02:10 GMT Subject: RFR: JDK-8302801: Remove fdlibm C sources Message-ID: While the review of https://github.com/openjdk/jdk/pull/12800 finishes up, I thought I'd get out for the review the next phase of the FDLIBM port: removing the FDLIBM C sources from the repo. A repo with the changes for JDK-8302027 and this PR successful build on the default set of platform and successfully run tier 1 tests, which includes tests of the math library. There are a few remaining references to the case-independent string "fdlibm" in the make directory and HotSpot sources. HotSpot contains a partial fork for FDLIBM (a tine of FDLIBM?) to use for intrinsics. The remaining make machinery contains logic to determine what set of gcc options can be used for the compile. The intention of this change is to remove use of FDLIBM for the core libraries. ------------- Depends on: https://git.openjdk.org/jdk/pull/12800 Commit messages: - JDK-8302801: Remove fdlibm C sources Changes: https://git.openjdk.org/jdk/pull/12821/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12821&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8302801 Stats: 6609 lines in 63 files changed: 0 ins; 6609 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12821.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12821/head:pull/12821 PR: https://git.openjdk.org/jdk/pull/12821 From dholmes at openjdk.org Thu Mar 2 06:23:11 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 2 Mar 2023 06:23:11 GMT Subject: RFR: 8303486: [REDO] Update ProcessTools.startProcess(...) to exit early if process exit before linePredicate is printed. In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 20:50:38 GMT, Leonid Mesnik wrote: > It is the 2nd attempt to fix > [JDK-8303133](https://bugs.openjdk.org/browse/JDK-8303133) Update ProcessTools.startProcess(...) to exit early if the process exit before linePredicate is printed. > > The first fix failed because it runs > Utils.waitForCondition(BooleanSupplier condition, long timeout, long sleepTime) { ..} > with 0 as no timeout and not -1 as required. Looks good. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/12815 From mdoerr at openjdk.org Thu Mar 2 06:43:15 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Thu, 2 Mar 2023 06:43:15 GMT Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function & Memory API (Preview) [v6] In-Reply-To: References: Message-ID: > Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification". > > This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `` (2.2.4 Variable Argument Lists). > > Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only. > > There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Will get addressed separately: [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017) > > The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests. > > I had to make changes to shared code and code for other platforms: > 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons: > - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that. > - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64. > - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian! > 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit. Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: Add test for HFA corner cases. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12708/files - new: https://git.openjdk.org/jdk/pull/12708/files/75b5c78f..c96e1120 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=04-05 Stats: 256 lines in 2 files changed: 256 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12708.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12708/head:pull/12708 PR: https://git.openjdk.org/jdk/pull/12708 From alanb at openjdk.org Thu Mar 2 07:15:11 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 2 Mar 2023 07:15:11 GMT Subject: RFR: JDK-8302801: Remove fdlibm C sources In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 05:54:52 GMT, Joe Darcy wrote: > While the review of https://github.com/openjdk/jdk/pull/12800 finishes up, I thought I'd get out for the review the next phase of the FDLIBM port: removing the FDLIBM C sources from the repo. > > A repo with the changes for JDK-8302027 and this PR successful build on the default set of platform and successfully run tier 1 tests, which includes tests of the math library. > > There are a few remaining references to the case-independent string "fdlibm" in the make directory and HotSpot sources. HotSpot contains a partial fork for FDLIBM (a tine of FDLIBM?) to use for intrinsics. The remaining make machinery contains logic to determine what set of gcc options can be used for the compile. > > The intention of this change is to remove use of FDLIBM for the core libraries. This is a great milestone to get to! Does the comment at the top of sharedRuntimeTrig.cpp need updating? ------------- PR: https://git.openjdk.org/jdk/pull/12821 From alanb at openjdk.org Thu Mar 2 07:47:17 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 2 Mar 2023 07:47:17 GMT Subject: RFR: 8303175: (fs) Deprecate com.sun.nio.file.SensitivityWatchEventModifier for removal [v4] In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 18:23:43 GMT, Brian Burkhalter wrote: >> Deprecate `SensitivityWatchEventModifier` for now instead of directly removing it as proposed in #12626. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8303175: Change @deprecated verbiage in SensitivityWatchEventModifier src/jdk.unsupported/share/classes/com/sun/nio/file/SensitivityWatchEventModifier.java line 41: > 39: * which used this {@code WatchEvent.Modifier}. Therefore this > 40: * {@code WatchEvent.Modifier} class is vestigial and should be removed in a > 41: * future release. "no longer recognizes" suggests that using them will lead to an error but it's actually that they will be just ignored. Also "should be removed in a future release" will duplicate text generated by javadoc. The JDK docs build doesn't generate javadoc for the jdk.unsupported module so maybe it doesn't matter but here's a suggestion for something a bit briefer: "The sensitivity levels were historically used by polling based WatchService implementations to configure the polling interval. They are are no longer used. The WatchService implementations in the JDK ignore these WatchEvent modifiers if they are specified when registering a directory to be watched." ------------- PR: https://git.openjdk.org/jdk/pull/12746 From jlahoda at openjdk.org Thu Mar 2 08:31:27 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 2 Mar 2023 08:31:27 GMT Subject: Integrated: 8297587: Upgrade JLine to 3.22.0 In-Reply-To: References: Message-ID: On Fri, 17 Feb 2023 10:20:46 GMT, Jan Lahoda wrote: > This is a proposal to upgrade the JLine inside JDK to 3.22.0. It was done by: > -for shared/classes, taking a diff between JLine 3.20.0 and the existing JDK version, copying the JLine 3.22.0 into the JDK, repackaing, re-appling the patch (including trailing space removal, UTF-8 characters replacement, addition of inputStreamWrapper), and adjusting TerminalProvider > -for Windows, mostly copying the JLine 3.22.0 code into the JDK, and adjusting based on old changes This pull request has now been integrated. Changeset: 4619e8ba Author: Jan Lahoda URL: https://git.openjdk.org/jdk/commit/4619e8bae838abd1f243c2c65a538806d226b8e8 Stats: 1763 lines in 54 files changed: 1055 ins; 452 del; 256 mod 8297587: Upgrade JLine to 3.22.0 Reviewed-by: vromero ------------- PR: https://git.openjdk.org/jdk/pull/12614 From sspitsyn at openjdk.org Thu Mar 2 08:53:11 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 2 Mar 2023 08:53:11 GMT Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324 [v2] In-Reply-To: References: Message-ID: On Wed, 23 Nov 2022 10:14:23 GMT, Serguei Spitsyn wrote: >> This problem has two sides. >> One is that the `VirtualThread::run() `cashes the field `notifyJvmtiEvents` value. >> It caused the native method `notifyJvmtiUnmountBegin()` not called after the field `notifyJvmtiEvents` >> value has been set to `true` when an agent library is loaded into running VM. >> The fix is to get rid of this cashing. >> Another is that enabling `notifyJvmtiEvents` notifications needs a synchronization. >> Otherwise, a VTMS transition start can be missed which will cause some asserts to fire. >> The fix is to use a JvmtiVTMSTransitionDisabler helper for sync. >> >> Testing: >> The originally failed tests are passed now: >> >> runtime/vthread/RedefineClass.java >> runtime/vthread/TestObjectAllocationSampleEvent.java >> >> In progress: >> Run the tiers 1-6 to make sure there are no regression. > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > remove caching if notifyJvmtiEvents in yieldContinuation Need to keep this PR alive for a while. ------------- PR: https://git.openjdk.org/jdk/pull/11304 From rgiulietti at openjdk.org Thu Mar 2 10:24:03 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Thu, 2 Mar 2023 10:24:03 GMT Subject: RFR: 8302590: Add String.indexOf(int ch, int fromIndex, int toIndex) [v7] In-Reply-To: References: Message-ID: > Add an `indexOf()` variant allowing to specify both a lower and an upper bound on the search. Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: 8302590: Add String.indexOf(int ch, int fromIndex, int toIndex) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12600/files - new: https://git.openjdk.org/jdk/pull/12600/files/dfd953f9..5bc1edb8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12600&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12600&range=05-06 Stats: 21 lines in 1 file changed: 0 ins; 0 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/12600.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12600/head:pull/12600 PR: https://git.openjdk.org/jdk/pull/12600 From duke at openjdk.org Thu Mar 2 10:32:48 2023 From: duke at openjdk.org (Ravali Yatham) Date: Thu, 2 Mar 2023 10:32:48 GMT Subject: RFR: 8302791: Add specific ClassLoader object to Proxy IllegalArgumentException message [v5] In-Reply-To: References: Message-ID: > Added specific class loader object to proxy IllegalArgumentException from which the class was not visible > > The bug report for the same: https://bugs.openjdk.org/browse/JDK-8302791 Ravali Yatham has updated the pull request incrementally with one additional commit since the last revision: Avoid long line of code ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12641/files - new: https://git.openjdk.org/jdk/pull/12641/files/ae442098..ba561eef Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12641&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12641&range=03-04 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/12641.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12641/head:pull/12641 PR: https://git.openjdk.org/jdk/pull/12641 From duke at openjdk.org Thu Mar 2 10:32:52 2023 From: duke at openjdk.org (Ravali Yatham) Date: Thu, 2 Mar 2023 10:32:52 GMT Subject: RFR: 8302791: Add specific ClassLoader object to Proxy IllegalArgumentException message [v4] In-Reply-To: References: <0jQQEOJWyqjmAP3UgPGk7V1muce0Yx14nWIlBnkOgas=.095d14d8-ee3c-4089-bb62-6f7d1c0100d5@github.com> Message-ID: On Wed, 1 Mar 2023 15:08:02 GMT, Alan Bateman wrote: >> Ravali Yatham has updated the pull request incrementally with one additional commit since the last revision: >> >> Add comments > > src/java.base/share/classes/java/lang/reflect/Proxy.java line 889: > >> 887: : Objects.toIdentityString(ld); >> 888: throw new IllegalArgumentException(c.getName() + >> 889: " referenced from a method is not visible from class loader: " + nid); > > Thanks for the update, this looks much better. A passing thought is that you might want to use "/" instead of "@" as the separator so that someone looking at the exception message will be able to distinguish a class name from a class loader name. Also you might want to re-format L886 to avoid the really long line as it's a bit inconsistent with the code in this source file. Thanks @AlanBateman. Regarding the separator, Have seen this being used in ClassLoader.java for nameAndId method. Hence used the same for consistency. I've reformatted L886 now, Please kindly check. ------------- PR: https://git.openjdk.org/jdk/pull/12641 From rgiulietti at openjdk.org Thu Mar 2 10:38:04 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Thu, 2 Mar 2023 10:38:04 GMT Subject: RFR: 8294137: Review running times of java.math tests In-Reply-To: <-dxso8siPUKzTOOKkoA5_2EAn7ACb_XJSYdQ_Af-4_I=.2e9f8478-f224-491e-a299-c59f9f373ff2@github.com> References: <-dxso8siPUKzTOOKkoA5_2EAn7ACb_XJSYdQ_Af-4_I=.2e9f8478-f224-491e-a299-c59f9f373ff2@github.com> Message-ID: On Wed, 1 Mar 2023 23:36:04 GMT, Brian Burkhalter wrote: > Break up `BigIntegerTest` and `SymmetricRangeTests` into subsets which are run quasi-randomly as a function of second within the minute at the time the test is running. `LargeValueExceptions` does not appear amenable to this treatment. LGTM ------------- PR: https://git.openjdk.org/jdk/pull/12819 From asotona at openjdk.org Thu Mar 2 10:51:33 2023 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 2 Mar 2023 10:51:33 GMT Subject: RFR: 8294982: Implementation of Classfile API [v32] In-Reply-To: References: Message-ID: > This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. > > Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. > > Classfile API development is tracked at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch > > Development branch of consolidated JDK class files parsing, generating, and transforming is at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch > > Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. > > Please take you time to review this non-trivial JDK addition. > > Thank you, > Adam Adam Sotona has updated the pull request incrementally with five additional commits since the last revision: - ConstantPoolBuilder::natEntry renamed to nameAndTypeEntry - removed static implementation methods from ClassEntry - removed unused imports - fixed PackageSnipets - default constantValue delegating to asSymbol pulled from implementations to ConstantDynamicEntry, MethodHandleEntry and MethodTypeEntry ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10982/files - new: https://git.openjdk.org/jdk/pull/10982/files/1e95e508..70ec5ec7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=31 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=30-31 Stats: 363 lines in 47 files changed: 17 ins; 307 del; 39 mod Patch: https://git.openjdk.org/jdk/pull/10982.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982 PR: https://git.openjdk.org/jdk/pull/10982 From asotona at openjdk.org Thu Mar 2 10:51:38 2023 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 2 Mar 2023 10:51:38 GMT Subject: RFR: 8294982: Implementation of Classfile API [v31] In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 21:36:41 GMT, Paul Sandoz wrote: >> Adam Sotona has updated the pull request incrementally with four additional commits since the last revision: >> >> - renamed all remaining ConcreteXyzEntry to XyzEntryImpl >> - abstract implementations of RefEntry, RefsEntry and NamedEntry renamed to AbstractRefEntry, AbstractRefsEntry and AbstractNamedEntry >> - renamed ConcreteBootstrapMethodEntry to BootstrapMethodEntryImpl >> - ConcreteEntry renamed to AbstractPoolEntry > > src/java.base/share/classes/jdk/internal/classfile/constantpool/ClassEntry.java line 48: > >> 46: default ConstantDesc constantValue() { >> 47: return asSymbol(); >> 48: } > > It seems possible to use this pattern consistently for `ConstantDynamicEntry`, `MethodHandleEntry`, and `MethodTypeEntry`? > > At first i thought why not make `asSymbol` a covariant override of `constantValue`, but its not the same thing, since there are constant values (subtypes of `ConstantValueEntry`) that are not symbols. Yes, I've moved the default `constantValue` delegation to `asSymbol` from implementations up to the `ConstantDynamicEntry`, `MethodHandleEntry`, and `MethodTypeEntry`. Thanks. > src/java.base/share/classes/jdk/internal/classfile/constantpool/ClassEntry.java line 71: > >> 69: * @return the combined {@link List} >> 70: */ >> 71: static List adding(List base, List additions) { > > This and all the other following static methods seem more like implementation details rather than part of the public API? I've searched over all use cases we have and found no direct use of these API methods, so I've removed them. We may later re-open discussion about possible API to combine and deduplicate lists of entries and symbols, however this isolated solution really does not fit and does not serve any purpose. > src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPool.java line 49: > >> 47: import static jdk.internal.classfile.Classfile.TAG_STRING; >> 48: import static jdk.internal.classfile.Classfile.TAG_UTF8; >> 49: > > Unused imports, perhaps sweep through all classes (i think it can be done over multiple packages with IntelliJ). This and hopefully all other unused imports have been removed. Thanks. > src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPoolBuilder.java line 222: > >> 220: * @param typeEntry the member field or method descriptor >> 221: */ >> 222: NameAndTypeEntry natEntry(Utf8Entry nameEntry, Utf8Entry typeEntry); > > I would be inclined to rename more literally as `nameAndTypeEntry`, which is consistent with the naming convention in all other cases in this interface AFAICT (edit: almost i also see `bsm`) . (FWIW i keep reading nat as "not a type"!) Good point, renamed. Thanks. > src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java line 376: > >> 374: } else if (o instanceof Utf8Entry u) { >> 375: return equalsString(u.stringValue()); >> 376: } > > Dead branch? since there is only one concrete implementation of `Utf8Entry`. fixed, thanks. > src/java.base/share/classes/jdk/internal/classfile/snippet-files/PackageSnippets.java line 111: > >> 109: Set dependencies = cm.elementStream() >> 110: .filter(ce -> ce instanceof MethodModel) >> 111: .flatMap(ce -> ((MethodModel) ce).elementStream()) > > You could potentially collapse this into a single `flatMap` and avoid the cast: > > .flatMap(ce -> ce instanceof MethodMethod mm ? mm.elementStream() : Stream.empty()) fixed, thanks. ------------- PR: https://git.openjdk.org/jdk/pull/10982 From jlaskey at openjdk.org Thu Mar 2 11:14:36 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 2 Mar 2023 11:14:36 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v42] In-Reply-To: <9XP497xudeRhZKkIpxIgpbqT24eG8SCbfG6TelYtM3M=.f1ad5a76-798c-4e3d-b43b-a25a20210154@github.com> References: <9XP497xudeRhZKkIpxIgpbqT24eG8SCbfG6TelYtM3M=.f1ad5a76-798c-4e3d-b43b-a25a20210154@github.com> Message-ID: On Mon, 27 Feb 2023 12:47:03 GMT, Jim Laskey wrote: >> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Tighten up reporting of string template errors (fewer messages) Can I get some signing reviewers of the CSR https://bugs.openjdk.org/browse/JDK-8286021 ? ------------- PR: https://git.openjdk.org/jdk/pull/10889 From duke at openjdk.org Thu Mar 2 11:15:17 2023 From: duke at openjdk.org (Viktor Klang) Date: Thu, 2 Mar 2023 11:15:17 GMT Subject: RFR: JDK-8302666: Replace CHM with VarHandle in ForeachOrderedTask [v5] In-Reply-To: <1LzrIgu7t_JjtaAd-i9yJeTqlANUbXKEPimWpEGPJu0=.b5478cfa-2a00-4532-8dc7-8c545fe0bd48@github.com> References: <9Th3ZUGlDBxNXHg6dkVO63m-qFw8OV1b6nDqJF0H6SA=.fdf383c0-8914-40b0-806e-c1d8b2e2045e@github.com> <1LzrIgu7t_JjtaAd-i9yJeTqlANUbXKEPimWpEGPJu0=.b5478cfa-2a00-4532-8dc7-8c545fe0bd48@github.com> Message-ID: On Tue, 28 Feb 2023 16:11:25 GMT, Paul Sandoz wrote: >> Viktor Klang 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: >> >> Updating copyright header of ForEachOps.java and removing unnecessary suppression of an unchecked cast. > > src/java.base/share/classes/java/util/stream/ForEachOps.java line 513: > >> 511: // of right subtree (if any, which can be this task's right sibling) >> 512: // >> 513: var leftDescendant = (ForEachOrderedTask)NEXT.getAndSet(this, (ForEachOrderedTask)null); > > The reference cast on the argument is not required. `VarHandle`'s by default have `MethodHandle` invoke semantics (but without the throwing Throwable): > > https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/lang/invoke/VarHandle.html#invoke > > VarHandle's have been engineered so such reference casts on the arguments can be optimized away. This makes them much easier to use than MethodHandles. @PaulSandoz Ah, that's great wisdom right there. I'll remove the cast on the argument. ? ------------- PR: https://git.openjdk.org/jdk/pull/12320 From asotona at openjdk.org Thu Mar 2 11:18:32 2023 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 2 Mar 2023 11:18:32 GMT Subject: RFR: 8294982: Implementation of Classfile API [v33] In-Reply-To: References: Message-ID: > This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. > > Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. > > Classfile API development is tracked at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch > > Development branch of consolidated JDK class files parsing, generating, and transforming is at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch > > Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. > > Please take you time to review this non-trivial JDK addition. > > Thank you, > Adam Adam Sotona has updated the pull request incrementally with three additional commits since the last revision: - Update src/java.base/share/classes/jdk/internal/classfile/ClassReader.java Co-authored-by: Paul Sandoz - Update src/java.base/share/classes/jdk/internal/classfile/impl/TemporaryConstantPool.java Co-authored-by: Paul Sandoz - SplitConstantPool fixes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10982/files - new: https://git.openjdk.org/jdk/pull/10982/files/70ec5ec7..e674bada Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=32 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=31-32 Stats: 20 lines in 3 files changed: 10 ins; 2 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/10982.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982 PR: https://git.openjdk.org/jdk/pull/10982 From asotona at openjdk.org Thu Mar 2 11:18:37 2023 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 2 Mar 2023 11:18:37 GMT Subject: RFR: 8294982: Implementation of Classfile API [v31] In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 22:38:32 GMT, Paul Sandoz wrote: >> Adam Sotona has updated the pull request incrementally with four additional commits since the last revision: >> >> - renamed all remaining ConcreteXyzEntry to XyzEntryImpl >> - abstract implementations of RefEntry, RefsEntry and NamedEntry renamed to AbstractRefEntry, AbstractRefsEntry and AbstractNamedEntry >> - renamed ConcreteBootstrapMethodEntry to BootstrapMethodEntryImpl >> - ConcreteEntry renamed to AbstractPoolEntry > > src/java.base/share/classes/jdk/internal/classfile/impl/SplitConstantPool.java line 167: > >> 165: buf.patchInt(pos + 2, 4, attrLen - 6); >> 166: buf.patchInt(pos + 6, 2, bsmSize); >> 167: return true; > > The if and else branch return true, factor out at the end of the method? fixed, thanks. > src/java.base/share/classes/jdk/internal/classfile/impl/SplitConstantPool.java line 339: > >> 337: } >> 338: >> 339: private AbstractPoolEntry.Utf8EntryImpl tryFindUtf8(int hash, String target) { > > Unused type variable `T` fixed, thanks. > src/java.base/share/classes/jdk/internal/classfile/impl/SplitConstantPool.java line 488: > >> 486: return methodHandleEntry(refKind, reference); >> 487: } >> 488: return internalAdd(new AbstractPoolEntry.MethodHandleEntryImpl(this, size, hash, refKind, (AbstractPoolEntry.AbstractMemberRefEntry) reference), hash); > > Break the long line (same for two following methods). fixed, thanks. ------------- PR: https://git.openjdk.org/jdk/pull/10982 From duke at openjdk.org Thu Mar 2 11:20:39 2023 From: duke at openjdk.org (Viktor Klang) Date: Thu, 2 Mar 2023 11:20:39 GMT Subject: RFR: JDK-8297605 DelayQueue javadoc is confusing [v2] In-Reply-To: References: Message-ID: On Fri, 24 Feb 2023 16:08:57 GMT, Viktor Klang wrote: >> Clarifies the distinction between expiration of the head of DelayQueue and how it relates to `poll`, `take`, and `peek`. See discussion on https://bugs.openjdk.org/browse/JDK-8297605 >> >> @DougLea If possible, please weigh in on whether this is in line with your thoughts on the matter. > > Viktor Klang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > JDK-8297605 DelayQueue javadoc is confusing Perhaps @pavelrappo has any suggestion for adding clarifying Javadoc to a subclass without having to override the method? ? ------------- PR: https://git.openjdk.org/jdk/pull/12729 From asotona at openjdk.org Thu Mar 2 11:21:49 2023 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 2 Mar 2023 11:21:49 GMT Subject: RFR: 8294982: Implementation of Classfile API [v34] In-Reply-To: References: Message-ID: > This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. > > Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. > > Classfile API development is tracked at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch > > Development branch of consolidated JDK class files parsing, generating, and transforming is at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch > > Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. > > Please take you time to review this non-trivial JDK addition. > > Thank you, > Adam Adam Sotona has updated the pull request incrementally with two additional commits since the last revision: - Update src/java.base/share/classes/jdk/internal/classfile/attribute/CodeAttribute.java Co-authored-by: Paul Sandoz - Update src/java.base/share/classes/jdk/internal/classfile/ClassModel.java Co-authored-by: Paul Sandoz ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10982/files - new: https://git.openjdk.org/jdk/pull/10982/files/e674bada..79ce1698 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=33 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=32-33 Stats: 3 lines in 2 files changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10982.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982 PR: https://git.openjdk.org/jdk/pull/10982 From duke at openjdk.org Thu Mar 2 11:22:26 2023 From: duke at openjdk.org (Viktor Klang) Date: Thu, 2 Mar 2023 11:22:26 GMT Subject: RFR: JDK-8302666: Replace CHM with VarHandle in ForeachOrderedTask [v6] In-Reply-To: References: Message-ID: > I noticed when looking at the code that there was no real need to use a CHM to perform the tracking of activation in an ordered fashion on ForEachOrderedTask, but instead a VarHandle can be used, reducing allocations and indirection. Viktor Klang has updated the pull request incrementally with one additional commit since the last revision: Removing unnecessary cast of argument to VarHandle getAndSet ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12320/files - new: https://git.openjdk.org/jdk/pull/12320/files/a5c6b0d0..2c8f0ab4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12320&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12320&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12320.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12320/head:pull/12320 PR: https://git.openjdk.org/jdk/pull/12320 From prappo at openjdk.org Thu Mar 2 12:13:14 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Thu, 2 Mar 2023 12:13:14 GMT Subject: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments Message-ID: Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API. The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows: diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html --- build/macosx-aarch64/images/docs-before/api/serialized-form.html 2023-03-02 11:47:44 +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html 2023-03-02 11:48:45 @@ -17084,7 +17084,7 @@ throws IOException, ClassNotFoundException
readObject is called to restore the state of the - (@code BasicPermission} from a stream.
+ BasicPermission from a stream.
Parameters:
s - the ObjectInputStream from which data is read
Notes ----- * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas. * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary. * I will update copyright years after (and if) the fix had been approved, as required. ------------- Commit messages: - Initial commit Changes: https://git.openjdk.org/jdk/pull/12826/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12826&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303480 Stats: 75 lines in 39 files changed: 0 ins; 0 del; 75 mod Patch: https://git.openjdk.org/jdk/pull/12826.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12826/head:pull/12826 PR: https://git.openjdk.org/jdk/pull/12826 From prappo at openjdk.org Thu Mar 2 12:22:11 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Thu, 2 Mar 2023 12:22:11 GMT Subject: RFR: JDK-8297605 DelayQueue javadoc is confusing [v2] In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 11:17:10 GMT, Viktor Klang wrote: > Perhaps @pavelrappo has any suggestion for adding clarifying Javadoc to a subclass without having to override the method? ? You cannot do that. ------------- PR: https://git.openjdk.org/jdk/pull/12729 From duke at openjdk.org Thu Mar 2 12:24:11 2023 From: duke at openjdk.org (Afshin Zafari) Date: Thu, 2 Mar 2023 12:24:11 GMT Subject: RFR: 8301622: ProcessTools.java compilation gets ThreadDeath deprecation warning Message-ID: ### Description The use of `ThreadDeath` is replaced with checking the exception be of type `Error` and the thread is `TERMINATED`. ### Test local and mach5 tier1 ------------- Commit messages: - 8301622: ProcessTools.java compilation gets ThreadDeath deprecation warning Changes: https://git.openjdk.org/jdk/pull/12827/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12827&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301622 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/12827.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12827/head:pull/12827 PR: https://git.openjdk.org/jdk/pull/12827 From asotona at openjdk.org Thu Mar 2 12:35:48 2023 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 2 Mar 2023 12:35:48 GMT Subject: RFR: 8294982: Implementation of Classfile API [v31] In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 23:43:55 GMT, Paul Sandoz wrote: >> Adam Sotona has updated the pull request incrementally with four additional commits since the last revision: >> >> - renamed all remaining ConcreteXyzEntry to XyzEntryImpl >> - abstract implementations of RefEntry, RefsEntry and NamedEntry renamed to AbstractRefEntry, AbstractRefsEntry and AbstractNamedEntry >> - renamed ConcreteBootstrapMethodEntry to BootstrapMethodEntryImpl >> - ConcreteEntry renamed to AbstractPoolEntry > > src/java.base/share/classes/jdk/internal/classfile/attribute/CodeAttribute.java line 56: > >> 54: * @param label a marker for a position within this {@code CodeAttribute} >> 55: * @return position of the {@code Label} in the {@code codeArray} >> 56: */ > > Suggestion: > > /** > * {@return the position of the {@code Label} in the {@code codeArray}} > * @param label a marker for a position within this {@code CodeAttribute} > */ > > Throws IAE if the label is not positioned in the code array? All the dependent code expects -1 when the Label is not positioned in the code array. Throwing IAE would require significant refactoring and may have performance effects. I'll add a javadoc comment meanwhile. ------------- PR: https://git.openjdk.org/jdk/pull/10982 From asotona at openjdk.org Thu Mar 2 13:03:41 2023 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 2 Mar 2023 13:03:41 GMT Subject: RFR: 8294982: Implementation of Classfile API [v35] In-Reply-To: References: Message-ID: <_9nZVJqQlrj9vY3AKIxr1DDEqqdYTbc9MDiabpfXwQY=.d8a97e16-98f4-4488-bc84-2392ca20c7e5@github.com> > This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. > > Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. > > Classfile API development is tracked at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch > > Development branch of consolidated JDK class files parsing, generating, and transforming is at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch > > Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. > > Please take you time to review this non-trivial JDK addition. > > Thank you, > Adam Adam Sotona has updated the pull request incrementally with two additional commits since the last revision: - added comment to CodeAttribute::labelToBci - ClassReader::readXyzEntry methods throw IllegalArgumentException instead of ClassCastException ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10982/files - new: https://git.openjdk.org/jdk/pull/10982/files/79ce1698..13d78c96 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=34 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=33-34 Stats: 22 lines in 3 files changed: 8 ins; 2 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/10982.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982 PR: https://git.openjdk.org/jdk/pull/10982 From asotona at openjdk.org Thu Mar 2 13:03:54 2023 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 2 Mar 2023 13:03:54 GMT Subject: RFR: 8294982: Implementation of Classfile API [v31] In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 23:07:38 GMT, Paul Sandoz wrote: >> Adam Sotona has updated the pull request incrementally with four additional commits since the last revision: >> >> - renamed all remaining ConcreteXyzEntry to XyzEntryImpl >> - abstract implementations of RefEntry, RefsEntry and NamedEntry renamed to AbstractRefEntry, AbstractRefsEntry and AbstractNamedEntry >> - renamed ConcreteBootstrapMethodEntry to BootstrapMethodEntryImpl >> - ConcreteEntry renamed to AbstractPoolEntry > > src/java.base/share/classes/jdk/internal/classfile/ClassReader.java line 144: > >> 142: * constant pool size, or zero >> 143: * @throws ClassCastException if the index does not correspond to >> 144: * a module entry > > Throwing `ClassCastException` is certainly convenient from an implementation perspective, but I think it is better to throw `IllegalArgumentException`. Fixed in all `ClassReader::readXyzEntry` methods, thanks. > src/java.base/share/classes/jdk/internal/classfile/impl/ClassReaderImpl.java line 90: > >> 88: private BootstrapMethodsAttribute bootstrapMethodsAttribute; >> 89: >> 90: @SuppressWarnings("unchecked") > > Is this needed? not needed, removed, thanks > src/java.base/share/classes/jdk/internal/classfile/impl/ClassReaderImpl.java line 115: > >> 113: >> 114: // 4 >> 115: case TAG_CONSTANTDYNAMIC, TAG_FIELDREF, TAG_FLOAT, TAG_INTEGER, TAG_INTERFACEMETHODREF, TAG_INVOKEDYNAMIC, TAG_METHODREF, TAG_NAMEANDTYPE -> p += 4; > > Break the line fixed, thanks. > src/java.base/share/classes/jdk/internal/classfile/impl/ClassReaderImpl.java line 132: > >> 130: this.cp = new PoolEntry[constantPoolCount]; >> 131: >> 132: p = metadataStart; > > Redundant assignment (see line 127). fixed, thanks. ------------- PR: https://git.openjdk.org/jdk/pull/10982 From mullan at openjdk.org Thu Mar 2 13:24:07 2023 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 2 Mar 2023 13:24:07 GMT Subject: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 12:03:44 GMT, Pavel Rappo wrote: > Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API. > > The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows: > > > diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html > --- build/macosx-aarch64/images/docs-before/api/serialized-form.html 2023-03-02 11:47:44 > +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html 2023-03-02 11:48:45 > @@ -17084,7 +17084,7 @@ > throws IOException, > ClassNotFoundException >
readObject is called to restore the state of the > - (@code BasicPermission} from a stream.
> + BasicPermission from a stream. >
>
Parameters:
>
s - the ObjectInputStream from which data is read
> > Notes > ----- > > * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas. > * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary. > * I will update copyright years after (and if) the fix had been approved, as required. security related changes look fine. ------------- Marked as reviewed by mullan (Reviewer). PR: https://git.openjdk.org/jdk/pull/12826 From duke at openjdk.org Thu Mar 2 13:29:33 2023 From: duke at openjdk.org (Saint Wesonga) Date: Thu, 2 Mar 2023 13:29:33 GMT Subject: Integrated: 8303409: Add Windows AArch64 ABI support to the Foreign Function & Memory API In-Reply-To: References: Message-ID: On Mon, 27 Feb 2023 17:04:28 GMT, Saint Wesonga wrote: > There are 2 primary differences between the Windows ARM64 ABI and the macOS/Linux ARM64 ABI: variadic floating point arguments are passed in general purpose registers on Windows (instead of the vector registers). In addition to this, up to 64 bytes of a struct being passed to a variadic function can be placed in general purpose registers. This happens regardless of the type of struct (HFA or other generic struct). This means that a struct can be split across registers and the stack when invoking a variadic function. The Windows ARM64 ABI conventions are documented at https://learn.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions > > For details about the Foreign Function & Memory API, see JEP 434 at https://openjdk.org/jeps/434 > > This change is a cherry pick of https://github.com/openjdk/panama-foreign/commit/d379ca1c and https://github.com/openjdk/panama-foreign/commit/08225e4f from https://github.com/openjdk/panama-foreign/pull/754 and includes an additional commit that introduces a VaList implementation for Windows on AArch64. This pull request has now been integrated. Changeset: fb130639 Author: Saint Wesonga Committer: Jorn Vernee URL: https://git.openjdk.org/jdk/commit/fb1306394368bdfe3ccfe4980c663d0a56b4a643 Stats: 2135 lines in 20 files changed: 1445 ins; 650 del; 40 mod 8303409: Add Windows AArch64 ABI support to the Foreign Function & Memory API Reviewed-by: jvernee ------------- PR: https://git.openjdk.org/jdk/pull/12773 From thartmann at openjdk.org Thu Mar 2 13:38:13 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Thu, 2 Mar 2023 13:38:13 GMT Subject: RFR: 8143900: OptimizeStringConcat has an opaque dependency on Integer.sizeTable field [v3] In-Reply-To: References: Message-ID: On Mon, 27 Feb 2023 02:16:21 GMT, Yi Yang wrote: >> Hi, can I have a review for this patch? I noticed a strange field Integer.sizeTable which is used by PhaseStringOpts, after digging into the history, I think it could be replaced by an in-place array allocation and initialization. Before it, we are fetching from Integer.sizeTable and get num of digit in integer by iterating size table, now we fetch from in-place sizeTable and get size from that. The changed IR looks like this: >> >> ![image](https://user-images.githubusercontent.com/5010047/220239446-7b8b8381-b300-4f2c-a24a-aa19ec9e2f88.png) >> >> Thanks. > > Yi Yang has updated the pull request incrementally with one additional commit since the last revision: > > comment from review feedback Looks good to me too. ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.org/jdk/pull/12680 From erikj at openjdk.org Thu Mar 2 14:09:08 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 2 Mar 2023 14:09:08 GMT Subject: RFR: JDK-8302801: Remove fdlibm C sources In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 05:54:52 GMT, Joe Darcy wrote: > While the review of https://github.com/openjdk/jdk/pull/12800 finishes up, I thought I'd get out for the review the next phase of the FDLIBM port: removing the FDLIBM C sources from the repo. > > A repo with the changes for JDK-8302027 and this PR successful build on the default set of platform and successfully run tier 1 tests, which includes tests of the math library. > > There are a few remaining references to the case-independent string "fdlibm" in the make directory and HotSpot sources. HotSpot contains a partial fork for FDLIBM (a tine of FDLIBM?) to use for intrinsics. The remaining make machinery contains logic to determine what set of gcc options can be used for the compile. > > The intention of this change is to remove use of FDLIBM for the core libraries. make/autoconf/buildjdk-spec.gmk.in line 85: > 83: JVM_LIBS := @OPENJDK_BUILD_JVM_LIBS@ > 84: > 85: FDLIBM_CFLAGS := @OPENJDK_BUILD_FDLIBM_CFLAGS@ If the hotspot build still needs `FDLIBM_CFLAGS`, then this line needs to stay. ------------- PR: https://git.openjdk.org/jdk/pull/12821 From alanb at openjdk.org Thu Mar 2 14:16:06 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 2 Mar 2023 14:16:06 GMT Subject: RFR: 8301622: ProcessTools.java compilation gets ThreadDeath deprecation warning In-Reply-To: References: Message-ID: <6DJKnl1KHpUHIvIfdjn3KYAKJhvu9iLRhlz0CVL8DlA=.3324e840-6812-4020-b93b-9aea9d2442f1@github.com> On Thu, 2 Mar 2023 12:15:21 GMT, Afshin Zafari wrote: > ### Description > The use of `ThreadDeath` is replaced with checking the exception be of type `Error` and the thread is `TERMINATED`. > > > ### Test > local and mach5 tier1 test/lib/jdk/test/lib/process/ProcessTools.java line 827: > 825: > 826: public void uncaughtException(Thread t, Throwable e) { > 827: if (e instanceof Error && t.getState() == State.TERMINATED) { Dropping the check for ThreadDeath is fine but checking the thread state is puzzling. When a Thread completes with an uncaught exception/error then the UHE is called from the thread before it terminates so it's state won't be TERMINATED. Is there more going on here that the UHE is called with an already terminated Thread? ------------- PR: https://git.openjdk.org/jdk/pull/12827 From alanb at openjdk.org Thu Mar 2 14:21:09 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 2 Mar 2023 14:21:09 GMT Subject: RFR: 8302791: Add specific ClassLoader object to Proxy IllegalArgumentException message [v5] In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 10:32:48 GMT, Ravali Yatham wrote: >> Added specific class loader object to proxy IllegalArgumentException from which the class was not visible >> >> The bug report for the same: https://bugs.openjdk.org/browse/JDK-8302791 > > Ravali Yatham has updated the pull request incrementally with one additional commit since the last revision: > > Avoid long line of code Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12641 From alanb at openjdk.org Thu Mar 2 14:21:13 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 2 Mar 2023 14:21:13 GMT Subject: RFR: 8302791: Add specific ClassLoader object to Proxy IllegalArgumentException message [v4] In-Reply-To: References: <0jQQEOJWyqjmAP3UgPGk7V1muce0Yx14nWIlBnkOgas=.095d14d8-ee3c-4089-bb62-6f7d1c0100d5@github.com> Message-ID: <2R2lxJGzA5rDl4k2PSsKI6fIZ-ob8HdbSrWtKfRyv9M=.9d24250a-3d90-497c-af37-f672b4398bc0@github.com> On Wed, 1 Mar 2023 15:08:02 GMT, Alan Bateman wrote: >> Ravali Yatham has updated the pull request incrementally with one additional commit since the last revision: >> >> Add comments > > src/java.base/share/classes/java/lang/reflect/Proxy.java line 889: > >> 887: : Objects.toIdentityString(ld); >> 888: throw new IllegalArgumentException(c.getName() + >> 889: " referenced from a method is not visible from class loader: " + nid); > > Thanks for the update, this looks much better. A passing thought is that you might want to use "/" instead of "@" as the separator so that someone looking at the exception message will be able to distinguish a class name from a class loader name. Also you might want to re-format L886 to avoid the really long line as it's a bit inconsistent with the code in this source file. > Thanks @AlanBateman. Regarding the separator, Have seen this being used in ClassLoader.java for nameAndId method. Hence used the same for consistency. I've reformatted L886 now, Please kindly check. Thanks for checking, the updated version looks good. ------------- PR: https://git.openjdk.org/jdk/pull/12641 From asotona at openjdk.org Thu Mar 2 14:31:06 2023 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 2 Mar 2023 14:31:06 GMT Subject: RFR: 8294982: Implementation of Classfile API [v36] In-Reply-To: References: Message-ID: > This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. > > Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. > > Classfile API development is tracked at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch > > Development branch of consolidated JDK class files parsing, generating, and transforming is at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch > > Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. > > Please take you time to review this non-trivial JDK addition. > > Thank you, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: StackMapFrameInfo extracted to top level from StackMapTableAttribute ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10982/files - new: https://git.openjdk.org/jdk/pull/10982/files/13d78c96..074dd304 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=35 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=34-35 Stats: 225 lines in 6 files changed: 123 ins; 93 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/10982.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982 PR: https://git.openjdk.org/jdk/pull/10982 From asotona at openjdk.org Thu Mar 2 14:32:09 2023 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 2 Mar 2023 14:32:09 GMT Subject: RFR: 8294982: Implementation of Classfile API [v13] In-Reply-To: <2nbxm42RWgHdKnlYOUL4AI3cIJsidHjP5LUpMbOEbrs=.25776a2b-7aed-4719-904e-fd9f4a013d5a@github.com> References: <2nbxm42RWgHdKnlYOUL4AI3cIJsidHjP5LUpMbOEbrs=.25776a2b-7aed-4719-904e-fd9f4a013d5a@github.com> Message-ID: On Wed, 1 Mar 2023 23:57:52 GMT, Paul Sandoz wrote: >> Every case has been considered individually, evaluated on use cases and pros and cons have been weighted. Unified approach across the whole API would be nice, however not so simple and not the highest priority. > > I had the same observation as Maurizio. I've extracted `StackMapFrameInfo` to the top level and moved `VerificationTypeInfo`, however it is still nested. Let me know if you think we should really avoid all nested or if info inside info is OK. Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/10982 From duke at openjdk.org Thu Mar 2 14:33:58 2023 From: duke at openjdk.org (Viktor Klang) Date: Thu, 2 Mar 2023 14:33:58 GMT Subject: RFR: JDK-8297605 DelayQueue javadoc is confusing In-Reply-To: <3sC0ll4wZ6mBKGu6Gs2t5GHcr_JBqPDBgvvhyW5xQBk=.f9937235-271d-4d4e-9fcd-dfafe47f4315@github.com> References: <3sC0ll4wZ6mBKGu6Gs2t5GHcr_JBqPDBgvvhyW5xQBk=.f9937235-271d-4d4e-9fcd-dfafe47f4315@github.com> Message-ID: On Thu, 2 Mar 2023 02:03:51 GMT, Martin Buchholz wrote: >>> @Martin-Buchholz Martin, how would you like to proceed with your proposed wording, would you prefer a suggested edit to this PR, do a separate PR, or otherwise? /cc @AlanBateman (any recommendation, Alan? thinking ) >> >> Talked me into it - I will dust off my github/skara skillz and make a new PR. >> >> I wonder if there's now a way to override javadoc for remove() without creating a new method body. > >> I wonder if there's now a way to override javadoc for remove() without creating a new method body. > > I thought recent javadoc features might have been useful here, but I scanned the results from this jql: > > > subcomponent in ( "javadoc(tool)", "doclet" ) AND (resolution in ( Fixed, Approved ) ) AND issuetype in (JEP, Enhancement) ORDER BY resolved DESC > > > and came up empty @Martin-Buchholz @pavelrappo OTOH I see that DelayQueue *has already* overridden `remove(Object o)` so you should be able to modify that? ------------- PR: https://git.openjdk.org/jdk/pull/12729 From rriggs at openjdk.org Thu Mar 2 15:38:16 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 2 Mar 2023 15:38:16 GMT Subject: RFR: 8302590: Add String.indexOf(int ch, int fromIndex, int toIndex) [v7] In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 10:24:03 GMT, Raffaello Giulietti wrote: >> Add an `indexOf()` variant allowing to specify both a lower and an upper bound on the search. > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > 8302590: Add String.indexOf(int ch, int fromIndex, int toIndex) The commit comments could be more informative and useful. ------------- PR: https://git.openjdk.org/jdk/pull/12600 From rriggs at openjdk.org Thu Mar 2 15:58:08 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 2 Mar 2023 15:58:08 GMT Subject: RFR: 8299807: newStringNoRepl should avoid copying arrays for ASCII compatible charsets [v4] In-Reply-To: References: Message-ID: On Sat, 28 Jan 2023 19:54:32 GMT, Glavo wrote: >> This is the javadoc of `JavaLangAccess::newStringNoRepl`: >> >> >> /** >> * Constructs a new {@code String} by decoding the specified subarray of >> * bytes using the specified {@linkplain java.nio.charset.Charset charset}. >> * >> * The caller of this method shall relinquish and transfer the ownership of >> * the byte array to the callee since the later will not make a copy. >> * >> * @param bytes the byte array source >> * @param cs the Charset >> * @return the newly created string >> * @throws CharacterCodingException for malformed or unmappable bytes >> */ >> >> >> It is recorded in the document that it should be able to directly construct strings with parameter byte array to reduce array allocation. >> >> However, at present, `newStringNoRepl` always copies arrays for UTF-8 or other ASCII compatible charsets. >> >> This PR fixes this problem. > > Glavo has updated the pull request incrementally with one additional commit since the last revision: > > update Looks good, thanks for the updates. ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.org/jdk/pull/12119 From martin at openjdk.org Thu Mar 2 16:02:31 2023 From: martin at openjdk.org (Martin Buchholz) Date: Thu, 2 Mar 2023 16:02:31 GMT Subject: RFR: JDK-8297605 DelayQueue javadoc is confusing In-Reply-To: <3sC0ll4wZ6mBKGu6Gs2t5GHcr_JBqPDBgvvhyW5xQBk=.f9937235-271d-4d4e-9fcd-dfafe47f4315@github.com> References: <3sC0ll4wZ6mBKGu6Gs2t5GHcr_JBqPDBgvvhyW5xQBk=.f9937235-271d-4d4e-9fcd-dfafe47f4315@github.com> Message-ID: <-RLFuLCSoctbO5UPfrDDmR9uiUGEv1vqGlR6Qz8WkKk=.018ccc77-32e7-47cc-988f-8de319868134@github.com> On Thu, 2 Mar 2023 02:03:51 GMT, Martin Buchholz wrote: >>> @Martin-Buchholz Martin, how would you like to proceed with your proposed wording, would you prefer a suggested edit to this PR, do a separate PR, or otherwise? /cc @AlanBateman (any recommendation, Alan? thinking ) >> >> Talked me into it - I will dust off my github/skara skillz and make a new PR. >> >> I wonder if there's now a way to override javadoc for remove() without creating a new method body. > >> I wonder if there's now a way to override javadoc for remove() without creating a new method body. > > I thought recent javadoc features might have been useful here, but I scanned the results from this jql: > > > subcomponent in ( "javadoc(tool)", "doclet" ) AND (resolution in ( Fixed, Approved ) ) AND issuetype in (JEP, Enhancement) ORDER BY resolved DESC > > > and came up empty > @Martin-Buchholz @pavelrappo OTOH I see that DelayQueue _has already_ overridden `remove(Object o)` so you should be able to modify that? Right. But remove(Object) unlike remove() doesn't consider the expiration time. Confusing! ------------- PR: https://git.openjdk.org/jdk/pull/12729 From naoto at openjdk.org Thu Mar 2 16:17:08 2023 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 2 Mar 2023 16:17:08 GMT Subject: RFR: 8303472: Display name for region TR [v2] In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 23:45:47 GMT, Justin Lu wrote: >> This PR changes the English name for the region `TR`, from `Turkey` to `T?rkiye`. Although this change is included in the upcoming CLDR v43, it should be applied as a spot change so that it can be back-ported properly (As it is a common English region name). >> >> >> >> This change targets both the CLDR and COMPAT data. > > Justin Lu has updated the pull request incrementally with two additional commits since the last revision: > > - Supply test with changes, use unicode escapes to be consistent > - copyright year Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12816 From psandoz at openjdk.org Thu Mar 2 16:22:19 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 2 Mar 2023 16:22:19 GMT Subject: RFR: JDK-8302666: Replace CHM with VarHandle in ForeachOrderedTask [v4] In-Reply-To: References: Message-ID: On Tue, 28 Feb 2023 10:53:14 GMT, Viktor Klang wrote: >> src/java.base/share/classes/java/util/stream/ForEachOps.java line 513: >> >>> 511: // of right subtree (if any, which can be this task's right sibling) >>> 512: // >>> 513: var leftDescendant = (ForEachOrderedTask)NEXT.getAndSet(this, null); >> >> Casting the?`null` is?required for?the?resolved method?descriptor to?be?`(ForEachOrderedTask, ForEachOrderedTask)ForEachOrderedTask` instead?of?`(ForEachOrderedTask, Object)ForEachOrderedTask`, which?prevents unnecessary type?conversion `LambdaForm`s from?being?introduced and?allows [`VarHandle::withInvokeExactBehavior`] to?be?used: >> Suggestion: >> >> var leftDescendant = (ForEachOrderedTask) NEXT.getAndSet(this, (ForEachOrderedTask) null); >> >> >> [`VarHandle::withInvokeExactBehavior`]: https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/lang/invoke/VarHandle.html#withInvokeExactBehavior() > > @ExE-Boss Ah, sorry, it was meant to be there. :) VarHandles are more optimized than MethodHandles when the signature at the call site does not match the signature of the handle. For referenced casts of arguments VarHandles avoid the `asType` conversion that would occur with method handles. This makes it much easier to write/read. VarHandle::withInvokeExactBehavior was introduced to deal with cases where an exact signature match is required. Sometimes this is useful to avoid performance potholes resulting from unintended primitive casts/conversions, where VarHandles otherwise resort to `asType` conversion. ------------- PR: https://git.openjdk.org/jdk/pull/12320 From iris at openjdk.org Thu Mar 2 16:42:18 2023 From: iris at openjdk.org (Iris Clark) Date: Thu, 2 Mar 2023 16:42:18 GMT Subject: RFR: 8303039: Utilize `coverageLevels.txt` [v2] In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 01:03:20 GMT, Naoto Sato wrote: >> This is a pre-requisite for supporting CLDR v43, where they combine `seeds` locales with `common` locales (https://cldr.unicode.org/index/downloads/cldr-43#h.7s25aqdv767e). In order to have the same coverage level of locales, CLDRConverter tool needs to comb through the locale files based on the `coverageLevels.txt` file, (and the ones we already included as of v42). Confirmed the same set of locales is generated before and after this modification. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Explicitly filter coverage levels Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12812 From duke at openjdk.org Thu Mar 2 16:45:08 2023 From: duke at openjdk.org (Steven R. Loomis) Date: Thu, 2 Mar 2023 16:45:08 GMT Subject: RFR: 8303472: Display name for region TR [v2] In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 23:45:47 GMT, Justin Lu wrote: >> This PR changes the English name for the region `TR`, from `Turkey` to `T?rkiye`. Although this change is included in the upcoming CLDR v43, it should be applied as a spot change so that it can be back-ported properly (As it is a common English region name). >> >> >> >> This change targets both the CLDR and COMPAT data. > > Justin Lu has updated the pull request incrementally with two additional commits since the last revision: > > - Supply test with changes, use unicode escapes to be consistent > - copyright year Marked as reviewed by srl295 at github.com (no known OpenJDK username). ------------- PR: https://git.openjdk.org/jdk/pull/12816 From naoto at openjdk.org Thu Mar 2 16:47:08 2023 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 2 Mar 2023 16:47:08 GMT Subject: RFR: 8303275: Use {@Return and @linkplain in Locale and related classes In-Reply-To: <9XzLdPaTCaYpzrJStx2riu1ZTMIYEgZOkPIy_CgK5jk=.0ec33845-108e-4651-9e6e-6be6c7cc3ef4@github.com> References: <9XzLdPaTCaYpzrJStx2riu1ZTMIYEgZOkPIy_CgK5jk=.0ec33845-108e-4651-9e6e-6be6c7cc3ef4@github.com> Message-ID: On Tue, 28 Feb 2023 00:09:45 GMT, Justin Lu wrote: > This PR modifies the javadoc of methods in Locale, LocaleServiceProvider, and LocaleServiceProviderPool to use {@return and @linkplain. src/java.base/share/classes/java/util/Locale.java line 2075: > 2073: * user. This will be the values returned by getDisplayLanguage(), > 2074: * getDisplayScript(), getDisplayCountry(), getDisplayVariant() and > 2075: * optional {@linkplain Locale##def_locale_extension Unicode extensions} Can `Locale` be removed? It seems redundant. There are other locations with the same situation in this class. ------------- PR: https://git.openjdk.org/jdk/pull/12780 From mullan at openjdk.org Thu Mar 2 16:52:07 2023 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 2 Mar 2023 16:52:07 GMT Subject: RFR: 8297955: LDAP CertStore should use LdapName and not String for DNs Message-ID: The LDAPCertStore implementation passes Distinguished Names in CRL and Certificate URLs as Strings to JNDI APIs such as LdapContext.getAttributes(String), which then treats them as CompositeNames. This causes issues with URLs that have DNs with forward slashes. These are rare but compliant with the LDAP URL format for DNs referenced by [section 4.2.1.13 of RFC 5280](https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.13). Instead, the implementation should be passing the DN to JNDI APIs as an LdapName, which parses the forward slash character as part of the DN. Unfortunately, LDAP referral URLs can not be converted to LdapNames, so we keep the current DN syntax checks (and disallow forward slashes) if there are referrals involved. The current test/jdk/security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.java can be used to test this fix as it contains a test certificate with an LDAP URL in the CRL Distribution Points with a forward slash in the Distinguished Name. Prior to the fix it was failing because of this bug, now it is passing. We also take this opportunity to update the test and replace expired test certificates with new ones. ------------- Commit messages: - Add comments. Update Actalis test certificates. - Restore checking of composite name on referral URL. - Merge - Update copyright date. - Merge - Initial revision. Changes: https://git.openjdk.org/jdk/pull/12730/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12730&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297955 Stats: 62 lines in 2 files changed: 11 ins; 8 del; 43 mod Patch: https://git.openjdk.org/jdk/pull/12730.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12730/head:pull/12730 PR: https://git.openjdk.org/jdk/pull/12730 From rgiulietti at openjdk.org Thu Mar 2 16:54:28 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Thu, 2 Mar 2023 16:54:28 GMT Subject: RFR: 8302590: Add String.indexOf(int ch, int fromIndex, int toIndex) [v7] In-Reply-To: References: Message-ID: <9VRwe3jdAwTVB0lizb44gM79rIvJbE7YXI3j5P69rgE=.4fceee69-4661-4f5e-8840-b692e620b425@github.com> On Thu, 2 Mar 2023 10:24:03 GMT, Raffaello Giulietti wrote: >> Add an `indexOf()` variant allowing to specify both a lower and an upper bound on the search. > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > 8302590: Add String.indexOf(int ch, int fromIndex, int toIndex) The last commit renames the new method's parameters to align with other methods (like `substring(int beginIndex, int endIndex)`) that check that indices are in range. It also rephrases the `@apiNote` on `indexOf(int ch, int fromIndex)`. ------------- PR: https://git.openjdk.org/jdk/pull/12600 From alex.buckley at oracle.com Thu Mar 2 17:04:30 2023 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 2 Mar 2023 09:04:30 -0800 Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v42] In-Reply-To: References: <9XP497xudeRhZKkIpxIgpbqT24eG8SCbfG6TelYtM3M=.f1ad5a76-798c-4e3d-b43b-a25a20210154@github.com> Message-ID: <78f03eda-ea1d-40f2-2a57-1ec805aa1d3e@oracle.com> On 3/2/2023 3:14 AM, Jim Laskey wrote: > Can I get some signing reviewers of the CSR https://bugs.openjdk.org/browse/JDK-8286021 ? I added remarks to the CSR about the static field STR that is automatically imported into every Java program. (Only when preview features are enabled, right?) Alex From psandoz at openjdk.org Thu Mar 2 17:13:16 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 2 Mar 2023 17:13:16 GMT Subject: RFR: 8294982: Implementation of Classfile API [v13] In-Reply-To: References: <2nbxm42RWgHdKnlYOUL4AI3cIJsidHjP5LUpMbOEbrs=.25776a2b-7aed-4719-904e-fd9f4a013d5a@github.com> Message-ID: On Thu, 2 Mar 2023 14:29:13 GMT, Adam Sotona wrote: >> I had the same observation as Maurizio. > > I've extracted `StackMapFrameInfo` to the top level and moved `VerificationTypeInfo`, however it is still nested. > Let me know if you think we should really avoid all nested or if info inside info is OK. > Thanks. That seems reasonable (top level `StackMapFrameInfo` with nesting for less important stuff.) ------------- PR: https://git.openjdk.org/jdk/pull/10982 From james.laskey at oracle.com Thu Mar 2 17:14:13 2023 From: james.laskey at oracle.com (Jim Laskey) Date: Thu, 2 Mar 2023 17:14:13 +0000 Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v42] In-Reply-To: <78f03eda-ea1d-40f2-2a57-1ec805aa1d3e@oracle.com> References: <9XP497xudeRhZKkIpxIgpbqT24eG8SCbfG6TelYtM3M=.f1ad5a76-798c-4e3d-b43b-a25a20210154@github.com> <78f03eda-ea1d-40f2-2a57-1ec805aa1d3e@oracle.com> Message-ID: <12FF7F62-040D-4F2D-B68F-BA5AC0DA5EE2@oracle.com> Correct and thank you. ? > On Mar 2, 2023, at 1:04 PM, Alex Buckley wrote: > > ?On 3/2/2023 3:14 AM, Jim Laskey wrote: >> Can I get some signing reviewers of the CSR https://bugs.openjdk.org/browse/JDK-8286021 ? > > I added remarks to the CSR about the static field STR that is automatically imported into every Java program. (Only when preview features are enabled, right?) > > Alex From bpb at openjdk.org Thu Mar 2 17:26:53 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 2 Mar 2023 17:26:53 GMT Subject: RFR: 8303175: (fs) Deprecate com.sun.nio.file.SensitivityWatchEventModifier for removal [v5] In-Reply-To: References: Message-ID: > Deprecate `SensitivityWatchEventModifier` for now instead of directly removing it as proposed in #12626. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8303175: Improve @deprecated verbiage in SensitivityWatchEventModifier ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12746/files - new: https://git.openjdk.org/jdk/pull/12746/files/45d63422..ca92fdba Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12746&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12746&range=03-04 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/12746.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12746/head:pull/12746 PR: https://git.openjdk.org/jdk/pull/12746 From bpb at openjdk.org Thu Mar 2 17:26:57 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 2 Mar 2023 17:26:57 GMT Subject: RFR: 8303175: (fs) Deprecate com.sun.nio.file.SensitivityWatchEventModifier for removal [v4] In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 07:44:06 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8303175: Change @deprecated verbiage in SensitivityWatchEventModifier > > src/jdk.unsupported/share/classes/com/sun/nio/file/SensitivityWatchEventModifier.java line 41: > >> 39: * which used this {@code WatchEvent.Modifier}. Therefore this >> 40: * {@code WatchEvent.Modifier} class is vestigial and should be removed in a >> 41: * future release. > > "no longer recognizes" suggests that using them will lead to an error but it's actually that they will be just ignored. > > Also "should be removed in a future release" will duplicate text generated by javadoc. The JDK docs build doesn't generate javadoc for the jdk.unsupported module so maybe it doesn't matter but here's a suggestion for something a bit briefer: > > "The sensitivity levels were historically used by polling based WatchService implementations to configure the polling interval. They are are no longer used. The WatchService implementations in the JDK ignore these WatchEvent modifiers if they are specified when registering a directory to be watched." Thanks, that is much better; used in ca92fdba0897b7acfedc3bc933b874c3b421a0a3. ------------- PR: https://git.openjdk.org/jdk/pull/12746 From igraves at openjdk.org Thu Mar 2 17:27:47 2023 From: igraves at openjdk.org (Ian Graves) Date: Thu, 2 Mar 2023 17:27:47 GMT Subject: RFR: 8217496: Matcher.group() can return null after usePattern Message-ID: Updates to the documentation to describe behavior in Matcher.group(). ------------- Commit messages: - Updating verbiage - Merge branch 'master' into matcher-group-doc-update - 8217496 Matcher.group() can return null after usePattern Changes: https://git.openjdk.org/jdk/pull/12835/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12835&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8217496 Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/12835.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12835/head:pull/12835 PR: https://git.openjdk.org/jdk/pull/12835 From duke at openjdk.org Thu Mar 2 17:31:18 2023 From: duke at openjdk.org (Afshin Zafari) Date: Thu, 2 Mar 2023 17:31:18 GMT Subject: RFR: 8301622: ProcessTools.java compilation gets ThreadDeath deprecation warning In-Reply-To: <6DJKnl1KHpUHIvIfdjn3KYAKJhvu9iLRhlz0CVL8DlA=.3324e840-6812-4020-b93b-9aea9d2442f1@github.com> References: <6DJKnl1KHpUHIvIfdjn3KYAKJhvu9iLRhlz0CVL8DlA=.3324e840-6812-4020-b93b-9aea9d2442f1@github.com> Message-ID: On Thu, 2 Mar 2023 14:13:10 GMT, Alan Bateman wrote: >> ### Description >> The use of `ThreadDeath` is replaced with checking the exception be of type `Error` and the thread is `TERMINATED`. >> >> >> ### Test >> local and mach5 tier1 > > test/lib/jdk/test/lib/process/ProcessTools.java line 827: > >> 825: >> 826: public void uncaughtException(Thread t, Throwable e) { >> 827: if (e instanceof Error && t.getState() == State.TERMINATED) { > > Dropping the check for ThreadDeath is fine but checking the thread state is puzzling. When a Thread completes with an uncaught exception/error then the UHE is called from the thread before it terminates so it's state won't be TERMINATED. Is there more going on here that the UHE is called with an already terminated Thread? I assumed the `ThreadDeath` was there to catch `Thread.stop()` calls and just ignore them. So, I wanted to keep this functionality. Can we remove using `ThreadDeath` relying on that `Thread.stop()` is also deprecated? ------------- PR: https://git.openjdk.org/jdk/pull/12827 From joehw at openjdk.org Thu Mar 2 17:32:16 2023 From: joehw at openjdk.org (Joe Wang) Date: Thu, 2 Mar 2023 17:32:16 GMT Subject: RFR: 8303039: Utilize `coverageLevels.txt` [v2] In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 01:03:20 GMT, Naoto Sato wrote: >> This is a pre-requisite for supporting CLDR v43, where they combine `seeds` locales with `common` locales (https://cldr.unicode.org/index/downloads/cldr-43#h.7s25aqdv767e). In order to have the same coverage level of locales, CLDRConverter tool needs to comb through the locale files based on the `coverageLevels.txt` file, (and the ones we already included as of v42). Confirmed the same set of locales is generated before and after this modification. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Explicitly filter coverage levels Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12812 From alanb at openjdk.org Thu Mar 2 17:38:15 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 2 Mar 2023 17:38:15 GMT Subject: RFR: 8301622: ProcessTools.java compilation gets ThreadDeath deprecation warning In-Reply-To: References: <6DJKnl1KHpUHIvIfdjn3KYAKJhvu9iLRhlz0CVL8DlA=.3324e840-6812-4020-b93b-9aea9d2442f1@github.com> Message-ID: <471GonMmx1x-bXzHkzjWs3w3MNuOuf54zYzZXSpMUxk=.ae71e576-4796-412f-bd65-51f1ecf5b457@github.com> On Thu, 2 Mar 2023 17:27:59 GMT, Afshin Zafari wrote: >> test/lib/jdk/test/lib/process/ProcessTools.java line 827: >> >>> 825: >>> 826: public void uncaughtException(Thread t, Throwable e) { >>> 827: if (e instanceof Error && t.getState() == State.TERMINATED) { >> >> Dropping the check for ThreadDeath is fine but checking the thread state is puzzling. When a Thread completes with an uncaught exception/error then the UHE is called from the thread before it terminates so it's state won't be TERMINATED. Is there more going on here that the UHE is called with an already terminated Thread? > > I assumed the `ThreadDeath` was there to catch `Thread.stop()` calls and just ignore them. So, I wanted to keep this functionality. > Can we remove using `ThreadDeath` relying on that `Thread.stop()` is also deprecated? I think it can be removed. ------------- PR: https://git.openjdk.org/jdk/pull/12827 From alanb at openjdk.org Thu Mar 2 17:39:06 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 2 Mar 2023 17:39:06 GMT Subject: RFR: 8303175: (fs) Deprecate com.sun.nio.file.SensitivityWatchEventModifier for removal [v5] In-Reply-To: References: Message-ID: <7cGs8eEO2tccx5Cq4IVCeAX774k-7G6UWxvkhzqRxYU=.fc47b2cd-d03a-407f-b633-6f56ce448e1f@github.com> On Thu, 2 Mar 2023 17:26:53 GMT, Brian Burkhalter wrote: >> Deprecate `SensitivityWatchEventModifier` for now instead of directly removing it as proposed in #12626. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8303175: Improve @deprecated verbiage in SensitivityWatchEventModifier Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12746 From duke at openjdk.org Thu Mar 2 17:43:54 2023 From: duke at openjdk.org (Afshin Zafari) Date: Thu, 2 Mar 2023 17:43:54 GMT Subject: RFR: 8301622: ProcessTools.java compilation gets ThreadDeath deprecation warning [v2] In-Reply-To: References: Message-ID: > ### Description > The use of `ThreadDeath` is replaced with checking the exception be of type `Error` and the thread is `TERMINATED`. > > > ### Test > local and mach5 tier1 Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: 8301622: ProcessTools.java compilation gets ThreadDeath deprecation warning ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12827/files - new: https://git.openjdk.org/jdk/pull/12827/files/c03cd8f8..473b7cff Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12827&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12827&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12827.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12827/head:pull/12827 PR: https://git.openjdk.org/jdk/pull/12827 From alanb at openjdk.org Thu Mar 2 17:43:56 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 2 Mar 2023 17:43:56 GMT Subject: RFR: 8301622: ProcessTools.java compilation gets ThreadDeath deprecation warning [v2] In-Reply-To: References: Message-ID: <9q8GRBZhZsv0zX7w1QxkPySdB2M2KD6vw4oLwrL41QA=.8ea4568b-8bf4-428d-bd81-82641087e252@github.com> On Thu, 2 Mar 2023 17:39:10 GMT, Afshin Zafari wrote: >> ### Description >> The use of `ThreadDeath` is replaced with checking the exception be of type `Error` and the thread is `TERMINATED`. >> >> >> ### Test >> local and mach5 tier1 > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > 8301622: ProcessTools.java compilation gets ThreadDeath deprecation warning test/lib/jdk/test/lib/process/ProcessTools.java line 35: > 33: import java.io.OutputStream; > 34: import java.io.PrintStream; > 35: import java.lang.Thread.State; This is no longer needed. ------------- PR: https://git.openjdk.org/jdk/pull/12827 From darcy at openjdk.org Thu Mar 2 18:31:56 2023 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 2 Mar 2023 18:31:56 GMT Subject: RFR: JDK-8302801: Remove fdlibm C sources In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 07:12:01 GMT, Alan Bateman wrote: > This is a great milestone to get to! Does the comment at the top of sharedRuntimeTrig.cpp need updating? Updated several of the comments in the HotSpot sources and added a description of the transliteration process to StrictMath. ------------- PR: https://git.openjdk.org/jdk/pull/12821 From darcy at openjdk.org Thu Mar 2 18:31:54 2023 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 2 Mar 2023 18:31:54 GMT Subject: RFR: JDK-8302801: Remove fdlibm C sources [v2] In-Reply-To: References: Message-ID: > While the review of https://github.com/openjdk/jdk/pull/12800 finishes up, I thought I'd get out for the review the next phase of the FDLIBM port: removing the FDLIBM C sources from the repo. > > A repo with the changes for JDK-8302027 and this PR successful build on the default set of platform and successfully run tier 1 tests, which includes tests of the math library. > > There are a few remaining references to the case-independent string "fdlibm" in the make directory and HotSpot sources. HotSpot contains a partial fork for FDLIBM (a tine of FDLIBM?) to use for intrinsics. The remaining make machinery contains logic to determine what set of gcc options can be used for the compile. > > The intention of this change is to remove use of FDLIBM for the core libraries. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Respond to review feedback and add description of transliteration process. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12821/files - new: https://git.openjdk.org/jdk/pull/12821/files/a1a12347..481af9ad Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12821&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12821&range=00-01 Stats: 36 lines in 5 files changed: 22 ins; 5 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/12821.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12821/head:pull/12821 PR: https://git.openjdk.org/jdk/pull/12821 From darcy at openjdk.org Thu Mar 2 18:32:00 2023 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 2 Mar 2023 18:32:00 GMT Subject: RFR: JDK-8302801: Remove fdlibm C sources [v2] In-Reply-To: References: Message-ID: <3JvuLUDJO3_dzKHOsMocC6kGDEmnIQo_7uobd-VTzHg=.22565440-42ae-4d26-9d74-2cbb7c63f9ea@github.com> On Thu, 2 Mar 2023 14:05:55 GMT, Erik Joelsson wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> Respond to review feedback and add description of transliteration process. > > make/autoconf/buildjdk-spec.gmk.in line 85: > >> 83: JVM_LIBS := @OPENJDK_BUILD_JVM_LIBS@ >> 84: >> 85: FDLIBM_CFLAGS := @OPENJDK_BUILD_FDLIBM_CFLAGS@ > > If the hotspot build still needs `FDLIBM_CFLAGS`, then this line needs to stay. Okay; added back. ------------- PR: https://git.openjdk.org/jdk/pull/12821 From naoto at openjdk.org Thu Mar 2 18:35:24 2023 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 2 Mar 2023 18:35:24 GMT Subject: Integrated: 8303039: Utilize `coverageLevels.txt` In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 19:50:56 GMT, Naoto Sato wrote: > This is a pre-requisite for supporting CLDR v43, where they combine `seeds` locales with `common` locales (https://cldr.unicode.org/index/downloads/cldr-43#h.7s25aqdv767e). In order to have the same coverage level of locales, CLDRConverter tool needs to comb through the locale files based on the `coverageLevels.txt` file, (and the ones we already included as of v42). Confirmed the same set of locales is generated before and after this modification. This pull request has now been integrated. Changeset: 0b635579 Author: Naoto Sato URL: https://git.openjdk.org/jdk/commit/0b6355794101bda9de623016ce88f8abbb314f63 Stats: 319 lines in 4 files changed: 315 ins; 1 del; 3 mod 8303039: Utilize `coverageLevels.txt` Reviewed-by: iris, joehw ------------- PR: https://git.openjdk.org/jdk/pull/12812 From aturbanov at openjdk.org Thu Mar 2 18:42:24 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 2 Mar 2023 18:42:24 GMT Subject: RFR: JDK-8302323 Add repeat methods to StringBuilder/StringBuffer [v5] In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 12:54:44 GMT, Jim Laskey wrote: >> Add the ability to repeatedly append char and CharSequence data to StringBuilder/StringBuffer. > > Jim Laskey has updated the pull request incrementally with two additional commits since the last revision: > > - Move @since in subclasses > - Move @since src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1911: > 1909: if (cs instanceof String str) { > 1910: putStringAt(offset, str); > 1911: } else if (cs instanceof AbstractStringBuilder asb) { Suggestion: } else if (cs instanceof AbstractStringBuilder asb) { ------------- PR: https://git.openjdk.org/jdk/pull/12728 From duke at openjdk.org Thu Mar 2 18:54:23 2023 From: duke at openjdk.org (Matthew Donovan) Date: Thu, 2 Mar 2023 18:54:23 GMT Subject: RFR: 8298939: Refactor open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.sh to jtreg java test [v6] In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 15:25:07 GMT, Matthew Donovan wrote: >> Removed SSLSocketParametersTest.sh script (which just called a Java file) and configured the java code to run directly with jtreg > > Matthew Donovan 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 eight additional commits since the last revision: > > - Merge branch 'master' into rmi-sslparams > - cleaned up exception handling > - added System.exit when exceptions are thrown and refactored for clarity > - Merge branch 'master' into rmi-sslparams > - added default switch case and additional refactoring > - added exceptions for cases 4 and 5 > - clarified cases 4 and 5 > - 8298939: Refactor open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.sh to jtreg java test I created a new bug, JDK-8303525, for the additional refactoring suggestions. I assigned it to myself but wouldn't be bothered if someone else wanted to take it. ------------- PR: https://git.openjdk.org/jdk/pull/11910 From psandoz at openjdk.org Thu Mar 2 19:00:59 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 2 Mar 2023 19:00:59 GMT Subject: RFR: 8294982: Implementation of Classfile API [v36] In-Reply-To: References: Message-ID: <6Ja9on6nsT4dF8Gk6ZAlLzfugxMSiFgEo5XCrVMzwuA=.1b45e6db-62de-4e1c-bac8-882e4fe4d63b@github.com> On Thu, 2 Mar 2023 14:31:06 GMT, Adam Sotona wrote: >> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. >> >> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. >> >> Classfile API development is tracked at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch >> >> Development branch of consolidated JDK class files parsing, generating, and transforming is at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch >> >> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. >> >> Please take you time to review this non-trivial JDK addition. >> >> Thank you, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > StackMapFrameInfo extracted to top level from StackMapTableAttribute src/java.base/share/classes/jdk/internal/classfile/snippet-files/PackageSnippets.java line 157: > 155: if (!(ce instanceof MethodModel mm > 156: && mm.methodName().stringValue().startsWith("debug"))) > 157: classBuilder.with(ce); Indentation is confusing (even though its less concise its probably better to use braces for all the examples): Suggestion: classBuilder.with(ce); ------------- PR: https://git.openjdk.org/jdk/pull/10982 From bpb at openjdk.org Thu Mar 2 19:22:07 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 2 Mar 2023 19:22:07 GMT Subject: RFR: JDK-8302801: Remove fdlibm C sources [v2] In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 18:31:54 GMT, Joe Darcy wrote: >> While the review of https://github.com/openjdk/jdk/pull/12800 finishes up, I thought I'd get out for the review the next phase of the FDLIBM port: removing the FDLIBM C sources from the repo. >> >> A repo with the changes for JDK-8302027 and this PR successful build on the default set of platform and successfully run tier 1 tests, which includes tests of the math library. >> >> There are a few remaining references to the case-independent string "fdlibm" in the make directory and HotSpot sources. HotSpot contains a partial fork for FDLIBM (a tine of FDLIBM?) to use for intrinsics. The remaining make machinery contains logic to determine what set of gcc options can be used for the compile. >> >> The intention of this change is to remove use of FDLIBM for the core libraries. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback and add description of transliteration process. src/java.base/share/classes/java/lang/StrictMath.java line 45: > 43: * href="https://www.netlib.org/fdlibm/">{@code fdlibm}. These > 44: * algorithms, which are written in the C programming language, are > 45: * then to be understood to be transliterated into Java and executed This change looks good (did not build and view javadoc). ------------- PR: https://git.openjdk.org/jdk/pull/12821 From alanb at openjdk.org Thu Mar 2 19:28:10 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 2 Mar 2023 19:28:10 GMT Subject: RFR: JDK-8302801: Remove fdlibm C sources [v2] In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 18:31:54 GMT, Joe Darcy wrote: >> While the review of https://github.com/openjdk/jdk/pull/12800 finishes up, I thought I'd get out for the review the next phase of the FDLIBM port: removing the FDLIBM C sources from the repo. >> >> A repo with the changes for JDK-8302027 and this PR successful build on the default set of platform and successfully run tier 1 tests, which includes tests of the math library. >> >> There are a few remaining references to the case-independent string "fdlibm" in the make directory and HotSpot sources. HotSpot contains a partial fork for FDLIBM (a tine of FDLIBM?) to use for intrinsics. The remaining make machinery contains logic to determine what set of gcc options can be used for the compile. >> >> The intention of this change is to remove use of FDLIBM for the core libraries. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback and add description of transliteration process. src/hotspot/share/runtime/sharedRuntimeTrig.cpp line 34: > 32: // StrictMath. Avoiding the indirect call through function > 33: // pointer out to libjava.so in SharedRuntime speeds these routines up > 34: // by roughly 15% on multiple architectures. These functions will no longer be in libjava so maybe the "Avoiding the indirect call ..." sentence should be dropped too. ------------- PR: https://git.openjdk.org/jdk/pull/12821 From psandoz at openjdk.org Thu Mar 2 19:30:57 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 2 Mar 2023 19:30:57 GMT Subject: RFR: 8294982: Implementation of Classfile API [v36] In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 14:31:06 GMT, Adam Sotona wrote: >> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. >> >> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. >> >> Classfile API development is tracked at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch >> >> Development branch of consolidated JDK class files parsing, generating, and transforming is at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch >> >> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. >> >> Please take you time to review this non-trivial JDK addition. >> >> Thank you, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > StackMapFrameInfo extracted to top level from StackMapTableAttribute src/java.base/share/classes/jdk/internal/classfile/instruction/CharacterRange.java line 42: > 40: * the setting of the {@link Classfile.Option#processDebug(boolean)} option. > 41: */ > 42: public sealed interface CharacterRange extends PseudoInstruction This and some other instructions with unbounded implementations do not have static `of` factory methods. Is that intended? ------------- PR: https://git.openjdk.org/jdk/pull/10982 From darcy at openjdk.org Thu Mar 2 19:33:47 2023 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 2 Mar 2023 19:33:47 GMT Subject: RFR: JDK-8302801: Remove fdlibm C sources [v2] In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 19:19:20 GMT, Brian Burkhalter wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> Respond to review feedback and add description of transliteration process. > > src/java.base/share/classes/java/lang/StrictMath.java line 45: > >> 43: * href="https://www.netlib.org/fdlibm/">{@code fdlibm}. These >> 44: * algorithms, which are written in the C programming language, are >> 45: * then to be understood to be transliterated into Java and executed > > This change looks good (did not build and view javadoc). I checked that the change rendered as desired in a local docs build. ------------- PR: https://git.openjdk.org/jdk/pull/12821 From psandoz at openjdk.org Thu Mar 2 19:35:27 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 2 Mar 2023 19:35:27 GMT Subject: RFR: 8294982: Implementation of Classfile API [v36] In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 14:31:06 GMT, Adam Sotona wrote: >> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. >> >> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. >> >> Classfile API development is tracked at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch >> >> Development branch of consolidated JDK class files parsing, generating, and transforming is at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch >> >> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. >> >> Please take you time to review this non-trivial JDK addition. >> >> Thank you, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > StackMapFrameInfo extracted to top level from StackMapTableAttribute src/java.base/share/classes/jdk/internal/classfile/components/CodeRelabeler.java line 98: > 96: @Override > 97: public void accept(CodeBuilder cob, CodeElement coe) { > 98: switch (coe) { Missing case for`CharacterRange` instruction? I am not sure it makes any sense, if so perhaps add a comment as to why. ------------- PR: https://git.openjdk.org/jdk/pull/10982 From jlu at openjdk.org Thu Mar 2 19:38:29 2023 From: jlu at openjdk.org (Justin Lu) Date: Thu, 2 Mar 2023 19:38:29 GMT Subject: RFR: 8303275: Use {@Return and @linkplain in Locale and related classes [v2] In-Reply-To: <9XzLdPaTCaYpzrJStx2riu1ZTMIYEgZOkPIy_CgK5jk=.0ec33845-108e-4651-9e6e-6be6c7cc3ef4@github.com> References: <9XzLdPaTCaYpzrJStx2riu1ZTMIYEgZOkPIy_CgK5jk=.0ec33845-108e-4651-9e6e-6be6c7cc3ef4@github.com> Message-ID: > This PR modifies the javadoc of methods in Locale, LocaleServiceProvider, and LocaleServiceProviderPool to use {@return and @linkplain. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: Remove prefix Locale for in-class linkplains ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12780/files - new: https://git.openjdk.org/jdk/pull/12780/files/cfbbfa0a..5850ca02 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12780&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12780&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/12780.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12780/head:pull/12780 PR: https://git.openjdk.org/jdk/pull/12780 From jlu at openjdk.org Thu Mar 2 19:38:31 2023 From: jlu at openjdk.org (Justin Lu) Date: Thu, 2 Mar 2023 19:38:31 GMT Subject: RFR: 8303275: Use {@Return and @linkplain in Locale and related classes [v2] In-Reply-To: References: <9XzLdPaTCaYpzrJStx2riu1ZTMIYEgZOkPIy_CgK5jk=.0ec33845-108e-4651-9e6e-6be6c7cc3ef4@github.com> Message-ID: On Thu, 2 Mar 2023 16:43:47 GMT, Naoto Sato wrote: >> Justin Lu has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove prefix Locale for in-class linkplains > > src/java.base/share/classes/java/util/Locale.java line 2075: > >> 2073: * user. This will be the values returned by getDisplayLanguage(), >> 2074: * getDisplayScript(), getDisplayCountry(), getDisplayVariant() and >> 2075: * optional {@linkplain Locale##def_locale_extension Unicode extensions} > > Can `Locale` be removed? It seems redundant. There are other locations with the same situation in this class. Yes, removed this and the other instances of `@linkplain` that use the _Locale_ prefix. I left the ones in `Locale.Builder` and `Locale.LanguageRange` since they are generated with different html pages and need the _Locale_ link. ------------- PR: https://git.openjdk.org/jdk/pull/12780 From psandoz at openjdk.org Thu Mar 2 19:49:58 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 2 Mar 2023 19:49:58 GMT Subject: RFR: 8294982: Implementation of Classfile API [v36] In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 14:31:06 GMT, Adam Sotona wrote: >> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. >> >> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. >> >> Classfile API development is tracked at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch >> >> Development branch of consolidated JDK class files parsing, generating, and transforming is at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch >> >> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. >> >> Please take you time to review this non-trivial JDK addition. >> >> Thank you, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > StackMapFrameInfo extracted to top level from StackMapTableAttribute src/java.base/share/classes/jdk/internal/classfile/components/snippet-files/PackageSnippets.java line 171: > 169: > 170: //store stacked method parameters into locals > 171: var storeStack = new LinkedList(); FWIW you can use an ArrayDeque + push + forEach, in the spirit of highlighting Deque over LinkedList for stack-based usage (since this is an example with visibility). ------------- PR: https://git.openjdk.org/jdk/pull/10982 From darcy at openjdk.org Thu Mar 2 19:55:39 2023 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 2 Mar 2023 19:55:39 GMT Subject: RFR: JDK-8302801: Remove fdlibm C sources [v3] In-Reply-To: References: Message-ID: <3ePedpVieHDjKofsLHTwEI2xiCfEZ047Ewb4hwxSjiQ=.368af0f3-935e-4be8-9bc7-dbda01decf5c@github.com> > While the review of https://github.com/openjdk/jdk/pull/12800 finishes up, I thought I'd get out for the review the next phase of the FDLIBM port: removing the FDLIBM C sources from the repo. > > A repo with the changes for JDK-8302027 and this PR successful build on the default set of platform and successfully run tier 1 tests, which includes tests of the math library. > > There are a few remaining references to the case-independent string "fdlibm" in the make directory and HotSpot sources. HotSpot contains a partial fork for FDLIBM (a tine of FDLIBM?) to use for intrinsics. The remaining make machinery contains logic to determine what set of gcc options can be used for the compile. > > The intention of this change is to remove use of FDLIBM for the core libraries. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Respond to review feedback. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12821/files - new: https://git.openjdk.org/jdk/pull/12821/files/481af9ad..417cb739 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12821&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12821&range=01-02 Stats: 5 lines in 1 file changed: 0 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/12821.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12821/head:pull/12821 PR: https://git.openjdk.org/jdk/pull/12821 From psandoz at openjdk.org Thu Mar 2 19:59:56 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 2 Mar 2023 19:59:56 GMT Subject: RFR: 8294982: Implementation of Classfile API [v36] In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 14:31:06 GMT, Adam Sotona wrote: >> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. >> >> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. >> >> Classfile API development is tracked at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch >> >> Development branch of consolidated JDK class files parsing, generating, and transforming is at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch >> >> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. >> >> Please take you time to review this non-trivial JDK addition. >> >> Thank you, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > StackMapFrameInfo extracted to top level from StackMapTableAttribute src/java.base/share/classes/jdk/internal/classfile/components/snippet-files/PackageSnippets.java line 149: > 147: var instrumentorCodeMap = instrumentor.methods().stream() > 148: .filter(instrumentedMethodsFilter) > 149: .collect(Collectors.toMap(mm -> mm.methodName().stringValue() + mm.methodType().stringValue(), mm -> mm.code().orElse(null))); Should we be filtering out abstract methods before the `collect` and/or replace with: mm -> mm.code().orElseThrow() ? ------------- PR: https://git.openjdk.org/jdk/pull/10982 From mchung at openjdk.org Thu Mar 2 20:03:25 2023 From: mchung at openjdk.org (Mandy Chung) Date: Thu, 2 Mar 2023 20:03:25 GMT Subject: RFR: 8302791: Add specific ClassLoader object to Proxy IllegalArgumentException message [v4] In-Reply-To: <2R2lxJGzA5rDl4k2PSsKI6fIZ-ob8HdbSrWtKfRyv9M=.9d24250a-3d90-497c-af37-f672b4398bc0@github.com> References: <0jQQEOJWyqjmAP3UgPGk7V1muce0Yx14nWIlBnkOgas=.095d14d8-ee3c-4089-bb62-6f7d1c0100d5@github.com> <2R2lxJGzA5rDl4k2PSsKI6fIZ-ob8HdbSrWtKfRyv9M=.9d24250a-3d90-497c-af37-f672b4398bc0@github.com> Message-ID: On Thu, 2 Mar 2023 14:18:13 GMT, Alan Bateman wrote: >> src/java.base/share/classes/java/lang/reflect/Proxy.java line 889: >> >>> 887: : Objects.toIdentityString(ld); >>> 888: throw new IllegalArgumentException(c.getName() + >>> 889: " referenced from a method is not visible from class loader: " + nid); >> >> Thanks for the update, this looks much better. A passing thought is that you might want to use "/" instead of "@" as the separator so that someone looking at the exception message will be able to distinguish a class name from a class loader name. Also you might want to re-format L886 to avoid the really long line as it's a bit inconsistent with the code in this source file. > >> Thanks @AlanBateman. Regarding the separator, Have seen this being used in ClassLoader.java for nameAndId method. Hence used the same for consistency. I've reformatted L886 now, Please kindly check. > > Thanks for checking, the updated version looks good. I suggest to add a `JavaLangAccess::getLoaderNameID(ClassLoader loader)` so that Proxy (and other classes) can use the same representation. The patch will look like this: diff --git a/src/java.base/share/classes/java/lang/ClassLoader.java b/src/java.base/share/classes/java/lang/ClassLoader.java index 2bc9a22700a..f412ecfa3ae 100644 --- a/src/java.base/share/classes/java/lang/ClassLoader.java +++ b/src/java.base/share/classes/java/lang/ClassLoader.java @@ -407,6 +407,10 @@ public abstract class ClassLoader { return nid; } + String nameAndId() { + return nameAndId; + } + /** * Creates a new class loader of the specified name and using the * specified parent class loader for delegation. diff --git a/src/java.base/share/classes/java/lang/System.java b/src/java.base/share/classes/java/lang/System.java index 501ed47fcad..c138ea9fef5 100644 --- a/src/java.base/share/classes/java/lang/System.java +++ b/src/java.base/share/classes/java/lang/System.java @@ -2663,6 +2663,10 @@ public final class System { Continuation continuation) { return StackWalker.newInstance(options, null, contScope, continuation); } + + public String getLoaderNameID(ClassLoader loader) { + return loader.nameAndId(); + } }); } } diff --git a/src/java.base/share/classes/java/lang/reflect/Proxy.java b/src/java.base/share/classes/java/lang/reflect/Proxy.java index 6064dcf5b6b..a2a9a03e6c4 100644 --- a/src/java.base/share/classes/java/lang/reflect/Proxy.java +++ b/src/java.base/share/classes/java/lang/reflect/Proxy.java @@ -878,7 +878,7 @@ public class Proxy implements java.io.Serializable { } if (type != c) { throw new IllegalArgumentException(c.getName() + - " referenced from a method is not visible from class loader"); + " referenced from a method is not visible from class loader: " + JLA.getLoaderNameID(ld)); } } diff --git a/src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java b/src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java index 39adfb2130a..4720e589efb 100644 --- a/src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java +++ b/src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java @@ -564,4 +564,6 @@ public interface JavaLangAccess { StackWalker newStackWalkerInstance(Set options, ContinuationScope contScope, Continuation continuation); + + String getLoaderNameID(ClassLoader loader); } ------------- PR: https://git.openjdk.org/jdk/pull/12641 From jlaskey at openjdk.org Thu Mar 2 20:05:05 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 2 Mar 2023 20:05:05 GMT Subject: RFR: JDK-8302323 Add repeat methods to StringBuilder/StringBuffer [v6] In-Reply-To: References: Message-ID: > Add the ability to repeatedly append char and CharSequence data to StringBuilder/StringBuffer. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Support code points ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12728/files - new: https://git.openjdk.org/jdk/pull/12728/files/34c7948c..02a4cc70 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12728&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12728&range=04-05 Stats: 72 lines in 4 files changed: 46 ins; 12 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/12728.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12728/head:pull/12728 PR: https://git.openjdk.org/jdk/pull/12728 From jlaskey at openjdk.org Thu Mar 2 20:05:08 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 2 Mar 2023 20:05:08 GMT Subject: RFR: JDK-8302323 Add repeat methods to StringBuilder/StringBuffer [v5] In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 18:39:36 GMT, Andrey Turbanov wrote: >> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision: >> >> - Move @since in subclasses >> - Move @since > > src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1911: > >> 1909: if (cs instanceof String str) { >> 1910: putStringAt(offset, str); >> 1911: } else if (cs instanceof AbstractStringBuilder asb) { > > Suggestion: > > } else if (cs instanceof AbstractStringBuilder asb) { Thanks ------------- PR: https://git.openjdk.org/jdk/pull/12728 From martin at openjdk.org Thu Mar 2 20:09:08 2023 From: martin at openjdk.org (Martin Buchholz) Date: Thu, 2 Mar 2023 20:09:08 GMT Subject: RFR: 8297605: DelayQueue javadoc is confusing Message-ID: Inviting @DougLea and @viktorklang-ora to review. As usual, I couldn't resist more fiddling. - Added missing tests for take, remove(), remove(Object). - Improved DelayQueueTest's testing infrastructure - added more test assertions - linkified new javadoc definitions ------------- Commit messages: - JDK-8297605 Changes: https://git.openjdk.org/jdk/pull/12838/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12838&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297605 Stats: 170 lines in 2 files changed: 114 ins; 9 del; 47 mod Patch: https://git.openjdk.org/jdk/pull/12838.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12838/head:pull/12838 PR: https://git.openjdk.org/jdk/pull/12838 From bpb at openjdk.org Thu Mar 2 20:09:09 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 2 Mar 2023 20:09:09 GMT Subject: RFR: JDK-8302801: Remove fdlibm C sources [v3] In-Reply-To: <3ePedpVieHDjKofsLHTwEI2xiCfEZ047Ewb4hwxSjiQ=.368af0f3-935e-4be8-9bc7-dbda01decf5c@github.com> References: <3ePedpVieHDjKofsLHTwEI2xiCfEZ047Ewb4hwxSjiQ=.368af0f3-935e-4be8-9bc7-dbda01decf5c@github.com> Message-ID: On Thu, 2 Mar 2023 19:55:39 GMT, Joe Darcy wrote: >> While the review of https://github.com/openjdk/jdk/pull/12800 finishes up, I thought I'd get out for the review the next phase of the FDLIBM port: removing the FDLIBM C sources from the repo. >> >> A repo with the changes for JDK-8302027 and this PR successful build on the default set of platform and successfully run tier 1 tests, which includes tests of the math library. >> >> There are a few remaining references to the case-independent string "fdlibm" in the make directory and HotSpot sources. HotSpot contains a partial fork for FDLIBM (a tine of FDLIBM?) to use for intrinsics. The remaining make machinery contains logic to determine what set of gcc options can be used for the compile. >> >> The intention of this change is to remove use of FDLIBM for the core libraries. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback. Looks fine to me. ------------- Marked as reviewed by bpb (Reviewer). PR: https://git.openjdk.org/jdk/pull/12821 From psandoz at openjdk.org Thu Mar 2 20:14:08 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 2 Mar 2023 20:14:08 GMT Subject: RFR: 8294982: Implementation of Classfile API [v36] In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 14:31:06 GMT, Adam Sotona wrote: >> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. >> >> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. >> >> Classfile API development is tracked at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch >> >> Development branch of consolidated JDK class files parsing, generating, and transforming is at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch >> >> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. >> >> Please take you time to review this non-trivial JDK addition. >> >> Thank you, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > StackMapFrameInfo extracted to top level from StackMapTableAttribute src/java.base/share/classes/jdk/internal/classfile/instruction/ConstantInstruction.java line 41: > 39: * Models a constant-load instruction in the {@code code} array of a {@code > 40: * Code} attribute, including "intrinsic constant" instructions (e.g., {@code > 41: * aload_0}), "argument constant" instructions (e.g., {@code bipush}), and "load Suggestion: * iconst_0}), "argument constant" instructions (e.g., {@code bipush}), and "load Otherwise we can refer to `aconst_null` src/java.base/share/classes/jdk/internal/classfile/instruction/ConstantInstruction.java line 60: > 58: /** > 59: * Models an "intrinsic constant" instruction (e.g., {@code > 60: * aload_0}). Suggestion: * iconst_0}). ------------- PR: https://git.openjdk.org/jdk/pull/10982 From jlaskey at openjdk.org Thu Mar 2 20:19:01 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 2 Mar 2023 20:19:01 GMT Subject: RFR: JDK-8302323 Add repeat methods to StringBuilder/StringBuffer [v7] In-Reply-To: References: Message-ID: <7MFQi5db0hcKy59xaMjJKUhrYD269uZUyFYoci8i7yc=.2751c5b5-021c-4fa3-a3ae-a6f770b37ee7@github.com> > Add the ability to repeatedly append char and CharSequence data to StringBuilder/StringBuffer. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Add snippet ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12728/files - new: https://git.openjdk.org/jdk/pull/12728/files/02a4cc70..7d3ecc77 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12728&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12728&range=05-06 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12728.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12728/head:pull/12728 PR: https://git.openjdk.org/jdk/pull/12728 From psandoz at openjdk.org Thu Mar 2 20:19:58 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 2 Mar 2023 20:19:58 GMT Subject: RFR: 8294982: Implementation of Classfile API [v15] In-Reply-To: References: Message-ID: On Wed, 15 Feb 2023 14:12:21 GMT, Adam Sotona wrote: >> src/java.base/share/classes/jdk/internal/classfile/instruction/ConstantInstruction.java line 63: >> >>> 61: * aload_0}). >>> 62: */ >>> 63: sealed interface IntrinsicConstantInstruction extends ConstantInstruction >> >> I'm not super sure of the fine-grained distinction here. The constant pool variant is interesting (as you can ask for the associated constant entry) - but the distinction between intrinsics vs. argument seems rather weak. > > They significantly differ in instruction formats and instruction format distinction is critical for some use cases. I think this distinction is appropriate for the level of modeling. CodeBuilder::constantInstruction(ConstantDesc value) is very useful in selecting the most appropriate specific constant instruction. ------------- PR: https://git.openjdk.org/jdk/pull/10982 From naoto at openjdk.org Thu Mar 2 20:24:06 2023 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 2 Mar 2023 20:24:06 GMT Subject: RFR: 8303275: Use {@Return and @linkplain in Locale and related classes [v2] In-Reply-To: References: <9XzLdPaTCaYpzrJStx2riu1ZTMIYEgZOkPIy_CgK5jk=.0ec33845-108e-4651-9e6e-6be6c7cc3ef4@github.com> Message-ID: On Thu, 2 Mar 2023 19:38:29 GMT, Justin Lu wrote: >> This PR modifies the javadoc of methods in Locale, LocaleServiceProvider, and LocaleServiceProviderPool to use {@return and @linkplain. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > Remove prefix Locale for in-class linkplains Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12780 From psandoz at openjdk.org Thu Mar 2 20:24:42 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 2 Mar 2023 20:24:42 GMT Subject: RFR: 8294982: Implementation of Classfile API [v36] In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 14:31:06 GMT, Adam Sotona wrote: >> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. >> >> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. >> >> Classfile API development is tracked at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch >> >> Development branch of consolidated JDK class files parsing, generating, and transforming is at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch >> >> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. >> >> Please take you time to review this non-trivial JDK addition. >> >> Thank you, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > StackMapFrameInfo extracted to top level from StackMapTableAttribute src/java.base/share/classes/jdk/internal/classfile/instruction/ExceptionCatch.java line 77: > 75: static ExceptionCatch of(Label handler, Label tryStart, Label tryEnd, > 76: Optional catchTypeEntry) { > 77: return new AbstractPseudoInstruction.ExceptionCatchImpl(handler, tryStart, tryEnd, catchTypeEntry); Suggestion: return new AbstractPseudoInstruction.ExceptionCatchImpl(handler, tryStart, tryEnd, catchTypeEntry.orElse(null)); Then you only need one constructor for `ExceptionCatchImpl` and you don't need to disambiguate a call using a cast for a final argument that is `null` . ------------- PR: https://git.openjdk.org/jdk/pull/10982 From jlu at openjdk.org Thu Mar 2 20:26:12 2023 From: jlu at openjdk.org (Justin Lu) Date: Thu, 2 Mar 2023 20:26:12 GMT Subject: Integrated: 8303405: fix @returnss typo in ReflectionFactory In-Reply-To: <-0G_v0gBCIwZzCJrCns71VpiwaLRpNvbpmRYVUm_k4U=.3f2f80b3-5c8d-4134-9c0a-79a94ce8678e@github.com> References: <-0G_v0gBCIwZzCJrCns71VpiwaLRpNvbpmRYVUm_k4U=.3f2f80b3-5c8d-4134-9c0a-79a94ce8678e@github.com> Message-ID: On Wed, 1 Mar 2023 00:24:31 GMT, Justin Lu wrote: > The following typo: `@returnss` was reported on line _482 of Reflection Factory.java_. > > In addition to fixing that, I have replaced multiple instances of `@returns` with `@return` in the same file. This pull request has now been integrated. Changeset: 45d8a175 Author: Justin Lu Committer: Naoto Sato URL: https://git.openjdk.org/jdk/commit/45d8a175b11bde953c8897c103d8c3cd6b26f9aa Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod 8303405: fix @returnss typo in ReflectionFactory Reviewed-by: jpai, mchung, martin, iris, lancea, naoto ------------- PR: https://git.openjdk.org/jdk/pull/12794 From psandoz at openjdk.org Thu Mar 2 20:40:52 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 2 Mar 2023 20:40:52 GMT Subject: RFR: 8294982: Implementation of Classfile API [v36] In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 14:31:06 GMT, Adam Sotona wrote: >> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. >> >> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. >> >> Classfile API development is tracked at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch >> >> Development branch of consolidated JDK class files parsing, generating, and transforming is at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch >> >> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. >> >> Please take you time to review this non-trivial JDK addition. >> >> Thank you, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > StackMapFrameInfo extracted to top level from StackMapTableAttribute src/java.base/share/classes/jdk/internal/classfile/instruction/NewMultiArrayInstruction.java line 60: > 58: static NewMultiArrayInstruction of(ClassEntry arrayTypeEntry, > 59: int dimensions) { > 60: return new AbstractInstruction.UnboundNewMultidimensionalArrayInstruction(arrayTypeEntry, dimensions); Should we validate that the dimensionality of `arrayType` is greater than or equal to `dimensions`? ------------- PR: https://git.openjdk.org/jdk/pull/10982 From psandoz at openjdk.org Thu Mar 2 20:57:44 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 2 Mar 2023 20:57:44 GMT Subject: RFR: 8294982: Implementation of Classfile API [v36] In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 14:31:06 GMT, Adam Sotona wrote: >> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. >> >> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. >> >> Classfile API development is tracked at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch >> >> Development branch of consolidated JDK class files parsing, generating, and transforming is at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch >> >> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. >> >> Please take you time to review this non-trivial JDK addition. >> >> Thank you, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > StackMapFrameInfo extracted to top level from StackMapTableAttribute src/java.base/share/classes/jdk/internal/classfile/instruction/LoadInstruction.java line 66: > 64: * @param slot the local varaible slot to load from > 65: */ > 66: static LoadInstruction of(Opcode op, int slot) { Should you validate that `slot` is compatible with `op`? (same for the StoreInstruction?) src/java.base/share/classes/jdk/internal/classfile/instruction/NewObjectInstruction.java line 38: > 36: * of a {@link CodeModel}. > 37: */ > 38: public sealed interface NewObjectInstruction extends Instruction Should we add a helper method on `CodeBuilder` that does the new + dup + invoke special dance? ------------- PR: https://git.openjdk.org/jdk/pull/10982 From rriggs at openjdk.org Thu Mar 2 21:05:10 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 2 Mar 2023 21:05:10 GMT Subject: RFR: 8302590: Add String.indexOf(int ch, int fromIndex, int toIndex) [v7] In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 10:24:03 GMT, Raffaello Giulietti wrote: >> Add an `indexOf()` variant allowing to specify both a lower and an upper bound on the search. > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > 8302590: Add String.indexOf(int ch, int fromIndex, int toIndex) Looks good ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.org/jdk/pull/12600 From prr at openjdk.org Thu Mar 2 21:29:04 2023 From: prr at openjdk.org (Phil Race) Date: Thu, 2 Mar 2023 21:29:04 GMT Subject: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 12:03:44 GMT, Pavel Rappo wrote: > Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API. > > The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows: > > > diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html > --- build/macosx-aarch64/images/docs-before/api/serialized-form.html 2023-03-02 11:47:44 > +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html 2023-03-02 11:48:45 > @@ -17084,7 +17084,7 @@ > throws IOException, > ClassNotFoundException >
readObject is called to restore the state of the > - (@code BasicPermission} from a stream.
> + BasicPermission from a stream. >
>
Parameters:
>
s - the ObjectInputStream from which data is read
> > Notes > ----- > > * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas. > * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary. > * I will update copyright years after (and if) the fix had been approved, as required. java.desktop changes are fine ------------- Marked as reviewed by prr (Reviewer). PR: https://git.openjdk.org/jdk/pull/12826 From bhuang at openjdk.org Thu Mar 2 21:42:07 2023 From: bhuang at openjdk.org (Bill Huang) Date: Thu, 2 Mar 2023 21:42:07 GMT Subject: RFR: JDK-8295859 Update Manual Test Groups Message-ID: The purpose of this task is to add the difference between -manual jdk_core and jdk_core_manual to the jdk_core_manual test goal. Furthermore, in order to streamline the manual test execution process, a new test group called jdk_core_manual_human has been created for manual tests that demand extra preparation or test input. ------------- Commit messages: - JDK-8295859 Update Manual Test Groups. Changes: https://git.openjdk.org/jdk/pull/12840/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12840&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8295859 Stats: 24 lines in 1 file changed: 16 ins; 3 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/12840.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12840/head:pull/12840 PR: https://git.openjdk.org/jdk/pull/12840 From dholmes at openjdk.org Thu Mar 2 22:07:29 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 2 Mar 2023 22:07:29 GMT Subject: RFR: 8301622: ProcessTools.java compilation gets ThreadDeath deprecation warning [v2] In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 17:43:54 GMT, Afshin Zafari wrote: >> ### Description >> The use of `ThreadDeath` is replaced with checking the exception be of type `Error` and the thread is `TERMINATED`. >> >> >> ### Test >> local and mach5 tier1 > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > 8301622: ProcessTools.java compilation gets ThreadDeath deprecation warning The check for ThreadDeath was to basically ignore the uncaught exception from Thread.stop(). Such an exception is no longer possible so the check can just be deleted. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/12827 From psandoz at openjdk.org Thu Mar 2 22:09:01 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 2 Mar 2023 22:09:01 GMT Subject: RFR: 8294982: Implementation of Classfile API [v36] In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 14:31:06 GMT, Adam Sotona wrote: >> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. >> >> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. >> >> Classfile API development is tracked at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch >> >> Development branch of consolidated JDK class files parsing, generating, and transforming is at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch >> >> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. >> >> Please take you time to review this non-trivial JDK addition. >> >> Thank you, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > StackMapFrameInfo extracted to top level from StackMapTableAttribute src/java.base/share/classes/jdk/internal/classfile/impl/AbstractInstruction.java line 156: > 154: @Override > 155: public String toString() { > 156: return String.format("Store[OP=%s, slot=%d]", this.opcode(), slot()); A suggestion. I believe the `toString` output for bound and unbound instructions should be identical and it can composed solely from methods on the public instruction interface. There are some differences e.g. `Increment` and `Inc` for the unbound and bound increment instruction respectively. If those assumptions are correct i recommend placing a static `toString` method on all unbound instructions that also have bound instructions, accepting the public instruction interface as an argument. Then the overridden `Object::toString` method defers to those. Thereby there is no duplication. (Alas we cannot override `toString` on the instruction interface itself). ------------- PR: https://git.openjdk.org/jdk/pull/10982 From duke at openjdk.org Thu Mar 2 22:12:07 2023 From: duke at openjdk.org (Afshin Zafari) Date: Thu, 2 Mar 2023 22:12:07 GMT Subject: RFR: 8301622: ProcessTools.java compilation gets ThreadDeath deprecation warning [v2] In-Reply-To: <471GonMmx1x-bXzHkzjWs3w3MNuOuf54zYzZXSpMUxk=.ae71e576-4796-412f-bd65-51f1ecf5b457@github.com> References: <6DJKnl1KHpUHIvIfdjn3KYAKJhvu9iLRhlz0CVL8DlA=.3324e840-6812-4020-b93b-9aea9d2442f1@github.com> <471GonMmx1x-bXzHkzjWs3w3MNuOuf54zYzZXSpMUxk=.ae71e576-4796-412f-bd65-51f1ecf5b457@github.com> Message-ID: On Thu, 2 Mar 2023 17:35:35 GMT, Alan Bateman wrote: >> I assumed the `ThreadDeath` was there to catch `Thread.stop()` calls and just ignore them. So, I wanted to keep this functionality. >> Can we remove using `ThreadDeath` relying on that `Thread.stop()` is also deprecated? > > I think it can be removed. Removed. ------------- PR: https://git.openjdk.org/jdk/pull/12827 From cjplummer at openjdk.org Thu Mar 2 22:18:08 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 2 Mar 2023 22:18:08 GMT Subject: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments In-Reply-To: References: Message-ID: <63UHTjtrUOVGBTwRt_M4QJ7aqBnuAGqekNTTTl3GM74=.ddedac04-ff87-40b9-9ea7-6b6d26d9d202@github.com> On Thu, 2 Mar 2023 12:03:44 GMT, Pavel Rappo wrote: > Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API. > > The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows: > > > diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html > --- build/macosx-aarch64/images/docs-before/api/serialized-form.html 2023-03-02 11:47:44 > +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html 2023-03-02 11:48:45 > @@ -17084,7 +17084,7 @@ > throws IOException, > ClassNotFoundException >
readObject is called to restore the state of the > - (@code BasicPermission} from a stream.
> + BasicPermission from a stream. >
>
Parameters:
>
s - the ObjectInputStream from which data is read
> > Notes > ----- > > * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas. > * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary. > * I will update copyright years after (and if) the fix had been approved, as required. The SA changes (jdk.hotspot.agent) look fine. ------------- Marked as reviewed by cjplummer (Reviewer). PR: https://git.openjdk.org/jdk/pull/12826 From darcy at openjdk.org Thu Mar 2 22:22:13 2023 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 2 Mar 2023 22:22:13 GMT Subject: RFR: 8294137: Review running times of java.math tests In-Reply-To: <-dxso8siPUKzTOOKkoA5_2EAn7ACb_XJSYdQ_Af-4_I=.2e9f8478-f224-491e-a299-c59f9f373ff2@github.com> References: <-dxso8siPUKzTOOKkoA5_2EAn7ACb_XJSYdQ_Af-4_I=.2e9f8478-f224-491e-a299-c59f9f373ff2@github.com> Message-ID: On Wed, 1 Mar 2023 23:36:04 GMT, Brian Burkhalter wrote: > Break up `BigIntegerTest` and `SymmetricRangeTests` into subsets which are run quasi-randomly as a function of second within the minute at the time the test is running. `LargeValueExceptions` does not appear amenable to this treatment. Hmmm. There are fairly standard idioms to get a random number generator from the test library and use it in the test. I'd prefer to see that approach taken here, with an update to use the jtreg "@randomness" tag in the appropriate place. ------------- PR: https://git.openjdk.org/jdk/pull/12819 From weijun at openjdk.org Thu Mar 2 22:32:07 2023 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 2 Mar 2023 22:32:07 GMT Subject: RFR: 8297955: LDAP CertStore should use LdapName and not String for DNs In-Reply-To: References: Message-ID: On Thu, 23 Feb 2023 16:42:17 GMT, Sean Mullan wrote: > The LDAPCertStore implementation passes Distinguished Names in CRL and Certificate URLs as Strings to JNDI APIs such as LdapContext.getAttributes(String), which then treats them as CompositeNames. This causes issues with URLs that have DNs with forward slashes. These are rare but compliant with the LDAP URL format for DNs referenced by [section 4.2.1.13 of RFC 5280](https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.13). Instead, the implementation should be passing the DN to JNDI APIs as an LdapName, which parses the forward slash character as part of the DN. Unfortunately, LDAP referral URLs can not be converted to LdapNames, so we keep the current DN syntax checks (and disallow forward slashes) if there are referrals involved. > > The current test/jdk/security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.java can be used to test this fix as it contains a test certificate with an LDAP URL in the CRL Distribution Points with a forward slash in the Distinguished Name. Prior to the fix it was failing because of this bug, now it is passing. We also take this opportunity to update the test and replace expired test certificates with new ones. Marked as reviewed by weijun (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12730 From bpb at openjdk.org Thu Mar 2 22:35:52 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 2 Mar 2023 22:35:52 GMT Subject: RFR: 8294137: Review running times of java.math tests [v2] In-Reply-To: <-dxso8siPUKzTOOKkoA5_2EAn7ACb_XJSYdQ_Af-4_I=.2e9f8478-f224-491e-a299-c59f9f373ff2@github.com> References: <-dxso8siPUKzTOOKkoA5_2EAn7ACb_XJSYdQ_Af-4_I=.2e9f8478-f224-491e-a299-c59f9f373ff2@github.com> Message-ID: > Break up `BigIntegerTest` and `SymmetricRangeTests` into subsets which are run quasi-randomly as a function of second within the minute at the time the test is running. `LargeValueExceptions` does not appear amenable to this treatment. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8303269: Use Random instead of Calendar to select test subset ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12819/files - new: https://git.openjdk.org/jdk/pull/12819/files/3128f03c..ca998b8e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12819&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12819&range=00-01 Stats: 10 lines in 2 files changed: 2 ins; 5 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/12819.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12819/head:pull/12819 PR: https://git.openjdk.org/jdk/pull/12819 From bpb at openjdk.org Thu Mar 2 22:37:06 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 2 Mar 2023 22:37:06 GMT Subject: RFR: 8294137: Review running times of java.math tests In-Reply-To: References: <-dxso8siPUKzTOOKkoA5_2EAn7ACb_XJSYdQ_Af-4_I=.2e9f8478-f224-491e-a299-c59f9f373ff2@github.com> Message-ID: On Thu, 2 Mar 2023 22:18:53 GMT, Joe Darcy wrote: > There are fairly standard idioms to get a random number generator from the test library and use it in the test. > > I'd prefer to see that approach taken here, with an update to use the jtreg "@randomness" tag in the appropriate place. So changed in ca998b8e7e5d293a9d2727cb2b074551e7a017a7. The `@randomness` tag was already there for other reasons. ------------- PR: https://git.openjdk.org/jdk/pull/12819 From joe.darcy at oracle.com Thu Mar 2 22:42:24 2023 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Thu, 2 Mar 2023 14:42:24 -0800 Subject: New class for handling infinite-precision rationals In-Reply-To: References: Message-ID: <57ceaa79-fec4-55a4-ed66-860ed1730225@oracle.com> Hello, I suggest a general discussion about whether or not such a class is appropriate for inclusion in the platform [1] ahead of review of a particular PR. Cheers, -Joe [1] https://openjdk.org/guide/#socialize-your-change On 2/21/2023 10:21 AM, Fabio Romano wrote: > The Rational class provides operations for arithmetic, rounding, > comparison, hashing, and format conversion. The toString method > provides a canonical representation of a Rational. All the > calculations performed have an exact result, except for the square and > nth roots, in which the user can specify the rounding behavior. > Link to pull request: https://github.com/openjdk/jdk/pull/11982 From rhalade at openjdk.org Thu Mar 2 22:50:13 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Thu, 2 Mar 2023 22:50:13 GMT Subject: RFR: 8297955: LDAP CertStore should use LdapName and not String for DNs In-Reply-To: References: Message-ID: On Thu, 23 Feb 2023 16:42:17 GMT, Sean Mullan wrote: > The LDAPCertStore implementation passes Distinguished Names in CRL and Certificate URLs as Strings to JNDI APIs such as LdapContext.getAttributes(String), which then treats them as CompositeNames. This causes issues with URLs that have DNs with forward slashes. These are rare but compliant with the LDAP URL format for DNs referenced by [section 4.2.1.13 of RFC 5280](https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.13). Instead, the implementation should be passing the DN to JNDI APIs as an LdapName, which parses the forward slash character as part of the DN. Unfortunately, LDAP referral URLs can not be converted to LdapNames, so we keep the current DN syntax checks (and disallow forward slashes) if there are referrals involved. > > The current test/jdk/security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.java can be used to test this fix as it contains a test certificate with an LDAP URL in the CRL Distribution Points with a forward slash in the Distinguished Name. Prior to the fix it was failing because of this bug, now it is passing. We also take this opportunity to update the test and replace expired test certificates with new ones. Marked as reviewed by rhalade (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12730 From psandoz at openjdk.org Thu Mar 2 22:50:50 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 2 Mar 2023 22:50:50 GMT Subject: RFR: 8294982: Implementation of Classfile API [v36] In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 14:31:06 GMT, Adam Sotona wrote: >> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. >> >> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. >> >> Classfile API development is tracked at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch >> >> Development branch of consolidated JDK class files parsing, generating, and transforming is at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch >> >> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. >> >> Please take you time to review this non-trivial JDK addition. >> >> Thank you, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > StackMapFrameInfo extracted to top level from StackMapTableAttribute src/java.base/share/classes/jdk/internal/classfile/CodeBuilder.java line 93: > 91: * directly; they are passed to handlers by methods such as {@link > 92: * MethodBuilder#withCode(Consumer)} or to code transforms. The elements of a > 93: * code can be specified abstractly (by passing a {@link CodeElement} to {@link Suggestion: * code can be specified abstractly, by passing a {@link CodeElement} to {@link ------------- PR: https://git.openjdk.org/jdk/pull/10982 From psandoz at openjdk.org Thu Mar 2 23:02:52 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 2 Mar 2023 23:02:52 GMT Subject: RFR: 8294982: Implementation of Classfile API [v36] In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 14:31:06 GMT, Adam Sotona wrote: >> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. >> >> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. >> >> Classfile API development is tracked at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch >> >> Development branch of consolidated JDK class files parsing, generating, and transforming is at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch >> >> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. >> >> Please take you time to review this non-trivial JDK addition. >> >> Thank you, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > StackMapFrameInfo extracted to top level from StackMapTableAttribute src/java.base/share/classes/jdk/internal/classfile/CodeBuilder.java line 164: > 162: * generate the code. > 163: * @return this builder > 164: */ Suggestion: /** * Apply a transform to the code built by a handler, directing results to this builder. * * @param transform the transform to apply to the code built by the handler * @param handler the handler that receives a {@linkplain CodeBuilder} to * build the code. * @return this builder */ ------------- PR: https://git.openjdk.org/jdk/pull/10982 From psandoz at openjdk.org Thu Mar 2 23:31:48 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 2 Mar 2023 23:31:48 GMT Subject: RFR: 8294982: Implementation of Classfile API [v36] In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 14:31:06 GMT, Adam Sotona wrote: >> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. >> >> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. >> >> Classfile API development is tracked at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch >> >> Development branch of consolidated JDK class files parsing, generating, and transforming is at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch >> >> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. >> >> Please take you time to review this non-trivial JDK addition. >> >> Thank you, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > StackMapFrameInfo extracted to top level from StackMapTableAttribute src/java.base/share/classes/jdk/internal/classfile/CodeBuilder.java line 165: > 163: * @return this builder > 164: */ > 165: default CodeBuilder transforming(CodeTransform transform, Consumer handler) { The functionality of this method, `transforming`, and `ClassfileBuilder::transform`, are in effect equivalent in their transforming: adding the results of transformed code to the builder. They differ in the source of code elements. The latter's behaviour can be implemented using the former, with a consumer that passes all elements of a code model to the builder e.g. `builder -> model.forEach(builder::with)`. The difference in naming initially confused me. To me this suggests the method names should be the same? (perhaps with the transformer being consistently the last argument?). ------------- PR: https://git.openjdk.org/jdk/pull/10982 From jlu at openjdk.org Thu Mar 2 23:49:00 2023 From: jlu at openjdk.org (Justin Lu) Date: Thu, 2 Mar 2023 23:49:00 GMT Subject: RFR: 6453901: (cal) clean up sun.util.calendar classes Message-ID: This PR includes cleanup changes to the sun.util.calendar package only. The changes include removing unused methods, imports, adjusting incorrect links, and using newer syntax patterns. Since there are no plans to promote any of these classes to java.calendar, these unused methods can be removed. Mach5: https://mach5.us.oracle.com/mdash/jobs/jclu-jdk2-20230228-2223-42671403 ------------- Commit messages: - Additional unused method: CalendarDate.addSeconds() - Merge branch 'master' into 6453901-CalCleanUp - Copyright years - Unused methods, imports, variables. Pattern instance, Java array dec Changes: https://git.openjdk.org/jdk/pull/12817/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12817&range=00 Issue: https://bugs.openjdk.org/browse/JDK-6453901 Stats: 211 lines in 10 files changed: 1 ins; 182 del; 28 mod Patch: https://git.openjdk.org/jdk/pull/12817.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12817/head:pull/12817 PR: https://git.openjdk.org/jdk/pull/12817 From psandoz at openjdk.org Thu Mar 2 23:52:46 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 2 Mar 2023 23:52:46 GMT Subject: RFR: 8294982: Implementation of Classfile API [v36] In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 14:31:06 GMT, Adam Sotona wrote: >> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. >> >> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. >> >> Classfile API development is tracked at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch >> >> Development branch of consolidated JDK class files parsing, generating, and transforming is at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch >> >> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. >> >> Please take you time to review this non-trivial JDK addition. >> >> Thank you, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > StackMapFrameInfo extracted to top level from StackMapTableAttribute src/java.base/share/classes/jdk/internal/classfile/CodeTransform.java line 91: > 89: @Override > 90: default ResolvedTransform resolve(CodeBuilder builder) { > 91: return new TransformImpl.CodeTransformImpl(e -> accept(builder, e), Make `CodeTransformImpl` generic in the class file element, rename to say `ResolvedTransformImpl` and reuse for the other `XxxTransform`? ------------- PR: https://git.openjdk.org/jdk/pull/10982 From dl at openjdk.org Fri Mar 3 00:03:16 2023 From: dl at openjdk.org (Doug Lea) Date: Fri, 3 Mar 2023 00:03:16 GMT Subject: RFR: 8297605: DelayQueue javadoc is confusing In-Reply-To: References: Message-ID: <7YhoiOJr-ppdmYShC9a1xHtInceAwjEpcQjWyUp9i8s=.82bd57e4-5a85-4a30-bb62-8720ff661f1b@github.com> On Thu, 2 Mar 2023 20:00:56 GMT, Martin Buchholz wrote: > Inviting @DougLea and @viktorklang-ora to review. > > As usual, I couldn't resist more fiddling. > - Added missing tests for take, remove(), remove(Object). > - Improved DelayQueueTest's testing infrastructure > - added more test assertions > - linkified new javadoc definitions Thanks. This is overkill, but the wording changes and new tests look OK. ------------- PR: https://git.openjdk.org/jdk/pull/12838 From dholmes at openjdk.org Fri Mar 3 00:34:22 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 3 Mar 2023 00:34:22 GMT Subject: RFR: JDK-8302801: Remove fdlibm C sources [v3] In-Reply-To: <3ePedpVieHDjKofsLHTwEI2xiCfEZ047Ewb4hwxSjiQ=.368af0f3-935e-4be8-9bc7-dbda01decf5c@github.com> References: <3ePedpVieHDjKofsLHTwEI2xiCfEZ047Ewb4hwxSjiQ=.368af0f3-935e-4be8-9bc7-dbda01decf5c@github.com> Message-ID: On Thu, 2 Mar 2023 19:55:39 GMT, Joe Darcy wrote: >> While the review of https://github.com/openjdk/jdk/pull/12800 finishes up, I thought I'd get out for the review the next phase of the FDLIBM port: removing the FDLIBM C sources from the repo. >> >> A repo with the changes for JDK-8302027 and this PR successful build on the default set of platform and successfully run tier 1 tests, which includes tests of the math library. >> >> There are a few remaining references to the case-independent string "fdlibm" in the make directory and HotSpot sources. HotSpot contains a partial fork for FDLIBM (a tine of FDLIBM?) to use for intrinsics. The remaining make machinery contains logic to determine what set of gcc options can be used for the compile. >> >> The intention of this change is to remove use of FDLIBM for the core libraries. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback. Hotspot changes are okay but I'm a bit confused about what the hotspot code will now be used for? ------------- PR: https://git.openjdk.org/jdk/pull/12821 From psandoz at openjdk.org Fri Mar 3 00:36:47 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Fri, 3 Mar 2023 00:36:47 GMT Subject: RFR: 8294982: Implementation of Classfile API [v36] In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 14:31:06 GMT, Adam Sotona wrote: >> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. >> >> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. >> >> Classfile API development is tracked at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch >> >> Development branch of consolidated JDK class files parsing, generating, and transforming is at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch >> >> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. >> >> Please take you time to review this non-trivial JDK addition. >> >> Thank you, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > StackMapFrameInfo extracted to top level from StackMapTableAttribute src/java.base/share/classes/jdk/internal/classfile/impl/TransformImpl.java line 63: > 61: private static final Runnable NOTHING = () -> { }; > 62: > 63: interface FakeClassTransform extends ClassTransform { Rename to `UnresolvedXxxTransform`? I think that is a better name, since it could appear in stack traces. ------------- PR: https://git.openjdk.org/jdk/pull/10982 From dholmes at openjdk.org Fri Mar 3 00:41:06 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 3 Mar 2023 00:41:06 GMT Subject: RFR: JDK-8302801: Remove fdlibm C sources [v3] In-Reply-To: <3ePedpVieHDjKofsLHTwEI2xiCfEZ047Ewb4hwxSjiQ=.368af0f3-935e-4be8-9bc7-dbda01decf5c@github.com> References: <3ePedpVieHDjKofsLHTwEI2xiCfEZ047Ewb4hwxSjiQ=.368af0f3-935e-4be8-9bc7-dbda01decf5c@github.com> Message-ID: On Thu, 2 Mar 2023 19:55:39 GMT, Joe Darcy wrote: >> While the review of https://github.com/openjdk/jdk/pull/12800 finishes up, I thought I'd get out for the review the next phase of the FDLIBM port: removing the FDLIBM C sources from the repo. >> >> A repo with the changes for JDK-8302027 and this PR successful build on the default set of platform and successfully run tier 1 tests, which includes tests of the math library. >> >> There are a few remaining references to the case-independent string "fdlibm" in the make directory and HotSpot sources. HotSpot contains a partial fork for FDLIBM (a tine of FDLIBM?) to use for intrinsics. The remaining make machinery contains logic to determine what set of gcc options can be used for the compile. >> >> The intention of this change is to remove use of FDLIBM for the core libraries. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback. Actually this is really my lack of understanding about the current code: why do we intrinsify `Math` but not `StrictMath`? ------------- PR: https://git.openjdk.org/jdk/pull/12821 From psandoz at openjdk.org Fri Mar 3 01:00:42 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Fri, 3 Mar 2023 01:00:42 GMT Subject: RFR: 8294982: Implementation of Classfile API [v36] In-Reply-To: References: Message-ID: <9OJf7oMSoRjxxBMyevUqjKvG8kynN4dqVg-aO4UXoKI=.a4156836-2c7f-4758-9477-b8144eed231a@github.com> On Thu, 2 Mar 2023 14:31:06 GMT, Adam Sotona wrote: >> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. >> >> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. >> >> Classfile API development is tracked at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch >> >> Development branch of consolidated JDK class files parsing, generating, and transforming is at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch >> >> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. >> >> Please take you time to review this non-trivial JDK addition. >> >> Thank you, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > StackMapFrameInfo extracted to top level from StackMapTableAttribute src/java.base/share/classes/jdk/internal/classfile/impl/AbstractDirectBuilder.java line 34: > 32: * AbstractDirectBuilder > 33: */ > 34: public class AbstractDirectBuilder { Type variable `B` is unused. ------------- PR: https://git.openjdk.org/jdk/pull/10982 From kvn at openjdk.org Fri Mar 3 01:05:12 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 3 Mar 2023 01:05:12 GMT Subject: RFR: JDK-8302801: Remove fdlibm C sources [v3] In-Reply-To: References: <3ePedpVieHDjKofsLHTwEI2xiCfEZ047Ewb4hwxSjiQ=.368af0f3-935e-4be8-9bc7-dbda01decf5c@github.com> Message-ID: On Fri, 3 Mar 2023 00:31:12 GMT, David Holmes wrote: > Hotspot changes are okay but I'm a bit confused about what the hotspot code will now be used for? `SharedRuntime::*` runtime math functions are used on platforms where there are no HW instructions or intrinsics (Zero VM). JIT compiled code may also call them in such case (or when intrinsics disabled with flag): https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/library_call.cpp#L1815 Consider them as default intrinsics for all platforms (since they are written in C). They are faster than interpreting bytecode. They are also needed for results consistency - the same code is used by Interpreter and JITed code. ------------- PR: https://git.openjdk.org/jdk/pull/12821 From psandoz at openjdk.org Fri Mar 3 01:11:48 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Fri, 3 Mar 2023 01:11:48 GMT Subject: RFR: 8294982: Implementation of Classfile API [v36] In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 14:31:06 GMT, Adam Sotona wrote: >> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. >> >> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. >> >> Classfile API development is tracked at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch >> >> Development branch of consolidated JDK class files parsing, generating, and transforming is at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch >> >> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. >> >> Please take you time to review this non-trivial JDK addition. >> >> Thank you, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > StackMapFrameInfo extracted to top level from StackMapTableAttribute src/java.base/share/classes/jdk/internal/classfile/impl/NonterminalCodeBuilder.java line 46: > 44: this.terminal = switch (parent) { > 45: case ChainedCodeBuilder cb -> cb.terminal; > 46: case BlockCodeBuilderImpl cb -> cb.terminal; Suggestion: case NonterminalCodeBuilder cb -> cb.terminal; ? ------------- PR: https://git.openjdk.org/jdk/pull/10982 From psandoz at openjdk.org Fri Mar 3 01:35:59 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Fri, 3 Mar 2023 01:35:59 GMT Subject: RFR: 8294982: Implementation of Classfile API [v36] In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 14:31:06 GMT, Adam Sotona wrote: >> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. >> >> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. >> >> Classfile API development is tracked at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch >> >> Development branch of consolidated JDK class files parsing, generating, and transforming is at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch >> >> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. >> >> Please take you time to review this non-trivial JDK addition. >> >> Thank you, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > StackMapFrameInfo extracted to top level from StackMapTableAttribute src/java.base/share/classes/jdk/internal/classfile/TypeKind.java line 45: > 43: DoubleType("double", "D", 7), > 44: /** a reference type */ > 45: ReferenceType("reference type", "A", -1), Suggestion: ReferenceType("reference type", "L", -1), ? Otherwise `TypeKind.fromDescriptor(TypeKind.ReferenceType.descriptor())` will fail. ------------- PR: https://git.openjdk.org/jdk/pull/10982 From yyang at openjdk.org Fri Mar 3 02:04:21 2023 From: yyang at openjdk.org (Yi Yang) Date: Fri, 3 Mar 2023 02:04:21 GMT Subject: RFR: 8143900: OptimizeStringConcat has an opaque dependency on Integer.sizeTable field [v2] In-Reply-To: References: Message-ID: On Mon, 27 Feb 2023 18:45:44 GMT, Vladimir Kozlov wrote: >>> Testing results seem good. Except one strange failure I put in [JDK-8143900](https://bugs.openjdk.org/browse/JDK-8143900) comment. You need second review. >> >> This seems related to https://bugs.openjdk.org/browse/JDK-8296914 > >> > Testing results seem good. Except one strange failure I put in [JDK-8143900](https://bugs.openjdk.org/browse/JDK-8143900) comment. You need second review. >> >> This seems related to https://bugs.openjdk.org/browse/JDK-8296914 > > [JDK-8296914 ](https://bugs.openjdk.org/browse/JDK-8296914)was closed as duplicate of still opened [JDK-8270202](https://bugs.openjdk.org/browse/JDK-8270202) Thanks @vnkozlov @TobiHartmann for reviews. ------------- PR: https://git.openjdk.org/jdk/pull/12680 From yyang at openjdk.org Fri Mar 3 02:04:23 2023 From: yyang at openjdk.org (Yi Yang) Date: Fri, 3 Mar 2023 02:04:23 GMT Subject: Integrated: 8143900: OptimizeStringConcat has an opaque dependency on Integer.sizeTable field In-Reply-To: References: Message-ID: On Tue, 21 Feb 2023 02:29:44 GMT, Yi Yang wrote: > Hi, can I have a review for this patch? I noticed a strange field Integer.sizeTable which is used by PhaseStringOpts, after digging into the history, I think it could be replaced by an in-place array allocation and initialization. Before it, we are fetching from Integer.sizeTable and get num of digit in integer by iterating size table, now we fetch from in-place sizeTable and get size from that. The changed IR looks like this: > > ![image](https://user-images.githubusercontent.com/5010047/220239446-7b8b8381-b300-4f2c-a24a-aa19ec9e2f88.png) > > Thanks. This pull request has now been integrated. Changeset: c961a918 Author: Yi Yang URL: https://git.openjdk.org/jdk/commit/c961a918ad41a78ec15389837abf29c98d66792f Stats: 192 lines in 3 files changed: 49 ins; 106 del; 37 mod 8143900: OptimizeStringConcat has an opaque dependency on Integer.sizeTable field Reviewed-by: kvn, thartmann ------------- PR: https://git.openjdk.org/jdk/pull/12680 From darcy at openjdk.org Fri Mar 3 02:06:06 2023 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 3 Mar 2023 02:06:06 GMT Subject: RFR: JDK-8302801: Remove fdlibm C sources [v3] In-Reply-To: References: <3ePedpVieHDjKofsLHTwEI2xiCfEZ047Ewb4hwxSjiQ=.368af0f3-935e-4be8-9bc7-dbda01decf5c@github.com> Message-ID: On Fri, 3 Mar 2023 00:38:18 GMT, David Holmes wrote: > Actually this is really my lack of understanding about the current code: why do we intrinsify `Math` but not `StrictMath`? In brief, the Math methods are allowed implementation flexibility in terms of their algorithm but the StrictMath methods are not. The "interesting" StrictMath methods are required to use the FDLIBM algorithms. (One exception is StrictMath.sqrt. Since sqrt is required to be correctly rounded, there is only one correct answer for any given argument and StrictMath.sqrt can be intrinsified to a hardware sqrt instruction just like Math.sqrt can.) ------------- PR: https://git.openjdk.org/jdk/pull/12821 From darcy at openjdk.org Fri Mar 3 02:10:15 2023 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 3 Mar 2023 02:10:15 GMT Subject: RFR: JDK-8302801: Remove fdlibm C sources [v3] In-Reply-To: References: <3ePedpVieHDjKofsLHTwEI2xiCfEZ047Ewb4hwxSjiQ=.368af0f3-935e-4be8-9bc7-dbda01decf5c@github.com> Message-ID: On Fri, 3 Mar 2023 01:02:40 GMT, Vladimir Kozlov wrote: > Hotspot changes are okay but I'm a bit confused about what the hotspot code will now be used for? I'm not 100% positive if the current __kernel_rem_pio2 code would be in use. IIRC, back when we used the fsin/fcos instructions to intrinsify sin/cos on the x87 FPU, to meet Java semantics we needed to do argument reduction into the range supported by fsin/fcos. Perhaps __kernel_rem_pio2 is a hold-over from that time? I believe my recent sin/cos algorithms for instrincs wouldn't need to use these pathways. ------------- PR: https://git.openjdk.org/jdk/pull/12821 From jvernee at openjdk.org Fri Mar 3 02:34:07 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 3 Mar 2023 02:34:07 GMT Subject: RFR: 8303516: HFAs with nested structs/unions/arrays not handled correctly on AArch64 Message-ID: Port of: https://github.com/openjdk/panama-foreign/pull/780 Which adds tests for nested structs/unions/arrays, and fixes an issue with nested HFAs on AArch64. This PR also includes https://github.com/openjdk/panama-foreign/pull/765 which is required for the fix to apply cleanly. Moving these change sets into the mainline now seems useful for the currently ongoing porting effort on PPC, as well as taking a load off of the JEP PR review which will come later. ------------- Commit messages: - disable test on x86 - update copyright years - 8300294: Add tests for by-value unions and structs with nested fixed-length arrays - 8299911: Refactor struct handling in AArch64 CallArranger Changes: https://git.openjdk.org/jdk/pull/12831/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12831&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303516 Stats: 1046 lines in 8 files changed: 786 ins; 174 del; 86 mod Patch: https://git.openjdk.org/jdk/pull/12831.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12831/head:pull/12831 PR: https://git.openjdk.org/jdk/pull/12831 From jvernee at openjdk.org Fri Mar 3 02:34:07 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 3 Mar 2023 02:34:07 GMT Subject: RFR: 8303516: HFAs with nested structs/unions/arrays not handled correctly on AArch64 In-Reply-To: References: Message-ID: <-XSminklDStlDqrddNR0C-iuqdPujOPnuUrJ9ZBbko4=.3399fae7-ac86-4183-adf1-b1741e055c86@github.com> On Thu, 2 Mar 2023 13:48:26 GMT, Jorn Vernee wrote: > Port of: https://github.com/openjdk/panama-foreign/pull/780 Which adds tests for nested structs/unions/arrays, and fixes an issue with nested HFAs on AArch64. > > This PR also includes https://github.com/openjdk/panama-foreign/pull/765 which is required for the fix to apply cleanly. > > Moving these change sets into the mainline now seems useful for the currently ongoing porting effort on PPC, as well as taking a load off of the JEP PR review which will come later. I've also disabled the TestMacOsAArch64CallArranger test on x86, which was failing (this slipped through the review of the windows/aarch64 port) ------------- PR: https://git.openjdk.org/jdk/pull/12831 From rriggs at openjdk.org Fri Mar 3 02:35:14 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 3 Mar 2023 02:35:14 GMT Subject: RFR: 8303198: System and Runtime.exit() resilience to logging errors [v2] In-Reply-To: References: Message-ID: <2KB9hkJ9ldV40taY1rIJ5vXLd4m2kAxbd36QSNfAPH8=.ff43275a-4cde-49a7-9b17-6e587fe00f55@github.com> On Wed, 1 Mar 2023 16:59:51 GMT, Roger Riggs wrote: >> Consolidate logging and handle exceptions by printing to standard error and ignoring the exception. >> Exceptions while logging will not interfere with Runtime.exit. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Add exit status to output when the logging fails with an exception. Are there any more comments? ------------- PR: https://git.openjdk.org/jdk/pull/12770 From cjplummer at openjdk.org Fri Mar 3 02:52:13 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 3 Mar 2023 02:52:13 GMT Subject: RFR: 8303198: System and Runtime.exit() resilience to logging errors [v2] In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 16:59:51 GMT, Roger Riggs wrote: >> Consolidate logging and handle exceptions by printing to standard error and ignoring the exception. >> Exceptions while logging will not interfere with Runtime.exit. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Add exit status to output when the logging fails with an exception. Are you going to remove VMOutOfMemoryException001.java from the problem list? ------------- PR: https://git.openjdk.org/jdk/pull/12770 From rriggs at openjdk.org Fri Mar 3 02:55:11 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 3 Mar 2023 02:55:11 GMT Subject: RFR: 8303198: System and Runtime.exit() resilience to logging errors [v2] In-Reply-To: References: Message-ID: On Fri, 3 Mar 2023 02:49:01 GMT, Chris Plummer wrote: > Are you going to remove VMOutOfMemoryException001.java from the problem list? I'll do that a separate PR to avoid mixing the issues and solutions. This change is not only to address JDK-8303057. ------------- PR: https://git.openjdk.org/jdk/pull/12770 From mdoerr at openjdk.org Fri Mar 3 04:04:06 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Fri, 3 Mar 2023 04:04:06 GMT Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function & Memory API (Preview) [v7] In-Reply-To: References: Message-ID: > Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification". > > This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `` (2.2.4 Variable Argument Lists). > > Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only. > > There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Will get addressed separately: [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017) > > The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests. > > I had to make changes to shared code and code for other platforms: > 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons: > - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that. > - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64. > - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian! > 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit. Martin Doerr has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Merge branch 'master' into PPC64_Panama - Add test for HFA corner cases. - Minor cleanup. - HFA: Add support for nested structures. See JDK-8300294. - Remove size restriction for structs. Add TODO for Big Endian. - Clean fix for NativeMemorySegmentImpl issue with byteSize 0. - Initial Panama implementation. ------------- Changes: https://git.openjdk.org/jdk/pull/12708/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=06 Stats: 2247 lines in 59 files changed: 2139 ins; 1 del; 107 mod Patch: https://git.openjdk.org/jdk/pull/12708.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12708/head:pull/12708 PR: https://git.openjdk.org/jdk/pull/12708 From dholmes at openjdk.org Fri Mar 3 04:16:15 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 3 Mar 2023 04:16:15 GMT Subject: RFR: 8303198: System and Runtime.exit() resilience to logging errors [v2] In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 16:59:51 GMT, Roger Riggs wrote: >> Consolidate logging and handle exceptions by printing to standard error and ignoring the exception. >> Exceptions while logging will not interfere with Runtime.exit. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Add exit status to output when the logging fails with an exception. I still have my doubts about the actual logging strategy and the usefulness of doing it outside the lock, but won't press it. The main thing is that `logRuntimeExit` can not throw an exception. Thanks. If this gets integrated then JDK-8303057 should be closed as a duplicate, at which point the entry in the ProblemList gets orphaned. If JDK-8303057 is to be closed as a duplicate of this issue, then this issue should update the ProblemList. Otherwise you need a new issue just to do the PL update (it would make no sense for JDK-8303057 to be hijacked for that). ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/12770 From mdoerr at openjdk.org Fri Mar 3 04:43:40 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Fri, 3 Mar 2023 04:43:40 GMT Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function & Memory API (Preview) [v8] In-Reply-To: References: Message-ID: > Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification". > > This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `` (2.2.4 Variable Argument Lists). > > Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only. > > There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Will get addressed separately: [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017) > > The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests. > > I had to make changes to shared code and code for other platforms: > 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons: > - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that. > - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64. > - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian! > 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit. Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: Fix merge bug. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12708/files - new: https://git.openjdk.org/jdk/pull/12708/files/d71f0f0a..f23edd8e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=06-07 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12708.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12708/head:pull/12708 PR: https://git.openjdk.org/jdk/pull/12708 From darcy at openjdk.org Fri Mar 3 06:17:07 2023 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 3 Mar 2023 06:17:07 GMT Subject: RFR: JDK-8302027: Port fdlibm trig functions (sin, cos, tan) to Java [v2] In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 15:28:24 GMT, Raffaello Giulietti wrote: >> Joe Darcy has updated the pull request incrementally with 10 additional commits since the last revision: >> >> - Update src/java.base/share/classes/java/lang/FdLibm.java >> >> Co-authored-by: Andrey Turbanov >> - Update src/java.base/share/classes/java/lang/FdLibm.java >> >> Co-authored-by: Andrey Turbanov >> - Update src/java.base/share/classes/java/lang/FdLibm.java >> >> Co-authored-by: Andrey Turbanov >> - Update src/java.base/share/classes/java/lang/FdLibm.java >> >> Co-authored-by: Andrey Turbanov >> - Update src/java.base/share/classes/java/lang/FdLibm.java >> >> Co-authored-by: Andrey Turbanov >> - Update src/java.base/share/classes/java/lang/FdLibm.java >> >> Co-authored-by: Andrey Turbanov >> - Update src/java.base/share/classes/java/lang/FdLibm.java >> >> Co-authored-by: Andrey Turbanov >> - Update src/java.base/share/classes/java/lang/FdLibm.java >> >> Co-authored-by: Andrey Turbanov >> - Update src/java.base/share/classes/java/lang/FdLibm.java >> >> Co-authored-by: Andrey Turbanov >> - Update src/java.base/share/classes/java/lang/FdLibm.java >> >> Co-authored-by: Andrey Turbanov > > test/jdk/java/lang/StrictMath/FdlibmTranslit.java line 839: > >> 837: twon24 = 5.96046447753906250000e-08; /* 0x3E700000, 0x00000000 */ >> 838: >> 839: static int __kernel_rem_pio2(double[] x, double[] y, int e0, int nx, int prec, final int[] ipio2) { > > `final int[]` in Java has a different semantics than `const int*` in C. The latter denotes a pointer to constant `int`s. > I don't think that the `final` keywords conveys any benefit here. Hmm. I don't think having "final" on the parameter is harmful, but I see the case for it not being that useful either. At least in the JDK source, we typically don't make an effort to final-ize parameters when possible. ------------- PR: https://git.openjdk.org/jdk/pull/12800 From darcy at openjdk.org Fri Mar 3 06:35:41 2023 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 3 Mar 2023 06:35:41 GMT Subject: RFR: JDK-8302027: Port fdlibm trig functions (sin, cos, tan) to Java [v3] In-Reply-To: References: Message-ID: > Last and certainly not least in the port of FDLIBM to Java, the transcendental methods for sin, cos, and tan. > > Some more tests are to be written in the StrictMath directory to verify that the StrictMath algorihtm for sin/cos/tan is being used rather than a different one. However, I wanted to get the rest of the change out for review first. > > The sin/cos/tan methods are grouped together since they share the same argument reduction logic. Argument reduction is the process of mapping an argument of a function to an argument in a restricted range (and possibly returning some function of the reduced argument). For sin, cos, and tan, since they are fundamentally periodic with respect to a multiple of pi, argument reduction is done to find the remainder of the original argument with respect to pi/2. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Add note explaining goto translation. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12800/files - new: https://git.openjdk.org/jdk/pull/12800/files/321a66cd..20d2f2f8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12800&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12800&range=01-02 Stats: 11 lines in 1 file changed: 11 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12800.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12800/head:pull/12800 PR: https://git.openjdk.org/jdk/pull/12800 From darcy at openjdk.org Fri Mar 3 06:35:42 2023 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 3 Mar 2023 06:35:42 GMT Subject: RFR: JDK-8302027: Port fdlibm trig functions (sin, cos, tan) to Java [v3] In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 15:42:08 GMT, Raffaello Giulietti wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> Add note explaining goto translation. > > test/jdk/java/lang/StrictMath/FdlibmTranslit.java line 867: > >> 865: >> 866: jz = jk; >> 867: while(true) { > > Would it be worthwhile to add some remarks about how the C `goto` + label has been "translitted"? > Or even add the `recompute:` label explicitly and adapt the `continue` and `break` statements inside the `while`? Note added. I think there is a stronger case for adding the note to the transliteration port than to the mainline one. I'm open to restructuring the looping construct for the mainline port. ------------- PR: https://git.openjdk.org/jdk/pull/12800 From darcy at openjdk.org Fri Mar 3 06:56:57 2023 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 3 Mar 2023 06:56:57 GMT Subject: RFR: JDK-8302027: Port fdlibm trig functions (sin, cos, tan) to Java [v4] In-Reply-To: References: Message-ID: > Last and certainly not least in the port of FDLIBM to Java, the transcendental methods for sin, cos, and tan. > > Some more tests are to be written in the StrictMath directory to verify that the StrictMath algorihtm for sin/cos/tan is being used rather than a different one. However, I wanted to get the rest of the change out for review first. > > The sin/cos/tan methods are grouped together since they share the same argument reduction logic. Argument reduction is the process of mapping an argument of a function to an argument in a restricted range (and possibly returning some function of the reduced argument). For sin, cos, and tan, since they are fundamentally periodic with respect to a multiple of pi, argument reduction is done to find the remainder of the original argument with respect to pi/2. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Add more tests. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12800/files - new: https://git.openjdk.org/jdk/pull/12800/files/20d2f2f8..b0cff650 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12800&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12800&range=02-03 Stats: 231 lines in 1 file changed: 231 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12800.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12800/head:pull/12800 PR: https://git.openjdk.org/jdk/pull/12800 From darcy at openjdk.org Fri Mar 3 06:58:11 2023 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 3 Mar 2023 06:58:11 GMT Subject: RFR: JDK-8302027: Port fdlibm trig functions (sin, cos, tan) to Java [v3] In-Reply-To: References: Message-ID: On Fri, 3 Mar 2023 06:35:41 GMT, Joe Darcy wrote: >> Last and certainly not least in the port of FDLIBM to Java, the transcendental methods for sin, cos, and tan. >> >> Some more tests are to be written in the StrictMath directory to verify that the StrictMath algorihtm for sin/cos/tan is being used rather than a different one. However, I wanted to get the rest of the change out for review first. >> >> The sin/cos/tan methods are grouped together since they share the same argument reduction logic. Argument reduction is the process of mapping an argument of a function to an argument in a restricted range (and possibly returning some function of the reduced argument). For sin, cos, and tan, since they are fundamentally periodic with respect to a multiple of pi, argument reduction is done to find the remainder of the original argument with respect to pi/2. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Add note explaining goto translation. I added a StrictMath test to probe at FDLIBM decision points. Either before this change goes back or as follow-up work in a separate bug I can add some tests to probe where other particular sin/cos/tan implementations return different results than FDLIBM. ------------- PR: https://git.openjdk.org/jdk/pull/12800 From alanb at openjdk.org Fri Mar 3 07:04:05 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 3 Mar 2023 07:04:05 GMT Subject: RFR: 8301622: ProcessTools.java compilation gets ThreadDeath deprecation warning [v2] In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 17:43:54 GMT, Afshin Zafari wrote: >> ### Description >> The use of `ThreadDeath` is replaced with checking the exception be of type `Error` and the thread is `TERMINATED`. >> >> >> ### Test >> local and mach5 tier1 > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > 8301622: ProcessTools.java compilation gets ThreadDeath deprecation warning Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12827 From duke at openjdk.org Fri Mar 3 08:21:59 2023 From: duke at openjdk.org (Amit Kumar) Date: Fri, 3 Mar 2023 08:21:59 GMT Subject: RFR: 8303499: [s390x] ProblemList StressStackOverflow Message-ID: This PR adds StressStackOverflow.java test to ProblemList. The feature Scope Value is not yet implemented on s390x-arch which is Incubating state. Whenever fix will be given to [JDK-8303498](https://bugs.openjdk.org/browse/JDK-8303498) then we will remove it. ------------- Commit messages: - adds StressStackOverflow test to ProblemList Changes: https://git.openjdk.org/jdk/pull/12834/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12834&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303499 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12834.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12834/head:pull/12834 PR: https://git.openjdk.org/jdk/pull/12834 From alanb at openjdk.org Fri Mar 3 08:22:00 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 3 Mar 2023 08:22:00 GMT Subject: RFR: 8303499: [s390x] ProblemList StressStackOverflow In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 16:22:24 GMT, Amit Kumar wrote: > This PR adds StressStackOverflow.java test to ProblemList. The feature Scope Value is not yet implemented on s390x-arch which is Incubating state. Whenever fix will be given to [JDK-8303498](https://bugs.openjdk.org/browse/JDK-8303498) then we will remove it. Marked as reviewed by alanb (Reviewer). If scoped values aren't implemented on s390x then I would expect several other tests to fail, e.g. ScopeValueAPI.java, ManyBindings.java, StructuredTaskScope/WithScopedValue.java, ThreadFlock/WithScopedValue.java. So I suspect something else is going on here. Maybe it's stack overflow handling? ------------- PR: https://git.openjdk.org/jdk/pull/12834 From duke at openjdk.org Fri Mar 3 08:22:02 2023 From: duke at openjdk.org (Amit Kumar) Date: Fri, 3 Mar 2023 08:22:02 GMT Subject: RFR: 8303499: [s390x] ProblemList StressStackOverflow In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 16:22:24 GMT, Amit Kumar wrote: > This PR adds StressStackOverflow.java test to ProblemList. The feature Scope Value is not yet implemented on s390x-arch which is Incubating state. Whenever fix will be given to [JDK-8303498](https://bugs.openjdk.org/browse/JDK-8303498) then we will remove it. Alan I'm attaching JTR file could you confirm the same probably provide more insights, as test you mentioned `ScopeValueAPI.java` and `ManyBindings.java` are passing. [StressStackOverflow.log](https://github.com/openjdk/jdk/files/10878364/StressStackOverflow.log) These are trivial changes. So I guess 1 Reviewer should be enough. ------------- PR: https://git.openjdk.org/jdk/pull/12834 From alanb at openjdk.org Fri Mar 3 08:22:03 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 3 Mar 2023 08:22:03 GMT Subject: RFR: 8303499: [s390x] ProblemList StressStackOverflow In-Reply-To: References: Message-ID: <4mQ5x8rFj1nmLLoFq7gv4biblMCCGSyTtZubveyzfp8=.d0fdc3a4-5477-4e5c-aa65-f50fcc71141a@github.com> On Fri, 3 Mar 2023 05:23:00 GMT, Amit Kumar wrote: > Alan I'm attaching JTR file could you confirm the same probably provide more insights, as test you mentioned `ScopeValueAPI.java` and `ManyBindings.java` are passing. > [StressStackOverflow.log](https://github.com/openjdk/jdk/files/10878364/StressStackOverflow.log) @theRealAph may wish to comment on this issue. If ScopeValueAPI.java and ManyBindings.java are passing then it suggests that ScopeValue API is at least functional. The JEP 429 implementation did have a small change to C2 (look at `git show 221e1a426070088b819ddc37b7ca77d9d8626eb4 src/hotspot/cpu`) and maybe the equivalent changes for s390x have not done been done yet. Excluding the test via the ProblemList until the s390x work is done seem reasonable. ------------- PR: https://git.openjdk.org/jdk/pull/12834 From aivanov at openjdk.org Fri Mar 3 08:28:19 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 3 Mar 2023 08:28:19 GMT Subject: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 12:03:44 GMT, Pavel Rappo wrote: > Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API. > > The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows: > > > diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html > --- build/macosx-aarch64/images/docs-before/api/serialized-form.html 2023-03-02 11:47:44 > +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html 2023-03-02 11:48:45 > @@ -17084,7 +17084,7 @@ > throws IOException, > ClassNotFoundException >
readObject is called to restore the state of the > - (@code BasicPermission} from a stream.
> + BasicPermission from a stream. >
>
Parameters:
>
s - the ObjectInputStream from which data is read
> > Notes > ----- > > * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas. > * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary. > * I will update copyright years after (and if) the fix had been approved, as required. Looks good to me. I looked through all the changes, paying more attention to the client area. src/java.base/share/classes/java/lang/invoke/BootstrapMethodInvoker.java line 257: > 255: > 256: /** > 257: * @return true iff the BSM method type exactly matches I assume ?iff? should ?if?? src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 2866: > 2864: * Merge multiple abstract methods. The preferred method is a method that is a subsignature > 2865: * of all the other signatures and whose return type is more specific {@link MostSpecificReturnCheck}. > 2866: * The resulting preferred method has a thrown clause that is the intersection of the merged Is it ??has a {@code throws} clause??? ------------- Marked as reviewed by aivanov (Reviewer). PR: https://git.openjdk.org/jdk/pull/12826 From asotona at openjdk.org Fri Mar 3 08:34:36 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 3 Mar 2023 08:34:36 GMT Subject: RFR: 8294982: Implementation of Classfile API [v37] In-Reply-To: References: Message-ID: <8MlxnBXt40ihGlDMVVx6Y2rVt2zLeFtPz83Qz6wVJ8U=.087ba426-c421-4c98-b9fe-8743e0f6af18@github.com> > This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. > > Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. > > Classfile API development is tracked at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch > > Development branch of consolidated JDK class files parsing, generating, and transforming is at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch > > Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. > > Please take you time to review this non-trivial JDK addition. > > Thank you, > Adam Adam Sotona has updated the pull request incrementally with three additional commits since the last revision: - Update src/java.base/share/classes/jdk/internal/classfile/instruction/ConstantInstruction.java Co-authored-by: Paul Sandoz - Update src/java.base/share/classes/jdk/internal/classfile/instruction/ConstantInstruction.java Co-authored-by: Paul Sandoz - Update src/java.base/share/classes/jdk/internal/classfile/snippet-files/PackageSnippets.java Co-authored-by: Paul Sandoz ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10982/files - new: https://git.openjdk.org/jdk/pull/10982/files/074dd304..02bd6dcb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=36 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=35-36 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/10982.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982 PR: https://git.openjdk.org/jdk/pull/10982 From asotona at openjdk.org Fri Mar 3 08:37:30 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 3 Mar 2023 08:37:30 GMT Subject: RFR: 8294982: Implementation of Classfile API [v38] In-Reply-To: References: Message-ID: > This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. > > Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. > > Classfile API development is tracked at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch > > Development branch of consolidated JDK class files parsing, generating, and transforming is at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch > > Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. > > Please take you time to review this non-trivial JDK addition. > > Thank you, > Adam Adam Sotona has updated the pull request incrementally with three additional commits since the last revision: - Update src/java.base/share/classes/jdk/internal/classfile/CodeBuilder.java Co-authored-by: Paul Sandoz - Update src/java.base/share/classes/jdk/internal/classfile/CodeBuilder.java Co-authored-by: Paul Sandoz - Update src/java.base/share/classes/jdk/internal/classfile/instruction/ExceptionCatch.java Co-authored-by: Paul Sandoz ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10982/files - new: https://git.openjdk.org/jdk/pull/10982/files/02bd6dcb..0bd5281f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=37 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=36-37 Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/10982.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982 PR: https://git.openjdk.org/jdk/pull/10982 From asotona at openjdk.org Fri Mar 3 08:40:19 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 3 Mar 2023 08:40:19 GMT Subject: RFR: 8294982: Implementation of Classfile API [v39] In-Reply-To: References: Message-ID: > This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. > > Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. > > Classfile API development is tracked at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch > > Development branch of consolidated JDK class files parsing, generating, and transforming is at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch > > Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. > > Please take you time to review this non-trivial JDK addition. > > Thank you, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: Update src/java.base/share/classes/jdk/internal/classfile/impl/NonterminalCodeBuilder.java Co-authored-by: Paul Sandoz ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10982/files - new: https://git.openjdk.org/jdk/pull/10982/files/0bd5281f..e5fd5764 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=38 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=37-38 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10982.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982 PR: https://git.openjdk.org/jdk/pull/10982 From asotona at openjdk.org Fri Mar 3 08:46:36 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 3 Mar 2023 08:46:36 GMT Subject: RFR: 8294982: Implementation of Classfile API [v40] In-Reply-To: References: Message-ID: > This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. > > Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. > > Classfile API development is tracked at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch > > Development branch of consolidated JDK class files parsing, generating, and transforming is at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch > > Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. > > Please take you time to review this non-trivial JDK addition. > > Thank you, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: Update src/java.base/share/classes/jdk/internal/classfile/TypeKind.java Co-authored-by: Paul Sandoz ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10982/files - new: https://git.openjdk.org/jdk/pull/10982/files/e5fd5764..79bfd4c5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=39 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=38-39 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10982.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982 PR: https://git.openjdk.org/jdk/pull/10982 From prappo at openjdk.org Fri Mar 3 09:15:23 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Fri, 3 Mar 2023 09:15:23 GMT Subject: Integrated: 8303473: Add implied {@code} in java.lang.invoke.MethodHandles In-Reply-To: References: Message-ID: <9LK54qkb8Nzk3kHEGK22z73zdp825aS568Gqv9yusIs=.c21c5907-82e3-4aa2-9a74-d2b7285ff3bb@github.com> On Wed, 1 Mar 2023 18:47:14 GMT, Pavel Rappo wrote: > Please review this trivial fix for _comments_. While some affected comments aren't doc comments and none of the affected comments partake in the API Documentation, it seems reasonable to be consistent. This pull request has now been integrated. Changeset: e1745bc9 Author: Pavel Rappo URL: https://git.openjdk.org/jdk/commit/e1745bc98180e0d49ed4dd3116a43c90645a1a09 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod 8303473: Add implied {@code} in java.lang.invoke.MethodHandles Reviewed-by: jjg, lancea, mchung ------------- PR: https://git.openjdk.org/jdk/pull/12811 From prappo at openjdk.org Fri Mar 3 09:41:06 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Fri, 3 Mar 2023 09:41:06 GMT Subject: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 16:23:17 GMT, Alexey Ivanov wrote: >> Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API. >> >> The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows: >> >> >> diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html >> --- build/macosx-aarch64/images/docs-before/api/serialized-form.html 2023-03-02 11:47:44 >> +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html 2023-03-02 11:48:45 >> @@ -17084,7 +17084,7 @@ >> throws IOException, >> ClassNotFoundException >>
readObject is called to restore the state of the >> - (@code BasicPermission} from a stream.
>> + BasicPermission from a stream. >>
>>
Parameters:
>>
s - the ObjectInputStream from which data is read
>> >> Notes >> ----- >> >> * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas. >> * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary. >> * I will update copyright years after (and if) the fix had been approved, as required. > > src/java.base/share/classes/java/lang/invoke/BootstrapMethodInvoker.java line 257: > >> 255: >> 256: /** >> 257: * @return true iff the BSM method type exactly matches > > I assume ?iff? should ?if?? Here and elsewhere in this file "iff" might mean [if and only if](https://en.wikipedia.org/wiki/If_and_only_if), which would make sense. (FWIW, there are a few hundred occurrences of the word "iff" in src.) @cl4es (Claes Redestad), as the author of those lines would you like to chime in? Since Claes might read this, I note that when I changed unsupported `{@see}` to `{@link}` thoughtout this file, my IDE could not resolve one of the links: `java.lang.invoke.LambdaMetafactory#metafactory(MethodHandles.Lookup,String,Class,MethodType,MethodHandle,MethodType)` While there's a similarly-name method with slightly different parameters, I refrained from using it: `java.lang.invoke.LambdaMetafactory#metafactory(MethodHandles.Lookup,String,MethodType,MethodType,MethodHandle,MethodType)`. ------------- PR: https://git.openjdk.org/jdk/pull/12826 From prappo at openjdk.org Fri Mar 3 09:44:13 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Fri, 3 Mar 2023 09:44:13 GMT Subject: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments In-Reply-To: References: Message-ID: <5TgKeBVz0u1hCa1qOiC7Y46DJvUtDIsDa1wv2I4tAX8=.8575f968-0685-450d-8d77-16523cd7531a@github.com> On Fri, 3 Mar 2023 08:15:49 GMT, Alexey Ivanov wrote: >> Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API. >> >> The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows: >> >> >> diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html >> --- build/macosx-aarch64/images/docs-before/api/serialized-form.html 2023-03-02 11:47:44 >> +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html 2023-03-02 11:48:45 >> @@ -17084,7 +17084,7 @@ >> throws IOException, >> ClassNotFoundException >>
readObject is called to restore the state of the >> - (@code BasicPermission} from a stream.
>> + BasicPermission from a stream. >>
>>
Parameters:
>>
s - the ObjectInputStream from which data is read
>> >> Notes >> ----- >> >> * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas. >> * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary. >> * I will update copyright years after (and if) the fix had been approved, as required. > > src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 2866: > >> 2864: * Merge multiple abstract methods. The preferred method is a method that is a subsignature >> 2865: * of all the other signatures and whose return type is more specific {@link MostSpecificReturnCheck}. >> 2866: * The resulting preferred method has a thrown clause that is the intersection of the merged > > Is it ??has a {@code throws} clause??? Thanks! I'll add this to a separate PR. ------------- PR: https://git.openjdk.org/jdk/pull/12826 From mcimadamore at openjdk.org Fri Mar 3 10:02:09 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 3 Mar 2023 10:02:09 GMT Subject: RFR: 8303516: HFAs with nested structs/unions/arrays not handled correctly on AArch64 In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 13:48:26 GMT, Jorn Vernee wrote: > Port of: https://github.com/openjdk/panama-foreign/pull/780 Which adds tests for nested structs/unions/arrays, and fixes an issue with nested HFAs on AArch64. > > This PR also includes https://github.com/openjdk/panama-foreign/pull/765 which is required for the fix to apply cleanly. > > Moving these change sets into the mainline now seems useful for the currently ongoing porting effort on PPC, as well as taking a load off of the JEP PR review which will come later. Look good (already reviewed in the panama repository) ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.org/jdk/pull/12831 From redestad at openjdk.org Fri Mar 3 10:12:13 2023 From: redestad at openjdk.org (Claes Redestad) Date: Fri, 3 Mar 2023 10:12:13 GMT Subject: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments In-Reply-To: References: Message-ID: <-U8YFFuXm_hMf-bY1AVCRauRrE-fRYRxrx_yf38ZL1A=.d50884c5-cc4b-489a-b817-828faf876c76@github.com> On Fri, 3 Mar 2023 09:38:13 GMT, Pavel Rappo wrote: >> src/java.base/share/classes/java/lang/invoke/BootstrapMethodInvoker.java line 257: >> >>> 255: >>> 256: /** >>> 257: * @return true iff the BSM method type exactly matches >> >> I assume ?iff? should ?if?? > > Here and elsewhere in this file "iff" might mean [if and only if](https://en.wikipedia.org/wiki/If_and_only_if), which would make sense. (FWIW, there are a few hundred occurrences of the word "iff" in src.) > > @cl4es (Claes Redestad), as the author of those lines would you like to chime in? > > Since Claes might read this, I note that when I changed unsupported `{@see}` to `{@link}` thoughtout this file, my IDE could not resolve one of the links: `java.lang.invoke.LambdaMetafactory#metafactory(MethodHandles.Lookup,String,Class,MethodType,MethodHandle,MethodType)` > > While there's a similarly-name method with slightly different parameters, I refrained from using it: > `java.lang.invoke.LambdaMetafactory#metafactory(MethodHandles.Lookup,String,MethodType,MethodType,MethodHandle,MethodType)`. Yes, iff means if-and-only-if and is used for extra precision in formal logic, mathematics. As @pavelrappo points out it's a relatively common occurrence in the OpenJDK sources, though perhaps not in the public javadocs. Perhaps a bit pretentious, but mostly a terse way to say "return true if the BSM method type exactly matches X, otherwise false". The broken link stems from the fact that the method I was targeting (a way to use condy for lambda proxy singletons rather than a `MethodHandle.constant`) was never integrated. We'll look at either getting that done (@briangoetz suggested the time might be ready for it) or remove this currently pointless static bootstrap specialization test. ------------- PR: https://git.openjdk.org/jdk/pull/12826 From mdoerr at openjdk.org Fri Mar 3 10:55:57 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Fri, 3 Mar 2023 10:55:57 GMT Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function & Memory API (Preview) [v9] In-Reply-To: References: Message-ID: > Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification". > > This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `` (2.2.4 Variable Argument Lists). > > Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only. > > There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Will get addressed separately: [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017) > > The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests. > > I had to make changes to shared code and code for other platforms: > 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons: > - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that. > - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64. > - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian! > 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit. Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: Handle HFA corner cases with overlapping registers in Java. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12708/files - new: https://git.openjdk.org/jdk/pull/12708/files/f23edd8e..98e242c2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=07-08 Stats: 53 lines in 4 files changed: 16 ins; 20 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/12708.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12708/head:pull/12708 PR: https://git.openjdk.org/jdk/pull/12708 From duke at openjdk.org Fri Mar 3 10:57:18 2023 From: duke at openjdk.org (Thomas Wuerthinger) Date: Fri, 3 Mar 2023 10:57:18 GMT Subject: RFR: 8292914: Introduce a system property that enables stable names for lambda proxy classes [v7] In-Reply-To: References: Message-ID: <3rZvcMQD7e4zIK14-2JRdcQX7jtgZO85z8se_gR0ufY=.2b6701c5-7422-45c4-881c-508eb0476d3f@github.com> On Mon, 21 Nov 2022 16:46:43 GMT, Strahinja Stanojevic wrote: >> This PR introduces an option to output stable names for the lambda classes in the JDK. A stable name consists of two parts: The first part is the predefined value `$$Lambda$` appended to the lambda capturing class, and the second is a 64-bit hash part of the name. Thus, it looks like `lambdaCapturingClass$$Lambda$hashValue`. >> Parameters used to create a stable hash are a superset of the parameters used for lambda class archiving when the CDS dumping option is enabled. During this process, all the mutual parameters are in the same form as they are in the low-level implementation (`SystemDictionaryShared::add_lambda_proxy_class`) of the archiving process. >> We decided to use a well-specified `CRC32` algorithm from the standard Java library. We created two 32-bit hashes from the parameters used to create stable names. Then, we combined those two 32-bit hashes into one 64-bit hash value. >> We chose `CRC32` because it is a well-specified hash function, and we don't need to write additional code in the JDK. `SHA-256, MD5`, and all other hash functions that rely on `MessageDigest` use lambdas in the implementation, so they are unsuitable for our purpose. We also considered a few different hash functions with a low collision rate. All these functions would require at least 100 lines of additional code in the JDK. The best alternative we found is 64-bit` MurmurHash2`: https://commons.apache.org/proper/commons-codec/jacoco/org.apache.commons.codec.digest/MurmurHash2.java.html. In case adding a new hash implementation (e.g., Murmur2) to the JDK is preferred, this PR can be easily modified. >> We found the post (https://softwareengineering.stackexchange.com/questions/49550/which-hashing-algorithm-is-best-for-uniqueness-and-speed/145633#145633) that compares different hash functions. >> We also tested the `CRC32` hash function against half a billion generated strings, and there were no collisions. Note that the capturing-class name is also part of the lambda class name, so the potential collisions can only appear in a single class. Thus, we do not expect to have name collisions due to a relatively low number of lambdas per class. Every tool that uses this feature should handle potential collisions on its own. >> We found an overall approximation of the collision rate too. You can find it here: https://preshing.com/20110504/hash-collision-probabilities/. >> >> JDK currently adds an atomic integer after `$$Lambda$`, and the names of the lambdas depend on the creation order. In the `TestStableLambdaNames`, we generate all the lambdas two times. In the first run, the method createPlainLambdas generate the following lambdas: >> >> - TestStableLambdaNames$$Lambda$1/0x0000000800c00400 >> - TestStableLambdaNames$$Lambda$2/0x0000000800c01800 >> - TestStableLambdaNames$$Lambda$3/0x0000000800c01a38 >> The same method in the second run generates lambdas with different names: >> - TestStableLambdaNames$$Lambda$1471/0x0000000800d10000 >> - TestStableLambdaNames$$Lambda$1472/0x0000000800d10238 >> - TestStableLambdaNames$$Lambda$1473/0x0000000800d10470 >> >> If we use the introduced flag, generated lambdas are: >> - TestStableLambdaNames$$Lambda$65ba26bbc6c7500d/0x0000000800c00400 >> - TestStableLambdaNames$$Lambda$1569c8c4abe3ab18/0x0000000800c01800 >> - TestStableLambdaNames$$Lambda$493c0ecaaf682428/0x0000000800c01a38 >> In the second run of the method, generated lambdas are: >> - TestStableLambdaNames$$Lambda$65ba26bbc6c7500d/0x0000000800d10000 >> - TestStableLambdaNames$$Lambda$1569c8c4abe3ab18/0x0000000800d10238 >> - TestStableLambdaNames$$Lambda$493c0ecaaf682428/0x0000000800d10470 >> >> We can see that the introduced hash value does not change between two calls of the method `createPlainLambdas`. That was not the case in the JDK run without this change. Those lambdas are extracted directly from the test. > > Strahinja Stanojevic has updated the pull request incrementally with one additional commit since the last revision: > > Remove address from lambda class names in test on the 32-bit architecture too Having a stable numeric suffix for the lambda class name improves debuggability of the system compared to a solution where all lambdas have the same class name. The stable hash function can probably be simplified given that collisions are less problematic because of #12579. ------------- PR: https://git.openjdk.org/jdk/pull/10024 From mdoerr at openjdk.org Fri Mar 3 11:02:18 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Fri, 3 Mar 2023 11:02:18 GMT Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function & Memory API (Preview) [v3] In-Reply-To: References: <8b3vVrV22RuhdRoRYacXV0ZeghFGgKkC8S_z-iMrzAQ=.dd84b743-8b51-4281-8f5f-f9eff6207bc7@github.com> Message-ID: On Wed, 1 Mar 2023 06:26:20 GMT, Martin Doerr wrote: >> src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/CallArranger.java line 293: >> >>> 291: } else { >>> 292: overlappingReg = new VMStorage(StorageType.STACK_AND_FLOAT, >>> 293: (short) STACK_SLOT_SIZE, (int) stackOffset - 4); >> >> I think you could remove the mixed VMStorage types here relatively easily by returning a `VMStorage[][]`, where each element is a single element array, but then for the `needOverlapping` case add another element to the array for the extra store (instead of replacing the existing one). >> >> Then when unboxing a `STRUCT_HFA`, `dup` the result of the `bufferLoad` and then do 2 `vmStore`s (one for each element). >> >> For boxing, you could just ignore the extra storage, and just `vmLoad` the first one (or, whichever one you like :)) > > Thanks! I need to find extra time for this. Sounds like a good idea and I may be able to get rid of some nasty code. Done by https://github.com/openjdk/jdk/pull/12708/commits/98e242c24c07ea977b7709b9f8d0c10ce87e84c0 (using a record instead of a `VMStorage[][]` because I think this is better readable). Note that it's a bit more complicated. I couldn't use your `dup` trick, because I need to put the value into a GP reg and one half of it to a FP reg. The Panama code doesn't support that (IllegalArgumentException: Invalid operand type: interface java.lang.foreign.MemorySegment. float expected). ------------- PR: https://git.openjdk.org/jdk/pull/12708 From mcimadamore at openjdk.org Fri Mar 3 11:10:22 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 3 Mar 2023 11:10:22 GMT Subject: RFR: 8303409: Add Windows AArch64 ABI support to the Foreign Function & Memory API In-Reply-To: References: Message-ID: On Mon, 27 Feb 2023 17:04:28 GMT, Saint Wesonga wrote: > There are 2 primary differences between the Windows ARM64 ABI and the macOS/Linux ARM64 ABI: variadic floating point arguments are passed in general purpose registers on Windows (instead of the vector registers). In addition to this, up to 64 bytes of a struct being passed to a variadic function can be placed in general purpose registers. This happens regardless of the type of struct (HFA or other generic struct). This means that a struct can be split across registers and the stack when invoking a variadic function. The Windows ARM64 ABI conventions are documented at https://learn.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions > > For details about the Foreign Function & Memory API, see JEP 434 at https://openjdk.org/jeps/434 > > This change is a cherry pick of https://github.com/openjdk/panama-foreign/commit/d379ca1c and https://github.com/openjdk/panama-foreign/commit/08225e4f from https://github.com/openjdk/panama-foreign/pull/754 and includes an additional commit that introduces a VaList implementation for Windows on AArch64. Many thanks for looking into this port! ------------- PR: https://git.openjdk.org/jdk/pull/12773 From aivanov at openjdk.org Fri Mar 3 11:34:16 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 3 Mar 2023 11:34:16 GMT Subject: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments In-Reply-To: <-U8YFFuXm_hMf-bY1AVCRauRrE-fRYRxrx_yf38ZL1A=.d50884c5-cc4b-489a-b817-828faf876c76@github.com> References: <-U8YFFuXm_hMf-bY1AVCRauRrE-fRYRxrx_yf38ZL1A=.d50884c5-cc4b-489a-b817-828faf876c76@github.com> Message-ID: On Fri, 3 Mar 2023 10:09:27 GMT, Claes Redestad wrote: > Yes, iff means if-and-only-if and is used for extra precision in formal logic, mathematics. I've never come across it before. With your explanations, it makes perfect sense. ------------- PR: https://git.openjdk.org/jdk/pull/12826 From mullan at openjdk.org Fri Mar 3 13:09:33 2023 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 3 Mar 2023 13:09:33 GMT Subject: Integrated: 8297955: LDAP CertStore should use LdapName and not String for DNs In-Reply-To: References: Message-ID: On Thu, 23 Feb 2023 16:42:17 GMT, Sean Mullan wrote: > The LDAPCertStore implementation passes Distinguished Names in CRL and Certificate URLs as Strings to JNDI APIs such as LdapContext.getAttributes(String), which then treats them as CompositeNames. This causes issues with URLs that have DNs with forward slashes. These are rare but compliant with the LDAP URL format for DNs referenced by [section 4.2.1.13 of RFC 5280](https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.13). Instead, the implementation should be passing the DN to JNDI APIs as an LdapName, which parses the forward slash character as part of the DN. Unfortunately, LDAP referral URLs can not be converted to LdapNames, so we keep the current DN syntax checks (and disallow forward slashes) if there are referrals involved. > > The current test/jdk/security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.java can be used to test this fix as it contains a test certificate with an LDAP URL in the CRL Distribution Points with a forward slash in the Distinguished Name. Prior to the fix it was failing because of this bug, now it is passing. We also take this opportunity to update the test and replace expired test certificates with new ones. This pull request has now been integrated. Changeset: df9aad01 Author: Sean Mullan URL: https://git.openjdk.org/jdk/commit/df9aad018a769a27221cb29e4e66465e5d98ba94 Stats: 62 lines in 2 files changed: 11 ins; 8 del; 43 mod 8297955: LDAP CertStore should use LdapName and not String for DNs Reviewed-by: weijun, rhalade ------------- PR: https://git.openjdk.org/jdk/pull/12730 From amitkumar at openjdk.org Fri Mar 3 13:20:29 2023 From: amitkumar at openjdk.org (Amit Kumar) Date: Fri, 3 Mar 2023 13:20:29 GMT Subject: Integrated: 8303499: [s390x] ProblemList StressStackOverflow In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 16:22:24 GMT, Amit Kumar wrote: > This PR adds StressStackOverflow.java test to ProblemList. The feature Scope Value is not yet implemented on s390x-arch which is Incubating state. Whenever fix will be given to [JDK-8303498](https://bugs.openjdk.org/browse/JDK-8303498) then we will remove it. This pull request has now been integrated. Changeset: 8bf084ce Author: Amit Kumar Committer: Alan Bateman URL: https://git.openjdk.org/jdk/commit/8bf084ced9efbed0be99f95103d25f7e6d4aab90 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8303499: [s390x] ProblemList StressStackOverflow Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/12834 From duke at openjdk.org Fri Mar 3 13:20:29 2023 From: duke at openjdk.org (Afshin Zafari) Date: Fri, 3 Mar 2023 13:20:29 GMT Subject: Integrated: 8301622: ProcessTools.java compilation gets ThreadDeath deprecation warning In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 12:15:21 GMT, Afshin Zafari wrote: > ### Description > The use of `ThreadDeath` is replaced with checking the exception be of type `Error` and the thread is `TERMINATED`. > > > ### Test > local and mach5 tier1 This pull request has now been integrated. Changeset: ff364c19 Author: Afshin Zafari Committer: Alan Bateman URL: https://git.openjdk.org/jdk/commit/ff364c1906f078c13e121a43e60606caff5781e7 Stats: 5 lines in 1 file changed: 1 ins; 3 del; 1 mod 8301622: ProcessTools.java compilation gets ThreadDeath deprecation warning Reviewed-by: dholmes, alanb ------------- PR: https://git.openjdk.org/jdk/pull/12827 From jpai at openjdk.org Fri Mar 3 13:48:49 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 3 Mar 2023 13:48:49 GMT Subject: RFR: 8303198: System and Runtime.exit() resilience to logging errors [v2] In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 16:59:51 GMT, Roger Riggs wrote: >> Consolidate logging and handle exceptions by printing to standard error and ignoring the exception. >> Exceptions while logging will not interfere with Runtime.exit. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Add exit status to output when the logging fails with an exception. Thank you Roger. The changes look good to me. ------------- Marked as reviewed by jpai (Reviewer). PR: https://git.openjdk.org/jdk/pull/12770 From asotona at openjdk.org Fri Mar 3 13:50:15 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 3 Mar 2023 13:50:15 GMT Subject: RFR: 8294982: Implementation of Classfile API [v41] In-Reply-To: References: Message-ID: > This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. > > Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. > > Classfile API development is tracked at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch > > Development branch of consolidated JDK class files parsing, generating, and transforming is at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch > > Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. > > Please take you time to review this non-trivial JDK addition. > > Thank you, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: Signature.TypeArg does not inherit from Signature ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10982/files - new: https://git.openjdk.org/jdk/pull/10982/files/79bfd4c5..b03f15c1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=40 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=39-40 Stats: 78 lines in 5 files changed: 37 ins; 8 del; 33 mod Patch: https://git.openjdk.org/jdk/pull/10982.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982 PR: https://git.openjdk.org/jdk/pull/10982 From duke at openjdk.org Fri Mar 3 13:59:11 2023 From: duke at openjdk.org (David M. Lloyd) Date: Fri, 3 Mar 2023 13:59:11 GMT Subject: RFR: 8292914: Introduce a system property that enables stable names for lambda proxy classes [v7] In-Reply-To: References: Message-ID: On Mon, 21 Nov 2022 16:46:43 GMT, Strahinja Stanojevic wrote: >> This PR introduces an option to output stable names for the lambda classes in the JDK. A stable name consists of two parts: The first part is the predefined value `$$Lambda$` appended to the lambda capturing class, and the second is a 64-bit hash part of the name. Thus, it looks like `lambdaCapturingClass$$Lambda$hashValue`. >> Parameters used to create a stable hash are a superset of the parameters used for lambda class archiving when the CDS dumping option is enabled. During this process, all the mutual parameters are in the same form as they are in the low-level implementation (`SystemDictionaryShared::add_lambda_proxy_class`) of the archiving process. >> We decided to use a well-specified `CRC32` algorithm from the standard Java library. We created two 32-bit hashes from the parameters used to create stable names. Then, we combined those two 32-bit hashes into one 64-bit hash value. >> We chose `CRC32` because it is a well-specified hash function, and we don't need to write additional code in the JDK. `SHA-256, MD5`, and all other hash functions that rely on `MessageDigest` use lambdas in the implementation, so they are unsuitable for our purpose. We also considered a few different hash functions with a low collision rate. All these functions would require at least 100 lines of additional code in the JDK. The best alternative we found is 64-bit` MurmurHash2`: https://commons.apache.org/proper/commons-codec/jacoco/org.apache.commons.codec.digest/MurmurHash2.java.html. In case adding a new hash implementation (e.g., Murmur2) to the JDK is preferred, this PR can be easily modified. >> We found the post (https://softwareengineering.stackexchange.com/questions/49550/which-hashing-algorithm-is-best-for-uniqueness-and-speed/145633#145633) that compares different hash functions. >> We also tested the `CRC32` hash function against half a billion generated strings, and there were no collisions. Note that the capturing-class name is also part of the lambda class name, so the potential collisions can only appear in a single class. Thus, we do not expect to have name collisions due to a relatively low number of lambdas per class. Every tool that uses this feature should handle potential collisions on its own. >> We found an overall approximation of the collision rate too. You can find it here: https://preshing.com/20110504/hash-collision-probabilities/. >> >> JDK currently adds an atomic integer after `$$Lambda$`, and the names of the lambdas depend on the creation order. In the `TestStableLambdaNames`, we generate all the lambdas two times. In the first run, the method createPlainLambdas generate the following lambdas: >> >> - TestStableLambdaNames$$Lambda$1/0x0000000800c00400 >> - TestStableLambdaNames$$Lambda$2/0x0000000800c01800 >> - TestStableLambdaNames$$Lambda$3/0x0000000800c01a38 >> The same method in the second run generates lambdas with different names: >> - TestStableLambdaNames$$Lambda$1471/0x0000000800d10000 >> - TestStableLambdaNames$$Lambda$1472/0x0000000800d10238 >> - TestStableLambdaNames$$Lambda$1473/0x0000000800d10470 >> >> If we use the introduced flag, generated lambdas are: >> - TestStableLambdaNames$$Lambda$65ba26bbc6c7500d/0x0000000800c00400 >> - TestStableLambdaNames$$Lambda$1569c8c4abe3ab18/0x0000000800c01800 >> - TestStableLambdaNames$$Lambda$493c0ecaaf682428/0x0000000800c01a38 >> In the second run of the method, generated lambdas are: >> - TestStableLambdaNames$$Lambda$65ba26bbc6c7500d/0x0000000800d10000 >> - TestStableLambdaNames$$Lambda$1569c8c4abe3ab18/0x0000000800d10238 >> - TestStableLambdaNames$$Lambda$493c0ecaaf682428/0x0000000800d10470 >> >> We can see that the introduced hash value does not change between two calls of the method `createPlainLambdas`. That was not the case in the JDK run without this change. Those lambdas are extracted directly from the test. > > Strahinja Stanojevic has updated the pull request incrementally with one additional commit since the last revision: > > Remove address from lambda class names in test on the 32-bit architecture too What about other cases like the JLI `MH`, `DMH`, `InjectedInvoker`, lambda form etc. classes? Or the FFI specialized upcall proxies, or the many cases where users define hidden classes? Wouldn't it be better to make the suffix of a hidden class be repeatable, thus solving all of these cases at once, rather than chasing down every place where a hidden class is defined? ------------- PR: https://git.openjdk.org/jdk/pull/10024 From alanb at openjdk.org Fri Mar 3 14:00:15 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 3 Mar 2023 14:00:15 GMT Subject: RFR: 8303198: System and Runtime.exit() resilience to logging errors [v2] In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 16:59:51 GMT, Roger Riggs wrote: >> Consolidate logging and handle exceptions by printing to standard error and ignoring the exception. >> Exceptions while logging will not interfere with Runtime.exit. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Add exit status to output when the logging fails with an exception. I think this looks okay. The main goal is to make it easy to identify the code that is calling System.exit and this seems as robust as it can be. The issue of racing exits can be looked at again, if it turns out to be interesting. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.org/jdk/pull/12770 From jpai at openjdk.org Fri Mar 3 14:18:14 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 3 Mar 2023 14:18:14 GMT Subject: RFR: 8294982: Implementation of Classfile API [v41] In-Reply-To: References: Message-ID: On Fri, 3 Mar 2023 13:50:15 GMT, Adam Sotona wrote: >> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. >> >> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. >> >> Classfile API development is tracked at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch >> >> Development branch of consolidated JDK class files parsing, generating, and transforming is at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch >> >> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. >> >> Please take you time to review this non-trivial JDK addition. >> >> Thank you, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > Signature.TypeArg does not inherit from Signature src/java.base/share/classes/jdk/internal/classfile/AccessFlags.java line 54: > 52: * {@return whether the specified flag is present} The specified flag > 53: * should be a valid flag for the classfile location associated with this > 54: * element. Hello Adam, the way this is worded, it feels like if the flag isn't valid then this method would raise an exception. Looking at the implementation, that doesn't look like the case. Should it be reworded to say it returns false in such cases? On a related note, since this JEP is for introducing this API for internal use only, would you prefer if the javadoc text isn't reviewed to this level of detail? ------------- PR: https://git.openjdk.org/jdk/pull/10982 From jvernee at openjdk.org Fri Mar 3 14:37:31 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 3 Mar 2023 14:37:31 GMT Subject: Integrated: 8303516: HFAs with nested structs/unions/arrays not handled correctly on AArch64 In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 13:48:26 GMT, Jorn Vernee wrote: > Port of: https://github.com/openjdk/panama-foreign/pull/780 Which adds tests for nested structs/unions/arrays, and fixes an issue with nested HFAs on AArch64. > > This PR also includes https://github.com/openjdk/panama-foreign/pull/765 which is required for the fix to apply cleanly. > > Moving these change sets into the mainline now seems useful for the currently ongoing porting effort on PPC, as well as taking a load off of the JEP PR review which will come later. This pull request has now been integrated. Changeset: c6de66c0 Author: Jorn Vernee URL: https://git.openjdk.org/jdk/commit/c6de66c03f691469ff26c14923bf21bdefd5ae72 Stats: 1046 lines in 8 files changed: 786 ins; 174 del; 86 mod 8303516: HFAs with nested structs/unions/arrays not handled correctly on AArch64 Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.org/jdk/pull/12831 From asotona at openjdk.org Fri Mar 3 14:57:21 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 3 Mar 2023 14:57:21 GMT Subject: RFR: 8294982: Implementation of Classfile API [v36] In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 19:27:58 GMT, Paul Sandoz wrote: >> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: >> >> StackMapFrameInfo extracted to top level from StackMapTableAttribute > > src/java.base/share/classes/jdk/internal/classfile/instruction/CharacterRange.java line 42: > >> 40: * the setting of the {@link Classfile.Option#processDebug(boolean)} option. >> 41: */ >> 42: public sealed interface CharacterRange extends PseudoInstruction > > This and some other instructions with unbounded implementations do not have static `of` factory methods. Is that intended? It seems to be incomplete. I'll add factory methods to `CharacterRange`, `LineNumber`, `LocalVariable` and `LocalVariableType`. Thanks for pointing it out. ------------- PR: https://git.openjdk.org/jdk/pull/10982 From jlaskey at openjdk.org Fri Mar 3 14:59:53 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 3 Mar 2023 14:59:53 GMT Subject: RFR: JDK-8302323 Add repeat methods to StringBuilder/StringBuffer [v7] In-Reply-To: <7MFQi5db0hcKy59xaMjJKUhrYD269uZUyFYoci8i7yc=.2751c5b5-021c-4fa3-a3ae-a6f770b37ee7@github.com> References: <7MFQi5db0hcKy59xaMjJKUhrYD269uZUyFYoci8i7yc=.2751c5b5-021c-4fa3-a3ae-a6f770b37ee7@github.com> Message-ID: On Thu, 2 Mar 2023 20:19:01 GMT, Jim Laskey wrote: >> Add the ability to repeatedly append char and CharSequence data to StringBuilder/StringBuffer. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Add snippet Can I get some final reviews? ------------- PR: https://git.openjdk.org/jdk/pull/12728 From tvaleev at openjdk.org Fri Mar 3 15:15:22 2023 From: tvaleev at openjdk.org (Tagir F. Valeev) Date: Fri, 3 Mar 2023 15:15:22 GMT Subject: RFR: JDK-8302323 Add repeat methods to StringBuilder/StringBuffer [v7] In-Reply-To: <7MFQi5db0hcKy59xaMjJKUhrYD269uZUyFYoci8i7yc=.2751c5b5-021c-4fa3-a3ae-a6f770b37ee7@github.com> References: <7MFQi5db0hcKy59xaMjJKUhrYD269uZUyFYoci8i7yc=.2751c5b5-021c-4fa3-a3ae-a6f770b37ee7@github.com> Message-ID: On Thu, 2 Mar 2023 20:19:01 GMT, Jim Laskey wrote: >> Add the ability to repeatedly append char and CharSequence data to StringBuilder/StringBuffer. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Add snippet Marked as reviewed by tvaleev (Committer). ------------- PR: https://git.openjdk.org/jdk/pull/12728 From alanb at openjdk.org Fri Mar 3 15:25:23 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 3 Mar 2023 15:25:23 GMT Subject: RFR: JDK-8302323 Add repeat methods to StringBuilder/StringBuffer [v7] In-Reply-To: <7MFQi5db0hcKy59xaMjJKUhrYD269uZUyFYoci8i7yc=.2751c5b5-021c-4fa3-a3ae-a6f770b37ee7@github.com> References: <7MFQi5db0hcKy59xaMjJKUhrYD269uZUyFYoci8i7yc=.2751c5b5-021c-4fa3-a3ae-a6f770b37ee7@github.com> Message-ID: On Thu, 2 Mar 2023 20:19:01 GMT, Jim Laskey wrote: >> Add the ability to repeatedly append char and CharSequence data to StringBuilder/StringBuffer. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Add snippet The repeat codePoint throws IAE if the input is not a valid Unicode code point. Is there a test for that? The tests for IAE seem to be the negative repeat count but maybe I missed it? Also wondering if this needs tests for legacy StringBuffer. ------------- PR: https://git.openjdk.org/jdk/pull/12728 From asotona at openjdk.org Fri Mar 3 15:35:15 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 3 Mar 2023 15:35:15 GMT Subject: RFR: 8294982: Implementation of Classfile API [v42] In-Reply-To: References: Message-ID: > This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. > > Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. > > Classfile API development is tracked at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch > > Development branch of consolidated JDK class files parsing, generating, and transforming is at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch > > Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. > > Please take you time to review this non-trivial JDK addition. > > Thank you, > Adam Adam Sotona has updated the pull request incrementally with two additional commits since the last revision: - factory methods to CharacterRange, LineNumber, LocalVariable and LocalVariableType - CodeRelabeler fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10982/files - new: https://git.openjdk.org/jdk/pull/10982/files/b03f15c1..8561d134 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=41 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=40-41 Stats: 107 lines in 6 files changed: 100 ins; 3 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/10982.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982 PR: https://git.openjdk.org/jdk/pull/10982 From asotona at openjdk.org Fri Mar 3 15:35:18 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 3 Mar 2023 15:35:18 GMT Subject: RFR: 8294982: Implementation of Classfile API [v36] In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 19:31:50 GMT, Paul Sandoz wrote: >> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: >> >> StackMapFrameInfo extracted to top level from StackMapTableAttribute > > src/java.base/share/classes/jdk/internal/classfile/components/CodeRelabeler.java line 98: > >> 96: @Override >> 97: public void accept(CodeBuilder cob, CodeElement coe) { >> 98: switch (coe) { > > Missing case for`CharacterRange` instruction? I am not sure it makes any sense, if so perhaps add a comment as to why. Fixed, thanks. ------------- PR: https://git.openjdk.org/jdk/pull/10982 From asotona at openjdk.org Fri Mar 3 15:35:18 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 3 Mar 2023 15:35:18 GMT Subject: RFR: 8294982: Implementation of Classfile API [v36] In-Reply-To: References: Message-ID: On Fri, 3 Mar 2023 14:53:19 GMT, Adam Sotona wrote: >> src/java.base/share/classes/jdk/internal/classfile/instruction/CharacterRange.java line 42: >> >>> 40: * the setting of the {@link Classfile.Option#processDebug(boolean)} option. >>> 41: */ >>> 42: public sealed interface CharacterRange extends PseudoInstruction >> >> This and some other instructions with unbounded implementations do not have static `of` factory methods. Is that intended? > > It seems to be incomplete. I'll add factory methods to `CharacterRange`, `LineNumber`, `LocalVariable` and `LocalVariableType`. > Thanks for pointing it out. Fixed, thanks. ------------- PR: https://git.openjdk.org/jdk/pull/10982 From rgiulietti at openjdk.org Fri Mar 3 15:35:40 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 3 Mar 2023 15:35:40 GMT Subject: RFR: 8302987: Add uniform and spatially equidistributed bounded float/double streams to RandomGenerator [v4] In-Reply-To: <8B2_dePA34zyndM7SzuG6sanXNQmbge8DCIOIfpnTLs=.81cb4f5b-e3d0-4352-8209-eb1ac6197126@github.com> References: <8B2_dePA34zyndM7SzuG6sanXNQmbge8DCIOIfpnTLs=.81cb4f5b-e3d0-4352-8209-eb1ac6197126@github.com> Message-ID: > The `default` method `nextDouble(double origin, double bound)` in `java.util.random.RandomGenerator` aims at generating a uniformly and spatially equidistributed random `double` in the left-closed and right-open range [`origin`, `bound`). It does so by applying the affine transform `origin + (bound - origin) * r` to a uniformly and spatially equidistributed random `double` `r` in the range [0, 1). > > Since floating-point arithmetic suffers from small but noticeable rounding errors, this ends up slightly deforming the distribution of `r` when applying the affine transform. Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: 8302987: Add uniform and spatially equidistributed bounded float/double streams to RandomGenerator Refactored to have just one public API point. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12719/files - new: https://git.openjdk.org/jdk/pull/12719/files/2d1f8e9c..a38cb827 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12719&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12719&range=02-03 Stats: 137 lines in 1 file changed: 12 ins; 98 del; 27 mod Patch: https://git.openjdk.org/jdk/pull/12719.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12719/head:pull/12719 PR: https://git.openjdk.org/jdk/pull/12719 From jlaskey at openjdk.org Fri Mar 3 15:37:12 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 3 Mar 2023 15:37:12 GMT Subject: RFR: JDK-8302323 Add repeat methods to StringBuilder/StringBuffer [v7] In-Reply-To: <7MFQi5db0hcKy59xaMjJKUhrYD269uZUyFYoci8i7yc=.2751c5b5-021c-4fa3-a3ae-a6f770b37ee7@github.com> References: <7MFQi5db0hcKy59xaMjJKUhrYD269uZUyFYoci8i7yc=.2751c5b5-021c-4fa3-a3ae-a6f770b37ee7@github.com> Message-ID: On Thu, 2 Mar 2023 20:19:01 GMT, Jim Laskey wrote: >> Add the ability to repeatedly append char and CharSequence data to StringBuilder/StringBuffer. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Add snippet I agree. Will add IAE tests for bad code points and create as second set of tests for StringBuffer. ------------- PR: https://git.openjdk.org/jdk/pull/12728 From duke at openjdk.org Fri Mar 3 15:44:47 2023 From: duke at openjdk.org (Glavo) Date: Fri, 3 Mar 2023 15:44:47 GMT Subject: Integrated: 8299807: newStringNoRepl should avoid copying arrays for ASCII compatible charsets In-Reply-To: References: Message-ID: On Fri, 20 Jan 2023 16:47:27 GMT, Glavo wrote: > This is the javadoc of `JavaLangAccess::newStringNoRepl`: > > > /** > * Constructs a new {@code String} by decoding the specified subarray of > * bytes using the specified {@linkplain java.nio.charset.Charset charset}. > * > * The caller of this method shall relinquish and transfer the ownership of > * the byte array to the callee since the later will not make a copy. > * > * @param bytes the byte array source > * @param cs the Charset > * @return the newly created string > * @throws CharacterCodingException for malformed or unmappable bytes > */ > > > It is recorded in the document that it should be able to directly construct strings with parameter byte array to reduce array allocation. > > However, at present, `newStringNoRepl` always copies arrays for UTF-8 or other ASCII compatible charsets. > > This PR fixes this problem. This pull request has now been integrated. Changeset: 7449e1c6 Author: Glavo Committer: Roger Riggs URL: https://git.openjdk.org/jdk/commit/7449e1c6617f51101e415fc29fafa79c6b55e24d Stats: 16 lines in 2 files changed: 11 ins; 0 del; 5 mod 8299807: newStringNoRepl should avoid copying arrays for ASCII compatible charsets Reviewed-by: rriggs ------------- PR: https://git.openjdk.org/jdk/pull/12119 From asotona at openjdk.org Fri Mar 3 15:54:56 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 3 Mar 2023 15:54:56 GMT Subject: RFR: 8294982: Implementation of Classfile API [v36] In-Reply-To: References: Message-ID: <6znsZYLeDpBRVVQxG5tnzA8Vat1DWuPkVX8Xeu0L31o=.5b08aebd-5769-4593-8664-7a3f80ed58fb@github.com> On Thu, 2 Mar 2023 20:37:37 GMT, Paul Sandoz wrote: >> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: >> >> StackMapFrameInfo extracted to top level from StackMapTableAttribute > > src/java.base/share/classes/jdk/internal/classfile/instruction/NewMultiArrayInstruction.java line 60: > >> 58: static NewMultiArrayInstruction of(ClassEntry arrayTypeEntry, >> 59: int dimensions) { >> 60: return new AbstractInstruction.UnboundNewMultidimensionalArrayInstruction(arrayTypeEntry, dimensions); > > Should we validate that the dimensionality of `arrayType` is greater than or equal to `dimensions`? Architectural decision is to do not provide much of validation in favour of performance, however it might be re-visited in cases like this. Please raise the validation topic at classfile-api-dev at openjdk.org, thanks. > src/java.base/share/classes/jdk/internal/classfile/instruction/NewObjectInstruction.java line 38: > >> 36: * of a {@link CodeModel}. >> 37: */ >> 38: public sealed interface NewObjectInstruction extends Instruction > > Should we add a helper method on `CodeBuilder` that does the new + dup + invoke special dance? That is great RFE for `CodeBuilder`, thanks. ------------- PR: https://git.openjdk.org/jdk/pull/10982 From asotona at openjdk.org Fri Mar 3 16:05:07 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 3 Mar 2023 16:05:07 GMT Subject: RFR: 8294982: Implementation of Classfile API [v36] In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 20:54:39 GMT, Paul Sandoz wrote: >> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: >> >> StackMapFrameInfo extracted to top level from StackMapTableAttribute > > src/java.base/share/classes/jdk/internal/classfile/instruction/LoadInstruction.java line 66: > >> 64: * @param slot the local varaible slot to load from >> 65: */ >> 66: static LoadInstruction of(Opcode op, int slot) { > > Should you validate that `slot` is compatible with `op`? (same for the StoreInstruction?) There are three aspects of this kind of validation: 1. similar to `arrayType` there was an architectural decision to less validate so to perform faster 2. static instruction factory does not have the information necessary to validate local variable slot, it could theoretically be validated in the `CodeBuilder` 3. incompatible slot would most probably prevent stack map generation and such code will fail in the later phase, or at least when verification is explicitly called on the generated code ------------- PR: https://git.openjdk.org/jdk/pull/10982 From rriggs at openjdk.org Fri Mar 3 16:18:31 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 3 Mar 2023 16:18:31 GMT Subject: Integrated: 8303198: System and Runtime.exit() resilience to logging errors In-Reply-To: References: Message-ID: On Mon, 27 Feb 2023 15:41:01 GMT, Roger Riggs wrote: > Consolidate logging and handle exceptions by printing to standard error and ignoring the exception. > Exceptions while logging will not interfere with Runtime.exit. This pull request has now been integrated. Changeset: 379f2061 Author: Roger Riggs URL: https://git.openjdk.org/jdk/commit/379f2061aa4c83388a1becd9661c1ee7b2907830 Stats: 74 lines in 2 files changed: 47 ins; 7 del; 20 mod 8303198: System and Runtime.exit() resilience to logging errors Reviewed-by: dholmes, jpai, alanb ------------- PR: https://git.openjdk.org/jdk/pull/12770 From asotona at openjdk.org Fri Mar 3 16:19:55 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 3 Mar 2023 16:19:55 GMT Subject: RFR: 8294982: Implementation of Classfile API [v41] In-Reply-To: References: Message-ID: On Fri, 3 Mar 2023 14:14:55 GMT, Jaikiran Pai wrote: >> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: >> >> Signature.TypeArg does not inherit from Signature > > src/java.base/share/classes/jdk/internal/classfile/AccessFlags.java line 54: > >> 52: * {@return whether the specified flag is present} The specified flag >> 53: * should be a valid flag for the classfile location associated with this >> 54: * element. > > Hello Adam, the way this is worded, it feels like if the flag isn't valid then this method would raise an exception. Looking at the implementation, that doesn't look like the case. Should it be reworded to say it returns false in such cases? > > On a related note, since this JEP is for introducing this API for internal use only, would you prefer if the javadoc text isn't reviewed to this level of detail? I'll fix it, thanks for the review. Manageable amount of javadoc comments is OK, preferably with directly proposed patches :) ------------- PR: https://git.openjdk.org/jdk/pull/10982 From psandoz at openjdk.org Fri Mar 3 16:19:57 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Fri, 3 Mar 2023 16:19:57 GMT Subject: RFR: 8294982: Implementation of Classfile API [v36] In-Reply-To: <6znsZYLeDpBRVVQxG5tnzA8Vat1DWuPkVX8Xeu0L31o=.5b08aebd-5769-4593-8664-7a3f80ed58fb@github.com> References: <6znsZYLeDpBRVVQxG5tnzA8Vat1DWuPkVX8Xeu0L31o=.5b08aebd-5769-4593-8664-7a3f80ed58fb@github.com> Message-ID: <67WNkektqQsrZC718PwbDCXnuHb0c-Q63UllY1hRl1Q=.4e1023f2-9dd3-4c30-9c50-9e21af2b6963@github.com> On Fri, 3 Mar 2023 15:50:33 GMT, Adam Sotona wrote: >> src/java.base/share/classes/jdk/internal/classfile/instruction/NewMultiArrayInstruction.java line 60: >> >>> 58: static NewMultiArrayInstruction of(ClassEntry arrayTypeEntry, >>> 59: int dimensions) { >>> 60: return new AbstractInstruction.UnboundNewMultidimensionalArrayInstruction(arrayTypeEntry, dimensions); >> >> Should we validate that the dimensionality of `arrayType` is greater than or equal to `dimensions`? > > Architectural decision is to do not provide much of validation in favour of performance, however it might be re-visited in cases like this. Please raise the validation topic at classfile-api-dev at openjdk.org, thanks. Ok. ------------- PR: https://git.openjdk.org/jdk/pull/10982 From asotona at openjdk.org Fri Mar 3 16:39:41 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 3 Mar 2023 16:39:41 GMT Subject: RFR: 8294982: Implementation of Classfile API [v43] In-Reply-To: References: Message-ID: > This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. > > Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. > > Classfile API development is tracked at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch > > Development branch of consolidated JDK class files parsing, generating, and transforming is at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch > > Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. > > Please take you time to review this non-trivial JDK addition. > > Thank you, > Adam Adam Sotona has updated the pull request incrementally with three additional commits since the last revision: - fixed AccessFlags javadoc - TransformImpl.FakeXyzTransform renamed to UnresolvedXyzTransform - removed obsolete generic parameter from AbstractDirectBuilder ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10982/files - new: https://git.openjdk.org/jdk/pull/10982/files/8561d134..173dc1e7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=42 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=41-42 Stats: 24 lines in 7 files changed: 0 ins; 0 del; 24 mod Patch: https://git.openjdk.org/jdk/pull/10982.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982 PR: https://git.openjdk.org/jdk/pull/10982 From asotona at openjdk.org Fri Mar 3 16:39:47 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 3 Mar 2023 16:39:47 GMT Subject: RFR: 8294982: Implementation of Classfile API [v36] In-Reply-To: <9OJf7oMSoRjxxBMyevUqjKvG8kynN4dqVg-aO4UXoKI=.a4156836-2c7f-4758-9477-b8144eed231a@github.com> References: <9OJf7oMSoRjxxBMyevUqjKvG8kynN4dqVg-aO4UXoKI=.a4156836-2c7f-4758-9477-b8144eed231a@github.com> Message-ID: On Fri, 3 Mar 2023 00:57:35 GMT, Paul Sandoz wrote: >> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: >> >> StackMapFrameInfo extracted to top level from StackMapTableAttribute > > src/java.base/share/classes/jdk/internal/classfile/impl/AbstractDirectBuilder.java line 34: > >> 32: * AbstractDirectBuilder >> 33: */ >> 34: public class AbstractDirectBuilder { > > Type variable `B` is unused. fixed, thanks. > src/java.base/share/classes/jdk/internal/classfile/impl/TransformImpl.java line 63: > >> 61: private static final Runnable NOTHING = () -> { }; >> 62: >> 63: interface FakeClassTransform extends ClassTransform { > > Rename to `UnresolvedXxxTransform`? I think that is a better name, since it could appear in stack traces. Like with `XxxTransformImpl` it may be possible to share across all implementations by mixing in? Renamed to `UnresolvedXyzTransform`, thanks. I'll consider conversion to generic form in a next step. ------------- PR: https://git.openjdk.org/jdk/pull/10982 From rriggs at openjdk.org Fri Mar 3 17:19:08 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 3 Mar 2023 17:19:08 GMT Subject: RFR: JDK-8303587 Remove VMOutOfMemoryError001 test from the problem list after 8303198 Message-ID: Remove VMOutOfMemoryException001.java from the problem list, after JDK-8303198. The logging of Runtime.exit interfered with out-of-memory exception handling in this test. Making the logging more robust in JDK-8303198 by handling exceptions restores the conditions expected by this test. ------------- Commit messages: - JDK-8303587 Remove VMOutOfMemoryError001 test from the problem list after 8303198 Changes: https://git.openjdk.org/jdk/pull/12859/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12859&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303587 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12859.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12859/head:pull/12859 PR: https://git.openjdk.org/jdk/pull/12859 From jlu at openjdk.org Fri Mar 3 17:22:29 2023 From: jlu at openjdk.org (Justin Lu) Date: Fri, 3 Mar 2023 17:22:29 GMT Subject: Integrated: 8303472: Display name for region TR In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 21:58:00 GMT, Justin Lu wrote: > This PR changes the English name for the region `TR`, from `Turkey` to `T?rkiye`. Although this change is included in the upcoming CLDR v43, it should be applied as a spot change so that it can be back-ported properly (As it is a common English region name). > > > > This change targets both the CLDR and COMPAT data. This pull request has now been integrated. Changeset: e3016c11 Author: Justin Lu Committer: Naoto Sato URL: https://git.openjdk.org/jdk/commit/e3016c11425f7f915eaf20b6e02a9ec0c9ec8690 Stats: 11 lines in 5 files changed: 6 ins; 0 del; 5 mod 8303472: Display name for region TR Reviewed-by: naoto ------------- PR: https://git.openjdk.org/jdk/pull/12816 From cjplummer at openjdk.org Fri Mar 3 17:27:07 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 3 Mar 2023 17:27:07 GMT Subject: RFR: JDK-8303587 Remove VMOutOfMemoryError001 test from the problem list after 8303198 In-Reply-To: References: Message-ID: On Fri, 3 Mar 2023 16:40:41 GMT, Roger Riggs wrote: > Remove VMOutOfMemoryException001.java from the problem list, after JDK-8303198. > > The logging of Runtime.exit interfered with out-of-memory exception handling in this test. > Making the logging more robust in JDK-8303198 by handling exceptions restores the conditions expected by this test. Approved and trivial. ------------- Marked as reviewed by cjplummer (Reviewer). PR: https://git.openjdk.org/jdk/pull/12859 From dnsimon at openjdk.org Fri Mar 3 18:00:12 2023 From: dnsimon at openjdk.org (Doug Simon) Date: Fri, 3 Mar 2023 18:00:12 GMT Subject: RFR: 8303577: [JVMCI] OOME causes crash while translating exceptions Message-ID: JDK-8297431 added code for special handling of OutOfMemoryError when translating an exception between libjvmci and HotSpot[1]. Unfortunately, this code was deleted by JDK-8298099 when moving the exception translation mechanism to VMSupport[2]. This causes the VM to crash when an OOME occurs while translating an exception from HotSpot to libjvmci. This PR revives the deleted code. This bug was found by running `test/jdk/java/util/concurrent/locks/Lock/OOMEInAQS.java` on libgraal. The fix now makes the test pass. [1] https://github.com/openjdk/jdk/commit/952e10055135613e8ea2b818a4f35842936f5633#diff-4d3a3b7e7e12e1d5b4cf3e4677d9e0de5e9df3bbf1bbfa0d8d43d12098d67dc4R222-R234 [2] https://github.com/openjdk/jdk/commit/8b69a2e434ad2fa3369079622b57afb973d5bd9a#diff-7292551772c27b7152a3333f03cbbad90a897c5e37c6a97d4026be835e6d8fe1R121-R125 ------------- Commit messages: - decodeAndThrowThrowable needs to handle error codes Changes: https://git.openjdk.org/jdk/pull/12857/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12857&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303577 Stats: 31 lines in 5 files changed: 22 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/12857.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12857/head:pull/12857 PR: https://git.openjdk.org/jdk/pull/12857 From naoto at openjdk.org Fri Mar 3 18:01:11 2023 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 3 Mar 2023 18:01:11 GMT Subject: RFR: 6453901: (cal) clean up sun.util.calendar classes In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 21:58:15 GMT, Justin Lu wrote: > This PR includes cleanup changes to the sun.util.calendar package only. > > The changes include removing unused methods, imports, adjusting incorrect links, and using newer syntax patterns. Since there are no plans to promote any of these classes to java.calendar, these unused methods can be removed. > > > Mach5: https://mach5.us.oracle.com/mdash/jobs/jclu-jdk2-20230228-2223-42671403 Nice cleanup for removing dead code. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.org/jdk/pull/12817 From alexey.ivanov at oracle.com Fri Mar 3 18:02:41 2023 From: alexey.ivanov at oracle.com (Aleksei Ivanov) Date: Fri, 3 Mar 2023 18:02:41 +0000 Subject: Testing no memory leak occurs via references Message-ID: Hello, In clientlibs, there's occasionally a need to verify an object isn't leaked. For this purpose, WeakReference or PhantomReference is used. Then, we need to make the reference object be cleared, so a GC cycle need to be triggered. The common approach is generating OutOfMemoryError, catching it and verifying whether the reference is cleared. Some tests use a utility method regtesthelpers/Util.generateOOME [1]. For example, these tests follow the above approach: https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/border/TestTitledBorderLeak.java https://github.com/openjdk/jdk/blob/master/test/jdk/java/awt/List/ListGarbageCollectionTest/AwtListGarbageCollectionTest.java The AwtListGarbageCollectionTest.java test started to fail pretty often in the end of January 2023. I followed a piece of advice provided in a JBS comment for JDK-8300727 [2] and replaced generating OOME with a simple call to System.gc() along with adding a loop for re-trying. The specification for System.gc() [3] mentions that this call can be ignored, which started a discussion in the PR #12594 [4] that System.gc() should not be used, at the very least without generating OOME in addition to invoking System.gc(). At the same time, many tests for Reference objects, such as ReferenceEnqueue.java [5] and PhantomReferentClearing.java [6], rely solely on System.gc. What would be your recommendation? Are there best practices in core-libs and hotspot for testing for memory leaks that clientlibs should follow? -- Regards, Alexey [1] https://github.com/openjdk/jdk/blob/29ee7c3b70ded8cd124ca5b4a38a2aee7c39068b/test/jdk/javax/swing/regtesthelpers/Util.java#L87 [2] https://bugs.openjdk.org/browse/JDK-8300727 [3] https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/System.html#gc() [4] https://github.com/openjdk/jdk/pull/12594 [5] https://github.com/openjdk/jdk/blob/f612dcfebea7ffd4390f833646ad45d6f0ebd04f/test/jdk/java/lang/ref/ReferenceEnqueue.java#L54-L60 [6] https://github.com/openjdk/jdk/blob/f612dcfebea7ffd4390f833646ad45d6f0ebd04f/test/jdk/java/lang/ref/PhantomReferentClearing.java#L85-L92 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lancea at openjdk.org Fri Mar 3 18:07:21 2023 From: lancea at openjdk.org (Lance Andersen) Date: Fri, 3 Mar 2023 18:07:21 GMT Subject: RFR: 6453901: (cal) clean up sun.util.calendar classes In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 21:58:15 GMT, Justin Lu wrote: > This PR includes cleanup changes to the sun.util.calendar package only. > > The changes include removing unused methods, imports, adjusting incorrect links, and using newer syntax patterns. Since there are no plans to promote any of these classes to java.calendar, these unused methods can be removed. > > > Mach5: https://mach5.us.oracle.com/mdash/jobs/jclu-jdk2-20230228-2223-42671403 Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12817 From alanb at openjdk.org Fri Mar 3 18:07:25 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 3 Mar 2023 18:07:25 GMT Subject: RFR: 8302590: Add String.indexOf(int ch, int fromIndex, int toIndex) [v7] In-Reply-To: References: Message-ID: <2KCrKNVtbO80vCNr-UVZ3TsVLGDsLcWdvstm2RZPHUk=.213cd7e0-4b28-4e2a-b94d-ae59ba0f67cc@github.com> On Thu, 2 Mar 2023 10:24:03 GMT, Raffaello Giulietti wrote: >> Add an `indexOf()` variant allowing to specify both a lower and an upper bound on the search. > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > 8302590: Add String.indexOf(int ch, int fromIndex, int toIndex) The latest version looks good. Thanks for going through the process of getting this to a good place. One minor comment is that the test should probably in the java/lang/String rather than the CompactString sub-directory. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.org/jdk/pull/12600 From kvn at openjdk.org Fri Mar 3 18:08:37 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 3 Mar 2023 18:08:37 GMT Subject: RFR: 8303577: [JVMCI] OOME causes crash while translating exceptions In-Reply-To: References: Message-ID: On Fri, 3 Mar 2023 15:40:01 GMT, Doug Simon wrote: > JDK-8297431 added code for special handling of OutOfMemoryError when translating an exception between libjvmci and HotSpot[1]. > Unfortunately, this code was deleted by JDK-8298099 when moving the exception translation mechanism to VMSupport[2]. > This causes the VM to crash when an OOME occurs while translating an exception from HotSpot to libjvmci. > This PR revives the deleted code. > > This bug was found by running `test/jdk/java/util/concurrent/locks/Lock/OOMEInAQS.java` on libgraal. The fix now makes the test pass. > > [1] https://github.com/openjdk/jdk/commit/952e10055135613e8ea2b818a4f35842936f5633#diff-4d3a3b7e7e12e1d5b4cf3e4677d9e0de5e9df3bbf1bbfa0d8d43d12098d67dc4R222-R234 > [2] https://github.com/openjdk/jdk/commit/8b69a2e434ad2fa3369079622b57afb973d5bd9a#diff-7292551772c27b7152a3333f03cbbad90a897c5e37c6a97d4026be835e6d8fe1R121-R125 Good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.org/jdk/pull/12857 From roger.riggs at oracle.com Fri Mar 3 18:25:55 2023 From: roger.riggs at oracle.com (Roger Riggs) Date: Fri, 3 Mar 2023 13:25:55 -0500 Subject: Testing no memory leak occurs via references In-Reply-To: References: Message-ID: Hi, There is test library class jdk.test.lib.util.ForceGC that is useful for that case. It uses a PhantomReference to detect that gc has been run. And it can be called with a function that can test for another condition. For an example, look at the tests that use ForceGC in test/jdk/... Regards, Roger On 3/3/23 1:02 PM, Aleksei Ivanov wrote: > Hello, > > In clientlibs, there's occasionally a need to verify an object isn't > leaked. For this purpose, WeakReference or PhantomReference is used. > > Then, we need to make the reference object be cleared, so a GC cycle > need to be triggered. The common approach is generating > OutOfMemoryError, catching it and verifying whether the reference is > cleared. > > Some tests use a utility method regtesthelpers/Util.generateOOME [1]. > > For example, these tests follow the above approach: > https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/border/TestTitledBorderLeak.java > https://github.com/openjdk/jdk/blob/master/test/jdk/java/awt/List/ListGarbageCollectionTest/AwtListGarbageCollectionTest.java > > > The AwtListGarbageCollectionTest.java test started to fail pretty > often in the end of January 2023. > > I followed a piece of advice provided in a JBS comment for JDK-8300727 > [2] and replaced generating OOME with a simple call to System.gc() > along with adding a loop for re-trying. > > The specification for System.gc() [3] mentions that this call can be > ignored, which started a discussion in the PR #12594 [4] that > System.gc() should not be used, at the very least without generating > OOME in addition to invoking System.gc(). > > At the same time, many tests for Reference objects, such as > ReferenceEnqueue.java [5] and PhantomReferentClearing.java [6], rely > solely on System.gc. > > > What would be your recommendation? Are there best practices in > core-libs and hotspot for testing for memory leaks that clientlibs > should follow? > > > -- > Regards, > Alexey > > [1] > https://github.com/openjdk/jdk/blob/29ee7c3b70ded8cd124ca5b4a38a2aee7c39068b/test/jdk/javax/swing/regtesthelpers/Util.java#L87 > [2] https://bugs.openjdk.org/browse/JDK-8300727 > [3] > https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/System.html#gc() > [4] https://github.com/openjdk/jdk/pull/12594 > [5] > https://github.com/openjdk/jdk/blob/f612dcfebea7ffd4390f833646ad45d6f0ebd04f/test/jdk/java/lang/ref/ReferenceEnqueue.java#L54-L60 > [6] > https://github.com/openjdk/jdk/blob/f612dcfebea7ffd4390f833646ad45d6f0ebd04f/test/jdk/java/lang/ref/PhantomReferentClearing.java#L85-L92 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rgiulietti at openjdk.org Fri Mar 3 18:29:20 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 3 Mar 2023 18:29:20 GMT Subject: RFR: 8302590: Add String.indexOf(int ch, int fromIndex, int toIndex) [v7] In-Reply-To: <2KCrKNVtbO80vCNr-UVZ3TsVLGDsLcWdvstm2RZPHUk=.213cd7e0-4b28-4e2a-b94d-ae59ba0f67cc@github.com> References: <2KCrKNVtbO80vCNr-UVZ3TsVLGDsLcWdvstm2RZPHUk=.213cd7e0-4b28-4e2a-b94d-ae59ba0f67cc@github.com> Message-ID: <0CHqtHEi81FZQrhps63oot7vVBGHpstPO1DhkucPISQ=.ee24e43a-f597-4046-a09d-47059ace180c@github.com> On Fri, 3 Mar 2023 18:04:11 GMT, Alan Bateman wrote: >> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: >> >> 8302590: Add String.indexOf(int ch, int fromIndex, int toIndex) > > The latest version looks good. Thanks for going through the process of getting this to a good place. One minor comment is that the test should probably in the java/lang/String rather than the CompactString sub-directory. @AlanBateman There's a `IndexOf.java` test file already in the `CompactString` folder, which is why the new test file is located there, side-by-side to the current one. Both classes extend class `CompactString`, also residing in that folder, to get access to `String` constants defined there. I have no problem in moving the new test file to the parent folder, but would like to understand more about the distinction between the two groups of tests. Could you expand a bit on this to help me getting a better picture? TIA ------------- PR: https://git.openjdk.org/jdk/pull/12600 From rriggs at openjdk.org Fri Mar 3 18:31:25 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 3 Mar 2023 18:31:25 GMT Subject: Integrated: JDK-8303587 Remove VMOutOfMemoryError001 test from the problem list after 8303198 In-Reply-To: References: Message-ID: On Fri, 3 Mar 2023 16:40:41 GMT, Roger Riggs wrote: > Remove VMOutOfMemoryException001.java from the problem list, after JDK-8303198. > > The logging of Runtime.exit interfered with out-of-memory exception handling in this test. > Making the logging more robust in JDK-8303198 by handling exceptions restores the conditions expected by this test. This pull request has now been integrated. Changeset: 99443142 Author: Roger Riggs URL: https://git.openjdk.org/jdk/commit/99443142cc8280a1fc896981ef3d0ac27365d035 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod 8303587: Remove VMOutOfMemoryError001 test from the problem list after 8303198 Reviewed-by: cjplummer ------------- PR: https://git.openjdk.org/jdk/pull/12859 From bpb at openjdk.org Fri Mar 3 18:41:17 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 3 Mar 2023 18:41:17 GMT Subject: Integrated: 8303175: (fs) Deprecate com.sun.nio.file.SensitivityWatchEventModifier for removal In-Reply-To: References: Message-ID: On Fri, 24 Feb 2023 18:23:06 GMT, Brian Burkhalter wrote: > Deprecate `SensitivityWatchEventModifier` for now instead of directly removing it as proposed in #12626. This pull request has now been integrated. Changeset: ae290541 Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/ae290541d17be77bbedf56a4592102ead4e4691e Stats: 10 lines in 1 file changed: 9 ins; 0 del; 1 mod 8303175: (fs) Deprecate com.sun.nio.file.SensitivityWatchEventModifier for removal Reviewed-by: lancea, alanb ------------- PR: https://git.openjdk.org/jdk/pull/12746 From alanb at openjdk.org Fri Mar 3 18:43:12 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 3 Mar 2023 18:43:12 GMT Subject: RFR: 8302590: Add String.indexOf(int ch, int fromIndex, int toIndex) [v7] In-Reply-To: <2KCrKNVtbO80vCNr-UVZ3TsVLGDsLcWdvstm2RZPHUk=.213cd7e0-4b28-4e2a-b94d-ae59ba0f67cc@github.com> References: <2KCrKNVtbO80vCNr-UVZ3TsVLGDsLcWdvstm2RZPHUk=.213cd7e0-4b28-4e2a-b94d-ae59ba0f67cc@github.com> Message-ID: On Fri, 3 Mar 2023 18:04:11 GMT, Alan Bateman wrote: >> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: >> >> 8302590: Add String.indexOf(int ch, int fromIndex, int toIndex) > > The latest version looks good. Thanks for going through the process of getting this to a good place. One minor comment is that the test should probably in the java/lang/String rather than the CompactString sub-directory. > @AlanBateman There's a `IndexOf.java` test file already in the `CompactString` folder, which is why the new test file is located there, side-by-side to the current one. Both classes extend class `CompactString`, also residing in that folder, to get access to `String` constants defined there. > > I have no problem in moving the new test file to the parent folder, but would like to understand more about the distinction between the two groups of tests. Could you expand a bit on this to help me getting a better picture? TIA String dates from JDK 1.0 and didn't historically have many tests except for some regression tests that accumulated along the way. Recent work on new String APIs (repeat, indent, ..) added to the tests in java/lang/String. The CompactString sub-directory is from the JEP 254 work in JDK 9 - it needed good tests to exercise all methods/cases. It might get onto someone radar sometime to do some consolidation and make it less confusing as to whether to put new tests. ------------- PR: https://git.openjdk.org/jdk/pull/12600 From jlaskey at openjdk.org Fri Mar 3 19:04:22 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 3 Mar 2023 19:04:22 GMT Subject: RFR: JDK-8302323 Add repeat methods to StringBuilder/StringBuffer [v8] In-Reply-To: References: Message-ID: > Add the ability to repeatedly append char and CharSequence data to StringBuilder/StringBuffer. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Expand test for StringBuffer and illegal code points ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12728/files - new: https://git.openjdk.org/jdk/pull/12728/files/7d3ecc77..1a77988b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12728&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12728&range=06-07 Stats: 568 lines in 3 files changed: 388 ins; 180 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12728.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12728/head:pull/12728 PR: https://git.openjdk.org/jdk/pull/12728 From albert.m.yang at oracle.com Fri Mar 3 19:16:51 2023 From: albert.m.yang at oracle.com (Albert Yang) Date: Fri, 3 Mar 2023 19:16:51 +0000 Subject: Testing no memory leak occurs via references In-Reply-To: References: Message-ID: I wonder if `WhiteBoxAPI` can be used if the goal is to trigger a (Full) GC cycle. An example is `whitebox.fullGC()` in `test/jdk/java/lang/ref/CleanerTest.java`. /Albert From jvernee at openjdk.org Fri Mar 3 19:32:07 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 3 Mar 2023 19:32:07 GMT Subject: RFR: 8303582: Reduce duplication in test code (mainline) Message-ID: Port of: https://github.com/openjdk/panama-foreign/pull/804 which reduces duplication in the test code by switching test value generation over to a common method in `NativeTestHelper`. ------------- Commit messages: - remove byteWidthOfPrimitive for now - 8302990: Reduce duplication in test code Changes: https://git.openjdk.org/jdk/pull/12856/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12856&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303582 Stats: 503 lines in 13 files changed: 138 ins; 272 del; 93 mod Patch: https://git.openjdk.org/jdk/pull/12856.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12856/head:pull/12856 PR: https://git.openjdk.org/jdk/pull/12856 From jvernee at openjdk.org Fri Mar 3 19:32:08 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 3 Mar 2023 19:32:08 GMT Subject: RFR: 8303582: Reduce duplication in test code (mainline) In-Reply-To: References: Message-ID: <-gALOnD6quJYoNpEg8ToxG5I2uVmJKJx14WB0bMp5Uw=.365fcf93-8897-4b08-b4a6-017202f8bd47@github.com> On Fri, 3 Mar 2023 15:08:01 GMT, Jorn Vernee wrote: > Port of: https://github.com/openjdk/panama-foreign/pull/804 which reduces duplication in the test code by switching test value generation over to a common method in `NativeTestHelper`. src/java.base/share/classes/jdk/internal/foreign/Utils.java line 224: > 222: * @param elements the structs' fields > 223: */ > 224: public static StructLayout computePaddedStructLayout(MemoryLayout... elements) { Note that this method is in `Utils` since we will also need it later for the fallback linker. ------------- PR: https://git.openjdk.org/jdk/pull/12856 From rriggs at openjdk.org Fri Mar 3 19:34:09 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 3 Mar 2023 19:34:09 GMT Subject: RFR: 8303392: Runtime.exec and ProcessBuilder.start should use System logger Message-ID: <-1i11ZrHHgzUbCSa_RXAcGKNfgtpdui--bltZ4Ujs2A=.f5f1a7e2-d3ec-4f64-9b1e-317ef2f24ef1@github.com> Runtime.exec and ProcessBuilder.start methods create a new operating system process with the program and arguments. Many applications configure a logging subsystem to monitor application events. Logging a process start message with the program, arguments, and stack trace can identify the caller and purpose. Logging the process start event is complementary to the process start event generated for JFR (Java Flight Recorder). ------------- Commit messages: - 8303392: Runtime.exec and ProcessBuilder.start should use System logger Changes: https://git.openjdk.org/jdk/pull/12862/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12862&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303392 Stats: 200 lines in 4 files changed: 199 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12862.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12862/head:pull/12862 PR: https://git.openjdk.org/jdk/pull/12862 From rgiulietti at openjdk.org Fri Mar 3 19:38:57 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 3 Mar 2023 19:38:57 GMT Subject: RFR: 8302590: Add String.indexOf(int ch, int fromIndex, int toIndex) [v8] In-Reply-To: References: Message-ID: > Add an `indexOf()` variant allowing to specify both a lower and an upper bound on the search. Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: git commit -m "8302590: Add String.indexOf(int ch, int fromIndex, int toIndex)" Moved and renamed test file to parent folder ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12600/files - new: https://git.openjdk.org/jdk/pull/12600/files/5bc1edb8..7007ec96 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12600&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12600&range=06-07 Stats: 426 lines in 2 files changed: 223 ins; 203 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12600.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12600/head:pull/12600 PR: https://git.openjdk.org/jdk/pull/12600 From rriggs at openjdk.org Fri Mar 3 20:27:53 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 3 Mar 2023 20:27:53 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v42] In-Reply-To: <9XP497xudeRhZKkIpxIgpbqT24eG8SCbfG6TelYtM3M=.f1ad5a76-798c-4e3d-b43b-a25a20210154@github.com> References: <9XP497xudeRhZKkIpxIgpbqT24eG8SCbfG6TelYtM3M=.f1ad5a76-798c-4e3d-b43b-a25a20210154@github.com> Message-ID: On Mon, 27 Feb 2023 12:47:03 GMT, Jim Laskey wrote: >> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Tighten up reporting of string template errors (fewer messages) src/java.base/share/classes/java/lang/template/ProcessorLinkage.java line 37: > 35: > 36: /** > 37: * Policies using this additional interface have the flexibility to specialize Since it is 'sealed' it may clarify the use to say "Builtin policies"... src/java.base/share/classes/java/lang/template/StringProcessor.java line 49: > 47: * @implNote Implementations using {@link StringProcessor} are equivalent to implementations using > 48: * {@code TemplateProcessor} or {@code ValidatingProcessor}, > 49: * however, StringProcessor is cleaner and easier to understand. Split into two sentences. Suggestion: * {@code TemplateProcessor} or {@code ValidatingProcessor}. * However, StringProcessor is cleaner and easier to understand. src/java.base/share/classes/java/lang/template/StringProcessor.java line 58: > 56: /** > 57: * Constructs a {@link String} based on the template fragments and values in the > 58: * supplied {@link StringTemplate} object. Some inconsistency in the use of link/linkplain and the capitalization of stringTemplate, the instance or the type. (As compared to TemplateProcessor.process(stringTemplate)) Suggestion: * supplied {@link StringTemplate} object. src/java.base/share/classes/java/util/FormatProcessor.java line 42: > 40: * {@link Formatter} specifications and values found in the {@link StringTemplate}. > 41: * Unlike {@link Formatter}, {@link FormatProcessor} uses the value from the > 42: * embedded expression that immediately follows, no whitespace, after the Suggestion: * embedded expression that immediately follows, without whitespace, the src/java.base/share/classes/java/util/FormatProcessor.java line 66: > 64: *

> 65: * {@link FormatProcessor} format specification uses and exceptions are the same as > 66: * those of {@link Formatter}. Suggestion: * The {@link FormatProcessor} format specification uses and exceptions are the same as * those of {@link Formatter}. src/java.base/share/classes/java/util/FormatProcessor.java line 80: > 78: * int x = 10; > 79: * int y = 20; > 80: * String result = thaiFMT."%d\{x} + %d\{y} = %d\{x + y}"; The inclusion of format specifiers that yield the same results as the default (%s) may mislead developers into thinking they need the format specifier. Making the examples look more complicated than necessary. Can the examples, show customized output. Suggestion: * String result = thaiFMT."%d{x} + %d{y} = %d{x + y}"; src/java.base/share/classes/java/util/FormatProcessor.java line 134: > 132: * format string from the fragments, gathers up the values and > 133: * evaluates the expression > 134: * {@code new Formatter(locale).format(format, values).toString()}. Should this be described using the "as if"... phrasing to avoid a literal requirement in the spec that is inflexible? src/java.base/share/classes/java/util/FormatProcessor.java line 175: > 173: * {@link FormatProcessor#FMT} ({@code static final FormatProcessor}). > 174: *

> 175: * Other {@link FormatProcessor} can be specialized if stored as static final. Suggestion: * Other {@link FormatProcessor}s can be specialized if stored as a static final. src/java.base/share/classes/java/util/FormatProcessor.java line 187: > 185: * @throws IllegalFormatException > 186: * If a format specifier contains an illegal syntax, a format > 187: * specifier that is incompatible with the given arguments, Suggestion: * specifier is incompatible with the given arguments, ------------- PR: https://git.openjdk.org/jdk/pull/10889 From rriggs at openjdk.org Fri Mar 3 20:32:10 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 3 Mar 2023 20:32:10 GMT Subject: RFR: 8302590: Add String.indexOf(int ch, int fromIndex, int toIndex) [v8] In-Reply-To: References: Message-ID: On Fri, 3 Mar 2023 19:38:57 GMT, Raffaello Giulietti wrote: >> Add an `indexOf()` variant allowing to specify both a lower and an upper bound on the search. > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > git commit -m "8302590: Add String.indexOf(int ch, int fromIndex, int toIndex)" > > Moved and renamed test file to parent folder Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12600 From rgiulietti at openjdk.org Fri Mar 3 20:54:29 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 3 Mar 2023 20:54:29 GMT Subject: Integrated: 8302590: Add String.indexOf(int ch, int fromIndex, int toIndex) In-Reply-To: References: Message-ID: On Thu, 16 Feb 2023 17:16:35 GMT, Raffaello Giulietti wrote: > Add an `indexOf()` variant allowing to specify both a lower and an upper bound on the search. This pull request has now been integrated. Changeset: 5b2e2e46 Author: Raffaello Giulietti URL: https://git.openjdk.org/jdk/commit/5b2e2e4695768a6bd8090fb9a6c342fcddcbb3fd Stats: 299 lines in 4 files changed: 282 ins; 4 del; 13 mod 8302590: Add String.indexOf(int ch, int fromIndex, int toIndex) Reviewed-by: rriggs, alanb ------------- PR: https://git.openjdk.org/jdk/pull/12600 From naoto at openjdk.org Fri Mar 3 20:59:07 2023 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 3 Mar 2023 20:59:07 GMT Subject: RFR: 8303440: The "ZonedDateTime.parse" may not accept the "UTC+XX" zone id Message-ID: This change is to fix a regression caused by the fix to [JDK-8234347](https://bugs.openjdk.org/browse/JDK-8234347). The previous fix was simply disabling offset-based parsing if the parser was text-based. Instead, check if it is an offset or not by explicitly comparing the character with '+'/'-' and continue offset parsing if it is. ------------- Commit messages: - 8303440: The "ZonedDateTime.parse" may not accept the "UTC+XX" zone id Changes: https://git.openjdk.org/jdk/pull/12868/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12868&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303440 Stats: 81 lines in 2 files changed: 79 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/12868.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12868/head:pull/12868 PR: https://git.openjdk.org/jdk/pull/12868 From naoto at openjdk.org Fri Mar 3 21:10:57 2023 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 3 Mar 2023 21:10:57 GMT Subject: RFR: 8303440: The "ZonedDateTime.parse" may not accept the "UTC+XX" zone id [v2] In-Reply-To: References: Message-ID: > This change is to fix a regression caused by the fix to [JDK-8234347](https://bugs.openjdk.org/browse/JDK-8234347). The previous fix was simply disabling offset-based parsing if the parser was text-based. Instead, check if it is an offset or not by explicitly comparing the character with '+'/'-' and continue offset parsing if it is. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: now() -> of() to avoid DST ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12868/files - new: https://git.openjdk.org/jdk/pull/12868/files/966b8f67..5cda8482 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12868&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12868&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/12868.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12868/head:pull/12868 PR: https://git.openjdk.org/jdk/pull/12868 From psandoz at openjdk.org Fri Mar 3 21:47:55 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Fri, 3 Mar 2023 21:47:55 GMT Subject: RFR: 8294982: Implementation of Classfile API [v43] In-Reply-To: References: Message-ID: On Fri, 3 Mar 2023 16:39:41 GMT, Adam Sotona wrote: >> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. >> >> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. >> >> Classfile API development is tracked at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch >> >> Development branch of consolidated JDK class files parsing, generating, and transforming is at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch >> >> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. >> >> Please take you time to review this non-trivial JDK addition. >> >> Thank you, >> Adam > > Adam Sotona has updated the pull request incrementally with three additional commits since the last revision: > > - fixed AccessFlags javadoc > - TransformImpl.FakeXyzTransform renamed to UnresolvedXyzTransform > - removed obsolete generic parameter from AbstractDirectBuilder src/java.base/share/classes/jdk/internal/classfile/impl/AbstractInstruction.java line 683: > 681: public UnboundInstruction(Opcode op, int size) { > 682: super(op, size); > 683: } Unused? ------------- PR: https://git.openjdk.org/jdk/pull/10982 From psandoz at openjdk.org Fri Mar 3 21:52:51 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Fri, 3 Mar 2023 21:52:51 GMT Subject: RFR: 8294982: Implementation of Classfile API [v43] In-Reply-To: References: Message-ID: On Fri, 3 Mar 2023 16:39:41 GMT, Adam Sotona wrote: >> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. >> >> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. >> >> Classfile API development is tracked at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch >> >> Development branch of consolidated JDK class files parsing, generating, and transforming is at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch >> >> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. >> >> Please take you time to review this non-trivial JDK addition. >> >> Thank you, >> Adam > > Adam Sotona has updated the pull request incrementally with three additional commits since the last revision: > > - fixed AccessFlags javadoc > - TransformImpl.FakeXyzTransform renamed to UnresolvedXyzTransform > - removed obsolete generic parameter from AbstractDirectBuilder src/java.base/share/classes/jdk/internal/classfile/impl/AnnotationReader.java line 99: > 97: } > 98: > 99: public static List> readParameterAnnotations(ClassReader classReader, int p, boolean isVisible) { Parameter `isVisible` is unused, but method is called with true/false values. ------------- PR: https://git.openjdk.org/jdk/pull/10982 From psandoz at openjdk.org Fri Mar 3 22:00:54 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Fri, 3 Mar 2023 22:00:54 GMT Subject: RFR: 8294982: Implementation of Classfile API [v43] In-Reply-To: References: Message-ID: On Fri, 3 Mar 2023 16:39:41 GMT, Adam Sotona wrote: >> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. >> >> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. >> >> Classfile API development is tracked at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch >> >> Development branch of consolidated JDK class files parsing, generating, and transforming is at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch >> >> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. >> >> Please take you time to review this non-trivial JDK addition. >> >> Thank you, >> Adam > > Adam Sotona has updated the pull request incrementally with three additional commits since the last revision: > > - fixed AccessFlags javadoc > - TransformImpl.FakeXyzTransform renamed to UnresolvedXyzTransform > - removed obsolete generic parameter from AbstractDirectBuilder src/java.base/share/classes/jdk/internal/classfile/impl/AttributeHolder.java line 73: > 71: if (a.attributeMapper() == am) > 72: iterator.remove(); > 73: } Suggestion: attributes.removeIf(a -> a.attributeMappter() == am); But presumably use an inner class instead. I can understand because of that if you want to keep the existing code instead. src/java.base/share/classes/jdk/internal/classfile/impl/AttributeHolder.java line 76: > 74: } > 75: > 76: List> attributes() { Unused ------------- PR: https://git.openjdk.org/jdk/pull/10982 From psandoz at openjdk.org Fri Mar 3 22:13:10 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Fri, 3 Mar 2023 22:13:10 GMT Subject: RFR: 8294982: Implementation of Classfile API [v43] In-Reply-To: References: Message-ID: <26xE8eQEqKMRahtSKZZFgt2VBb5M2dn98Wa91mttUvo=.36cebc7b-ec24-45f5-adab-25dff7987835@github.com> On Fri, 3 Mar 2023 16:39:41 GMT, Adam Sotona wrote: >> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. >> >> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. >> >> Classfile API development is tracked at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch >> >> Development branch of consolidated JDK class files parsing, generating, and transforming is at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch >> >> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. >> >> Please take you time to review this non-trivial JDK addition. >> >> Thank you, >> Adam > > Adam Sotona has updated the pull request incrementally with three additional commits since the last revision: > > - fixed AccessFlags javadoc > - TransformImpl.FakeXyzTransform renamed to UnresolvedXyzTransform > - removed obsolete generic parameter from AbstractDirectBuilder src/java.base/share/classes/jdk/internal/classfile/impl/BootstrapMethodEntryImpl.java line 83: > 81: } > 82: else > 83: return false; Suggestion: return obj instanceof BootstrapMethodEntry e && e.bootstrapMethod().equals(handle) && e.arguments().equals(arguments); ? I am uncertain about the use of reference equality, since it indicates an instance is only equal to itself? src/java.base/share/classes/jdk/internal/classfile/impl/BootstrapMethodEntryImpl.java line 91: > 89: for (LoadableConstantEntry a : arguments) { > 90: hash = 31 * hash + a.hashCode(); > 91: } Suggestion: hash = 31 * hash + arguments.hashCode(); ------------- PR: https://git.openjdk.org/jdk/pull/10982 From psandoz at openjdk.org Fri Mar 3 22:19:06 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Fri, 3 Mar 2023 22:19:06 GMT Subject: RFR: 8294982: Implementation of Classfile API [v43] In-Reply-To: References: Message-ID: On Fri, 3 Mar 2023 16:39:41 GMT, Adam Sotona wrote: >> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. >> >> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. >> >> Classfile API development is tracked at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch >> >> Development branch of consolidated JDK class files parsing, generating, and transforming is at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch >> >> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. >> >> Please take you time to review this non-trivial JDK addition. >> >> Thank you, >> Adam > > Adam Sotona has updated the pull request incrementally with three additional commits since the last revision: > > - fixed AccessFlags javadoc > - TransformImpl.FakeXyzTransform renamed to UnresolvedXyzTransform > - removed obsolete generic parameter from AbstractDirectBuilder src/java.base/share/classes/jdk/internal/classfile/impl/BufferedMethodBuilder.java line 54: > 52: private final List elements = new ArrayList<>(); > 53: private final SplitConstantPool constantPool; > 54: private final ClassEntry thisClass; Unused. Can be removed as can the associated constructor parameter. ------------- PR: https://git.openjdk.org/jdk/pull/10982 From psandoz at openjdk.org Fri Mar 3 22:29:05 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Fri, 3 Mar 2023 22:29:05 GMT Subject: RFR: 8294982: Implementation of Classfile API [v43] In-Reply-To: References: Message-ID: <9XwE1ABm8VZRQH0cPg21c9uZz-st4o4LupIJ9w_SjzA=.6244d818-462d-4275-a650-57bb435f5873@github.com> On Fri, 3 Mar 2023 16:39:41 GMT, Adam Sotona wrote: >> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. >> >> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. >> >> Classfile API development is tracked at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch >> >> Development branch of consolidated JDK class files parsing, generating, and transforming is at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch >> >> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. >> >> Please take you time to review this non-trivial JDK addition. >> >> Thank you, >> Adam > > Adam Sotona has updated the pull request incrementally with three additional commits since the last revision: > > - fixed AccessFlags javadoc > - TransformImpl.FakeXyzTransform renamed to UnresolvedXyzTransform > - removed obsolete generic parameter from AbstractDirectBuilder src/java.base/share/classes/jdk/internal/classfile/impl/ClassPrinterImpl.java line 570: > 568: fieldToTree(f, verbosity)))) > 569: .with(new ListNodeImpl(BLOCK, "methods", clm.methods().stream().map(mm -> > 570: (Node)methodToTree(mm, verbosity)))); Suggestion: methodToTree(mm, verbosity)))); (Note as i go through the code i am looking at the IDEs report of problems and making note as comments. Likely be more productive for you to do that directly.) ------------- PR: https://git.openjdk.org/jdk/pull/10982 From bpb at openjdk.org Fri Mar 3 22:49:23 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 3 Mar 2023 22:49:23 GMT Subject: RFR: JDK-8302027: Port fdlibm trig functions (sin, cos, tan) to Java [v4] In-Reply-To: References: Message-ID: On Fri, 3 Mar 2023 06:56:57 GMT, Joe Darcy wrote: >> Last and certainly not least in the port of FDLIBM to Java, the transcendental methods for sin, cos, and tan. >> >> Some more tests are to be written in the StrictMath directory to verify that the StrictMath algorihtm for sin/cos/tan is being used rather than a different one. However, I wanted to get the rest of the change out for review first. >> >> The sin/cos/tan methods are grouped together since they share the same argument reduction logic. Argument reduction is the process of mapping an argument of a function to an argument in a restricted range (and possibly returning some function of the reduced argument). For sin, cos, and tan, since they are fundamentally periodic with respect to a multiple of pi, argument reduction is done to find the remainder of the original argument with respect to pi/2. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Add more tests. Approved for integration once other reviewers concerns have been addressed. ------------- Marked as reviewed by bpb (Reviewer). PR: https://git.openjdk.org/jdk/pull/12800 From stuart.marks at oracle.com Fri Mar 3 22:54:54 2023 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 3 Mar 2023 14:54:54 -0800 Subject: Testing no memory leak occurs via references In-Reply-To: References: Message-ID: <5e0f77c6-446b-a533-0783-db7f554861c3@oracle.com> As Roger mentioned, there is a ForceGC utility in the test library: ??? test/lib/jdk/test/lib/util/ForceGC.java and it's used in a variety of places in the core libs tests. Essentially it sets up a PhantomReference and a ReferenceQueue and runs System.gc() in a loop. I'd strongly recommend using this in preference to allocating a lot of memory in order to provoke OutOfMemoryError. That technique has historically been a cause of test flakiness, and it still is, as you've discovered. There is also MemoryMXBean.gc(), which does the same thing System.gc() does -- it calls Runtime.getRuntime().gc(). It's true that System.gc() may sometimes be ignored -- for instance if Epsilon GC is enabled -- but for practical purposes, on Hotspot using a standard collector, calling it will eventually cause garbage collection and reference processing. If at some point the behavior provided by System.gc() is inadequate for our testing, we'll need to plumb a JDK-specific interface that has stronger semantics, and then convert ForceGC to use it so that individual tests won't have to be updated. There are still some tests that allocate lots of memory in order to provoke OOME and consequently reference processing. They probably need to be run in /othervm mode in order to set custom heap sizes and to avoid interfering with other tests. It would be interesting to see if those could be adjusted to use something ForceGC so that they can share the JVM with other tests and also avoid allocating lots of memory. s'marks On 3/3/23 10:02 AM, Aleksei Ivanov wrote: > Hello, > > In clientlibs, there's occasionally a need to verify an object isn't leaked. For > this purpose, WeakReference or PhantomReference is used. > > Then, we need to make the reference object be cleared, so a GC cycle need to be > triggered. The common approach is generating OutOfMemoryError, catching it and > verifying whether the reference is cleared. > > Some tests use a utility method regtesthelpers/Util.generateOOME [1]. > > For example, these tests follow the above approach: > https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/border/TestTitledBorderLeak.java > https://github.com/openjdk/jdk/blob/master/test/jdk/java/awt/List/ListGarbageCollectionTest/AwtListGarbageCollectionTest.java > > > The AwtListGarbageCollectionTest.java test started to fail pretty often in the end > of January 2023. > > I followed a piece of advice provided in a JBS comment for JDK-8300727 [2] and > replaced generating OOME with a simple call to System.gc() along with adding a > loop for re-trying. > > The specification for System.gc() [3] mentions that this call can be ignored, > which started a discussion in the PR #12594 [4] that System.gc() should not be > used, at the very least without generating OOME in addition to invoking System.gc(). > > At the same time, many tests for Reference objects, such as ReferenceEnqueue.java > [5] and PhantomReferentClearing.java [6], rely solely on System.gc. > > > What would be your recommendation? Are there best practices in core-libs and > hotspot for testing for memory leaks that clientlibs should follow? > > > -- > Regards, > Alexey > > [1] > https://github.com/openjdk/jdk/blob/29ee7c3b70ded8cd124ca5b4a38a2aee7c39068b/test/jdk/javax/swing/regtesthelpers/Util.java#L87 > [2] https://bugs.openjdk.org/browse/JDK-8300727 > [3] > https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/System.html#gc() > [4] https://github.com/openjdk/jdk/pull/12594 > [5] > https://github.com/openjdk/jdk/blob/f612dcfebea7ffd4390f833646ad45d6f0ebd04f/test/jdk/java/lang/ref/ReferenceEnqueue.java#L54-L60 > [6] > https://github.com/openjdk/jdk/blob/f612dcfebea7ffd4390f833646ad45d6f0ebd04f/test/jdk/java/lang/ref/PhantomReferentClearing.java#L85-L92 -------------- next part -------------- An HTML attachment was scrubbed... URL: From psandoz at openjdk.org Fri Mar 3 23:08:00 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Fri, 3 Mar 2023 23:08:00 GMT Subject: RFR: 8294982: Implementation of Classfile API [v43] In-Reply-To: References: Message-ID: On Fri, 3 Mar 2023 16:39:41 GMT, Adam Sotona wrote: >> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. >> >> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. >> >> Classfile API development is tracked at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch >> >> Development branch of consolidated JDK class files parsing, generating, and transforming is at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch >> >> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. >> >> Please take you time to review this non-trivial JDK addition. >> >> Thank you, >> Adam > > Adam Sotona has updated the pull request incrementally with three additional commits since the last revision: > > - fixed AccessFlags javadoc > - TransformImpl.FakeXyzTransform renamed to UnresolvedXyzTransform > - removed obsolete generic parameter from AbstractDirectBuilder src/java.base/share/classes/jdk/internal/classfile/impl/CodeImpl.java line 52: > 50: static final Instruction[] SINGLETON_INSTRUCTIONS = new Instruction[256]; > 51: > 52: static { Can we loop through all `Opcode` values filter for `sizeIfFixed == 1` and switch on the kind? If so that would avoid the need for explicit lists and simplify the code. src/java.base/share/classes/jdk/internal/classfile/impl/EntryMap.java line 176: > 174: } > 175: > 176: public static long nextPowerOfTwo( long x ) { If you like you can change the implementation to be: x = -1 >>> Long.numberOfLeadingZeros(x - 1); return x + 1; See `ConcurrentHashMap`. src/java.base/share/classes/jdk/internal/classfile/impl/Util.java line 84: > 82: } > 83: } > 84: } Suggestion: loop: for (int i = 1; i < type.length(); ++i) { switch (type.charAt(i)) { case '[': bs.set(i); while (type.charAt(++i) == '[') ; if (type.charAt(i) == 'L') { while (type.charAt(++i) != ';') ; } break; case ')': break loop; default: bs.set(i); if (type.charAt(i) == 'L') { while (type.charAt(++i) != ';') ; } } } ------------- PR: https://git.openjdk.org/jdk/pull/10982 From psandoz at openjdk.org Fri Mar 3 23:15:56 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Fri, 3 Mar 2023 23:15:56 GMT Subject: RFR: 8294982: Implementation of Classfile API [v43] In-Reply-To: References: Message-ID: <2sq9xOJ5ZPAgrWj9cBR1wRdGhHdIteZh8FkXratspQs=.3b804f36-2531-4504-b274-3237b84dfdbd@github.com> On Fri, 3 Mar 2023 16:39:41 GMT, Adam Sotona wrote: >> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. >> >> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. >> >> Classfile API development is tracked at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch >> >> Development branch of consolidated JDK class files parsing, generating, and transforming is at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch >> >> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. >> >> Please take you time to review this non-trivial JDK addition. >> >> Thank you, >> Adam > > Adam Sotona has updated the pull request incrementally with three additional commits since the last revision: > > - fixed AccessFlags javadoc > - TransformImpl.FakeXyzTransform renamed to UnresolvedXyzTransform > - removed obsolete generic parameter from AbstractDirectBuilder src/java.base/share/classes/jdk/internal/classfile/impl/Util.java line 161: > 159: var desc = cd.descriptorString(); > 160: return switch (desc.charAt(0)) { > 161: case '[' -> desc; Is this correct? Arrays don't have an internal name. ------------- PR: https://git.openjdk.org/jdk/pull/10982 From psandoz at openjdk.org Fri Mar 3 23:49:46 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Fri, 3 Mar 2023 23:49:46 GMT Subject: RFR: 8294982: Implementation of Classfile API [v43] In-Reply-To: References: Message-ID: On Fri, 3 Mar 2023 16:39:41 GMT, Adam Sotona wrote: >> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. >> >> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. >> >> Classfile API development is tracked at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch >> >> Development branch of consolidated JDK class files parsing, generating, and transforming is at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch >> >> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. >> >> Please take you time to review this non-trivial JDK addition. >> >> Thank you, >> Adam > > Adam Sotona has updated the pull request incrementally with three additional commits since the last revision: > > - fixed AccessFlags javadoc > - TransformImpl.FakeXyzTransform renamed to UnresolvedXyzTransform > - removed obsolete generic parameter from AbstractDirectBuilder This is a significant amount of work over a long period of time. Well done to all involved. Initially it's easy to get overwhelmed with the quantity of new classes. There are lots of "things" in a classfile and to properly model a classfile there will naturally be lots of classes for those "things". It's all very logically structured and very disciplined. For me the most powerful aspect of the design is that of the builder, which can be combined with a flatmap transformation and pattern matching. A clean, functional, and immutable design. When transforming a classfile the developer has a choice to apply composed transformations to a stream of elements or obtain a list of all elements and apply more globally (perhaps building up a transformation plan that is then applied to the stream), depending on their needs. It's slightly awkward that composed transformers (resulting from `andThen` and `ofStateful`) cannot be operated on and the resolved artifact is exposed, but i don't think anyone will likely notice given the usage. (I cannot off the top of my head suggest anything better. Maybe as this soaks internally new ideas emerge.) ------------- Marked as reviewed by psandoz (Reviewer). PR: https://git.openjdk.org/jdk/pull/10982 From jvernee at openjdk.org Fri Mar 3 23:53:24 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 3 Mar 2023 23:53:24 GMT Subject: RFR: 8303604: Passing by-value structs whose size is not power of 2 doesn't work on all platforms (mainline) Message-ID: Port of: https://github.com/openjdk/panama-foreign/pull/806 which fixes an issue with passing structs whose size is not a power of two on SysV and AArch64 platforms. ------------- Depends on: https://git.openjdk.org/jdk/pull/12856 Commit messages: - 8303017: Passing by-value structs whose size is not power of 2 doesn't work on all platforms Changes: https://git.openjdk.org/jdk/pull/12863/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12863&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303604 Stats: 705 lines in 11 files changed: 652 ins; 2 del; 51 mod Patch: https://git.openjdk.org/jdk/pull/12863.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12863/head:pull/12863 PR: https://git.openjdk.org/jdk/pull/12863 From mcimadamore at openjdk.org Sat Mar 4 00:11:12 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Sat, 4 Mar 2023 00:11:12 GMT Subject: RFR: 8303604: Passing by-value structs whose size is not power of 2 doesn't work on all platforms (mainline) In-Reply-To: References: Message-ID: On Fri, 3 Mar 2023 19:27:24 GMT, Jorn Vernee wrote: > Port of: https://github.com/openjdk/panama-foreign/pull/806 which fixes an issue with passing structs whose size is not a power of two on SysV and AArch64 platforms. Looks good (already reviewed on Panama repo) ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.org/jdk/pull/12863 From iris at openjdk.org Sat Mar 4 00:27:12 2023 From: iris at openjdk.org (Iris Clark) Date: Sat, 4 Mar 2023 00:27:12 GMT Subject: RFR: 8303440: The "ZonedDateTime.parse" may not accept the "UTC+XX" zone id [v2] In-Reply-To: References: Message-ID: <7MUDfOoFZHqhXDwn_VQ7wTxIIDqeQEwtSliHgzGDtX8=.c487aca5-6858-4fdf-99cc-c76421feb2d0@github.com> On Fri, 3 Mar 2023 21:10:57 GMT, Naoto Sato wrote: >> This change is to fix a regression caused by the fix to [JDK-8234347](https://bugs.openjdk.org/browse/JDK-8234347). The previous fix was simply disabling offset-based parsing if the parser was text-based. Instead, check if it is an offset or not by explicitly comparing the character with '+'/'-' and continue offset parsing if it is. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > now() -> of() to avoid DST Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12868 From jpai at openjdk.org Sat Mar 4 01:40:06 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 4 Mar 2023 01:40:06 GMT Subject: RFR: 8303440: The "ZonedDateTime.parse" may not accept the "UTC+XX" zone id [v2] In-Reply-To: References: Message-ID: On Fri, 3 Mar 2023 21:10:57 GMT, Naoto Sato wrote: >> This change is to fix a regression caused by the fix to [JDK-8234347](https://bugs.openjdk.org/browse/JDK-8234347). The previous fix was simply disabling offset-based parsing if the parser was text-based. Instead, check if it is an offset or not by explicitly comparing the character with '+'/'-' and continue offset parsing if it is. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > now() -> of() to avoid DST test/jdk/java/time/test/java/time/format/TestUTCParse.java line 27: > 25: * @modules jdk.localedata > 26: * @bug 8303440 > 27: * @summary Test parsing "UTC-XX:XX" text works correctly Hello Naoto, I haven't tried it, but without a `@run testng` instruction, does jtreg have the ability to auto infer this as a testng testcase? test/jdk/java/time/test/java/time/format/TestUTCParse.java line 48: > 46: // Assuming CLDR's SHORT name for "America/Los_Angeles" > 47: // produces "UTC\u212208:00" > 48: System.setProperty("java.locale.providers", "CLDR"); Since this updates a system property (that's recognized by code even outside of this test), perhaps we should use `@run testng/othervm` to prevent interfering with other tests? ------------- PR: https://git.openjdk.org/jdk/pull/12868 From jpai at openjdk.org Sat Mar 4 01:44:14 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 4 Mar 2023 01:44:14 GMT Subject: RFR: 8303440: The "ZonedDateTime.parse" may not accept the "UTC+XX" zone id [v2] In-Reply-To: References: Message-ID: <_c06I5fjMUnVswxoFmSD-Myn6XWgZQzJZtCNo3uDtaE=.b613cc1f-2728-4334-9d56-20a711aed12a@github.com> On Fri, 3 Mar 2023 21:10:57 GMT, Naoto Sato wrote: >> This change is to fix a regression caused by the fix to [JDK-8234347](https://bugs.openjdk.org/browse/JDK-8234347). The previous fix was simply disabling offset-based parsing if the parser was text-based. Instead, check if it is an offset or not by explicitly comparing the character with '+'/'-' and continue offset parsing if it is. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > now() -> of() to avoid DST test/jdk/java/time/test/java/time/format/TestUTCParse.java line 63: > 61: public void testUTCShortNameRoundTrip() { > 62: var fmt = DateTimeFormatter.ofPattern("z", Locale.FRANCE); > 63: var now = ZonedDateTime.of(2023, 3, 3, 0, 0, 0, 0, ZoneId.of("America/Los_Angeles")); Nit, this is no longer `now`. Should it renamed to avoid confusion? ------------- PR: https://git.openjdk.org/jdk/pull/12868 From naoto at openjdk.org Sat Mar 4 02:22:39 2023 From: naoto at openjdk.org (Naoto Sato) Date: Sat, 4 Mar 2023 02:22:39 GMT Subject: RFR: 8303440: The "ZonedDateTime.parse" may not accept the "UTC+XX" zone id [v3] In-Reply-To: References: Message-ID: > This change is to fix a regression caused by the fix to [JDK-8234347](https://bugs.openjdk.org/browse/JDK-8234347). The previous fix was simply disabling offset-based parsing if the parser was text-based. Instead, check if it is an offset or not by explicitly comparing the character with '+'/'-' and continue offset parsing if it is. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: now -> zdt ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12868/files - new: https://git.openjdk.org/jdk/pull/12868/files/5cda8482..e61d4fc8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12868&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12868&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/12868.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12868/head:pull/12868 PR: https://git.openjdk.org/jdk/pull/12868 From naoto at openjdk.org Sat Mar 4 02:22:39 2023 From: naoto at openjdk.org (Naoto Sato) Date: Sat, 4 Mar 2023 02:22:39 GMT Subject: RFR: 8303440: The "ZonedDateTime.parse" may not accept the "UTC+XX" zone id [v2] In-Reply-To: References: Message-ID: <_6lBAijzJqHagDhACqUPbhIjcrRDt6TCFDKSQYLYtbM=.70a6ec61-44e4-4753-a908-5243f9a44d79@github.com> On Sat, 4 Mar 2023 01:36:11 GMT, Jaikiran Pai wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> now() -> of() to avoid DST > > test/jdk/java/time/test/java/time/format/TestUTCParse.java line 27: > >> 25: * @modules jdk.localedata >> 26: * @bug 8303440 >> 27: * @summary Test parsing "UTC-XX:XX" text works correctly > > Hello Naoto, I haven't tried it, but without a `@run testng` instruction, does jtreg have the ability to auto infer this as a testng testcase? Thanks for the review, Jai! The default test behavior under `java/time` directory is defined in `java/time/test/TEST.properties` file, where it directs they are run using `TestNG`. > test/jdk/java/time/test/java/time/format/TestUTCParse.java line 48: > >> 46: // Assuming CLDR's SHORT name for "America/Los_Angeles" >> 47: // produces "UTC\u212208:00" >> 48: System.setProperty("java.locale.providers", "CLDR"); > > Since this updates a system property (that's recognized by code even outside of this test), perhaps we should use `@run testng/othervm` to prevent interfering with other tests? And the `TEST.properties` directs tests to be run under `othervm` mode. > test/jdk/java/time/test/java/time/format/TestUTCParse.java line 63: > >> 61: public void testUTCShortNameRoundTrip() { >> 62: var fmt = DateTimeFormatter.ofPattern("z", Locale.FRANCE); >> 63: var now = ZonedDateTime.of(2023, 3, 3, 0, 0, 0, 0, ZoneId.of("America/Los_Angeles")); > > Nit, this is no longer `now`. Should it renamed to avoid confusion? Good catch. Modified. ------------- PR: https://git.openjdk.org/jdk/pull/12868 From jpai at openjdk.org Sat Mar 4 05:00:11 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 4 Mar 2023 05:00:11 GMT Subject: RFR: 8303440: The "ZonedDateTime.parse" may not accept the "UTC+XX" zone id [v3] In-Reply-To: References: Message-ID: On Sat, 4 Mar 2023 02:22:39 GMT, Naoto Sato wrote: >> This change is to fix a regression caused by the fix to [JDK-8234347](https://bugs.openjdk.org/browse/JDK-8234347). The previous fix was simply disabling offset-based parsing if the parser was text-based. Instead, check if it is an offset or not by explicitly comparing the character with '+'/'-' and continue offset parsing if it is. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > now -> zdt Marked as reviewed by jpai (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12868 From jpai at openjdk.org Sat Mar 4 05:00:13 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 4 Mar 2023 05:00:13 GMT Subject: RFR: 8303440: The "ZonedDateTime.parse" may not accept the "UTC+XX" zone id [v2] In-Reply-To: <_6lBAijzJqHagDhACqUPbhIjcrRDt6TCFDKSQYLYtbM=.70a6ec61-44e4-4753-a908-5243f9a44d79@github.com> References: <_6lBAijzJqHagDhACqUPbhIjcrRDt6TCFDKSQYLYtbM=.70a6ec61-44e4-4753-a908-5243f9a44d79@github.com> Message-ID: On Sat, 4 Mar 2023 02:18:37 GMT, Naoto Sato wrote: >> test/jdk/java/time/test/java/time/format/TestUTCParse.java line 48: >> >>> 46: // Assuming CLDR's SHORT name for "America/Los_Angeles" >>> 47: // produces "UTC\u212208:00" >>> 48: System.setProperty("java.locale.providers", "CLDR"); >> >> Since this updates a system property (that's recognized by code even outside of this test), perhaps we should use `@run testng/othervm` to prevent interfering with other tests? > > And the `TEST.properties` directs tests to be run under `othervm` mode. Thank you Naoto for that detail, I wasn't aware of it. ------------- PR: https://git.openjdk.org/jdk/pull/12868 From darcy at openjdk.org Sat Mar 4 05:16:35 2023 From: darcy at openjdk.org (Joe Darcy) Date: Sat, 4 Mar 2023 05:16:35 GMT Subject: RFR: JDK-8302027: Port fdlibm trig functions (sin, cos, tan) to Java [v5] In-Reply-To: References: Message-ID: > Last and certainly not least in the port of FDLIBM to Java, the transcendental methods for sin, cos, and tan. > > Some more tests are to be written in the StrictMath directory to verify that the StrictMath algorihtm for sin/cos/tan is being used rather than a different one. However, I wanted to get the rest of the change out for review first. > > The sin/cos/tan methods are grouped together since they share the same argument reduction logic. Argument reduction is the process of mapping an argument of a function to an argument in a restricted range (and possibly returning some function of the reduced argument). For sin, cos, and tan, since they are fundamentally periodic with respect to a multiple of pi, argument reduction is done to find the remainder of the original argument with respect to pi/2. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Add test cases with Math and StrictMath differ on a given input. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12800/files - new: https://git.openjdk.org/jdk/pull/12800/files/b0cff650..20a9512d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12800&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12800&range=03-04 Stats: 87 lines in 1 file changed: 87 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12800.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12800/head:pull/12800 PR: https://git.openjdk.org/jdk/pull/12800 From darcy at openjdk.org Sat Mar 4 05:17:03 2023 From: darcy at openjdk.org (Joe Darcy) Date: Sat, 4 Mar 2023 05:17:03 GMT Subject: RFR: JDK-8302027: Port fdlibm trig functions (sin, cos, tan) to Java [v4] In-Reply-To: References: Message-ID: <71cSH1_LEdPk7OKWtBZqc3jj3NYFZ-XDFxRM1OncG64=.6640aca0-29d0-43bd-846c-3cf68d03f170@github.com> On Fri, 3 Mar 2023 06:56:57 GMT, Joe Darcy wrote: >> Last and certainly not least in the port of FDLIBM to Java, the transcendental methods for sin, cos, and tan. >> >> Some more tests are to be written in the StrictMath directory to verify that the StrictMath algorihtm for sin/cos/tan is being used rather than a different one. However, I wanted to get the rest of the change out for review first. >> >> The sin/cos/tan methods are grouped together since they share the same argument reduction logic. Argument reduction is the process of mapping an argument of a function to an argument in a restricted range (and possibly returning some function of the reduced argument). For sin, cos, and tan, since they are fundamentally periodic with respect to a multiple of pi, argument reduction is done to find the remainder of the original argument with respect to pi/2. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Add more tests. > Added tests cases where the different implementation of trig function T differ in at least one implementation of Math.T. ------------- PR: https://git.openjdk.org/jdk/pull/12800 From rgiulietti at openjdk.org Sat Mar 4 10:30:31 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Sat, 4 Mar 2023 10:30:31 GMT Subject: RFR: 8302987: Add uniform and spatially equidistributed bounded float/double streams to RandomGenerator [v5] In-Reply-To: <8B2_dePA34zyndM7SzuG6sanXNQmbge8DCIOIfpnTLs=.81cb4f5b-e3d0-4352-8209-eb1ac6197126@github.com> References: <8B2_dePA34zyndM7SzuG6sanXNQmbge8DCIOIfpnTLs=.81cb4f5b-e3d0-4352-8209-eb1ac6197126@github.com> Message-ID: > The `default` method `nextDouble(double origin, double bound)` in `java.util.random.RandomGenerator` aims at generating a uniformly and spatially equidistributed random `double` in the left-closed and right-open range [`origin`, `bound`). It does so by applying the affine transform `origin + (bound - origin) * r` to a uniformly and spatially equidistributed random `double` `r` in the range [0, 1). > > Since floating-point arithmetic suffers from small but noticeable rounding errors, this ends up slightly deforming the distribution of `r` when applying the affine transform. Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: 8302987: Add uniform and spatially equidistributed bounded float/double streams to RandomGenerator Inlining of private method and renaming the public one ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12719/files - new: https://git.openjdk.org/jdk/pull/12719/files/a38cb827..7d313c97 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12719&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12719&range=03-04 Stats: 86 lines in 1 file changed: 39 ins; 42 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/12719.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12719/head:pull/12719 PR: https://git.openjdk.org/jdk/pull/12719 From thomas.schatzl at oracle.com Sat Mar 4 13:34:07 2023 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Sat, 4 Mar 2023 14:34:07 +0100 Subject: Testing no memory leak occurs via references In-Reply-To: References: Message-ID: <06426b1a-b0f9-5700-84f2-a10bdd4086f0@oracle.com> Hi, On 03.03.23 19:02, Aleksei Ivanov wrote: > Hello, > > In clientlibs, there's occasionally a need to verify an object isn't > leaked. For this purpose, WeakReference or PhantomReference is used. > > Then, we need to make the reference object be cleared, so a GC cycle > need to be triggered. The common approach is generating > OutOfMemoryError, catching it and verifying whether the reference is > cleared. > > Some tests use a utility method regtesthelpers/Util.generateOOME [1]. > > For example, these tests follow the above approach: > https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/border/TestTitledBorderLeak.java > https://github.com/openjdk/jdk/blob/master/test/jdk/java/awt/List/ListGarbageCollectionTest/AwtListGarbageCollectionTest.java > > > The AwtListGarbageCollectionTest.java test started to fail pretty often > in the end of January 2023. > > I followed a piece of advice provided in a JBS comment for JDK-8300727 > [2] and replaced generating OOME with a simple call to System.gc() along > with adding a loop for re-trying. > > The specification for System.gc() [3] mentions that this call can be > ignored, which started a discussion in the PR #12594 [4] that > System.gc() should not be used, at the very least without generating > OOME in addition to invoking System.gc(). > > At the same time, many tests for Reference objects, such as > ReferenceEnqueue.java [5] and PhantomReferentClearing.java [6], rely > solely on System.gc. > > > What would be your recommendation? Are there best practices in core-libs > and hotspot for testing for memory leaks that clientlibs should follow? > For tests, the Whitebox methods allow you to specify the exact GC you want to have with a guarantee that it will be executed (in addition to potentially others caused naturally by the application!), i.e. minor/major gc, and specific to collectors, start concurrent gcs etc. E.g. test/hotspot/jtreg/gc/whitebox/TestWBGC.java gives an example how to execute young gcs. It may not be a comprehensive API to test all kinds of GCs, but it fits the use cases we need so far. I recommend to not use OOME for anything unless in extremely specific situations (test OOME is triggered or something). At/after OOME the VM is in a very precarious state that can give unexpected VM bailouts. Thanks, Thomas From rriggs at openjdk.org Sat Mar 4 14:22:33 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Sat, 4 Mar 2023 14:22:33 GMT Subject: RFR: 8303392: Runtime.exec and ProcessBuilder.start should use System logger [v2] In-Reply-To: <-1i11ZrHHgzUbCSa_RXAcGKNfgtpdui--bltZ4Ujs2A=.f5f1a7e2-d3ec-4f64-9b1e-317ef2f24ef1@github.com> References: <-1i11ZrHHgzUbCSa_RXAcGKNfgtpdui--bltZ4Ujs2A=.f5f1a7e2-d3ec-4f64-9b1e-317ef2f24ef1@github.com> Message-ID: > Runtime.exec and ProcessBuilder.start methods create a new operating system process with the program and arguments. Many applications configure a logging subsystem to monitor application events. Logging a process start message with the program, arguments, and stack trace can identify the caller and purpose. > Logging the process start event is complementary to the process start event generated for JFR (Java Flight Recorder). Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Add javadoc @implNote to Runtime.exec and ProcessBuilder methods ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12862/files - new: https://git.openjdk.org/jdk/pull/12862/files/478d8e0e..3013ca0e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12862&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12862&range=00-01 Stats: 26 lines in 2 files changed: 26 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12862.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12862/head:pull/12862 PR: https://git.openjdk.org/jdk/pull/12862 From rgiulietti at openjdk.org Sat Mar 4 22:42:10 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Sat, 4 Mar 2023 22:42:10 GMT Subject: RFR: JDK-8302027: Port fdlibm trig functions (sin, cos, tan) to Java [v4] In-Reply-To: <71cSH1_LEdPk7OKWtBZqc3jj3NYFZ-XDFxRM1OncG64=.6640aca0-29d0-43bd-846c-3cf68d03f170@github.com> References: <71cSH1_LEdPk7OKWtBZqc3jj3NYFZ-XDFxRM1OncG64=.6640aca0-29d0-43bd-846c-3cf68d03f170@github.com> Message-ID: On Sat, 4 Mar 2023 05:14:54 GMT, Joe Darcy wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> Add more tests. > >> > > Added tests cases where the different implementation of trig function T differ in at least one implementation of Math.T. Last port is good to go! Thanks @jddarcy ------------- PR: https://git.openjdk.org/jdk/pull/12800 From darcy at openjdk.org Sat Mar 4 23:56:29 2023 From: darcy at openjdk.org (Joe Darcy) Date: Sat, 4 Mar 2023 23:56:29 GMT Subject: RFR: JDK-8302027: Port fdlibm trig functions (sin, cos, tan) to Java [v6] In-Reply-To: References: Message-ID: > Last and certainly not least in the port of FDLIBM to Java, the transcendental methods for sin, cos, and tan. > > Some more tests are to be written in the StrictMath directory to verify that the StrictMath algorihtm for sin/cos/tan is being used rather than a different one. However, I wanted to get the rest of the change out for review first. > > The sin/cos/tan methods are grouped together since they share the same argument reduction logic. Argument reduction is the process of mapping an argument of a function to an argument in a restricted range (and possibly returning some function of the reduced argument). For sin, cos, and tan, since they are fundamentally periodic with respect to a multiple of pi, argument reduction is done to find the remainder of the original argument with respect to pi/2. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: - Merge branch 'master' into JDK-8302027 - Add test cases with Math and StrictMath differ on a given input. - Add more tests. - Add note explaining goto translation. - Update src/java.base/share/classes/java/lang/FdLibm.java Co-authored-by: Andrey Turbanov - Update src/java.base/share/classes/java/lang/FdLibm.java Co-authored-by: Andrey Turbanov - Update src/java.base/share/classes/java/lang/FdLibm.java Co-authored-by: Andrey Turbanov - Update src/java.base/share/classes/java/lang/FdLibm.java Co-authored-by: Andrey Turbanov - Update src/java.base/share/classes/java/lang/FdLibm.java Co-authored-by: Andrey Turbanov - Update src/java.base/share/classes/java/lang/FdLibm.java Co-authored-by: Andrey Turbanov - ... and 10 more: https://git.openjdk.org/jdk/compare/9fdbf3cf...0466a98d ------------- Changes: https://git.openjdk.org/jdk/pull/12800/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12800&range=05 Stats: 2305 lines in 7 files changed: 2283 ins; 12 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/12800.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12800/head:pull/12800 PR: https://git.openjdk.org/jdk/pull/12800 From darcy at openjdk.org Sat Mar 4 23:56:30 2023 From: darcy at openjdk.org (Joe Darcy) Date: Sat, 4 Mar 2023 23:56:30 GMT Subject: Integrated: JDK-8302027: Port fdlibm trig functions (sin, cos, tan) to Java In-Reply-To: References: Message-ID: <2rIuyoMdKVNYE6mVdA5iA-tR1AOZfXJ-btgPPvnEi10=.92b660fc-dd5f-4a6b-a32b-40f1fd3cc772@github.com> On Wed, 1 Mar 2023 05:28:34 GMT, Joe Darcy wrote: > Last and certainly not least in the port of FDLIBM to Java, the transcendental methods for sin, cos, and tan. > > Some more tests are to be written in the StrictMath directory to verify that the StrictMath algorihtm for sin/cos/tan is being used rather than a different one. However, I wanted to get the rest of the change out for review first. > > The sin/cos/tan methods are grouped together since they share the same argument reduction logic. Argument reduction is the process of mapping an argument of a function to an argument in a restricted range (and possibly returning some function of the reduced argument). For sin, cos, and tan, since they are fundamentally periodic with respect to a multiple of pi, argument reduction is done to find the remainder of the original argument with respect to pi/2. This pull request has now been integrated. Changeset: 1bb39a95 Author: Joe Darcy URL: https://git.openjdk.org/jdk/commit/1bb39a95eb42c7f68ba59ac2809717cd7b1df7bc Stats: 2305 lines in 7 files changed: 2283 ins; 12 del; 10 mod 8302027: Port fdlibm trig functions (sin, cos, tan) to Java Reviewed-by: bpb ------------- PR: https://git.openjdk.org/jdk/pull/12800 From stuefe at openjdk.org Sun Mar 5 06:18:16 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sun, 5 Mar 2023 06:18:16 GMT Subject: RFR: 8303392: Runtime.exec and ProcessBuilder.start should use System logger [v2] In-Reply-To: References: <-1i11ZrHHgzUbCSa_RXAcGKNfgtpdui--bltZ4Ujs2A=.f5f1a7e2-d3ec-4f64-9b1e-317ef2f24ef1@github.com> Message-ID: <-PHwf09-m1XajVZo9TpIbaJfM0duZ3PVQfINW6gtEvs=.bab3ee00-a561-4207-ac19-1f2abf8a5f6c@github.com> On Sat, 4 Mar 2023 14:22:33 GMT, Roger Riggs wrote: >> Runtime.exec and ProcessBuilder.start methods create a new operating system process with the program and arguments. Many applications configure a logging subsystem to monitor application events. Logging a process start message with the program, arguments, and stack trace can identify the caller and purpose. >> Logging the process start event is complementary to the process start event generated for JFR (Java Flight Recorder). > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Add javadoc @implNote to Runtime.exec and ProcessBuilder methods Hi Roger, I think to be even more useful it could make sense to print the current directory the child is started in as well as the env var array, possibly only with a finer logging level. Cheers, Thomas ------------- PR: https://git.openjdk.org/jdk/pull/12862 From darcy at openjdk.org Sun Mar 5 06:19:06 2023 From: darcy at openjdk.org (Joe Darcy) Date: Sun, 5 Mar 2023 06:19:06 GMT Subject: RFR: JDK-8302801: Remove fdlibm C sources [v4] In-Reply-To: References: Message-ID: > While the review of https://github.com/openjdk/jdk/pull/12800 finishes up, I thought I'd get out for the review the next phase of the FDLIBM port: removing the FDLIBM C sources from the repo. > > A repo with the changes for JDK-8302027 and this PR successful build on the default set of platform and successfully run tier 1 tests, which includes tests of the math library. > > There are a few remaining references to the case-independent string "fdlibm" in the make directory and HotSpot sources. HotSpot contains a partial fork for FDLIBM (a tine of FDLIBM?) to use for intrinsics. The remaining make machinery contains logic to determine what set of gcc options can be used for the compile. > > The intention of this change is to remove use of FDLIBM for the core libraries. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: - Merge branch 'master' of https://git.openjdk.org/jdk into JDK-8302801-expr - Respond to review feedback. - Respond to review feedback and add description of transliteration process. - JDK-8302801: Remove fdlibm C sources - Update src/java.base/share/classes/java/lang/FdLibm.java Co-authored-by: Andrey Turbanov - Update src/java.base/share/classes/java/lang/FdLibm.java Co-authored-by: Andrey Turbanov - Update src/java.base/share/classes/java/lang/FdLibm.java Co-authored-by: Andrey Turbanov - Update src/java.base/share/classes/java/lang/FdLibm.java Co-authored-by: Andrey Turbanov - Update src/java.base/share/classes/java/lang/FdLibm.java Co-authored-by: Andrey Turbanov - Update src/java.base/share/classes/java/lang/FdLibm.java Co-authored-by: Andrey Turbanov - ... and 10 more: https://git.openjdk.org/jdk/compare/1bb39a95...437a8fce ------------- Changes: https://git.openjdk.org/jdk/pull/12821/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12821&range=03 Stats: 6643 lines in 65 files changed: 20 ins; 6613 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/12821.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12821/head:pull/12821 PR: https://git.openjdk.org/jdk/pull/12821 From aturbanov at openjdk.org Sun Mar 5 09:41:29 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Sun, 5 Mar 2023 09:41:29 GMT Subject: RFR: JDK-8302027: Port fdlibm trig functions (sin, cos, tan) to Java [v6] In-Reply-To: References: Message-ID: <3Ldza_9LcFInP14aCmJeRMgmzwlnhAV9qFjV4JWh85Y=.193e87bb-562a-4a40-84b9-634b62bdefc9@github.com> The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. ---------------------------------------------------------------------- On Wed, 1 Mar 2023 14:26:44 GMT, Andrey Turbanov wrote: >> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: >> >> - Merge branch 'master' into JDK-8302027 >> - Add test cases with Math and StrictMath differ on a given input. >> - Add more tests. >> - Add note explaining goto translation. >> - Update src/java.base/share/classes/java/lang/FdLibm.java >> >> Co-authored-by: Andrey Turbanov >> - Update src/java.base/share/classes/java/lang/FdLibm.java >> >> Co-authored-by: Andrey Turbanov >> - Update src/java.base/share/classes/java/lang/FdLibm.java >> >> Co-authored-by: Andrey Turbanov >> - Update src/java.base/share/classes/java/lang/FdLibm.java >> >> Co-authored-by: Andrey Turbanov >> - Update src/java.base/share/classes/java/lang/FdLibm.java >> >> Co-authored-by: Andrey Turbanov >> - Update src/java.base/share/classes/java/lang/FdLibm.java >> >> Co-authored-by: Andrey Turbanov >> - ... and 10 more: https://git.openjdk.org/jdk/compare/9fdbf3cf...0466a98d > > src/java.base/share/classes/java/lang/FdLibm.java line 166: > >> 164: } else { // argument reduction needed >> 165: n = RemPio2.__ieee754_rem_pio2(x, y); >> 166: switch(n & 3) { > > Suggestion: > > switch (n & 3) { :( ------------- PR: https://git.openjdk.org/jdk/pull/12800 From darcy at openjdk.org Sun Mar 5 17:13:09 2023 From: darcy at openjdk.org (Joe Darcy) Date: Sun, 5 Mar 2023 17:13:09 GMT Subject: RFR: JDK-8302801: Remove fdlibm C sources [v4] In-Reply-To: <3JvuLUDJO3_dzKHOsMocC6kGDEmnIQo_7uobd-VTzHg=.22565440-42ae-4d26-9d74-2cbb7c63f9ea@github.com> References: <3JvuLUDJO3_dzKHOsMocC6kGDEmnIQo_7uobd-VTzHg=.22565440-42ae-4d26-9d74-2cbb7c63f9ea@github.com> Message-ID: On Thu, 2 Mar 2023 18:27:09 GMT, Joe Darcy wrote: >> make/autoconf/buildjdk-spec.gmk.in line 85: >> >>> 83: JVM_LIBS := @OPENJDK_BUILD_JVM_LIBS@ >>> 84: >>> 85: FDLIBM_CFLAGS := @OPENJDK_BUILD_FDLIBM_CFLAGS@ >> >> If the hotspot build still needs `FDLIBM_CFLAGS`, then this line needs to stay. > > Okay; added back. PS Successful Mach 5 job of default builds and tier 1 tests with this make line present. ------------- PR: https://git.openjdk.org/jdk/pull/12821 From alanb at openjdk.org Sun Mar 5 19:21:09 2023 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 5 Mar 2023 19:21:09 GMT Subject: RFR: JDK-8302801: Remove fdlibm C sources [v4] In-Reply-To: References: Message-ID: On Sun, 5 Mar 2023 06:19:06 GMT, Joe Darcy wrote: >> While the review of https://github.com/openjdk/jdk/pull/12800 finishes up, I thought I'd get out for the review the next phase of the FDLIBM port: removing the FDLIBM C sources from the repo. >> >> A repo with the changes for JDK-8302027 and this PR successful build on the default set of platform and successfully run tier 1 tests, which includes tests of the math library. >> >> There are a few remaining references to the case-independent string "fdlibm" in the make directory and HotSpot sources. HotSpot contains a partial fork for FDLIBM (a tine of FDLIBM?) to use for intrinsics. The remaining make machinery contains logic to determine what set of gcc options can be used for the compile. >> >> The intention of this change is to remove use of FDLIBM for the core libraries. > > Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: > > - Merge branch 'master' of https://git.openjdk.org/jdk into JDK-8302801-expr > - Respond to review feedback. > - Respond to review feedback and add description of transliteration process. > - JDK-8302801: Remove fdlibm C sources > - Update src/java.base/share/classes/java/lang/FdLibm.java > > Co-authored-by: Andrey Turbanov > - Update src/java.base/share/classes/java/lang/FdLibm.java > > Co-authored-by: Andrey Turbanov > - Update src/java.base/share/classes/java/lang/FdLibm.java > > Co-authored-by: Andrey Turbanov > - Update src/java.base/share/classes/java/lang/FdLibm.java > > Co-authored-by: Andrey Turbanov > - Update src/java.base/share/classes/java/lang/FdLibm.java > > Co-authored-by: Andrey Turbanov > - Update src/java.base/share/classes/java/lang/FdLibm.java > > Co-authored-by: Andrey Turbanov > - ... and 10 more: https://git.openjdk.org/jdk/compare/1bb39a95...437a8fce I don't have any other comments on this, looks good. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.org/jdk/pull/12821 From dnsimon at openjdk.org Sun Mar 5 22:08:07 2023 From: dnsimon at openjdk.org (Doug Simon) Date: Sun, 5 Mar 2023 22:08:07 GMT Subject: RFR: 8303431: [JVMCI] libgraal annotation API [v2] In-Reply-To: References: Message-ID: > This PR extends JVMCI with new API (`jdk.vm.ci.meta.Annotated`) for accessing annotations. The main differences from `java.lang.reflect.AnnotatedElement` are: > * Each `Annotated` method explicitly specifies the annotation type(s) for which it wants annotation data. That is, there is no direct equivalent of `AnnotatedElement.getAnnotations()`. > * Annotation data is returned in a map-like object (of type `jdk.vm.ci.meta.AnnotationData`) instead of in an `Annotation` object. This works better for libgraal as it avoids the need for annotation types to be loaded and included in libgraal. > > To demonstrate the new API, here's an example in terms `java.lang.reflect.AnnotatedElement` (which `ResolvedJavaType` implements): > > ResolvedJavaMethod method = ...; > ExplodeLoop a = method.getAnnotation(ExplodeLoop.class); > return switch (a.kind()) { > case FULL_UNROLL -> LoopExplosionKind.FULL_UNROLL; > case FULL_UNROLL_UNTIL_RETURN -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN; > ... > } > > > The same code using the new API: > > > ResolvedJavaMethod method = ...; > ResolvedJavaType explodeLoopType = ...; > AnnotationData a = method.getAnnotationDataFor(explodeLoopType); > return switch (a.getEnum("kind").getName()) { > case "FULL_UNROLL" -> LoopExplosionKind.FULL_UNROLL; > case "FULL_UNROLL_UNTIL_RETURN" -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN; > ... > } > > > The implementation relies on new methods in `jdk.internal.vm.VMSupport` for parsing annotations and serializing/deserializing to/from a byte array. This allows the annotation data to be passed from the HotSpot heap to the libgraal heap. Doug Simon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - added support for inherited annotations - Merge branch 'master' into JDK-8303431 - made AnnotationDataDecoder package-private - add annotation API to JVMCI ------------- Changes: https://git.openjdk.org/jdk/pull/12810/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12810&range=01 Stats: 2752 lines in 33 files changed: 2700 ins; 24 del; 28 mod Patch: https://git.openjdk.org/jdk/pull/12810.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12810/head:pull/12810 PR: https://git.openjdk.org/jdk/pull/12810 From dholmes at openjdk.org Sun Mar 5 22:28:11 2023 From: dholmes at openjdk.org (David Holmes) Date: Sun, 5 Mar 2023 22:28:11 GMT Subject: RFR: JDK-8302801: Remove fdlibm C sources [v4] In-Reply-To: References: Message-ID: On Sun, 5 Mar 2023 06:19:06 GMT, Joe Darcy wrote: >> While the review of https://github.com/openjdk/jdk/pull/12800 finishes up, I thought I'd get out for the review the next phase of the FDLIBM port: removing the FDLIBM C sources from the repo. >> >> A repo with the changes for JDK-8302027 and this PR successful build on the default set of platform and successfully run tier 1 tests, which includes tests of the math library. >> >> There are a few remaining references to the case-independent string "fdlibm" in the make directory and HotSpot sources. HotSpot contains a partial fork for FDLIBM (a tine of FDLIBM?) to use for intrinsics. The remaining make machinery contains logic to determine what set of gcc options can be used for the compile. >> >> The intention of this change is to remove use of FDLIBM for the core libraries. > > Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: > > - Merge branch 'master' of https://git.openjdk.org/jdk into JDK-8302801-expr > - Respond to review feedback. > - Respond to review feedback and add description of transliteration process. > - JDK-8302801: Remove fdlibm C sources > - Update src/java.base/share/classes/java/lang/FdLibm.java > > Co-authored-by: Andrey Turbanov > - Update src/java.base/share/classes/java/lang/FdLibm.java > > Co-authored-by: Andrey Turbanov > - Update src/java.base/share/classes/java/lang/FdLibm.java > > Co-authored-by: Andrey Turbanov > - Update src/java.base/share/classes/java/lang/FdLibm.java > > Co-authored-by: Andrey Turbanov > - Update src/java.base/share/classes/java/lang/FdLibm.java > > Co-authored-by: Andrey Turbanov > - Update src/java.base/share/classes/java/lang/FdLibm.java > > Co-authored-by: Andrey Turbanov > - ... and 10 more: https://git.openjdk.org/jdk/compare/1bb39a95...437a8fce Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12821 From dnsimon at openjdk.org Sun Mar 5 22:37:38 2023 From: dnsimon at openjdk.org (Doug Simon) Date: Sun, 5 Mar 2023 22:37:38 GMT Subject: RFR: 8303431: [JVMCI] libgraal annotation API [v3] In-Reply-To: References: Message-ID: > This PR extends JVMCI with new API (`jdk.vm.ci.meta.Annotated`) for accessing annotations. The main differences from `java.lang.reflect.AnnotatedElement` are: > * Each `Annotated` method explicitly specifies the annotation type(s) for which it wants annotation data. That is, there is no direct equivalent of `AnnotatedElement.getAnnotations()`. > * Annotation data is returned in a map-like object (of type `jdk.vm.ci.meta.AnnotationData`) instead of in an `Annotation` object. This works better for libgraal as it avoids the need for annotation types to be loaded and included in libgraal. > > To demonstrate the new API, here's an example in terms `java.lang.reflect.AnnotatedElement` (which `ResolvedJavaType` implements): > > ResolvedJavaMethod method = ...; > ExplodeLoop a = method.getAnnotation(ExplodeLoop.class); > return switch (a.kind()) { > case FULL_UNROLL -> LoopExplosionKind.FULL_UNROLL; > case FULL_UNROLL_UNTIL_RETURN -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN; > ... > } > > > The same code using the new API: > > > ResolvedJavaMethod method = ...; > ResolvedJavaType explodeLoopType = ...; > AnnotationData a = method.getAnnotationDataFor(explodeLoopType); > return switch (a.getEnum("kind").getName()) { > case "FULL_UNROLL" -> LoopExplosionKind.FULL_UNROLL; > case "FULL_UNROLL_UNTIL_RETURN" -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN; > ... > } > > > The implementation relies on new methods in `jdk.internal.vm.VMSupport` for parsing annotations and serializing/deserializing to/from a byte array. This allows the annotation data to be passed from the HotSpot heap to the libgraal heap. Doug Simon has updated the pull request incrementally with one additional commit since the last revision: fixed whitespace ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12810/files - new: https://git.openjdk.org/jdk/pull/12810/files/8743e8b9..3dd5ef9c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12810&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12810&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12810.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12810/head:pull/12810 PR: https://git.openjdk.org/jdk/pull/12810 From duke at openjdk.org Sun Mar 5 23:21:57 2023 From: duke at openjdk.org (Marius Volkhart) Date: Sun, 5 Mar 2023 23:21:57 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v42] In-Reply-To: <9XP497xudeRhZKkIpxIgpbqT24eG8SCbfG6TelYtM3M=.f1ad5a76-798c-4e3d-b43b-a25a20210154@github.com> References: <9XP497xudeRhZKkIpxIgpbqT24eG8SCbfG6TelYtM3M=.f1ad5a76-798c-4e3d-b43b-a25a20210154@github.com> Message-ID: <5YvuMA0QcACRyYG3hYiE9A5K2m0TB40R3OPzzAuoqRo=.27359ff9-1ce3-45df-a9bf-5674d57a333d@github.com> On Mon, 27 Feb 2023 12:47:03 GMT, Jim Laskey wrote: >> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Tighten up reporting of string template errors (fewer messages) src/java.base/share/classes/java/lang/template/Carriers.java line 396: > 394: > 395: /** > 396: * Wrapper object for carrier data. Instances types are stored in the {@code objects} Suggestion: * Wrapper object for carrier data. Instance types are stored in the {@code objects} src/java.base/share/classes/java/lang/template/StringTemplate.java line 76: > 74: * produced that returns the same lists from {@link StringTemplate#fragments()} and > 75: * {@link StringTemplate#values()} as shown above. The {@link StringTemplate#STR} template > 76: * processor uses these lists to yield an interpolated string. the value of {@code s} will Suggestion: * processor uses these lists to yield an interpolated string. The value of {@code s} will ------------- PR: https://git.openjdk.org/jdk/pull/10889 From brett.okken.os at gmail.com Sun Mar 5 23:49:23 2023 From: brett.okken.os at gmail.com (Brett Okken) Date: Sun, 5 Mar 2023 17:49:23 -0600 Subject: UUID creation performance In-Reply-To: <608c81ee-cb3d-d142-c8fa-a1bcd9551975@oracle.com> References: <608c81ee-cb3d-d142-c8fa-a1bcd9551975@oracle.com> Message-ID: The new ByteArray class works great for the nameUUIDFromBytes method, which must be in big endian. For randomUUID, byte order does not matter, so using native would be fastest, but there does not appear to be a utility class for that. Is there a preference of just having a native order VarHandle to use in UUID vs. having a utility method which chooses which utility class to call based on the native order vs. some other option? Thanks, Brett On Wed, Mar 1, 2023 at 9:08?AM Roger Riggs wrote: > > Hi, > > That's an interesting idea. Recently VarHandle access methods were > created by JDK-8300236 [1] [2] > in the jdk.internal.util package. See the ByteArray and > ByteArrayLittleEndian classes. > > See how that would affect performance and leverage existing VarHandles. > > Thanks, Roger > > [1] https://bugs.openjdk.org/browse/JDK-8300236 > [2] https://github.com/openjdk/jdk/pull/12076 > > On 3/1/23 7:50 AM, Brett Okken wrote: > > Is there any interest in updating the static UUID.randomUUID() and > > UUID.nameUUIDFromBytes(byte[]) factory methods to use either a > > ByteBuffer or byteArrayViewVarHandle to convert the byte[] to 2 long > > values then do the bit twiddling? > > These methods are really dominated by time to create/populate the > > byte[], but this does reduce the time to create the 2 long values by > > at least half. > > It would also allow the removal of the private UUID(byte[] data). > > > > public static UUID randomUUID() { > > SecureRandom ng = Holder.numberGenerator; > > > > byte[] randomBytes = new byte[16]; > > ng.nextBytes(randomBytes); > > final ByteBuffer bb = ByteBuffer.wrap(randomBytes); > > bb.order(ByteOrder.nativeOrder()); > > > > long msb = bb.getLong(); > > long lsb = bb.getLong(); > > > > msb &= 0xFFFFFFFFFFFF0FFFL; /* clear version */ > > msb |= 0x4000L; /* set to version 4 */ > > > > lsb &= 0x3FFFFFFFFFFFFFFFL; /* clear variant */ > > lsb |= 0x8000000000000000L; /* set to IETF variant */ > > > > return new UUID(msb, lsb); > > } > > > > public static UUID nameUUIDFromBytes(byte[] name) { > > MessageDigest md; > > try { > > md = MessageDigest.getInstance("MD5"); > > } catch (NoSuchAlgorithmException nsae) { > > throw new InternalError("MD5 not supported", nsae); > > } > > byte[] md5Bytes = md.digest(name); > > > > // default byte order is BIG_ENDIAN > > final ByteBuffer bb = ByteBuffer.wrap(md5Bytes); > > > > long msb = bb.getLong(); > > long lsb = bb.getLong(); > > > > msb &= 0xFFFFFFFFFFFF0FFFL; /* clear version */ > > msb |= 0x3000L; /* set to version 3 */ > > > > lsb &= 0x3FFFFFFFFFFFFFFFL; /* clear variant */ > > lsb |= 0x8000000000000000L; /* set to IETF variant */ > > > > return new UUID(msb, lsb); > > } > > > > Benchmark Mode Cnt Score Error Units > > UUIDBenchmark.jdk_name avgt 3 11.885 ? 4.025 ns/op > > UUIDBenchmark.jdk_random avgt 3 11.656 ? 0.987 ns/op > > UUIDBenchmark.longs avgt 3 7.618 ? 1.047 ns/op > > UUIDBenchmark.longs_bb avgt 3 7.755 ? 1.643 ns/op > > UUIDBenchmark.longs_name avgt 3 8.467 ? 1.784 ns/op > > UUIDBenchmark.longs_name_bb avgt 3 8.455 ? 1.662 ns/op > > UUIDBenchmark.randomBytes avgt 3 6.132 ? 0.447 ns/op > > > > > > @BenchmarkMode(Mode.AverageTime) > > @OutputTimeUnit(TimeUnit.NANOSECONDS) > > @Warmup(iterations = 3, time = 2, timeUnit = TimeUnit.SECONDS) > > @Measurement(iterations = 3, time = 2, timeUnit = TimeUnit.SECONDS) > > @Fork(1) > > @State(Scope.Benchmark) > > public class UUIDBenchmark { > > > > private static final VarHandle LONGS_ACCESS = > > MethodHandles.byteArrayViewVarHandle(long[].class, > > ByteOrder.nativeOrder()); > > > > private static final VarHandle BE_LONGS_ACCESS = > > MethodHandles.byteArrayViewVarHandle(long[].class, > > ByteOrder.BIG_ENDIAN); > > > > @Benchmark > > public byte[] randomBytes() { > > final byte[] bytes = new byte[16]; > > randomBytes(bytes); > > return bytes; > > } > > > > @Benchmark > > public void jdk_random(Blackhole bh) { > > final byte[] data = new byte[16]; > > randomBytes(data); > > data[6] &= 0x0f; /* clear version */ > > data[6] |= 0x40; /* set to version 4 */ > > data[8] &= 0x3f; /* clear variant */ > > data[8] |= 0x80; /* set to IETF variant */ > > long msb = 0; > > long lsb = 0; > > assert data.length == 16 : "data must be 16 bytes in length"; > > for (int i=0; i<8; i++) > > msb = (msb << 8) | (data[i] & 0xff); > > for (int i=8; i<16; i++) > > lsb = (lsb << 8) | (data[i] & 0xff); > > bh.consume(msb); > > bh.consume(lsb); > > } > > > > @Benchmark > > public void jdk_name(Blackhole bh) > > { > > final byte[] md5Bytes = new byte[16]; > > randomBytes(md5Bytes); > > md5Bytes[6] &= 0x0f; /* clear version */ > > md5Bytes[6] |= 0x30; /* set to version 3 */ > > md5Bytes[8] &= 0x3f; /* clear variant */ > > md5Bytes[8] |= 0x80; /* set to IETF variant */ > > long msb = 0; > > long lsb = 0; > > assert md5Bytes.length == 16 : "data must be 16 bytes in length"; > > for (int i=0; i<8; i++) > > msb = (msb << 8) | (md5Bytes[i] & 0xff); > > for (int i=8; i<16; i++) > > lsb = (lsb << 8) | (md5Bytes[i] & 0xff); > > bh.consume(msb); > > bh.consume(lsb); > > } > > > > @Benchmark > > public void longs(Blackhole bh) { > > final byte[] data = new byte[16]; > > randomBytes(data); > > > > long msb = (long) LONGS_ACCESS.get(data, 0); > > long lsb = (long) LONGS_ACCESS.get(data, 8); > > > > msb &= 0xFFFFFFFFFFFF0FFFL; > > msb |= 0x4000L; > > > > lsb &= 0x3FFFFFFFFFFFFFFFL; > > lsb |= 0x8000000000000000L; > > > > bh.consume(msb); > > bh.consume(lsb); > > } > > > > @Benchmark > > public void longs_name(Blackhole bh) { > > final byte[] data = new byte[16]; > > randomBytes(data); > > > > long msb = (long) BE_LONGS_ACCESS.get(data, 0); > > long lsb = (long) BE_LONGS_ACCESS.get(data, 8); > > > > msb &= 0xFFFFFFFFFFFF0FFFL; > > msb |= 0x3000L; > > > > lsb &= 0x3FFFFFFFFFFFFFFFL; > > lsb |= 0x8000000000000000L; > > > > bh.consume(msb); > > bh.consume(lsb); > > } > > > > @Benchmark > > public void longs_bb(Blackhole bh) { > > final byte[] data = new byte[16]; > > randomBytes(data); > > > > final ByteBuffer bb = ByteBuffer.wrap(data); > > bb.order(ByteOrder.nativeOrder()); > > > > long msb = bb.getLong(); > > long lsb = bb.getLong(); > > > > msb &= 0xFFFFFFFFFFFF0FFFL; > > msb |= 0x4000L; > > > > lsb &= 0x3FFFFFFFFFFFFFFFL; > > lsb |= 0x8000000000000000L; > > > > bh.consume(msb); > > bh.consume(lsb); > > } > > > > @Benchmark > > public void longs_name_bb(Blackhole bh) { > > final byte[] data = new byte[16]; > > randomBytes(data); > > > > final ByteBuffer bb = ByteBuffer.wrap(data); > > // bb.order(ByteOrder.BIG_ENDIAN); > > > > long msb = bb.getLong(); > > long lsb = bb.getLong(); > > > > msb &= 0xFFFFFFFFFFFF0FFFL; > > msb |= 0x3000L; > > > > lsb &= 0x3FFFFFFFFFFFFFFFL; > > lsb |= 0x8000000000000000L; > > > > bh.consume(msb); > > bh.consume(lsb); > > } > > > > static void randomBytes(byte[] bytes) { > > ThreadLocalRandom tlr = ThreadLocalRandom.current(); > > LONGS_ACCESS.set(bytes, 0, tlr.nextLong()); > > LONGS_ACCESS.set(bytes, 8, tlr.nextLong()); > > } > > } > From kvn at openjdk.org Mon Mar 6 03:08:17 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 6 Mar 2023 03:08:17 GMT Subject: RFR: JDK-8302801: Remove fdlibm C sources [v4] In-Reply-To: References: Message-ID: <-GBkdRKUf-hykdFTOo44ZVnuJSyhGzfCid3xeUHuMb0=.9225c4b6-65f8-4e54-8dac-c300872f660b@github.com> On Sun, 5 Mar 2023 06:19:06 GMT, Joe Darcy wrote: >> While the review of https://github.com/openjdk/jdk/pull/12800 finishes up, I thought I'd get out for the review the next phase of the FDLIBM port: removing the FDLIBM C sources from the repo. >> >> A repo with the changes for JDK-8302027 and this PR successful build on the default set of platform and successfully run tier 1 tests, which includes tests of the math library. >> >> There are a few remaining references to the case-independent string "fdlibm" in the make directory and HotSpot sources. HotSpot contains a partial fork for FDLIBM (a tine of FDLIBM?) to use for intrinsics. The remaining make machinery contains logic to determine what set of gcc options can be used for the compile. >> >> The intention of this change is to remove use of FDLIBM for the core libraries. > > Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: > > - Merge branch 'master' of https://git.openjdk.org/jdk into JDK-8302801-expr > - Respond to review feedback. > - Respond to review feedback and add description of transliteration process. > - JDK-8302801: Remove fdlibm C sources > - Update src/java.base/share/classes/java/lang/FdLibm.java > > Co-authored-by: Andrey Turbanov > - Update src/java.base/share/classes/java/lang/FdLibm.java > > Co-authored-by: Andrey Turbanov > - Update src/java.base/share/classes/java/lang/FdLibm.java > > Co-authored-by: Andrey Turbanov > - Update src/java.base/share/classes/java/lang/FdLibm.java > > Co-authored-by: Andrey Turbanov > - Update src/java.base/share/classes/java/lang/FdLibm.java > > Co-authored-by: Andrey Turbanov > - Update src/java.base/share/classes/java/lang/FdLibm.java > > Co-authored-by: Andrey Turbanov > - ... and 10 more: https://git.openjdk.org/jdk/compare/1bb39a95...437a8fce HotSpot changes look good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.org/jdk/pull/12821 From amitkumar at openjdk.org Mon Mar 6 06:24:26 2023 From: amitkumar at openjdk.org (Amit Kumar) Date: Mon, 6 Mar 2023 06:24:26 GMT Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x [v2] In-Reply-To: <3z7u66KVgFfL7S7S4uxDtOA6gD-WkNU7R-zon0trIVg=.d27446ca-c11d-49cc-bb85-b162e5ac58f2@github.com> References: <3z7u66KVgFfL7S7S4uxDtOA6gD-WkNU7R-zon0trIVg=.d27446ca-c11d-49cc-bb85-b162e5ac58f2@github.com> Message-ID: On Thu, 2 Feb 2023 08:27:55 GMT, Amit Kumar wrote: >> DeInflate.java test fails on s390x platform because size for out1 array which is responsible for storing the compressed data is insufficient. And being unable to write whole compressed data on array, on s390 whole data can't be recovered after compression. So this fix increase Array size (for s390). > > Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: > > change acc to Alan comments Alan, please update, if you want further testing and provide suggestion :-) ------------- PR: https://git.openjdk.org/jdk/pull/12283 From jpai at openjdk.org Mon Mar 6 06:57:09 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 6 Mar 2023 06:57:09 GMT Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x [v2] In-Reply-To: <3z7u66KVgFfL7S7S4uxDtOA6gD-WkNU7R-zon0trIVg=.d27446ca-c11d-49cc-bb85-b162e5ac58f2@github.com> References: <3z7u66KVgFfL7S7S4uxDtOA6gD-WkNU7R-zon0trIVg=.d27446ca-c11d-49cc-bb85-b162e5ac58f2@github.com> Message-ID: On Thu, 2 Feb 2023 08:27:55 GMT, Amit Kumar wrote: >> DeInflate.java test fails on s390x platform because size for out1 array which is responsible for storing the compressed data is insufficient. And being unable to write whole compressed data on array, on s390 whole data can't be recovered after compression. So this fix increase Array size (for s390). > > Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: > > change acc to Alan comments Hello Amit, like Alan notes, we don't have a clarity on what's going on here. It is an interesting failure, but neither of us have access to the system where this fails, so we can just provide suggestions on how to narrow this down. Alan provided some suggestions on what can be done to debug this. I think you or someone who has access to this system will need to do some more debugging/changes to narrow this down. Your logs so far have shown that this fails for deflate level 1. What you can do in the test is just focus on this specific level and the default strategy and then debug the code (either through logs or actual runtime debugging) to figure out why "deflate.finished()" returns false. To help, I have trimmed down the test case to this specific scenario and here's the patch: diff --git a/test/jdk/java/util/zip/DeInflate.java b/test/jdk/java/util/zip/DeInflate.java index ff2cb63c6e7..d720c53e8c3 100644 --- a/test/jdk/java/util/zip/DeInflate.java +++ b/test/jdk/java/util/zip/DeInflate.java @@ -125,9 +125,30 @@ public class DeInflate { Arrays.fill(out1, (byte)0); Arrays.fill(out2, (byte)0); + System.out.println("Feeding input of length " + len); def.setInput(in, 0, len); - def.finish(); - int m = def.deflate(out1); + def.finish(); // this implies the deflater will not be provided with any more input data + // than what we set on previous line + + int m = 0; + while (!def.finished()) { + int remaining = out1.length - m; + int numWritten = def.deflate(out1, m, remaining); + System.out.println("Num written " + numWritten); + if (numWritten == 0) { + // Check if needsInput(), this shouldn't have happened because we have + // marked the deflater with "def.finish()" indicating there's no more input data to + // provide + if (def.needsInput()) { + throw new RuntimeException("Deflater is expecting more input data when " + + "deflater.finish() was already called"); + } else { + System.out.println("Deflater isn't expecting any more data but numWritten is 0" + + " and finished is " + def.finished()); + } + } + m += numWritten; + } Inflater inf = new Inflater(nowrap); inf.setInput(out1, 0, m); @@ -271,34 +292,10 @@ public class DeInflate { byte[] dataOut1 = new byte[dataIn.length + 1024]; byte[] dataOut2 = new byte[dataIn.length]; - Deflater defNotWrap = new Deflater(Deflater.DEFAULT_COMPRESSION, false); - Deflater defWrap = new Deflater(Deflater.DEFAULT_COMPRESSION, true); - - for (int level = Deflater.DEFAULT_COMPRESSION; - level <= Deflater.BEST_COMPRESSION; level++) { - for (int strategy = Deflater.DEFAULT_STRATEGY; - strategy <= Deflater.HUFFMAN_ONLY; strategy++) { - for (boolean dowrap : new boolean[] { false, true }) { - System.out.println("level:" + level + - ", strategy: " + strategy + - ", dowrap: " + dowrap); - for (int i = 0; i < 5; i++) { - int len = (i == 0)? dataIn.length - : new Random().nextInt(dataIn.length); - // use a new deflater - Deflater def = newDeflater(level, strategy, dowrap, dataOut2); - check(def, dataIn, len, dataOut1, dataOut2, dowrap); - def.end(); - - // reuse the deflater (with reset) and test on stream, which - // uses a "smaller" buffer (smaller than the overall data) - def = resetDeflater(dowrap ? defWrap : defNotWrap, level, strategy); - checkStream(def, dataIn, len, dataOut1, dataOut2, dowrap); - } - } - // test setDictionary() - checkDict(level, strategy); - } - } + final boolean dowrap = true; + Deflater def = newDeflater(Deflater.BEST_SPEED, Deflater.DEFAULT_STRATEGY, dowrap, dataOut2); + check(def, dataIn, dataIn.length, dataOut1, dataOut2, dowrap); + def.end(); + } } (apply it afresh, without any existing changes). What this patch does is, it jus focuses on the level 1 deflater. Additionally in the check() method is adds some additional checks to see why the deflater might be returning finished() false. The (original and this patched version of the) test calls `deflater.finish()` before calling `deflate()`. What this means is that the deflater shouldn't expect any more input data. I have added some checks in that test to see if it does infact expect more input data. After running the test you can share with us the logs. We could provide more suggestions what to debug further, but I think you or someone with access to that system will have to do the actual investigation. ------------- PR: https://git.openjdk.org/jdk/pull/12283 From aturbanov at openjdk.org Mon Mar 6 08:46:23 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 6 Mar 2023 08:46:23 GMT Subject: Integrated: 8303266: Prefer ArrayList to LinkedList in JImageTask In-Reply-To: References: Message-ID: On Mon, 27 Feb 2023 11:33:38 GMT, Andrey Turbanov wrote: > `LinkedList` is used as a field `jdk.tools.jimage.JImageTask.OptionsValues#jimages` > It's created, filled (with `add`) and then iterated. No removes from the head or something like this. `ArrayList` should be preferred as more efficient and widely used (more chances for JIT) collection. This pull request has now been integrated. Changeset: fa1cebed Author: Andrey Turbanov URL: https://git.openjdk.org/jdk/commit/fa1cebedb5de10e34e9d0cd1d8a563c56b562f54 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod 8303266: Prefer ArrayList to LinkedList in JImageTask Reviewed-by: jlaskey ------------- PR: https://git.openjdk.org/jdk/pull/12760 From amitkumar at openjdk.org Mon Mar 6 09:44:14 2023 From: amitkumar at openjdk.org (Amit Kumar) Date: Mon, 6 Mar 2023 09:44:14 GMT Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x [v2] In-Reply-To: References: <3z7u66KVgFfL7S7S4uxDtOA6gD-WkNU7R-zon0trIVg=.d27446ca-c11d-49cc-bb85-b162e5ac58f2@github.com> Message-ID: On Mon, 6 Mar 2023 06:54:27 GMT, Jaikiran Pai wrote: >After running the test you can share with us the logs. We could provide more suggestions what to debug further, but I think you or someone with access to that system will have to do the actual investigation.. Output for above patch, I can share whole JTR file if you want. Feeding input of length 524288 Num written 525312 Num written 0 Deflater isn't expecting any more data but numWritten is 0 and finished is false Num written 0 Deflater isn't expecting any more data but numWritten is 0 and finished is false Num written 0 Deflater isn't expecting any more data but numWritten is 0 and finished is false Num written 0 Deflater isn't expecting any more data but numWritten is 0 and finished is false Num written 0 Deflater isn't expecting any more data but numWritten is 0 and finished is false Num written 0 Deflater isn't expecting any more data but numWritten is 0 and finished is false Num written 0 Deflater isn't expecting any more data but numWritten is 0 and finished is false Num written 0 Deflater isn't expecting any more data but numWritten is 0 and finished is false Num written 0 Deflater isn't expecting any more data but numWritten is 0 and finished is false Num written 0 Deflater isn't expecting any more data but numWritten is 0 and finished is false Num written 0 Deflater isn't expecting any more data but numWritten is 0 and finished is false Num written 0 Deflater isn't expecting any more data but numWritten is 0 and finished is false Num written 0 Deflater isn't expecting any more data but numWritten is 0 an result: Error. Agent error: java.lang.Exception: Agent 2 timed out with a timeout of 480 seconds; check console log for any additional details test result: Error. Agent error: java.lang.Exception: Agent 2 timed out with a timeout of 480 seconds; check console log for any additional details ------------- PR: https://git.openjdk.org/jdk/pull/12283 From duke at openjdk.org Mon Mar 6 10:11:13 2023 From: duke at openjdk.org (Viktor Klang) Date: Mon, 6 Mar 2023 10:11:13 GMT Subject: RFR: 8297605: DelayQueue javadoc is confusing In-Reply-To: References: Message-ID: The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. ---------------------------------------------------------------------- On Thu, 2 Mar 2023 20:00:56 GMT, Martin Buchholz wrote: > Inviting @DougLea and @viktorklang-ora to review. > > As usual, I couldn't resist more fiddling. > - Added missing tests for take, remove(), remove(Object). > - Improved DelayQueueTest's testing infrastructure > - added more test assertions > - linkified new javadoc definitions @Martin-Buchholz I think the updated documentation is clearer. We need some extra reviewers like @AlanBateman or @pron to sign off :) ------------- PR: https://git.openjdk.org/jdk/pull/12838 From asotona at openjdk.org Mon Mar 6 10:19:09 2023 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 6 Mar 2023 10:19:09 GMT Subject: RFR: 8294982: Implementation of Classfile API [v44] In-Reply-To: References: Message-ID: > This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. > > Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. > > Classfile API development is tracked at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch > > Development branch of consolidated JDK class files parsing, generating, and transforming is at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch > > Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. > > Please take you time to review this non-trivial JDK addition. > > Thank you, > Adam Adam Sotona has updated the pull request incrementally with four additional commits since the last revision: - Update src/java.base/share/classes/jdk/internal/classfile/impl/Util.java Co-authored-by: Paul Sandoz - Update src/java.base/share/classes/jdk/internal/classfile/impl/ClassPrinterImpl.java Co-authored-by: Paul Sandoz - Update src/java.base/share/classes/jdk/internal/classfile/impl/BootstrapMethodEntryImpl.java Co-authored-by: Paul Sandoz - Update src/java.base/share/classes/jdk/internal/classfile/impl/BootstrapMethodEntryImpl.java Co-authored-by: Paul Sandoz ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10982/files - new: https://git.openjdk.org/jdk/pull/10982/files/173dc1e7..b44f47ba Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=43 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=42-43 Stats: 19 lines in 3 files changed: 0 ins; 12 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/10982.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982 PR: https://git.openjdk.org/jdk/pull/10982 From asotona at openjdk.org Mon Mar 6 10:33:21 2023 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 6 Mar 2023 10:33:21 GMT Subject: RFR: 8294982: Implementation of Classfile API [v45] In-Reply-To: References: Message-ID: <6TKIHLmc-w5q1E44Bsmkm6keOkwiBPsO39JgVfYeBj0=.401cd699-ca11-48a4-98e0-e05e060cef6b@github.com> The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. ---------------------------------------------------------------------- > This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. > > Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. > > Classfile API development is tracked at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch > > Development branch of consolidated JDK class files parsing, generating, and transforming is at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch > > Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. > > Please take you time to review this non-trivial JDK addition. > > Thank you, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: Update src/java.base/share/classes/jdk/internal/classfile/impl/AttributeHolder.java Co-authored-by: Paul Sandoz ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10982/files - new: https://git.openjdk.org/jdk/pull/10982/files/b44f47ba..a40842c4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=44 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=43-44 Stats: 6 lines in 1 file changed: 0 ins; 5 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10982.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982 PR: https://git.openjdk.org/jdk/pull/10982 From asotona at openjdk.org Mon Mar 6 10:33:22 2023 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 6 Mar 2023 10:33:22 GMT Subject: RFR: 8294982: Implementation of Classfile API [v43] In-Reply-To: References: Message-ID: On Fri, 3 Mar 2023 21:56:39 GMT, Paul Sandoz wrote: >> Adam Sotona has updated the pull request incrementally with three additional commits since the last revision: >> >> - fixed AccessFlags javadoc >> - TransformImpl.FakeXyzTransform renamed to UnresolvedXyzTransform >> - removed obsolete generic parameter from AbstractDirectBuilder > > src/java.base/share/classes/jdk/internal/classfile/impl/AttributeHolder.java line 73: > >> 71: if (a.attributeMapper() == am) >> 72: iterator.remove(); >> 73: } > > Suggestion: > > attributes.removeIf(a -> a.attributeMappter() == am); > > But presumably use an inner class instead. I can understand because of that if you want to keep the existing code instead. It seems to be OK to use lambda here (not on critical JDK bootstrap path), thanks. ------------- PR: https://git.openjdk.org/jdk/pull/10982 From duke at openjdk.org Mon Mar 6 11:08:42 2023 From: duke at openjdk.org (Ravali Yatham) Date: Mon, 6 Mar 2023 11:08:42 GMT Subject: RFR: 8302791: Add specific ClassLoader object to Proxy IllegalArgumentException message [v6] In-Reply-To: References: Message-ID: > Added specific class loader object to proxy IllegalArgumentException from which the class was not visible > > The bug report for the same: https://bugs.openjdk.org/browse/JDK-8302791 Ravali Yatham has updated the pull request incrementally with one additional commit since the last revision: Added JavaLangAccess::getLoaderNameID(ClassLoader loader) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12641/files - new: https://git.openjdk.org/jdk/pull/12641/files/ba561eef..2dd5fbc5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12641&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12641&range=04-05 Stats: 24 lines in 4 files changed: 14 ins; 9 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12641.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12641/head:pull/12641 PR: https://git.openjdk.org/jdk/pull/12641 From duke at openjdk.org Mon Mar 6 11:08:42 2023 From: duke at openjdk.org (Ravali Yatham) Date: Mon, 6 Mar 2023 11:08:42 GMT Subject: RFR: 8302791: Add specific ClassLoader object to Proxy IllegalArgumentException message [v4] In-Reply-To: References: <0jQQEOJWyqjmAP3UgPGk7V1muce0Yx14nWIlBnkOgas=.095d14d8-ee3c-4089-bb62-6f7d1c0100d5@github.com> <2R2lxJGzA5rDl4k2PSsKI6fIZ-ob8HdbSrWtKfRyv9M=.9d24250a-3d90-497c-af37-f672b4398bc0@github.com> Message-ID: On Thu, 2 Mar 2023 20:00:24 GMT, Mandy Chung wrote: >>> Thanks @AlanBateman. Regarding the separator, Have seen this being used in ClassLoader.java for nameAndId method. Hence used the same for consistency. I've reformatted L886 now, Please kindly check. >> >> Thanks for checking, the updated version looks good. > > I suggest to add a `JavaLangAccess::getLoaderNameID(ClassLoader loader)` so that Proxy (and other classes) can use the same representation. > > The patch will look like this: > > > diff --git a/src/java.base/share/classes/java/lang/ClassLoader.java b/src/java.base/share/classes/java/lang/ClassLoader.java > index 2bc9a22700a..f412ecfa3ae 100644 > --- a/src/java.base/share/classes/java/lang/ClassLoader.java > +++ b/src/java.base/share/classes/java/lang/ClassLoader.java > @@ -407,6 +407,10 @@ public abstract class ClassLoader { > return nid; > } > > + String nameAndId() { > + return nameAndId; > + } > + > /** > * Creates a new class loader of the specified name and using the > * specified parent class loader for delegation. > diff --git a/src/java.base/share/classes/java/lang/System.java b/src/java.base/share/classes/java/lang/System.java > index 501ed47fcad..c138ea9fef5 100644 > --- a/src/java.base/share/classes/java/lang/System.java > +++ b/src/java.base/share/classes/java/lang/System.java > @@ -2663,6 +2663,10 @@ public final class System { > Continuation continuation) { > return StackWalker.newInstance(options, null, contScope, continuation); > } > + > + public String getLoaderNameID(ClassLoader loader) { > + return loader.nameAndId(); > + } > }); > } > } > diff --git a/src/java.base/share/classes/java/lang/reflect/Proxy.java b/src/java.base/share/classes/java/lang/reflect/Proxy.java > index 6064dcf5b6b..a2a9a03e6c4 100644 > --- a/src/java.base/share/classes/java/lang/reflect/Proxy.java > +++ b/src/java.base/share/classes/java/lang/reflect/Proxy.java > @@ -878,7 +878,7 @@ public class Proxy implements java.io.Serializable { > } > if (type != c) { > throw new IllegalArgumentException(c.getName() + > - " referenced from a method is not visible from class loader"); > + " referenced from a method is not visible from class loader: " + JLA.getLoaderNameID(ld)); > } > } > > diff --git a/src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java b/src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java > index 39adfb2130a..4720e589efb 100644 > --- a/src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java > +++ b/src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java > @@ -564,4 +564,6 @@ public interface JavaLangAccess { > StackWalker newStackWalkerInstance(Set options, > ContinuationScope contScope, > Continuation continuation); > + > + String getLoaderNameID(ClassLoader loader); > } @mlchung - Thanks for suggesting this so as to reuse the existing `nameAndId` functionality in Proxy class. I've pushed new commit, Please kindly review. ------------- PR: https://git.openjdk.org/jdk/pull/12641 From jpai at openjdk.org Mon Mar 6 11:13:08 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 6 Mar 2023 11:13:08 GMT Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x [v2] In-Reply-To: <3z7u66KVgFfL7S7S4uxDtOA6gD-WkNU7R-zon0trIVg=.d27446ca-c11d-49cc-bb85-b162e5ac58f2@github.com> References: <3z7u66KVgFfL7S7S4uxDtOA6gD-WkNU7R-zon0trIVg=.d27446ca-c11d-49cc-bb85-b162e5ac58f2@github.com> Message-ID: On Thu, 2 Feb 2023 08:27:55 GMT, Amit Kumar wrote: >> DeInflate.java test fails on s390x platform because size for out1 array which is responsible for storing the compressed data is insufficient. And being unable to write whole compressed data on array, on s390 whole data can't be recovered after compression. So this fix increase Array size (for s390). > > Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: > > change acc to Alan comments Thank you Amit for running this test. So the custom zlib implementation does indeed returns false for `needsInput()`, which is a good thing. Based on the tests so far, what this suggests to me is that the `deflate` implementation of this custom `zlib` library compresses the data to a size larger than what this test expects. It isn't clear how large it is going to be or whether it will always be the same size after deflate, based on what you note: > But I guess this behaviour could be explained (by zEDC). On s390x, there is additional instruction present and it could be enabled by setting DFLTCC=1. And for accelerator the size of compressed data could go2 times the size of actual data. Again this is not deterministic as well, i.e. for same data there could be different valid deflate stream. This specific test `DeInflate` notes that it's there for basic deflate and inflate testing. As far as I can see, there's nothing in the specification of `Deflater#deflate()` which states that the current size of the output buffer that the test uses is mandated/expected by spec: > byte[] dataOut1 = new byte[dataIn.length + 1024]; So `1024` is a reasonable extra length that the test has been using successfully so far. It appears that this is not enough on s390x with this custom implementation of zlib. I believe it doesn't violate any spec. So your proposed change (which Alan recommended) to use a `ByteArrayOutputStream` to keep accumulating the deflated (and later inflated) data, until the deflater is `finished()` sounds fine to me. The important thing here is that the inflated content from this deflated content matches the original input. From what I see in this discussion, with these changes, it does indeed match and thus the test passes. So I think that's a good thing. Now coming to this proposed patch, now that you are using local ByteArrayOutputStream(s) for the deflate/inflate part in this `check()` method, I think the `out1` and `out2` should no longer be needed in this method and thus the method signature can be changed to remove these params. I see that this is the only place where this method is used, so changing the method signature of `check()` should be OK and shouldn't impact other parts of the test. While we are at it, just for the sake of testing, undo the changes I suggested in my last reply and use the current PR's code (afresh) and print out the length of the final deflated content, something like: out1 = baos.toByteArray(); System.out.println("Deflated length is: " + out1.length + " for input of length: " + len); I'm curious how large the deflated content would be. Finally, are you or someone in your team, in contact with the author(s) of the custom zlib implementation https://github.com/iii-i/zlib/commit/113203437eda67261848b14b6c80a33ff7e33d34? Would you be able to ask for their inputs on whether this (large?) difference in the deflated content size expected and are there any specific input (sizes) that this shows up or is it for all inputs? Finally, I would wait to hear from Alan or Lance on whether these changes are OK, given the results of the experiments we have seen so far. ------------- PR: https://git.openjdk.org/jdk/pull/12283 From amitkumar at openjdk.org Mon Mar 6 11:54:16 2023 From: amitkumar at openjdk.org (Amit Kumar) Date: Mon, 6 Mar 2023 11:54:16 GMT Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x [v2] In-Reply-To: <3z7u66KVgFfL7S7S4uxDtOA6gD-WkNU7R-zon0trIVg=.d27446ca-c11d-49cc-bb85-b162e5ac58f2@github.com> References: <3z7u66KVgFfL7S7S4uxDtOA6gD-WkNU7R-zon0trIVg=.d27446ca-c11d-49cc-bb85-b162e5ac58f2@github.com> Message-ID: <-mFGxclAbcys2bvCY8Gi2yJlo85XGcSyXecck82Hj8Q=.e1dc7e1d-9e6d-4b89-a51e-7c4de8469867@github.com> On Thu, 2 Feb 2023 08:27:55 GMT, Amit Kumar wrote: >> DeInflate.java test fails on s390x platform because size for out1 array which is responsible for storing the compressed data is insufficient. And being unable to write whole compressed data on array, on s390 whole data can't be recovered after compression. So this fix increase Array size (for s390). > > Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: > > change acc to Alan comments Hi Jaikiran, Thank you so much for your inputs :-) >While we are at it, just for the sake of testing, undo the changes I suggested in my last reply and use the current PR's code (afresh) and print out the length of the final deflated content, something like: >``` >out1 = baos.toByteArray(); >System.out.println("Deflated length is: " + out1.length + " for input of length: " + len); >``` >I'm curious how large the deflated content would be. I guess this is what you want to see ? > `initial size: 525312` > > error I'm facing is on level 1 not on -1. > > ``` > level:1, strategy: 0, dowrap: false > required size: 553018 <- there is an issue > required size: 283432 > required size: 526225 <- there is an issue > required size: 301127 > required size: 409196 > level:1, strategy: 0, dowrap: true > required size: 553012 <- there is an issue > required size: 44541 > required size: 414324 > required size: 289230 > required size: 176785 > ``` > > this is result for executing test case 2nd time: > > ``` > level:1, strategy: 0, dowrap: false > required size: 552979 <- there is an issue > required size: 549979 <- there is an issue > required size: 49738 > required size: 116661 > required size: 439574 > level:1, strategy: 0, dowrap: true > required size: 552973 <- there is an issue > required size: 466730 > required size: 509795 > required size: 94907 > required size: 476173 > ``` > > All other levels are okay, this could be explained by Ilya's patch. What states that `hardware` compression will be used on level 1 and `software` compression will be used on all other levels. >Capacity with out1 * 32: 557056 <-> Buffer we need 552981 >Capacity with out1 * 32: 557056 <-> Buffer we need 552975 >Initial size of out1: 525312 ------------- PR: https://git.openjdk.org/jdk/pull/12283 From jpai at openjdk.org Mon Mar 6 12:25:19 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 6 Mar 2023 12:25:19 GMT Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x [v2] In-Reply-To: <3z7u66KVgFfL7S7S4uxDtOA6gD-WkNU7R-zon0trIVg=.d27446ca-c11d-49cc-bb85-b162e5ac58f2@github.com> References: <3z7u66KVgFfL7S7S4uxDtOA6gD-WkNU7R-zon0trIVg=.d27446ca-c11d-49cc-bb85-b162e5ac58f2@github.com> Message-ID: On Thu, 2 Feb 2023 08:27:55 GMT, Amit Kumar wrote: >> DeInflate.java test fails on s390x platform because size for out1 array which is responsible for storing the compressed data is insufficient. And being unable to write whole compressed data on array, on s390 whole data can't be recovered after compression. So this fix increase Array size (for s390). > > Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: > > change acc to Alan comments > I guess this is what you want to see ? > > > level:1, strategy: 0, dowrap: false > required size: 553018 <- there is an issue Yes, thank you. So to summarize, an input of size `524288` bytes gets "compressed"/deflated to a size of `553018` i.e. it _adds_ `28730` bytes, when level 1 deflater level (`BEST_SPEED`) is used and the custom zlib's hardware instruction is triggered. That, in my opinion, is odd (adding that many additional bytes for compressed data). So I think it would be good to get the team which did the zlib change involved in this discussion to understand if this large an impact is expected. And if so, is it for all inputs or if there's some issue that needs to be looked into in the implementation. Would you or someone in your team be able to get their attention to this? ------------- PR: https://git.openjdk.org/jdk/pull/12283 From amitkumar at openjdk.org Mon Mar 6 12:29:17 2023 From: amitkumar at openjdk.org (Amit Kumar) Date: Mon, 6 Mar 2023 12:29:17 GMT Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x [v2] In-Reply-To: <3z7u66KVgFfL7S7S4uxDtOA6gD-WkNU7R-zon0trIVg=.d27446ca-c11d-49cc-bb85-b162e5ac58f2@github.com> References: <3z7u66KVgFfL7S7S4uxDtOA6gD-WkNU7R-zon0trIVg=.d27446ca-c11d-49cc-bb85-b162e5ac58f2@github.com> Message-ID: On Thu, 2 Feb 2023 08:27:55 GMT, Amit Kumar wrote: >> DeInflate.java test fails on s390x platform because size for out1 array which is responsible for storing the compressed data is insufficient. And being unable to write whole compressed data on array, on s390 whole data can't be recovered after compression. So this fix increase Array size (for s390). > > Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: > > change acc to Alan comments Hi JaiKiran, I already sent a request to Ilya, for his input on this PR. ------------- PR: https://git.openjdk.org/jdk/pull/12283 From asotona at openjdk.org Mon Mar 6 12:39:42 2023 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 6 Mar 2023 12:39:42 GMT Subject: RFR: 8294982: Implementation of Classfile API [v46] In-Reply-To: References: Message-ID: <5KOqaE0qBdUe95-bih4iXcBofTUvyRPbqA7sYWtliho=.1a8275d7-72ff-4ee0-915c-99b3e437dacb@github.com> > This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. > > Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. > > Classfile API development is tracked at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch > > Development branch of consolidated JDK class files parsing, generating, and transforming is at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch > > Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. > > Please take you time to review this non-trivial JDK addition. > > Thank you, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: removed unused methods, fields and parameters added missing overrides fixed pointless operations and possible null pointer dereferences ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10982/files - new: https://git.openjdk.org/jdk/pull/10982/files/a40842c4..61ff1c7c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=45 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=44-45 Stats: 297 lines in 35 files changed: 58 ins; 121 del; 118 mod Patch: https://git.openjdk.org/jdk/pull/10982.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982 PR: https://git.openjdk.org/jdk/pull/10982 From asotona at openjdk.org Mon Mar 6 12:39:47 2023 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 6 Mar 2023 12:39:47 GMT Subject: RFR: 8294982: Implementation of Classfile API [v43] In-Reply-To: References: Message-ID: On Fri, 3 Mar 2023 21:44:24 GMT, Paul Sandoz wrote: >> Adam Sotona has updated the pull request incrementally with three additional commits since the last revision: >> >> - fixed AccessFlags javadoc >> - TransformImpl.FakeXyzTransform renamed to UnresolvedXyzTransform >> - removed obsolete generic parameter from AbstractDirectBuilder > > src/java.base/share/classes/jdk/internal/classfile/impl/AbstractInstruction.java line 683: > >> 681: public UnboundInstruction(Opcode op, int size) { >> 682: super(op, size); >> 683: } > > Unused? fixed, thanks. > src/java.base/share/classes/jdk/internal/classfile/impl/AnnotationReader.java line 99: > >> 97: } >> 98: >> 99: public static List> readParameterAnnotations(ClassReader classReader, int p, boolean isVisible) { > > Parameter `isVisible` is unused, but method is called with true/false values. fixed, thanks. > src/java.base/share/classes/jdk/internal/classfile/impl/AttributeHolder.java line 76: > >> 74: } >> 75: >> 76: List> attributes() { > > Unused fixed, thanks. > src/java.base/share/classes/jdk/internal/classfile/impl/BufferedMethodBuilder.java line 54: > >> 52: private final List elements = new ArrayList<>(); >> 53: private final SplitConstantPool constantPool; >> 54: private final ClassEntry thisClass; > > Unused. Can be removed as can the associated constructor parameter. fixed, thanks. ------------- PR: https://git.openjdk.org/jdk/pull/10982 From dfuchs at openjdk.org Mon Mar 6 12:48:13 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 6 Mar 2023 12:48:13 GMT Subject: RFR: 8303392: Runtime.exec and ProcessBuilder.start should use System logger [v2] In-Reply-To: References: <-1i11ZrHHgzUbCSa_RXAcGKNfgtpdui--bltZ4Ujs2A=.f5f1a7e2-d3ec-4f64-9b1e-317ef2f24ef1@github.com> Message-ID: On Sat, 4 Mar 2023 14:22:33 GMT, Roger Riggs wrote: >> Runtime.exec and ProcessBuilder.start methods create a new operating system process with the program and arguments. Many applications configure a logging subsystem to monitor application events. Logging a process start message with the program, arguments, and stack trace can identify the caller and purpose. >> Logging the process start event is complementary to the process start event generated for JFR (Java Flight Recorder). > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Add javadoc @implNote to Runtime.exec and ProcessBuilder methods src/java.base/share/classes/java/lang/ProcessBuilder.java line 1148: > 1146: ", pid: " + process.pid()); > 1147: } catch (Throwable thEx) {/* ignore */} > 1148: } Is it really useful to try & catch a potential exception here, or wouldn't be better to let it propagate to the caller? An exception here would indicate a bug somewhere either in the logging backend or in the logging configuration - or possibly OOM or any other kind of VM error and maybe it would be better to just fail in that case, and let the VM exit (unless that exception is caught down the road by the caller?) I understand why we would not want an exception in logging to prevent System.exit() from exiting, but surely the same constraint doesn't hold for `ProcessBuilder::start`? ------------- PR: https://git.openjdk.org/jdk/pull/12862 From duke at openjdk.org Mon Mar 6 13:16:10 2023 From: duke at openjdk.org (Ilya Leoshkevich) Date: Mon, 6 Mar 2023 13:16:10 GMT Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x [v2] In-Reply-To: <3z7u66KVgFfL7S7S4uxDtOA6gD-WkNU7R-zon0trIVg=.d27446ca-c11d-49cc-bb85-b162e5ac58f2@github.com> References: <3z7u66KVgFfL7S7S4uxDtOA6gD-WkNU7R-zon0trIVg=.d27446ca-c11d-49cc-bb85-b162e5ac58f2@github.com> Message-ID: <-wkW0TuI0kpzf9WxyUjqcVWZ8Q1mHMCwrWpCcCvGIwM=.b2eb9493-d0d3-408b-aa7b-26bbae671914@github.com> On Thu, 2 Feb 2023 08:27:55 GMT, Amit Kumar wrote: >> DeInflate.java test fails on s390x platform because size for out1 array which is responsible for storing the compressed data is insufficient. And being unable to write whole compressed data on array, on s390 whole data can't be recovered after compression. So this fix increase Array size (for s390). > > Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: > > change acc to Alan comments > Finally, are you or someone in your team, in contact with the author(s) of the custom zlib implementation [iii-i/zlib at 1132034](https://github.com/iii-i/zlib/commit/113203437eda67261848b14b6c80a33ff7e33d34)? Would you be able to ask for their inputs on whether this (large?) difference in the deflated content size expected and are there any specific input (sizes) that this shows up or is it for all inputs? This can happen for any poorly compressible inputs, regardless of their size. Here is the calculation for the worst case: https://github.com/iii-i/zlib/blob/dfltcc-20230109/contrib/s390/dfltcc.h#L17 (TL;DR: the size can double), but, of course, we don't expect this to be happening often. Here are some benchmarking results: https://github.com/iii-i/zlib-ng/wiki/Performance-with-dfltcc-patch-applied-and-dfltcc-support-built-on-dfltcc-enabled-machine. The interesting data is in column `compressed_size` where `level` is 1. This is the hardware compressed size divided by the software compressed size. Most of the time it's +5-20%, in a few cases it compresses better than software, and only in one case (kennedy.xls) we see a big difference of +44%. ------------- PR: https://git.openjdk.org/jdk/pull/12283 From asotona at openjdk.org Mon Mar 6 13:23:02 2023 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 6 Mar 2023 13:23:02 GMT Subject: RFR: 8294982: Implementation of Classfile API [v43] In-Reply-To: <2sq9xOJ5ZPAgrWj9cBR1wRdGhHdIteZh8FkXratspQs=.3b804f36-2531-4504-b274-3237b84dfdbd@github.com> References: <2sq9xOJ5ZPAgrWj9cBR1wRdGhHdIteZh8FkXratspQs=.3b804f36-2531-4504-b274-3237b84dfdbd@github.com> Message-ID: The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. ---------------------------------------------------------------------- On Fri, 3 Mar 2023 23:12:17 GMT, Paul Sandoz wrote: >> Adam Sotona has updated the pull request incrementally with three additional commits since the last revision: >> >> - fixed AccessFlags javadoc >> - TransformImpl.FakeXyzTransform renamed to UnresolvedXyzTransform >> - removed obsolete generic parameter from AbstractDirectBuilder > > src/java.base/share/classes/jdk/internal/classfile/impl/Util.java line 161: > >> 159: var desc = cd.descriptorString(); >> 160: return switch (desc.charAt(0)) { >> 161: case '[' -> desc; > > Is this correct? Arrays don't have an internal name. It is a workaround to get CP class entry name string from descriptor, so the `toInternalName` is not exact. I'll handle the array descriptors separately and let this method to handle real class internal names only. ------------- PR: https://git.openjdk.org/jdk/pull/10982 From jpai at openjdk.org Mon Mar 6 13:24:38 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 6 Mar 2023 13:24:38 GMT Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x [v2] In-Reply-To: <-wkW0TuI0kpzf9WxyUjqcVWZ8Q1mHMCwrWpCcCvGIwM=.b2eb9493-d0d3-408b-aa7b-26bbae671914@github.com> References: <3z7u66KVgFfL7S7S4uxDtOA6gD-WkNU7R-zon0trIVg=.d27446ca-c11d-49cc-bb85-b162e5ac58f2@github.com> <-wkW0TuI0kpzf9WxyUjqcVWZ8Q1mHMCwrWpCcCvGIwM=.b2eb9493-d0d3-408b-aa7b-26bbae671914@github.com> Message-ID: <_nwt1UCGp9ryA1dYOxUYylwPtsSF74hEUw81kSbNzms=.6539dbbb-98c6-459c-b86a-f302178bfd9b@github.com> On Mon, 6 Mar 2023 13:10:57 GMT, Ilya Leoshkevich wrote: >> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: >> >> change acc to Alan comments > >> Finally, are you or someone in your team, in contact with the author(s) of the custom zlib implementation [iii-i/zlib at 1132034](https://github.com/iii-i/zlib/commit/113203437eda67261848b14b6c80a33ff7e33d34)? Would you be able to ask for their inputs on whether this (large?) difference in the deflated content size expected and are there any specific input (sizes) that this shows up or is it for all inputs? > > This can happen for any poorly compressible inputs, regardless of their size. Here is the calculation for the worst case: https://github.com/iii-i/zlib/blob/dfltcc-20230109/contrib/s390/dfltcc.h#L17 (TL;DR: the size can double), but, of course, we don't expect this to be happening often. > > Here are some benchmarking results: https://github.com/iii-i/zlib-ng/wiki/Performance-with-dfltcc-patch-applied-and-dfltcc-support-built-on-dfltcc-enabled-machine. The interesting data is in column `compressed_size` where `level` is 1. This is the hardware compressed size divided by the software compressed size. Most of the time it's +5-20%, in a few cases it compresses better than software, and only in one case (kennedy.xls) we see a big difference of +44%. > > P.S. Here we are compressing random data, if I read the testcase correctly (`rnd.nextBytes(dataIn);`), so poor results are expected. Ideally we should emit stored blocks, but the hardware engine does not support this at the moment. @iii-i Thank you Ilya for those details. I haven't fully caught up with them, but while you are here - In the benchmarking table, are the "compress_cpu" and the "compress_wall" too ratios of hardware compress time to software compress time for level 1 (BEST_SPEED)? ------------- PR: https://git.openjdk.org/jdk/pull/12283 From duke at openjdk.org Mon Mar 6 13:27:19 2023 From: duke at openjdk.org (Ilya Leoshkevich) Date: Mon, 6 Mar 2023 13:27:19 GMT Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x [v2] In-Reply-To: <3z7u66KVgFfL7S7S4uxDtOA6gD-WkNU7R-zon0trIVg=.d27446ca-c11d-49cc-bb85-b162e5ac58f2@github.com> References: <3z7u66KVgFfL7S7S4uxDtOA6gD-WkNU7R-zon0trIVg=.d27446ca-c11d-49cc-bb85-b162e5ac58f2@github.com> Message-ID: On Thu, 2 Feb 2023 08:27:55 GMT, Amit Kumar wrote: >> DeInflate.java test fails on s390x platform because size for out1 array which is responsible for storing the compressed data is insufficient. And being unable to write whole compressed data on array, on s390 whole data can't be recovered after compression. So this fix increase Array size (for s390). > > Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: > > change acc to Alan comments Right, and that's the main selling point of the accelerator - it can be up to 100x faster than software (this is reached with the enwik8, mozilla and sao benchmarks). ------------- PR: https://git.openjdk.org/jdk/pull/12283 From alexey.ivanov at oracle.com Mon Mar 6 13:28:00 2023 From: alexey.ivanov at oracle.com (Aleksei Ivanov) Date: Mon, 6 Mar 2023 13:28:00 +0000 Subject: Testing no memory leak occurs via references In-Reply-To: <5e0f77c6-446b-a533-0783-db7f554861c3@oracle.com> References: <5e0f77c6-446b-a533-0783-db7f554861c3@oracle.com> Message-ID: <309de0aa-51e9-ca62-da86-9774983b14af@oracle.com> Thank you, Stuart and Roger, for the suggestion. I didn't know about ForceGC class. We should use the common library, I have updated my PR [7] with ForceGC. Albert and Thomas suggested using WhiteBox API. It would probably work too, however, I decided ForceGC is simpler and easier to use, so I went for it. It does its job and it's used in core-libs tests. Thanks to everyone who provided their input, I appreciate your help. -- Regards, Alexey [7]? https://github.com/openjdk/jdk/pull/12594 On 03/03/2023 22:54, Stuart Marks wrote: > > As Roger mentioned, there is a ForceGC utility in the test library: > > ??? test/lib/jdk/test/lib/util/ForceGC.java > > and it's used in a variety of places in the core libs tests. > Essentially it sets up a PhantomReference and a ReferenceQueue and > runs System.gc() in a loop. I'd strongly recommend using this in > preference to allocating a lot of memory in order to provoke > OutOfMemoryError. That technique has historically been a cause of test > flakiness, and it still is, as you've discovered. > > There is also MemoryMXBean.gc(), which does the same thing System.gc() > does -- it calls Runtime.getRuntime().gc(). > > It's true that System.gc() may sometimes be ignored -- for instance if > Epsilon GC is enabled -- but for practical purposes, on Hotspot using > a standard collector, calling it will eventually cause garbage > collection and reference processing. > > If at some point the behavior provided by System.gc() is inadequate > for our testing, we'll need to plumb a JDK-specific interface that has > stronger semantics, and then convert ForceGC to use it so that > individual tests won't have to be updated. > > There are still some tests that allocate lots of memory in order to > provoke OOME and consequently reference processing. They probably need > to be run in /othervm mode in order to set custom heap sizes and to > avoid interfering with other tests. It would be interesting to see if > those could be adjusted to use something ForceGC so that they can > share the JVM with other tests and also avoid allocating lots of memory. > > s'marks > > > On 3/3/23 10:02 AM, Aleksei Ivanov wrote: >> Hello, >> >> In clientlibs, there's occasionally a need to verify an object isn't >> leaked. For this purpose, WeakReference or PhantomReference is used. >> >> Then, we need to make the reference object be cleared, so a GC cycle >> need to be triggered. The common approach is generating >> OutOfMemoryError, catching it and verifying whether the reference is >> cleared. >> >> Some tests use a utility method regtesthelpers/Util.generateOOME [1]. >> >> For example, these tests follow the above approach: >> https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/border/TestTitledBorderLeak.java >> https://github.com/openjdk/jdk/blob/master/test/jdk/java/awt/List/ListGarbageCollectionTest/AwtListGarbageCollectionTest.java >> >> >> The AwtListGarbageCollectionTest.java test started to fail pretty >> often in the end of January 2023. >> >> I followed a piece of advice provided in a JBS comment for >> JDK-8300727 [2] and replaced generating OOME with a simple call to >> System.gc() along with adding a loop for re-trying. >> >> The specification for System.gc() [3] mentions that this call can be >> ignored, which started a discussion in the PR #12594 [4] that >> System.gc() should not be used, at the very least without generating >> OOME in addition to invoking System.gc(). >> >> At the same time, many tests for Reference objects, such as >> ReferenceEnqueue.java [5] and PhantomReferentClearing.java [6], rely >> solely on System.gc. >> >> >> What would be your recommendation? Are there best practices in >> core-libs and hotspot for testing for memory leaks that clientlibs >> should follow? >> >> >> -- >> Regards, >> Alexey >> >> [1] >> https://github.com/openjdk/jdk/blob/29ee7c3b70ded8cd124ca5b4a38a2aee7c39068b/test/jdk/javax/swing/regtesthelpers/Util.java#L87 >> [2] https://bugs.openjdk.org/browse/JDK-8300727 >> [3] >> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/System.html#gc() >> [4] https://github.com/openjdk/jdk/pull/12594 >> [5] >> https://github.com/openjdk/jdk/blob/f612dcfebea7ffd4390f833646ad45d6f0ebd04f/test/jdk/java/lang/ref/ReferenceEnqueue.java#L54-L60 >> [6] >> https://github.com/openjdk/jdk/blob/f612dcfebea7ffd4390f833646ad45d6f0ebd04f/test/jdk/java/lang/ref/PhantomReferentClearing.java#L85-L92 From duke at openjdk.org Mon Mar 6 13:35:08 2023 From: duke at openjdk.org (Viktor Klang) Date: Mon, 6 Mar 2023 13:35:08 GMT Subject: RFR: JDK-8302360 Atomic*.compareAndExchange Javadoc unclear Message-ID: I think the following proposal is very non-invasive and merely draws attention to the fact that "witness value" is a specific term related to the notion of these atomic methods. It's a small change which I think provides additional clarity, see JBS for the discussion on the topic. ------------- Commit messages: - JDK-8302360 : Adding emphasis to the witness value term in the JavaDoc Changes: https://git.openjdk.org/jdk/pull/12880/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12880&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8302360 Stats: 34 lines in 8 files changed: 0 ins; 0 del; 34 mod Patch: https://git.openjdk.org/jdk/pull/12880.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12880/head:pull/12880 PR: https://git.openjdk.org/jdk/pull/12880 From jpai at openjdk.org Mon Mar 6 13:42:16 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 6 Mar 2023 13:42:16 GMT Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x [v2] In-Reply-To: <-wkW0TuI0kpzf9WxyUjqcVWZ8Q1mHMCwrWpCcCvGIwM=.b2eb9493-d0d3-408b-aa7b-26bbae671914@github.com> References: <3z7u66KVgFfL7S7S4uxDtOA6gD-WkNU7R-zon0trIVg=.d27446ca-c11d-49cc-bb85-b162e5ac58f2@github.com> <-wkW0TuI0kpzf9WxyUjqcVWZ8Q1mHMCwrWpCcCvGIwM=.b2eb9493-d0d3-408b-aa7b-26bbae671914@github.com> Message-ID: On Mon, 6 Mar 2023 13:10:57 GMT, Ilya Leoshkevich wrote: > P.S. Here we are compressing random data, if I read the testcase correctly (rnd.nextBytes(dataIn);), Yes, you read it right. ------------- PR: https://git.openjdk.org/jdk/pull/12283 From albert.m.yang at oracle.com Mon Mar 6 13:51:09 2023 From: albert.m.yang at oracle.com (Albert Yang) Date: Mon, 6 Mar 2023 13:51:09 +0000 Subject: Testing no memory leak occurs via references In-Reply-To: <309de0aa-51e9-ca62-da86-9774983b14af@oracle.com> References: <5e0f77c6-446b-a533-0783-db7f554861c3@oracle.com> <309de0aa-51e9-ca62-da86-9774983b14af@oracle.com> Message-ID: Upon a cursory inspection of ForceGC.java, it seems that the fundamental logic involves waiting for a certain duration and relying on chance. However, I am of the opinion that utilizing the WhiteBox API can provide greater determinism and potentially strengthen some of the assertions. > I decided ForceGC is simpler and easier to use I was not aware of your specific requirements, so I cannot say for certain which approach is best. (However, it is worth noting that the WhiteBox API can be utilized to implement ForceGC if necessary.) /Albert From asotona at openjdk.org Mon Mar 6 14:06:38 2023 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 6 Mar 2023 14:06:38 GMT Subject: RFR: 8294982: Implementation of Classfile API [v47] In-Reply-To: References: Message-ID: <7pAuhkeIO5VRhdvaEKI1DPOFotFCpBU5-IRLAu5cM54=.826cea3c-8038-44e9-8c48-ba0e19734ce4@github.com> > This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. > > Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. > > Classfile API development is tracked at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch > > Development branch of consolidated JDK class files parsing, generating, and transforming is at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch > > Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. > > Please take you time to review this non-trivial JDK addition. > > Thank you, > Adam Adam Sotona has updated the pull request incrementally with two additional commits since the last revision: - simplified CodeImpl.SINGLETON_INSTRUCTIONS initialization - fixed handling of array descriptors by Util::toInternalName ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10982/files - new: https://git.openjdk.org/jdk/pull/10982/files/61ff1c7c..46fffe40 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=46 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=45-46 Stats: 60 lines in 7 files changed: 0 ins; 34 del; 26 mod Patch: https://git.openjdk.org/jdk/pull/10982.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982 PR: https://git.openjdk.org/jdk/pull/10982 From asotona at openjdk.org Mon Mar 6 14:06:41 2023 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 6 Mar 2023 14:06:41 GMT Subject: RFR: 8294982: Implementation of Classfile API [v43] In-Reply-To: References: Message-ID: <3jw5w8BFj4j00lheVoarG3sVII1G5c3ck5zTQlvl3b0=.aff3e199-85d8-4795-9411-1c04ae9b5c74@github.com> On Fri, 3 Mar 2023 22:35:48 GMT, Paul Sandoz wrote: >> Adam Sotona has updated the pull request incrementally with three additional commits since the last revision: >> >> - fixed AccessFlags javadoc >> - TransformImpl.FakeXyzTransform renamed to UnresolvedXyzTransform >> - removed obsolete generic parameter from AbstractDirectBuilder > > src/java.base/share/classes/jdk/internal/classfile/impl/CodeImpl.java line 52: > >> 50: static final Instruction[] SINGLETON_INSTRUCTIONS = new Instruction[256]; >> 51: >> 52: static { > > Can we loop through all `Opcode` values filter for `sizeIfFixed == 1` and switch on the kind? If so that would avoid the need for explicit lists and simplify the code. Yes, that is good idea. Fixed, thanks. ------------- PR: https://git.openjdk.org/jdk/pull/10982 From jlaskey at openjdk.org Mon Mar 6 14:11:55 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 6 Mar 2023 14:11:55 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v42] In-Reply-To: References: <9XP497xudeRhZKkIpxIgpbqT24eG8SCbfG6TelYtM3M=.f1ad5a76-798c-4e3d-b43b-a25a20210154@github.com> Message-ID: On Fri, 3 Mar 2023 19:42:53 GMT, Roger Riggs wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Tighten up reporting of string template errors (fewer messages) > > src/java.base/share/classes/java/util/FormatProcessor.java line 66: > >> 64: *

>> 65: * {@link FormatProcessor} format specification uses and exceptions are the same as >> 66: * those of {@link Formatter}. > > Suggestion: > > * The {@link FormatProcessor} format specification uses and exceptions are the same as > * those of {@link Formatter}. Changing. > src/java.base/share/classes/java/util/FormatProcessor.java line 134: > >> 132: * format string from the fragments, gathers up the values and >> 133: * evaluates the expression >> 134: * {@code new Formatter(locale).format(format, values).toString()}. > > Should this be described using the "as if"... phrasing to avoid a literal requirement in the spec that is inflexible? Changing > src/java.base/share/classes/java/util/FormatProcessor.java line 175: > >> 173: * {@link FormatProcessor#FMT} ({@code static final FormatProcessor}). >> 174: *

>> 175: * Other {@link FormatProcessor} can be specialized if stored as static final. > > Suggestion: > > * Other {@link FormatProcessor}s can be specialized if stored as a static final. Changing > src/java.base/share/classes/java/util/FormatProcessor.java line 187: > >> 185: * @throws IllegalFormatException >> 186: * If a format specifier contains an illegal syntax, a format >> 187: * specifier that is incompatible with the given arguments, > > Suggestion: > > * specifier is incompatible with the given arguments, Existing statement is consistent with those in Formatter. Reads more correctly as is. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Mon Mar 6 14:24:14 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 6 Mar 2023 14:24:14 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v42] In-Reply-To: <5YvuMA0QcACRyYG3hYiE9A5K2m0TB40R3OPzzAuoqRo=.27359ff9-1ce3-45df-a9bf-5674d57a333d@github.com> References: <9XP497xudeRhZKkIpxIgpbqT24eG8SCbfG6TelYtM3M=.f1ad5a76-798c-4e3d-b43b-a25a20210154@github.com> <5YvuMA0QcACRyYG3hYiE9A5K2m0TB40R3OPzzAuoqRo=.27359ff9-1ce3-45df-a9bf-5674d57a333d@github.com> Message-ID: On Sat, 4 Mar 2023 19:34:36 GMT, Marius Volkhart wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Tighten up reporting of string template errors (fewer messages) > > src/java.base/share/classes/java/lang/template/Carriers.java line 396: > >> 394: >> 395: /** >> 396: * Wrapper object for carrier data. Instances types are stored in the {@code objects} > > Suggestion: > > * Wrapper object for carrier data. Instance types are stored in the {@code objects} Changing > src/java.base/share/classes/java/lang/template/StringTemplate.java line 76: > >> 74: * produced that returns the same lists from {@link StringTemplate#fragments()} and >> 75: * {@link StringTemplate#values()} as shown above. The {@link StringTemplate#STR} template >> 76: * processor uses these lists to yield an interpolated string. the value of {@code s} will > > Suggestion: > > * processor uses these lists to yield an interpolated string. The value of {@code s} will Changing ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Mon Mar 6 14:24:18 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 6 Mar 2023 14:24:18 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v42] In-Reply-To: References: <9XP497xudeRhZKkIpxIgpbqT24eG8SCbfG6TelYtM3M=.f1ad5a76-798c-4e3d-b43b-a25a20210154@github.com> Message-ID: <1o1R5JiEv0hfQDksNEHsYwPv0BmLwKlK81xeqx_0arI=.5663b84d-5273-44ee-9ab4-f28400b1441a@github.com> The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. ---------------------------------------------------------------------- On Fri, 3 Mar 2023 20:17:24 GMT, Roger Riggs wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Tighten up reporting of string template errors (fewer messages) > > src/java.base/share/classes/java/lang/template/ProcessorLinkage.java line 37: > >> 35: >> 36: /** >> 37: * Policies using this additional interface have the flexibility to specialize > > Since it is 'sealed' it may clarify the use to say "Builtin policies"... Changing > src/java.base/share/classes/java/lang/template/StringProcessor.java line 58: > >> 56: /** >> 57: * Constructs a {@link String} based on the template fragments and values in the >> 58: * supplied {@link StringTemplate} object. > > Some inconsistency in the use of link/linkplain and the capitalization of stringTemplate, the instance or the type. > (As compared to TemplateProcessor.process(stringTemplate)) > Suggestion: > > * supplied {@link StringTemplate} object. Changing > src/java.base/share/classes/java/util/FormatProcessor.java line 42: > >> 40: * {@link Formatter} specifications and values found in the {@link StringTemplate}. >> 41: * Unlike {@link Formatter}, {@link FormatProcessor} uses the value from the >> 42: * embedded expression that immediately follows, no whitespace, after the > > Suggestion: > > * embedded expression that immediately follows, without whitespace, the Changing > src/java.base/share/classes/java/util/FormatProcessor.java line 80: > >> 78: * int x = 10; >> 79: * int y = 20; >> 80: * String result = thaiFMT."%d\{x} + %d\{y} = %d\{x + y}"; > > The inclusion of format specifiers that yield the same results as the default (%s) may mislead developers into thinking they need the format specifier. Making the examples look more complicated than necessary. > Can the examples, show customized output. > > Suggestion: > > * String result = thaiFMT."%d{x} + %d{y} = %d{x + y}"; Changing ------------- PR: https://git.openjdk.org/jdk/pull/10889 From asotona at openjdk.org Mon Mar 6 14:38:54 2023 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 6 Mar 2023 14:38:54 GMT Subject: RFR: 8294982: Implementation of Classfile API [v48] In-Reply-To: References: Message-ID: > This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. > > Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. > > Classfile API development is tracked at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch > > Development branch of consolidated JDK class files parsing, generating, and transforming is at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch > > Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. > > Please take you time to review this non-trivial JDK addition. > > Thank you, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: simplified initialization of terminal builder in chained builders ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10982/files - new: https://git.openjdk.org/jdk/pull/10982/files/46fffe40..0e43af66 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=47 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=46-47 Stats: 14 lines in 3 files changed: 0 ins; 2 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/10982.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982 PR: https://git.openjdk.org/jdk/pull/10982 From asotona at openjdk.org Mon Mar 6 14:40:16 2023 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 6 Mar 2023 14:40:16 GMT Subject: RFR: 8294982: Implementation of Classfile API [v20] In-Reply-To: <579H8pxWFy80yT9bwFjhQNp6UqWhPDIoQM3ykkneoHY=.53f8cf38-6682-483d-8c3b-44a8529533f6@github.com> References: <01V72lRVYH7rB1NrPpkVKhvj1mksmrelMMTMrHFQ2hk=.4b2c22f3-d9c6-4778-be53-1fb055969f6a@github.com> <579H8pxWFy80yT9bwFjhQNp6UqWhPDIoQM3ykkneoHY=.53f8cf38-6682-483d-8c3b-44a8529533f6@github.com> Message-ID: On Wed, 1 Mar 2023 10:05:27 GMT, Adam Sotona wrote: >> src/java.base/share/classes/jdk/internal/classfile/impl/ChainedFieldBuilder.java line 48: >> >>> 46: this.consumer = consumer; >>> 47: FieldBuilder b = downstream; >>> 48: while (b instanceof ChainedFieldBuilder cb) >> >> I'm probably missing something - but if `b` is another chained builder, instead of using a loop, can't we just skip to its `terminal` field? Also, the `downstream` field seems unused. (same considerations apply for `ChainedMethodBuilder` and `ChainedClassBuilder`). >> >> I note that `NonTerminalCodeBuilder` seems to be already doing what I suggest here (e.g. skip to `terminal`). > > I would have to test possible side-effects of the proposed shortcut to give you answer. > Thanks for pointing it out. Proposed shortcut seems to be OK, I've fixed it in `ChainedFieldBuilder`, `ChainedMethodBuilder` and `ChainedClassBuilder`. And removed unused `ChainedFieldBuilder.downstream` field. ------------- PR: https://git.openjdk.org/jdk/pull/10982 From mcimadamore at openjdk.org Mon Mar 6 14:52:41 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 6 Mar 2023 14:52:41 GMT Subject: RFR: 8303582: Reduce duplication in jdk/java/foreign tests In-Reply-To: References: Message-ID: On Fri, 3 Mar 2023 15:08:01 GMT, Jorn Vernee wrote: > Port of: https://github.com/openjdk/panama-foreign/pull/804 which reduces duplication in the test code by switching test value generation over to a common method in `NativeTestHelper`. Looks good (already reviewed in the panama repo) ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.org/jdk/pull/12856 From jvernee at openjdk.org Mon Mar 6 14:55:33 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 6 Mar 2023 14:55:33 GMT Subject: Integrated: 8303582: Reduce duplication in jdk/java/foreign tests In-Reply-To: References: Message-ID: On Fri, 3 Mar 2023 15:08:01 GMT, Jorn Vernee wrote: > Port of: https://github.com/openjdk/panama-foreign/pull/804 which reduces duplication in the test code by switching test value generation over to a common method in `NativeTestHelper`. This pull request has now been integrated. Changeset: dccfe8a2 Author: Jorn Vernee URL: https://git.openjdk.org/jdk/commit/dccfe8a2eedcead7f33f161f410222c7651398ef Stats: 503 lines in 13 files changed: 138 ins; 272 del; 93 mod 8303582: Reduce duplication in jdk/java/foreign tests Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.org/jdk/pull/12856 From roger.riggs at oracle.com Mon Mar 6 15:04:07 2023 From: roger.riggs at oracle.com (Roger Riggs) Date: Mon, 6 Mar 2023 10:04:07 -0500 Subject: Testing no memory leak occurs via references In-Reply-To: References: <5e0f77c6-446b-a533-0783-db7f554861c3@oracle.com> <309de0aa-51e9-ca62-da86-9774983b14af@oracle.com> Message-ID: Hi Albert, The only? downside of the WhiteBox API is the need to link and run with native code. It make adhoc testing more difficult. I would not say ForceGC relies on chance, since it is testing the specific condition as requested by the caller. It uses mechanisms available to normal applications and conditions they would encounter and not wait longer than necessary. Regards, Roger On 3/6/23 8:51 AM, Albert Yang wrote: > Upon a cursory inspection of ForceGC.java, it seems that the fundamental logic involves waiting for a certain duration and relying on chance. However, I am of the opinion that utilizing the WhiteBox API can provide greater determinism and potentially strengthen some of the assertions. > >> I decided ForceGC is simpler and easier to use > I was not aware of your specific requirements, so I cannot say for certain which approach is best. (However, it is worth noting that the WhiteBox API can be utilized to implement ForceGC if necessary.) > > /Albert From jvernee at openjdk.org Mon Mar 6 15:04:22 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 6 Mar 2023 15:04:22 GMT Subject: RFR: 8303604: Passing by-value structs whose size is not power of 2 doesn't work on all platforms (mainline) [v2] In-Reply-To: References: Message-ID: <4hxfUbMnBFnajGRHCdPVJexLh1F174xp9ddCisdoVsI=.74ae797a-cce7-4631-9706-1e42cdbc0e50@github.com> The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. ---------------------------------------------------------------------- > Port of: https://github.com/openjdk/panama-foreign/pull/806 which fixes an issue with passing structs whose size is not a power of two on SysV and AArch64 platforms. Jorn Vernee 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 OOB - 8303017: Passing by-value structs whose size is not power of 2 doesn't work on all platforms Reviewed-by: mcimadamore - remove byteWidthOfPrimitive for now - 8302990: Reduce duplication in test code 8293827: Padding computed by CallGeneratorHelper can be incorrect Reviewed-by: mcimadamore ------------- Changes: https://git.openjdk.org/jdk/pull/12863/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12863&range=01 Stats: 705 lines in 11 files changed: 652 ins; 2 del; 51 mod Patch: https://git.openjdk.org/jdk/pull/12863.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12863/head:pull/12863 PR: https://git.openjdk.org/jdk/pull/12863 From alexey.ivanov at oracle.com Mon Mar 6 15:11:23 2023 From: alexey.ivanov at oracle.com (Aleksei Ivanov) Date: Mon, 6 Mar 2023 15:11:23 +0000 Subject: Testing no memory leak occurs via references In-Reply-To: References: <5e0f77c6-446b-a533-0783-db7f554861c3@oracle.com> <309de0aa-51e9-ca62-da86-9774983b14af@oracle.com> Message-ID: <1dd51557-86c5-200f-a36f-b87d7e237813@oracle.com> On 06/03/2023 13:51, Albert Yang wrote: > Upon a cursory inspection of ForceGC.java, it seems that the fundamental logic involves waiting for a certain duration and relying on chance. However, I am of the opinion that utilizing the WhiteBox API can provide greater determinism and potentially strengthen some of the assertions. Yes, it calls System.gc in a loop and waits for a reference to become cleared. (It looks as if the body of ForceGC duplicates what one would have in the passed BooleanSupplier which again tests if a reference is cleared.) >> I decided ForceGC is simpler and easier to use > I was not aware of your specific requirements, so I cannot say for certain which approach is best. (However, it is worth noting that the WhiteBox API can be utilized to implement ForceGC if necessary.) My test is written to ensure awt.List gets garbage-collected when there are no strong references to it. Before JDK-8040076 had been fixed it wasn't. So the test creates awt.List, adds it to a frame, calls setMultipleMode(true) to enable multi-selection in the list component, removes it from the frame. At this point, I want to confirm the awt.List can be garbage-collected. The original test created a very long String to cause OutOfMemoryError and then verified whether the WeakReference to awt.List is cleared or not. In my first fix, I replaced generating OutOfMemoryError with a call to System.gc() in a loop and waited for the reference object to be cleared. Usually, the reference is cleared in the second iteration if not in the first one. Essentially, ForceGC does the same thing. So, it replaced my custom code with ForceGC. -- Alexey From jvernee at openjdk.org Mon Mar 6 15:21:45 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 6 Mar 2023 15:21:45 GMT Subject: Integrated: 8303604: Passing by-value structs whose size is not power of 2 doesn't work on all platforms (mainline) In-Reply-To: References: Message-ID: <2XeEa9aQCV8zwQNwKm4K6veyYfcK52kjvVEVu7iNUPw=.eba386b1-01b0-42bb-b9b7-632e242ba97a@github.com> The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. ---------------------------------------------------------------------- On Fri, 3 Mar 2023 19:27:24 GMT, Jorn Vernee wrote: > Port of: https://github.com/openjdk/panama-foreign/pull/806 which fixes an issue with passing structs whose size is not a power of two on SysV and AArch64 platforms. This pull request has now been integrated. Changeset: 5977f266 Author: Jorn Vernee URL: https://git.openjdk.org/jdk/commit/5977f266d04a7a9890665d433d0a2ab627573ca4 Stats: 705 lines in 11 files changed: 652 ins; 2 del; 51 mod 8303604: Passing by-value structs whose size is not power of 2 doesn't work on all platforms (mainline) Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.org/jdk/pull/12863 From lmesnik at openjdk.org Mon Mar 6 15:35:13 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 6 Mar 2023 15:35:13 GMT Subject: Integrated: 8303486: [REDO] Update ProcessTools.startProcess(...) to exit early if process exit before linePredicate is printed. In-Reply-To: References: Message-ID: <3qbZUBW7mR3lxnLEcB3eMXMaHvafWHFDxdFf76GkQhU=.f8a0490b-4044-443c-8366-e549e1004c67@github.com> On Wed, 1 Mar 2023 20:50:38 GMT, Leonid Mesnik wrote: > It is the 2nd attempt to fix > [JDK-8303133](https://bugs.openjdk.org/browse/JDK-8303133) Update ProcessTools.startProcess(...) to exit early if the process exit before linePredicate is printed. > > The first fix failed because it runs > Utils.waitForCondition(BooleanSupplier condition, long timeout, long sleepTime) { ..} > with 0 as no timeout and not -1 as required. This pull request has now been integrated. Changeset: ae8730fd Author: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/ae8730fd62b382564cda8749763b939aa2939225 Stats: 30 lines in 2 files changed: 18 ins; 3 del; 9 mod 8303486: [REDO] Update ProcessTools.startProcess(...) to exit early if process exit before linePredicate is printed. Reviewed-by: dholmes ------------- PR: https://git.openjdk.org/jdk/pull/12815 From roger.riggs at oracle.com Mon Mar 6 15:40:55 2023 From: roger.riggs at oracle.com (Roger Riggs) Date: Mon, 6 Mar 2023 10:40:55 -0500 Subject: UUID creation performance In-Reply-To: References: <608c81ee-cb3d-d142-c8fa-a1bcd9551975@oracle.com> Message-ID: <08526617-ab98-7ec0-9817-d1d793701eb4@oracle.com> Hi Brett, You might be trying to over optimize, making the source more complex than is useful or necessary. I think it is likely that on most architectures the varhandles take advantage of appropriate machine instructions and both have the same performance. I expect the performance difference to be barely noticeable, and if so keep it simple and direct. Even so, a localized static cache inUUID of whichever VarHandle is native would serve the purpose better than a runtime check. Regards, Roger On 3/5/23 6:49 PM, Brett Okken wrote: > The new ByteArray class works great for the nameUUIDFromBytes method, > which must be in big endian. > For randomUUID, byte order does not matter, so using native would be > fastest, but there does not appear to be a utility class for that. > Is there a preference of just having a native order VarHandle to use > in UUID vs. having a utility method which chooses which utility class > to call based on the native order vs. some other option? > > Thanks, > Brett > > On Wed, Mar 1, 2023 at 9:08?AM Roger Riggs wrote: >> Hi, >> >> That's an interesting idea. Recently VarHandle access methods were >> created by JDK-8300236 [1] [2] >> in the jdk.internal.util package. See the ByteArray and >> ByteArrayLittleEndian classes. >> >> See how that would affect performance and leverage existing VarHandles. >> >> Thanks, Roger >> >> [1] https://bugs.openjdk.org/browse/JDK-8300236 >> [2] https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/12076__;!!ACWV5N9M2RV99hQ!LF6TU_iFxi-lfSpZXjna9bCMPRs_gRvdXsfL5Tih6k2oYN94Hfb3sV_gBzdTvty-gXm0rzSgEZ0_xdQdYa7b05LArw$ >> >> On 3/1/23 7:50 AM, Brett Okken wrote: >>> Is there any interest in updating the static UUID.randomUUID() and >>> UUID.nameUUIDFromBytes(byte[]) factory methods to use either a >>> ByteBuffer or byteArrayViewVarHandle to convert the byte[] to 2 long >>> values then do the bit twiddling? >>> These methods are really dominated by time to create/populate the >>> byte[], but this does reduce the time to create the 2 long values by >>> at least half. >>> It would also allow the removal of the private UUID(byte[] data). >>> >>> public static UUID randomUUID() { >>> SecureRandom ng = Holder.numberGenerator; >>> >>> byte[] randomBytes = new byte[16]; >>> ng.nextBytes(randomBytes); >>> final ByteBuffer bb = ByteBuffer.wrap(randomBytes); >>> bb.order(ByteOrder.nativeOrder()); >>> >>> long msb = bb.getLong(); >>> long lsb = bb.getLong(); >>> >>> msb &= 0xFFFFFFFFFFFF0FFFL; /* clear version */ >>> msb |= 0x4000L; /* set to version 4 */ >>> >>> lsb &= 0x3FFFFFFFFFFFFFFFL; /* clear variant */ >>> lsb |= 0x8000000000000000L; /* set to IETF variant */ >>> >>> return new UUID(msb, lsb); >>> } >>> >>> public static UUID nameUUIDFromBytes(byte[] name) { >>> MessageDigest md; >>> try { >>> md = MessageDigest.getInstance("MD5"); >>> } catch (NoSuchAlgorithmException nsae) { >>> throw new InternalError("MD5 not supported", nsae); >>> } >>> byte[] md5Bytes = md.digest(name); >>> >>> // default byte order is BIG_ENDIAN >>> final ByteBuffer bb = ByteBuffer.wrap(md5Bytes); >>> >>> long msb = bb.getLong(); >>> long lsb = bb.getLong(); >>> >>> msb &= 0xFFFFFFFFFFFF0FFFL; /* clear version */ >>> msb |= 0x3000L; /* set to version 3 */ >>> >>> lsb &= 0x3FFFFFFFFFFFFFFFL; /* clear variant */ >>> lsb |= 0x8000000000000000L; /* set to IETF variant */ >>> >>> return new UUID(msb, lsb); >>> } >>> >>> Benchmark Mode Cnt Score Error Units >>> UUIDBenchmark.jdk_name avgt 3 11.885 ? 4.025 ns/op >>> UUIDBenchmark.jdk_random avgt 3 11.656 ? 0.987 ns/op >>> UUIDBenchmark.longs avgt 3 7.618 ? 1.047 ns/op >>> UUIDBenchmark.longs_bb avgt 3 7.755 ? 1.643 ns/op >>> UUIDBenchmark.longs_name avgt 3 8.467 ? 1.784 ns/op >>> UUIDBenchmark.longs_name_bb avgt 3 8.455 ? 1.662 ns/op >>> UUIDBenchmark.randomBytes avgt 3 6.132 ? 0.447 ns/op >>> >>> >>> @BenchmarkMode(Mode.AverageTime) >>> @OutputTimeUnit(TimeUnit.NANOSECONDS) >>> @Warmup(iterations = 3, time = 2, timeUnit = TimeUnit.SECONDS) >>> @Measurement(iterations = 3, time = 2, timeUnit = TimeUnit.SECONDS) >>> @Fork(1) >>> @State(Scope.Benchmark) >>> public class UUIDBenchmark { >>> >>> private static final VarHandle LONGS_ACCESS = >>> MethodHandles.byteArrayViewVarHandle(long[].class, >>> ByteOrder.nativeOrder()); >>> >>> private static final VarHandle BE_LONGS_ACCESS = >>> MethodHandles.byteArrayViewVarHandle(long[].class, >>> ByteOrder.BIG_ENDIAN); >>> >>> @Benchmark >>> public byte[] randomBytes() { >>> final byte[] bytes = new byte[16]; >>> randomBytes(bytes); >>> return bytes; >>> } >>> >>> @Benchmark >>> public void jdk_random(Blackhole bh) { >>> final byte[] data = new byte[16]; >>> randomBytes(data); >>> data[6] &= 0x0f; /* clear version */ >>> data[6] |= 0x40; /* set to version 4 */ >>> data[8] &= 0x3f; /* clear variant */ >>> data[8] |= 0x80; /* set to IETF variant */ >>> long msb = 0; >>> long lsb = 0; >>> assert data.length == 16 : "data must be 16 bytes in length"; >>> for (int i=0; i<8; i++) >>> msb = (msb << 8) | (data[i] & 0xff); >>> for (int i=8; i<16; i++) >>> lsb = (lsb << 8) | (data[i] & 0xff); >>> bh.consume(msb); >>> bh.consume(lsb); >>> } >>> >>> @Benchmark >>> public void jdk_name(Blackhole bh) >>> { >>> final byte[] md5Bytes = new byte[16]; >>> randomBytes(md5Bytes); >>> md5Bytes[6] &= 0x0f; /* clear version */ >>> md5Bytes[6] |= 0x30; /* set to version 3 */ >>> md5Bytes[8] &= 0x3f; /* clear variant */ >>> md5Bytes[8] |= 0x80; /* set to IETF variant */ >>> long msb = 0; >>> long lsb = 0; >>> assert md5Bytes.length == 16 : "data must be 16 bytes in length"; >>> for (int i=0; i<8; i++) >>> msb = (msb << 8) | (md5Bytes[i] & 0xff); >>> for (int i=8; i<16; i++) >>> lsb = (lsb << 8) | (md5Bytes[i] & 0xff); >>> bh.consume(msb); >>> bh.consume(lsb); >>> } >>> >>> @Benchmark >>> public void longs(Blackhole bh) { >>> final byte[] data = new byte[16]; >>> randomBytes(data); >>> >>> long msb = (long) LONGS_ACCESS.get(data, 0); >>> long lsb = (long) LONGS_ACCESS.get(data, 8); >>> >>> msb &= 0xFFFFFFFFFFFF0FFFL; >>> msb |= 0x4000L; >>> >>> lsb &= 0x3FFFFFFFFFFFFFFFL; >>> lsb |= 0x8000000000000000L; >>> >>> bh.consume(msb); >>> bh.consume(lsb); >>> } >>> >>> @Benchmark >>> public void longs_name(Blackhole bh) { >>> final byte[] data = new byte[16]; >>> randomBytes(data); >>> >>> long msb = (long) BE_LONGS_ACCESS.get(data, 0); >>> long lsb = (long) BE_LONGS_ACCESS.get(data, 8); >>> >>> msb &= 0xFFFFFFFFFFFF0FFFL; >>> msb |= 0x3000L; >>> >>> lsb &= 0x3FFFFFFFFFFFFFFFL; >>> lsb |= 0x8000000000000000L; >>> >>> bh.consume(msb); >>> bh.consume(lsb); >>> } >>> >>> @Benchmark >>> public void longs_bb(Blackhole bh) { >>> final byte[] data = new byte[16]; >>> randomBytes(data); >>> >>> final ByteBuffer bb = ByteBuffer.wrap(data); >>> bb.order(ByteOrder.nativeOrder()); >>> >>> long msb = bb.getLong(); >>> long lsb = bb.getLong(); >>> >>> msb &= 0xFFFFFFFFFFFF0FFFL; >>> msb |= 0x4000L; >>> >>> lsb &= 0x3FFFFFFFFFFFFFFFL; >>> lsb |= 0x8000000000000000L; >>> >>> bh.consume(msb); >>> bh.consume(lsb); >>> } >>> >>> @Benchmark >>> public void longs_name_bb(Blackhole bh) { >>> final byte[] data = new byte[16]; >>> randomBytes(data); >>> >>> final ByteBuffer bb = ByteBuffer.wrap(data); >>> // bb.order(ByteOrder.BIG_ENDIAN); >>> >>> long msb = bb.getLong(); >>> long lsb = bb.getLong(); >>> >>> msb &= 0xFFFFFFFFFFFF0FFFL; >>> msb |= 0x3000L; >>> >>> lsb &= 0x3FFFFFFFFFFFFFFFL; >>> lsb |= 0x8000000000000000L; >>> >>> bh.consume(msb); >>> bh.consume(lsb); >>> } >>> >>> static void randomBytes(byte[] bytes) { >>> ThreadLocalRandom tlr = ThreadLocalRandom.current(); >>> LONGS_ACCESS.set(bytes, 0, tlr.nextLong()); >>> LONGS_ACCESS.set(bytes, 8, tlr.nextLong()); >>> } >>> } From martin at openjdk.org Mon Mar 6 15:49:34 2023 From: martin at openjdk.org (Martin Buchholz) Date: Mon, 6 Mar 2023 15:49:34 GMT Subject: RFR: JDK-8302360 Atomic*.compareAndExchange Javadoc unclear In-Reply-To: References: Message-ID: On Mon, 6 Mar 2023 13:23:59 GMT, Viktor Klang wrote: > I think the following proposal is very non-invasive and merely draws attention to the fact that "witness value" is a specific term related to the notion of these atomic methods. > > It's a small change which I think provides additional clarity, see JBS for the discussion on the topic. Marked as reviewed by martin (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12880 From rriggs at openjdk.org Mon Mar 6 15:55:32 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 6 Mar 2023 15:55:32 GMT Subject: RFR: 8303440: The "ZonedDateTime.parse" may not accept the "UTC+XX" zone id [v3] In-Reply-To: References: Message-ID: <-vsDsyWuF_MWHZtADr1CjMRtd4nLxiSHdPrsPBMu9-Q=.460fc7ad-d44d-4a9b-bb32-b55f2340bb11@github.com> On Sat, 4 Mar 2023 02:22:39 GMT, Naoto Sato wrote: >> This change is to fix a regression caused by the fix to [JDK-8234347](https://bugs.openjdk.org/browse/JDK-8234347). The previous fix was simply disabling offset-based parsing if the parser was text-based. Instead, check if it is an offset or not by explicitly comparing the character with '+'/'-' and continue offset parsing if it is. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > now -> zdt LGTM ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.org/jdk/pull/12868 From kvn at openjdk.org Mon Mar 6 16:09:13 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 6 Mar 2023 16:09:13 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter Message-ID: The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. ---------------------------------------------------------------------- Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in Interpreter and C1 compiler to produce the same results as C2 intrinsics on x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java methods were implemented originally. Replaced `SharedRuntime::f2hf()` and `hf2f()` C runtime functions with calls to runtime stubs which use the same HW instructions as C2 intrinsics. Only for 64-bit x64 because 32-bit x86 stub does not work: result is passed through FPU register and NaN values become different from C2 intrinsic. This runtime stub is only used to calculate constant values during C2 compilation and can be skipped. I added new tests based on Tobias's `TestAll.java` And copied `jdk/lang/Float/Binary16Conversion*.java` tests to run them with `-Xcomp` to make sure code is compiled by C1 or C2. I modified `Binary16ConversionNaN.java` to compare results from Interpreter, C1 and C2. Tested tier1-5, Xcomp, stress ------------- Commit messages: - Remove ConvF2HFNode::Identity(). Updated tests - Copyright year update - Check float16 instructions support on platforms for C1 - Update Copyright year. Add missing UnlockDiagnosticVMOptions flag in new test - Implement Aarch64 and RiscV parts, remove 32-bit x86 runtime stub - Merge branch 'master' into 8302976 - 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter Changes: https://git.openjdk.org/jdk/pull/12869/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12869&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8302976 Stats: 1432 lines in 48 files changed: 1284 ins; 97 del; 51 mod Patch: https://git.openjdk.org/jdk/pull/12869.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12869/head:pull/12869 PR: https://git.openjdk.org/jdk/pull/12869 From kvn at openjdk.org Mon Mar 6 16:09:14 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 6 Mar 2023 16:09:14 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter In-Reply-To: References: Message-ID: On Fri, 3 Mar 2023 21:41:35 GMT, Vladimir Kozlov wrote: > Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in Interpreter and C1 compiler to produce the same results as C2 intrinsics on x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java methods were implemented originally. > > Replaced `SharedRuntime::f2hf()` and `hf2f()` C runtime functions with calls to runtime stubs which use the same HW instructions as C2 intrinsics. Only for 64-bit x64 because 32-bit x86 stub does not work: result is passed through FPU register and NaN values become different from C2 intrinsic. This runtime stub is only used to calculate constant values during C2 compilation and can be skipped. > > I added new tests based on Tobias's `TestAll.java` And copied `jdk/lang/Float/Binary16Conversion*.java` tests to run them with `-Xcomp` to make sure code is compiled by C1 or C2. I modified `Binary16ConversionNaN.java` to compare results from Interpreter, C1 and C2. > > Tested tier1-5, Xcomp, stress GHA failure on linux-x86 in test compiler/vectorization/runner/LoopRangeStrideTest.java is due to [JDK-8303105](https://bugs.openjdk.org/browse/JDK-8303105) ------------- PR: https://git.openjdk.org/jdk/pull/12869 From never at openjdk.org Mon Mar 6 16:13:47 2023 From: never at openjdk.org (Tom Rodriguez) Date: Mon, 6 Mar 2023 16:13:47 GMT Subject: RFR: 8303577: [JVMCI] OOME causes crash while translating exceptions In-Reply-To: References: Message-ID: On Fri, 3 Mar 2023 15:40:01 GMT, Doug Simon wrote: > JDK-8297431 added code for special handling of OutOfMemoryError when translating an exception between libjvmci and HotSpot[1]. > Unfortunately, this code was deleted by JDK-8298099 when moving the exception translation mechanism to VMSupport[2]. > This causes the VM to crash when an OOME occurs while translating an exception from HotSpot to libjvmci. > This PR revives the deleted code. > > This bug was found by running `test/jdk/java/util/concurrent/locks/Lock/OOMEInAQS.java` on libgraal. The fix now makes the test pass. > > Note that the code modified in `src/java.base/share/classes/jdk/internal/vm/VMSupport.java` is JVMCI specific and was original added by [JDK-8298099](https://git.openjdk.org/jdk/pull/11513). > > [1] https://github.com/openjdk/jdk/commit/952e10055135613e8ea2b818a4f35842936f5633#diff-4d3a3b7e7e12e1d5b4cf3e4677d9e0de5e9df3bbf1bbfa0d8d43d12098d67dc4R222-R234 > [2] https://github.com/openjdk/jdk/commit/8b69a2e434ad2fa3369079622b57afb973d5bd9a#diff-7292551772c27b7152a3333f03cbbad90a897c5e37c6a97d4026be835e6d8fe1R121-R125 Marked as reviewed by never (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12857 From dnsimon at openjdk.org Mon Mar 6 16:14:01 2023 From: dnsimon at openjdk.org (Doug Simon) Date: Mon, 6 Mar 2023 16:14:01 GMT Subject: RFR: 8303577: [JVMCI] OOME causes crash while translating exceptions In-Reply-To: References: Message-ID: On Fri, 3 Mar 2023 18:05:51 GMT, Vladimir Kozlov wrote: >> JDK-8297431 added code for special handling of OutOfMemoryError when translating an exception between libjvmci and HotSpot[1]. >> Unfortunately, this code was deleted by JDK-8298099 when moving the exception translation mechanism to VMSupport[2]. >> This causes the VM to crash when an OOME occurs while translating an exception from HotSpot to libjvmci. >> This PR revives the deleted code. >> >> This bug was found by running `test/jdk/java/util/concurrent/locks/Lock/OOMEInAQS.java` on libgraal. The fix now makes the test pass. >> >> Note that the code modified in `src/java.base/share/classes/jdk/internal/vm/VMSupport.java` is JVMCI specific and was original added by [JDK-8298099](https://git.openjdk.org/jdk/pull/11513). >> >> [1] https://github.com/openjdk/jdk/commit/952e10055135613e8ea2b818a4f35842936f5633#diff-4d3a3b7e7e12e1d5b4cf3e4677d9e0de5e9df3bbf1bbfa0d8d43d12098d67dc4R222-R234 >> [2] https://github.com/openjdk/jdk/commit/8b69a2e434ad2fa3369079622b57afb973d5bd9a#diff-7292551772c27b7152a3333f03cbbad90a897c5e37c6a97d4026be835e6d8fe1R121-R125 > > Good. Thanks for the reviews @vnkozlov and @tkrodriguez . ------------- PR: https://git.openjdk.org/jdk/pull/12857 From dnsimon at openjdk.org Mon Mar 6 16:14:02 2023 From: dnsimon at openjdk.org (Doug Simon) Date: Mon, 6 Mar 2023 16:14:02 GMT Subject: Integrated: 8303577: [JVMCI] OOME causes crash while translating exceptions In-Reply-To: References: Message-ID: The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. ---------------------------------------------------------------------- On Fri, 3 Mar 2023 15:40:01 GMT, Doug Simon wrote: > JDK-8297431 added code for special handling of OutOfMemoryError when translating an exception between libjvmci and HotSpot[1]. > Unfortunately, this code was deleted by JDK-8298099 when moving the exception translation mechanism to VMSupport[2]. > This causes the VM to crash when an OOME occurs while translating an exception from HotSpot to libjvmci. > This PR revives the deleted code. > > This bug was found by running `test/jdk/java/util/concurrent/locks/Lock/OOMEInAQS.java` on libgraal. The fix now makes the test pass. > > Note that the code modified in `src/java.base/share/classes/jdk/internal/vm/VMSupport.java` is JVMCI specific and was original added by [JDK-8298099](https://git.openjdk.org/jdk/pull/11513). > > [1] https://github.com/openjdk/jdk/commit/952e10055135613e8ea2b818a4f35842936f5633#diff-4d3a3b7e7e12e1d5b4cf3e4677d9e0de5e9df3bbf1bbfa0d8d43d12098d67dc4R222-R234 > [2] https://github.com/openjdk/jdk/commit/8b69a2e434ad2fa3369079622b57afb973d5bd9a#diff-7292551772c27b7152a3333f03cbbad90a897c5e37c6a97d4026be835e6d8fe1R121-R125 This pull request has now been integrated. Changeset: cac81ddc Author: Doug Simon URL: https://git.openjdk.org/jdk/commit/cac81ddc9259168a5b12c290ae2ce7db25a729fc Stats: 31 lines in 5 files changed: 22 ins; 0 del; 9 mod 8303577: [JVMCI] OOME causes crash while translating exceptions Reviewed-by: kvn, never ------------- PR: https://git.openjdk.org/jdk/pull/12857 From lancea at openjdk.org Mon Mar 6 16:25:19 2023 From: lancea at openjdk.org (Lance Andersen) Date: Mon, 6 Mar 2023 16:25:19 GMT Subject: RFR: 8303440: The "ZonedDateTime.parse" may not accept the "UTC+XX" zone id [v3] In-Reply-To: References: Message-ID: On Sat, 4 Mar 2023 02:22:39 GMT, Naoto Sato wrote: >> This change is to fix a regression caused by the fix to [JDK-8234347](https://bugs.openjdk.org/browse/JDK-8234347). The previous fix was simply disabling offset-based parsing if the parser was text-based. Instead, check if it is an offset or not by explicitly comparing the character with '+'/'-' and continue offset parsing if it is. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > now -> zdt Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12868 From rriggs at openjdk.org Mon Mar 6 16:39:06 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 6 Mar 2023 16:39:06 GMT Subject: RFR: 8303392: Runtime.exec and ProcessBuilder.start should use System logger [v2] In-Reply-To: References: <-1i11ZrHHgzUbCSa_RXAcGKNfgtpdui--bltZ4Ujs2A=.f5f1a7e2-d3ec-4f64-9b1e-317ef2f24ef1@github.com> Message-ID: On Mon, 6 Mar 2023 12:44:57 GMT, Daniel Fuchs wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Add javadoc @implNote to Runtime.exec and ProcessBuilder methods > > src/java.base/share/classes/java/lang/ProcessBuilder.java line 1148: > >> 1146: ", pid: " + process.pid()); >> 1147: } catch (Throwable thEx) {/* ignore */} >> 1148: } > > Is it really useful to try & catch a potential exception here, or wouldn't be better to let it propagate to the caller? An exception here would indicate a bug somewhere either in the logging backend or in the logging configuration - or possibly OOM or any other kind of VM error and maybe it would be better to just fail in that case, and let the VM exit (unless that exception is caught down the road by the caller?) > > I understand why we would not want an exception in logging to prevent System.exit() from exiting, but surely the same constraint doesn't hold for `ProcessBuilder::start`? Since adding logging injects additional code during start(), the idea was to handle exceptions to avoid breaking existing code. And since the logger is cached during the static initialization of the ProcessBuilder class, a mis-configured logger would cause ExceptionInInitializer, exposing the cause early, though in a pretty ugly way. I may need to reconsider that. ------------- PR: https://git.openjdk.org/jdk/pull/12862 From jvernee at openjdk.org Mon Mar 6 16:42:10 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 6 Mar 2023 16:42:10 GMT Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function & Memory API (Preview) [v3] In-Reply-To: References: <8b3vVrV22RuhdRoRYacXV0ZeghFGgKkC8S_z-iMrzAQ=.dd84b743-8b51-4281-8f5f-f9eff6207bc7@github.com> Message-ID: On Wed, 1 Mar 2023 06:37:45 GMT, Martin Doerr wrote: >>> * Uploaded my simple reproducer to [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017) >> >> Thanks! >> >>> * Using oversized load / stores is problematic. Don't forget that OpenJDK still supports Big Endian platforms (AIX, s390x). >> >> You're right. I realized that it's also problematic for heap segments, for which we can't do oversized accesses. I am working on another solution that splits up the loads/stores into power-of-two sized chunks: https://github.com/openjdk/panama-foreign/compare/foreign-memaccess+abi...JornVernee:panama-foreign:OOB That patch is just a POC at this point though. Also, I don't think it works for BE at the moment (need to flip the offset for BE, I think. Just like we do in Unsafe). >> >>> * The result of `NativeCallingConvention::calling_convention` is interpreted as size, but it returns the max offset. That's off by one slot. Should I file a bug for that? (PPC64 is not affected because it doesn't use the result.) >> >> I'm not sure there's an issue there. Note that the 'max offset' is computed as `reg.offset() + reg.stack_size()`, so that should get us the size we need to allocate for the stack arguments. (e.g. 2 ints being passed at offset 0 and 4, would make max offset 4 + 4 = 8, which gives the size needed for the 2 ints). Computing the max offset instead of just summing the sizes of the stack arguments is needed since stack arguments can be sparsely placed in some cases on Mac/AArch64. >> >>> * Since the membar on the return path was mentioned: I think it would be good to enable UseSystemMemoryBarrier by default on operating systems which support it. Maybe we should discuss this with @robehn. >> >> ~I don't think we've done that much testing with UseSystemMemoryBarrier since it was added~. I'm a bit nervous about turning it on by default since it's currently also used for JNI. Let's see what Robbin thinks. > > @JornVernee: Thanks a lot for your detailed review! I have quite a few TODOs which include: > - Include my tests for the HFA corner cases. > - Try to improve handling of the overlapping registers as you suggested. > - Check nesting of HFA. > > There will surely be more when looking into Big Endian support after merging with your recent work on https://github.com/openjdk/panama-foreign/compare/foreign-memaccess+abi...JornVernee:panama-foreign:OOB > We should get rid of oversized accesses on PPC64, too. > Thanks for sharing your plans to intrisify `linkToNative` in C2 later. I guess we should do more preparation work on all platforms when that gets addressed. @TheRealMDoerr I've moved the support for structs/unions that are not a power of 2 in size to this repo, so you should be able to merge the master branch to get it now. ------------- PR: https://git.openjdk.org/jdk/pull/12708 From rriggs at openjdk.org Mon Mar 6 17:02:26 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 6 Mar 2023 17:02:26 GMT Subject: RFR: 8303392: Runtime.exec and ProcessBuilder.start should use System logger [v2] In-Reply-To: <-PHwf09-m1XajVZo9TpIbaJfM0duZ3PVQfINW6gtEvs=.bab3ee00-a561-4207-ac19-1f2abf8a5f6c@github.com> References: <-1i11ZrHHgzUbCSa_RXAcGKNfgtpdui--bltZ4Ujs2A=.f5f1a7e2-d3ec-4f64-9b1e-317ef2f24ef1@github.com> <-PHwf09-m1XajVZo9TpIbaJfM0duZ3PVQfINW6gtEvs=.bab3ee00-a561-4207-ac19-1f2abf8a5f6c@github.com> Message-ID: On Sun, 5 Mar 2023 06:14:49 GMT, Thomas Stuefe wrote: > I think to be even more useful it could make sense to print the current directory the child is started in as well as the env var array, possibly only with a finer logging level. There are concerns about exposing potentially sensitive information in exceptions and logs. And it would need to apply to all process arguments, not just directory and environment. For example, there is a property "jdk.includeInExceptions" that is used to only include detail information if it is set. Unless specifically enabled, the information such as host names and file names are not exposed. Restricting the detail to finer grained logging levels might be the/an answer. ------------- PR: https://git.openjdk.org/jdk/pull/12862 From asotona at openjdk.org Mon Mar 6 17:07:14 2023 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 6 Mar 2023 17:07:14 GMT Subject: RFR: 8294982: Implementation of Classfile API [v36] In-Reply-To: References: Message-ID: <5QdeZ3Cz8gZ6QJYVrJHfaYSnQf306mumDrHWn0cCiVM=.f9198f75-3f2e-427d-bf69-0a846b39089d@github.com> On Thu, 2 Mar 2023 23:28:23 GMT, Paul Sandoz wrote: >> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: >> >> StackMapFrameInfo extracted to top level from StackMapTableAttribute > > src/java.base/share/classes/jdk/internal/classfile/CodeBuilder.java line 165: > >> 163: * @return this builder >> 164: */ >> 165: default CodeBuilder transforming(CodeTransform transform, Consumer handler) { > > The functionality of this method, `transforming`, and `ClassfileBuilder::transform`, are in effect equivalent in their transforming: adding the results of transformed code to the builder. They differ in the source of code elements. > > The latter's behaviour can be implemented using the former, with a consumer that passes all elements of a code model to the builder e.g. `builder -> model.forEach(builder::with)`. > > The difference in naming initially confused me. To me this suggests the method names should be the same? (perhaps with the transformer being consistently the last argument?). The `CodeBuilder::transforming` solves a bit different use cases than all the other transform. It is designed to be able to use code transformations on a code building handler within a single pass. Main reason is support of features like `StackTracker` in a form of code transformation. `StackTracker` (or any other similar tool requiring to monitor or affect code building) is passed as a transformation of a code fragment, while it can immediately serve as a source of information necessary to generate follow-up bytecode of the same method (in the same pass). Example of such use case is here: https://github.com/openjdk/jdk/blob/0e43af667ba6c6bda61461c260688bc46d3f3474/src/java.base/share/classes/jdk/internal/classfile/components/CodeStackTracker.java#L49 These code generation/transformation cases must be handled in a single pass and `CodeBuilder::transforming` method has no similar peer in any other (method, field or class) builder, because it is not necessary. ------------- PR: https://git.openjdk.org/jdk/pull/10982 From mchung at openjdk.org Mon Mar 6 17:10:46 2023 From: mchung at openjdk.org (Mandy Chung) Date: Mon, 6 Mar 2023 17:10:46 GMT Subject: RFR: 8302791: Add specific ClassLoader object to Proxy IllegalArgumentException message [v6] In-Reply-To: References: Message-ID: On Mon, 6 Mar 2023 11:08:42 GMT, Ravali Yatham wrote: >> Added specific class loader object to proxy IllegalArgumentException from which the class was not visible >> >> The bug report for the same: https://bugs.openjdk.org/browse/JDK-8302791 > > Ravali Yatham has updated the pull request incrementally with one additional commit since the last revision: > > Added JavaLangAccess::getLoaderNameID(ClassLoader loader) Looks good. Thanks for the change. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.org/jdk/pull/12641 From asotona at openjdk.org Mon Mar 6 17:11:42 2023 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 6 Mar 2023 17:11:42 GMT Subject: RFR: 8294982: Implementation of Classfile API [v49] In-Reply-To: References: Message-ID: <17U4X6UFV0n08QWRkpROWyGLTXGBlRPQ-x3yrlPEQWY=.5e4dc9a4-49c4-4988-b365-238e3c4687e9@github.com> > This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. > > Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. > > Classfile API development is tracked at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch > > Development branch of consolidated JDK class files parsing, generating, and transforming is at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch > > Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. > > Please take you time to review this non-trivial JDK addition. > > Thank you, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: snippets and tests synced with jdk.jfr class instrumentation source code ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10982/files - new: https://git.openjdk.org/jdk/pull/10982/files/0e43af66..6df1297e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=48 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=47-48 Stats: 13 lines in 2 files changed: 1 ins; 3 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/10982.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982 PR: https://git.openjdk.org/jdk/pull/10982 From psandoz at openjdk.org Mon Mar 6 17:19:05 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Mon, 6 Mar 2023 17:19:05 GMT Subject: RFR: 8294982: Implementation of Classfile API [v36] In-Reply-To: <5QdeZ3Cz8gZ6QJYVrJHfaYSnQf306mumDrHWn0cCiVM=.f9198f75-3f2e-427d-bf69-0a846b39089d@github.com> References: <5QdeZ3Cz8gZ6QJYVrJHfaYSnQf306mumDrHWn0cCiVM=.f9198f75-3f2e-427d-bf69-0a846b39089d@github.com> Message-ID: On Mon, 6 Mar 2023 17:02:46 GMT, Adam Sotona wrote: >> src/java.base/share/classes/jdk/internal/classfile/CodeBuilder.java line 165: >> >>> 163: * @return this builder >>> 164: */ >>> 165: default CodeBuilder transforming(CodeTransform transform, Consumer handler) { >> >> The functionality of this method, `transforming`, and `ClassfileBuilder::transform`, are in effect equivalent in their transforming: adding the results of transformed code to the builder. They differ in the source of code elements. >> >> The latter's behaviour can be implemented using the former, with a consumer that passes all elements of a code model to the builder e.g. `builder -> model.forEach(builder::with)`. >> >> The difference in naming initially confused me. To me this suggests the method names should be the same? (perhaps with the transformer being consistently the last argument?). > > The `CodeBuilder::transforming` solves a bit different use cases than all the other transform. > It is designed to be able to use code transformations on a code building handler within a single pass. > Main reason is support of features like `StackTracker` in a form of code transformation. `StackTracker` (or any other similar tool requiring to monitor or affect code building) is passed as a transformation of a code fragment, while it can immediately serve as a source of information necessary to generate follow-up bytecode of the same method (in the same pass). > Example of such use case is here: > https://github.com/openjdk/jdk/blob/0e43af667ba6c6bda61461c260688bc46d3f3474/src/java.base/share/classes/jdk/internal/classfile/components/CodeStackTracker.java#L49 > > These code generation/transformation cases must be handled in a single pass and `CodeBuilder::transforming` method has no similar peer in any other (method, field or class) builder, because it is not necessary. The use-case seems fine to me (and that it only makes sense for building code). I still think it's a "transform", but with a different source. Subtly changing the name makes it seem different and fundamentally it is not AFAICT. If there is a separate name I think it should reflect the difference in source input to the transformation, rather than differentiate via the present participle. ------------- PR: https://git.openjdk.org/jdk/pull/10982 From asotona at openjdk.org Mon Mar 6 17:19:10 2023 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 6 Mar 2023 17:19:10 GMT Subject: RFR: 8294982: Implementation of Classfile API [v36] In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 19:56:08 GMT, Paul Sandoz wrote: >> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: >> >> StackMapFrameInfo extracted to top level from StackMapTableAttribute > > src/java.base/share/classes/jdk/internal/classfile/components/snippet-files/PackageSnippets.java line 149: > >> 147: var instrumentorCodeMap = instrumentor.methods().stream() >> 148: .filter(instrumentedMethodsFilter) >> 149: .collect(Collectors.toMap(mm -> mm.methodName().stringValue() + mm.methodType().stringValue(), mm -> mm.code().orElse(null))); > > Should we be filtering out abstract methods before the `collect` and/or replace with: > > mm -> mm.code().orElseThrow() > > ? Abstract methods should not be selected for instrumentation, so `orElseThrow()` is a good idea. Fixed, thanks. > src/java.base/share/classes/jdk/internal/classfile/components/snippet-files/PackageSnippets.java line 171: > >> 169: >> 170: //store stacked method parameters into locals >> 171: var storeStack = new LinkedList(); > > FWIW you can use an ArrayDeque + push + forEach, in the spirit of highlighting Deque over LinkedList for stack-based usage (since this is an example with visibility). fixed, thanks. ------------- PR: https://git.openjdk.org/jdk/pull/10982 From naoto at openjdk.org Mon Mar 6 17:26:43 2023 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 6 Mar 2023 17:26:43 GMT Subject: Integrated: 8303440: The "ZonedDateTime.parse" may not accept the "UTC+XX" zone id In-Reply-To: References: Message-ID: <9rQzO54BU5-16VvHggj93ua9_AuZHUOon0UGC03sr44=.e55c19c3-94cf-4265-aab9-9248244bb76a@github.com> The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. ---------------------------------------------------------------------- On Fri, 3 Mar 2023 20:51:14 GMT, Naoto Sato wrote: > This change is to fix a regression caused by the fix to [JDK-8234347](https://bugs.openjdk.org/browse/JDK-8234347). The previous fix was simply disabling offset-based parsing if the parser was text-based. Instead, check if it is an offset or not by explicitly comparing the character with '+'/'-' and continue offset parsing if it is. This pull request has now been integrated. Changeset: cfb0a25a Author: Naoto Sato URL: https://git.openjdk.org/jdk/commit/cfb0a25a4ee1a9cebd88c84fa622c46fe1c89bae Stats: 81 lines in 2 files changed: 79 ins; 0 del; 2 mod 8303440: The "ZonedDateTime.parse" may not accept the "UTC+XX" zone id Reviewed-by: iris, jpai, rriggs, lancea ------------- PR: https://git.openjdk.org/jdk/pull/12868 From asotona at openjdk.org Mon Mar 6 17:36:36 2023 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 6 Mar 2023 17:36:36 GMT Subject: RFR: 8294982: Implementation of Classfile API [v36] In-Reply-To: References: <5QdeZ3Cz8gZ6QJYVrJHfaYSnQf306mumDrHWn0cCiVM=.f9198f75-3f2e-427d-bf69-0a846b39089d@github.com> Message-ID: The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. ---------------------------------------------------------------------- On Mon, 6 Mar 2023 17:15:25 GMT, Paul Sandoz wrote: >> The `CodeBuilder::transforming` solves a bit different use cases than all the other transform. >> It is designed to be able to use code transformations on a code building handler within a single pass. >> Main reason is support of features like `StackTracker` in a form of code transformation. `StackTracker` (or any other similar tool requiring to monitor or affect code building) is passed as a transformation of a code fragment, while it can immediately serve as a source of information necessary to generate follow-up bytecode of the same method (in the same pass). >> Example of such use case is here: >> https://github.com/openjdk/jdk/blob/0e43af667ba6c6bda61461c260688bc46d3f3474/src/java.base/share/classes/jdk/internal/classfile/components/CodeStackTracker.java#L49 >> >> These code generation/transformation cases must be handled in a single pass and `CodeBuilder::transforming` method has no similar peer in any other (method, field or class) builder, because it is not necessary. > > The use-case seems fine to me (and that it only makes sense for building code). I still think it's a "transform", but with a different source. Subtly changing the name makes it seem different and fundamentally it is not AFAICT. If there is a separate name I think it should reflect the difference in source input to the transformation, rather than differentiate via the present participle. I see what you mean. `transforming` was selected to represent the continuation of the code building process, similar to `trying` and `catching`. While `transform` may imply that the actual code builder gets transformed into something else. For example `MethodModel::transformCode` takes `CodeModel`, applies `CodeTransform` and after that the code of the actual method is finished. What about `transformBlock(BlockCodeBuilder, CodeTransform)`? ------------- PR: https://git.openjdk.org/jdk/pull/10982 From psandoz at openjdk.org Mon Mar 6 17:49:29 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Mon, 6 Mar 2023 17:49:29 GMT Subject: RFR: 8294982: Implementation of Classfile API [v36] In-Reply-To: References: <5QdeZ3Cz8gZ6QJYVrJHfaYSnQf306mumDrHWn0cCiVM=.f9198f75-3f2e-427d-bf69-0a846b39089d@github.com> Message-ID: On Mon, 6 Mar 2023 17:34:35 GMT, Adam Sotona wrote: >> The use-case seems fine to me (and that it only makes sense for building code). I still think it's a "transform", but with a different source. Subtly changing the name makes it seem different and fundamentally it is not AFAICT. If there is a separate name I think it should reflect the difference in source input to the transformation, rather than differentiate via the present participle. > > I see what you mean. `transforming` was selected to represent the continuation of the code building process, similar to `trying` and `catching`. While `transform` may imply that the actual code builder gets transformed into something else. For example `MethodModel::transformCode` takes `CodeModel`, applies `CodeTransform` and after that the code of the actual method is finished. > What about `transformBlock(BlockCodeBuilder, CodeTransform)`? I am unsure how you might use `BlockCodeBuilder`. If the current signature is not changed then `transformFromHandler` seems reasonable (since its the handler that pushes elements into its given builder). The other `transform` is implicitly "transform model". ------------- PR: https://git.openjdk.org/jdk/pull/10982 From eirbjo at gmail.com Mon Mar 6 18:43:15 2023 From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=) Date: Mon, 6 Mar 2023 19:43:15 +0100 Subject: ZipOutputStream & directories Message-ID: Hi, I noticed that ZipOutputStream violates APPNOTE.txt when writing directory entries: Zero-byte files, directories, and other file types that > contain no content MUST NOT include file data. Nobody seems to have complained about this violation (I searched JBS), so in itself it might not be worth pursuing a fix. However, in addition to breaking the specification, this also causes suboptimal performance both on the write and read paths. Before I go ahead and suggest any particular solution, I wanted to share some analysis: ZipOutputStream writes directories as any other entry, so by default it ends up writing a LOC header with the DEFLATED method and the data descriptor bit set. This is followed by a final, empty DEFLATE block (0x0300) and then a signed data descriptor with the CRC, csize (2) and size (0), each 4 bytes: ------ Local File Header ------ 000000 signature 0x04034b50 000004 version 20 000006 flags 0x0808 000008 method 8 Deflated 000010 time 0x9812 19:00:36 000012 date 0x5666 2023-03-06 000014 crc 0x00000000 000018 csize 0 000022 size 0 000026 nlen 9 000028 elen 0 000030 name 9 bytes 'META-INF/' ------ File Data ------ 000039 data 2 bytes ------ Data Descriptor ------ 000041 signature 0x08074b50 000045 crc 0x00000000 000049 csize 2 000053 size 0 In total, this means that an extra 18 bytes is output, which is a waste of storage space and IO cycles while writing and reading/parsing the unnecessary headers and data. If the directory entry has the STORED method and the sizes and crc is set to 0, then the file data and data descriptors are skipped and we reclaim 18 bytes. The use of DEFLATE has an adverse negative impact on performance, since native ZLIB code needs to be called to produce and read (in ZipInputStream) the empty DEFLATE block. Worse, Deflater.reset and Inflater.reset are called, which seems to incur a significant overhead. In fact, when configuring the STORED method and explicitly setting csize, size and crc to 0, we see considerable benchmark improvements writing and reading directory entries: DEFLATED: Benchmark (size) Mode Cnt Score Error Units ZipEmptyStreams.readDirStream 512 avgt 15 0.278 ? 0.005 ms/op ZipEmptyStreams.readDirStream 1024 avgt 15 0.550 ? 0.006 ms/op ZipEmptyStreams.writeDirStreams 512 avgt 15 2.379 ? 0.043 ms/op ZipEmptyStreams.writeDirStreams 1024 avgt 15 4.845 ? 0.087 ms/op STORED: Benchmark (size) Mode Cnt Score Error Units ZipEmptyStreams.readDirStream 512 avgt 15 0.082 ? 0.001 ms/op ZipEmptyStreams.readDirStream 1024 avgt 15 0.176 ? 0.015 ms/op ZipEmptyStreams.writeDirStream 512 avgt 15 0.233 ? 0.021 ms/op ZipEmptyStreams.writeDirStream 1024 avgt 15 0.460 ? 0.028 ms/op Possible actions: - Do nothing: Nobody complained so far, so if is ain't broke, don't fix it. - Update Javadocs of ZipInputStream.putNextEntry to recommend that users should use STORED and configure sizes & crc for directory entries for correctness and performance - Change the default compression method for directories to STORED and set sizes & crc to 0. This would add the risk of changing behavior of existing code. For context, 7% of entries in the dependencies of Spring Petclinic are directories. Any thoughts or input? Thanks, Eirik. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lance.andersen at oracle.com Mon Mar 6 19:16:30 2023 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 6 Mar 2023 19:16:30 +0000 Subject: ZipOutputStream & directories In-Reply-To: References: Message-ID: Hi Eirik, Please see below On Mar 6, 2023, at 1:43 PM, Eirik Bj?rsn?s > wrote: Hi, I noticed that ZipOutputStream violates APPNOTE.txt when writing directory entries: You are referring to section: ------------ 4.3.8 File data Immediately following the local header for a file SHOULD be placed the compressed or stored data for the file. If the file is encrypted, the encryption header for the file SHOULD be placed after the local header and before the file data. The series of [local file header][encryption header] [file data][data descriptor] repeats for each file in the .ZIP archive. Zero-byte files, directories, and other file types that contain no content MUST NOT include file data. ?????? I don?t think changing the default will cause any harm but I have been surprised by even the most trivial change before. The jar tool already addresses this in Main.java:addFile() on a quick glance. So I guess I do not see a huge downside, however we might want to look at a property to adjust in the unlikely event the unexpected occurs? Alan thoughts? Zero-byte files, directories, and other file types that contain no content MUST NOT include file data. Nobody seems to have complained about this violation (I searched JBS), so in itself it might not be worth pursuing a fix. However, in addition to breaking the specification, this also causes suboptimal performance both on the write and read paths. Before I go ahead and suggest any particular solution, I wanted to share some analysis: ZipOutputStream writes directories as any other entry, so by default it ends up writing a LOC header with the DEFLATED method and the data descriptor bit set. This is followed by a final, empty DEFLATE block (0x0300) and then a signed data descriptor with the CRC, csize (2) and size (0), each 4 bytes: ------ Local File Header ------ 000000 signature 0x04034b50 000004 version 20 000006 flags 0x0808 000008 method 8 Deflated 000010 time 0x9812 19:00:36 000012 date 0x5666 2023-03-06 000014 crc 0x00000000 000018 csize 0 000022 size 0 000026 nlen 9 000028 elen 0 000030 name 9 bytes 'META-INF/' ------ File Data ------ 000039 data 2 bytes ------ Data Descriptor ------ 000041 signature 0x08074b50 000045 crc 0x00000000 000049 csize 2 000053 size 0 In total, this means that an extra 18 bytes is output, which is a waste of storage space and IO cycles while writing and reading/parsing the unnecessary headers and data. If the directory entry has the STORED method and the sizes and crc is set to 0, then the file data and data descriptors are skipped and we reclaim 18 bytes. The use of DEFLATE has an adverse negative impact on performance, since native ZLIB code needs to be called to produce and read (in ZipInputStream) the empty DEFLATE block. Worse, Deflater.reset and Inflater.reset are called, which seems to incur a significant overhead. In fact, when configuring the STORED method and explicitly setting csize, size and crc to 0, we see considerable benchmark improvements writing and reading directory entries: DEFLATED: Benchmark (size) Mode Cnt Score Error Units ZipEmptyStreams.readDirStream 512 avgt 15 0.278 ? 0.005 ms/op ZipEmptyStreams.readDirStream 1024 avgt 15 0.550 ? 0.006 ms/op ZipEmptyStreams.writeDirStreams 512 avgt 15 2.379 ? 0.043 ms/op ZipEmptyStreams.writeDirStreams 1024 avgt 15 4.845 ? 0.087 ms/op STORED: Benchmark (size) Mode Cnt Score Error Units ZipEmptyStreams.readDirStream 512 avgt 15 0.082 ? 0.001 ms/op ZipEmptyStreams.readDirStream 1024 avgt 15 0.176 ? 0.015 ms/op ZipEmptyStreams.writeDirStream 512 avgt 15 0.233 ? 0.021 ms/op ZipEmptyStreams.writeDirStream 1024 avgt 15 0.460 ? 0.028 ms/op Possible actions: - Do nothing: Nobody complained so far, so if is ain't broke, don't fix it. - Update Javadocs of ZipInputStream.putNextEntry to recommend that users should use STORED and configure sizes & crc for directory entries for correctness and performance - Change the default compression method for directories to STORED and set sizes & crc to 0. This would add the risk of changing behavior of existing code. For context, 7% of entries in the dependencies of Spring Petclinic are directories. Any thoughts or input? Thanks, Eirik. [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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: oracle_sig_logo.gif URL: From jlaskey at openjdk.org Mon Mar 6 19:16:31 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 6 Mar 2023 19:16:31 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v43] In-Reply-To: References: Message-ID: <_G-pacG_MK2x2hRQogujTpfZ7w5xT1Ep0ekHgs1w1-s=.fc5cf7fa-fa65-4256-aaa6-7ac036fb47ec@github.com> > Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 59 commits: - Merge branch 'master' into 8285932 - Javadoc corrections and bug fix for StringTemplate::combine - Tighten up reporting of string template errors (fewer messages) - Merge branch 'master' into 8285932 - Merge branch 'master' into 8285932 - Minor correction to javadoc - Merge branch 'master' into 8285932 - CSR review - Bring up to date - Merge branch 'master' into 8285932 - ... and 49 more: https://git.openjdk.org/jdk/compare/cfb0a25a...5d79f650 ------------- Changes: https://git.openjdk.org/jdk/pull/10889/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=42 Stats: 9552 lines in 81 files changed: 9452 ins; 24 del; 76 mod Patch: https://git.openjdk.org/jdk/pull/10889.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889 PR: https://git.openjdk.org/jdk/pull/10889 From duke at openjdk.org Mon Mar 6 19:22:05 2023 From: duke at openjdk.org (Matthew Donovan) Date: Mon, 6 Mar 2023 19:22:05 GMT Subject: Integrated: 8298939: Refactor open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.sh to jtreg java test In-Reply-To: References: Message-ID: On Mon, 9 Jan 2023 19:54:24 GMT, Matthew Donovan wrote: > Removed SSLSocketParametersTest.sh script (which just called a Java file) and configured the java code to run directly with jtreg This pull request has now been integrated. Changeset: ccfe1675 Author: Matthew Donovan Committer: Stuart Marks URL: https://git.openjdk.org/jdk/commit/ccfe1675a2a82accbca0ecd8bd6f1c167a1c06c6 Stats: 238 lines in 2 files changed: 34 ins; 149 del; 55 mod 8298939: Refactor open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.sh to jtreg java test Reviewed-by: dfuchs, smarks ------------- PR: https://git.openjdk.org/jdk/pull/11910 From Alan.Bateman at oracle.com Mon Mar 6 19:44:59 2023 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 6 Mar 2023 19:44:59 +0000 Subject: ZipOutputStream & directories In-Reply-To: References: Message-ID: <73dd6700-0f15-fbe0-af5c-9e87a3e9a130@oracle.com> On 06/03/2023 19:16, Lance Andersen wrote: > : > > So I guess I do not see a huge downside, however we might want to look > at a property to adjust in the unlikely event the unexpected occurs? > > Alan thoughts? > Yeah, the jar tool does the right thing and writes directories entries with the STORED method and a size of 0. Eirik's mail mentions that 7% of Spring Petclinic dependences are directories. It might be interesting to dig into that to see how they are generated, is it mostly maven-jar-plugin and if so, which APIs is it using? Changing ZOS.putNextEntry to ignore the method/size provided by the caller would change long standing behavior, and Hyrum's Law has it that somebody will notice. This may be something for an API note rather than an implementation change. -Alan From lance.andersen at oracle.com Mon Mar 6 20:05:50 2023 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 6 Mar 2023 20:05:50 +0000 Subject: ZipOutputStream & directories In-Reply-To: <73dd6700-0f15-fbe0-af5c-9e87a3e9a130@oracle.com> References: <73dd6700-0f15-fbe0-af5c-9e87a3e9a130@oracle.com> Message-ID: <2A300C81-1365-47C5-810B-5C9689441254@oracle.com> On Mar 6, 2023, at 2:44 PM, Alan Bateman > wrote: On 06/03/2023 19:16, Lance Andersen wrote: : So I guess I do not see a huge downside, however we might want to look at a property to adjust in the unlikely event the unexpected occurs? Alan thoughts? Yeah, the jar tool does the right thing and writes directories entries with the STORED method and a size of 0. Eirik's mail mentions that 7% of Spring Petclinic dependences are directories. It might be interesting to dig into that to see how they are generated, is it mostly maven-jar-plugin and if so, which APIs is it using? Changing ZOS.putNextEntry to ignore the method/size provided by the caller would change long standing behavior, and Hyrum's Law has it that somebody will notice. This may be something for an API note rather than an implementation change. That is what I was thinking (once bitten twice shy). I agree an API note is probably best Best Lance -Alan [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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: oracle_sig_logo.gif URL: From eirbjo at gmail.com Mon Mar 6 20:20:11 2023 From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=) Date: Mon, 6 Mar 2023 21:20:11 +0100 Subject: ZipOutputStream & directories In-Reply-To: <73dd6700-0f15-fbe0-af5c-9e87a3e9a130@oracle.com> References: <73dd6700-0f15-fbe0-af5c-9e87a3e9a130@oracle.com> Message-ID: On Mon, Mar 6, 2023 at 8:45?PM Alan Bateman wrote: > Changing ZOS.putNextEntry to ignore the method/size provided by the > caller would change long standing behavior, and Hyrum's Law has it that > somebody will notice. I was not thinking of changing anything if the caller actually specified a method. This would be just for the default/unspecified case, in which case ZipEntry.method is -1. So: if (e.method == -1) { if (e.isDirectory()) { // New code: e.setMethod(STORED); e.setSize(0); e.setCrc(0); } else { // Today's code: e.method = method; // use default method } } But I guess this doesn't completely alleviate concerns, since there might be code out there doing: zo.putNextEntry("directory/"); zo.write("Hello".getBytes()); (This would be very weird code, but people might have found it convenient to attach data to directories somehow). This may be something for an API note rather than > an implementation change. > Am I right that this would not be a specification change, so it would not require a CSR? Thanks, -------------- next part -------------- An HTML attachment was scrubbed... URL: From prappo at openjdk.org Mon Mar 6 20:22:48 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Mon, 6 Mar 2023 20:22:48 GMT Subject: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments [v2] In-Reply-To: References: Message-ID: > Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API. > > The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows: > > > diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html > --- build/macosx-aarch64/images/docs-before/api/serialized-form.html 2023-03-02 11:47:44 > +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html 2023-03-02 11:48:45 > @@ -17084,7 +17084,7 @@ > throws IOException, > ClassNotFoundException >

readObject is called to restore the state of the > - (@code BasicPermission} from a stream.
> + BasicPermission from a stream. >
>
Parameters:
>
s - the ObjectInputStream from which data is read
> > Notes > ----- > > * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas. > * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary. > * I will update copyright years after (and if) the fix had been approved, as required. Pavel Rappo 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 'master' into 8303480 - Initial commit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12826/files - new: https://git.openjdk.org/jdk/pull/12826/files/d2f4a553..87166408 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12826&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12826&range=00-01 Stats: 13433 lines in 415 files changed: 9003 ins; 2610 del; 1820 mod Patch: https://git.openjdk.org/jdk/pull/12826.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12826/head:pull/12826 PR: https://git.openjdk.org/jdk/pull/12826 From jjg at openjdk.org Mon Mar 6 20:31:18 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Mon, 6 Mar 2023 20:31:18 GMT Subject: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments [v2] In-Reply-To: References: <-U8YFFuXm_hMf-bY1AVCRauRrE-fRYRxrx_yf38ZL1A=.d50884c5-cc4b-489a-b817-828faf876c76@github.com> Message-ID: On Fri, 3 Mar 2023 11:31:04 GMT, Alexey Ivanov wrote: >> Yes, iff means if-and-only-if and is used for extra precision in formal logic, mathematics. As @pavelrappo points out it's a relatively common occurrence in the OpenJDK sources, though perhaps not in the public javadocs. Perhaps a bit pretentious, but mostly a terse way to say "return true if the BSM method type exactly matches X, otherwise false". >> >> The broken link stems from the fact that the method I was targeting (a way to use condy for lambda proxy singletons rather than a `MethodHandle.constant`) was never integrated. We'll look at either getting that done (@briangoetz suggested the time might be ready for it) or remove this currently pointless static bootstrap specialization test. > >> Yes, iff means if-and-only-if and is used for extra precision in formal logic, mathematics. > > I've never come across it before. With your explanations, it makes perfect sense. I would recommend (separately) changing `iff` to the expanded form `if and only if` ------------- PR: https://git.openjdk.org/jdk/pull/12826 From lance.andersen at oracle.com Mon Mar 6 20:32:56 2023 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 6 Mar 2023 20:32:56 +0000 Subject: ZipOutputStream & directories In-Reply-To: References: <73dd6700-0f15-fbe0-af5c-9e87a3e9a130@oracle.com> Message-ID: Adding an API Note will require a CSR. And yes, what we often think as the right change tends to bite us (given this code has been in the wild since the 90s) so best to err on the side of documentation vs. assuming this change would not cause more problems than it is worth. Best Lance On Mar 6, 2023, at 3:20 PM, Eirik Bj?rsn?s > wrote: On Mon, Mar 6, 2023 at 8:45?PM Alan Bateman > wrote: Changing ZOS.putNextEntry to ignore the method/size provided by the caller would change long standing behavior, and Hyrum's Law has it that somebody will notice. I was not thinking of changing anything if the caller actually specified a method. This would be just for the default/unspecified case, in which case ZipEntry.method is -1. So: if (e.method == -1) { if (e.isDirectory()) { // New code: e.setMethod(STORED); e.setSize(0); e.setCrc(0); } else { // Today's code: e.method = method; // use default method } } But I guess this doesn't completely alleviate concerns, since there might be code out there doing: zo.putNextEntry("directory/"); zo.write("Hello".getBytes()); (This would be very weird code, but people might have found it convenient to attach data to directories somehow). This may be something for an API note rather than an implementation change. Am I right that this would not be a specification change, so it would not require a CSR? Thanks, [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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: oracle_sig_logo.gif URL: From jjg at openjdk.org Mon Mar 6 20:36:13 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Mon, 6 Mar 2023 20:36:13 GMT Subject: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments [v2] In-Reply-To: References: Message-ID: The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. ---------------------------------------------------------------------- On Mon, 6 Mar 2023 20:22:48 GMT, Pavel Rappo wrote: >> Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API. >> >> The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows: >> >> >> diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html >> --- build/macosx-aarch64/images/docs-before/api/serialized-form.html 2023-03-02 11:47:44 >> +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html 2023-03-02 11:48:45 >> @@ -17084,7 +17084,7 @@ >> throws IOException, >> ClassNotFoundException >>
readObject is called to restore the state of the >> - (@code BasicPermission} from a stream.
>> + BasicPermission from a stream. >>
>>
Parameters:
>>
s - the ObjectInputStream from which data is read
>> >> Notes >> ----- >> >> * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas. >> * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary. >> * I will update copyright years after (and if) the fix had been approved, as required. > > Pavel Rappo 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 'master' into 8303480 > - Initial commit Marked as reviewed by jjg (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12826 From lancea at openjdk.org Mon Mar 6 20:39:17 2023 From: lancea at openjdk.org (Lance Andersen) Date: Mon, 6 Mar 2023 20:39:17 GMT Subject: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments [v2] In-Reply-To: References: Message-ID: On Mon, 6 Mar 2023 20:22:48 GMT, Pavel Rappo wrote: >> Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API. >> >> The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows: >> >> >> diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html >> --- build/macosx-aarch64/images/docs-before/api/serialized-form.html 2023-03-02 11:47:44 >> +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html 2023-03-02 11:48:45 >> @@ -17084,7 +17084,7 @@ >> throws IOException, >> ClassNotFoundException >>
readObject is called to restore the state of the >> - (@code BasicPermission} from a stream.
>> + BasicPermission from a stream. >>
>>
Parameters:
>>
s - the ObjectInputStream from which data is read
>> >> Notes >> ----- >> >> * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas. >> * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary. >> * I will update copyright years after (and if) the fix had been approved, as required. > > Pavel Rappo 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 'master' into 8303480 > - Initial commit Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12826 From eirbjo at gmail.com Mon Mar 6 21:21:43 2023 From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=) Date: Mon, 6 Mar 2023 22:21:43 +0100 Subject: ZipOutputStream & directories In-Reply-To: <73dd6700-0f15-fbe0-af5c-9e87a3e9a130@oracle.com> References: <73dd6700-0f15-fbe0-af5c-9e87a3e9a130@oracle.com> Message-ID: > > Eirik's mail mentions that 7% of Spring Petclinic dependences are > directories. It might be interesting to dig into that to see how they > are generated, is it mostly maven-jar-plugin and if so, which APIs is it > using? > Some stats: Of 109 JAR files, 2 do not have a manifest file, and 28 do not have a "Created-By" attribute. The distribution of "Created-By" of the remaining files: 1.4.2_09 (Apple Computer, Inc.): 1 Apache Maven Bundle Plugin: 30 Apache Maven Bundle Plugin 5.1.4: 2 Apache Maven Bundle Plugin 5.1.7: 2 Apache Maven 3.6.0: 1 Apache Maven 3.2.3: 1 Apache Maven 3.6.3: 2 Maven Jar Plugin 3.2.0: 5 Maven JAR Plugin 3.2.2: 2 1.6.0_32-b05 (Sun Microsystems Inc.): 1 1.8.0_25 (Oracle Corporation): 1 1.8.0_202 (Oracle Corporation): 1 1.8.0_252 (Oracle Corporation): 1 1.8.0_231 (Oracle Corporation): 1 1.8.0_241-b07 (Oracle Corporation): 1 1.8.0_281-b09 (Oracle Corporation): 1 1.8.0_333 (Oracle Corporation): 14 11.0.2 (Oracle Corporation 11.0.2+9): 1 11.0.8 (GraalVM Community): 1 11.0.11 (AdoptOpenJDK): 1 11.0.14 (Eclipse Adoptium): 1 11.0.13 (Eclipse Adoptium 11.0.13+8): 6 18.0.1+10 (Eclipse Adoptium): 1 I also checked which method was used for directories: 4 files had no directories. 65 files had DEFLATE only directories 34 files has STORED only directories 6 files (interestingly!) has a mix of DEFLATED and STORED directories. Here is the count of directories of each method for each file: jakarta.xml.bind-api-2.3.3.jar: STORED 17 jsonassert-1.5.1.jar: STORED 9 checker-qual-3.5.0.jar: DEFLATED 59 byte-buddy-agent-1.12.13.jar: STORED 13 spring-core-5.3.22.jar: DEFLATED 53 jboss-logging-3.4.3.Final.jar: STORED 7 spring-boot-actuator-2.7.3.jar: DEFLATED 85 spring-web-5.3.22.jar: DEFLATED 60 slf4j-api-1.7.36.jar: STORED 9 junit-jupiter-5.8.2.jar: DEFLATED 1 spring-aspects-5.3.22.jar: DEFLATED 15 micrometer-core-1.9.3.jar: DEFLATED 50 byte-buddy-1.12.13.jar: DEFLATED 48 spring-context-5.3.22.jar: DEFLATED 69 objenesis-3.2.jar: STORED 12 json-smart-2.4.8.jar: DEFLATED 11 spring-boot-starter-tomcat-2.7.3.jar: DEFLATED 1 thymeleaf-3.0.15.RELEASE.jar: STORED 42 postgresql-42.3.6.jar: DEFLATED 57 spring-context-support-5.3.22.jar: DEFLATED 17 junit-jupiter-engine-5.8.2.jar: DEFLATED 13 spring-boot-starter-2.7.3.jar: DEFLATED 1 jaxb-runtime-2.3.6.jar: STORED 39 mysql-connector-java-8.0.30.jar: STORED 36 log4j-api-2.17.2.jar: STORED 23 spring-boot-starter-jdbc-2.7.3.jar: DEFLATED 1 spring-boot-devtools-2.7.3.jar: DEFLATED 24 spring-boot-test-autoconfigure-2.7.3.jar: DEFLATED 37 spring-data-commons-2.7.2.jar: STORED 49 spring-boot-starter-actuator-2.7.3.jar: DEFLATED 1 log4j-to-slf4j-2.17.2.jar: STORED 9 spring-boot-starter-aop-2.7.3.jar: DEFLATED 1 jakarta.persistence-api-2.2.3.jar: STORED 9 logback-core-1.2.11.jar: STORED 41 spring-jcl-5.3.22.jar: DEFLATED 7 junit-platform-commons-1.8.2.jar: DEFLATED 16 assertj-core-3.22.0.jar: STORED 76 spring-test-5.3.22.jar: DEFLATED 50 json-path-2.7.0.jar: DEFLATED 16 spring-boot-starter-web-2.7.3.jar: DEFLATED 1 spring-beans-5.3.22.jar: DEFLATED 16 accessors-smart-2.4.8.jar: DEFLATED 8 jackson-core-2.13.3.jar: STORED 2 DEFLATED 20 junit-platform-engine-1.8.2.jar: DEFLATED 13 spring-aop-5.3.22.jar: DEFLATED 21 asm-9.1.jar: DEFLATED 5 spring-boot-starter-test-2.7.3.jar: DEFLATED 1 classmate-1.5.1.jar: DEFLATED 10 jandex-2.4.2.Final.jar: DEFLATED 7 snakeyaml-1.30.jar: DEFLATED 35 HdrHistogram-2.1.12.jar: DEFLATED 7 thymeleaf-extras-java8time-3.0.4.RELEASE.jar: STORED 8 spring-boot-actuator-autoconfigure-2.7.3.jar: DEFLATED 106 thymeleaf-spring5-3.0.15.RELEASE.jar: STORED 24 jakarta.activation-1.2.2.jar: STORED 11 tomcat-embed-el-9.0.65.jar: mockito-core-4.5.1.jar: DEFLATED 69 jakarta.transaction-api-1.3.3.jar: STORED 6 aspectjweaver-1.9.7.jar: DEFLATED 47 spring-boot-starter-validation-2.7.3.jar: DEFLATED 1 LatencyUtils-2.0.3.jar: STORED 6 junit-jupiter-params-5.8.2.jar: DEFLATED 29 spring-boot-starter-data-jpa-2.7.3.jar: DEFLATED 1 spring-boot-starter-logging-2.7.3.jar: DEFLATED 1 jakarta.activation-api-1.2.2.jar: STORED 6 spring-boot-starter-json-2.7.3.jar: DEFLATED 1 spring-boot-starter-thymeleaf-2.7.3.jar: DEFLATED 1 jackson-datatype-jsr310-2.13.3.jar: STORED 2 DEFLATED 15 tomcat-embed-websocket-9.0.65.jar: spring-jdbc-5.3.22.jar: DEFLATED 20 jackson-databind-2.13.3.jar: STORED 2 DEFLATED 30 jul-to-slf4j-1.7.36.jar: STORED 7 jackson-annotations-2.13.3.jar: DEFLATED 8 tomcat-embed-core-9.0.65.jar: hibernate-core-5.6.10.Final.jar: DEFLATED 344 istack-commons-runtime-3.0.12.jar: STORED 15 mockito-junit-jupiter-4.5.1.jar: DEFLATED 5 apiguardian-api-1.1.2.jar: DEFLATED 4 jakarta.annotation-api-1.3.5.jar: STORED 8 xmlunit-core-2.9.0.jar: STORED 14 bootstrap-5.1.3.jar: DEFLATED 5 hibernate-commons-annotations-5.1.2.Final.jar: DEFLATED 11 spring-webmvc-5.3.22.jar: DEFLATED 32 hibernate-validator-6.2.4.Final.jar: STORED 93 spring-boot-starter-cache-2.7.3.jar: DEFLATED 1 font-awesome-4.7.0.jar: DEFLATED 8 logback-classic-1.2.11.jar: STORED 37 jackson-module-parameter-names-2.13.3.jar: STORED 2 DEFLATED 10 unbescape-1.1.6.RELEASE.jar: STORED 12 spring-expression-5.3.22.jar: DEFLATED 10 txw2-2.3.6.jar: STORED 10 attoparser-2.0.5.RELEASE.jar: STORED 14 antlr-2.7.7.jar: STORED 13 DEFLATED 1 cache-api-1.1.1.jar: STORED 14 hamcrest-2.2.jar: DEFLATED 13 junit-jupiter-api-5.8.2.jar: DEFLATED 11 spring-tx-5.3.22.jar: DEFLATED 24 h2-2.1.214.jar: spring-data-jpa-2.7.2.jar: STORED 24 ehcache-3.10.0.jar: DEFLATED 158 spring-boot-test-2.7.3.jar: DEFLATED 27 opentest4j-1.2.0.jar: DEFLATED 3 HikariCP-4.0.3.jar: DEFLATED 16 android-json-0.0.20131108.vaadin1.jar: STORED 3 spring-boot-autoconfigure-2.7.3.jar: DEFLATED 118 jackson-datatype-jdk8-2.13.3.jar: STORED 2 DEFLATED 10 jakarta.validation-api-2.0.2.jar: STORED 14 spring-boot-2.7.3.jar: DEFLATED 105 spring-orm-5.3.22.jar: DEFLATED 10 Cheers, Eirik. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rriggs at openjdk.org Mon Mar 6 21:29:08 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 6 Mar 2023 21:29:08 GMT Subject: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments [v2] In-Reply-To: References: Message-ID: On Mon, 6 Mar 2023 20:22:48 GMT, Pavel Rappo wrote: >> Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API. >> >> The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows: >> >> >> diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html >> --- build/macosx-aarch64/images/docs-before/api/serialized-form.html 2023-03-02 11:47:44 >> +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html 2023-03-02 11:48:45 >> @@ -17084,7 +17084,7 @@ >> throws IOException, >> ClassNotFoundException >>
readObject is called to restore the state of the >> - (@code BasicPermission} from a stream.
>> + BasicPermission from a stream. >>
>>
Parameters:
>>
s - the ObjectInputStream from which data is read
>> >> Notes >> ----- >> >> * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas. >> * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary. >> * I will update copyright years after (and if) the fix had been approved, as required. > > Pavel Rappo 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 'master' into 8303480 > - Initial commit Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12826 From smarks at openjdk.org Mon Mar 6 22:34:12 2023 From: smarks at openjdk.org (Stuart Marks) Date: Mon, 6 Mar 2023 22:34:12 GMT Subject: RFR: 8217496: Matcher.group() can return null after usePattern In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 17:13:28 GMT, Ian Graves wrote: > Updates to the documentation to describe behavior in Matcher.group(). LGTM ------------- Marked as reviewed by smarks (Reviewer). PR: https://git.openjdk.org/jdk/pull/12835 From kvn at openjdk.org Mon Mar 6 23:57:16 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 6 Mar 2023 23:57:16 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter In-Reply-To: References: Message-ID: On Fri, 3 Mar 2023 21:41:35 GMT, Vladimir Kozlov wrote: > Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in Interpreter and C1 compiler to produce the same results as C2 intrinsics on x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java methods were implemented originally. > > Replaced `SharedRuntime::f2hf()` and `hf2f()` C runtime functions with calls to runtime stubs which use the same HW instructions as C2 intrinsics. Only for 64-bit x64 because 32-bit x86 stub does not work: result is passed through FPU register and NaN values become different from C2 intrinsic. This runtime stub is only used to calculate constant values during C2 compilation and can be skipped. > > I added new tests based on Tobias's `TestAll.java` And copied `jdk/lang/Float/Binary16Conversion*.java` tests to run them with `-Xcomp` to make sure code is compiled by C1 or C2. I modified `Binary16ConversionNaN.java` to compare results from Interpreter, C1 and C2. > > Tested tier1-5, Xcomp, stress @fyang, please help to verify that new tests passed on RISC-V with these changes and review these changes. Thanks! I tested x86 (64- and 32-bit) and AArch64. ------------- PR: https://git.openjdk.org/jdk/pull/12869 From sviswanathan at openjdk.org Tue Mar 7 00:22:15 2023 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Tue, 7 Mar 2023 00:22:15 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter In-Reply-To: References: Message-ID: On Mon, 6 Mar 2023 23:54:44 GMT, Vladimir Kozlov wrote: >> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in Interpreter and C1 compiler to produce the same results as C2 intrinsics on x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java methods were implemented originally. >> >> Replaced `SharedRuntime::f2hf()` and `hf2f()` C runtime functions with calls to runtime stubs which use the same HW instructions as C2 intrinsics. Only for 64-bit x64 because 32-bit x86 stub does not work: result is passed through FPU register and NaN values become different from C2 intrinsic. This runtime stub is only used to calculate constant values during C2 compilation and can be skipped. >> >> I added new tests based on Tobias's `TestAll.java` And copied `jdk/lang/Float/Binary16Conversion*.java` tests to run them with `-Xcomp` to make sure code is compiled by C1 or C2. I modified `Binary16ConversionNaN.java` to compare results from Interpreter, C1 and C2. >> >> Tested tier1-5, Xcomp, stress > > @fyang, please help to verify that new tests passed on RISC-V with these changes and review these changes. Thanks! > > I tested x86 (64- and 32-bit) and AArch64. @vnkozlov Thanks a lot for taking this up. Is the following in the PR description still true: "Replaced SharedRuntime::f2hf() and hf2f() C runtime functions with calls to runtime stubs which use the same HW instructions as C2 intrinsics. Only for 64-bit x64 because 32-bit x86 stub does not work: result is passed through FPU register and NaN values become different from C2 intrinsic." >From the PR it looks to me that for x86_64 you have the changes in place for SharedRuntime and the same result is produced across SharedRuntime, interpreter, c1, and c2. For x86 32-bit also things are consistent across. Only the SharedRuntime optimization doesnt happen for x86 32bit as StubRoutines::hf2f() and StubRoutines::f2hf() are set as null. The fallback is handled correctly in interpreter, c1, and c2. ------------- PR: https://git.openjdk.org/jdk/pull/12869 From kvn at openjdk.org Tue Mar 7 00:51:12 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 7 Mar 2023 00:51:12 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter In-Reply-To: References: Message-ID: On Tue, 7 Mar 2023 00:19:03 GMT, Sandhya Viswanathan wrote: > For x86 32-bit also things are consistent across. Only the SharedRuntime optimization doesnt happen for x86 32bit as StubRoutines::hf2f() and StubRoutines::f2hf() are set as null. The fallback is handled correctly in interpreter, c1, and c2. Correct, it is consistent. Only optimization to calculate constant value during compile time is skipped. C2 will generate HW instruction for `ConvF2HF` node as if its input was not constant. That is it. It is possible to add similar Stub routines for AArch64 and RISC-V to be called from C2 but I am not expert in those platforms so I skipped them. ------------- PR: https://git.openjdk.org/jdk/pull/12869 From kvn at openjdk.org Tue Mar 7 00:55:16 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 7 Mar 2023 00:55:16 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter In-Reply-To: References: Message-ID: On Fri, 3 Mar 2023 21:41:35 GMT, Vladimir Kozlov wrote: > Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in Interpreter and C1 compiler to produce the same results as C2 intrinsics on x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java methods were implemented originally. > > Replaced `SharedRuntime::f2hf()` and `hf2f()` C runtime functions with calls to runtime stubs which use the same HW instructions as C2 intrinsics. Only for 64-bit x64 because 32-bit x86 stub does not work: result is passed through FPU register and NaN values become different from C2 intrinsic. This runtime stub is only used to calculate constant values during C2 compilation and can be skipped. > > I added new tests based on Tobias's `TestAll.java` And copied `jdk/lang/Float/Binary16Conversion*.java` tests to run them with `-Xcomp` to make sure code is compiled by C1 or C2. I modified `Binary16ConversionNaN.java` to compare results from Interpreter, C1 and C2. > > Tested tier1-5, Xcomp, stress Note, I removed `ConvF2HFNode::Identity()` optimization because tests show that it produces different NaN results due to skipped conversion. ------------- PR: https://git.openjdk.org/jdk/pull/12869 From almatvee at openjdk.org Tue Mar 7 01:03:10 2023 From: almatvee at openjdk.org (Alexander Matveev) Date: Tue, 7 Mar 2023 01:03:10 GMT Subject: RFR: 8299779: Test tools/jpackage/share/jdk/jpackage/tests/MainClassTest.java timed out Message-ID: <6VsQikMFY5Fckwv8WB39RDFR5gzqkSwtJOXeF3IEbcg=.0ab0a46e-400c-4383-a0e8-e99d78df54e8@github.com> - Fixed by increasing test timeout. Fix verified on host which reproduced issue. ------------- Commit messages: - 8299779: Test tools/jpackage/share/jdk/jpackage/tests/MainClassTest.java timed out Changes: https://git.openjdk.org/jdk/pull/12896/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12896&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299779 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/12896.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12896/head:pull/12896 PR: https://git.openjdk.org/jdk/pull/12896 From sviswanathan at openjdk.org Tue Mar 7 01:24:19 2023 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Tue, 7 Mar 2023 01:24:19 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter In-Reply-To: References: Message-ID: On Fri, 3 Mar 2023 21:41:35 GMT, Vladimir Kozlov wrote: > Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in Interpreter and C1 compiler to produce the same results as C2 intrinsics on x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java methods were implemented originally. > > Replaced `SharedRuntime::f2hf()` and `hf2f()` C runtime functions with calls to runtime stubs which use the same HW instructions as C2 intrinsics. Only for 64-bit x64 because 32-bit x86 stub does not work: result is passed through FPU register and NaN values become different from C2 intrinsic. This runtime stub is only used to calculate constant values during C2 compilation and can be skipped. > > I added new tests based on Tobias's `TestAll.java` And copied `jdk/lang/Float/Binary16Conversion*.java` tests to run them with `-Xcomp` to make sure code is compiled by C1 or C2. I modified `Binary16ConversionNaN.java` to compare results from Interpreter, C1 and C2. > > Tested tier1-5, Xcomp, stress src/hotspot/cpu/x86/macroAssembler_x86.hpp line 199: > 197: void flt_to_flt16(Register dst, XMMRegister src, XMMRegister tmp) { > 198: // Instruction requires different XMM registers > 199: vcvtps2ph(tmp, src, 0x04, Assembler::AVX_128bit); vcvtps2ph can have source and destination as same. Did you mean to say here in the comment that "Instruction requires XMM register as destination"? src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 3928: > 3926: } > 3927: > 3928: if (VM_Version::supports_f16c() || VM_Version::supports_avx512vl()) { We could check for VM_Version::supports_float16() here instead. src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 3931: > 3929: // For results consistency both intrinsics should be enabled. > 3930: if (vmIntrinsics::is_intrinsic_available(vmIntrinsics::_float16ToFloat) && > 3931: vmIntrinsics::is_intrinsic_available(vmIntrinsics::_floatToFloat16)) { Should this also check for InlineIntrinsics? src/hotspot/cpu/x86/templateInterpreterGenerator_x86_64.cpp line 346: > 344: } > 345: // For AVX CPUs only. f16c support is disabled if UseAVX == 0. > 346: if (VM_Version::supports_f16c() || VM_Version::supports_avx512vl()) { We could check for VM_Version::supports_float16() here instead. ------------- PR: https://git.openjdk.org/jdk/pull/12869 From sviswanathan at openjdk.org Tue Mar 7 01:29:13 2023 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Tue, 7 Mar 2023 01:29:13 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter In-Reply-To: References: Message-ID: On Tue, 7 Mar 2023 00:52:37 GMT, Vladimir Kozlov wrote: > Note, I removed `ConvF2HFNode::Identity()` optimization because tests show that it produces different NaN results due to skipped conversion. Yes, removing the Identity optimization is correct. It doesn't hold for NaN inputs. ------------- PR: https://git.openjdk.org/jdk/pull/12869 From sviswanathan at openjdk.org Tue Mar 7 01:29:16 2023 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Tue, 7 Mar 2023 01:29:16 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter In-Reply-To: References: Message-ID: On Fri, 3 Mar 2023 21:41:35 GMT, Vladimir Kozlov wrote: > Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in Interpreter and C1 compiler to produce the same results as C2 intrinsics on x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java methods were implemented originally. > > Replaced `SharedRuntime::f2hf()` and `hf2f()` C runtime functions with calls to runtime stubs which use the same HW instructions as C2 intrinsics. Only for 64-bit x64 because 32-bit x86 stub does not work: result is passed through FPU register and NaN values become different from C2 intrinsic. This runtime stub is only used to calculate constant values during C2 compilation and can be skipped. > > I added new tests based on Tobias's `TestAll.java` And copied `jdk/lang/Float/Binary16Conversion*.java` tests to run them with `-Xcomp` to make sure code is compiled by C1 or C2. I modified `Binary16ConversionNaN.java` to compare results from Interpreter, C1 and C2. > > Tested tier1-5, Xcomp, stress Other than the minor comments above, the x86 side changes look good to me. ------------- PR: https://git.openjdk.org/jdk/pull/12869 From darcy at openjdk.org Tue Mar 7 01:39:14 2023 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 7 Mar 2023 01:39:14 GMT Subject: RFR: JDK-8302801: Remove fdlibm C sources [v4] In-Reply-To: References: <3JvuLUDJO3_dzKHOsMocC6kGDEmnIQo_7uobd-VTzHg=.22565440-42ae-4d26-9d74-2cbb7c63f9ea@github.com> Message-ID: On Sun, 5 Mar 2023 17:10:08 GMT, Joe Darcy wrote: > PS Successful Mach 5 job of default builds and tier 1 tests with this make line present. PPS And for extra measure as suggested by David Holmes, a tier 1 through 5 build job was also successful. ------------- PR: https://git.openjdk.org/jdk/pull/12821 From kvn at openjdk.org Tue Mar 7 02:07:21 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 7 Mar 2023 02:07:21 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter In-Reply-To: References: Message-ID: On Fri, 3 Mar 2023 21:41:35 GMT, Vladimir Kozlov wrote: > Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in Interpreter and C1 compiler to produce the same results as C2 intrinsics on x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java methods were implemented originally. > > Replaced `SharedRuntime::f2hf()` and `hf2f()` C runtime functions with calls to runtime stubs which use the same HW instructions as C2 intrinsics. Only for 64-bit x64 because 32-bit x86 stub does not work: result is passed through FPU register and NaN values become different from C2 intrinsic. This runtime stub is only used to calculate constant values during C2 compilation and can be skipped. > > I added new tests based on Tobias's `TestAll.java` And copied `jdk/lang/Float/Binary16Conversion*.java` tests to run them with `-Xcomp` to make sure code is compiled by C1 or C2. I modified `Binary16ConversionNaN.java` to compare results from Interpreter, C1 and C2. > > Tested tier1-5, Xcomp, stress Thank you for review @sviswa7. I will address you comments. ------------- PR: https://git.openjdk.org/jdk/pull/12869 From kvn at openjdk.org Tue Mar 7 02:07:26 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 7 Mar 2023 02:07:26 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter In-Reply-To: References: Message-ID: On Tue, 7 Mar 2023 01:04:00 GMT, Sandhya Viswanathan wrote: >> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in Interpreter and C1 compiler to produce the same results as C2 intrinsics on x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java methods were implemented originally. >> >> Replaced `SharedRuntime::f2hf()` and `hf2f()` C runtime functions with calls to runtime stubs which use the same HW instructions as C2 intrinsics. Only for 64-bit x64 because 32-bit x86 stub does not work: result is passed through FPU register and NaN values become different from C2 intrinsic. This runtime stub is only used to calculate constant values during C2 compilation and can be skipped. >> >> I added new tests based on Tobias's `TestAll.java` And copied `jdk/lang/Float/Binary16Conversion*.java` tests to run them with `-Xcomp` to make sure code is compiled by C1 or C2. I modified `Binary16ConversionNaN.java` to compare results from Interpreter, C1 and C2. >> >> Tested tier1-5, Xcomp, stress > > src/hotspot/cpu/x86/macroAssembler_x86.hpp line 199: > >> 197: void flt_to_flt16(Register dst, XMMRegister src, XMMRegister tmp) { >> 198: // Instruction requires different XMM registers >> 199: vcvtps2ph(tmp, src, 0x04, Assembler::AVX_128bit); > > vcvtps2ph can have source and destination as same. Did you mean to say here in the comment that "Instruction requires XMM register as destination"? `flt_to_flt16` is used in `x86.ad` instruction which requires preserving `src` register. I did not want to add an other macroassembler instruction for src->src case. I will add this to this comment. > src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 3928: > >> 3926: } >> 3927: >> 3928: if (VM_Version::supports_f16c() || VM_Version::supports_avx512vl()) { > > We could check for VM_Version::supports_float16() here instead. Yes. > src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 3931: > >> 3929: // For results consistency both intrinsics should be enabled. >> 3930: if (vmIntrinsics::is_intrinsic_available(vmIntrinsics::_float16ToFloat) && >> 3931: vmIntrinsics::is_intrinsic_available(vmIntrinsics::_floatToFloat16)) { > > Should this also check for InlineIntrinsics? `vmIntrinsics::disabled_by_jvm_flags()` checks `InlineIntrinsics`. See `vmIntrinsics.cpp` changes. > src/hotspot/cpu/x86/templateInterpreterGenerator_x86_64.cpp line 346: > >> 344: } >> 345: // For AVX CPUs only. f16c support is disabled if UseAVX == 0. >> 346: if (VM_Version::supports_f16c() || VM_Version::supports_avx512vl()) { > > We could check for VM_Version::supports_float16() here instead. Yes. And I need to remove `!InlineIntrinsics` check at line 340. ------------- PR: https://git.openjdk.org/jdk/pull/12869 From dholmes at openjdk.org Tue Mar 7 02:27:26 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 7 Mar 2023 02:27:26 GMT Subject: RFR: 8303499: [s390x] ProblemList StressStackOverflow In-Reply-To: References: Message-ID: The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. ---------------------------------------------------------------------- On Thu, 2 Mar 2023 16:22:24 GMT, Amit Kumar wrote: > This PR adds StressStackOverflow.java test to ProblemList. The feature Scope Value is not yet implemented on s390x-arch which is Incubating state. Whenever fix will be given to [JDK-8303498](https://bugs.openjdk.org/browse/JDK-8303498) then we will remove it. Wouldn't this also be an issue on AIX? ------------- PR: https://git.openjdk.org/jdk/pull/12834 From amitkumar at openjdk.org Tue Mar 7 02:30:25 2023 From: amitkumar at openjdk.org (Amit Kumar) Date: Tue, 7 Mar 2023 02:30:25 GMT Subject: RFR: 8303499: [s390x] ProblemList StressStackOverflow In-Reply-To: References: Message-ID: On Tue, 7 Mar 2023 02:23:52 GMT, David Holmes wrote: >> This PR adds StressStackOverflow.java test to ProblemList. The feature Scope Value is not yet implemented on s390x-arch which is Incubating state. Whenever fix will be given to [JDK-8303498](https://bugs.openjdk.org/browse/JDK-8303498) then we will remove it. > > Wouldn't this also be an issue on AIX? Yes @dholmes-ora it is, and I informed Tyler Steele about it. ------------- PR: https://git.openjdk.org/jdk/pull/12834 From sviswanathan at openjdk.org Tue Mar 7 02:45:15 2023 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Tue, 7 Mar 2023 02:45:15 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter In-Reply-To: References: Message-ID: On Tue, 7 Mar 2023 01:59:25 GMT, Vladimir Kozlov wrote: >> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 3931: >> >>> 3929: // For results consistency both intrinsics should be enabled. >>> 3930: if (vmIntrinsics::is_intrinsic_available(vmIntrinsics::_float16ToFloat) && >>> 3931: vmIntrinsics::is_intrinsic_available(vmIntrinsics::_floatToFloat16)) { >> >> Should this also check for InlineIntrinsics? > > `vmIntrinsics::disabled_by_jvm_flags()` checks `InlineIntrinsics`. See `vmIntrinsics.cpp` changes. Yes you are right. ------------- PR: https://git.openjdk.org/jdk/pull/12869 From dholmes at openjdk.org Tue Mar 7 02:47:16 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 7 Mar 2023 02:47:16 GMT Subject: RFR: JDK-8302360 Atomic*.compareAndExchange Javadoc unclear In-Reply-To: References: Message-ID: On Mon, 6 Mar 2023 13:23:59 GMT, Viktor Klang wrote: > I think the following proposal is very non-invasive and merely draws attention to the fact that "witness value" is a specific term related to the notion of these atomic methods. > > It's a small change which I think provides additional clarity, see JBS for the discussion on the topic. Changes requested by dholmes (Reviewer). src/java.base/share/classes/java/util/concurrent/atomic/AtomicReference.java line 357: > 355: * @param newValue the new value > 356: * @return the witness value, which is the current value > 357: * at the time of the operation. This change is not appropriate as discussed in JBS. And unclear why you changed only this version? Leftover? ------------- PR: https://git.openjdk.org/jdk/pull/12880 From kvn at openjdk.org Tue Mar 7 02:53:48 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 7 Mar 2023 02:53:48 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter [v2] In-Reply-To: References: Message-ID: <9xh4y5OLD7_ZgSgnRtBk8dUWEODYa9ut3H19y3XNGxw=.d21814f5-ac8f-4786-98ff-53b926f0ad8e@github.com> > Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in Interpreter and C1 compiler to produce the same results as C2 intrinsics on x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java methods were implemented originally. > > Replaced `SharedRuntime::f2hf()` and `hf2f()` C runtime functions with calls to runtime stubs which use the same HW instructions as C2 intrinsics. Only for 64-bit x64 because 32-bit x86 stub does not work: result is passed through FPU register and NaN values become different from C2 intrinsic. This runtime stub is only used to calculate constant values during C2 compilation and can be skipped. > > I added new tests based on Tobias's `TestAll.java` And copied `jdk/lang/Float/Binary16Conversion*.java` tests to run them with `-Xcomp` to make sure code is compiled by C1 or C2. I modified `Binary16ConversionNaN.java` to compare results from Interpreter, C1 and C2. > > Tested tier1-5, Xcomp, stress Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12869/files - new: https://git.openjdk.org/jdk/pull/12869/files/2eb47bf5..9302d4bc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12869&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12869&range=00-01 Stats: 86 lines in 8 files changed: 15 ins; 24 del; 47 mod Patch: https://git.openjdk.org/jdk/pull/12869.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12869/head:pull/12869 PR: https://git.openjdk.org/jdk/pull/12869 From kvn at openjdk.org Tue Mar 7 03:03:07 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 7 Mar 2023 03:03:07 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter In-Reply-To: References: Message-ID: On Tue, 7 Mar 2023 01:26:44 GMT, Sandhya Viswanathan wrote: >> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in Interpreter and C1 compiler to produce the same results as C2 intrinsics on x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java methods were implemented originally. >> >> Replaced `SharedRuntime::f2hf()` and `hf2f()` C runtime functions with calls to runtime stubs which use the same HW instructions as C2 intrinsics. Only for 64-bit x64 because 32-bit x86 stub does not work: result is passed through FPU register and NaN values become different from C2 intrinsic. This runtime stub is only used to calculate constant values during C2 compilation and can be skipped. >> >> I added new tests based on Tobias's `TestAll.java` And copied `jdk/lang/Float/Binary16Conversion*.java` tests to run them with `-Xcomp` to make sure code is compiled by C1 or C2. I modified `Binary16ConversionNaN.java` to compare results from Interpreter, C1 and C2. >> >> Tested tier1-5, Xcomp, stress > > Other than the minor comments above, the x86 side changes look good to me. @sviswa7 I update changes based on your comments. Please, look: [9302d4b](https://github.com/openjdk/jdk/pull/12869/commits/9302d4bc00f8f1d8e774a260eb6aacb2d51a2dd4) ------------- PR: https://git.openjdk.org/jdk/pull/12869 From martin at openjdk.org Tue Mar 7 03:57:16 2023 From: martin at openjdk.org (Martin Buchholz) Date: Tue, 7 Mar 2023 03:57:16 GMT Subject: RFR: JDK-8297605 DelayQueue javadoc is confusing In-Reply-To: <-RLFuLCSoctbO5UPfrDDmR9uiUGEv1vqGlR6Qz8WkKk=.018ccc77-32e7-47cc-988f-8de319868134@github.com> References: <3sC0ll4wZ6mBKGu6Gs2t5GHcr_JBqPDBgvvhyW5xQBk=.f9937235-271d-4d4e-9fcd-dfafe47f4315@github.com> <-RLFuLCSoctbO5UPfrDDmR9uiUGEv1vqGlR6Qz8WkKk=.018ccc77-32e7-47cc-988f-8de319868134@github.com> Message-ID: <65kSx_jUVUN-mwBg0nDva8ODtQvzeGJiA5-PAvZBSOk=.de47bc8f-1d70-4bca-9794-9bde44b8dd34@github.com> On Thu, 2 Mar 2023 15:59:33 GMT, Martin Buchholz wrote: > Right. But remove(Object) unlike remove() doesn't consider the expiration time. Confusing! Actually, confusion extends to **three** methods with the same name: - `Queue.remove()` - `Collection.remove(Object)` - `Iterator.remove()` ------------- PR: https://git.openjdk.org/jdk/pull/12729 From duke at openjdk.org Tue Mar 7 04:51:16 2023 From: duke at openjdk.org (Ravali Yatham) Date: Tue, 7 Mar 2023 04:51:16 GMT Subject: RFR: 8302791: Add specific ClassLoader object to Proxy IllegalArgumentException message [v6] In-Reply-To: References: Message-ID: On Mon, 6 Mar 2023 17:07:14 GMT, Mandy Chung wrote: >> Ravali Yatham has updated the pull request incrementally with one additional commit since the last revision: >> >> Added JavaLangAccess::getLoaderNameID(ClassLoader loader) > > Looks good. Thanks for the change. @mlchung @AlanBateman - I have issued the integrate command. Now it is ready to be sponsored. Please do the needful ------------- PR: https://git.openjdk.org/jdk/pull/12641 From jpai at openjdk.org Tue Mar 7 06:00:08 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 7 Mar 2023 06:00:08 GMT Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x [v2] In-Reply-To: <-wkW0TuI0kpzf9WxyUjqcVWZ8Q1mHMCwrWpCcCvGIwM=.b2eb9493-d0d3-408b-aa7b-26bbae671914@github.com> References: <3z7u66KVgFfL7S7S4uxDtOA6gD-WkNU7R-zon0trIVg=.d27446ca-c11d-49cc-bb85-b162e5ac58f2@github.com> <-wkW0TuI0kpzf9WxyUjqcVWZ8Q1mHMCwrWpCcCvGIwM=.b2eb9493-d0d3-408b-aa7b-26bbae671914@github.com> Message-ID: On Mon, 6 Mar 2023 13:10:57 GMT, Ilya Leoshkevich wrote: > Here are some benchmarking results: https://github.com/iii-i/zlib-ng/wiki/Performance-with-dfltcc-patch-applied-and-dfltcc-support-built-on-dfltcc-enabled-machine. The interesting data is in column `compressed_size` where `level` is 1. This is the hardware compressed size divided by the software compressed size. Most of the time it's +5-20%, in a few cases it compresses better than software, and only in one case (kennedy.xls) we see a big difference of +44%. > > P.S. Here we are compressing random data, if I read the testcase correctly (`rnd.nextBytes(dataIn);`), so poor results are expected. Ideally we should emit stored blocks, but the hardware engine does not support this at the moment. Thank you Ilya, that was helpful in understanding the current behaviour of this custom zlib implementation. ------------- PR: https://git.openjdk.org/jdk/pull/12283 From eirbjo at gmail.com Tue Mar 7 08:21:35 2023 From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=) Date: Tue, 7 Mar 2023 09:21:35 +0100 Subject: ZipOutputStream & directories In-Reply-To: References: <73dd6700-0f15-fbe0-af5c-9e87a3e9a130@oracle.com> Message-ID: On Mon, Mar 6, 2023 at 9:33?PM Lance Andersen wrote: > Adding an API Note will require a CSR. > Lance, Alan Seems we reached consensus that the right thing to do here is to add an `@apiNote` Here's a draft PR with a suggested CSR: https://github.com/openjdk/jdk/pull/12899 Thanks, Eirik. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue Mar 7 08:31:11 2023 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 7 Mar 2023 08:31:11 +0000 Subject: ZipOutputStream & directories In-Reply-To: References: <73dd6700-0f15-fbe0-af5c-9e87a3e9a130@oracle.com> Message-ID: On 06/03/2023 20:20, Eirik Bj?rsn?s wrote: > : > > I was not thinking of changing anything if the caller actually > specified a method. This would be just for the default/unspecified > case, in which case ZipEntry.method is -1. > It would require re-specifying ZOS.setMethod to set the default compression method for non-directory entries and re-specifying ZOS.putNextEntry to use the STORED method as the default for directory entries. Even so, this wouldn't ensure that directory entries have 0 size. Given that ZOS dates from JDK 1.1 then I think we have to cautious about changing. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From asotona at openjdk.org Tue Mar 7 08:38:03 2023 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 7 Mar 2023 08:38:03 GMT Subject: RFR: 8294982: Implementation of Classfile API [v36] In-Reply-To: References: <5QdeZ3Cz8gZ6QJYVrJHfaYSnQf306mumDrHWn0cCiVM=.f9198f75-3f2e-427d-bf69-0a846b39089d@github.com> Message-ID: <9U9BXKKFh-9k0rTEoQeF9UEQo0k9NkiBMWSjkrZ4hjA=.def2b4f0-d049-4b09-96c1-ff3d070302f1@github.com> On Mon, 6 Mar 2023 17:45:27 GMT, Paul Sandoz wrote: >> I see what you mean. `transforming` was selected to represent the continuation of the code building process, similar to `trying` and `catching`. While `transform` may imply that the actual code builder gets transformed into something else. For example `MethodModel::transformCode` takes `CodeModel`, applies `CodeTransform` and after that the code of the actual method is finished. >> What about `transformBlock(BlockCodeBuilder, CodeTransform)`? > > I am unsure how you might use `BlockCodeBuilder`. If the current signature is not changed then `transformFromHandler` seems reasonable (since its the handler that pushes elements into its given builder). > > The other `transform` is implicitly "transform model". I'm sorry my answer was inaccurate, what I'm proposing is `transformBlock(Consumer, CodeTransform)` or `transformedBlock(Consumer, CodeTransform)`. `BlockCodeBuilder` is just an extension of `CodeBuilder` with ability to break block execution. Block is a sub-unit of code, so I expect it would be a logical extension of the actual `block(Consumer`. I'll move this discussion to the mailing list to make common decision about API change. Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/10982 From eirbjo at gmail.com Tue Mar 7 08:44:33 2023 From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=) Date: Tue, 7 Mar 2023 09:44:33 +0100 Subject: ZipOutputStream & directories In-Reply-To: References: <73dd6700-0f15-fbe0-af5c-9e87a3e9a130@oracle.com> Message-ID: > > It would require re-specifying ZOS.setMethod to set the default > compression method for non-directory entries and re-specifying > ZOS.putNextEntry to use the STORED method as the default for directory > entries. Even so, this wouldn't ensure that directory entries have 0 size. > Given that ZOS dates from JDK 1.1 then I think we have to cautious about > changing. > I added a note to the Solution section in the suggested CSR documenting this as a road not taken. Eirik. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kim.barrett at oracle.com Tue Mar 7 10:16:26 2023 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 7 Mar 2023 10:16:26 +0000 Subject: Testing no memory leak occurs via references In-Reply-To: <1dd51557-86c5-200f-a36f-b87d7e237813@oracle.com> References: <5e0f77c6-446b-a533-0783-db7f554861c3@oracle.com> <309de0aa-51e9-ca62-da86-9774983b14af@oracle.com> <1dd51557-86c5-200f-a36f-b87d7e237813@oracle.com> Message-ID: > On Mar 6, 2023, at 10:11 AM, Aleksei Ivanov wrote: > > On 06/03/2023 13:51, Albert Yang wrote: >> Upon a cursory inspection of ForceGC.java, it seems that the fundamental logic involves waiting for a certain duration and relying on chance. However, I am of the opinion that utilizing the WhiteBox API can provide greater determinism and potentially strengthen some of the assertions. > > Yes, it calls System.gc in a loop and waits for a reference to become cleared. WhiteBox.fullGC is better. System.gc may not do a full GC; consider, for example, G1 with -XX:+ExplicitGCInvokesConcurrent. Because of potential cross-generational j.l.r.Reference and referent, one invocation might not clear a Reference that would be cleared by a full GC, and might in fact require many iterations. Also, because of SATB requirements, G1 with -XX:+ExplicitGCInvokesConcurrent might never clear a Reference if it is being checked for being cleared in the traditional way (by ref.get() == null) rather than by using the newer ref.refersTo(null). WhiteBox.fullGC deals with both of those, and there's no need for looping. The loops in functions like ForceGC are to deal with those kinds of issues. And waiting for clearing is completely pointless. A given GC invocation will either clear or not, and there's not a delay afterward. The ZGC equivalent of the second can still be a problem. Checking for a cleared Reference really should be done using Reference.refersTo. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From duke at openjdk.org Tue Mar 7 10:23:52 2023 From: duke at openjdk.org (Viktor Klang) Date: Tue, 7 Mar 2023 10:23:52 GMT Subject: RFR: JDK-8302360 Atomic*.compareAndExchange Javadoc unclear [v2] In-Reply-To: References: Message-ID: > I think the following proposal is very non-invasive and merely draws attention to the fact that "witness value" is a specific term related to the notion of these atomic methods. > > It's a small change which I think provides additional clarity, see JBS for the discussion on the topic. Viktor Klang has updated the pull request incrementally with one additional commit since the last revision: Reverting wording change to AtomicReference compareAndExchange ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12880/files - new: https://git.openjdk.org/jdk/pull/12880/files/923d23d0..d6d2e81b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12880&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12880&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/12880.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12880/head:pull/12880 PR: https://git.openjdk.org/jdk/pull/12880 From duke at openjdk.org Tue Mar 7 10:23:57 2023 From: duke at openjdk.org (Viktor Klang) Date: Tue, 7 Mar 2023 10:23:57 GMT Subject: RFR: JDK-8302360 Atomic*.compareAndExchange Javadoc unclear [v2] In-Reply-To: References: Message-ID: On Tue, 7 Mar 2023 02:43:42 GMT, David Holmes wrote: >> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision: >> >> Reverting wording change to AtomicReference compareAndExchange > > src/java.base/share/classes/java/util/concurrent/atomic/AtomicReference.java line 357: > >> 355: * @param newValue the new value >> 356: * @return the witness value, which is the current value >> 357: * at the time of the operation. > > This change is not appropriate as discussed in JBS. And unclear why you changed only this version? Leftover? @dholmes-ora Good catch, will fix. ------------- PR: https://git.openjdk.org/jdk/pull/12880 From duke at openjdk.org Tue Mar 7 10:31:09 2023 From: duke at openjdk.org (Viktor Klang) Date: Tue, 7 Mar 2023 10:31:09 GMT Subject: RFR: JDK-8297605 DelayQueue javadoc is confusing In-Reply-To: <65kSx_jUVUN-mwBg0nDva8ODtQvzeGJiA5-PAvZBSOk=.de47bc8f-1d70-4bca-9794-9bde44b8dd34@github.com> References: <3sC0ll4wZ6mBKGu6Gs2t5GHcr_JBqPDBgvvhyW5xQBk=.f9937235-271d-4d4e-9fcd-dfafe47f4315@github.com> <-RLFuLCSoctbO5UPfrDDmR9uiUGEv1vqGlR6Qz8WkKk=.018ccc77-32e7-47cc-988f-8de319868134@github.com> <65kSx_jUVUN-mwBg0nDva8ODtQvzeGJiA5-PAvZBSOk=.de47bc8f-1d70-4bca-9794-9bde44b8dd34@github.com> Message-ID: On Tue, 7 Mar 2023 03:53:59 GMT, Martin Buchholz wrote: >>> @Martin-Buchholz @pavelrappo OTOH I see that DelayQueue _has already_ overridden `remove(Object o)` so you should be able to modify that? >> >> Right. But remove(Object) unlike remove() doesn't consider the expiration time. Confusing! > >> Right. But remove(Object) unlike remove() doesn't consider the expiration time. Confusing! > > Actually, confusion extends to **three** methods with the same name: > - `Queue.remove()` > - `Collection.remove(Object)` > - `Iterator.remove()` @Martin-Buchholz Oh *that* remove() :) ------------- PR: https://git.openjdk.org/jdk/pull/12729 From asotona at openjdk.org Tue Mar 7 11:00:40 2023 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 7 Mar 2023 11:00:40 GMT Subject: RFR: 8294982: Implementation of Classfile API [v36] In-Reply-To: References: <9OJf7oMSoRjxxBMyevUqjKvG8kynN4dqVg-aO4UXoKI=.a4156836-2c7f-4758-9477-b8144eed231a@github.com> Message-ID: <5bgZYk6gc-NDpKbGDhzCKK2KD5XOup1Xfq3OTZeHMJg=.39384b5b-b7ac-449d-91e9-1d3899d24ec7@github.com> On Fri, 3 Mar 2023 16:33:49 GMT, Adam Sotona wrote: >> src/java.base/share/classes/jdk/internal/classfile/impl/TransformImpl.java line 63: >> >>> 61: private static final Runnable NOTHING = () -> { }; >>> 62: >>> 63: interface FakeClassTransform extends ClassTransform { >> >> Rename to `UnresolvedXxxTransform`? I think that is a better name, since it could appear in stack traces. Like with `XxxTransformImpl` it may be possible to share across all implementations by mixing in? > > Renamed to `UnresolvedXyzTransform`, thanks. > I'll consider conversion to generic form in a next step. Unfortunately application of common generic `UnresolvedTransform` does not work here. ------------- PR: https://git.openjdk.org/jdk/pull/10982 From mcimadamore at openjdk.org Tue Mar 7 11:18:31 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 7 Mar 2023 11:18:31 GMT Subject: RFR: 8294982: Implementation of Classfile API [v49] In-Reply-To: <17U4X6UFV0n08QWRkpROWyGLTXGBlRPQ-x3yrlPEQWY=.5e4dc9a4-49c4-4988-b365-238e3c4687e9@github.com> References: <17U4X6UFV0n08QWRkpROWyGLTXGBlRPQ-x3yrlPEQWY=.5e4dc9a4-49c4-4988-b365-238e3c4687e9@github.com> Message-ID: On Mon, 6 Mar 2023 17:11:42 GMT, Adam Sotona wrote: >> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. >> >> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. >> >> Classfile API development is tracked at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch >> >> Development branch of consolidated JDK class files parsing, generating, and transforming is at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch >> >> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. >> >> Please take you time to review this non-trivial JDK addition. >> >> Thank you, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > snippets and tests synced with jdk.jfr class instrumentation source code src/java.base/share/classes/jdk/internal/classfile/components/CodeRelabeler.java line 44: > 42: > 43: /** > 44: * CodeRelabeler is a {@link jdk.internal.classfile.CodeTransform} replacing all occurrences Nit - perhaps just use `A code relabeler is a ...` (instead of using the class name, which then would require another `{@code ... }`. src/java.base/share/classes/jdk/internal/classfile/components/package-info.java line 114: > 112: * {@snippet lang="java" class="PackageSnippets" region="classInstrumentation"} > 113: */ > 114: package jdk.internal.classfile.components; watch out for newline ------------- PR: https://git.openjdk.org/jdk/pull/10982 From ihse at openjdk.org Tue Mar 7 11:19:08 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 7 Mar 2023 11:19:08 GMT Subject: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments [v2] In-Reply-To: References: Message-ID: On Mon, 6 Mar 2023 20:22:48 GMT, Pavel Rappo wrote: >> Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API. >> >> The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows: >> >> >> diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html >> --- build/macosx-aarch64/images/docs-before/api/serialized-form.html 2023-03-02 11:47:44 >> +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html 2023-03-02 11:48:45 >> @@ -17084,7 +17084,7 @@ >> throws IOException, >> ClassNotFoundException >>
readObject is called to restore the state of the >> - (@code BasicPermission} from a stream.
>> + BasicPermission from a stream. >>
>>
Parameters:
>>
s - the ObjectInputStream from which data is read
>> >> Notes >> ----- >> >> * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas. >> * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary. >> * I will update copyright years after (and if) the fix had been approved, as required. > > Pavel Rappo 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 'master' into 8303480 > - Initial commit Marked as reviewed by ihse (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12826 From mcimadamore at openjdk.org Tue Mar 7 11:27:33 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 7 Mar 2023 11:27:33 GMT Subject: RFR: 8294982: Implementation of Classfile API [v49] In-Reply-To: <17U4X6UFV0n08QWRkpROWyGLTXGBlRPQ-x3yrlPEQWY=.5e4dc9a4-49c4-4988-b365-238e3c4687e9@github.com> References: <17U4X6UFV0n08QWRkpROWyGLTXGBlRPQ-x3yrlPEQWY=.5e4dc9a4-49c4-4988-b365-238e3c4687e9@github.com> Message-ID: On Mon, 6 Mar 2023 17:11:42 GMT, Adam Sotona wrote: >> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. >> >> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. >> >> Classfile API development is tracked at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch >> >> Development branch of consolidated JDK class files parsing, generating, and transforming is at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch >> >> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. >> >> Please take you time to review this non-trivial JDK addition. >> >> Thank you, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > snippets and tests synced with jdk.jfr class instrumentation source code Well done. The API does a great job at mastering the complexity (and, at time, ad-hocness) of the Java bytecode, and expose it in a way that is principled and useful to developers. src/java.base/share/classes/jdk/internal/classfile/impl/EntryMap.java line 194: > 192: return (int)s; > 193: } > 194: } newline! src/java.base/share/classes/jdk/internal/classfile/impl/TargetInfoImpl.java line 34: > 32: > 33: /** > 34: * TargetInfoImpl Does this javadoc add any value? Since this is implementation, we could also remove it. ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.org/jdk/pull/10982 From asotona at openjdk.org Tue Mar 7 11:27:38 2023 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 7 Mar 2023 11:27:38 GMT Subject: RFR: 8294982: Implementation of Classfile API [v36] In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 23:49:24 GMT, Paul Sandoz wrote: >> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: >> >> StackMapFrameInfo extracted to top level from StackMapTableAttribute > > src/java.base/share/classes/jdk/internal/classfile/CodeTransform.java line 91: > >> 89: @Override >> 90: default ResolvedTransform resolve(CodeBuilder builder) { >> 91: return new TransformImpl.CodeTransformImpl(e -> accept(builder, e), > > Make `CodeTransformImpl` generic in the class file element, rename to say `ResolvedTransformImpl` and reuse for the other `XxxTransform`? Good idea, I'll fix it, thanks. ------------- PR: https://git.openjdk.org/jdk/pull/10982 From Alan.Bateman at oracle.com Tue Mar 7 12:11:41 2023 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 7 Mar 2023 12:11:41 +0000 Subject: ZipOutputStream & directories In-Reply-To: References: <73dd6700-0f15-fbe0-af5c-9e87a3e9a130@oracle.com> Message-ID: <8bd49106-7dad-86a6-e217-9ebde63b26d5@oracle.com> On 07/03/2023 08:21, Eirik Bj?rsn?s wrote: > : > > Seems we reached consensus?that the right thing to do here is to add > an `@apiNote` > > Here's a draft PR with a suggested CSR: > > https://github.com/openjdk/jdk/pull/12899 > > Yes, I think an apiNote is the best thing to do here. For the note then you might want to change it to "ZipEntry e = ..." because the reader see the trailing slash after dir so it is obviously a directory. Also the javadoc uses "crc-32" rather than "crc" should we should keep that consistent if we can. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From dholmes at openjdk.org Tue Mar 7 12:18:58 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 7 Mar 2023 12:18:58 GMT Subject: RFR: JDK-8302360 Atomic*.compareAndExchange Javadoc unclear [v2] In-Reply-To: References: Message-ID: On Tue, 7 Mar 2023 10:23:52 GMT, Viktor Klang wrote: >> I think the following proposal is very non-invasive and merely draws attention to the fact that "witness value" is a specific term related to the notion of these atomic methods. >> >> It's a small change which I think provides additional clarity, see JBS for the discussion on the topic. > > Viktor Klang has updated the pull request incrementally with one additional commit since the last revision: > > Reverting wording change to AtomicReference compareAndExchange Looks fine now. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/12880 From asotona at openjdk.org Tue Mar 7 12:26:02 2023 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 7 Mar 2023 12:26:02 GMT Subject: RFR: 8294982: Implementation of Classfile API [v50] In-Reply-To: References: Message-ID: > This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. > > Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. > > Classfile API development is tracked at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch > > Development branch of consolidated JDK class files parsing, generating, and transforming is at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch > > Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. > > Please take you time to review this non-trivial JDK addition. > > Thank you, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: generic implementation of ResolvedTransform ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10982/files - new: https://git.openjdk.org/jdk/pull/10982/files/6df1297e..a87d0096 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=49 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=48-49 Stats: 46 lines in 5 files changed: 1 ins; 18 del; 27 mod Patch: https://git.openjdk.org/jdk/pull/10982.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982 PR: https://git.openjdk.org/jdk/pull/10982 From eirbjo at gmail.com Tue Mar 7 12:31:15 2023 From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=) Date: Tue, 7 Mar 2023 13:31:15 +0100 Subject: ZipOutputStream & directories In-Reply-To: <8bd49106-7dad-86a6-e217-9ebde63b26d5@oracle.com> References: <73dd6700-0f15-fbe0-af5c-9e87a3e9a130@oracle.com> <8bd49106-7dad-86a6-e217-9ebde63b26d5@oracle.com> Message-ID: > > For the note then you might want to change it to "ZipEntry e = ..." > because the reader see the trailing slash after dir so it is obviously a > directory. > That does indeed make more sense for the general case. > Also the javadoc uses "crc-32" rather than "crc" should we should keep > that consistent if we can. > I opted for the uppercase "CRC-32" here since that seems to be used in the majority of cases when referring to this checksum. I have pushed the updates to the PR and the updated the suggested CSR. I would appreciate help from someone to file an issue and CSR in JBS. Should be mostly copy paste from the PR if I got it right. Thanks, Eirik. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lance.andersen at oracle.com Tue Mar 7 12:57:46 2023 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 7 Mar 2023 12:57:46 +0000 Subject: ZipOutputStream & directories In-Reply-To: References: Message-ID: <84D44C22-2BB9-4C60-B42B-ECF8F597FCD1@oracle.com> Morning I will take care of this for you -- 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 Sent from my iPhone On Mar 7, 2023, at 7:31 AM, Eirik Bj?rsn?s wrote: ? For the note then you might want to change it to "ZipEntry e = ..." because the reader see the trailing slash after dir so it is obviously a directory. That does indeed make more sense for the general case. Also the javadoc uses "crc-32" rather than "crc" should we should keep that consistent if we can. I opted for the uppercase "CRC-32" here since that seems to be used in the majority of cases when referring to this checksum. I have pushed the updates to the PR and the updated the suggested CSR. I would appreciate help from someone to file an issue and CSR in JBS. Should be mostly copy paste from the PR if I got it right. Thanks, Eirik. -------------- next part -------------- An HTML attachment was scrubbed... URL: From asotona at openjdk.org Tue Mar 7 14:28:41 2023 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 7 Mar 2023 14:28:41 GMT Subject: RFR: 8294982: Implementation of Classfile API [v51] In-Reply-To: References: Message-ID: > This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. > > Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. > > Classfile API development is tracked at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch > > Development branch of consolidated JDK class files parsing, generating, and transforming is at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch > > Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. > > Please take you time to review this non-trivial JDK addition. > > Thank you, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: Shared `toString` formats for bound and unbound instructions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10982/files - new: https://git.openjdk.org/jdk/pull/10982/files/a87d0096..2b1bd7f8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=50 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=49-50 Stats: 59 lines in 1 file changed: 23 ins; 0 del; 36 mod Patch: https://git.openjdk.org/jdk/pull/10982.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982 PR: https://git.openjdk.org/jdk/pull/10982 From mdoerr at openjdk.org Tue Mar 7 14:33:22 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 7 Mar 2023 14:33:22 GMT Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function & Memory API (Preview) [v10] In-Reply-To: References: Message-ID: > Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification". > > This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `` (2.2.4 Variable Argument Lists). > > Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only. > > There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Will get addressed separately: [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017) > > The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests. > > I had to make changes to shared code and code for other platforms: > 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons: > - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that. > - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64. > - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian! > 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit. Martin Doerr has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: - Merge remote-tracking branch 'origin' into PPC64_Panama - Handle HFA corner cases with overlapping registers in Java. - Fix merge bug. - Merge branch 'master' into PPC64_Panama - Add test for HFA corner cases. - Minor cleanup. - HFA: Add support for nested structures. See JDK-8300294. - Remove size restriction for structs. Add TODO for Big Endian. - Clean fix for NativeMemorySegmentImpl issue with byteSize 0. - Initial Panama implementation. ------------- Changes: https://git.openjdk.org/jdk/pull/12708/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=09 Stats: 2287 lines in 59 files changed: 2157 ins; 16 del; 114 mod Patch: https://git.openjdk.org/jdk/pull/12708.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12708/head:pull/12708 PR: https://git.openjdk.org/jdk/pull/12708 From asotona at openjdk.org Tue Mar 7 14:39:04 2023 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 7 Mar 2023 14:39:04 GMT Subject: RFR: 8294982: Implementation of Classfile API [v12] In-Reply-To: References: Message-ID: On Mon, 6 Feb 2023 14:25:54 GMT, Adam Sotona wrote: >> src/java.base/share/classes/jdk/internal/classfile/CodeBuilder.java line 1371: >> >>> 1369: } >>> 1370: >>> 1371: default CodeBuilder tableswitch(Label defaultTarget, List cases) { >> >> `switch` seems the one instruction for which an high-level variant (like `trying`) could be useful, as generating code for that can be quite painful. > > Nice RFE, thanks. collected and tracked in the mailing list ------------- PR: https://git.openjdk.org/jdk/pull/10982 From asotona at openjdk.org Tue Mar 7 14:39:07 2023 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 7 Mar 2023 14:39:07 GMT Subject: RFR: 8294982: Implementation of Classfile API [v36] In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 22:05:24 GMT, Paul Sandoz wrote: >> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: >> >> StackMapFrameInfo extracted to top level from StackMapTableAttribute > > src/java.base/share/classes/jdk/internal/classfile/impl/AbstractInstruction.java line 156: > >> 154: @Override >> 155: public String toString() { >> 156: return String.format("Store[OP=%s, slot=%d]", this.opcode(), slot()); > > A suggestion. I believe the `toString` output for bound and unbound instructions should be identical and it can composed solely from methods on the public instruction interface. There are some differences e.g. `Increment` and `Inc` for the unbound and bound increment instruction respectively. > > If those assumptions are correct i recommend placing a static `toString` method on all unbound instructions that also have bound instructions, accepting the public instruction interface as an argument. Then the overridden `Object::toString` method defers to those. Thereby there is no duplication. > (Alas we cannot override `toString` on the instruction interface itself). resolved using common static format Strings ------------- PR: https://git.openjdk.org/jdk/pull/10982 From asotona at openjdk.org Tue Mar 7 14:39:09 2023 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 7 Mar 2023 14:39:09 GMT Subject: RFR: 8294982: Implementation of Classfile API [v43] In-Reply-To: References: Message-ID: On Fri, 3 Mar 2023 22:48:23 GMT, Paul Sandoz wrote: >> Adam Sotona has updated the pull request incrementally with three additional commits since the last revision: >> >> - fixed AccessFlags javadoc >> - TransformImpl.FakeXyzTransform renamed to UnresolvedXyzTransform >> - removed obsolete generic parameter from AbstractDirectBuilder > > src/java.base/share/classes/jdk/internal/classfile/impl/EntryMap.java line 176: > >> 174: } >> 175: >> 176: public static long nextPowerOfTwo( long x ) { > > If you like you can change the implementation to be: > > x = -1 >>> Long.numberOfLeadingZeros(x - 1); > return x + 1; > > See `ConcurrentHashMap`. `Long:numberOfLeadingZeros` implementation uses more method calls, conditional statements and binary operations. I would prefer to stick with the current implementation for its speed and simplicity. ------------- PR: https://git.openjdk.org/jdk/pull/10982 From asotona at openjdk.org Tue Mar 7 14:39:13 2023 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 7 Mar 2023 14:39:13 GMT Subject: RFR: 8294982: Implementation of Classfile API [v15] In-Reply-To: References: Message-ID: On Wed, 15 Feb 2023 14:24:18 GMT, Adam Sotona wrote: >> src/java.base/share/classes/jdk/internal/classfile/instruction/CharacterRange.java line 47: >> >>> 45: * {@return the start of the instruction range} >>> 46: */ >>> 47: Label startScope(); >> >> I noticed that this pattern of start/endScope is here, but also in ExceptionCatch, LocalVariable and LocalVariableType. Consider using a common interface for "instructions that are associated with a range". > > That is interesting RFE, thanks. collected and tracked in the mailing list ------------- PR: https://git.openjdk.org/jdk/pull/10982 From asotona at openjdk.org Tue Mar 7 14:39:16 2023 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 7 Mar 2023 14:39:16 GMT Subject: RFR: 8294982: Implementation of Classfile API [v36] In-Reply-To: <6znsZYLeDpBRVVQxG5tnzA8Vat1DWuPkVX8Xeu0L31o=.5b08aebd-5769-4593-8664-7a3f80ed58fb@github.com> References: <6znsZYLeDpBRVVQxG5tnzA8Vat1DWuPkVX8Xeu0L31o=.5b08aebd-5769-4593-8664-7a3f80ed58fb@github.com> Message-ID: On Fri, 3 Mar 2023 15:51:25 GMT, Adam Sotona wrote: >> src/java.base/share/classes/jdk/internal/classfile/instruction/NewObjectInstruction.java line 38: >> >>> 36: * of a {@link CodeModel}. >>> 37: */ >>> 38: public sealed interface NewObjectInstruction extends Instruction >> >> Should we add a helper method on `CodeBuilder` that does the new + dup + invoke special dance? > > That is great RFE for `CodeBuilder`, thanks. collected and tracked in the mailing list ------------- PR: https://git.openjdk.org/jdk/pull/10982 From rgiulietti at openjdk.org Tue Mar 7 14:53:28 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Tue, 7 Mar 2023 14:53:28 GMT Subject: RFR: 8303648: Add String.indexOf(String str, int beginIndex, int endIndex) Message-ID: As a followup of [JDK-8302590](https://bugs.openjdk.org/browse/JDK-8302590), this issue covers the analogous case for a search of a string rather than a character. ------------- Commit messages: - 8303648: Add String.indexOf(String str, int beginIndex, int endIndex) Changes: https://git.openjdk.org/jdk/pull/12903/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12903&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303648 Stats: 251 lines in 2 files changed: 236 ins; 5 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/12903.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12903/head:pull/12903 PR: https://git.openjdk.org/jdk/pull/12903 From asotona at openjdk.org Tue Mar 7 14:59:09 2023 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 7 Mar 2023 14:59:09 GMT Subject: RFR: 8294982: Implementation of Classfile API [v52] In-Reply-To: References: Message-ID: > This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. > > Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. > > Classfile API development is tracked at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch > > Development branch of consolidated JDK class files parsing, generating, and transforming is at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch > > Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. > > Please take you time to review this non-trivial JDK addition. > > Thank you, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: fixed CodeRelabeler javadoc ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10982/files - new: https://git.openjdk.org/jdk/pull/10982/files/2b1bd7f8..7a2b5cbe Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=51 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=50-51 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10982.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982 PR: https://git.openjdk.org/jdk/pull/10982 From asotona at openjdk.org Tue Mar 7 14:59:21 2023 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 7 Mar 2023 14:59:21 GMT Subject: RFR: 8294982: Implementation of Classfile API [v49] In-Reply-To: References: <17U4X6UFV0n08QWRkpROWyGLTXGBlRPQ-x3yrlPEQWY=.5e4dc9a4-49c4-4988-b365-238e3c4687e9@github.com> Message-ID: On Tue, 7 Mar 2023 11:14:17 GMT, Maurizio Cimadamore wrote: >> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: >> >> snippets and tests synced with jdk.jfr class instrumentation source code > > src/java.base/share/classes/jdk/internal/classfile/components/CodeRelabeler.java line 44: > >> 42: >> 43: /** >> 44: * CodeRelabeler is a {@link jdk.internal.classfile.CodeTransform} replacing all occurrences > > Nit - perhaps just use `A code relabeler is a ...` (instead of using the class name, which then would require another `{@code ... }`. fixed, thanks. > src/java.base/share/classes/jdk/internal/classfile/components/package-info.java line 114: > >> 112: * {@snippet lang="java" class="PackageSnippets" region="classInstrumentation"} >> 113: */ >> 114: package jdk.internal.classfile.components; > > watch out for newline I'm not quite sure I understand what is wrong with this javadoc fragment. Thanks. > src/java.base/share/classes/jdk/internal/classfile/impl/EntryMap.java line 194: > >> 192: return (int)s; >> 193: } >> 194: } > > newline! Here I'm also not sure I understand, the long line has bee wrapped. > src/java.base/share/classes/jdk/internal/classfile/impl/TargetInfoImpl.java line 34: > >> 32: >> 33: /** >> 34: * TargetInfoImpl > > Does this javadoc add any value? Since this is implementation, we could also remove it. This is common practise across the whole implementation. Do you suggest to remove all similar javadoc from all implementation classes? ------------- PR: https://git.openjdk.org/jdk/pull/10982 From asotona at openjdk.org Tue Mar 7 15:35:24 2023 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 7 Mar 2023 15:35:24 GMT Subject: RFR: 8294982: Implementation of Classfile API [v53] In-Reply-To: References: Message-ID: <2WHb0qQeBp4ITNvx7yLZBGcs8IR-NE-K3QnsMheBa98=.7fad7fb2-ec9f-4ae2-ac0d-5ce0e912befb@github.com> > This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. > > Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. > > Classfile API development is tracked at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch > > Development branch of consolidated JDK class files parsing, generating, and transforming is at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch > > Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. > > Please take you time to review this non-trivial JDK addition. > > Thank you, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: package jdk.internal.classfile.jdktypes moved to jdk.internal.classfile.java.lang.constant ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10982/files - new: https://git.openjdk.org/jdk/pull/10982/files/7a2b5cbe..a994c572 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=52 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=51-52 Stats: 35 lines in 26 files changed: 0 ins; 0 del; 35 mod Patch: https://git.openjdk.org/jdk/pull/10982.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982 PR: https://git.openjdk.org/jdk/pull/10982 From prappo at openjdk.org Tue Mar 7 15:35:51 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Tue, 7 Mar 2023 15:35:51 GMT Subject: Integrated: 8303480: Miscellaneous fixes to mostly invisible doc comments In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 12:03:44 GMT, Pavel Rappo wrote: > Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API. > > The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows: > > > diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html > --- build/macosx-aarch64/images/docs-before/api/serialized-form.html 2023-03-02 11:47:44 > +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html 2023-03-02 11:48:45 > @@ -17084,7 +17084,7 @@ > throws IOException, > ClassNotFoundException >
readObject is called to restore the state of the > - (@code BasicPermission} from a stream.
> + BasicPermission from a stream. >
>
Parameters:
>
s - the ObjectInputStream from which data is read
> > Notes > ----- > > * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas. > * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary. > * I will update copyright years after (and if) the fix had been approved, as required. This pull request has now been integrated. Changeset: 45a616a8 Author: Pavel Rappo URL: https://git.openjdk.org/jdk/commit/45a616a891e4a4b0e77b1f2fa040522f4a99d172 Stats: 75 lines in 39 files changed: 0 ins; 0 del; 75 mod 8303480: Miscellaneous fixes to mostly invisible doc comments Reviewed-by: mullan, prr, cjplummer, aivanov, jjg, lancea, rriggs, ihse ------------- PR: https://git.openjdk.org/jdk/pull/12826 From asotona at openjdk.org Tue Mar 7 15:43:49 2023 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 7 Mar 2023 15:43:49 GMT Subject: RFR: 8294982: Implementation of Classfile API [v36] In-Reply-To: <9U9BXKKFh-9k0rTEoQeF9UEQo0k9NkiBMWSjkrZ4hjA=.def2b4f0-d049-4b09-96c1-ff3d070302f1@github.com> References: <5QdeZ3Cz8gZ6QJYVrJHfaYSnQf306mumDrHWn0cCiVM=.f9198f75-3f2e-427d-bf69-0a846b39089d@github.com> <9U9BXKKFh-9k0rTEoQeF9UEQo0k9NkiBMWSjkrZ4hjA=.def2b4f0-d049-4b09-96c1-ff3d070302f1@github.com> Message-ID: <7LwX-JnVlPddoKRdATODlLUlBd2z8EcmK7h6JlMB7vo=.02584a1d-95e0-430f-af66-aec46c6f0894@github.com> On Tue, 7 Mar 2023 08:35:34 GMT, Adam Sotona wrote: >> I am unsure how you might use `BlockCodeBuilder`. If the current signature is not changed then `transformFromHandler` seems reasonable (since its the handler that pushes elements into its given builder). >> >> The other `transform` is implicitly "transform model". > > I'm sorry my answer was inaccurate, what I'm proposing is `transformBlock(Consumer, CodeTransform)` or `transformedBlock(Consumer, CodeTransform)`. `BlockCodeBuilder` is just an extension of `CodeBuilder` with ability to break block execution. > Block is a sub-unit of code, so I expect it would be a logical extension of the actual `block(Consumer`. > I'll move this discussion to the mailing list to make common decision about API change. > Thanks. This topic is now tracked as RFE ------------- PR: https://git.openjdk.org/jdk/pull/10982 From mcimadamore at openjdk.org Tue Mar 7 15:52:52 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 7 Mar 2023 15:52:52 GMT Subject: RFR: 8294982: Implementation of Classfile API [v49] In-Reply-To: References: <17U4X6UFV0n08QWRkpROWyGLTXGBlRPQ-x3yrlPEQWY=.5e4dc9a4-49c4-4988-b365-238e3c4687e9@github.com> Message-ID: On Tue, 7 Mar 2023 14:48:43 GMT, Adam Sotona wrote: >> src/java.base/share/classes/jdk/internal/classfile/impl/EntryMap.java line 194: >> >>> 192: return (int)s; >>> 193: } >>> 194: } >> >> newline! > > Here I'm also not sure I understand, the long line has bee wrapped. I mean here (and in the other) there seems to be a missing newline at the end of the file >> src/java.base/share/classes/jdk/internal/classfile/impl/TargetInfoImpl.java line 34: >> >>> 32: >>> 33: /** >>> 34: * TargetInfoImpl >> >> Does this javadoc add any value? Since this is implementation, we could also remove it. > > This is common practise across the whole implementation. Do you suggest to remove all similar javadoc from all implementation classes? Well, if the javadoc simply states the name of the class it doesn't seem very useful. But I leave that decision to you. ------------- PR: https://git.openjdk.org/jdk/pull/10982 From psandoz at openjdk.org Tue Mar 7 16:10:24 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Tue, 7 Mar 2023 16:10:24 GMT Subject: RFR: 8294982: Implementation of Classfile API [v43] In-Reply-To: References: Message-ID: On Tue, 7 Mar 2023 14:35:22 GMT, Adam Sotona wrote: >> src/java.base/share/classes/jdk/internal/classfile/impl/EntryMap.java line 176: >> >>> 174: } >>> 175: >>> 176: public static long nextPowerOfTwo( long x ) { >> >> If you like you can change the implementation to be: >> >> x = -1 >>> Long.numberOfLeadingZeros(x - 1); >> return x + 1; >> >> See `ConcurrentHashMap`. > > `Long:numberOfLeadingZeros` implementation uses more method calls, conditional statements and binary operations. I would prefer to stick with the current implementation for its speed and simplicity. `numberOfLeadingZeros` is an intrinsic, so it will compile down to a machine instruction. Up to you. ------------- PR: https://git.openjdk.org/jdk/pull/10982 From asotona at openjdk.org Tue Mar 7 16:10:25 2023 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 7 Mar 2023 16:10:25 GMT Subject: RFR: 8294982: Implementation of Classfile API [v49] In-Reply-To: References: <17U4X6UFV0n08QWRkpROWyGLTXGBlRPQ-x3yrlPEQWY=.5e4dc9a4-49c4-4988-b365-238e3c4687e9@github.com> Message-ID: On Tue, 7 Mar 2023 15:48:22 GMT, Maurizio Cimadamore wrote: >> Here I'm also not sure I understand, the long line has bee wrapped. > > I mean here (and in the other) there seems to be a missing newline at the end of the file OK, I'll fix it, thanks. ------------- PR: https://git.openjdk.org/jdk/pull/10982 From asotona at openjdk.org Tue Mar 7 16:19:05 2023 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 7 Mar 2023 16:19:05 GMT Subject: RFR: 8294982: Implementation of Classfile API [v54] In-Reply-To: References: Message-ID: > This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. > > Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. > > Classfile API development is tracked at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch > > Development branch of consolidated JDK class files parsing, generating, and transforming is at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch > > Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. > > Please take you time to review this non-trivial JDK addition. > > Thank you, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: fixed new lines at end of file ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10982/files - new: https://git.openjdk.org/jdk/pull/10982/files/a994c572..f14287d0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=53 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=52-53 Stats: 13 lines in 13 files changed: 0 ins; 0 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/10982.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982 PR: https://git.openjdk.org/jdk/pull/10982 From asotona at openjdk.org Tue Mar 7 16:21:36 2023 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 7 Mar 2023 16:21:36 GMT Subject: RFR: 8294982: Implementation of Classfile API [v55] In-Reply-To: References: Message-ID: > This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. > > Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. > > Classfile API development is tracked at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch > > Development branch of consolidated JDK class files parsing, generating, and transforming is at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch > > Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. > > Please take you time to review this non-trivial JDK addition. > > Thank you, > Adam Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 183 commits: - Merge branch 'master' into JDK-8294982 - fixed new lines at end of file - package jdk.internal.classfile.jdktypes moved to jdk.internal.classfile.java.lang.constant - fixed CodeRelabeler javadoc - Shared `toString` formats for bound and unbound instructions - generic implementation of ResolvedTransform - snippets and tests synced with jdk.jfr class instrumentation source code - simplified initialization of terminal builder in chained builders - simplified CodeImpl.SINGLETON_INSTRUCTIONS initialization - fixed handling of array descriptors by Util::toInternalName - ... and 173 more: https://git.openjdk.org/jdk/compare/45a616a8...4680572a ------------- Changes: https://git.openjdk.org/jdk/pull/10982/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=54 Stats: 53052 lines in 322 files changed: 53048 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/10982.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982 PR: https://git.openjdk.org/jdk/pull/10982 From sviswanathan at openjdk.org Tue Mar 7 17:02:23 2023 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Tue, 7 Mar 2023 17:02:23 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter [v2] In-Reply-To: <9xh4y5OLD7_ZgSgnRtBk8dUWEODYa9ut3H19y3XNGxw=.d21814f5-ac8f-4786-98ff-53b926f0ad8e@github.com> References: <9xh4y5OLD7_ZgSgnRtBk8dUWEODYa9ut3H19y3XNGxw=.d21814f5-ac8f-4786-98ff-53b926f0ad8e@github.com> Message-ID: On Tue, 7 Mar 2023 02:53:48 GMT, Vladimir Kozlov wrote: >> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in Interpreter and C1 compiler to produce the same results as C2 intrinsics on x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java methods were implemented originally. >> >> Replaced `SharedRuntime::f2hf()` and `hf2f()` C runtime functions with calls to runtime stubs which use the same HW instructions as C2 intrinsics. Only for 64-bit x64 because 32-bit x86 stub does not work: result is passed through FPU register and NaN values become different from C2 intrinsic. This runtime stub is only used to calculate constant values during C2 compilation and can be skipped. >> >> I added new tests based on Tobias's `TestAll.java` And copied `jdk/lang/Float/Binary16Conversion*.java` tests to run them with `-Xcomp` to make sure code is compiled by C1 or C2. I modified `Binary16ConversionNaN.java` to compare results from Interpreter, C1 and C2. >> >> Tested tier1-5, Xcomp, stress > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments The PR looks good to me. ------------- Marked as reviewed by sviswanathan (Reviewer). PR: https://git.openjdk.org/jdk/pull/12869 From igraves at openjdk.org Tue Mar 7 17:23:52 2023 From: igraves at openjdk.org (Ian Graves) Date: Tue, 7 Mar 2023 17:23:52 GMT Subject: Integrated: 8217496: Matcher.group() can return null after usePattern In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 17:13:28 GMT, Ian Graves wrote: > Updates to the documentation to describe behavior in Matcher.group(). This pull request has now been integrated. Changeset: ac3ab5b0 Author: Ian Graves URL: https://git.openjdk.org/jdk/commit/ac3ab5b00754a6d96dcb107edb7b82ba582f15b9 Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod 8217496: Matcher.group() can return null after usePattern Reviewed-by: smarks ------------- PR: https://git.openjdk.org/jdk/pull/12835 From jlu at openjdk.org Tue Mar 7 18:22:30 2023 From: jlu at openjdk.org (Justin Lu) Date: Tue, 7 Mar 2023 18:22:30 GMT Subject: Integrated: 8303275: Use {@Return and @linkplain in Locale and related classes In-Reply-To: <9XzLdPaTCaYpzrJStx2riu1ZTMIYEgZOkPIy_CgK5jk=.0ec33845-108e-4651-9e6e-6be6c7cc3ef4@github.com> References: <9XzLdPaTCaYpzrJStx2riu1ZTMIYEgZOkPIy_CgK5jk=.0ec33845-108e-4651-9e6e-6be6c7cc3ef4@github.com> Message-ID: On Tue, 28 Feb 2023 00:09:45 GMT, Justin Lu wrote: > This PR modifies the javadoc of methods in Locale, LocaleServiceProvider, and LocaleServiceProviderPool to use {@return and @linkplain. This pull request has now been integrated. Changeset: acf89961 Author: Justin Lu Committer: Naoto Sato URL: https://git.openjdk.org/jdk/commit/acf899612f9b6c4fdd919c40a92ce9c40b3744ed Stats: 107 lines in 3 files changed: 11 ins; 19 del; 77 mod 8303275: Use {@Return and @linkplain in Locale and related classes Reviewed-by: naoto ------------- PR: https://git.openjdk.org/jdk/pull/12780 From jbhateja at openjdk.org Tue Mar 7 18:33:11 2023 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Tue, 7 Mar 2023 18:33:11 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter In-Reply-To: References: Message-ID: On Tue, 7 Mar 2023 03:00:34 GMT, Vladimir Kozlov wrote: >> Other than the minor comments above, the x86 side changes look good to me. > > @sviswa7 I update changes based on your comments. Please, look: [9302d4b](https://github.com/openjdk/jdk/pull/12869/commits/9302d4bc00f8f1d8e774a260eb6aacb2d51a2dd4) Hi @vnkozlov , There is some discrepancy in results b/w interpreter, C1 and C2 for following case. public class Foo { public static short bar(float f) {return Float.floatToFloat16(f);} public static void main(String[] args) { System.out.println(Float.floatToRawIntBits(Float.float16ToFloat((short) 31745))); System.out.println(bar(Float.float16ToFloat((short) 31745))); } } CPROMPT>java -Xint -cp . Foo 2143297536 // FP32 QNaN + significand preserved 32257 // FP16 QNaN + significand preserved CPROMPT>java -Xbatch -Xcomp -cp . Foo 2139103232 // FP32 SNaN + significand preserved 31745 // FP16 SNaN + significand preserved CPROMPT>java -XX:-TieredCompilation -Xbatch -Xcomp -cp . Foo 2139103232 // FP32 SNaN + significand preserved 32257 // FP16 QNaN + significand preserved. ------------- PR: https://git.openjdk.org/jdk/pull/12869 From qamai at openjdk.org Tue Mar 7 18:34:01 2023 From: qamai at openjdk.org (Quan Anh Mai) Date: Tue, 7 Mar 2023 18:34:01 GMT Subject: RFR: 8303762: [vectorapi] Intrinsification of Vector.slice Message-ID: `Vector::slice` is a method at the top-level class of the Vector API that concatenates the 2 inputs into an intermediate composite and extracts a window equal to the size of the inputs into the result. It is used in vector conversion methods where the part number is not 0 to slice the parts to the correct positions. Slicing is also used in text processing such as utf8 and utf16 validation. x86 starting from SSSE3 has `palignr` which does vector slicing very efficiently. As a result, I think it is beneficial to add a C2 node for this operation as well as intrinsify `Vector::slice` method. A slice is currently implemented as `v2.rearrange(iota).blend(v1.rearrange(iota), blendMask)` which requires preparation of the index vector and the blending mask. Even with the preparations being hoisted out of the loops, microbenchmarks show improvement using the slice instrinsics. Some have tremendous increases in throughput due to the limitation that a mask of length 2 cannot currently be intrinsified, leading to falling back to the Java implementations. Please take a look and have some reviews. Thank you very much. ------------- Commit messages: - sse2, increase warmup - aesthetic - optimise 64B - add jmh - vector slice intrinsics Changes: https://git.openjdk.org/jdk/pull/12909/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12909&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303762 Stats: 1699 lines in 58 files changed: 1376 ins; 257 del; 66 mod Patch: https://git.openjdk.org/jdk/pull/12909.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12909/head:pull/12909 PR: https://git.openjdk.org/jdk/pull/12909 From qamai at openjdk.org Tue Mar 7 18:34:01 2023 From: qamai at openjdk.org (Quan Anh Mai) Date: Tue, 7 Mar 2023 18:34:01 GMT Subject: RFR: 8303762: [vectorapi] Intrinsification of Vector.slice In-Reply-To: References: Message-ID: On Tue, 7 Mar 2023 18:23:42 GMT, Quan Anh Mai wrote: > `Vector::slice` is a method at the top-level class of the Vector API that concatenates the 2 inputs into an intermediate composite and extracts a window equal to the size of the inputs into the result. It is used in vector conversion methods where the part number is not 0 to slice the parts to the correct positions. Slicing is also used in text processing such as utf8 and utf16 validation. x86 starting from SSSE3 has `palignr` which does vector slicing very efficiently. As a result, I think it is beneficial to add a C2 node for this operation as well as intrinsify `Vector::slice` method. > > A slice is currently implemented as `v2.rearrange(iota).blend(v1.rearrange(iota), blendMask)` which requires preparation of the index vector and the blending mask. Even with the preparations being hoisted out of the loops, microbenchmarks show improvement using the slice instrinsics. Some have tremendous increases in throughput due to the limitation that a mask of length 2 cannot currently be intrinsified, leading to falling back to the Java implementations. > > Please take a look and have some reviews. Thank you very much. Benchmark results: Before After Benchmark (size) Mode Cnt Score Error Score Error Units Change Byte128Vector.sliceBinaryConstant 1024 thrpt 5 5058.760 ? 2214.115 8315.263 ? 102.169 ops/ms +64.37% Byte256Vector.sliceBinaryConstant 1024 thrpt 5 6986.299 ? 1028.257 8440.387 ? 30.163 ops/ms +20.81% Byte64Vector.sliceBinaryConstant 1024 thrpt 5 2944.869 ? 849.548 5926.054 ? 493.146 ops/ms +101.23% ByteMaxVector.sliceBinaryConstant 1024 thrpt 5 7269.226 ? 366.246 8201.184 ? 309.539 ops/ms +12.82% Double128Vector.sliceBinaryConstant 1024 thrpt 5 10.204 ? 0.508 979.287 ? 19.991 ops/ms x95.97 Double256Vector.sliceBinaryConstant 1024 thrpt 5 868.085 ? 26.378 967.799 ? 10.224 ops/ms +11.49% DoubleMaxVector.sliceBinaryConstant 1024 thrpt 5 813.646 ? 74.468 978.150 ? 14.316 ops/ms +20.22% Float128Vector.sliceBinaryConstant 1024 thrpt 5 1297.281 ? 23.650 1850.995 ? 29.741 ops/ms +42.68% Float256Vector.sliceBinaryConstant 1024 thrpt 5 1796.121 ? 26.662 2011.362 ? 38.418 ops/ms +11.98% Float64Vector.sliceBinaryConstant 1024 thrpt 5 10.381 ? 0.194 1628.510 ? 8.752 ops/ms x156.87 FloatMaxVector.sliceBinaryConstant 1024 thrpt 5 1820.161 ? 26.802 1988.085 ? 41.835 ops/ms +9.23% Int128Vector.sliceBinaryConstant 1024 thrpt 5 1394.911 ? 40.815 1864.818 ? 33.792 ops/ms +33.69% Int256Vector.sliceBinaryConstant 1024 thrpt 5 1874.496 ? 60.541 1864.818 ? 33.792 ops/ms -0.52% Int64Vector.sliceBinaryConstant 1024 thrpt 5 10.942 ? 0.377 1621.849 ? 56.538 ops/ms x148.22 IntMaxVector.sliceBinaryConstant 1024 thrpt 5 1870.746 ? 40.665 2027.041 ? 25.880 ops/ms +8.35% Long128Vector.sliceBinaryConstant 1024 thrpt 5 10.595 ? 0.306 991.969 ? 15.033 ops/ms x93.63 Long256Vector.sliceBinaryConstant 1024 thrpt 5 815.689 ? 12.243 989.365 ? 25.969 ops/ms +21.29% LongMaxVector.sliceBinaryConstant 1024 thrpt 5 822.060 ? 12.337 977.061 ? 31.968 ops/ms +18.86% Short128Vector.sliceBinaryConstant 1024 thrpt 5 3062.676 ? 124.796 3890.796 ? 326.767 ops/ms +27.04% Short256Vector.sliceBinaryConstant 1024 thrpt 5 3747.778 ? 119.356 4125.463 ? 33.602 ops/ms +10.08% Short64Vector.sliceBinaryConstant 1024 thrpt 5 1879.203 ? 69.160 2899.515 ? 57.870 ops/ms +54.29% ShortMaxVector.sliceBinaryConstant 1024 thrpt 5 3717.217 ? 48.876 4035.455 ? 102.725 ops/ms +8.56% ------------- PR: https://git.openjdk.org/jdk/pull/12909 From jlu at openjdk.org Tue Mar 7 18:34:21 2023 From: jlu at openjdk.org (Justin Lu) Date: Tue, 7 Mar 2023 18:34:21 GMT Subject: Integrated: 6453901: (cal) clean up sun.util.calendar classes In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 21:58:15 GMT, Justin Lu wrote: > This PR includes cleanup changes to the sun.util.calendar package only. > > The changes include removing unused methods, imports, adjusting incorrect links, and using newer syntax patterns. Since there are no plans to promote any of these classes to java.calendar, these unused methods can be removed. > > > Mach5: https://mach5.us.oracle.com/mdash/jobs/jclu-jdk2-20230228-2223-42671403 This pull request has now been integrated. Changeset: f1f4e1de Author: Justin Lu Committer: Naoto Sato URL: https://git.openjdk.org/jdk/commit/f1f4e1de445cbec44f871791e93d4dd566c232f1 Stats: 211 lines in 10 files changed: 1 ins; 182 del; 28 mod 6453901: (cal) clean up sun.util.calendar classes Reviewed-by: naoto, lancea ------------- PR: https://git.openjdk.org/jdk/pull/12817 From kvn at openjdk.org Tue Mar 7 18:41:37 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 7 Mar 2023 18:41:37 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter In-Reply-To: References: Message-ID: On Tue, 7 Mar 2023 03:00:34 GMT, Vladimir Kozlov wrote: >> Other than the minor comments above, the x86 side changes look good to me. > > @sviswa7 I update changes based on your comments. Please, look: [9302d4b](https://github.com/openjdk/jdk/pull/12869/commits/9302d4bc00f8f1d8e774a260eb6aacb2d51a2dd4) > Hi @vnkozlov , There is some discrepancy in results b/w interpreter, C1 and C2 for following case. And that is fine. Consistency have to be preserved only during one run. Different runs with different flags (with disabled intrinsics, for example) may produce different results. ------------- PR: https://git.openjdk.org/jdk/pull/12869 From kvn at openjdk.org Tue Mar 7 18:48:53 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 7 Mar 2023 18:48:53 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter [v2] In-Reply-To: <9xh4y5OLD7_ZgSgnRtBk8dUWEODYa9ut3H19y3XNGxw=.d21814f5-ac8f-4786-98ff-53b926f0ad8e@github.com> References: <9xh4y5OLD7_ZgSgnRtBk8dUWEODYa9ut3H19y3XNGxw=.d21814f5-ac8f-4786-98ff-53b926f0ad8e@github.com> Message-ID: On Tue, 7 Mar 2023 02:53:48 GMT, Vladimir Kozlov wrote: >> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in Interpreter and C1 compiler to produce the same results as C2 intrinsics on x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java methods were implemented originally. >> >> Replaced `SharedRuntime::f2hf()` and `hf2f()` C runtime functions with calls to runtime stubs which use the same HW instructions as C2 intrinsics. Only for 64-bit x64 because 32-bit x86 stub does not work: result is passed through FPU register and NaN values become different from C2 intrinsic. This runtime stub is only used to calculate constant values during C2 compilation and can be skipped. >> >> I added new tests based on Tobias's `TestAll.java` And copied `jdk/lang/Float/Binary16Conversion*.java` tests to run them with `-Xcomp` to make sure code is compiled by C1 or C2. I modified `Binary16ConversionNaN.java` to compare results from Interpreter, C1 and C2. >> >> Tested tier1-5, Xcomp, stress > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments On other hand `-Xint` should not disable intrinsics. I will look. ------------- PR: https://git.openjdk.org/jdk/pull/12869 From kvn at openjdk.org Tue Mar 7 19:01:39 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 7 Mar 2023 19:01:39 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter [v2] In-Reply-To: <9xh4y5OLD7_ZgSgnRtBk8dUWEODYa9ut3H19y3XNGxw=.d21814f5-ac8f-4786-98ff-53b926f0ad8e@github.com> References: <9xh4y5OLD7_ZgSgnRtBk8dUWEODYa9ut3H19y3XNGxw=.d21814f5-ac8f-4786-98ff-53b926f0ad8e@github.com> Message-ID: <6vpmSEQIHUeuayoEWhm124zzQY2CgwxG-hydLzjm4Z4=.47ad041b-1c49-4c06-ba9d-66f64f5fb7a1@github.com> On Tue, 7 Mar 2023 02:53:48 GMT, Vladimir Kozlov wrote: >> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in Interpreter and C1 compiler to produce the same results as C2 intrinsics on x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java methods were implemented originally. >> >> Replaced `SharedRuntime::f2hf()` and `hf2f()` C runtime functions with calls to runtime stubs which use the same HW instructions as C2 intrinsics. Only for 64-bit x64 because 32-bit x86 stub does not work: result is passed through FPU register and NaN values become different from C2 intrinsic. This runtime stub is only used to calculate constant values during C2 compilation and can be skipped. >> >> I added new tests based on Tobias's `TestAll.java` And copied `jdk/lang/Float/Binary16Conversion*.java` tests to run them with `-Xcomp` to make sure code is compiled by C1 or C2. I modified `Binary16ConversionNaN.java` to compare results from Interpreter, C1 and C2. >> >> Tested tier1-5, Xcomp, stress > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments It looks like C1 compilation does not invoke intrinsics. Investigating. ------------- PR: https://git.openjdk.org/jdk/pull/12869 From kvn at openjdk.org Tue Mar 7 20:28:25 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 7 Mar 2023 20:28:25 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter [v2] In-Reply-To: <9xh4y5OLD7_ZgSgnRtBk8dUWEODYa9ut3H19y3XNGxw=.d21814f5-ac8f-4786-98ff-53b926f0ad8e@github.com> References: <9xh4y5OLD7_ZgSgnRtBk8dUWEODYa9ut3H19y3XNGxw=.d21814f5-ac8f-4786-98ff-53b926f0ad8e@github.com> Message-ID: On Tue, 7 Mar 2023 02:53:48 GMT, Vladimir Kozlov wrote: >> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in Interpreter and C1 compiler to produce the same results as C2 intrinsics on x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java methods were implemented originally. >> >> Replaced `SharedRuntime::f2hf()` and `hf2f()` C runtime functions with calls to runtime stubs which use the same HW instructions as C2 intrinsics. Only for 64-bit x64 because 32-bit x86 stub does not work: result is passed through FPU register and NaN values become different from C2 intrinsic. This runtime stub is only used to calculate constant values during C2 compilation and can be skipped. >> >> I added new tests based on Tobias's `TestAll.java` And copied `jdk/lang/Float/Binary16Conversion*.java` tests to run them with `-Xcomp` to make sure code is compiled by C1 or C2. I modified `Binary16ConversionNaN.java` to compare results from Interpreter, C1 and C2. >> >> Tested tier1-5, Xcomp, stress > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments We should not allow JIT compilation of `Float.float16ToFloat` and `Float.floatToFloat16` Java methods as we do for other math methods: [abstractInterpreter.hpp#L144](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/interpreter/abstractInterpreter.hpp#L144) What happens with @jatin-bhateja test is `Float` class is still not loaded when we trigger compilation for `Foo::main` method with `-Xcomp` flag. C2 generates Uncommon trap at the very start of `main()` and code is deoptimized and goes to Interpreter which uses intrinsics. C1 on other hand generates calls to `Float.float16ToFloat` and `Float.floatToFloat16` in compiled `Foo::main` method and then compiles `Float.float16ToFloat` and `Float.floatToFloat16` which are called. The fix ix simple: +++ b/src/hotspot/share/interpreter/abstractInterpreter.hpp @@ -159,6 +159,8 @@ class AbstractInterpreter: AllStatic { case vmIntrinsics::_dexp : // fall thru case vmIntrinsics::_fmaD : // fall thru case vmIntrinsics::_fmaF : // fall thru + case vmIntrinsics::_floatToFloat16 : // fall thru + case vmIntrinsics::_float16ToFloat : // fall thru case vmIntrinsics::_Continuation_doYield : // fall thru return false; test now produce the same result: $ java -Xint Foo 2143297536 32257 $ java -Xcomp -XX:-TieredCompilation Foo 2143297536 32257 $ java -Xcomp -XX:TieredStopAtLevel=1 Foo 2143297536 32257 ------------- PR: https://git.openjdk.org/jdk/pull/12869 From kvn at openjdk.org Tue Mar 7 20:35:04 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 7 Mar 2023 20:35:04 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter [v2] In-Reply-To: <9xh4y5OLD7_ZgSgnRtBk8dUWEODYa9ut3H19y3XNGxw=.d21814f5-ac8f-4786-98ff-53b926f0ad8e@github.com> References: <9xh4y5OLD7_ZgSgnRtBk8dUWEODYa9ut3H19y3XNGxw=.d21814f5-ac8f-4786-98ff-53b926f0ad8e@github.com> Message-ID: <_z_y5VwjSFljVZjnn-lM7X6ecLtPpkSSSfKEiFjDCA4=.2d84e402-c22c-40e3-9a05-40977fd2ed63@github.com> On Tue, 7 Mar 2023 02:53:48 GMT, Vladimir Kozlov wrote: >> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in Interpreter and C1 compiler to produce the same results as C2 intrinsics on x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java methods were implemented originally. >> >> Replaced `SharedRuntime::f2hf()` and `hf2f()` C runtime functions with calls to runtime stubs which use the same HW instructions as C2 intrinsics. Only for 64-bit x64 because 32-bit x86 stub does not work: result is passed through FPU register and NaN values become different from C2 intrinsic. This runtime stub is only used to calculate constant values during C2 compilation and can be skipped. >> >> I added new tests based on Tobias's `TestAll.java` And copied `jdk/lang/Float/Binary16Conversion*.java` tests to run them with `-Xcomp` to make sure code is compiled by C1 or C2. I modified `Binary16ConversionNaN.java` to compare results from Interpreter, C1 and C2. >> >> Tested tier1-5, Xcomp, stress > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments C2 also compiled `float16ToFloat`. That is why we got `FP32 SNaN` result with `-XX:-TieredCompilation` in Jatin's example. ------------- PR: https://git.openjdk.org/jdk/pull/12869 From dnsimon at openjdk.org Tue Mar 7 20:52:16 2023 From: dnsimon at openjdk.org (Doug Simon) Date: Tue, 7 Mar 2023 20:52:16 GMT Subject: RFR: 8303431: [JVMCI] libgraal annotation API [v3] In-Reply-To: References: Message-ID: On Sun, 5 Mar 2023 22:37:38 GMT, Doug Simon wrote: >> This PR extends JVMCI with new API (`jdk.vm.ci.meta.Annotated`) for accessing annotations. The main differences from `java.lang.reflect.AnnotatedElement` are: >> * Each `Annotated` method explicitly specifies the annotation type(s) for which it wants annotation data. That is, there is no direct equivalent of `AnnotatedElement.getAnnotations()`. >> * Annotation data is returned in a map-like object (of type `jdk.vm.ci.meta.AnnotationData`) instead of in an `Annotation` object. This works better for libgraal as it avoids the need for annotation types to be loaded and included in libgraal. >> >> To demonstrate the new API, here's an example in terms `java.lang.reflect.AnnotatedElement` (which `ResolvedJavaType` implements): >> >> ResolvedJavaMethod method = ...; >> ExplodeLoop a = method.getAnnotation(ExplodeLoop.class); >> return switch (a.kind()) { >> case FULL_UNROLL -> LoopExplosionKind.FULL_UNROLL; >> case FULL_UNROLL_UNTIL_RETURN -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN; >> ... >> } >> >> >> The same code using the new API: >> >> >> ResolvedJavaMethod method = ...; >> ResolvedJavaType explodeLoopType = ...; >> AnnotationData a = method.getAnnotationDataFor(explodeLoopType); >> return switch (a.getEnum("kind").getName()) { >> case "FULL_UNROLL" -> LoopExplosionKind.FULL_UNROLL; >> case "FULL_UNROLL_UNTIL_RETURN" -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN; >> ... >> } >> >> >> The implementation relies on new methods in `jdk.internal.vm.VMSupport` for parsing annotations and serializing/deserializing to/from a byte array. This allows the annotation data to be passed from the HotSpot heap to the libgraal heap. > > Doug Simon has updated the pull request incrementally with one additional commit since the last revision: > > fixed whitespace This PR still needs work. I'll re-open it when ready. ------------- PR: https://git.openjdk.org/jdk/pull/12810 From dnsimon at openjdk.org Tue Mar 7 20:52:17 2023 From: dnsimon at openjdk.org (Doug Simon) Date: Tue, 7 Mar 2023 20:52:17 GMT Subject: Withdrawn: 8303431: [JVMCI] libgraal annotation API In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 18:07:34 GMT, Doug Simon wrote: > This PR extends JVMCI with new API (`jdk.vm.ci.meta.Annotated`) for accessing annotations. The main differences from `java.lang.reflect.AnnotatedElement` are: > * Each `Annotated` method explicitly specifies the annotation type(s) for which it wants annotation data. That is, there is no direct equivalent of `AnnotatedElement.getAnnotations()`. > * Annotation data is returned in a map-like object (of type `jdk.vm.ci.meta.AnnotationData`) instead of in an `Annotation` object. This works better for libgraal as it avoids the need for annotation types to be loaded and included in libgraal. > > To demonstrate the new API, here's an example in terms `java.lang.reflect.AnnotatedElement` (which `ResolvedJavaType` implements): > > ResolvedJavaMethod method = ...; > ExplodeLoop a = method.getAnnotation(ExplodeLoop.class); > return switch (a.kind()) { > case FULL_UNROLL -> LoopExplosionKind.FULL_UNROLL; > case FULL_UNROLL_UNTIL_RETURN -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN; > ... > } > > > The same code using the new API: > > > ResolvedJavaMethod method = ...; > ResolvedJavaType explodeLoopType = ...; > AnnotationData a = method.getAnnotationDataFor(explodeLoopType); > return switch (a.getEnum("kind").getName()) { > case "FULL_UNROLL" -> LoopExplosionKind.FULL_UNROLL; > case "FULL_UNROLL_UNTIL_RETURN" -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN; > ... > } > > > The implementation relies on new methods in `jdk.internal.vm.VMSupport` for parsing annotations and serializing/deserializing to/from a byte array. This allows the annotation data to be passed from the HotSpot heap to the libgraal heap. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/12810 From kvn at openjdk.org Tue Mar 7 21:38:38 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 7 Mar 2023 21:38:38 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter [v3] In-Reply-To: References: Message-ID: The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. ---------------------------------------------------------------------- > Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in Interpreter and C1 compiler to produce the same results as C2 intrinsics on x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java methods were implemented originally. > > Replaced `SharedRuntime::f2hf()` and `hf2f()` C runtime functions with calls to runtime stubs which use the same HW instructions as C2 intrinsics. Only for 64-bit x64 because 32-bit x86 stub does not work: result is passed through FPU register and NaN values become different from C2 intrinsic. This runtime stub is only used to calculate constant values during C2 compilation and can be skipped. > > I added new tests based on Tobias's `TestAll.java` And copied `jdk/lang/Float/Binary16Conversion*.java` tests to run them with `-Xcomp` to make sure code is compiled by C1 or C2. I modified `Binary16ConversionNaN.java` to compare results from Interpreter, C1 and C2. > > Tested tier1-5, Xcomp, stress Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: Do not allow JIT compilation of Float.float16ToFloat and Float.floatToFloat16 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12869/files - new: https://git.openjdk.org/jdk/pull/12869/files/9302d4bc..ed01863d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12869&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12869&range=01-02 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12869.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12869/head:pull/12869 PR: https://git.openjdk.org/jdk/pull/12869 From kvn at openjdk.org Tue Mar 7 21:38:40 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 7 Mar 2023 21:38:40 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter In-Reply-To: References: Message-ID: On Tue, 7 Mar 2023 18:28:46 GMT, Jatin Bhateja wrote: >> @sviswa7 I update changes based on your comments. Please, look: [9302d4b](https://github.com/openjdk/jdk/pull/12869/commits/9302d4bc00f8f1d8e774a260eb6aacb2d51a2dd4) > > Hi @vnkozlov , There is some discrepancy in results b/w interpreter, C1 and C2 for following case. > > public class Foo { > public static short bar(float f) {return Float.floatToFloat16(f);} > public static void main(String[] args) { > System.out.println(Float.floatToRawIntBits(Float.float16ToFloat((short) 31745))); > System.out.println(bar(Float.float16ToFloat((short) 31745))); > } > } > > CPROMPT>java -Xint -cp . Foo > 2143297536 // FP32 QNaN + significand preserved > 32257 // FP16 QNaN + significand preserved > CPROMPT>java -Xbatch -Xcomp -cp . Foo > 2139103232 // FP32 SNaN + significand preserved > 31745 // FP16 SNaN + significand preserved > CPROMPT>java -XX:-TieredCompilation -Xbatch -Xcomp -cp . Foo > 2139103232 // FP32 SNaN + significand preserved > 32257 // FP16 QNaN + significand preserved. @jatin-bhateja I applied the fix. Please, verify. ------------- PR: https://git.openjdk.org/jdk/pull/12869 From darcy at openjdk.org Tue Mar 7 22:31:42 2023 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 7 Mar 2023 22:31:42 GMT Subject: Integrated: JDK-8302801: Remove fdlibm C sources In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 05:54:52 GMT, Joe Darcy wrote: > While the review of https://github.com/openjdk/jdk/pull/12800 finishes up, I thought I'd get out for the review the next phase of the FDLIBM port: removing the FDLIBM C sources from the repo. > > A repo with the changes for JDK-8302027 and this PR successful build on the default set of platform and successfully run tier 1 tests, which includes tests of the math library. > > There are a few remaining references to the case-independent string "fdlibm" in the make directory and HotSpot sources. HotSpot contains a partial fork for FDLIBM (a tine of FDLIBM?) to use for intrinsics. The remaining make machinery contains logic to determine what set of gcc options can be used for the compile. > > The intention of this change is to remove use of FDLIBM for the core libraries. This pull request has now been integrated. Changeset: b5b5cba7 Author: Joe Darcy URL: https://git.openjdk.org/jdk/commit/b5b5cba7feb0e7ef957fd6bef1e591fdb6fdaa9f Stats: 6643 lines in 65 files changed: 20 ins; 6613 del; 10 mod 8302801: Remove fdlibm C sources Reviewed-by: bpb, dholmes, alanb, kvn ------------- PR: https://git.openjdk.org/jdk/pull/12821 From duke at openjdk.org Tue Mar 7 22:34:28 2023 From: duke at openjdk.org (Ravali Yatham) Date: Tue, 7 Mar 2023 22:34:28 GMT Subject: Integrated: 8302791: Add specific ClassLoader object to Proxy IllegalArgumentException message In-Reply-To: References: Message-ID: On Sun, 19 Feb 2023 08:28:37 GMT, Ravali Yatham wrote: > Added specific class loader object to proxy IllegalArgumentException from which the class was not visible > > The bug report for the same: https://bugs.openjdk.org/browse/JDK-8302791 This pull request has now been integrated. Changeset: 9f9d6785 Author: Ravali Yatham Committer: Mandy Chung URL: https://git.openjdk.org/jdk/commit/9f9d678591e02ecaeae7b81eeefb0ba41c7b4dae Stats: 15 lines in 4 files changed: 14 ins; 0 del; 1 mod 8302791: Add specific ClassLoader object to Proxy IllegalArgumentException message Reviewed-by: alanb, mchung ------------- PR: https://git.openjdk.org/jdk/pull/12641 From jlu at openjdk.org Tue Mar 7 23:05:13 2023 From: jlu at openjdk.org (Justin Lu) Date: Tue, 7 Mar 2023 23:05:13 GMT Subject: RFR: 8171156: Class java.util.LocaleISOData has outdated information for country Code NP Message-ID: <0CQdEFn8R2OO_XAG5RSmSYgN-jm8-G0tv7SuETPD8-4=.d6cd8746-0a64-47f5-a38d-cce5ede7009d@github.com> The java.util.LocaleISOData.isoCountryTable has an incorrect formal name for Nepal. According to [Wikipedia](https://en.wikipedia.org/wiki/Nepal) and the [UN](https://www.un.int/protocol/sites/www.un.int/files/Protocol%20and%20Liaison%20Service/officialnamesofcountries.pdf), Nepal's formal name should be `Federal Democratic Republic of Nepal`, not `Kingdom of Nepal`. It is only a comment, however there is no reason it should not be corrected. ------------- Commit messages: - Update Nepal formal name in ISO 3166 table Changes: https://git.openjdk.org/jdk/pull/12912/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12912&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8171156 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/12912.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12912/head:pull/12912 PR: https://git.openjdk.org/jdk/pull/12912 From naoto at openjdk.org Tue Mar 7 23:48:07 2023 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 7 Mar 2023 23:48:07 GMT Subject: RFR: 8171156: Class java.util.LocaleISOData has outdated information for country Code NP In-Reply-To: <0CQdEFn8R2OO_XAG5RSmSYgN-jm8-G0tv7SuETPD8-4=.d6cd8746-0a64-47f5-a38d-cce5ede7009d@github.com> References: <0CQdEFn8R2OO_XAG5RSmSYgN-jm8-G0tv7SuETPD8-4=.d6cd8746-0a64-47f5-a38d-cce5ede7009d@github.com> Message-ID: On Tue, 7 Mar 2023 22:55:56 GMT, Justin Lu wrote: > The java.util.LocaleISOData.isoCountryTable has an incorrect formal name for Nepal. > > According to [Wikipedia](https://en.wikipedia.org/wiki/Nepal) and the [UN](https://www.un.int/protocol/sites/www.un.int/files/Protocol%20and%20Liaison%20Service/officialnamesofcountries.pdf), Nepal's formal name should be `Federal Democratic Republic of Nepal`, not `Kingdom of Nepal`. It is only a comment, however there is no reason it should not be corrected. Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12912 From psandoz at openjdk.org Wed Mar 8 00:32:17 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Wed, 8 Mar 2023 00:32:17 GMT Subject: RFR: 8303762: [vectorapi] Intrinsification of Vector.slice In-Reply-To: References: Message-ID: <_PA9oL9dVd3Yrg0sXw3m0uwfGjP6TuqXGBm5M090GHM=.a09a8733-e59e-4b6d-a6a6-e518a8518450@github.com> On Tue, 7 Mar 2023 18:23:42 GMT, Quan Anh Mai wrote: > `Vector::slice` is a method at the top-level class of the Vector API that concatenates the 2 inputs into an intermediate composite and extracts a window equal to the size of the inputs into the result. It is used in vector conversion methods where the part number is not 0 to slice the parts to the correct positions. Slicing is also used in text processing such as utf8 and utf16 validation. x86 starting from SSSE3 has `palignr` which does vector slicing very efficiently. As a result, I think it is beneficial to add a C2 node for this operation as well as intrinsify `Vector::slice` method. > > A slice is currently implemented as `v2.rearrange(iota).blend(v1.rearrange(iota), blendMask)` which requires preparation of the index vector and the blending mask. Even with the preparations being hoisted out of the loops, microbenchmarks show improvement using the slice instrinsics. Some have tremendous increases in throughput due to the limitation that a mask of length 2 cannot currently be intrinsified, leading to falling back to the Java implementations. > > Please take a look and have some reviews. Thank you very much. src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java line 2289: > 2287: getClass(), byte.class, length(), > 2288: this, that, origin, > 2289: new VectorSliceOp() { Change from inner class to lambda expression? ------------- PR: https://git.openjdk.org/jdk/pull/12909 From psandoz at openjdk.org Wed Mar 8 00:49:16 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Wed, 8 Mar 2023 00:49:16 GMT Subject: RFR: 8303762: [vectorapi] Intrinsification of Vector.slice In-Reply-To: References: Message-ID: <_btCmeotboVIVWcIbHksJAaRcJO5aFl0CPVRnqpkuj0=.e3405352-fa81-4707-babe-25061abd99c5@github.com> On Tue, 7 Mar 2023 18:23:42 GMT, Quan Anh Mai wrote: > `Vector::slice` is a method at the top-level class of the Vector API that concatenates the 2 inputs into an intermediate composite and extracts a window equal to the size of the inputs into the result. It is used in vector conversion methods where the part number is not 0 to slice the parts to the correct positions. Slicing is also used in text processing such as utf8 and utf16 validation. x86 starting from SSSE3 has `palignr` which does vector slicing very efficiently. As a result, I think it is beneficial to add a C2 node for this operation as well as intrinsify `Vector::slice` method. > > A slice is currently implemented as `v2.rearrange(iota).blend(v1.rearrange(iota), blendMask)` which requires preparation of the index vector and the blending mask. Even with the preparations being hoisted out of the loops, microbenchmarks show improvement using the slice instrinsics. Some have tremendous increases in throughput due to the limitation that a mask of length 2 cannot currently be intrinsified, leading to falling back to the Java implementations. > > Please take a look and have some reviews. Thank you very much. test/hotspot/jtreg/compiler/vectorapi/TestVectorSlice.java line 65: > 63: Asserts.assertEquals(expected, dst[i][j]); > 64: } > 65: } It should be possible to factor out this code into something like this: assertOffsets(length, (expected, i, j) -> Assert.assertEquals((byte)expected, dst[i][j]) test/hotspot/jtreg/compiler/vectorapi/TestVectorSlice.java line 68: > 66: > 67: length = 16; > 68: testB128(dst, src1, src2); Should `dst` be zeroed before the next call? or maybe easier to just reallocate. test/jdk/jdk/incubator/vector/templates/Kernel-Slice-bop-const.template line 1: > 1: $type$[] a = fa.apply(SPECIES.length()); Forgot to commit the updated unit tests? ------------- PR: https://git.openjdk.org/jdk/pull/12909 From david.holmes at oracle.com Wed Mar 8 00:56:31 2023 From: david.holmes at oracle.com (David Holmes) Date: Wed, 8 Mar 2023 10:56:31 +1000 Subject: Integrated: JDK-8302801: Remove fdlibm C sources In-Reply-To: References: Message-ID: Please note this fix has a problem with a missing definition for IEEEremainder that is causing UnsatisfiedLinkError. You can expect some significant noise in testing above tier 1 until this is fixed - which will hopefully be in the next 30 minutes or so. Otherwise a Backout will be performed. David On 8/03/2023 8:31 am, Joe Darcy wrote: > On Thu, 2 Mar 2023 05:54:52 GMT, Joe Darcy wrote: > >> While the review of https://github.com/openjdk/jdk/pull/12800 finishes up, I thought I'd get out for the review the next phase of the FDLIBM port: removing the FDLIBM C sources from the repo. >> >> A repo with the changes for JDK-8302027 and this PR successful build on the default set of platform and successfully run tier 1 tests, which includes tests of the math library. >> >> There are a few remaining references to the case-independent string "fdlibm" in the make directory and HotSpot sources. HotSpot contains a partial fork for FDLIBM (a tine of FDLIBM?) to use for intrinsics. The remaining make machinery contains logic to determine what set of gcc options can be used for the compile. >> >> The intention of this change is to remove use of FDLIBM for the core libraries. > > This pull request has now been integrated. > > Changeset: b5b5cba7 > Author: Joe Darcy > URL: https://git.openjdk.org/jdk/commit/b5b5cba7feb0e7ef957fd6bef1e591fdb6fdaa9f > Stats: 6643 lines in 65 files changed: 20 ins; 6613 del; 10 mod > > 8302801: Remove fdlibm C sources > > Reviewed-by: bpb, dholmes, alanb, kvn > > ------------- > > PR: https://git.openjdk.org/jdk/pull/12821 From darcy at openjdk.org Wed Mar 8 01:37:05 2023 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 8 Mar 2023 01:37:05 GMT Subject: RFR: JDK-8303794: IEEEremainder problems are causing test failures after JDK-8302801 Message-ID: Quick port of IEEEremainder; sorry for missing this earlier. Will add targeted tests in a follow-up fix. ------------- Commit messages: - Fixes. - JDK-8303794: IEEEremainder problems are causing test failures after JDK-8302801 Changes: https://git.openjdk.org/jdk/pull/12915/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12915&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303794 Stats: 165 lines in 2 files changed: 164 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12915.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12915/head:pull/12915 PR: https://git.openjdk.org/jdk/pull/12915 From dholmes at openjdk.org Wed Mar 8 01:41:11 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 8 Mar 2023 01:41:11 GMT Subject: RFR: JDK-8303794: IEEEremainder problems are causing test failures after JDK-8302801 In-Reply-To: References: Message-ID: On Wed, 8 Mar 2023 01:30:58 GMT, Joe Darcy wrote: > Quick port of IEEEremainder; sorry for missing this earlier. Will add targeted tests in a follow-up fix. I can't attest to the correctness of the algorithm but I assume the necessary testing has been done in that regard. I can attest to this fixing the UnsatisfiedLinkError. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/12915 From fyang at openjdk.org Wed Mar 8 01:57:31 2023 From: fyang at openjdk.org (Fei Yang) Date: Wed, 8 Mar 2023 01:57:31 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter [v3] In-Reply-To: References: Message-ID: On Tue, 7 Mar 2023 21:38:38 GMT, Vladimir Kozlov wrote: >> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in Interpreter and C1 compiler to produce the same results as C2 intrinsics on x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java methods were implemented originally. >> >> Replaced `SharedRuntime::f2hf()` and `hf2f()` C runtime functions with calls to runtime stubs which use the same HW instructions as C2 intrinsics. Only for 64-bit x64 because 32-bit x86 stub does not work: result is passed through FPU register and NaN values become different from C2 intrinsic. This runtime stub is only used to calculate constant values during C2 compilation and can be skipped. >> >> I added new tests based on Tobias's `TestAll.java` And copied `jdk/lang/Float/Binary16Conversion*.java` tests to run them with `-Xcomp` to make sure code is compiled by C1 or C2. I modified `Binary16ConversionNaN.java` to compare results from Interpreter, C1 and C2. >> >> Tested tier1-5, Xcomp, stress > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Do not allow JIT compilation of Float.float16ToFloat and Float.floatToFloat16 Hi, Thanks for handling linux-riscv64 at the same time. Bad news is that we witnessed test failures when running following test with QEMU (no riscv hardware available with Zfhmin extension for now): test/hotspot/jtreg/compiler/intrinsics/float16/TestAllFloat16ToFloat.java Exception in thread "main" java.lang.RuntimeException: Inconsistent result for Float.floatToFloat16(NaN/7fc00000): 7e00 != fc01 at TestAllFloat16ToFloat.verify(TestAllFloat16ToFloat.java:62) at TestAllFloat16ToFloat.run(TestAllFloat16ToFloat.java:72) at TestAllFloat16ToFloat.main(TestAllFloat16ToFloat.java:94) It looks like there is a problem when handling NaNs with fcvt.h.s/fmv.x.h and fmv.h.x/fcvt.s.h instructions at the bottom. It's also possible to be an issue of QEMU as well. It would take quite a while to diagnose. But I don't want this to block this PR. So I would prefer removing support of this feature for this port and adding back once this is resolved. And I have prepared a patch for that purpose. See attachement. [12869-revert-riscv.txt](https://github.com/openjdk/jdk/files/10915606/12869-revert-riscv.txt) ------------- PR: https://git.openjdk.org/jdk/pull/12869 From bpb at openjdk.org Wed Mar 8 02:30:05 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 8 Mar 2023 02:30:05 GMT Subject: RFR: JDK-8303794: IEEEremainder problems are causing test failures after JDK-8302801 In-Reply-To: References: Message-ID: On Wed, 8 Mar 2023 01:30:58 GMT, Joe Darcy wrote: > Quick port of IEEEremainder; sorry for missing this earlier. Will add targeted tests in a follow-up fix. Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12915 From dholmes at openjdk.org Wed Mar 8 02:39:32 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 8 Mar 2023 02:39:32 GMT Subject: RFR: 8303799: [BACKOUT] JDK-8302801 Remove fdlibm C sources Message-ID: This reverts commit b5b5cba7feb0e7ef957fd6bef1e591fdb6fdaa9f. Thanks. ------------- Commit messages: - Revert "8302801: Remove fdlibm C sources" Changes: https://git.openjdk.org/jdk/pull/12916/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12916&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303799 Stats: 6643 lines in 65 files changed: 6613 ins; 20 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/12916.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12916/head:pull/12916 PR: https://git.openjdk.org/jdk/pull/12916 From darcy at openjdk.org Wed Mar 8 02:39:32 2023 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 8 Mar 2023 02:39:32 GMT Subject: RFR: 8303799: [BACKOUT] JDK-8302801 Remove fdlibm C sources In-Reply-To: References: Message-ID: <5FoTd9vTbjbqt5elKqfE5JL8rN_HDV_2t1BzMGRGiCE=.4b7253e9-647e-43b9-8853-bfe2f66f0c4e@github.com> On Wed, 8 Mar 2023 02:27:21 GMT, David Holmes wrote: > This reverts commit b5b5cba7feb0e7ef957fd6bef1e591fdb6fdaa9f. > > Thanks. Sorry for the noise (and missing IEEERemainer)! Thanks @dholmes-ora . ------------- Marked as reviewed by darcy (Reviewer). PR: https://git.openjdk.org/jdk/pull/12916 From bpb at openjdk.org Wed Mar 8 02:39:32 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 8 Mar 2023 02:39:32 GMT Subject: RFR: 8303799: [BACKOUT] JDK-8302801 Remove fdlibm C sources In-Reply-To: References: Message-ID: <4oeA0sOeKyTZtgAkE6avxboBskYMbaOE-oaV3fRNtHE=.2d5eda40-4689-46d1-90ed-022ce53f69fe@github.com> On Wed, 8 Mar 2023 02:27:21 GMT, David Holmes wrote: > This reverts commit b5b5cba7feb0e7ef957fd6bef1e591fdb6fdaa9f. > > Thanks. Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12916 From dholmes at openjdk.org Wed Mar 8 02:40:04 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 8 Mar 2023 02:40:04 GMT Subject: RFR: 8303799: [BACKOUT] JDK-8302801 Remove fdlibm C sources In-Reply-To: <5FoTd9vTbjbqt5elKqfE5JL8rN_HDV_2t1BzMGRGiCE=.4b7253e9-647e-43b9-8853-bfe2f66f0c4e@github.com> References: <5FoTd9vTbjbqt5elKqfE5JL8rN_HDV_2t1BzMGRGiCE=.4b7253e9-647e-43b9-8853-bfe2f66f0c4e@github.com> Message-ID: On Wed, 8 Mar 2023 02:31:09 GMT, Joe Darcy wrote: >> This reverts commit b5b5cba7feb0e7ef957fd6bef1e591fdb6fdaa9f. >> >> Thanks. > > Sorry for the noise (and missing IEEERemainer)! Thanks @dholmes-ora . Thanks for the reviews @jddarcy and @bplb ! ------------- PR: https://git.openjdk.org/jdk/pull/12916 From dholmes at openjdk.org Wed Mar 8 02:42:18 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 8 Mar 2023 02:42:18 GMT Subject: Integrated: 8303799: [BACKOUT] JDK-8302801 Remove fdlibm C sources In-Reply-To: References: Message-ID: The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. ---------------------------------------------------------------------- On Wed, 8 Mar 2023 02:27:21 GMT, David Holmes wrote: > This reverts commit b5b5cba7feb0e7ef957fd6bef1e591fdb6fdaa9f. > > Thanks. This pull request has now been integrated. Changeset: 21a6ab1e Author: David Holmes URL: https://git.openjdk.org/jdk/commit/21a6ab1e3ea5228a31955d58fe75e5ae66d1c6cd Stats: 6643 lines in 65 files changed: 6613 ins; 20 del; 10 mod 8303799: [BACKOUT] JDK-8302801 Remove fdlibm C sources Reviewed-by: darcy, bpb ------------- PR: https://git.openjdk.org/jdk/pull/12916 From philip.race at oracle.com Wed Mar 8 03:18:11 2023 From: philip.race at oracle.com (Philip Race) Date: Tue, 7 Mar 2023 19:18:11 -0800 Subject: Testing no memory leak occurs via references In-Reply-To: <1dd51557-86c5-200f-a36f-b87d7e237813@oracle.com> References: <5e0f77c6-446b-a533-0783-db7f554861c3@oracle.com> <309de0aa-51e9-ca62-da86-9774983b14af@oracle.com> <1dd51557-86c5-200f-a36f-b87d7e237813@oracle.com> Message-ID: Having just a very few sources of wisdom on this in the JDK test suites is a good idea because then any tests that might be affected by policy changes would be easily spotted. I say this despite an instinctive reticence to rely on "frameworks" and "utilities" in jtreg tests. As resources allow we should look into that (across all areas). I don't know if tests which expect to run with the default GC would be wise setting a specific GC. Testing "out of the box" is more important to (eg) client tests. I also think native code is a problem because a lot of tests are run using jtreg *outside* of a build. ie add jtreg and a build to your path and then run jtreg. This is actually normal not an aberration. It has come to me as a surprise in the past that folks who work on VM etc were surprised at this :-) So its not easy to build the native code then. The observations about the fragility of the VM in OOME situations is noted. Also othervm mode just seems a lot safer for all the above tests. -phil. PS someone On 3/6/23 7:11 AM, Aleksei Ivanov wrote: > On 06/03/2023 13:51, Albert Yang wrote: >> Upon a cursory inspection of ForceGC.java, it seems that the >> fundamental logic involves waiting for a certain duration and relying >> on chance. However, I am of the opinion that utilizing the WhiteBox >> API can provide greater determinism and potentially strengthen some >> of the assertions. > > Yes, it calls System.gc in a loop and waits for a reference to become > cleared. > > (It looks as if the body of ForceGC duplicates what one would have in > the passed BooleanSupplier which again tests if a reference is cleared.) > >>> I decided ForceGC is simpler and easier to use >> I was not aware of your specific requirements, so I cannot say for >> certain which approach is best. (However, it is worth noting that the >> WhiteBox API can be utilized to implement ForceGC if necessary.) > > My test is written to ensure awt.List gets garbage-collected when > there are no strong references to it. Before JDK-8040076 had been > fixed it wasn't. > > So the test creates awt.List, adds it to a frame, calls > setMultipleMode(true) to enable multi-selection in the list component, > removes it from the frame. At this point, I want to confirm the > awt.List can be garbage-collected. > > The original test created a very long String to cause OutOfMemoryError > and then verified whether the WeakReference to awt.List is cleared or > not. > > In my first fix, I replaced generating OutOfMemoryError with a call to > System.gc() in a loop and waited for the reference object to be > cleared. Usually, the reference is cleared in the second iteration if > not in the first one. > > Essentially, ForceGC does the same thing. So, it replaced my custom > code with ForceGC. > From kvn at openjdk.org Wed Mar 8 05:17:53 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 8 Mar 2023 05:17:53 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter [v4] In-Reply-To: References: Message-ID: > Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in Interpreter and C1 compiler to produce the same results as C2 intrinsics on x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java methods were implemented originally. > > Replaced `SharedRuntime::f2hf()` and `hf2f()` C runtime functions with calls to runtime stubs which use the same HW instructions as C2 intrinsics. Only for 64-bit x64 because 32-bit x86 stub does not work: result is passed through FPU register and NaN values become different from C2 intrinsic. This runtime stub is only used to calculate constant values during C2 compilation and can be skipped. > > I added new tests based on Tobias's `TestAll.java` And copied `jdk/lang/Float/Binary16Conversion*.java` tests to run them with `-Xcomp` to make sure code is compiled by C1 or C2. I modified `Binary16ConversionNaN.java` to compare results from Interpreter, C1 and C2. > > Tested tier1-5, Xcomp, stress Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: Remove RISC-V port code for float16 intrinsics ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12869/files - new: https://git.openjdk.org/jdk/pull/12869/files/ed01863d..9f4b2474 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12869&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12869&range=02-03 Stats: 130 lines in 13 files changed: 0 ins; 116 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/12869.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12869/head:pull/12869 PR: https://git.openjdk.org/jdk/pull/12869 From kvn at openjdk.org Wed Mar 8 05:17:56 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 8 Mar 2023 05:17:56 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter [v3] In-Reply-To: References: Message-ID: The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. ---------------------------------------------------------------------- On Wed, 8 Mar 2023 01:53:14 GMT, Fei Yang wrote: >> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> Do not allow JIT compilation of Float.float16ToFloat and Float.floatToFloat16 > > Hi, Thanks for handling linux-riscv64 at the same time. > Bad news is that we witnessed test failures when running following test with QEMU (no riscv hardware available with Zfhmin extension for now): test/hotspot/jtreg/compiler/intrinsics/float16/TestAllFloat16ToFloat.java > > > Exception in thread "main" java.lang.RuntimeException: Inconsistent result for Float.floatToFloat16(NaN/7fc00000): 7e00 != fc01 > at TestAllFloat16ToFloat.verify(TestAllFloat16ToFloat.java:62) > at TestAllFloat16ToFloat.run(TestAllFloat16ToFloat.java:72) > at TestAllFloat16ToFloat.main(TestAllFloat16ToFloat.java:94) > > > It looks like there is a problem when handling NaNs with fcvt.h.s/fmv.x.h and fmv.h.x/fcvt.s.h instructions at the bottom. > It's also possible to be an issue of QEMU as well. It would take quite a while to diagnose. But I don't want this to block this PR. > So I would prefer removing support of this feature for this port and adding back once this is resolved. And I have prepared a patch for that purpose. See attachement. > [12869-revert-riscv.txt](https://github.com/openjdk/jdk/files/10915606/12869-revert-riscv.txt) Thank you very much @RealFYang for testing changes and preparing patch. I applied your patch. ------------- PR: https://git.openjdk.org/jdk/pull/12869 From asotona at openjdk.org Wed Mar 8 08:21:35 2023 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 8 Mar 2023 08:21:35 GMT Subject: RFR: 8294982: Implementation of Classfile API [v56] In-Reply-To: References: Message-ID: > This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. > > Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. > > Classfile API development is tracked at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch > > Development branch of consolidated JDK class files parsing, generating, and transforming is at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch > > Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. > > Please take you time to review this non-trivial JDK addition. > > Thank you, > Adam Adam Sotona has updated the pull request incrementally with two additional commits since the last revision: - EntryMap::nextPowerOfTwo delegates to Long:numberOfLeadingZeros - fixed CodeBuilder:constantInstruction for -0.0d and -0.0f values and added test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10982/files - new: https://git.openjdk.org/jdk/pull/10982/files/4680572a..b49aae8b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=55 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=54-55 Stats: 21 lines in 3 files changed: 9 ins; 6 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/10982.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982 PR: https://git.openjdk.org/jdk/pull/10982 From asotona at openjdk.org Wed Mar 8 08:39:00 2023 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 8 Mar 2023 08:39:00 GMT Subject: RFR: 8294982: Implementation of Classfile API [v57] In-Reply-To: References: Message-ID: <4eShqAabbn7pqte61nbzRE6kIBbGK3tzrOxWKlCRX14=.96a519a0-048c-4ca3-97e2-108ffd0cfcb6@github.com> > This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. > > Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. > > Classfile API development is tracked at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch > > Development branch of consolidated JDK class files parsing, generating, and transforming is at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch > > Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. > > Please take you time to review this non-trivial JDK addition. > > Thank you, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: minor fix in CodeBuilder and added test cases to LDCTest ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10982/files - new: https://git.openjdk.org/jdk/pull/10982/files/b49aae8b..cd4a01cd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=56 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=55-56 Stats: 8 lines in 2 files changed: 5 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/10982.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982 PR: https://git.openjdk.org/jdk/pull/10982 From asotona at openjdk.org Wed Mar 8 08:39:03 2023 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 8 Mar 2023 08:39:03 GMT Subject: RFR: 8294982: Implementation of Classfile API [v43] In-Reply-To: References: Message-ID: On Tue, 7 Mar 2023 16:06:17 GMT, Paul Sandoz wrote: >> `Long:numberOfLeadingZeros` implementation uses more method calls, conditional statements and binary operations. I would prefer to stick with the current implementation for its speed and simplicity. > > `numberOfLeadingZeros` is an intrinsic, so it will compile down to a machine instruction. Up to you. Oh, I've changed it, thanks. ------------- PR: https://git.openjdk.org/jdk/pull/10982 From jbhateja at openjdk.org Wed Mar 8 08:39:27 2023 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Wed, 8 Mar 2023 08:39:27 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter [v4] In-Reply-To: References: Message-ID: <7DG9mLetq1UlaCe0EbNx-Lvk6roh05PalMDwmGsPQwU=.a6a01b6a-8575-49d5-a8d9-d31eee93ad25@github.com> On Wed, 8 Mar 2023 05:17:53 GMT, Vladimir Kozlov wrote: >> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in Interpreter and C1 compiler to produce the same results as C2 intrinsics on x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java methods were implemented originally. >> >> Replaced `SharedRuntime::f2hf()` and `hf2f()` C runtime functions with calls to runtime stubs which use the same HW instructions as C2 intrinsics. Only for 64-bit x64 because 32-bit x86 stub does not work: result is passed through FPU register and NaN values become different from C2 intrinsic. This runtime stub is only used to calculate constant values during C2 compilation and can be skipped. >> >> I added new tests based on Tobias's `TestAll.java` And copied `jdk/lang/Float/Binary16Conversion*.java` tests to run them with `-Xcomp` to make sure code is compiled by C1 or C2. I modified `Binary16ConversionNaN.java` to compare results from Interpreter, C1 and C2. >> >> Tested tier1-5, Xcomp, stress > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Remove RISC-V port code for float16 intrinsics Hi @vnkozlov , Thanks for explanations, looks good to me now. ------------- Marked as reviewed by jbhateja (Reviewer). PR: https://git.openjdk.org/jdk/pull/12869 From asotona at openjdk.org Wed Mar 8 08:50:24 2023 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 8 Mar 2023 08:50:24 GMT Subject: RFR: 8294982: Implementation of Classfile API [v58] In-Reply-To: References: Message-ID: > This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. > > Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. > > Classfile API development is tracked at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch > > Development branch of consolidated JDK class files parsing, generating, and transforming is at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch > > Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. > > Please take you time to review this non-trivial JDK addition. > > Thank you, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: removed obsolete javadoc from implementation classes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10982/files - new: https://git.openjdk.org/jdk/pull/10982/files/cd4a01cd..385cb264 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=57 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=56-57 Stats: 129 lines in 42 files changed: 0 ins; 128 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10982.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982 PR: https://git.openjdk.org/jdk/pull/10982 From asotona at openjdk.org Wed Mar 8 08:50:25 2023 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 8 Mar 2023 08:50:25 GMT Subject: RFR: 8294982: Implementation of Classfile API [v49] In-Reply-To: References: <17U4X6UFV0n08QWRkpROWyGLTXGBlRPQ-x3yrlPEQWY=.5e4dc9a4-49c4-4988-b365-238e3c4687e9@github.com> Message-ID: <5Ppm3aeAxu4zm3BTSRUa3vARbKvuWKMNtA7bfNk68-U=.d1df4188-2c95-417b-b680-01061c5ed0f4@github.com> On Tue, 7 Mar 2023 15:48:58 GMT, Maurizio Cimadamore wrote: >> This is common practise across the whole implementation. Do you suggest to remove all similar javadoc from all implementation classes? > > Well, if the javadoc simply states the name of the class it doesn't seem very useful. But I leave that decision to you. I've removed obsolete javadoc from implementation classes. Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/10982 From david.holmes at oracle.com Wed Mar 8 09:36:02 2023 From: david.holmes at oracle.com (David Holmes) Date: Wed, 8 Mar 2023 19:36:02 +1000 Subject: Testing no memory leak occurs via references In-Reply-To: References: <5e0f77c6-446b-a533-0783-db7f554861c3@oracle.com> <309de0aa-51e9-ca62-da86-9774983b14af@oracle.com> <1dd51557-86c5-200f-a36f-b87d7e237813@oracle.com> Message-ID: <683b9fd7-0295-aa2d-2ec2-d23d558b7f91@oracle.com> On 7/03/2023 8:16 pm, Kim Barrett wrote: >> On Mar 6, 2023, at 10:11 AM, Aleksei Ivanov wrote: >> >> On 06/03/2023 13:51, Albert Yang wrote: >>> Upon a cursory inspection of ForceGC.java, it seems that the fundamental logic involves waiting for a certain duration and relying on chance. However, I am of the opinion that utilizing the WhiteBox API can provide greater determinism and potentially strengthen some of the assertions. >> >> Yes, it calls System.gc in a loop and waits for a reference to become cleared. > > WhiteBox.fullGC is better. But is awkward to use within tests. Makes me wonder whether System.gc() should do whatever WhiteBox.fullGC() actually does? David ----- > System.gc may not do a full GC; consider, for example, G1 with > -XX:+ExplicitGCInvokesConcurrent. > > Because of potential cross-generational j.l.r.Reference and referent, one > invocation might not clear a Reference that would be cleared by a full GC, and > might in fact require many iterations. > > Also, because of SATB requirements, G1 with -XX:+ExplicitGCInvokesConcurrent > might never clear a Reference if it is being checked for being cleared in the > traditional way (by ref.get() == null) rather than by using the newer > ref.refersTo(null). > > WhiteBox.fullGC deals with both of those, and there's no need for looping. > The loops in functions like ForceGC are to deal with those kinds of issues. > And waiting for clearing is completely pointless. A given GC invocation will > either clear or not, and there's not a delay afterward. > > The ZGC equivalent of the second can still be a problem. Checking for a > cleared Reference really should be done using Reference.refersTo. > > From john.hendrikx at gmail.com Wed Mar 8 10:07:58 2023 From: john.hendrikx at gmail.com (John Hendrikx) Date: Wed, 8 Mar 2023 11:07:58 +0100 Subject: Testing no memory leak occurs via references In-Reply-To: <683b9fd7-0295-aa2d-2ec2-d23d558b7f91@oracle.com> References: <5e0f77c6-446b-a533-0783-db7f554861c3@oracle.com> <309de0aa-51e9-ca62-da86-9774983b14af@oracle.com> <1dd51557-86c5-200f-a36f-b87d7e237813@oracle.com> <683b9fd7-0295-aa2d-2ec2-d23d558b7f91@oracle.com> Message-ID: On 08/03/2023 10:36, David Holmes wrote: > On 7/03/2023 8:16 pm, Kim Barrett wrote: >>> On Mar 6, 2023, at 10:11 AM, Aleksei Ivanov >>> wrote: >>> >>> On 06/03/2023 13:51, Albert Yang wrote: >>>> Upon a cursory inspection of ForceGC.java, it seems that the >>>> fundamental logic involves waiting for a certain duration and >>>> relying on chance. However, I am of the opinion that utilizing the >>>> WhiteBox API can provide greater determinism and potentially >>>> strengthen some of the assertions. >>> >>> Yes, it calls System.gc in a loop and waits for a reference to >>> become cleared. >> >> WhiteBox.fullGC is better. > > But is awkward to use within tests. > > Makes me wonder whether System.gc() should do whatever > WhiteBox.fullGC() actually does? Would this be available to test code outside the JDK? Outside the JDK, there also exists a need to ask the system if a reference can be cleared. This is usually part of test code to see if no memory is being leaked unexpectedly. System.gc() is currently our only hope to perform such tests, but it is clear it isn't intended for that purpose. Perhaps there should be a more targetted solution; the intent isn't to run a GC (although that may be necessary depending on the implementation) but to test if a reference can be cleared. Implementations that can't or won't clear references could throw an exception to indicate this kind of test would not work with the current configuration. --John > >> System.gc may not do a full GC; consider, for example, G1 with >> -XX:+ExplicitGCInvokesConcurrent. >> >> Because of potential cross-generational j.l.r.Reference and referent, >> one >> invocation might not clear a Reference that would be cleared by a >> full GC, and >> might in fact require many iterations. >> >> Also, because of SATB requirements, G1 with >> -XX:+ExplicitGCInvokesConcurrent >> might never clear a Reference if it is being checked for being >> cleared in the >> traditional way (by ref.get() == null) rather than by using the newer >> ref.refersTo(null). >> >> WhiteBox.fullGC deals with both of those, and there's no need for >> looping. >> The loops in functions like ForceGC are to deal with those kinds of >> issues. >> And waiting for clearing is completely pointless.? A given GC >> invocation will >> either clear or not, and there's not a delay afterward. >> >> The ZGC equivalent of the second can still be a problem. Checking for a >> cleared Reference really should be done using Reference.refersTo. >> >> From asotona at openjdk.org Wed Mar 8 10:15:43 2023 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 8 Mar 2023 10:15:43 GMT Subject: RFR: 8294961: java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes [v4] In-Reply-To: References: Message-ID: > java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes and this patch converts it to use Classfile API. > > This pull request suppose to chain on the 8294982: Implementation of Classfile API https://github.com/openjdk/jdk/pull/10982 > > Please review. > > Thank you, > Adam Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: - Merge branch 'JDK-8294982' into JDK-8294961 - j.l.r.ProxyGenerator improvements Author: Mandy Chung - Merge branch 'JDK-8294982' into JDK-8294961 - j.l.r.ProxyGenerator fix - Classfile API moved under jdk.internal.classfile package - Merge branch 'JDK-8294982' into JDK-8294961 - Merge branch 'JDK-8294982' into JDK-8294961 - 8294961: java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10991/files - new: https://git.openjdk.org/jdk/pull/10991/files/9d671a04..0330c488 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10991&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10991&range=02-03 Stats: 116652 lines in 3261 files changed: 55855 ins; 28518 del; 32279 mod Patch: https://git.openjdk.org/jdk/pull/10991.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10991/head:pull/10991 PR: https://git.openjdk.org/jdk/pull/10991 From rgiulietti at openjdk.org Wed Mar 8 11:03:16 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 8 Mar 2023 11:03:16 GMT Subject: RFR: JDK-8303794: IEEEremainder problems are causing test failures after JDK-8302801 In-Reply-To: References: Message-ID: <5QsE3RP6pEL5o9mKN5sA9rT6PVXwYiuL09lIIzBSiz4=.734b24d9-bcc5-4be2-b02b-3bffafafc324@github.com> On Wed, 8 Mar 2023 01:30:58 GMT, Joe Darcy wrote: > Quick port of IEEEremainder; sorry for missing this earlier. Will add targeted tests in a follow-up fix. src/java.base/share/classes/java/lang/FdLibm.java line 3437: > 3435: return Zero[sx>>>31]; // unsigned shift > 3436: while(Integer.compareUnsigned(hx, 0x00100000) < 0) { /* normalize x */ > 3437: hx = hx+hx+(lx>>31); lx = lx+lx; Should be `>>>` ------------- PR: https://git.openjdk.org/jdk/pull/12915 From djelinski at openjdk.org Wed Mar 8 11:59:09 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 8 Mar 2023 11:59:09 GMT Subject: RFR: 8303814: getLastErrorString should avoid charset conversions Message-ID: This patch modifies the `getLastErrorString` method to return a `jstring`. Thanks to that we can avoid unnecessary back and forth conversions between Unicode and other charsets on Windows. Other changes include: - the Windows implementation of `getLastErrorString` no longer checks `errno`. I verified all uses of the method and confirmed that `errno` is not used anywhere. - While at it, I found and fixed a few calls to `JNU_ThrowIOExceptionWithLastError` that were done in context where `LastError` was not set. - jdk.hotspot.agent was modified to use `JNU_ThrowByNameWithLastError` and `JNU_ThrowByName` instead of `getLastErrorString`; the code is expected to have identical behavior. - zip_util was modified to return static messages instead of generated ones. The generated messages were not observed anywhere, because they were replaced by a static message in ZIP_Open, which is the only method used by other native code. - `getLastErrorString` is no longer exported by libjava. Tier1-3 tests continue to pass. No new automated regression test; testing this requires installing a language pack that cannot be displayed in the current code page. Tested this manually by installing Chinese language pack on English Windows 11, selecting Chinese language, then checking if the message on exception thrown by `InetAddress.getByName("nonexistent.local");` starts with `"?????????"` (or `"\u4e0d\u77e5\u9053\u8fd9\u6837\u7684\u4e3b\u673a\u3002"`). Without the change, the exception message started with a row of question marks. ------------- Commit messages: - Update copyrights - Remove LastError - Change getLastErrorString to return a jstring Changes: https://git.openjdk.org/jdk/pull/12922/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12922&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303814 Stats: 138 lines in 8 files changed: 19 ins; 44 del; 75 mod Patch: https://git.openjdk.org/jdk/pull/12922.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12922/head:pull/12922 PR: https://git.openjdk.org/jdk/pull/12922 From rgiulietti at openjdk.org Wed Mar 8 12:07:17 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 8 Mar 2023 12:07:17 GMT Subject: RFR: JDK-8303794: IEEEremainder problems are causing test failures after JDK-8302801 In-Reply-To: References: Message-ID: On Wed, 8 Mar 2023 01:30:58 GMT, Joe Darcy wrote: > Quick port of IEEEremainder; sorry for missing this earlier. Will add targeted tests in a follow-up fix. src/java.base/share/classes/java/lang/FdLibm.java line 3367: > 3365: /* purge off exception values */ > 3366: if((hy|ly)==0||(hx>=0x7ff00000)|| /* y=0,or x not finite */ > 3367: ((hy|((ly | -ly) >> 31))>0x7ff00000)) /* or y is NaN */ Should be `>>>` src/java.base/share/classes/java/lang/FdLibm.java line 3436: > 3434: if((hx|lx)==0) /* return sign(x)*0 */ > 3435: return Zero[sx>>>31]; // unsigned shift > 3436: while(Integer.compareUnsigned(hx, 0x00100000) < 0) { /* normalize x */ Should be `hx < 0x00100000` ------------- PR: https://git.openjdk.org/jdk/pull/12915 From mdoerr at openjdk.org Wed Mar 8 13:22:50 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 8 Mar 2023 13:22:50 GMT Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function & Memory API (Preview) [v11] In-Reply-To: References: Message-ID: > Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification". > > This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `` (2.2.4 Variable Argument Lists). > > Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only. > > There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Will get addressed separately: [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017) > > The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests. > > I had to make changes to shared code and code for other platforms: > 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons: > - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that. > - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64. > - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian! > 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit. Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: Remove STRUCT_REFERENCE which was incorrectly taken from aarch64. Pass size to bufferLoad/Store. Enable TestNested.java. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12708/files - new: https://git.openjdk.org/jdk/pull/12708/files/3a541d00..f75a240d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=09-10 Stats: 25 lines in 3 files changed: 0 ins; 21 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/12708.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12708/head:pull/12708 PR: https://git.openjdk.org/jdk/pull/12708 From qamai at openjdk.org Wed Mar 8 13:46:03 2023 From: qamai at openjdk.org (Quan Anh Mai) Date: Wed, 8 Mar 2023 13:46:03 GMT Subject: RFR: 8303762: [vectorapi] Intrinsification of Vector.slice [v2] In-Reply-To: References: Message-ID: > `Vector::slice` is a method at the top-level class of the Vector API that concatenates the 2 inputs into an intermediate composite and extracts a window equal to the size of the inputs into the result. It is used in vector conversion methods where the part number is not 0 to slice the parts to the correct positions. Slicing is also used in text processing such as utf8 and utf16 validation. x86 starting from SSSE3 has `palignr` which does vector slicing very efficiently. As a result, I think it is beneficial to add a C2 node for this operation as well as intrinsify `Vector::slice` method. > > A slice is currently implemented as `v2.rearrange(iota).blend(v1.rearrange(iota), blendMask)` which requires preparation of the index vector and the blending mask. Even with the preparations being hoisted out of the loops, microbenchmarks show improvement using the slice instrinsics. Some have tremendous increases in throughput due to the limitation that a mask of length 2 cannot currently be intrinsified, leading to falling back to the Java implementations. > > Please take a look and have some reviews. Thank you very much. Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: address reviews ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12909/files - new: https://git.openjdk.org/jdk/pull/12909/files/e992d4c6..65409f13 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12909&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12909&range=00-01 Stats: 333 lines in 2 files changed: 61 ins; 182 del; 90 mod Patch: https://git.openjdk.org/jdk/pull/12909.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12909/head:pull/12909 PR: https://git.openjdk.org/jdk/pull/12909 From qamai at openjdk.org Wed Mar 8 13:52:18 2023 From: qamai at openjdk.org (Quan Anh Mai) Date: Wed, 8 Mar 2023 13:52:18 GMT Subject: RFR: 8303762: [vectorapi] Intrinsification of Vector.slice [v2] In-Reply-To: <_PA9oL9dVd3Yrg0sXw3m0uwfGjP6TuqXGBm5M090GHM=.a09a8733-e59e-4b6d-a6a6-e518a8518450@github.com> References: <_PA9oL9dVd3Yrg0sXw3m0uwfGjP6TuqXGBm5M090GHM=.a09a8733-e59e-4b6d-a6a6-e518a8518450@github.com> Message-ID: On Wed, 8 Mar 2023 00:29:05 GMT, Paul Sandoz wrote: >> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: >> >> address reviews > > src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java line 2289: > >> 2287: getClass(), byte.class, length(), >> 2288: this, that, origin, >> 2289: new VectorSliceOp() { > > Change from inner class to lambda expression? We still need this method to be inlined and I don't know if there is a way to annotate the lambda function. > test/hotspot/jtreg/compiler/vectorapi/TestVectorSlice.java line 65: > >> 63: Asserts.assertEquals(expected, dst[i][j]); >> 64: } >> 65: } > > It should be possible to factor out this code into something like this: > > assertOffsets(length, (expected, i, j) -> Assert.assertEquals((byte)expected, dst[i][j]) Fixed. > test/hotspot/jtreg/compiler/vectorapi/TestVectorSlice.java line 68: > >> 66: >> 67: length = 16; >> 68: testB128(dst, src1, src2); > > Should `dst` be zeroed before the next call? or maybe easier to just reallocate. Fixed, I just allocate another array. > test/jdk/jdk/incubator/vector/templates/Kernel-Slice-bop-const.template line 1: > >> 1: $type$[] a = fa.apply(SPECIES.length()); > > Forgot to commit the updated unit tests? This is for the microbenchmarks generated in the panama-vector repo only. Thanks a lot. ------------- PR: https://git.openjdk.org/jdk/pull/12909 From jvernee at openjdk.org Wed Mar 8 14:45:55 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 8 Mar 2023 14:45:55 GMT Subject: RFR: 8303022: "assert(allocates2(pc)) failed: not in CodeBuffer memory" When linking downcall handle Message-ID: The issue is that the size of the code buffer is not large enough to hold the whole stub. Proposed solution is to scale the size of the stub with the number of arguments. I've adjusted sizes for both downcall and upcall stubs. I've also dropped the number of relocations, since we're not really using any for downcalls, and for upcalls we only have 1 AFAICS. (the size of the relocations can not be zero however, as that leads to the relocation section [not being initialized][1], and triggering [an assert][2] later when the code blob is copied). The way I've determined the new base size and per-argument size for stubs, is by first linking a stub without any arguments to get the required base size, and by then adding 20 `double` arguments to get a rough per-argument size. Both values have wiggle room as well. The sizes can be printed using e.g. `-XX:+LogCompilation`, and then looking for `nep_invoker_blob` and `upcall_stub*` in the log file. This experiment was done on a fastdebug build to account for additional debug code being generated. The included test is designed to try and maximize the size of the generated stub. I've also updated `CodeBuffer::log_section_sizes` to print the in-use size, rather than just the capacity and free space. [1]: https://github.com/openjdk/jdk/blob/56512cfe1f0682c98ba3488af3d03ccef632c016/src/hotspot/share/asm/codeBuffer.cpp#L119-L121 [2]: https://github.com/openjdk/jdk/blob/56512cfe1f0682c98ba3488af3d03ccef632c016/src/hotspot/share/asm/codeBuffer.cpp#L675 ------------- Commit messages: - improve test - fix test - adjust x86_64 stub size scaling - adjust upcall stub size based on arguments - adjust downcall stub size for aarch64 - fix comment typo - simplify test - improve log_section_sizes - base code size on argument count Changes: https://git.openjdk.org/jdk/pull/12908/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12908&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303022 Stats: 84 lines in 6 files changed: 73 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/12908.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12908/head:pull/12908 PR: https://git.openjdk.org/jdk/pull/12908 From jvernee at openjdk.org Wed Mar 8 14:52:01 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 8 Mar 2023 14:52:01 GMT Subject: RFR: 8303022: "assert(allocates2(pc)) failed: not in CodeBuffer memory" When linking downcall handle [v2] In-Reply-To: References: Message-ID: > The issue is that the size of the code buffer is not large enough to hold the whole stub. > > Proposed solution is to scale the size of the stub with the number of arguments. I've adjusted sizes for both downcall and upcall stubs. I've also dropped the number of relocations, since we're not really using any for downcalls, and for upcalls we only have 1 AFAICS. (the size of the relocations can not be zero however, as that leads to the relocation section [not being initialized][1], and triggering [an assert][2] later when the code blob is copied). > > The way I've determined the new base size and per-argument size for stubs, is by first linking a stub without any arguments to get the required base size, and by then adding 20 `double` arguments to get a rough per-argument size. Both values have wiggle room as well. The sizes can be printed using e.g. `-XX:+LogCompilation`, and then looking for `nep_invoker_blob` and `upcall_stub*` in the log file. This experiment was done on a fastdebug build to account for additional debug code being generated. The included test is designed to try and maximize the size of the generated stub. > > I've also updated `CodeBuffer::log_section_sizes` to print the in-use size, rather than just the capacity and free space. > > [1]: https://github.com/openjdk/jdk/blob/56512cfe1f0682c98ba3488af3d03ccef632c016/src/hotspot/share/asm/codeBuffer.cpp#L119-L121 > [2]: https://github.com/openjdk/jdk/blob/56512cfe1f0682c98ba3488af3d03ccef632c016/src/hotspot/share/asm/codeBuffer.cpp#L675 Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: update copyright years ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12908/files - new: https://git.openjdk.org/jdk/pull/12908/files/6428c8b7..0a2bc96c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12908&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12908&range=00-01 Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/12908.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12908/head:pull/12908 PR: https://git.openjdk.org/jdk/pull/12908 From psandoz at openjdk.org Wed Mar 8 16:22:13 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Wed, 8 Mar 2023 16:22:13 GMT Subject: RFR: 8303762: [vectorapi] Intrinsification of Vector.slice [v2] In-Reply-To: References: <_PA9oL9dVd3Yrg0sXw3m0uwfGjP6TuqXGBm5M090GHM=.a09a8733-e59e-4b6d-a6a6-e518a8518450@github.com> Message-ID: On Wed, 8 Mar 2023 13:48:16 GMT, Quan Anh Mai wrote: >> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java line 2289: >> >>> 2287: getClass(), byte.class, length(), >>> 2288: this, that, origin, >>> 2289: new VectorSliceOp() { >> >> Change from inner class to lambda expression? > > We still need this method to be inlined and I don't know if there is a way to annotate the lambda function. Yes, i wondered about the inline and how important it might be. You want the fallback to inline so as not to perturb platforms without the intrinsic. Can you add a comment on the anon class? ------------- PR: https://git.openjdk.org/jdk/pull/12909 From psandoz at openjdk.org Wed Mar 8 16:26:05 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Wed, 8 Mar 2023 16:26:05 GMT Subject: RFR: 8303762: [vectorapi] Intrinsification of Vector.slice [v2] In-Reply-To: References: Message-ID: On Wed, 8 Mar 2023 13:46:03 GMT, Quan Anh Mai wrote: >> `Vector::slice` is a method at the top-level class of the Vector API that concatenates the 2 inputs into an intermediate composite and extracts a window equal to the size of the inputs into the result. It is used in vector conversion methods where the part number is not 0 to slice the parts to the correct positions. Slicing is also used in text processing such as utf8 and utf16 validation. x86 starting from SSSE3 has `palignr` which does vector slicing very efficiently. As a result, I think it is beneficial to add a C2 node for this operation as well as intrinsify `Vector::slice` method. >> >> A slice is currently implemented as `v2.rearrange(iota).blend(v1.rearrange(iota), blendMask)` which requires preparation of the index vector and the blending mask. Even with the preparations being hoisted out of the loops, microbenchmarks show improvement using the slice instrinsics. Some have tremendous increases in throughput due to the limitation that a mask of length 2 cannot currently be intrinsified, leading to falling back to the Java implementations. >> >> Please take a look and have some reviews. Thank you very much. > > Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: > > address reviews Java changes look good. The HotSpot code looks well structured but i will let others comment on the specifics. ------------- Marked as reviewed by psandoz (Reviewer). PR: https://git.openjdk.org/jdk/pull/12909 From jvernee at openjdk.org Wed Mar 8 16:58:20 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 8 Mar 2023 16:58:20 GMT Subject: RFR: 8303684: Lift upcall sharing mechanism to AbstractLinker (mainline) Message-ID: Port of: https://github.com/openjdk/panama-foreign/pull/791 which lifts the sharing mechanism for upcall stubs to AbstractLinker. This also speeds up upcall stub linking: ------------- Commit messages: - update benchmark - update copyright years - 8302346: Lift upcall sharing mechanism to AbstractLinker Changes: https://git.openjdk.org/jdk/pull/12883/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12883&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303684 Stats: 155 lines in 16 files changed: 54 ins; 34 del; 67 mod Patch: https://git.openjdk.org/jdk/pull/12883.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12883/head:pull/12883 PR: https://git.openjdk.org/jdk/pull/12883 From qamai at openjdk.org Wed Mar 8 17:24:50 2023 From: qamai at openjdk.org (Quan Anh Mai) Date: Wed, 8 Mar 2023 17:24:50 GMT Subject: RFR: 8303762: [vectorapi] Intrinsification of Vector.slice [v3] In-Reply-To: References: Message-ID: > `Vector::slice` is a method at the top-level class of the Vector API that concatenates the 2 inputs into an intermediate composite and extracts a window equal to the size of the inputs into the result. It is used in vector conversion methods where the part number is not 0 to slice the parts to the correct positions. Slicing is also used in text processing such as utf8 and utf16 validation. x86 starting from SSSE3 has `palignr` which does vector slicing very efficiently. As a result, I think it is beneficial to add a C2 node for this operation as well as intrinsify `Vector::slice` method. > > A slice is currently implemented as `v2.rearrange(iota).blend(v1.rearrange(iota), blendMask)` which requires preparation of the index vector and the blending mask. Even with the preparations being hoisted out of the loops, microbenchmarks show improvement using the slice instrinsics. Some have tremendous increases in throughput due to the limitation that a mask of length 2 cannot currently be intrinsified, leading to falling back to the Java implementations. > > Please take a look and have some reviews. Thank you very much. Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: add comments explaining anonymous classes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12909/files - new: https://git.openjdk.org/jdk/pull/12909/files/65409f13..c31fdfe8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12909&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12909&range=01-02 Stats: 21 lines in 7 files changed: 21 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12909.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12909/head:pull/12909 PR: https://git.openjdk.org/jdk/pull/12909 From qamai at openjdk.org Wed Mar 8 17:24:55 2023 From: qamai at openjdk.org (Quan Anh Mai) Date: Wed, 8 Mar 2023 17:24:55 GMT Subject: RFR: 8303762: [vectorapi] Intrinsification of Vector.slice [v2] In-Reply-To: References: Message-ID: On Wed, 8 Mar 2023 16:23:16 GMT, Paul Sandoz wrote: >> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: >> >> address reviews > > Java changes look good. The HotSpot code looks well structured but i will let others comment on the specifics. @PaulSandoz Thanks for your review, I have added a comment explaining the rationales behind the anonymous class usage. ------------- PR: https://git.openjdk.org/jdk/pull/12909 From kvn at openjdk.org Wed Mar 8 18:43:30 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 8 Mar 2023 18:43:30 GMT Subject: RFR: 8303022: "assert(allocates2(pc)) failed: not in CodeBuffer memory" When linking downcall handle [v2] In-Reply-To: References: Message-ID: On Wed, 8 Mar 2023 14:52:01 GMT, Jorn Vernee wrote: >> The issue is that the size of the code buffer is not large enough to hold the whole stub. >> >> Proposed solution is to scale the size of the stub with the number of arguments. I've adjusted sizes for both downcall and upcall stubs. I've also dropped the number of relocations, since we're not really using any for downcalls, and for upcalls we only have 1 AFAICS. (the size of the relocations can not be zero however, as that leads to the relocation section [not being initialized][1], and triggering [an assert][2] later when the code blob is copied). >> >> The way I've determined the new base size and per-argument size for stubs, is by first linking a stub without any arguments to get the required base size, and by then adding 20 `double` arguments to get a rough per-argument size. Both values have wiggle room as well. The sizes can be printed using e.g. `-XX:+LogCompilation`, and then looking for `nep_invoker_blob` and `upcall_stub*` in the log file. This experiment was done on a fastdebug build to account for additional debug code being generated. The included test is designed to try and maximize the size of the generated stub. >> >> I've also updated `CodeBuffer::log_section_sizes` to print the in-use size, rather than just the capacity and free space. >> >> [1]: https://github.com/openjdk/jdk/blob/56512cfe1f0682c98ba3488af3d03ccef632c016/src/hotspot/share/asm/codeBuffer.cpp#L119-L121 >> [2]: https://github.com/openjdk/jdk/blob/56512cfe1f0682c98ba3488af3d03ccef632c016/src/hotspot/share/asm/codeBuffer.cpp#L675 > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > update copyright years I think you need to add these changes to other ports too and ask for testing on them. ------------- PR: https://git.openjdk.org/jdk/pull/12908 From rriggs at openjdk.org Wed Mar 8 19:24:34 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 8 Mar 2023 19:24:34 GMT Subject: RFR: 8303485: Replacing os.name for operating system customization Message-ID: Improvements to support OS specific customization for JDK internal use: - To select values and code; allowing elimination of unused code and values - Optionally evaluated by build processes, compilation, or archiving (i.e. CDS) - Simple API to replace adhoc comparisons with `os.name` - Clear and consistent use across build, runtime, and JDK modules The PR includes updates within java.base to use the new API. ------------- Commit messages: - 8303485: Replacing os.name for operating system customization Changes: https://git.openjdk.org/jdk/pull/12931/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12931&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303485 Stats: 435 lines in 13 files changed: 322 ins; 39 del; 74 mod Patch: https://git.openjdk.org/jdk/pull/12931.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12931/head:pull/12931 PR: https://git.openjdk.org/jdk/pull/12931 From mcimadamore at openjdk.org Wed Mar 8 19:25:04 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 8 Mar 2023 19:25:04 GMT Subject: RFR: 8303684: Lift upcall sharing mechanism to AbstractLinker (mainline) In-Reply-To: References: Message-ID: On Mon, 6 Mar 2023 18:40:47 GMT, Jorn Vernee wrote: > Port of: https://github.com/openjdk/panama-foreign/pull/791 which lifts the sharing mechanism for upcall stubs to AbstractLinker. > > This also speeds up upcall stub linking: Looks good (already reviewed on Panama repo) ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.org/jdk/pull/12883 From vlivanov at openjdk.org Wed Mar 8 19:46:14 2023 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Wed, 8 Mar 2023 19:46:14 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter [v4] In-Reply-To: References: Message-ID: <1WK1RTMCYwOXw7LvaJr04fL68nN64TpB05fcPC2a3uo=.d71b77a8-c814-4166-8f56-af97ac70dc55@github.com> On Wed, 8 Mar 2023 05:17:53 GMT, Vladimir Kozlov wrote: >> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in Interpreter and C1 compiler to produce the same results as C2 intrinsics on x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java methods were implemented originally. >> >> Replaced `SharedRuntime::f2hf()` and `hf2f()` C runtime functions with calls to runtime stubs which use the same HW instructions as C2 intrinsics. Only for 64-bit x64 because 32-bit x86 stub does not work: result is passed through FPU register and NaN values become different from C2 intrinsic. This runtime stub is only used to calculate constant values during C2 compilation and can be skipped. >> >> I added new tests based on Tobias's `TestAll.java` And copied `jdk/lang/Float/Binary16Conversion*.java` tests to run them with `-Xcomp` to make sure code is compiled by C1 or C2. I modified `Binary16ConversionNaN.java` to compare results from Interpreter, C1 and C2. >> >> Tested tier1-5, Xcomp, stress > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Remove RISC-V port code for float16 intrinsics Overall, looks good. Minor comments/suggestions follow. src/hotspot/share/opto/convertnode.cpp line 171: > 169: if (t == Type::TOP) return Type::TOP; > 170: if (t == Type::FLOAT) return TypeInt::SHORT; > 171: if (StubRoutines::f2hf() == nullptr) return bottom_type(); What's the purpose of this check? My understanding is ConvF2HF/ConvHF2F require intrinsification and on platforms where stubs are absent, intrinsification is disabled. src/hotspot/share/opto/convertnode.cpp line 244: > 242: > 243: const TypeInt *ti = t->is_int(); > 244: if (ti->is_con()) { I find it confusing that `ConvHF2FNode::Value()` has `is_con()` check, but `ConvF2HFNode::Value()`doesn't. I'd prefer to see both implementations unified. src/hotspot/share/runtime/sharedRuntime.cpp line 451: > 449: assert(StubRoutines::f2hf() != nullptr, "floatToFloat16 intrinsic is not supported on this platform"); > 450: typedef jshort (*f2hf_stub_t)(jfloat x); > 451: return ((f2hf_stub_t)StubRoutines::f2hf())(x); What's the point of keeping the wrappers around? The stubs can be called directly, can't they? ------------- PR: https://git.openjdk.org/jdk/pull/12869 From dnsimon at openjdk.org Wed Mar 8 19:59:02 2023 From: dnsimon at openjdk.org (Doug Simon) Date: Wed, 8 Mar 2023 19:59:02 GMT Subject: RFR: 8303431: [JVMCI] libgraal annotation API [v4] In-Reply-To: References: Message-ID: > This PR extends JVMCI with new API (`jdk.vm.ci.meta.Annotated`) for accessing annotations. The main differences from `java.lang.reflect.AnnotatedElement` are: > * Each `Annotated` method explicitly specifies the annotation type(s) for which it wants annotation data. That is, there is no direct equivalent of `AnnotatedElement.getAnnotations()`. > * Annotation data is returned in a map-like object (of type `jdk.vm.ci.meta.AnnotationData`) instead of in an `Annotation` object. This works better for libgraal as it avoids the need for annotation types to be loaded and included in libgraal. > > To demonstrate the new API, here's an example in terms `java.lang.reflect.AnnotatedElement` (which `ResolvedJavaType` implements): > > ResolvedJavaMethod method = ...; > ExplodeLoop a = method.getAnnotation(ExplodeLoop.class); > return switch (a.kind()) { > case FULL_UNROLL -> LoopExplosionKind.FULL_UNROLL; > case FULL_UNROLL_UNTIL_RETURN -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN; > ... > } > > > The same code using the new API: > > > ResolvedJavaMethod method = ...; > ResolvedJavaType explodeLoopType = ...; > AnnotationData a = method.getAnnotationDataFor(explodeLoopType); > return switch (a.getEnum("kind").getName()) { > case "FULL_UNROLL" -> LoopExplosionKind.FULL_UNROLL; > case "FULL_UNROLL_UNTIL_RETURN" -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN; > ... > } > > > The implementation relies on new methods in `jdk.internal.vm.VMSupport` for parsing annotations and serializing/deserializing to/from a byte array. This allows the annotation data to be passed from the HotSpot heap to the libgraal heap. Doug Simon has updated the pull request incrementally with one additional commit since the last revision: switched to use of lists and maps instead of arrays ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12810/files - new: https://git.openjdk.org/jdk/pull/12810/files/3dd5ef9c..948d3aa3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12810&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12810&range=02-03 Stats: 1241 lines in 15 files changed: 292 ins; 718 del; 231 mod Patch: https://git.openjdk.org/jdk/pull/12810.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12810/head:pull/12810 PR: https://git.openjdk.org/jdk/pull/12810 From naoto at openjdk.org Wed Mar 8 20:05:16 2023 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 8 Mar 2023 20:05:16 GMT Subject: RFR: 8303814: getLastErrorString should avoid charset conversions In-Reply-To: References: Message-ID: On Wed, 8 Mar 2023 11:30:27 GMT, Daniel Jeli?ski wrote: > This patch modifies the `getLastErrorString` method to return a `jstring`. Thanks to that we can avoid unnecessary back and forth conversions between Unicode and other charsets on Windows. > > Other changes include: > - the Windows implementation of `getLastErrorString` no longer checks `errno`. I verified all uses of the method and confirmed that `errno` is not used anywhere. > - While at it, I found and fixed a few calls to `JNU_ThrowIOExceptionWithLastError` that were done in context where `LastError` was not set. > - jdk.hotspot.agent was modified to use `JNU_ThrowByNameWithLastError` and `JNU_ThrowByName` instead of `getLastErrorString`; the code is expected to have identical behavior. > - zip_util was modified to return static messages instead of generated ones. The generated messages were not observed anywhere, because they were replaced by a static message in ZIP_Open, which is the only method used by other native code. > - `getLastErrorString` is no longer exported by libjava. > > Tier1-3 tests continue to pass. > > No new automated regression test; testing this requires installing a language pack that cannot be displayed in the current code page. > Tested this manually by installing Chinese language pack on English Windows 11, selecting Chinese language, then checking if the message on exception thrown by `InetAddress.getByName("nonexistent.local");` starts with `"?????????"` (or `"\u4e0d\u77e5\u9053\u8fd9\u6837\u7684\u4e3b\u673a\u3002"`). Without the change, the exception message started with a row of question marks. Hi Daniel, I like the idea of using `jstring` directly to avoid platform string. My concern is that is it OK to make it not export from libjava? Would it cause any concern on other platforms? Also, now it is not consistent with the other sibling `getErrorString()` call. ------------- PR: https://git.openjdk.org/jdk/pull/12922 From duke at openjdk.org Wed Mar 8 20:16:00 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Wed, 8 Mar 2023 20:16:00 GMT Subject: RFR: 8303833: java.util.LocaleISOData has wrong comments for 'Norwegian =?UTF-8?B?Qm9rbcOlbCc=?= and =?UTF-8?B?J1ZvbGFww7xrJw==?= Message-ID: The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. ---------------------------------------------------------------------- Please review this comment-only PR which fixes incorrect language names 'Norwegian Bokm?l' and 'Volap?k' in the comments in LocaleISOData: `+ "nb" + "nob" // Norwegian Bokm?l` `+ "vo" + "vol" // Volap?k` These encoding issues seem to have been around since Duke imported the file in 2007. Let's fix them now. For context: 'Norwegian bokm?l' is the most common written form of the Norwegian language: https://en.wikipedia.org/wiki/Bokm%C3%A5l 'Volap?k' is a constructed language: https://en.wikipedia.org/wiki/Volap%C3%BCk ------------- Commit messages: - Fix comment for "Norwegian Bokm?l" and "Volap?k" Changes: https://git.openjdk.org/jdk/pull/12932/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12932&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303833 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/12932.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12932/head:pull/12932 PR: https://git.openjdk.org/jdk/pull/12932 From naoto at openjdk.org Wed Mar 8 20:42:02 2023 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 8 Mar 2023 20:42:02 GMT Subject: RFR: 8303833: java.util.LocaleISOData has wrong comments for 'Norwegian =?UTF-8?B?Qm9rbcOlbCc=?= and =?UTF-8?B?J1ZvbGFww7xrJw==?= In-Reply-To: References: Message-ID: On Wed, 8 Mar 2023 19:57:43 GMT, Eirik Bjorsnos wrote: > Please review this comment-only PR which fixes incorrect language names 'Norwegian Bokm?l' and 'Volap?k' in the comments in LocaleISOData: > > `+ "nb" + "nob" // Norwegian Bokm?l` > `+ "vo" + "vol" // Volap?k` > > These encoding issues seem to have been around since Duke imported the file in 2007. Let's fix them now. > > For context: 'Norwegian bokm?l' is the most common written form of the Norwegian language: > > https://en.wikipedia.org/wiki/Bokm%C3%A5l > > 'Volap?k' is a constructed language: > > https://en.wikipedia.org/wiki/Volap%C3%BCk Looks good. The copyright year remains the same but it will be corrected with the other LocaleISOData fix, so it is OK. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.org/jdk/pull/12932 From jvernee at openjdk.org Wed Mar 8 20:57:16 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 8 Mar 2023 20:57:16 GMT Subject: RFR: 8303022: "assert(allocates2(pc)) failed: not in CodeBuffer memory" When linking downcall handle [v2] In-Reply-To: References: Message-ID: On Wed, 8 Mar 2023 18:40:05 GMT, Vladimir Kozlov wrote: >> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: >> >> update copyright years > > I think you need to add these changes to other ports too and ask for testing on them. @vnkozlov Yes, this is true. The only other existing port of this code is RISCV. However, to fix that port properly, someone needs to repeat the experiment on RISCV in order to figure out what the base size and the size per argument should be. I don't have access to a RISCV machine, so I figured I would file a followup issue for the RISCV maintainers to fix separately. @feilongjiang Could you comment on this? If you could figure out the needed sizes for RISCV I could add the needed changes to this patch. Otherwise I could file a followup issue if that seems more convenient. ------------- PR: https://git.openjdk.org/jdk/pull/12908 From kvn at openjdk.org Wed Mar 8 21:14:19 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 8 Mar 2023 21:14:19 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter [v4] In-Reply-To: References: Message-ID: <5OfHFOlt05wJhzyU1Rpce3xx3B4BnO-dEF6X0I1JgD8=.1135fdd9-ae96-45d9-a26c-ad22f721bad7@github.com> On Wed, 8 Mar 2023 05:17:53 GMT, Vladimir Kozlov wrote: >> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in Interpreter and C1 compiler to produce the same results as C2 intrinsics on x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java methods were implemented originally. >> >> Replaced `SharedRuntime::f2hf()` and `hf2f()` C runtime functions with calls to runtime stubs which use the same HW instructions as C2 intrinsics. Only for 64-bit x64 because 32-bit x86 stub does not work: result is passed through FPU register and NaN values become different from C2 intrinsic. This runtime stub is only used to calculate constant values during C2 compilation and can be skipped. >> >> I added new tests based on Tobias's `TestAll.java` And copied `jdk/lang/Float/Binary16Conversion*.java` tests to run them with `-Xcomp` to make sure code is compiled by C1 or C2. I modified `Binary16ConversionNaN.java` to compare results from Interpreter, C1 and C2. >> >> Tested tier1-5, Xcomp, stress > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Remove RISC-V port code for float16 intrinsics Thank you for review @iwanowww ------------- PR: https://git.openjdk.org/jdk/pull/12869 From kvn at openjdk.org Wed Mar 8 21:14:23 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 8 Mar 2023 21:14:23 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter [v4] In-Reply-To: <1WK1RTMCYwOXw7LvaJr04fL68nN64TpB05fcPC2a3uo=.d71b77a8-c814-4166-8f56-af97ac70dc55@github.com> References: <1WK1RTMCYwOXw7LvaJr04fL68nN64TpB05fcPC2a3uo=.d71b77a8-c814-4166-8f56-af97ac70dc55@github.com> Message-ID: On Wed, 8 Mar 2023 19:38:56 GMT, Vladimir Ivanov wrote: >> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove RISC-V port code for float16 intrinsics > > src/hotspot/share/opto/convertnode.cpp line 171: > >> 169: if (t == Type::TOP) return Type::TOP; >> 170: if (t == Type::FLOAT) return TypeInt::SHORT; >> 171: if (StubRoutines::f2hf() == nullptr) return bottom_type(); > > What's the purpose of this check? My understanding is ConvF2HF/ConvHF2F require intrinsification and on platforms where stubs are absent, intrinsification is disabled. This code is optimization: use stub to calculate constant value during compilation instead of generating HW instruction in compiled code. It is not required to have this stub for intensification to work - `ConvF2HFNode` will be processed normally and will use intrinsics code (HW instruction) defined in .ad file. These stubs are used only here, not in C1 and not in Interpreter. As consequence these stubs implementation is optional and I implemented them only on x64. That is why I have this check. I debated to not have them at all to not confuse people but they did improve performance a little. > src/hotspot/share/opto/convertnode.cpp line 244: > >> 242: >> 243: const TypeInt *ti = t->is_int(); >> 244: if (ti->is_con()) { > > I find it confusing that `ConvHF2FNode::Value()` has `is_con()` check, but `ConvF2HFNode::Value()`doesn't. I'd prefer to see both implementations unified. It follows the same pattern as other nodes here: `ConvF2INode::Value()` vs `ConvI2FNode::Value()`. If you want to change it we need to do that in separate RFE for all methods here. But I don't think we need to do that because Float/Double does not have range values as Integer types. Float have only 3 types of value: FloatTop, FloatBot, FloatCon. So we don't need to check for constant if checked for TOP and BOT. For Integer we need to check `bool is_con() const { return _lo==_hi; }`. ------------- PR: https://git.openjdk.org/jdk/pull/12869 From duke at openjdk.org Wed Mar 8 21:16:06 2023 From: duke at openjdk.org (Steven R. Loomis) Date: Wed, 8 Mar 2023 21:16:06 GMT Subject: RFR: 8303833: java.util.LocaleISOData has wrong comments for 'Norwegian =?UTF-8?B?Qm9rbcOlbCc=?= and =?UTF-8?B?J1ZvbGFww7xrJw==?= In-Reply-To: References: Message-ID: On Wed, 8 Mar 2023 19:57:43 GMT, Eirik Bjorsnos wrote: > Please review this comment-only PR which fixes incorrect language names 'Norwegian Bokm?l' and 'Volap?k' in the comments in LocaleISOData: > > `+ "nb" + "nob" // Norwegian Bokm?l` > `+ "vo" + "vol" // Volap?k` > > These encoding issues seem to have been around since Duke imported the file in 2007. Let's fix them now. > > For context: 'Norwegian bokm?l' is the most common written form of the Norwegian language: > > https://en.wikipedia.org/wiki/Bokm%C3%A5l > > 'Volap?k' is a constructed language: > > https://en.wikipedia.org/wiki/Volap%C3%BCk Marked as reviewed by srl295 at github.com (no known OpenJDK username). ------------- PR: https://git.openjdk.org/jdk/pull/12932 From duke at openjdk.org Wed Mar 8 21:20:13 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Wed, 8 Mar 2023 21:20:13 GMT Subject: RFR: 8303833: java.util.LocaleISOData has wrong comments for 'Norwegian =?UTF-8?B?Qm9rbcOlbCc=?= and =?UTF-8?B?J1ZvbGFww7xrJw==?= In-Reply-To: References: Message-ID: On Wed, 8 Mar 2023 19:57:43 GMT, Eirik Bjorsnos wrote: > Please review this comment-only PR which fixes incorrect language names 'Norwegian Bokm?l' and 'Volap?k' in the comments in LocaleISOData: > > `+ "nb" + "nob" // Norwegian Bokm?l` > `+ "vo" + "vol" // Volap?k` > > These encoding issues seem to have been around since Duke imported the file in 2007. Let's fix them now. > > For context: 'Norwegian bokm?l' is the most common written form of the Norwegian language: > > https://en.wikipedia.org/wiki/Bokm%C3%A5l > > 'Volap?k' is a constructed language: > > https://en.wikipedia.org/wiki/Volap%C3%BCk Thanks Naoto and Steven! I could claim that the change was too trivial for a copyright update, but I'd rather be honest and say I just forgot. Also, I'm not a lawyer :-) ------------- PR: https://git.openjdk.org/jdk/pull/12932 From kvn at openjdk.org Wed Mar 8 21:22:25 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 8 Mar 2023 21:22:25 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter [v4] In-Reply-To: <1WK1RTMCYwOXw7LvaJr04fL68nN64TpB05fcPC2a3uo=.d71b77a8-c814-4166-8f56-af97ac70dc55@github.com> References: <1WK1RTMCYwOXw7LvaJr04fL68nN64TpB05fcPC2a3uo=.d71b77a8-c814-4166-8f56-af97ac70dc55@github.com> Message-ID: <53sy823UIcXi4OTG8SgGnjrUmkOymF2L62BHoFkTgPk=.5de6fcd3-ea94-4f6a-8c1b-2ccf243374fd@github.com> On Wed, 8 Mar 2023 19:04:01 GMT, Vladimir Ivanov wrote: >> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove RISC-V port code for float16 intrinsics > > src/hotspot/share/runtime/sharedRuntime.cpp line 451: > >> 449: assert(StubRoutines::f2hf() != nullptr, "floatToFloat16 intrinsic is not supported on this platform"); >> 450: typedef jshort (*f2hf_stub_t)(jfloat x); >> 451: return ((f2hf_stub_t)StubRoutines::f2hf())(x); > > What's the point of keeping the wrappers around? The stubs can be called directly, can't they? I wanted isolate function type cast and assert in one place. BTW the comment in assert should be "the stub is not implemented on this platform". ------------- PR: https://git.openjdk.org/jdk/pull/12869 From duke at openjdk.org Wed Mar 8 21:28:29 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Wed, 8 Mar 2023 21:28:29 GMT Subject: Integrated: 8303833: java.util.LocaleISOData has wrong comments for 'Norwegian =?UTF-8?B?Qm9rbcOlbCc=?= and =?UTF-8?B?J1ZvbGFww7xrJw==?= In-Reply-To: References: Message-ID: The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. ---------------------------------------------------------------------- On Wed, 8 Mar 2023 19:57:43 GMT, Eirik Bjorsnos wrote: > Please review this comment-only PR which fixes incorrect language names 'Norwegian Bokm?l' and 'Volap?k' in the comments in LocaleISOData: > > `+ "nb" + "nob" // Norwegian Bokm?l` > `+ "vo" + "vol" // Volap?k` > > These encoding issues seem to have been around since Duke imported the file in 2007. Let's fix them now. > > For context: 'Norwegian bokm?l' is the most common written form of the Norwegian language: > > https://en.wikipedia.org/wiki/Bokm%C3%A5l > > 'Volap?k' is a constructed language: > > https://en.wikipedia.org/wiki/Volap%C3%BCk This pull request has now been integrated. Changeset: 05ceb37a Author: Eirik Bjorsnos Committer: Naoto Sato URL: https://git.openjdk.org/jdk/commit/05ceb37a2c036580d445c5a7759db74633c090fe Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8303833: java.util.LocaleISOData has wrong comments for 'Norwegian Bokm?l' and 'Volap?k' Reviewed-by: naoto ------------- PR: https://git.openjdk.org/jdk/pull/12932 From vlivanov at openjdk.org Wed Mar 8 21:44:18 2023 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Wed, 8 Mar 2023 21:44:18 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter [v4] In-Reply-To: References: <1WK1RTMCYwOXw7LvaJr04fL68nN64TpB05fcPC2a3uo=.d71b77a8-c814-4166-8f56-af97ac70dc55@github.com> Message-ID: On Wed, 8 Mar 2023 20:55:29 GMT, Vladimir Kozlov wrote: >> src/hotspot/share/opto/convertnode.cpp line 171: >> >>> 169: if (t == Type::TOP) return Type::TOP; >>> 170: if (t == Type::FLOAT) return TypeInt::SHORT; >>> 171: if (StubRoutines::f2hf() == nullptr) return bottom_type(); >> >> What's the purpose of this check? My understanding is ConvF2HF/ConvHF2F require intrinsification and on platforms where stubs are absent, intrinsification is disabled. > > This code is optimization: use stub to calculate constant value during compilation instead of generating HW instruction in compiled code. It is not required to have this stub for intensification to work - `ConvF2HFNode` will be processed normally and will use intrinsics code (HW instruction) defined in .ad file. > These stubs are used only here, not in C1 and not in Interpreter. As consequence these stubs implementation is optional and I implemented them only on x64. That is why I have this check. > I debated to not have them at all to not confuse people but they did improve performance a little. Thanks for the clarifications. Now it makes much more sense. Still, the mix of `StubRoutines::f2hf()` and `SharedRuntime::f2hf()` looks a bit confusing. What if you move the wrapper to `StubRoutines` class instead? (`JRT_LEAF` et al stuff looks redundant here. Also, even though there are other arithmetic operations declared on `StubRoutines`, they provide default implementations universally available across all platforms. `f2hf` case is different since it exposes a platform-specific stub and its availability is limited.) Or encapsulate the constant folding logic (along with the guard) into `SharedRuntime` and return `Type*` (instead of int/float scalar). ------------- PR: https://git.openjdk.org/jdk/pull/12869 From vlivanov at openjdk.org Wed Mar 8 21:50:17 2023 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Wed, 8 Mar 2023 21:50:17 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter [v4] In-Reply-To: References: <1WK1RTMCYwOXw7LvaJr04fL68nN64TpB05fcPC2a3uo=.d71b77a8-c814-4166-8f56-af97ac70dc55@github.com> Message-ID: <-P79Z2uDRHMZk2XTPNY9MidCv-H4t9Cj2Rot1aEj0Cg=.cc46bdde-0e11-4252-b2d7-96ee906c7f04@github.com> On Wed, 8 Mar 2023 21:41:31 GMT, Vladimir Ivanov wrote: > Or encapsulate the constant folding logic (along with the guard) into SharedRuntime and return Type* (instead of int/float scalar). I take this particular suggestion back. `SharedRuntime` is compiler-agnostic while `Type` is C2-specific. ------------- PR: https://git.openjdk.org/jdk/pull/12869 From djelinski at openjdk.org Wed Mar 8 22:03:14 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 8 Mar 2023 22:03:14 GMT Subject: RFR: 8303814: getLastErrorString should avoid charset conversions In-Reply-To: References: Message-ID: On Wed, 8 Mar 2023 11:30:27 GMT, Daniel Jeli?ski wrote: > This patch modifies the `getLastErrorString` method to return a `jstring`. Thanks to that we can avoid unnecessary back and forth conversions between Unicode and other charsets on Windows. > > Other changes include: > - the Windows implementation of `getLastErrorString` no longer checks `errno`. I verified all uses of the method and confirmed that `errno` is not used anywhere. > - While at it, I found and fixed a few calls to `JNU_ThrowIOExceptionWithLastError` that were done in context where `LastError` was not set. > - jdk.hotspot.agent was modified to use `JNU_ThrowByNameWithLastError` and `JNU_ThrowByName` instead of `getLastErrorString`; the code is expected to have identical behavior. > - zip_util was modified to return static messages instead of generated ones. The generated messages were not observed anywhere, because they were replaced by a static message in ZIP_Open, which is the only method used by other native code. > - `getLastErrorString` is no longer exported by libjava. > > Tier1-3 tests continue to pass. > > No new automated regression test; testing this requires installing a language pack that cannot be displayed in the current code page. > Tested this manually by installing Chinese language pack on English Windows 11, selecting Chinese language, then checking if the message on exception thrown by `InetAddress.getByName("nonexistent.local");` starts with `"?????????"` (or `"\u4e0d\u77e5\u9053\u8fd9\u6837\u7684\u4e3b\u673a\u3002"`). Without the change, the exception message started with a row of question marks. I think it's fine to remove `getLastErrorString` from the list of libjava exports. After my changes it's no longer used outside libjava, and it was never a part of the JDK's public interface. Regarding consistency with `getErrorString`, I'm not too concerned about that; the functions have similar names but serve different purposes. ------------- PR: https://git.openjdk.org/jdk/pull/12922 From jlu at openjdk.org Wed Mar 8 22:10:05 2023 From: jlu at openjdk.org (Justin Lu) Date: Wed, 8 Mar 2023 22:10:05 GMT Subject: RFR: 8299088: ClassLoader.c contains 2 JNI exception pending defect groups Message-ID: This PR removes the JNI Exception pending defect groups in ClassLoader.c. `getUTF()` throws an exception and subsequently returns `null`; the exception should either be cleared, or control returned to the JVM. `JNU_ThrowOutOfMemoryError(env, NULL);` should not be called again ------------- Commit messages: - Adress JNI Exception Pending errors Changes: https://git.openjdk.org/jdk/pull/12934/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12934&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299088 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12934.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12934/head:pull/12934 PR: https://git.openjdk.org/jdk/pull/12934 From dlong at openjdk.org Wed Mar 8 22:30:19 2023 From: dlong at openjdk.org (Dean Long) Date: Wed, 8 Mar 2023 22:30:19 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter [v4] In-Reply-To: References: Message-ID: On Wed, 8 Mar 2023 05:17:53 GMT, Vladimir Kozlov wrote: >> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in Interpreter and C1 compiler to produce the same results as C2 intrinsics on x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java methods were implemented originally. >> >> Replaced `SharedRuntime::f2hf()` and `hf2f()` C runtime functions with calls to runtime stubs which use the same HW instructions as C2 intrinsics. Only for 64-bit x64 because 32-bit x86 stub does not work: result is passed through FPU register and NaN values become different from C2 intrinsic. This runtime stub is only used to calculate constant values during C2 compilation and can be skipped. >> >> I added new tests based on Tobias's `TestAll.java` And copied `jdk/lang/Float/Binary16Conversion*.java` tests to run them with `-Xcomp` to make sure code is compiled by C1 or C2. I modified `Binary16ConversionNaN.java` to compare results from Interpreter, C1 and C2. >> >> Tested tier1-5, Xcomp, stress > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Remove RISC-V port code for float16 intrinsics src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 3534: > 3532: __ leave(); // required for proper stackwalking of RuntimeStub frame > 3533: __ ret(0); > 3534: Do we really need to set up a stack frame for these two? This should be a leaf, and we have other leaf stubs that don't set up a frame. ------------- PR: https://git.openjdk.org/jdk/pull/12869 From mchung at openjdk.org Wed Mar 8 22:41:09 2023 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 8 Mar 2023 22:41:09 GMT Subject: RFR: 8299088: ClassLoader.c contains 2 JNI exception pending defect groups In-Reply-To: References: Message-ID: On Wed, 8 Mar 2023 22:02:22 GMT, Justin Lu wrote: > This PR removes the JNI Exception pending defect groups in ClassLoader.c. > > `getUTF()` throws an exception and subsequently returns `null`; the exception should either be cleared, or control returned to the JVM. `JNU_ThrowOutOfMemoryError(env, NULL);` should not be called again This change looks right. OOME is thrown by getUTF if fails to allocate a string. It should not be thrown again. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.org/jdk/pull/12934 From kvn at openjdk.org Wed Mar 8 22:54:17 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 8 Mar 2023 22:54:17 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter [v4] In-Reply-To: References: Message-ID: On Wed, 8 Mar 2023 05:17:53 GMT, Vladimir Kozlov wrote: >> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in Interpreter and C1 compiler to produce the same results as C2 intrinsics on x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java methods were implemented originally. >> >> Replaced `SharedRuntime::f2hf()` and `hf2f()` C runtime functions with calls to runtime stubs which use the same HW instructions as C2 intrinsics. Only for 64-bit x64 because 32-bit x86 stub does not work: result is passed through FPU register and NaN values become different from C2 intrinsic. This runtime stub is only used to calculate constant values during C2 compilation and can be skipped. >> >> I added new tests based on Tobias's `TestAll.java` And copied `jdk/lang/Float/Binary16Conversion*.java` tests to run them with `-Xcomp` to make sure code is compiled by C1 or C2. I modified `Binary16ConversionNaN.java` to compare results from Interpreter, C1 and C2. >> >> Tested tier1-5, Xcomp, stress > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Remove RISC-V port code for float16 intrinsics > What if you move the wrapper to StubRoutines class instead? Okay, I will try it. ------------- PR: https://git.openjdk.org/jdk/pull/12869 From kvn at openjdk.org Wed Mar 8 22:54:19 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 8 Mar 2023 22:54:19 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter [v4] In-Reply-To: References: Message-ID: <-bRTiJ15e_f536NOqVIIge5Q_Ij1YwZVtS1Ciew-XDY=.9cbea18b-3202-4b76-a4aa-618005d4677b@github.com> On Wed, 8 Mar 2023 22:27:31 GMT, Dean Long wrote: >> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove RISC-V port code for float16 intrinsics > > src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 3534: > >> 3532: __ leave(); // required for proper stackwalking of RuntimeStub frame >> 3533: __ ret(0); >> 3534: > > Do we really need to set up a stack frame for these two? This should be a leaf, and we have other leaf stubs that don't set up a frame. I think you are right. These stubs are not called from compiled code, only from C++ (C2) code during compilation. Let me test it. ------------- PR: https://git.openjdk.org/jdk/pull/12869 From rgiulietti at openjdk.org Wed Mar 8 22:58:17 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 8 Mar 2023 22:58:17 GMT Subject: RFR: 8303485: Replacing os.name for operating system customization In-Reply-To: References: Message-ID: <63bDp4THq-tTVgVGSyKRzBJG5xonppC13R2bsHxrKWg=.8c7aca4a-32ee-4d43-b75a-619038fbc2fb@github.com> On Wed, 8 Mar 2023 19:15:16 GMT, Roger Riggs wrote: > Improvements to support OS specific customization for JDK internal use: > - To select values and code; allowing elimination of unused code and values > - Optionally evaluated by build processes, compilation, or archiving (i.e. CDS) > - Simple API to replace adhoc comparisons with `os.name` > - Clear and consistent use across build, runtime, and JDK modules > > The PR includes updates within java.base to use the new API. src/java.base/share/classes/jdk/internal/misc/OperatingSystem.java line 74: > 72: * The Mac OS X Operating system. > 73: */ > 74: Mac("Mac OS X"), The current spelling used by Apple is "macOS", probably to align to other Apple systems (iOS, iPadOS, etc.). src/java.base/share/classes/jdk/internal/misc/OperatingSystemProps.java.template line 34: > 32: // The values must match the ordinals of the respective enum > 33: private static final int TARGET_OS_linux = 0; > 34: private static final int TARGET_OS_macosx = 1; `TARGET_OS_macos` maybe? src/java.base/share/classes/jdk/internal/misc/OperatingSystemProps.java.template line 43: > 41: // Precomputed booleans for each Operating System > 42: static final boolean TARGET_OS_IS_LINUX = TARGET_OS_@@OPENJDK_TARGET_OS@@ == TARGET_OS_linux; > 43: static final boolean TARGET_OS_IS_MACOSX = TARGET_OS_@@OPENJDK_TARGET_OS@@ == TARGET_OS_macosx; `TARGET_OS_IS_MACOS` to be consistent with the suggestions. ------------- PR: https://git.openjdk.org/jdk/pull/12931 From dnsimon at openjdk.org Wed Mar 8 22:59:23 2023 From: dnsimon at openjdk.org (Doug Simon) Date: Wed, 8 Mar 2023 22:59:23 GMT Subject: RFR: 8303431: [JVMCI] libgraal annotation API [v5] In-Reply-To: References: Message-ID: > This PR extends JVMCI with new API (`jdk.vm.ci.meta.Annotated`) for accessing annotations. The main differences from `java.lang.reflect.AnnotatedElement` are: > * Each `Annotated` method explicitly specifies the annotation type(s) for which it wants annotation data. That is, there is no direct equivalent of `AnnotatedElement.getAnnotations()`. > * Annotation data is returned in a map-like object (of type `jdk.vm.ci.meta.AnnotationData`) instead of in an `Annotation` object. This works better for libgraal as it avoids the need for annotation types to be loaded and included in libgraal. > > To demonstrate the new API, here's an example in terms `java.lang.reflect.AnnotatedElement` (which `ResolvedJavaType` implements): > > ResolvedJavaMethod method = ...; > ExplodeLoop a = method.getAnnotation(ExplodeLoop.class); > return switch (a.kind()) { > case FULL_UNROLL -> LoopExplosionKind.FULL_UNROLL; > case FULL_UNROLL_UNTIL_RETURN -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN; > ... > } > > > The same code using the new API: > > > ResolvedJavaMethod method = ...; > ResolvedJavaType explodeLoopType = ...; > AnnotationData a = method.getAnnotationDataFor(explodeLoopType); > return switch (a.getEnum("kind").getName()) { > case "FULL_UNROLL" -> LoopExplosionKind.FULL_UNROLL; > case "FULL_UNROLL_UNTIL_RETURN" -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN; > ... > } > > > The implementation relies on new methods in `jdk.internal.vm.VMSupport` for parsing annotations and serializing/deserializing to/from a byte array. This allows the annotation data to be passed from the HotSpot heap to the libgraal heap. Doug Simon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Merge remote-tracking branch 'openjdk-jdk/master' into JDK-8303431 - switched to use of lists and maps instead of arrays - fixed whitespace - added support for inherited annotations - Merge branch 'master' into JDK-8303431 - made AnnotationDataDecoder package-private - add annotation API to JVMCI ------------- Changes: https://git.openjdk.org/jdk/pull/12810/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12810&range=04 Stats: 2326 lines in 34 files changed: 2273 ins; 23 del; 30 mod Patch: https://git.openjdk.org/jdk/pull/12810.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12810/head:pull/12810 PR: https://git.openjdk.org/jdk/pull/12810 From kvn at openjdk.org Wed Mar 8 23:14:05 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 8 Mar 2023 23:14:05 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter [v5] In-Reply-To: References: Message-ID: > Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in Interpreter and C1 compiler to produce the same results as C2 intrinsics on x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java methods were implemented originally. > > Replaced `SharedRuntime::f2hf()` and `hf2f()` C runtime functions with calls to runtime stubs which use the same HW instructions as C2 intrinsics. Only for 64-bit x64 because 32-bit x86 stub does not work: result is passed through FPU register and NaN values become different from C2 intrinsic. This runtime stub is only used to calculate constant values during C2 compilation and can be skipped. > > I added new tests based on Tobias's `TestAll.java` And copied `jdk/lang/Float/Binary16Conversion*.java` tests to run them with `-Xcomp` to make sure code is compiled by C1 or C2. I modified `Binary16ConversionNaN.java` to compare results from Interpreter, C1 and C2. > > Tested tier1-5, Xcomp, stress Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: Remove SharedRuntime::f2hf and hf2f wrapper functions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12869/files - new: https://git.openjdk.org/jdk/pull/12869/files/9f4b2474..fa799942 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12869&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12869&range=03-04 Stats: 43 lines in 5 files changed: 15 ins; 20 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/12869.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12869/head:pull/12869 PR: https://git.openjdk.org/jdk/pull/12869 From cjplummer at openjdk.org Wed Mar 8 23:26:13 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 8 Mar 2023 23:26:13 GMT Subject: RFR: 8303814: getLastErrorString should avoid charset conversions In-Reply-To: References: Message-ID: On Wed, 8 Mar 2023 11:30:27 GMT, Daniel Jeli?ski wrote: > This patch modifies the `getLastErrorString` method to return a `jstring`. Thanks to that we can avoid unnecessary back and forth conversions between Unicode and other charsets on Windows. > > Other changes include: > - the Windows implementation of `getLastErrorString` no longer checks `errno`. I verified all uses of the method and confirmed that `errno` is not used anywhere. > - While at it, I found and fixed a few calls to `JNU_ThrowIOExceptionWithLastError` that were done in context where `LastError` was not set. > - jdk.hotspot.agent was modified to use `JNU_ThrowByNameWithLastError` and `JNU_ThrowByName` instead of `getLastErrorString`; the code is expected to have identical behavior. > - zip_util was modified to return static messages instead of generated ones. The generated messages were not observed anywhere, because they were replaced by a static message in ZIP_Open, which is the only method used by other native code. > - `getLastErrorString` is no longer exported by libjava. > > Tier1-3 tests continue to pass. > > No new automated regression test; testing this requires installing a language pack that cannot be displayed in the current code page. > Tested this manually by installing Chinese language pack on English Windows 11, selecting Chinese language, then checking if the message on exception thrown by `InetAddress.getByName("nonexistent.local");` starts with `"?????????"` (or `"\u4e0d\u77e5\u9053\u8fd9\u6837\u7684\u4e3b\u673a\u3002"`). Without the change, the exception message started with a row of question marks. We don't have a test for the SA changes you made. The best way to test it is with clhsdb. Run the following against a JVM pid: `$ jhsdb clhsdb --pid ` Use "jstack -v" to get a native pc from a frame, and then try `disassemble` on the address. It most likely will produce an exception since it can't find hsdis, which is actually what we want to be testing in this case: hsdb> disassemble 0x00007f38b371fca0 Error: sun.jvm.hotspot.debugger.DebuggerException: hsdis-amd64.so: cannot open shared object file: No such file or directory You'll need to test separately on Windows and any unix platform. ------------- PR: https://git.openjdk.org/jdk/pull/12922 From mchung at openjdk.org Wed Mar 8 23:26:17 2023 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 8 Mar 2023 23:26:17 GMT Subject: RFR: 8303485: Replacing os.name for operating system customization In-Reply-To: References: Message-ID: On Wed, 8 Mar 2023 19:15:16 GMT, Roger Riggs wrote: > Improvements to support OS specific customization for JDK internal use: > - To select values and code; allowing elimination of unused code and values > - Optionally evaluated by build processes, compilation, or archiving (i.e. CDS) > - Simple API to replace adhoc comparisons with `os.name` > - Clear and consistent use across build, runtime, and JDK modules > > The PR includes updates within java.base to use the new API. I wonder if `jdk.internal.platform` would be a better home for `OperatingSystem` class? make/modules/java.base/gensrc/GensrcMisc.gmk line 57: > 55: OUTPUT_FILE := $(SUPPORT_OUTPUTDIR)/gensrc/java.base/jdk/internal/misc/OperatingSystemProps.java, \ > 56: REPLACEMENTS := \ > 57: @@OPENJDK_TARGET_OS@@ => $(OPENJDK_TARGET_OS), \ The replacement string can be as simple as `@@OS_NAME@@` that represents the current OS. Suggestion: @@OS_NAME@@ => $(OPENJDK_TARGET_OS), \ src/java.base/share/classes/jdk/internal/misc/OperatingSystem.java line 85: > 83: ; > 84: > 85: // Cache a copy of the array for lightweight indexing This is a reference to the Enum values array (not a copy). src/java.base/share/classes/jdk/internal/misc/OperatingSystem.java line 98: > 96: @ForceInline > 97: public static boolean isLinux() { > 98: return OperatingSystemProps.TARGET_OS_IS_LINUX; Suggestion: return OperatingSystemProps.CURRENT_OS_ORDINAL == Linux.ordinal(); This will also simplify the template file as `TARGET_OS_IS_XXX` constants are not needed. Also suggest to rename `TARGET_OS_ORDINAL` to `CURRENT_OS_ORDINAL` since it represents the current OS (vs the build target). src/java.base/share/classes/jdk/internal/misc/OperatingSystemProps.java.template line 29: > 27: * @see OperatingSystem > 28: */ > 29: class OperatingSystemProps { Have you considered to include OS architecture here for future use? So this file be `PlatformProps.java.template` instead. `jdk.tools.jlink.internal.Platform` needs to get the runtime OS and architecture. src/java.base/share/classes/jdk/internal/misc/OperatingSystemProps.java.template line 39: > 37: > 38: // Index/ordinal of the current OperatingSystem enum as substituted by the build > 39: static final int TARGET_OS_ORDINAL = TARGET_OS_@@OPENJDK_TARGET_OS@@; This represents the current OS. What about renaming it to: Suggestion: static final int CURRENT_OS_ORDINAL = @@OS_NAME@@; ------------- PR: https://git.openjdk.org/jdk/pull/12931 From vlivanov at openjdk.org Wed Mar 8 23:40:09 2023 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Wed, 8 Mar 2023 23:40:09 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter [v5] In-Reply-To: References: Message-ID: On Wed, 8 Mar 2023 23:14:05 GMT, Vladimir Kozlov wrote: >> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in Interpreter and C1 compiler to produce the same results as C2 intrinsics on x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java methods were implemented originally. >> >> Replaced `SharedRuntime::f2hf()` and `hf2f()` C runtime functions with calls to runtime stubs which use the same HW instructions as C2 intrinsics. Only for 64-bit x64 because 32-bit x86 stub does not work: result is passed through FPU register and NaN values become different from C2 intrinsic. This runtime stub is only used to calculate constant values during C2 compilation and can be skipped. >> >> I added new tests based on Tobias's `TestAll.java` And copied `jdk/lang/Float/Binary16Conversion*.java` tests to run them with `-Xcomp` to make sure code is compiled by C1 or C2. I modified `Binary16ConversionNaN.java` to compare results from Interpreter, C1 and C2. >> >> Tested tier1-5, Xcomp, stress > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Remove SharedRuntime::f2hf and hf2f wrapper functions Looks good. ------------- Marked as reviewed by vlivanov (Reviewer). PR: https://git.openjdk.org/jdk/pull/12869 From kvn at openjdk.org Thu Mar 9 00:04:09 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 9 Mar 2023 00:04:09 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter [v4] In-Reply-To: <-bRTiJ15e_f536NOqVIIge5Q_Ij1YwZVtS1Ciew-XDY=.9cbea18b-3202-4b76-a4aa-618005d4677b@github.com> References: <-bRTiJ15e_f536NOqVIIge5Q_Ij1YwZVtS1Ciew-XDY=.9cbea18b-3202-4b76-a4aa-618005d4677b@github.com> Message-ID: <3vTFng8nGQ-gFMkTzyexYknU4McM_8mzY5b6699QFaE=.ccd9b65f-fb69-49a4-b174-1847cdee3ebb@github.com> On Wed, 8 Mar 2023 22:49:42 GMT, Vladimir Kozlov wrote: >> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 3534: >> >>> 3532: __ leave(); // required for proper stackwalking of RuntimeStub frame >>> 3533: __ ret(0); >>> 3534: >> >> Do we really need to set up a stack frame for these two? This should be a leaf, and we have other leaf stubs that don't set up a frame. > > I think you are right. These stubs are not called from compiled code, only from C++ (C2) code during compilation. > Let me test it. Testing passed with `enter()` and `leave()` removed ------------- PR: https://git.openjdk.org/jdk/pull/12869 From kvn at openjdk.org Thu Mar 9 00:09:10 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 9 Mar 2023 00:09:10 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter [v5] In-Reply-To: References: Message-ID: On Wed, 8 Mar 2023 23:14:05 GMT, Vladimir Kozlov wrote: >> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in Interpreter and C1 compiler to produce the same results as C2 intrinsics on x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java methods were implemented originally. >> >> Replaced `SharedRuntime::f2hf()` and `hf2f()` C runtime functions with calls to runtime stubs which use the same HW instructions as C2 intrinsics. Only for 64-bit x64 because 32-bit x86 stub does not work: result is passed through FPU register and NaN values become different from C2 intrinsic. This runtime stub is only used to calculate constant values during C2 compilation and can be skipped. >> >> I added new tests based on Tobias's `TestAll.java` And copied `jdk/lang/Float/Binary16Conversion*.java` tests to run them with `-Xcomp` to make sure code is compiled by C1 or C2. I modified `Binary16ConversionNaN.java` to compare results from Interpreter, C1 and C2. >> >> Tested tier1-5, Xcomp, stress > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Remove SharedRuntime::f2hf and hf2f wrapper functions Thank you, Vladimir and Dean for review. ------------- PR: https://git.openjdk.org/jdk/pull/12869 From jlu at openjdk.org Thu Mar 9 00:13:21 2023 From: jlu at openjdk.org (Justin Lu) Date: Thu, 9 Mar 2023 00:13:21 GMT Subject: Integrated: 8171156: Class java.util.LocaleISOData has outdated information for country Code NP In-Reply-To: <0CQdEFn8R2OO_XAG5RSmSYgN-jm8-G0tv7SuETPD8-4=.d6cd8746-0a64-47f5-a38d-cce5ede7009d@github.com> References: <0CQdEFn8R2OO_XAG5RSmSYgN-jm8-G0tv7SuETPD8-4=.d6cd8746-0a64-47f5-a38d-cce5ede7009d@github.com> Message-ID: On Tue, 7 Mar 2023 22:55:56 GMT, Justin Lu wrote: > The java.util.LocaleISOData.isoCountryTable has an incorrect formal name for Nepal. > > According to [Wikipedia](https://en.wikipedia.org/wiki/Nepal) and the [UN](https://www.un.int/protocol/sites/www.un.int/files/Protocol%20and%20Liaison%20Service/officialnamesofcountries.pdf), Nepal's formal name should be `Federal Democratic Republic of Nepal`, not `Kingdom of Nepal`. It is only a comment, however there is no reason it should not be corrected. This pull request has now been integrated. Changeset: 02875e77 Author: Justin Lu Committer: Naoto Sato URL: https://git.openjdk.org/jdk/commit/02875e77fd01c39aee6f2f0900ea5605b40a8780 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8171156: Class java.util.LocaleISOData has outdated information for country Code NP Reviewed-by: naoto ------------- PR: https://git.openjdk.org/jdk/pull/12912 From smarks at openjdk.org Thu Mar 9 00:38:23 2023 From: smarks at openjdk.org (Stuart Marks) Date: Thu, 9 Mar 2023 00:38:23 GMT Subject: RFR: 8283660: Convert com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner [v16] In-Reply-To: References: Message-ID: On Fri, 22 Jul 2022 20:51:59 GMT, Brent Christian wrote: >> Please review this change to replace the finalizer in `AbstractLdapNamingEnumeration` with a Cleaner. >> >> The pieces of state required for cleanup (`LdapCtx homeCtx`, `LdapResult res`, and `LdapClient enumClnt`) are moved to a static inner class . From there, the change is fairly mechanical. >> >> Details of note: >> 1. Some operations need to change the state values (the update() method is probably the most interesting). >> 2. Subclasses need to access `homeCtx`; I added a `homeCtx()` method to read `homeCtx` from the superclass's `state`. >> >> The test case is based on a copy of `com/sun/jndi/ldap/blits/AddTests/AddNewEntry.java`. A more minimal test case might be possible, but this was done for expediency. >> >> The test only confirms that the new Cleaner use does not keep the object reachable. It only tests `LdapSearchEnumeration` (not `LdapNamingEnumeration` or `LdapBindingEnumeration`, though all are subclasses of `AbstractLdapNamingEnumeration`). >> >> Thanks. > > Brent Christian has updated the pull request incrementally with one additional commit since the last revision: > > remove some more tabs `MethodHandles.lookup().findVarHandle(PR.class, "8311").acquireFence()` ------------- PR: https://git.openjdk.org/jdk/pull/8311 From naoto at openjdk.org Thu Mar 9 00:52:18 2023 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 9 Mar 2023 00:52:18 GMT Subject: RFR: 8303485: Replacing os.name for operating system customization In-Reply-To: References: Message-ID: The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. ---------------------------------------------------------------------- On Wed, 8 Mar 2023 19:15:16 GMT, Roger Riggs wrote: > Improvements to support OS specific customization for JDK internal use: > - To select values and code; allowing elimination of unused code and values > - Optionally evaluated by build processes, compilation, or archiving (i.e. CDS) > - Simple API to replace adhoc comparisons with `os.name` > - Clear and consistent use across build, runtime, and JDK modules > > The PR includes updates within java.base to use the new API. Looks good. Some minor nits follow. src/java.base/share/classes/jdk/internal/util/StaticProperty.java line 261: > 259: > 260: /** > 261: * {@eturn the {@code os.arch} system property} typo: 'r' is misssing src/java.base/unix/classes/java/lang/ProcessImpl.java line 106: > 104: try { > 105: // Should be value of a LaunchMechanism enum > 106: LaunchMechanism lm = LaunchMechanism.valueOf(s.toUpperCase(Locale.ENGLISH)); I think `Locale.ROOT` is preferred here. test/jdk/java/foreign/TestUnsupportedLinker.java line 2: > 1: /* > 2: * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved. 2022, 2023? ------------- PR: https://git.openjdk.org/jdk/pull/12931 From dholmes at openjdk.org Thu Mar 9 02:54:14 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 9 Mar 2023 02:54:14 GMT Subject: RFR: 8303485: Replacing os.name for operating system customization In-Reply-To: References: Message-ID: On Wed, 8 Mar 2023 19:15:16 GMT, Roger Riggs wrote: > Improvements to support OS specific customization for JDK internal use: > - To select values and code; allowing elimination of unused code and values > - Optionally evaluated by build processes, compilation, or archiving (i.e. CDS) > - Simple API to replace adhoc comparisons with `os.name` > - Clear and consistent use across build, runtime, and JDK modules > > The PR includes updates within java.base to use the new API. I guess I'm surprised this hasn't been done long before now. :) Just a couple of drive by comments (I agree with comments made by others). Has this totally killed of BSD support on the JDK side? I thought building non-macOS BSD was still viable, but perhaps not - certainly not after this change. Thanks src/java.base/share/classes/jdk/internal/misc/OperatingSystem.java line 48: > 46: * For example, > 47: * {@snippet lang = "java": > 48: * if (OperatingSystem.current() == Windows) { Doesn't `Windows` need to be prefixed with `OperatingSystem` here? Ditto for dispatch example following. src/java.base/share/classes/jdk/internal/misc/OperatingSystem.java line 105: > 103: */ > 104: @ForceInline > 105: public static boolean isMac() { suggestion: isMacOS ------------- PR: https://git.openjdk.org/jdk/pull/12931 From kvn at openjdk.org Thu Mar 9 03:30:30 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 9 Mar 2023 03:30:30 GMT Subject: Integrated: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter In-Reply-To: References: Message-ID: On Fri, 3 Mar 2023 21:41:35 GMT, Vladimir Kozlov wrote: > Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in Interpreter and C1 compiler to produce the same results as C2 intrinsics on x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java methods were implemented originally. > > Replaced `SharedRuntime::f2hf()` and `hf2f()` C runtime functions with calls to runtime stubs which use the same HW instructions as C2 intrinsics. Only for 64-bit x64 because 32-bit x86 stub does not work: result is passed through FPU register and NaN values become different from C2 intrinsic. This runtime stub is only used to calculate constant values during C2 compilation and can be skipped. > > I added new tests based on Tobias's `TestAll.java` And copied `jdk/lang/Float/Binary16Conversion*.java` tests to run them with `-Xcomp` to make sure code is compiled by C1 or C2. I modified `Binary16ConversionNaN.java` to compare results from Interpreter, C1 and C2. > > Tested tier1-5, Xcomp, stress This pull request has now been integrated. Changeset: 8cfd74f7 Author: Vladimir Kozlov URL: https://git.openjdk.org/jdk/commit/8cfd74f76afc9e5d50c52104fef9974784718dd4 Stats: 1408 lines in 47 files changed: 1213 ins; 154 del; 41 mod 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter Reviewed-by: sviswanathan, jbhateja, vlivanov ------------- PR: https://git.openjdk.org/jdk/pull/12869 From jcking at google.com Thu Mar 9 04:02:52 2023 From: jcking at google.com (Justin King) Date: Wed, 8 Mar 2023 20:02:52 -0800 Subject: RFR: 8303485: Replacing os.name for operating system customization In-Reply-To: References: Message-ID: Let's please not kill generic BSD support if at all possible. There is NetBSD, OpenBSD, FreeBSD, and DragonflyBSD. I know FreeBSD and NetBSD have OpenJDK 19 and 17 respectively. On Wed, Mar 8, 2023, 6:54 PM David Holmes wrote: > On Wed, 8 Mar 2023 19:15:16 GMT, Roger Riggs wrote: > > > Improvements to support OS specific customization for JDK internal use: > > - To select values and code; allowing elimination of unused code and > values > > - Optionally evaluated by build processes, compilation, or archiving > (i.e. CDS) > > - Simple API to replace adhoc comparisons with `os.name` > > - Clear and consistent use across build, runtime, and JDK modules > > > > The PR includes updates within java.base to use the new API. > > I guess I'm surprised this hasn't been done long before now. :) > > Just a couple of drive by comments (I agree with comments made by others). > > Has this totally killed of BSD support on the JDK side? I thought building > non-macOS BSD was still viable, but perhaps not - certainly not after this > change. > > Thanks > > src/java.base/share/classes/jdk/internal/misc/OperatingSystem.java line 48: > > > 46: * For example, > > 47: * {@snippet lang = "java": > > 48: * if (OperatingSystem.current() == Windows) { > > Doesn't `Windows` need to be prefixed with `OperatingSystem` here? Ditto > for dispatch example following. > > src/java.base/share/classes/jdk/internal/misc/OperatingSystem.java line > 105: > > > 103: */ > > 104: @ForceInline > > 105: public static boolean isMac() { > > suggestion: isMacOS > > ------------- > > PR: https://git.openjdk.org/jdk/pull/12931 > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3999 bytes Desc: S/MIME Cryptographic Signature URL: From fjiang at openjdk.org Thu Mar 9 06:43:25 2023 From: fjiang at openjdk.org (Feilong Jiang) Date: Thu, 9 Mar 2023 06:43:25 GMT Subject: RFR: 8303022: "assert(allocates2(pc)) failed: not in CodeBuffer memory" When linking downcall handle [v2] In-Reply-To: References: Message-ID: On Wed, 8 Mar 2023 20:54:17 GMT, Jorn Vernee wrote: > @feilongjiang Could you comment on this? If you could figure out the needed sizes for RISCV I could add the needed changes to this patch. Otherwise I could file a followup issue if that seems more convenient. TIA Yes, I will take a look to find out the needed size for RISCV. ------------- PR: https://git.openjdk.org/jdk/pull/12908 From djelinski at openjdk.org Thu Mar 9 08:54:06 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 9 Mar 2023 08:54:06 GMT Subject: RFR: 8303814: getLastErrorString should avoid charset conversions In-Reply-To: References: Message-ID: On Wed, 8 Mar 2023 23:23:33 GMT, Chris Plummer wrote: >> This patch modifies the `getLastErrorString` method to return a `jstring`. Thanks to that we can avoid unnecessary back and forth conversions between Unicode and other charsets on Windows. >> >> Other changes include: >> - the Windows implementation of `getLastErrorString` no longer checks `errno`. I verified all uses of the method and confirmed that `errno` is not used anywhere. >> - While at it, I found and fixed a few calls to `JNU_ThrowIOExceptionWithLastError` that were done in context where `LastError` was not set. >> - jdk.hotspot.agent was modified to use `JNU_ThrowByNameWithLastError` and `JNU_ThrowByName` instead of `getLastErrorString`; the code is expected to have identical behavior. >> - zip_util was modified to return static messages instead of generated ones. The generated messages were not observed anywhere, because they were replaced by a static message in ZIP_Open, which is the only method used by other native code. >> - `getLastErrorString` is no longer exported by libjava. >> >> Tier1-3 tests continue to pass. >> >> No new automated regression test; testing this requires installing a language pack that cannot be displayed in the current code page. >> Tested this manually by installing Chinese language pack on English Windows 11, selecting Chinese language, then checking if the message on exception thrown by `InetAddress.getByName("nonexistent.local");` starts with `"?????????"` (or `"\u4e0d\u77e5\u9053\u8fd9\u6837\u7684\u4e3b\u673a\u3002"`). Without the change, the exception message started with a row of question marks. > > We don't have a test for the SA changes you made. The best way to test it is with clhsdb. Run the following against a JVM pid: > > `$ jhsdb clhsdb --pid ` > > Use "jstack -v" to get a native pc from a frame, and then try `disassemble` on the address. It most likely will produce an exception since it can't find hsdis, which is actually what we want to be testing in this case: > > > hsdb> disassemble 0x00007f38b371fca0 > Error: sun.jvm.hotspot.debugger.DebuggerException: hsdis-amd64.so: cannot open shared object file: No such file or directory > > > You'll need to test separately on Windows and any unix platform. Thanks @plummercj for the instructions. Here's the results: Linux, with this change applied: hsdb> disassemble 0x00007f3484558da0 Error: sun.jvm.hotspot.debugger.DebuggerException: hsdis-amd64.so: cannot open shared object file: No such file or directory Windows, EN, with the change: hsdb> disassemble 0x00000107d4dae0c6 Error: sun.jvm.hotspot.debugger.DebuggerException: The specified module could not be found Windows, misconfigured CN, without the change: hsdb> disassemble 0x00000200d60de0b4 Error: sun.jvm.hotspot.debugger.DebuggerException: ????????? Windows, misconfigured CN, with the change: hsdb> disassemble 0x000001fab996e0b4 Error: sun.jvm.hotspot.debugger.DebuggerException: ????????? (note: I had to run `chcp 65001` in the console, otherwise the exception would still display incorrectly) ------------- PR: https://git.openjdk.org/jdk/pull/12922 From duke at openjdk.org Thu Mar 9 10:20:19 2023 From: duke at openjdk.org (Viktor Klang) Date: Thu, 9 Mar 2023 10:20:19 GMT Subject: RFR: JDK-8302666: Replace CHM with VarHandle in ForeachOrderedTask [v2] In-Reply-To: <8S7Q0oMLcMo96x4Al5iiUspFDcgqk_tRavYCoDM1cbs=.0a3ccbe9-e199-4dbb-a1c1-252b4e906b86@github.com> References: <8S7Q0oMLcMo96x4Al5iiUspFDcgqk_tRavYCoDM1cbs=.0a3ccbe9-e199-4dbb-a1c1-252b4e906b86@github.com> Message-ID: On Fri, 17 Feb 2023 16:48:27 GMT, Paul Sandoz wrote: >> Viktor Klang has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. > > That's a nice find, looks good. (Update the year in the copyright header.) @PaulSandoz Ready to integrate? ? ------------- PR: https://git.openjdk.org/jdk/pull/12320 From duke at openjdk.org Thu Mar 9 12:22:22 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Thu, 9 Mar 2023 12:22:22 GMT Subject: RFR: 8303891: Zip64SizeTest could use a sparse file Message-ID: This PR suggests we use a sparse file when the Zip64SizeTest writes a ZIP file with a 5GB entry. The size requirement of this test is known to cause problems in some builds, see [JDK-8259866](https://bugs.openjdk.org/browse/JDK-8259866) Using a sparse file reduces the disk space requirements of running the test from 5GB to 12K and also reduces the runtime from ~35 seconds to ~3 seconds on my Macbook Pro. ------------- Commit messages: - Add a missing "when" in Javadocs for SparseOutputStream - Remove introduced blank line - Remove double whitespace - Rewrite Zip64SizeTest to write to a sparse file Changes: https://git.openjdk.org/jdk/pull/12948/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12948&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303891 Stats: 91 lines in 1 file changed: 56 ins; 17 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/12948.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12948/head:pull/12948 PR: https://git.openjdk.org/jdk/pull/12948 From duke at openjdk.org Thu Mar 9 14:02:30 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Thu, 9 Mar 2023 14:02:30 GMT Subject: RFR: 8303891: Zip64SizeTest could use a sparse file [v2] In-Reply-To: References: Message-ID: > This PR suggests we use a sparse file when the Zip64SizeTest writes a ZIP file with a 5GB entry. > > The size requirement of this test is known to cause problems in some builds, see [JDK-8259866](https://bugs.openjdk.org/browse/JDK-8259866) > > Using a sparse file reduces the disk space requirements of running the test from 5GB to 12K and also reduces the runtime from ~35 seconds to ~3 seconds on my Macbook Pro. Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision: Make test method public ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12948/files - new: https://git.openjdk.org/jdk/pull/12948/files/7f4643a1..d3a8d785 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12948&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12948&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12948.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12948/head:pull/12948 PR: https://git.openjdk.org/jdk/pull/12948 From mdoerr at openjdk.org Thu Mar 9 14:02:35 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Thu, 9 Mar 2023 14:02:35 GMT Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function & Memory API (Preview) [v12] In-Reply-To: References: Message-ID: > Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification". > > This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `` (2.2.4 Variable Argument Lists). > > Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only. > > There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Will get addressed separately: [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017) > > The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests. > > I had to make changes to shared code and code for other platforms: > 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons: > - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that. > - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64. > - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian! > 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit. Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: The merge change has messed up some includes in the tests. Revert. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12708/files - new: https://git.openjdk.org/jdk/pull/12708/files/f75a240d..a2eed058 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=10-11 Stats: 44 lines in 6 files changed: 15 ins; 21 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/12708.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12708/head:pull/12708 PR: https://git.openjdk.org/jdk/pull/12708 From fjiang at openjdk.org Thu Mar 9 14:48:23 2023 From: fjiang at openjdk.org (Feilong Jiang) Date: Thu, 9 Mar 2023 14:48:23 GMT Subject: RFR: 8303863: RISC-V: TestArrayStructs.java fails after JDK-8303604 Message-ID: The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. ---------------------------------------------------------------------- [JDK-8303604](https://bugs.openjdk.org/browse/JDK-8303604) fixes an issue with passing structs whose size is not a power of two on SysV and AArch64 platforms. The same issue happens on RISC-V. Modifications are unnecessary for `STRUCT_REGISTER_F` and `STRUCT_REGISTER_XF`. If there are no available registers, they will fall back to `STRUCT_REGISTER_X`. Testing: - [x] TestArrayStructs.java - [x] jdk_foreign on Unmatched Board (release build) ------------- Commit messages: - fix oob Changes: https://git.openjdk.org/jdk/pull/12950/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12950&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303863 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/12950.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12950/head:pull/12950 PR: https://git.openjdk.org/jdk/pull/12950 From duke at openjdk.org Thu Mar 9 15:10:28 2023 From: duke at openjdk.org (Viktor Klang) Date: Thu, 9 Mar 2023 15:10:28 GMT Subject: RFR: JDK-8302360 Atomic*.compareAndExchange Javadoc unclear [v2] In-Reply-To: References: Message-ID: On Tue, 7 Mar 2023 10:23:52 GMT, Viktor Klang wrote: >> I think the following proposal is very non-invasive and merely draws attention to the fact that "witness value" is a specific term related to the notion of these atomic methods. >> >> It's a small change which I think provides additional clarity, see JBS for the discussion on the topic. > > Viktor Klang has updated the pull request incrementally with one additional commit since the last revision: > > Reverting wording change to AtomicReference compareAndExchange @AlanBateman Who would be willing to sponsor this? ? ------------- PR: https://git.openjdk.org/jdk/pull/12880 From jvernee at openjdk.org Thu Mar 9 15:11:30 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 9 Mar 2023 15:11:30 GMT Subject: RFR: 8303863: RISC-V: TestArrayStructs.java fails after JDK-8303604 In-Reply-To: References: Message-ID: On Thu, 9 Mar 2023 14:39:55 GMT, Feilong Jiang wrote: > [JDK-8303604](https://bugs.openjdk.org/browse/JDK-8303604) fixes an issue with passing structs whose size is not a power of two on SysV and AArch64 platforms. The same issue happens on RISC-V. > > Modifications are unnecessary for `STRUCT_REGISTER_F` and `STRUCT_REGISTER_XF`. If there are no available registers, they will fall back to `STRUCT_REGISTER_X`. > > Testing: > > - [x] TestArrayStructs.java > - [x] jdk_foreign on Unmatched Board (release build) LGTM ------------- Marked as reviewed by jvernee (Reviewer). PR: https://git.openjdk.org/jdk/pull/12950 From erikj at openjdk.org Thu Mar 9 15:23:05 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 9 Mar 2023 15:23:05 GMT Subject: RFR: 8303485: Replacing os.name for operating system customization In-Reply-To: References: Message-ID: <7Skw3hFDdJ0cMXOZ2_foFbnHcghW1dVG0k_43QRboU4=.3913d27f-c71a-4949-9126-9dc2a9e4ae74@github.com> On Wed, 8 Mar 2023 19:15:16 GMT, Roger Riggs wrote: > Improvements to support OS specific customization for JDK internal use: > - To select values and code; allowing elimination of unused code and values > - Optionally evaluated by build processes, compilation, or archiving (i.e. CDS) > - Simple API to replace adhoc comparisons with `os.name` > - Clear and consistent use across build, runtime, and JDK modules > > The PR includes updates within java.base to use the new API. Build changes look good. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.org/jdk/pull/12931 From erikj at openjdk.org Thu Mar 9 15:27:08 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 9 Mar 2023 15:27:08 GMT Subject: RFR: 8303485: Replacing os.name for operating system customization In-Reply-To: References: Message-ID: <_8DN_1dTWHoKNsi93PzINoaR2f1ZCTfnyNJxPWF_qDs=.ab9adca9-ac4b-4bcd-8f53-6656a62d1401@github.com> On Wed, 8 Mar 2023 22:21:08 GMT, Mandy Chung wrote: >> Improvements to support OS specific customization for JDK internal use: >> - To select values and code; allowing elimination of unused code and values >> - Optionally evaluated by build processes, compilation, or archiving (i.e. CDS) >> - Simple API to replace adhoc comparisons with `os.name` >> - Clear and consistent use across build, runtime, and JDK modules >> >> The PR includes updates within java.base to use the new API. > > src/java.base/share/classes/jdk/internal/misc/OperatingSystemProps.java.template line 39: > >> 37: >> 38: // Index/ordinal of the current OperatingSystem enum as substituted by the build >> 39: static final int TARGET_OS_ORDINAL = TARGET_OS_@@OPENJDK_TARGET_OS@@; > > This represents the current OS. What about renaming it to: > Suggestion: > > static final int CURRENT_OS_ORDINAL = @@OS_NAME@@; I would argue that we should keep the replacement string matching the make variable its getting the value from. It makes it easier to trace the origin of the value. Using the terms `CURRENT` or `TARGET` inside the java class is less clear. `TARGET` is a references to how the JDK was built while `CURRENT` is more of a reference to the current runtime. Both are correct, it's more about what mental model we want at this level. ------------- PR: https://git.openjdk.org/jdk/pull/12931 From asotona at openjdk.org Thu Mar 9 15:28:21 2023 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 9 Mar 2023 15:28:21 GMT Subject: Integrated: 8294982: Implementation of Classfile API In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 12:38:04 GMT, Adam Sotona wrote: > This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. > > Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. > > Classfile API development is tracked at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch > > Development branch of consolidated JDK class files parsing, generating, and transforming is at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch > > Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. > > Please take you time to review this non-trivial JDK addition. > > Thank you, > Adam This pull request has now been integrated. Changeset: 4655b790 Author: Adam Sotona URL: https://git.openjdk.org/jdk/commit/4655b790d0b39b4ddabde78d7b3eed196b1152ed Stats: 52932 lines in 322 files changed: 52928 ins; 0 del; 4 mod 8294982: Implementation of Classfile API Reviewed-by: ihse, psandoz, mcimadamore ------------- PR: https://git.openjdk.org/jdk/pull/10982 From mdoerr at openjdk.org Thu Mar 9 15:51:56 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Thu, 9 Mar 2023 15:51:56 GMT Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function & Memory API (Preview) [v13] In-Reply-To: References: Message-ID: > Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification". > > This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `` (2.2.4 Variable Argument Lists). > > Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only. > > There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Will get addressed separately: [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017) > > The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests. > > I had to make changes to shared code and code for other platforms: > 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons: > - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that. > - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64. > - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian! > 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit. Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: Remove LinuxPPC64CallArranger.java because it doesn't contain anything. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12708/files - new: https://git.openjdk.org/jdk/pull/12708/files/a2eed058..fb87284c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=11-12 Stats: 44 lines in 3 files changed: 0 ins; 38 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/12708.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12708/head:pull/12708 PR: https://git.openjdk.org/jdk/pull/12708 From asotona at openjdk.org Thu Mar 9 15:53:25 2023 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 9 Mar 2023 15:53:25 GMT Subject: RFR: 8294961: java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes [v5] In-Reply-To: References: Message-ID: > java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes and this patch converts it to use Classfile API. > > This pull request suppose to chain on the 8294982: Implementation of Classfile API https://github.com/openjdk/jdk/pull/10982 > > Please review. > > Thank you, > Adam Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 195 commits: - Merge branch 'master' into JDK-8294961-proxy - Merge branch 'JDK-8294982' into JDK-8294961 - removed obsolete javadoc from implementation classes - minor fix in CodeBuilder and added test cases to LDCTest - EntryMap::nextPowerOfTwo delegates to Long:numberOfLeadingZeros - fixed CodeBuilder:constantInstruction for -0.0d and -0.0f values and added test - Merge branch 'master' into JDK-8294982 - fixed new lines at end of file - package jdk.internal.classfile.jdktypes moved to jdk.internal.classfile.java.lang.constant - fixed CodeRelabeler javadoc - ... and 185 more: https://git.openjdk.org/jdk/compare/cdcf5c1e...48ac16f8 ------------- Changes: https://git.openjdk.org/jdk/pull/10991/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10991&range=04 Stats: 465 lines in 2 files changed: 48 ins; 199 del; 218 mod Patch: https://git.openjdk.org/jdk/pull/10991.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10991/head:pull/10991 PR: https://git.openjdk.org/jdk/pull/10991 From mdoerr at openjdk.org Thu Mar 9 15:56:19 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Thu, 9 Mar 2023 15:56:19 GMT Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function & Memory API (Preview) [v3] In-Reply-To: References: <8b3vVrV22RuhdRoRYacXV0ZeghFGgKkC8S_z-iMrzAQ=.dd84b743-8b51-4281-8f5f-f9eff6207bc7@github.com> Message-ID: On Wed, 1 Mar 2023 06:27:19 GMT, Martin Doerr wrote: >> src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/CallArranger.java line 68: >> >>> 66: public abstract class CallArranger { >>> 67: // Linux PPC64 Little Endian uses ABI v2. >>> 68: private static final boolean useABIv2 = ByteOrder.nativeOrder() == ByteOrder.LITTLE_ENDIAN; >> >> Now that I'm here. This could be a potentially interesting case for having 2 subclasses of CallArranger: one for `useABIv2 == true` and one for `false`. > > Yeah, let's wait until we know what changes we need for AIX (and Big Endian linux). I think having a ABIV1CallArranger (for Big Endian linux and AIX) and a ABIV2CallArranger (linux ppc64le) will make sense. That's why I have removed the LinuxPPC64CallArranger.java with https://github.com/openjdk/jdk/pull/12708/commits/fb87284c1d3df946db378d196d7f48cd3acbab01. I guess a good time for such cleanup will be after the code for all variants is available (not part of this PR). ------------- PR: https://git.openjdk.org/jdk/pull/12708 From jvernee at openjdk.org Thu Mar 9 16:02:44 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 9 Mar 2023 16:02:44 GMT Subject: RFR: 8303001: Add test for re-entrant upcalls Message-ID: Add a test that tests re-entrant upcalls, which is a use-case that is uncovered by testing until now. ------------- Commit messages: - add reentrant upcalls test Changes: https://git.openjdk.org/jdk/pull/12927/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12927&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303001 Stats: 122 lines in 2 files changed: 122 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12927.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12927/head:pull/12927 PR: https://git.openjdk.org/jdk/pull/12927 From psandoz at openjdk.org Thu Mar 9 16:08:19 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 9 Mar 2023 16:08:19 GMT Subject: RFR: JDK-8302666: Replace CHM with VarHandle in ForeachOrderedTask [v6] In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 11:22:26 GMT, Viktor Klang wrote: >> I noticed when looking at the code that there was no real need to use a CHM to perform the tracking of activation in an ordered fashion on ForEachOrderedTask, but instead a VarHandle can be used, reducing allocations and indirection. > > Viktor Klang has updated the pull request incrementally with one additional commit since the last revision: > > Removing unnecessary cast of argument to VarHandle getAndSet Marked as reviewed by psandoz (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12320 From mcimadamore at openjdk.org Thu Mar 9 16:12:41 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 9 Mar 2023 16:12:41 GMT Subject: RFR: 8303001: Add test for re-entrant upcalls In-Reply-To: References: Message-ID: On Wed, 8 Mar 2023 15:51:05 GMT, Jorn Vernee wrote: > Add a test that tests re-entrant upcalls, which is a use-case that is uncovered by testing until now. Nice test! ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.org/jdk/pull/12927 From rriggs at openjdk.org Thu Mar 9 16:17:20 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 9 Mar 2023 16:17:20 GMT Subject: RFR: 8303485: Replacing os.name for operating system customization In-Reply-To: References: Message-ID: On Thu, 9 Mar 2023 02:51:24 GMT, David Holmes wrote: > Has this totally killed of BSD support on the JDK side? I thought building non-macOS BSD was still viable, but perhaps not - certainly not after this change. I haven't found any use of BSD and I don't think the build supports a BSD build. > src/java.base/share/classes/jdk/internal/misc/OperatingSystem.java line 48: > >> 46: * For example, >> 47: * {@snippet lang = "java": >> 48: * if (OperatingSystem.current() == Windows) { > > Doesn't `Windows` need to be prefixed with `OperatingSystem` here? Ditto for dispatch example following. Yes, either a static import or a qualified name is needed. (This is internal javadoc). > src/java.base/share/classes/jdk/internal/misc/OperatingSystem.java line 105: > >> 103: */ >> 104: @ForceInline >> 105: public static boolean isMac() { > > suggestion: isMacOS As above, sticking to a generic term can make this a bit less sensitive to branding changes. ------------- PR: https://git.openjdk.org/jdk/pull/12931 From rriggs at openjdk.org Thu Mar 9 16:17:23 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 9 Mar 2023 16:17:23 GMT Subject: RFR: 8303485: Replacing os.name for operating system customization In-Reply-To: <63bDp4THq-tTVgVGSyKRzBJG5xonppC13R2bsHxrKWg=.8c7aca4a-32ee-4d43-b75a-619038fbc2fb@github.com> References: <63bDp4THq-tTVgVGSyKRzBJG5xonppC13R2bsHxrKWg=.8c7aca4a-32ee-4d43-b75a-619038fbc2fb@github.com> Message-ID: On Wed, 8 Mar 2023 22:49:05 GMT, Raffaello Giulietti wrote: >> Improvements to support OS specific customization for JDK internal use: >> - To select values and code; allowing elimination of unused code and values >> - Optionally evaluated by build processes, compilation, or archiving (i.e. CDS) >> - Simple API to replace adhoc comparisons with `os.name` >> - Clear and consistent use across build, runtime, and JDK modules >> >> The PR includes updates within java.base to use the new API. > > src/java.base/share/classes/jdk/internal/misc/OperatingSystem.java line 74: > >> 72: * The Mac OS X Operating system. >> 73: */ >> 74: Mac("Mac OS X"), > > The current spelling used by Apple is "macOS", probably to align to other Apple systems (iOS, iPadOS, etc.). Names and branding have changed over the years. It may be prudent to remove the name entirely and stick to a 'generic' identification of the OS as the Enum name. > src/java.base/share/classes/jdk/internal/misc/OperatingSystemProps.java.template line 34: > >> 32: // The values must match the ordinals of the respective enum >> 33: private static final int TARGET_OS_linux = 0; >> 34: private static final int TARGET_OS_macosx = 1; > > `TARGET_OS_macos` maybe? These names need to match the names used in the build makefiles; currently is macosx. ------------- PR: https://git.openjdk.org/jdk/pull/12931 From rriggs at openjdk.org Thu Mar 9 16:17:29 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 9 Mar 2023 16:17:29 GMT Subject: RFR: 8303485: Replacing os.name for operating system customization In-Reply-To: References: Message-ID: On Wed, 8 Mar 2023 23:11:34 GMT, Mandy Chung wrote: >> Improvements to support OS specific customization for JDK internal use: >> - To select values and code; allowing elimination of unused code and values >> - Optionally evaluated by build processes, compilation, or archiving (i.e. CDS) >> - Simple API to replace adhoc comparisons with `os.name` >> - Clear and consistent use across build, runtime, and JDK modules >> >> The PR includes updates within java.base to use the new API. > > src/java.base/share/classes/jdk/internal/misc/OperatingSystem.java line 98: > >> 96: @ForceInline >> 97: public static boolean isLinux() { >> 98: return OperatingSystemProps.TARGET_OS_IS_LINUX; > > Suggestion: > > return OperatingSystemProps.CURRENT_OS_ORDINAL == Linux.ordinal(); > > > This will also simplify the template file as `TARGET_OS_IS_XXX` constants are not needed. > > Also suggest to rename `TARGET_OS_ORDINAL` to `CURRENT_OS_ORDINAL` since it represents the current OS (vs the build target). That would not yield a compile time constant. The TARGET_IS_XXX values must evaluate to compile time constants as evaluated by javac. > src/java.base/share/classes/jdk/internal/misc/OperatingSystemProps.java.template line 29: > >> 27: * @see OperatingSystem >> 28: */ >> 29: class OperatingSystemProps { > > Have you considered to include OS architecture here for future use? So this file be `PlatformProps.java.template` instead. > > `jdk.tools.jlink.internal.Platform` needs to get the runtime OS and architecture. I plan to come back to os.arch, it has a similar but not identical requirements. ------------- PR: https://git.openjdk.org/jdk/pull/12931 From rriggs at openjdk.org Thu Mar 9 16:17:31 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 9 Mar 2023 16:17:31 GMT Subject: RFR: 8303485: Replacing os.name for operating system customization In-Reply-To: <_8DN_1dTWHoKNsi93PzINoaR2f1ZCTfnyNJxPWF_qDs=.ab9adca9-ac4b-4bcd-8f53-6656a62d1401@github.com> References: <_8DN_1dTWHoKNsi93PzINoaR2f1ZCTfnyNJxPWF_qDs=.ab9adca9-ac4b-4bcd-8f53-6656a62d1401@github.com> Message-ID: On Thu, 9 Mar 2023 15:24:04 GMT, Erik Joelsson wrote: >> src/java.base/share/classes/jdk/internal/misc/OperatingSystemProps.java.template line 39: >> >>> 37: >>> 38: // Index/ordinal of the current OperatingSystem enum as substituted by the build >>> 39: static final int TARGET_OS_ORDINAL = TARGET_OS_@@OPENJDK_TARGET_OS@@; >> >> This represents the current OS. What about renaming it to: >> Suggestion: >> >> static final int CURRENT_OS_ORDINAL = @@OS_NAME@@; > > I would argue that we should keep the replacement string matching the make variable its getting the value from. It makes it easier to trace the origin of the value. > > Using the terms `CURRENT` or `TARGET` inside the java class is less clear. `TARGET` is a references to how the JDK was built while `CURRENT` is more of a reference to the current runtime. Both are correct, it's more about what mental model we want at this level. The symbol has to match the build usage of OPENJDK_TARGET_OS, not the name. ------------- PR: https://git.openjdk.org/jdk/pull/12931 From rriggs at openjdk.org Thu Mar 9 16:17:34 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 9 Mar 2023 16:17:34 GMT Subject: RFR: 8303485: Replacing os.name for operating system customization In-Reply-To: References: Message-ID: <5C6eCHsmnRR24PBxfSw_3UJNQECK14s6sJ7wbh1VwYc=.42c5f313-41d3-46c8-beec-b5a79a2f6cd8@github.com> On Thu, 9 Mar 2023 00:45:02 GMT, Naoto Sato wrote: >> Improvements to support OS specific customization for JDK internal use: >> - To select values and code; allowing elimination of unused code and values >> - Optionally evaluated by build processes, compilation, or archiving (i.e. CDS) >> - Simple API to replace adhoc comparisons with `os.name` >> - Clear and consistent use across build, runtime, and JDK modules >> >> The PR includes updates within java.base to use the new API. > > src/java.base/unix/classes/java/lang/ProcessImpl.java line 106: > >> 104: try { >> 105: // Should be value of a LaunchMechanism enum >> 106: LaunchMechanism lm = LaunchMechanism.valueOf(s.toUpperCase(Locale.ENGLISH)); > > I think `Locale.ROOT` is preferred here. ok, but not strictly in scope for this PR; that's pre-existing code. ------------- PR: https://git.openjdk.org/jdk/pull/12931 From rriggs at openjdk.org Thu Mar 9 16:39:28 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 9 Mar 2023 16:39:28 GMT Subject: RFR: 8303485: Replacing os.name for operating system customization In-Reply-To: References: Message-ID: On Wed, 8 Mar 2023 23:09:06 GMT, Mandy Chung wrote: >> Improvements to support OS specific customization for JDK internal use: >> - To select values and code; allowing elimination of unused code and values >> - Optionally evaluated by build processes, compilation, or archiving (i.e. CDS) >> - Simple API to replace adhoc comparisons with `os.name` >> - Clear and consistent use across build, runtime, and JDK modules >> >> The PR includes updates within java.base to use the new API. > > src/java.base/share/classes/jdk/internal/misc/OperatingSystem.java line 85: > >> 83: ; >> 84: >> 85: // Cache a copy of the array for lightweight indexing > > This is a reference to the Enum values array (not a copy). The implementation of OperatingSystem.values() does a clone() of the array. It would be risky to allow the enum to change its own members. ------------- PR: https://git.openjdk.org/jdk/pull/12931 From mchung at openjdk.org Thu Mar 9 17:06:30 2023 From: mchung at openjdk.org (Mandy Chung) Date: Thu, 9 Mar 2023 17:06:30 GMT Subject: RFR: 8303485: Replacing os.name for operating system customization In-Reply-To: References: <_8DN_1dTWHoKNsi93PzINoaR2f1ZCTfnyNJxPWF_qDs=.ab9adca9-ac4b-4bcd-8f53-6656a62d1401@github.com> Message-ID: On Thu, 9 Mar 2023 16:03:37 GMT, Roger Riggs wrote: >> I would argue that we should keep the replacement string matching the make variable its getting the value from. It makes it easier to trace the origin of the value. >> >> Using the terms `CURRENT` or `TARGET` inside the java class is less clear. `TARGET` is a references to how the JDK was built while `CURRENT` is more of a reference to the current runtime. Both are correct, it's more about what mental model we want at this level. > > The symbol has to match the build usage of OPENJDK_TARGET_OS, not the name. The one in the template file is independent to the build variables. ------------- PR: https://git.openjdk.org/jdk/pull/12931 From roger.riggs at oracle.com Thu Mar 9 17:09:25 2023 From: roger.riggs at oracle.com (Roger Riggs) Date: Thu, 9 Mar 2023 12:09:25 -0500 Subject: RFR: 8303485: Replacing os.name for operating system customization In-Reply-To: References: Message-ID: Hi Justin, How would I go about building one of those? Or knowing what the dependencies are? Thanks, Roger On 3/8/23 11:02 PM, Justin King wrote: > Let's please not kill generic BSD support if at all possible. There is > NetBSD, OpenBSD, FreeBSD, and DragonflyBSD. I know FreeBSD and NetBSD > have OpenJDK 19 and 17 respectively. > > On Wed, Mar 8, 2023, 6:54 PM David Holmes wrote: > > On Wed, 8 Mar 2023 19:15:16 GMT, Roger Riggs > wrote: > > > Improvements to support OS specific customization for JDK > internal use: > >? - To select values and code; allowing elimination of unused > code and values > >? - Optionally evaluated by build processes, compilation, or > archiving (i.e. CDS) > >? - Simple API to replace adhoc comparisons with `os.name > ` > >? - Clear and consistent use across build, runtime, and JDK modules > > > > The PR includes updates within java.base to use the new API. > > I guess I'm surprised this hasn't been done long before now. :) > > Just a couple of drive by comments (I agree with comments made by > others). > > Has this totally killed of BSD support on the JDK side? I thought > building non-macOS BSD was still viable, but perhaps not - > certainly not after this change. > > Thanks > > src/java.base/share/classes/jdk/internal/misc/OperatingSystem.java > line 48: > > > 46:? * For example, > > 47:? * {@snippet lang = "java": > > 48:? * if (OperatingSystem.current() == Windows) { > > Doesn't `Windows` need to be prefixed with `OperatingSystem` here? > Ditto for dispatch example following. > > src/java.base/share/classes/jdk/internal/misc/OperatingSystem.java > line 105: > > > 103:? ? ? */ > > 104:? ? ?@ForceInline > > 105:? ? ?public static boolean isMac() { > > suggestion: isMacOS > > ------------- > > PR: https://git.openjdk.org/jdk/pull/12931 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mchung at openjdk.org Thu Mar 9 17:10:27 2023 From: mchung at openjdk.org (Mandy Chung) Date: Thu, 9 Mar 2023 17:10:27 GMT Subject: RFR: 8303485: Replacing os.name for operating system customization In-Reply-To: References: <_8DN_1dTWHoKNsi93PzINoaR2f1ZCTfnyNJxPWF_qDs=.ab9adca9-ac4b-4bcd-8f53-6656a62d1401@github.com> Message-ID: On Thu, 9 Mar 2023 17:03:05 GMT, Mandy Chung wrote: >> The symbol has to match the build usage of OPENJDK_TARGET_OS, not the name. > > The one in the template file is independent to the build variables. > I would argue that we should keep the replacement string matching the make variable its getting the value from. It makes it easier to trace the origin of the value. Then we can define a new make variable that will also allow it be a different value than `OPENJDK_TARGET_OS` if desirable. ------------- PR: https://git.openjdk.org/jdk/pull/12931 From naoto at openjdk.org Thu Mar 9 17:11:37 2023 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 9 Mar 2023 17:11:37 GMT Subject: RFR: 8299088: ClassLoader.c contains 2 JNI exception pending defect groups In-Reply-To: References: Message-ID: <3xEQFtnLke14BPxUF65GyU8vOtp5aqhFkOfhL5uVw_k=.fbe6f6ed-b469-40ad-b43f-5425e6134b8b@github.com> On Wed, 8 Mar 2023 22:02:22 GMT, Justin Lu wrote: > This PR removes the JNI Exception pending defect groups in ClassLoader.c. > > `getUTF()` throws an exception and subsequently returns `null`; the exception should either be cleared, or control returned to the JVM. `JNU_ThrowOutOfMemoryError(env, NULL);` should not be called again LGTM ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.org/jdk/pull/12934 From rriggs at openjdk.org Thu Mar 9 17:15:50 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 9 Mar 2023 17:15:50 GMT Subject: RFR: 8303485: Replacing os.name for operating system customization In-Reply-To: References: <_8DN_1dTWHoKNsi93PzINoaR2f1ZCTfnyNJxPWF_qDs=.ab9adca9-ac4b-4bcd-8f53-6656a62d1401@github.com> Message-ID: On Thu, 9 Mar 2023 17:07:28 GMT, Mandy Chung wrote: >> The one in the template file is independent to the build variables. > >> I would argue that we should keep the replacement string matching the make variable its getting the value from. It makes it easier to trace the origin of the value. > > Then we can define a new make variable that will also allow it be a different value than `OPENJDK_TARGET_OS` if desirable. There is no need to define a new variable, there are already too many in the build and the build and the compiled files should be using the same symbols. ------------- PR: https://git.openjdk.org/jdk/pull/12931 From rriggs at openjdk.org Thu Mar 9 17:21:45 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 9 Mar 2023 17:21:45 GMT Subject: RFR: 8303485: Replacing os.name for operating system customization In-Reply-To: References: Message-ID: <9GNYcmdPMby8pBH09OhJmHnliaM2nHwFrpQhJRfS8-c=.23fa8a24-7464-43a4-a153-5a45a4ca7c85@github.com> On Thu, 9 Mar 2023 16:05:56 GMT, Roger Riggs wrote: >> src/java.base/share/classes/jdk/internal/misc/OperatingSystem.java line 98: >> >>> 96: @ForceInline >>> 97: public static boolean isLinux() { >>> 98: return OperatingSystemProps.TARGET_OS_IS_LINUX; >> >> Suggestion: >> >> return OperatingSystemProps.CURRENT_OS_ORDINAL == Linux.ordinal(); >> >> >> This will also simplify the template file as `TARGET_OS_IS_XXX` constants are not needed. >> >> Also suggest to rename `TARGET_OS_ORDINAL` to `CURRENT_OS_ORDINAL` since it represents the current OS (vs the build target). > > That would not yield a compile time constant. > The TARGET_IS_XXX values must evaluate to compile time constants as evaluated by javac. Using the naming from the build makes it clearer that there is a dependency between the build names and those in the template. ------------- PR: https://git.openjdk.org/jdk/pull/12931 From mchung at openjdk.org Thu Mar 9 17:26:06 2023 From: mchung at openjdk.org (Mandy Chung) Date: Thu, 9 Mar 2023 17:26:06 GMT Subject: RFR: 8294959: java.base java.lang.Module uses ASM to load module-info.class In-Reply-To: <5_kDTDkNw-ARy8ZmSqn_LOQw5lt-0WqKeHNdGWIBPHs=.ae41b748-0ca7-4492-9fcf-a0682576bc29@github.com> References: <5_kDTDkNw-ARy8ZmSqn_LOQw5lt-0WqKeHNdGWIBPHs=.ae41b748-0ca7-4492-9fcf-a0682576bc29@github.com> Message-ID: On Fri, 25 Nov 2022 14:35:22 GMT, Adam Sotona wrote: > java.base java.lang.Module uses ASM to load module-info.class and this patch converts it to use Classfile API. This change looks good. ------------- PR: https://git.openjdk.org/jdk/pull/11367 From asotona at openjdk.org Thu Mar 9 17:26:05 2023 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 9 Mar 2023 17:26:05 GMT Subject: RFR: 8294959: java.base java.lang.Module uses ASM to load module-info.class Message-ID: <5_kDTDkNw-ARy8ZmSqn_LOQw5lt-0WqKeHNdGWIBPHs=.ae41b748-0ca7-4492-9fcf-a0682576bc29@github.com> java.base java.lang.Module uses ASM to load module-info.class and this patch converts it to use Classfile API. ------------- Commit messages: - Merge branch 'master' into JDK-8294959-module - Merge branch 'JDK-8294982' into JDK-8294959 - removed obsolete javadoc from implementation classes - minor fix in CodeBuilder and added test cases to LDCTest - EntryMap::nextPowerOfTwo delegates to Long:numberOfLeadingZeros - fixed CodeBuilder:constantInstruction for -0.0d and -0.0f values and added test - Merge branch 'master' into JDK-8294982 - fixed new lines at end of file - package jdk.internal.classfile.jdktypes moved to jdk.internal.classfile.java.lang.constant - fixed CodeRelabeler javadoc - ... and 184 more: https://git.openjdk.org/jdk/compare/cdcf5c1e...61748d8c Changes: https://git.openjdk.org/jdk/pull/11367/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11367&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294959 Stats: 54 lines in 1 file changed: 8 ins; 37 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/11367.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11367/head:pull/11367 PR: https://git.openjdk.org/jdk/pull/11367 From mdoerr at openjdk.org Thu Mar 9 17:29:37 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Thu, 9 Mar 2023 17:29:37 GMT Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function & Memory API (Preview) [v14] In-Reply-To: References: Message-ID: > Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification". > > This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `` (2.2.4 Variable Argument Lists). > > Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only. > > There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Will get addressed separately: [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017) > > The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests. > > I had to make changes to shared code and code for other platforms: > 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons: > - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that. > - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64. > - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian! > 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit. Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: Introduce ABIv2CallArranger for linux ppc64le. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12708/files - new: https://git.openjdk.org/jdk/pull/12708/files/fb87284c..2e4e269e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=12-13 Stats: 178 lines in 8 files changed: 99 ins; 58 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/12708.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12708/head:pull/12708 PR: https://git.openjdk.org/jdk/pull/12708 From duke at openjdk.org Thu Mar 9 17:30:55 2023 From: duke at openjdk.org (liach) Date: Thu, 9 Mar 2023 17:30:55 GMT Subject: RFR: 8294961: java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes [v3] In-Reply-To: <6MQUzvBb7NdEBp2zu0FjIRVWNYw9INz7yXbqAAZU-vo=.c6a832a8-248f-4c5b-a36e-8b18f6c5a0b7@github.com> References: <6MQUzvBb7NdEBp2zu0FjIRVWNYw9INz7yXbqAAZU-vo=.c6a832a8-248f-4c5b-a36e-8b18f6c5a0b7@github.com> Message-ID: On Thu, 9 Feb 2023 18:48:19 GMT, Adam Sotona wrote: >> java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes and this patch converts it to use Classfile API. >> >> Please review. >> >> Thank you, >> Adam > > Adam Sotona 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: > > - j.l.r.ProxyGenerator improvements > Author: Mandy Chung > - Merge branch 'JDK-8294982' into JDK-8294961 > - j.l.r.ProxyGenerator fix - Classfile API moved under jdk.internal.classfile package > - Merge branch 'JDK-8294982' into JDK-8294961 > - Merge branch 'JDK-8294982' into JDK-8294961 > - 8294961: java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 661: > 659: */ > 660: private void generateMethod(ClassBuilder clb, ClassDesc className) { > 661: MethodTypeDesc desc = MethodType.methodType(returnType, parameterTypes).describeConstable().orElseThrow(); Can we convert this line to: MethodTypeDesc desc = MethodTypeDesc.of(toClassDesc(returnType), Arrays.stream(parameterTypes).map(ProxyGenerator::toClassDesc).toArray(ClassDesc[]::new)); Mainly due to that `MethodType` creation involves a lot of unrelated process such as generating lambda forms, and we can remove the `MethodType` import as a result. ------------- PR: https://git.openjdk.org/jdk/pull/10991 From asotona at openjdk.org Thu Mar 9 17:30:56 2023 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 9 Mar 2023 17:30:56 GMT Subject: RFR: 8294961: java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes [v3] In-Reply-To: References: <6MQUzvBb7NdEBp2zu0FjIRVWNYw9INz7yXbqAAZU-vo=.c6a832a8-248f-4c5b-a36e-8b18f6c5a0b7@github.com> Message-ID: On Sun, 19 Feb 2023 05:23:20 GMT, liach wrote: >> Adam Sotona 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: >> >> - j.l.r.ProxyGenerator improvements >> Author: Mandy Chung >> - Merge branch 'JDK-8294982' into JDK-8294961 >> - j.l.r.ProxyGenerator fix - Classfile API moved under jdk.internal.classfile package >> - Merge branch 'JDK-8294982' into JDK-8294961 >> - Merge branch 'JDK-8294982' into JDK-8294961 >> - 8294961: java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes > > src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 661: > >> 659: */ >> 660: private void generateMethod(ClassBuilder clb, ClassDesc className) { >> 661: MethodTypeDesc desc = MethodType.methodType(returnType, parameterTypes).describeConstable().orElseThrow(); > > Can we convert this line to: > > MethodTypeDesc desc = MethodTypeDesc.of(toClassDesc(returnType), Arrays.stream(parameterTypes).map(ProxyGenerator::toClassDesc).toArray(ClassDesc[]::new)); > > > Mainly due to that `MethodType` creation involves a lot of unrelated process such as generating lambda forms, and we can remove the `MethodType` import as a result. Isn't the "unrelated process such as generating lambda forms" critical for the `ProxyGenerator` functionality? ------------- PR: https://git.openjdk.org/jdk/pull/10991 From duke at openjdk.org Thu Mar 9 17:30:56 2023 From: duke at openjdk.org (liach) Date: Thu, 9 Mar 2023 17:30:56 GMT Subject: RFR: 8294961: java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes [v3] In-Reply-To: References: <6MQUzvBb7NdEBp2zu0FjIRVWNYw9INz7yXbqAAZU-vo=.c6a832a8-248f-4c5b-a36e-8b18f6c5a0b7@github.com> Message-ID: On Thu, 9 Mar 2023 11:15:44 GMT, Adam Sotona wrote: >> src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 661: >> >>> 659: */ >>> 660: private void generateMethod(ClassBuilder clb, ClassDesc className) { >>> 661: MethodTypeDesc desc = MethodType.methodType(returnType, parameterTypes).describeConstable().orElseThrow(); >> >> Can we convert this line to: >> >> MethodTypeDesc desc = MethodTypeDesc.of(toClassDesc(returnType), Arrays.stream(parameterTypes).map(ProxyGenerator::toClassDesc).toArray(ClassDesc[]::new)); >> >> >> Mainly due to that `MethodType` creation involves a lot of unrelated process such as generating lambda forms, and we can remove the `MethodType` import as a result. > > Isn't the "unrelated process such as generating lambda forms" critical for the `ProxyGenerator` functionality? More accurately, I mean the overhead generated by this: https://github.com/openjdk/jdk/blob/1e9942aa112edca33f964db127df6c9ce41e86ff/src/java.base/share/classes/java/lang/invoke/MethodType.java#L408 That method type construction is somewhat expensive and involves extra work besides simply storing the return class and the parameter classes. ------------- PR: https://git.openjdk.org/jdk/pull/10991 From asotona at openjdk.org Thu Mar 9 17:39:12 2023 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 9 Mar 2023 17:39:12 GMT Subject: RFR: 8294962: java.base jdk.internal.module package uses ASM to modify and write module-info.class Message-ID: 8294962: java.base jdk.internal.module package uses ASM to modify and write module-info.class. This patch converts it to use Classfile API. Please review. Thanks, Adam ------------- Commit messages: - Merge branch 'master' into JDK-8294962-internal-module - fixed jdk.internal.classfile.java.lang.constant package name - Merge branch 'JDK-8294982' into JDK-8294962 - removed obsolete javadoc from implementation classes - minor fix in CodeBuilder and added test cases to LDCTest - EntryMap::nextPowerOfTwo delegates to Long:numberOfLeadingZeros - fixed CodeBuilder:constantInstruction for -0.0d and -0.0f values and added test - Merge branch 'master' into JDK-8294982 - fixed new lines at end of file - package jdk.internal.classfile.jdktypes moved to jdk.internal.classfile.java.lang.constant - ... and 184 more: https://git.openjdk.org/jdk/compare/cdcf5c1e...011a6700 Changes: https://git.openjdk.org/jdk/pull/11368/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11368&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294962 Stats: 273 lines in 2 files changed: 85 ins; 116 del; 72 mod Patch: https://git.openjdk.org/jdk/pull/11368.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11368/head:pull/11368 PR: https://git.openjdk.org/jdk/pull/11368 From alanb at openjdk.org Thu Mar 9 17:39:13 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 9 Mar 2023 17:39:13 GMT Subject: RFR: 8294962: java.base jdk.internal.module package uses ASM to modify and write module-info.class In-Reply-To: References: Message-ID: On Fri, 25 Nov 2022 14:38:55 GMT, Adam Sotona wrote: > 8294962: java.base jdk.internal.module package uses ASM to modify and write module-info.class. > This patch converts it to use Classfile API. > > Please review. > Thanks, > Adam src/java.base/share/classes/jdk/internal/module/ModuleInfoExtender.java line 184: > 182: clb.with(ModuleAttribute.of(ma.moduleName(), ma.moduleFlagsMask(), clb.constantPool().utf8Entry(v.toString()), ma.requires(), ma.exports(), ma.opens(), ma.uses(), ma.provides())); > 183: } else { > 184: clb.accept(cle); Can you re-format this so that it's consistent with the existing code? Wildly long lines (180+ chars in this case) make it impossible to use side-by-side views when looking at changes. ------------- PR: https://git.openjdk.org/jdk/pull/11368 From asotona at openjdk.org Thu Mar 9 17:39:13 2023 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 9 Mar 2023 17:39:13 GMT Subject: RFR: 8294962: java.base jdk.internal.module package uses ASM to modify and write module-info.class In-Reply-To: References: Message-ID: On Fri, 25 Nov 2022 14:43:32 GMT, Alan Bateman wrote: >> 8294962: java.base jdk.internal.module package uses ASM to modify and write module-info.class. >> This patch converts it to use Classfile API. >> >> Please review. >> Thanks, >> Adam > > src/java.base/share/classes/jdk/internal/module/ModuleInfoExtender.java line 184: > >> 182: clb.with(ModuleAttribute.of(ma.moduleName(), ma.moduleFlagsMask(), clb.constantPool().utf8Entry(v.toString()), ma.requires(), ma.exports(), ma.opens(), ma.uses(), ma.provides())); >> 183: } else { >> 184: clb.accept(cle); > > Can you re-format this so that it's consistent with the existing code? Wildly long lines (180+ chars in this case) make it impossible to use side-by-side views when looking at changes. Fixed, I'm sorry I missed it. ------------- PR: https://git.openjdk.org/jdk/pull/11368 From mchung at openjdk.org Thu Mar 9 17:39:18 2023 From: mchung at openjdk.org (Mandy Chung) Date: Thu, 9 Mar 2023 17:39:18 GMT Subject: RFR: 8294962: java.base jdk.internal.module package uses ASM to modify and write module-info.class In-Reply-To: References: Message-ID: On Fri, 25 Nov 2022 14:38:55 GMT, Adam Sotona wrote: > 8294962: java.base jdk.internal.module package uses ASM to modify and write module-info.class. > This patch converts it to use Classfile API. > > Please review. > Thanks, > Adam src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java line 37: > 35: import jdk.internal.classfile.Classfile; > 36: import jdk.internal.classfile.jdktypes.ModuleDesc; > 37: import jdk.internal.classfile.jdktypes.PackageDesc; I'm a bit surprised of `jdk.internal.classfile.jdktypes` package. ClassFile API is JDK-specific. Would `jdk.internal.classfile.constant` be more appropriate? src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java line 146: > 144: > 145: // packages > 146: md.packages().stream().map(PackageDesc::of).toList(), When writing `module_info.class` via ASM, it only visits the packages if there are packages that aren't exported or open. Does the ClassFile API add `ModulePackages` attribute only if there are packages that aren't exported or open? ------------- PR: https://git.openjdk.org/jdk/pull/11368 From asotona at openjdk.org Thu Mar 9 17:39:20 2023 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 9 Mar 2023 17:39:20 GMT Subject: RFR: 8294962: java.base jdk.internal.module package uses ASM to modify and write module-info.class In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 01:19:24 GMT, Mandy Chung wrote: >> 8294962: java.base jdk.internal.module package uses ASM to modify and write module-info.class. >> This patch converts it to use Classfile API. >> >> Please review. >> Thanks, >> Adam > > src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java line 37: > >> 35: import jdk.internal.classfile.Classfile; >> 36: import jdk.internal.classfile.jdktypes.ModuleDesc; >> 37: import jdk.internal.classfile.jdktypes.PackageDesc; > > I'm a bit surprised of `jdk.internal.classfile.jdktypes` package. ClassFile API is JDK-specific. Would `jdk.internal.classfile.constant` be more appropriate? `jdk.internal.classfile.jdktypes` package has been renamed to `jdk.internal.classfile.java.lang.constant` thanks for pointing it out > src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java line 146: > >> 144: >> 145: // packages >> 146: md.packages().stream().map(PackageDesc::of).toList(), > > When writing `module_info.class` via ASM, it only visits the packages if there are packages that aren't exported or open. > > Does the ClassFile API add `ModulePackages` attribute only if there are packages that aren't exported or open? Yes, `Classfile::buildModule` contains logic determining if emission of `ModulePackages` is required or not. ------------- PR: https://git.openjdk.org/jdk/pull/11368 From asotona at openjdk.org Thu Mar 9 17:41:26 2023 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 9 Mar 2023 17:41:26 GMT Subject: RFR: 8294974: jdk.jshell jdk.jshell.execution.LocalExecutionControl uses ASM to instrument classes Message-ID: 8294974: jdk.jshell jdk.jshell.execution.LocalExecutionControl uses ASM to instrument classes This patch converts it to use Classfile API. Please review. Thanks, Adam ------------- Commit messages: - Merge branch 'master' into JDK-8294974-jshell - Merge branch 'JDK-8294982' into JDK-8294974 - removed obsolete javadoc from implementation classes - minor fix in CodeBuilder and added test cases to LDCTest - EntryMap::nextPowerOfTwo delegates to Long:numberOfLeadingZeros - fixed CodeBuilder:constantInstruction for -0.0d and -0.0f values and added test - Merge branch 'master' into JDK-8294982 - fixed new lines at end of file - package jdk.internal.classfile.jdktypes moved to jdk.internal.classfile.java.lang.constant - fixed CodeRelabeler javadoc - ... and 182 more: https://git.openjdk.org/jdk/compare/cdcf5c1e...cfcfb077 Changes: https://git.openjdk.org/jdk/pull/11413/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11413&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294974 Stats: 54 lines in 2 files changed: 11 ins; 21 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/11413.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11413/head:pull/11413 PR: https://git.openjdk.org/jdk/pull/11413 From mchung at openjdk.org Thu Mar 9 17:41:36 2023 From: mchung at openjdk.org (Mandy Chung) Date: Thu, 9 Mar 2023 17:41:36 GMT Subject: RFR: 8294966: jdk.jartool sun.tools.jar.FingerPrint uses ASM to parse class jar entries In-Reply-To: References: Message-ID: On Thu, 15 Dec 2022 14:56:03 GMT, Adam Sotona wrote: > 8294966: jdk.jartool sun.tools.jar.FingerPrint uses ASM to parse class jar entries > This patch converts it to use Classfile API. > > Please review. > Thanks, > Adam src/jdk.jartool/share/classes/sun/tools/jar/FingerPrint.java line 42: > 40: import jdk.internal.classfile.FieldModel; > 41: import jdk.internal.classfile.MethodModel; > 42: import jdk.internal.classfile.attribute.EnclosingMethodAttribute; this import is unused. src/jdk.jartool/share/classes/sun/tools/jar/FingerPrint.java line 282: > 280: fields.add(new Field(fm.flags().flagsMask(), > 281: fm.fieldName().stringValue(), > 282: fm.fieldType().stringValue())); I find it more readable if the parameters to the Field constructor is aligned: Suggestion: fields.add(new Field(fm.flags().flagsMask(), fm.fieldName().stringValue(), fm.fieldType().stringValue())); src/jdk.jartool/share/classes/sun/tools/jar/FingerPrint.java line 313: > 311: @Override > 312: public void visitEnd() { > 313: this.nestedClass = this.outerClassName != null; `this.nestedClass` is updated after the attributes are visited. Suggest to rename `nestedClass` to `maybeNestedClass` and change `isNestedClass` to: public boolean isNestedClass() { return attrs.maybeNestedClass && attrs.outerClassName != null; } ------------- PR: https://git.openjdk.org/jdk/pull/11694 From asotona at openjdk.org Thu Mar 9 17:41:29 2023 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 9 Mar 2023 17:41:29 GMT Subject: RFR: 8294966: jdk.jartool sun.tools.jar.FingerPrint uses ASM to parse class jar entries Message-ID: 8294966: jdk.jartool sun.tools.jar.FingerPrint uses ASM to parse class jar entries This patch converts it to use Classfile API. Please review. Thanks, Adam ------------- Commit messages: - Merge branch 'master' into JDK-8294966-jartool - FingerPrint fixes - Update src/jdk.jartool/share/classes/sun/tools/jar/FingerPrint.java - Merge branch 'JDK-8294982' into JDK-8294966 - removed obsolete javadoc from implementation classes - minor fix in CodeBuilder and added test cases to LDCTest - EntryMap::nextPowerOfTwo delegates to Long:numberOfLeadingZeros - fixed CodeBuilder:constantInstruction for -0.0d and -0.0f values and added test - Merge branch 'master' into JDK-8294982 - fixed new lines at end of file - ... and 186 more: https://git.openjdk.org/jdk/compare/cdcf5c1e...3a835539 Changes: https://git.openjdk.org/jdk/pull/11694/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11694&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294966 Stats: 123 lines in 4 files changed: 49 ins; 40 del; 34 mod Patch: https://git.openjdk.org/jdk/pull/11694.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11694/head:pull/11694 PR: https://git.openjdk.org/jdk/pull/11694 From asotona at openjdk.org Thu Mar 9 17:41:37 2023 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 9 Mar 2023 17:41:37 GMT Subject: RFR: 8294966: jdk.jartool sun.tools.jar.FingerPrint uses ASM to parse class jar entries In-Reply-To: References: Message-ID: On Tue, 7 Mar 2023 20:47:31 GMT, Mandy Chung wrote: >> 8294966: jdk.jartool sun.tools.jar.FingerPrint uses ASM to parse class jar entries >> This patch converts it to use Classfile API. >> >> Please review. >> Thanks, >> Adam > > src/jdk.jartool/share/classes/sun/tools/jar/FingerPrint.java line 42: > >> 40: import jdk.internal.classfile.FieldModel; >> 41: import jdk.internal.classfile.MethodModel; >> 42: import jdk.internal.classfile.attribute.EnclosingMethodAttribute; > > this import is unused. fixed, thanks. > src/jdk.jartool/share/classes/sun/tools/jar/FingerPrint.java line 313: > >> 311: @Override >> 312: public void visitEnd() { >> 313: this.nestedClass = this.outerClassName != null; > > `this.nestedClass` is updated after the attributes are visited. Suggest to rename `nestedClass` to `maybeNestedClass` and change `isNestedClass` to: > > public boolean isNestedClass() { > return attrs.maybeNestedClass && attrs.outerClassName != null; > } I've changed `nestedClass` according to the suggestion, thanks. ------------- PR: https://git.openjdk.org/jdk/pull/11694 From mdoerr at openjdk.org Thu Mar 9 17:42:50 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Thu, 9 Mar 2023 17:42:50 GMT Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function & Memory API (Preview) [v3] In-Reply-To: References: <8b3vVrV22RuhdRoRYacXV0ZeghFGgKkC8S_z-iMrzAQ=.dd84b743-8b51-4281-8f5f-f9eff6207bc7@github.com> Message-ID: On Mon, 6 Mar 2023 16:38:37 GMT, Jorn Vernee wrote: >> @JornVernee: Thanks a lot for your detailed review! I have quite a few TODOs which include: >> - Include my tests for the HFA corner cases. >> - Try to improve handling of the overlapping registers as you suggested. >> - Check nesting of HFA. >> >> There will surely be more when looking into Big Endian support after merging with your recent work on https://github.com/openjdk/panama-foreign/compare/foreign-memaccess+abi...JornVernee:panama-foreign:OOB >> We should get rid of oversized accesses on PPC64, too. >> Thanks for sharing your plans to intrisify `linkToNative` in C2 later. I guess we should do more preparation work on all platforms when that gets addressed. > > @TheRealMDoerr I've moved the support for structs/unions that are not a power of 2 in size to this repo, so you should be able to merge the master branch to get it now. @JornVernee: Thanks! I've merged in your changes. TestArrayStructs is not yet completely working. I will need to investigate. I think I've done most other things you had requested. You may want to take a look at my recent commits. ------------- PR: https://git.openjdk.org/jdk/pull/12708 From asotona at openjdk.org Thu Mar 9 17:43:46 2023 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 9 Mar 2023 17:43:46 GMT Subject: RFR: 8294971: jdk.jlink jdk.tools.jimage.JImageTask is using ASM to verify classes Message-ID: <1GjpLK1GYB9V9T8Z_qtnDw0U3RyS7E6qDZtRll8WpKw=.1981b0de-9e62-4601-b895-f6dac301cec1@github.com> The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. ---------------------------------------------------------------------- jdk.jlink jdk.tools.jimage.JImageTask is using ASM to verify classes This patch converts ASM calls to Classfile API. Please review. Thanks, Adam ------------- Commit messages: - Merge branch 'master' into JDK-8294971-jlink-jimage - 8294971: jdk.jlink jdk.tools.jimage.JImageTask is using ASM to verify classes - removed obsolete javadoc from implementation classes - minor fix in CodeBuilder and added test cases to LDCTest - EntryMap::nextPowerOfTwo delegates to Long:numberOfLeadingZeros - fixed CodeBuilder:constantInstruction for -0.0d and -0.0f values and added test - Merge branch 'master' into JDK-8294982 - fixed new lines at end of file - package jdk.internal.classfile.jdktypes moved to jdk.internal.classfile.java.lang.constant - fixed CodeRelabeler javadoc - ... and 179 more: https://git.openjdk.org/jdk/compare/cdcf5c1e...68009406 Changes: https://git.openjdk.org/jdk/pull/12943/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12943&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294971 Stats: 15 lines in 2 files changed: 10 ins; 2 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/12943.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12943/head:pull/12943 PR: https://git.openjdk.org/jdk/pull/12943 From asotona at openjdk.org Thu Mar 9 17:45:15 2023 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 9 Mar 2023 17:45:15 GMT Subject: RFR: 8294972: jdk.jlink internal plugins are heavily using ASM Message-ID: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> jdk.jlink internal plugins are heavily using ASM This patch converts ASM calls to Classfile API. Please review. Thanks, Adam ------------- Commit messages: - Merge branch 'master' into JDK-8294972-jlink-plugins - renamed variables in SystemModulesPlugin - 8294972: jdk.jlink internal plugins are heavily using ASM - removed obsolete javadoc from implementation classes - minor fix in CodeBuilder and added test cases to LDCTest - EntryMap::nextPowerOfTwo delegates to Long:numberOfLeadingZeros - fixed CodeBuilder:constantInstruction for -0.0d and -0.0f values and added test - Merge branch 'master' into JDK-8294982 - fixed new lines at end of file - package jdk.internal.classfile.jdktypes moved to jdk.internal.classfile.java.lang.constant - ... and 180 more: https://git.openjdk.org/jdk/compare/cdcf5c1e...49c5bd59 Changes: https://git.openjdk.org/jdk/pull/12944/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12944&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294972 Stats: 1025 lines in 6 files changed: 215 ins; 300 del; 510 mod Patch: https://git.openjdk.org/jdk/pull/12944.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12944/head:pull/12944 PR: https://git.openjdk.org/jdk/pull/12944 From mchung at openjdk.org Thu Mar 9 17:55:55 2023 From: mchung at openjdk.org (Mandy Chung) Date: Thu, 9 Mar 2023 17:55:55 GMT Subject: RFR: 8294961: java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes [v5] In-Reply-To: References: Message-ID: On Thu, 9 Mar 2023 15:53:25 GMT, Adam Sotona wrote: >> java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes and this patch converts it to use Classfile API. >> >> Please review. >> >> Thank you, >> Adam > > Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 195 commits: > > - Merge branch 'master' into JDK-8294961-proxy > - Merge branch 'JDK-8294982' into JDK-8294961 > - removed obsolete javadoc from implementation classes > - minor fix in CodeBuilder and added test cases to LDCTest > - EntryMap::nextPowerOfTwo delegates to Long:numberOfLeadingZeros > - fixed CodeBuilder:constantInstruction for -0.0d and -0.0f values and added test > - Merge branch 'master' into JDK-8294982 > - fixed new lines at end of file > - package jdk.internal.classfile.jdktypes moved to jdk.internal.classfile.java.lang.constant > - fixed CodeRelabeler javadoc > - ... and 185 more: https://git.openjdk.org/jdk/compare/cdcf5c1e...48ac16f8 This change looks good. Have you compared the performance in generating dynamic proxies before and after? `test/micro/org/openjdk/bench/java/lang/reflect/Proxy/ProxyPerf.java` compares `ProxyGenerator` with `ProxyGenerator_v49` which was the old implementation before converting to ASM. You may consider leveraging this benchmark. ------------- PR: https://git.openjdk.org/jdk/pull/10991 From jlu at openjdk.org Thu Mar 9 17:59:26 2023 From: jlu at openjdk.org (Justin Lu) Date: Thu, 9 Mar 2023 17:59:26 GMT Subject: RFR: 8303853: Update ISO 3166 country codes table Message-ID: This PR incorporates all of the missing updates to ensure that `java.util.LocaleISOData.isoCountryTable` is on par with the official [ISO 3166 data](https://www.iso.org/obp/ui/#search/code/). ------------- Commit messages: - 2006-03-29 fix - 2007-09-21 fix - 2003-07-23 fix - 2013-02-06 update - 2012-08-02 update - 2012-02-15 update - 2011-11-08 update - 2011-08-09 update - 2011-06-12 update - 2010-02-22 update - ... and 1 more: https://git.openjdk.org/jdk/compare/f3abc406...a2be3546 Changes: https://git.openjdk.org/jdk/pull/12954/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12954&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303853 Stats: 15 lines in 1 file changed: 0 ins; 0 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/12954.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12954/head:pull/12954 PR: https://git.openjdk.org/jdk/pull/12954 From mchung at openjdk.org Thu Mar 9 18:02:55 2023 From: mchung at openjdk.org (Mandy Chung) Date: Thu, 9 Mar 2023 18:02:55 GMT Subject: RFR: 8294962: java.base jdk.internal.module package uses ASM to modify and write module-info.class In-Reply-To: References: Message-ID: On Thu, 9 Mar 2023 10:59:25 GMT, Adam Sotona wrote: >> src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java line 146: >> >>> 144: >>> 145: // packages >>> 146: md.packages().stream().map(PackageDesc::of).toList(), >> >> When writing `module_info.class` via ASM, it only visits the packages if there are packages that aren't exported or open. >> >> Does the ClassFile API add `ModulePackages` attribute only if there are packages that aren't exported or open? > > Yes, `Classfile::buildModule` contains logic determining if emission of `ModulePackages` is required or not. It'd be helpful to add a comment that `ModulePackages` attribute is only emitted if there are packages that aren't exported or open. ------------- PR: https://git.openjdk.org/jdk/pull/11368 From mchung at openjdk.org Thu Mar 9 18:10:59 2023 From: mchung at openjdk.org (Mandy Chung) Date: Thu, 9 Mar 2023 18:10:59 GMT Subject: RFR: 8294959: java.base java.lang.Module uses ASM to load module-info.class In-Reply-To: <5_kDTDkNw-ARy8ZmSqn_LOQw5lt-0WqKeHNdGWIBPHs=.ae41b748-0ca7-4492-9fcf-a0682576bc29@github.com> References: <5_kDTDkNw-ARy8ZmSqn_LOQw5lt-0WqKeHNdGWIBPHs=.ae41b748-0ca7-4492-9fcf-a0682576bc29@github.com> Message-ID: On Fri, 25 Nov 2022 14:35:22 GMT, Adam Sotona wrote: > java.base java.lang.Module uses ASM to load module-info.class and this patch converts it to use Classfile API. LGTM ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.org/jdk/pull/11367 From mchung at openjdk.org Thu Mar 9 18:15:37 2023 From: mchung at openjdk.org (Mandy Chung) Date: Thu, 9 Mar 2023 18:15:37 GMT Subject: RFR: 8294971: jdk.jlink jdk.tools.jimage.JImageTask is using ASM to verify classes In-Reply-To: <1GjpLK1GYB9V9T8Z_qtnDw0U3RyS7E6qDZtRll8WpKw=.1981b0de-9e62-4601-b895-f6dac301cec1@github.com> References: <1GjpLK1GYB9V9T8Z_qtnDw0U3RyS7E6qDZtRll8WpKw=.1981b0de-9e62-4601-b895-f6dac301cec1@github.com> Message-ID: On Thu, 9 Mar 2023 11:33:13 GMT, Adam Sotona wrote: > jdk.jlink jdk.tools.jimage.JImageTask is using ASM to verify classes > > This patch converts ASM calls to Classfile API. > > Please review. > > Thanks, > Adam I wonder if it's worth to provide a convenient method to verify a classfile by visiting all model elements in the future. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.org/jdk/pull/12943 From naoto at openjdk.org Thu Mar 9 18:15:41 2023 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 9 Mar 2023 18:15:41 GMT Subject: RFR: 8303814: getLastErrorString should avoid charset conversions In-Reply-To: References: Message-ID: On Wed, 8 Mar 2023 11:30:27 GMT, Daniel Jeli?ski wrote: > This patch modifies the `getLastErrorString` method to return a `jstring`. Thanks to that we can avoid unnecessary back and forth conversions between Unicode and other charsets on Windows. > > Other changes include: > - the Windows implementation of `getLastErrorString` no longer checks `errno`. I verified all uses of the method and confirmed that `errno` is not used anywhere. > - While at it, I found and fixed a few calls to `JNU_ThrowIOExceptionWithLastError` that were done in context where `LastError` was not set. > - jdk.hotspot.agent was modified to use `JNU_ThrowByNameWithLastError` and `JNU_ThrowByName` instead of `getLastErrorString`; the code is expected to have identical behavior. > - zip_util was modified to return static messages instead of generated ones. The generated messages were not observed anywhere, because they were replaced by a static message in ZIP_Open, which is the only method used by other native code. > - `getLastErrorString` is no longer exported by libjava. > > Tier1-3 tests continue to pass. > > No new automated regression test; testing this requires installing a language pack that cannot be displayed in the current code page. > Tested this manually by installing Chinese language pack on English Windows 11, selecting Chinese language, then checking if the message on exception thrown by `InetAddress.getByName("nonexistent.local");` starts with `"?????????"` (or `"\u4e0d\u77e5\u9053\u8fd9\u6837\u7684\u4e3b\u673a\u3002"`). Without the change, the exception message started with a row of question marks. Looks good (w/ some minor comments) src/java.base/share/native/libzip/zip_util.c line 767: > 765: * or NULL if an error occurred. If a zip error occurred then *pmsg will > 766: * be set to the error message text if pmsg != 0. Otherwise, *pmsg will be > 767: * set to NULL. Caller doesn't need to free the error message. I'd put some more context here why the caller does not need to free. (as it is a static text) src/java.base/windows/native/libjava/jni_util_md.c line 80: > 78: 0, > 79: buf, > 80: sizeof(buf) / sizeof(WCHAR), Maybe better to #define the size 256 so that this division is not needed. src/java.base/windows/native/libnio/ch/FileDispatcherImpl.c line 208: > 206: > 207: if (result == 0) { > 208: JNU_ThrowIOExceptionWithLastError(env, "Write failed"); Could be replaced with `JNU_ThrowIOException`? src/java.base/windows/native/libnio/ch/FileDispatcherImpl.c line 260: > 258: > 259: if (result == 0) { > 260: JNU_ThrowIOExceptionWithLastError(env, "Write failed"); Same as above src/java.base/windows/native/libnio/ch/FileDispatcherImpl.c line 299: > 297: > 298: if (result == 0) { > 299: JNU_ThrowIOExceptionWithLastError(env, "Write failed"); Same here ------------- PR: https://git.openjdk.org/jdk/pull/12922 From asotona at openjdk.org Thu Mar 9 18:16:56 2023 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 9 Mar 2023 18:16:56 GMT Subject: Integrated: 8294959: java.base java.lang.Module uses ASM to load module-info.class In-Reply-To: <5_kDTDkNw-ARy8ZmSqn_LOQw5lt-0WqKeHNdGWIBPHs=.ae41b748-0ca7-4492-9fcf-a0682576bc29@github.com> References: <5_kDTDkNw-ARy8ZmSqn_LOQw5lt-0WqKeHNdGWIBPHs=.ae41b748-0ca7-4492-9fcf-a0682576bc29@github.com> Message-ID: On Fri, 25 Nov 2022 14:35:22 GMT, Adam Sotona wrote: > java.base java.lang.Module uses ASM to load module-info.class and this patch converts it to use Classfile API. This pull request has now been integrated. Changeset: 595645c7 Author: Adam Sotona URL: https://git.openjdk.org/jdk/commit/595645c76d09b0c30da7fa7d8435ca960c8e3268 Stats: 54 lines in 1 file changed: 8 ins; 37 del; 9 mod 8294959: java.base java.lang.Module uses ASM to load module-info.class Reviewed-by: mchung ------------- PR: https://git.openjdk.org/jdk/pull/11367 From asotona at openjdk.org Thu Mar 9 18:21:17 2023 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 9 Mar 2023 18:21:17 GMT Subject: RFR: 8294971: jdk.jlink jdk.tools.jimage.JImageTask is using ASM to verify classes In-Reply-To: <1GjpLK1GYB9V9T8Z_qtnDw0U3RyS7E6qDZtRll8WpKw=.1981b0de-9e62-4601-b895-f6dac301cec1@github.com> References: <1GjpLK1GYB9V9T8Z_qtnDw0U3RyS7E6qDZtRll8WpKw=.1981b0de-9e62-4601-b895-f6dac301cec1@github.com> Message-ID: <1mELCWSN3beSqB8XhzDq_zDa8o3_rTRP2fR9ISszgIk=.2b7edb62-5bd3-4333-8946-db59c0221893@github.com> The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. ---------------------------------------------------------------------- On Thu, 9 Mar 2023 11:33:13 GMT, Adam Sotona wrote: > jdk.jlink jdk.tools.jimage.JImageTask is using ASM to verify classes > > This patch converts ASM calls to Classfile API. > > Please review. > > Thanks, > Adam Provided code only reflect original verification by parsing the class content. It is now possible to extend the verification by utilizing Classfile API bytecode verification. However it would require to provide appropriate class hierarchy resolution for stack map table verification. ------------- PR: https://git.openjdk.org/jdk/pull/12943 From mchung at openjdk.org Thu Mar 9 18:23:12 2023 From: mchung at openjdk.org (Mandy Chung) Date: Thu, 9 Mar 2023 18:23:12 GMT Subject: RFR: 8294966: jdk.jartool sun.tools.jar.FingerPrint uses ASM to parse class jar entries In-Reply-To: References: Message-ID: On Thu, 15 Dec 2022 14:56:03 GMT, Adam Sotona wrote: > 8294966: jdk.jartool sun.tools.jar.FingerPrint uses ASM to parse class jar entries > This patch converts it to use Classfile API. > > Please review. > Thanks, > Adam make/modules/jdk.jartool/Java.gmk line 28: > 26: DISABLED_WARNINGS_java += missing-explicit-ctor > 27: JAVAC_FLAGS += -XDstringConcat=inline > 28: JAVAC_FLAGS += --enable-preview This change is no longer needed. It's not a preview API. src/java.base/share/classes/module-info.java line 155: > 153: jdk.incubator.concurrent, // participates in preview features > 154: jdk.incubator.vector, // participates in preview features > 155: jdk.jartool, // participates in preview features This is no longer needed. src/jdk.jartool/share/classes/module-info.java line 52: > 50: * @since 9 > 51: */ > 52: @ParticipatesInPreview Same here. No needed. src/jdk.jartool/share/classes/sun/tools/jar/FingerPrint.java line 252: > 250: private final int access; > 251: private final boolean publicClass; > 252: private boolean maybeNestedClass; should be final since this is no longer updated. ------------- PR: https://git.openjdk.org/jdk/pull/11694 From naoto at openjdk.org Thu Mar 9 18:28:54 2023 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 9 Mar 2023 18:28:54 GMT Subject: RFR: 8303853: Update ISO 3166 country codes table In-Reply-To: References: Message-ID: On Thu, 9 Mar 2023 17:50:32 GMT, Justin Lu wrote: > This PR incorporates all of the missing updates to ensure that `java.util.LocaleISOData.isoCountryTable` is on par with the official [ISO 3166 data](https://www.iso.org/obp/ui/#search/code/). Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12954 From mchung at openjdk.org Thu Mar 9 18:45:26 2023 From: mchung at openjdk.org (Mandy Chung) Date: Thu, 9 Mar 2023 18:45:26 GMT Subject: RFR: 8294962: java.base jdk.internal.module package uses ASM to modify and write module-info.class In-Reply-To: References: Message-ID: On Fri, 25 Nov 2022 14:38:55 GMT, Adam Sotona wrote: > 8294962: java.base jdk.internal.module package uses ASM to modify and write module-info.class. > This patch converts it to use Classfile API. > > Please review. > Thanks, > Adam src/java.base/share/classes/jdk/internal/module/ModuleInfoExtender.java line 165: > 163: List packageNames = packages.stream() > 164: .sorted() > 165: .map(s -> PackageDesc.of(s)) Suggestion: .map(PackageDesc::of) src/java.base/share/classes/jdk/internal/module/ModuleInfoExtender.java line 170: > 168: } > 169: > 170: // add ModuleTarget, ModuleResolution and ModuleHashes attributes This adds or replaces if the attribute exists. Perhaps just drop "add" from the comment? src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java line 138: > 136: for (ModuleDescriptor.Provides p : md.provides()) { > 137: mb.provides(ClassDesc.of(p.service()), > 138: p.providers() Formatting nit: align `p.providers()` with the first parameter to `mb.provides` - a little confusing with current indentation. ------------- PR: https://git.openjdk.org/jdk/pull/11368 From duke at openjdk.org Thu Mar 9 19:44:43 2023 From: duke at openjdk.org (liach) Date: Thu, 9 Mar 2023 19:44:43 GMT Subject: RFR: 8294962: java.base jdk.internal.module package uses ASM to modify and write module-info.class In-Reply-To: References: Message-ID: On Fri, 25 Nov 2022 14:38:55 GMT, Adam Sotona wrote: > 8294962: java.base jdk.internal.module package uses ASM to modify and write module-info.class. > This patch converts it to use Classfile API. > > Please review. > Thanks, > Adam src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java line 89: > 87: > 88: int moduleFlags = md.modifiers().stream() > 89: .map(MODULE_MODS_TO_FLAGS::get) The `MODULE_MODS_TO_FLAGS` can be reused in `modifiersToFlags`. Otherwise, it's useless and can be removed. ------------- PR: https://git.openjdk.org/jdk/pull/11368 From brian.goetz at oracle.com Thu Mar 9 19:45:00 2023 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 9 Mar 2023 14:45:00 -0500 Subject: RFR: 8294961: java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes [v2] In-Reply-To: References: Message-ID: <9870e234-42f2-0007-b34c-523596f6b5ac@oracle.com> > src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 390: > >> 388: uniqueList.add(ex); >> 389: } >> 390: return uniqueList.stream().map(ex -> ClassDesc.ofDescriptor(ex.descriptorString())).toList(); > It would be useful to add a helper method to convert Class to ClassDesc: > > private static ClassDesc toClassDesc(Class type) { > return ClassDesc.ofDescriptor(type.descriptorString()); > } I would love it if we could have this as a factory on ClassDesc itself.? We'd have to filter VMAC/hidden classes (and any other classes that can't be resolved symbolically), probably by returning Optional instead of ClassDesc. From rriggs at openjdk.org Thu Mar 9 19:53:07 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 9 Mar 2023 19:53:07 GMT Subject: RFR: 8303392: Runtime.exec and ProcessBuilder.start should use System logger [v3] In-Reply-To: <-1i11ZrHHgzUbCSa_RXAcGKNfgtpdui--bltZ4Ujs2A=.f5f1a7e2-d3ec-4f64-9b1e-317ef2f24ef1@github.com> References: <-1i11ZrHHgzUbCSa_RXAcGKNfgtpdui--bltZ4Ujs2A=.f5f1a7e2-d3ec-4f64-9b1e-317ef2f24ef1@github.com> Message-ID: > Runtime.exec and ProcessBuilder.start methods create a new operating system process with the program and arguments. Many applications configure a logging subsystem to monitor application events. Logging a process start message with the program, arguments, and stack trace can identify the caller and purpose. > Logging the process start event is complementary to the process start event generated for JFR (Java Flight Recorder). Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Revise logging of ProcessBuilder.start to support DEBUG and TRACE logging. Revise the implNote to include a warning about logging security sensistive information. DEBUG logs only the command, directory, stack trace, and pid. TRACE additionally logs arguments. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12862/files - new: https://git.openjdk.org/jdk/pull/12862/files/3013ca0e..0f172bab Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12862&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12862&range=01-02 Stats: 75 lines in 3 files changed: 44 ins; 1 del; 30 mod Patch: https://git.openjdk.org/jdk/pull/12862.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12862/head:pull/12862 PR: https://git.openjdk.org/jdk/pull/12862 From emcmanus at openjdk.org Thu Mar 9 19:59:34 2023 From: emcmanus at openjdk.org (Eamonn McManus) Date: Thu, 9 Mar 2023 19:59:34 GMT Subject: RFR: 8303919: Instant.ofEpochMilli says it can throw an exception that it can't Message-ID: Instant.ofEpochMilli says this: @throws DateTimeException if the instant exceeds the maximum or minimum instant But that can't happen. Even given `Long.MIN_VALUE` or `Long.MAX_VALUE` it does not throw. That's already implicitly tested in [`TestInstant`](https://github.com/openjdk/jdk/blob/a9dba565688a29bef8626488c47519008dcadbe8/test/jdk/java/time/test/java/time/TestInstant.java#L84), which calls it with both those values. ------------- Commit messages: - 8303919: Instant.ofEpochMilli javadoc bug Changes: https://git.openjdk.org/jdk/pull/12958/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12958&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303919 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12958.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12958/head:pull/12958 PR: https://git.openjdk.org/jdk/pull/12958 From duke at openjdk.org Thu Mar 9 20:08:28 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Thu, 9 Mar 2023 20:08:28 GMT Subject: RFR: 8303920: Avoid calling out to python in DataDescriptorSignatureMissing test Message-ID: The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. ---------------------------------------------------------------------- Please review this PR which brings the DataDescriptorSignatureMissing test back to life. This test currently calls out to Python to create a test vector ZIP with a Data Descriptor without the recommended but optional signature. The Python dependency has turned out to be very brittle, so the test is currently marked with `@ignore` The PR replaces Python callouts with directly creating the test vector ZIP in the test itself. We can then remove the `@ignore`tag and run this useful test automatically. ------------- Commit messages: - Update copyright years - Add method comments - Instead of calling out to python, create a ZIP file and remove the data descriptor signature. Changes: https://git.openjdk.org/jdk/pull/12959/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12959&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303920 Stats: 123 lines in 1 file changed: 22 ins; 66 del; 35 mod Patch: https://git.openjdk.org/jdk/pull/12959.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12959/head:pull/12959 PR: https://git.openjdk.org/jdk/pull/12959 From duke at openjdk.org Thu Mar 9 20:18:22 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Thu, 9 Mar 2023 20:18:22 GMT Subject: RFR: 8303922: build-test-lib target is broken Message-ID: The Make target 'build-test-lib-target' is broken in a few ways: - make/test/BuildTestLib.gmk references the directory $(TEST_LIB_SOURCE_DIR)/sun which does not seem to exist. This can be fixed by removing the reference. - Some test-lib sources use preview-features which is not enabled by make/test/BuildTestLib.gmk. This is fixed by adding a JAVAC_FLAGS with --enable-preview and also adding 'preview' to DISABLED_WARNINGS - ASN1Formatter.annotate has a possible lossy conversion from long to int which can be fixed by adding an explicit cast This PR fixes the above issues. ------------- Commit messages: - Update copyright years - Some test-lib sources use preview features, add --enable-preview to JAVAC_FLAGS and add "preview" as a DISABLED_WARNING - The directory $(TEST_LIB_SOURCE_DIR)/sun no longer seems to exist, remove it from SRC - Fix possible lossy conversion by adding and explicit cast Changes: https://git.openjdk.org/jdk/pull/12960/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12960&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303922 Stats: 8 lines in 2 files changed: 2 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/12960.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12960/head:pull/12960 PR: https://git.openjdk.org/jdk/pull/12960 From rriggs at openjdk.org Thu Mar 9 20:37:12 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 9 Mar 2023 20:37:12 GMT Subject: RFR: 8303485: Replacing os.name for operating system customization In-Reply-To: References: Message-ID: <7voiMwRt_RGy9VBQYRrC2sJdL8AtNcmnrhLfrljUgqM=.462df750-150c-4bef-8da0-c31a7c199058@github.com> On Wed, 8 Mar 2023 23:23:38 GMT, Mandy Chung wrote: > I wonder if `jdk.internal.platform` would be a better home for `OperatingSystem` class? jdk.internal.platform seems to be focused on information about container environments such as Docker. jdk.internal.misc already contains other classes that are shared out of java.base to other modules. ------------- PR: https://git.openjdk.org/jdk/pull/12931 From rriggs at openjdk.org Thu Mar 9 20:37:13 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 9 Mar 2023 20:37:13 GMT Subject: RFR: 8303485: Replacing os.name for operating system customization In-Reply-To: References: Message-ID: On Wed, 8 Mar 2023 19:15:16 GMT, Roger Riggs wrote: > Improvements to support OS specific customization for JDK internal use: > - To select values and code; allowing elimination of unused code and values > - Optionally evaluated by build processes, compilation, or archiving (i.e. CDS) > - Simple API to replace adhoc comparisons with `os.name` > - Clear and consistent use across build, runtime, and JDK modules > > The PR includes updates within java.base to use the new API. To see the knock-on effects of using the API in other modules, see the Draft PR #12961 ------------- PR: https://git.openjdk.org/jdk/pull/12931 From rriggs at openjdk.org Thu Mar 9 20:42:17 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 9 Mar 2023 20:42:17 GMT Subject: RFR: 8303392: Runtime.exec and ProcessBuilder.start should use System logger [v2] In-Reply-To: <-PHwf09-m1XajVZo9TpIbaJfM0duZ3PVQfINW6gtEvs=.bab3ee00-a561-4207-ac19-1f2abf8a5f6c@github.com> References: <-1i11ZrHHgzUbCSa_RXAcGKNfgtpdui--bltZ4Ujs2A=.f5f1a7e2-d3ec-4f64-9b1e-317ef2f24ef1@github.com> <-PHwf09-m1XajVZo9TpIbaJfM0duZ3PVQfINW6gtEvs=.bab3ee00-a561-4207-ac19-1f2abf8a5f6c@github.com> Message-ID: On Sun, 5 Mar 2023 06:14:49 GMT, Thomas Stuefe wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Add javadoc @implNote to Runtime.exec and ProcessBuilder methods > > Hi Roger, > > I think to be even more useful it could make sense to print the current directory the child is started in as well as the env var array, possibly only with a finer logging level. > > Cheers, Thomas @tstuefe > I think to be even more useful it could make sense to print the current directory the child is started in as well as the env var array, possibly only with a finer logging level. The environment is potentially bulky and may also contain sensitive information. It is unlikely to change betwen calls to PB.start() so it doesn't add much to log it. The logging should focus on the context and arguments of each call. ------------- PR: https://git.openjdk.org/jdk/pull/12862 From stuefe at openjdk.org Thu Mar 9 20:48:37 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 9 Mar 2023 20:48:37 GMT Subject: RFR: 8303392: Runtime.exec and ProcessBuilder.start should use System logger [v3] In-Reply-To: References: <-1i11ZrHHgzUbCSa_RXAcGKNfgtpdui--bltZ4Ujs2A=.f5f1a7e2-d3ec-4f64-9b1e-317ef2f24ef1@github.com> Message-ID: On Thu, 9 Mar 2023 19:53:07 GMT, Roger Riggs wrote: >> Runtime.exec and ProcessBuilder.start methods create a new operating system process with the program and arguments. Many applications configure a logging subsystem to monitor application events. Logging a process start message with the program, arguments, and stack trace can identify the caller and purpose. >> Logging the process start event is complementary to the process start event generated for JFR (Java Flight Recorder). > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Revise logging of ProcessBuilder.start to support DEBUG and TRACE logging. > Revise the implNote to include a warning about logging security sensistive information. > DEBUG logs only the command, directory, stack trace, and pid. > TRACE additionally logs arguments. LGTM. This looks really useful. We had a similar trace at SAP, a bit more involved (with env vars), and solved a lot of issues quickly with it. Small nits remain, up to you if you take my suggestions. src/java.base/share/classes/java/lang/ProcessBuilder.java line 1155: > 1153: "cmd: " + cmdargs + > 1154: ", dir: " + dir + > 1155: ", pid: " + process.pid(), It may make sense to revert the printout order, print pid first, cwd second, then the args, since argument vectors can get very large. Does Logger limit the line length? Furthermore - but up to you - when I do printouts like this I always enclose the command args in quotes. That helps people analyze situations like accidental trailing spaces in arguments. Pity that we cannot show at least PATH and LD_LIBRARY_PATH/LIBPATH. test/jdk/java/lang/ProcessBuilder/ProcessStartLoggingTest.java line 81: > 79: File nullDirectory = null; > 80: File thisDirectory = new File("."); > 81: I started to heavily use different `@test` sections with speaking names instead of running a bunch of test in sequence; the advantage is better parallelization of tests, that I can omit printing out the test name manually (if the test name itself is speaking), and the ability to start individual tests manually. It does come with lots of test sections though. ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.org/jdk/pull/12862 From rriggs at openjdk.org Thu Mar 9 21:07:15 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 9 Mar 2023 21:07:15 GMT Subject: RFR: 8303919: Instant.ofEpochMilli says it can throw an exception that it can't In-Reply-To: References: Message-ID: On Thu, 9 Mar 2023 19:49:29 GMT, Eamonn McManus wrote: > Instant.ofEpochMilli says this: > > > @throws DateTimeException if the instant exceeds the maximum or minimum instant > > > But that can't happen. Even given `Long.MIN_VALUE` or `Long.MAX_VALUE` it does not throw. That's already implicitly tested in [`TestInstant`](https://github.com/openjdk/jdk/blob/a9dba565688a29bef8626488c47519008dcadbe8/test/jdk/java/time/test/java/time/TestInstant.java#L84), which calls it with both those values. You're picking on a fine point here that is data dependent, and there's not much value in changing it. Also, since the spec of `ofEpochMilli` is changing it will need a CSR. ------------- PR: https://git.openjdk.org/jdk/pull/12958 From mr at openjdk.org Thu Mar 9 21:13:11 2023 From: mr at openjdk.org (Mark Reinhold) Date: Thu, 9 Mar 2023 21:13:11 GMT Subject: RFR: 8294962: java.base jdk.internal.module package uses ASM to modify and write module-info.class In-Reply-To: References: Message-ID: On Fri, 25 Nov 2022 14:38:55 GMT, Adam Sotona wrote: > 8294962: java.base jdk.internal.module package uses ASM to modify and write module-info.class. > This patch converts it to use Classfile API. > > Please review. > Thanks, > Adam Wouldn?t ?Convert java.base/jdk.internal.module to use the Classfile API? be a better issue title? (Similarly for similar issues.) Focus on the positive ... ------------- PR: https://git.openjdk.org/jdk/pull/11368 From emcmanus at openjdk.org Thu Mar 9 21:26:46 2023 From: emcmanus at openjdk.org (Eamonn McManus) Date: Thu, 9 Mar 2023 21:26:46 GMT Subject: RFR: 8303919: Instant.ofEpochMilli says it can throw an exception that it can't In-Reply-To: References: Message-ID: On Thu, 9 Mar 2023 21:03:38 GMT, Roger Riggs wrote: > You're picking on a fine point here that is data dependent, and there's not much value in changing it. Could you elaborate on this a bit? The way I see it, the argument to `ofEpochMillis` is a `long` with the same meaning as `System.currentTimeMillis()` and the like. Every `long` value is valid, but the current spec implies otherwise. That means that people may waste their time trying to handle the documented exception even though it can never happen. ------------- PR: https://git.openjdk.org/jdk/pull/12958 From liangchenblue at gmail.com Thu Mar 9 21:38:09 2023 From: liangchenblue at gmail.com (-) Date: Thu, 9 Mar 2023 15:38:09 -0600 Subject: RFR: 8294961: java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes [v2] In-Reply-To: <9870e234-42f2-0007-b34c-523596f6b5ac@oracle.com> References: <9870e234-42f2-0007-b34c-523596f6b5ac@oracle.com> Message-ID: We can already accomplish that with type.describeConstable().orElseThrow(); and we can replace all map(ProxyGenerator::toClassDesc) calls with map(Class::describeConstable).map(Optional::orElseThrow) instead. On Thu, Mar 9, 2023 at 1:45?PM Brian Goetz wrote: > > > > src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 390: > > > >> 388: uniqueList.add(ex); > >> 389: } > >> 390: return uniqueList.stream().map(ex -> ClassDesc.ofDescriptor(ex.descriptorString())).toList(); > > It would be useful to add a helper method to convert Class to ClassDesc: > > > > private static ClassDesc toClassDesc(Class type) { > > return ClassDesc.ofDescriptor(type.descriptorString()); > > } > > I would love it if we could have this as a factory on ClassDesc itself. > We'd have to filter VMAC/hidden classes (and any other classes that > can't be resolved symbolically), probably by returning > Optional instead of ClassDesc. > > From uschindler at openjdk.org Thu Mar 9 22:09:24 2023 From: uschindler at openjdk.org (Uwe Schindler) Date: Thu, 9 Mar 2023 22:09:24 GMT Subject: RFR: 8294962: java.base jdk.internal.module package uses ASM to modify and write module-info.class In-Reply-To: References: Message-ID: On Fri, 25 Nov 2022 14:38:55 GMT, Adam Sotona wrote: > 8294962: java.base jdk.internal.module package uses ASM to modify and write module-info.class. > This patch converts it to use Classfile API. > > Please review. > Thanks, > Adam src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java line 140: > 138: p.providers() > 139: .stream() > 140: .map(pn -> ClassDesc.of(pn)) Change to: `.map(ClassDesc::of)` ------------- PR: https://git.openjdk.org/jdk/pull/11368 From rriggs at openjdk.org Thu Mar 9 22:10:12 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 9 Mar 2023 22:10:12 GMT Subject: RFR: 8303919: Instant.ofEpochMilli says it can throw an exception that it can't In-Reply-To: References: Message-ID: On Thu, 9 Mar 2023 19:49:29 GMT, Eamonn McManus wrote: > Instant.ofEpochMilli says this: > > > @throws DateTimeException if the instant exceeds the maximum or minimum instant > > > But that can't happen. Even given `Long.MIN_VALUE` or `Long.MAX_VALUE` it does not throw. That's already implicitly tested in [`TestInstant`](https://github.com/openjdk/jdk/blob/a9dba565688a29bef8626488c47519008dcadbe8/test/jdk/java/time/test/java/time/TestInstant.java#L84), which calls it with both those values. I see your point, but no one has stumbled into/over it before. Rationalizing here... The presence of the exception is a reminder that there are values of epoch milliseconds that `Instant` can not represent. It is also the case that `long` cannot represent them either. For example `Instant.MIN.toEpochMilli()` throws and the method `Instant.ofEpochSecond(sec, nanos)` throws with Long.MIN_VALUE and Long.MAX_VALUE. ------------- PR: https://git.openjdk.org/jdk/pull/12958 From mchung at openjdk.org Thu Mar 9 22:55:22 2023 From: mchung at openjdk.org (Mandy Chung) Date: Thu, 9 Mar 2023 22:55:22 GMT Subject: RFR: 8294972: jdk.jlink internal plugins are heavily using ASM In-Reply-To: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> Message-ID: On Thu, 9 Mar 2023 11:35:32 GMT, Adam Sotona wrote: > jdk.jlink internal plugins are heavily using ASM > > This patch converts ASM calls to Classfile API. > > Please review. > Thanks, > Adam Looks good in general. src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/IncludeLocalesPlugin.java line 273: > 271: boolean modified = false; > 272: // I haven't found a way how to change content of existing CP entries or get entry offset to the byteocde array using Bytecode lib > 273: // so scanning CP entries directly What about: Suggestion: // scan CP entries directly to read the bytes of UTF8 entries and // patch in place with unsupported locale tags stripped src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 619: > 617: "", > 618: MethodTypeDesc.of(CD_void), > 619: false); nit: extra space sorry this might be from the patch I sent you. src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 1644: > 1642: CD_SYSTEM_MODULES_MAP, > 1643: clb -> { > 1644: clb.withFlags(ACC_FINAL+ACC_SUPER); Nit: consistent with line 578 with a space before and after `+` ------------- PR: https://git.openjdk.org/jdk/pull/12944 From duke at openjdk.org Thu Mar 9 23:12:49 2023 From: duke at openjdk.org (liach) Date: Thu, 9 Mar 2023 23:12:49 GMT Subject: RFR: 8303930: Fix ConstantUtils.skipOverFieldSignature void case return value Message-ID: This typo doesn't allow creation of malformed ClassDesc or MethodTypeDesc, but it produces an erroneous exception on certain inputs. Running `java.lang.constant.MethodTypeDesc.ofDescriptor("(IIIII[[[V)I")` in Jshell 19.0.2 throws StringIndexOutOfBoundsException, and throws IllegalArgumentException in the Jshell for this patch. ------------- Commit messages: - 8303930: Fix ConstantUtils.skipOverFieldSignature void case return value Changes: https://git.openjdk.org/jdk/pull/12964/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12964&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303930 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12964.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12964/head:pull/12964 PR: https://git.openjdk.org/jdk/pull/12964 From rriggs at openjdk.org Fri Mar 10 00:01:51 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 10 Mar 2023 00:01:51 GMT Subject: RFR: 8303392: Runtime.exec and ProcessBuilder.start should use System logger [v4] In-Reply-To: <-1i11ZrHHgzUbCSa_RXAcGKNfgtpdui--bltZ4Ujs2A=.f5f1a7e2-d3ec-4f64-9b1e-317ef2f24ef1@github.com> References: <-1i11ZrHHgzUbCSa_RXAcGKNfgtpdui--bltZ4Ujs2A=.f5f1a7e2-d3ec-4f64-9b1e-317ef2f24ef1@github.com> Message-ID: > Runtime.exec and ProcessBuilder.start methods create a new operating system process with the program and arguments. Many applications configure a logging subsystem to monitor application events. Logging a process start message with the program, arguments, and stack trace can identify the caller and purpose. > Logging the process start event is complementary to the process start event generated for JFR (Java Flight Recorder). Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Reorder pid, directory, args in logged message. Cleanup argument lists in tests. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12862/files - new: https://git.openjdk.org/jdk/pull/12862/files/0f172bab..0a5b1901 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12862&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12862&range=02-03 Stats: 31 lines in 2 files changed: 3 ins; 3 del; 25 mod Patch: https://git.openjdk.org/jdk/pull/12862.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12862/head:pull/12862 PR: https://git.openjdk.org/jdk/pull/12862 From liangchenblue at gmail.com Fri Mar 10 00:10:46 2023 From: liangchenblue at gmail.com (-) Date: Thu, 9 Mar 2023 18:10:46 -0600 Subject: DirectMethodHandleDesc for MethodHandles.classData/classDataAt Message-ID: Hello, I request the addition of 2 common DirectMethodHandleDesc constants, for the bootstrap methods MethodHandles::classData and MethodHandles::classDataAt, in ConstantDescs. Since class data is almost exclusively accessed by generated bytecode only, having their condy bootstrap method available would be convenient to users when the Classfile API is publicly available. For instance, in JDK, there are already 2 places (InnerClassLambdaMetafactory, BindingSpecializer) where classData is used as a bootstrap method for condys, and they will be migrating to Classfile API soon. Is this proposal feasible? If yes, I am more than glad to submit a changeset adding these 2 constants. Chen Liang From jcking at openjdk.org Fri Mar 10 00:12:05 2023 From: jcking at openjdk.org (Justin King) Date: Fri, 10 Mar 2023 00:12:05 GMT Subject: RFR: 8303485: Replacing os.name for operating system customization In-Reply-To: References: Message-ID: <-t6DHZsHknyq9__b5jUjWL9KcBbJJE3P4SDO_W56cMo=.aca1b85e-63f9-44f6-bf32-9bfc7d94e5a4@github.com> On Thu, 9 Mar 2023 16:11:19 GMT, Roger Riggs wrote: > > Has this totally killed of BSD support on the JDK side? I thought building non-macOS BSD was still viable, but perhaps not - certainly not after this change. > > I haven't found any use of BSD and I don't think the build supports a BSD build. It looks like FreeBSD and NetBSD have their own separate ports. They fork the OpenJDK repos and then add changes on-top to make it work for BSD. That is kind of disappointing...one more thing for them to patch I suppose. I wonder how big the diff is...it looks like github.com/battleblow/jdk19u is what FreeBSD uses. ------------- PR: https://git.openjdk.org/jdk/pull/12931 From duke at openjdk.org Fri Mar 10 00:34:20 2023 From: duke at openjdk.org (Viktor Klang) Date: Fri, 10 Mar 2023 00:34:20 GMT Subject: Integrated: JDK-8302360 Atomic*.compareAndExchange Javadoc unclear In-Reply-To: References: Message-ID: On Mon, 6 Mar 2023 13:23:59 GMT, Viktor Klang wrote: > I think the following proposal is very non-invasive and merely draws attention to the fact that "witness value" is a specific term related to the notion of these atomic methods. > > It's a small change which I think provides additional clarity, see JBS for the discussion on the topic. This pull request has now been integrated. Changeset: d06308c5 Author: Viktor Klang Committer: Martin Buchholz URL: https://git.openjdk.org/jdk/commit/d06308c54a6f3782565eae343778436013205e21 Stats: 33 lines in 8 files changed: 0 ins; 0 del; 33 mod 8302360: Atomic*.compareAndExchange Javadoc unclear Reviewed-by: martin, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/12880 From dholmes at openjdk.org Fri Mar 10 02:48:18 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 10 Mar 2023 02:48:18 GMT Subject: RFR: 8303485: Replacing os.name for operating system customization In-Reply-To: References: <63bDp4THq-tTVgVGSyKRzBJG5xonppC13R2bsHxrKWg=.8c7aca4a-32ee-4d43-b75a-619038fbc2fb@github.com> Message-ID: On Thu, 9 Mar 2023 16:01:21 GMT, Roger Riggs wrote: >> src/java.base/share/classes/jdk/internal/misc/OperatingSystem.java line 74: >> >>> 72: * The Mac OS X Operating system. >>> 73: */ >>> 74: Mac("Mac OS X"), >> >> The current spelling used by Apple is "macOS", probably to align to other Apple systems (iOS, iPadOS, etc.). > > Names and branding have changed over the years. > It may be prudent to remove the name entirely and stick to a 'generic' identification of the OS as the Enum name. The current branding is "macOS" and we made a lot of changes in various places (but not all of course) to ensure that we use "macOS". Even if this can change in the future I think starting with the current terminology rather than defining something new, would be much better. ------------- PR: https://git.openjdk.org/jdk/pull/12931 From dholmes at openjdk.org Fri Mar 10 02:48:20 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 10 Mar 2023 02:48:20 GMT Subject: RFR: 8303485: Replacing os.name for operating system customization In-Reply-To: References: Message-ID: The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. ---------------------------------------------------------------------- On Thu, 9 Mar 2023 16:12:26 GMT, Roger Riggs wrote: >> src/java.base/share/classes/jdk/internal/misc/OperatingSystem.java line 105: >> >>> 103: */ >>> 104: @ForceInline >>> 105: public static boolean isMac() { >> >> suggestion: isMacOS > > As above, sticking to a generic term can make this a bit less sensitive to branding changes. Lets at least be consistent and not introduce a rage of terms. "mac" is a piece of hardware. ------------- PR: https://git.openjdk.org/jdk/pull/12931 From duke at openjdk.org Fri Mar 10 02:50:45 2023 From: duke at openjdk.org (liach) Date: Fri, 10 Mar 2023 02:50:45 GMT Subject: RFR: 8303930: Fix ConstantUtils.skipOverFieldSignature void case return value [v2] In-Reply-To: References: Message-ID: <3_tc-gXSRlqhy9C1w8VyF3eob4DF_lz-E5JxwXH1bio=.3e41c14e-d376-4453-8d22-1fb5795ce170@github.com> > This typo doesn't allow creation of malformed ClassDesc or MethodTypeDesc, but it produces an erroneous exception on certain inputs. Running `java.lang.constant.MethodTypeDesc.ofDescriptor("(IIIII[[[V)I")` in Jshell 19.0.2 throws StringIndexOutOfBoundsException, and throws IllegalArgumentException in the Jshell for this patch. liach has updated the pull request incrementally with one additional commit since the last revision: Copyright year ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12964/files - new: https://git.openjdk.org/jdk/pull/12964/files/075c6050..d7b38bcf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12964&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12964&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12964.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12964/head:pull/12964 PR: https://git.openjdk.org/jdk/pull/12964 From dholmes at openjdk.org Fri Mar 10 02:51:15 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 10 Mar 2023 02:51:15 GMT Subject: RFR: 8303485: Replacing os.name for operating system customization In-Reply-To: References: <_8DN_1dTWHoKNsi93PzINoaR2f1ZCTfnyNJxPWF_qDs=.ab9adca9-ac4b-4bcd-8f53-6656a62d1401@github.com> Message-ID: <022QJiP5OAN-aj99SihsDtXskgxMVCP_k975KKFo3ao=.940d6615-58df-45aa-a672-2e3bbdf688ab@github.com> On Thu, 9 Mar 2023 17:12:53 GMT, Roger Riggs wrote: >>> I would argue that we should keep the replacement string matching the make variable its getting the value from. It makes it easier to trace the origin of the value. >> >> Then we can define a new make variable that will also allow it be a different value than `OPENJDK_TARGET_OS` if desirable. > > There is no need to define a new variable, there are already too many in the build and the build and the compiled files should be using the same symbols. IMO the naming should make sense from the perspective of reading the post-processed source file - so the variable should refer to "current" not "target". ------------- PR: https://git.openjdk.org/jdk/pull/12931 From liangchenblue at gmail.com Fri Mar 10 04:00:43 2023 From: liangchenblue at gmail.com (-) Date: Thu, 9 Mar 2023 22:00:43 -0600 Subject: Design principles of ConstantDesc.resolveConstantDesc Message-ID: Hello, While looking at ConstantDesc.resolveConstantDesc, I find that user code cannot call resolveConstantDesc without extra casts for these types of constant descriptors: ClassDesc, MethodTypeDesc, MethodHandleDesc. Other constant descriptors can have their constants resolved without casts: Double, DynamicConstantDesc, Float, Integer, Long, String. This appears as a design flaw to me, as in the implementation of the 3 cast-required types, their return types are Class, MethodType, and MethodHandle respectively. However, these implementations are not visible to users, so they cannot be benefitted by the more specific return types in the implementations (unlike the VarHandleDesc and EnumDesc, which are public). If this is valid, I propose to add covariant overrides to resolveConstantDesc in the ClassDesc, MethodTypeDesc, and MethodHandleDesc interfaces. These should have little backward compatibility concerns as these interfaces are already sealed. I can open an issue on JBS and submit a patch. Chen Liang From dholmes at openjdk.org Fri Mar 10 05:13:17 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 10 Mar 2023 05:13:17 GMT Subject: RFR: 8303485: Replacing os.name for operating system customization In-Reply-To: <9GNYcmdPMby8pBH09OhJmHnliaM2nHwFrpQhJRfS8-c=.23fa8a24-7464-43a4-a153-5a45a4ca7c85@github.com> References: <9GNYcmdPMby8pBH09OhJmHnliaM2nHwFrpQhJRfS8-c=.23fa8a24-7464-43a4-a153-5a45a4ca7c85@github.com> Message-ID: <0-ToBuOoraKiwwuK4eU4PlgOerOeHBB6fJHbuOv-hE4=.7b521903-2d77-4c19-ada6-bcd17db9d37c@github.com> On Thu, 9 Mar 2023 17:18:35 GMT, Roger Riggs wrote: >> That would not yield a compile time constant. >> The TARGET_IS_XXX values must evaluate to compile time constants as evaluated by javac. > > Using the naming from the build makes it clearer that there is a dependency between the build names and those in the template. Don't we have a conditional compilation ability with these template files such that we can just generate true or false depending on the OS? ------------- PR: https://git.openjdk.org/jdk/pull/12931 From mchung at openjdk.org Fri Mar 10 05:13:18 2023 From: mchung at openjdk.org (Mandy Chung) Date: Fri, 10 Mar 2023 05:13:18 GMT Subject: RFR: 8303485: Replacing os.name for operating system customization In-Reply-To: <0-ToBuOoraKiwwuK4eU4PlgOerOeHBB6fJHbuOv-hE4=.7b521903-2d77-4c19-ada6-bcd17db9d37c@github.com> References: <9GNYcmdPMby8pBH09OhJmHnliaM2nHwFrpQhJRfS8-c=.23fa8a24-7464-43a4-a153-5a45a4ca7c85@github.com> <0-ToBuOoraKiwwuK4eU4PlgOerOeHBB6fJHbuOv-hE4=.7b521903-2d77-4c19-ada6-bcd17db9d37c@github.com> Message-ID: On Fri, 10 Mar 2023 02:51:43 GMT, David Holmes wrote: >> Using the naming from the build makes it clearer that there is a dependency between the build names and those in the template. > > Don't we have a conditional compilation ability with these template files such that we can just generate true or false depending on the OS? Good point. `OperatingSystemProps.java` can be a OS-specific class like: src/java.base/macosx/classes/jdk/internal/misc/OperatingSystemProps.java linux/classes/jdk/internal/misc/OperatingSystemProps.java windows/classes/jdk/internal/misc/OperatingSystemProps.java OTOH, if we include `os.arch`, that would need to be a template. A single template file to include both OS and ARCH would do it. ------------- PR: https://git.openjdk.org/jdk/pull/12931 From dholmes at openjdk.org Fri Mar 10 05:45:13 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 10 Mar 2023 05:45:13 GMT Subject: RFR: 8303485: Replacing os.name for operating system customization In-Reply-To: References: <9GNYcmdPMby8pBH09OhJmHnliaM2nHwFrpQhJRfS8-c=.23fa8a24-7464-43a4-a153-5a45a4ca7c85@github.com> <0-ToBuOoraKiwwuK4eU4PlgOerOeHBB6fJHbuOv-hE4=.7b521903-2d77-4c19-ada6-bcd17db9d37c@github.com> Message-ID: <6b9jyeOfI5HBQ4YzYcpHfnXF6xxOuxYbHNlTk2NsEQc=.bd28cb3d-b743-40b5-8ad4-7df8ea62950f@github.com> On Fri, 10 Mar 2023 05:09:49 GMT, Mandy Chung wrote: >> Don't we have a conditional compilation ability with these template files such that we can just generate true or false depending on the OS? > > Good point. `OperatingSystemProps.java` can be a OS-specific class like: > > src/java.base/macosx/classes/jdk/internal/misc/OperatingSystemProps.java > linux/classes/jdk/internal/misc/OperatingSystemProps.java > windows/classes/jdk/internal/misc/OperatingSystemProps.java > > > OTOH, if we include `os.arch`, that would need to be a template. A single template file to include both OS and ARCH would do it. I was literally thinking of the `#if[xx]` conditional compilation facility rather than an OS specific file, but okay ... ------------- PR: https://git.openjdk.org/jdk/pull/12931 From cjplummer at openjdk.org Fri Mar 10 05:50:03 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 10 Mar 2023 05:50:03 GMT Subject: RFR: 8303814: getLastErrorString should avoid charset conversions In-Reply-To: References: Message-ID: On Wed, 8 Mar 2023 11:30:27 GMT, Daniel Jeli?ski wrote: > This patch modifies the `getLastErrorString` method to return a `jstring`. Thanks to that we can avoid unnecessary back and forth conversions between Unicode and other charsets on Windows. > > Other changes include: > - the Windows implementation of `getLastErrorString` no longer checks `errno`. I verified all uses of the method and confirmed that `errno` is not used anywhere. > - While at it, I found and fixed a few calls to `JNU_ThrowIOExceptionWithLastError` that were done in context where `LastError` was not set. > - jdk.hotspot.agent was modified to use `JNU_ThrowByNameWithLastError` and `JNU_ThrowByName` instead of `getLastErrorString`; the code is expected to have identical behavior. > - zip_util was modified to return static messages instead of generated ones. The generated messages were not observed anywhere, because they were replaced by a static message in ZIP_Open, which is the only method used by other native code. > - `getLastErrorString` is no longer exported by libjava. > > Tier1-3 tests continue to pass. > > No new automated regression test; testing this requires installing a language pack that cannot be displayed in the current code page. > Tested this manually by installing Chinese language pack on English Windows 11, selecting Chinese language, then checking if the message on exception thrown by `InetAddress.getByName("nonexistent.local");` starts with `"?????????"` (or `"\u4e0d\u77e5\u9053\u8fd9\u6837\u7684\u4e3b\u673a\u3002"`). Without the change, the exception message started with a row of question marks. I'm approving the SA changes. Thanks for the testing. ------------- Marked as reviewed by cjplummer (Reviewer). PR: https://git.openjdk.org/jdk/pull/12922 From asotona at openjdk.org Fri Mar 10 07:10:11 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 10 Mar 2023 07:10:11 GMT Subject: RFR: 8294962: java.base jdk.internal.module package uses ASM to modify and write module-info.class [v2] In-Reply-To: References: Message-ID: > 8294962: java.base jdk.internal.module package uses ASM to modify and write module-info.class. > This patch converts it to use Classfile API. > > Please review. > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: Update src/java.base/share/classes/jdk/internal/module/ModuleInfoExtender.java Co-authored-by: Mandy Chung ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11368/files - new: https://git.openjdk.org/jdk/pull/11368/files/011a6700..03da6dd3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11368&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11368&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11368.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11368/head:pull/11368 PR: https://git.openjdk.org/jdk/pull/11368 From asotona at openjdk.org Fri Mar 10 07:13:09 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 10 Mar 2023 07:13:09 GMT Subject: RFR: 8294972: jdk.jlink internal plugins are heavily using ASM [v2] In-Reply-To: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> Message-ID: <0l2GiDd458DlfIykTnGI6lbLpXF0iFvpmdn0p1WybbE=.b2ac32ea-1c0a-480a-a4b6-59806b0732b8@github.com> > jdk.jlink internal plugins are heavily using ASM > > This patch converts ASM calls to Classfile API. > > Please review. > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: Update src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/IncludeLocalesPlugin.java Co-authored-by: Mandy Chung ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12944/files - new: https://git.openjdk.org/jdk/pull/12944/files/49c5bd59..0c0df14c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12944&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12944&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/12944.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12944/head:pull/12944 PR: https://git.openjdk.org/jdk/pull/12944 From asotona at openjdk.org Fri Mar 10 07:30:24 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 10 Mar 2023 07:30:24 GMT Subject: RFR: 8294971: jdk.jlink jdk.tools.jimage.JImageTask is using ASM to verify classes [v2] In-Reply-To: <1GjpLK1GYB9V9T8Z_qtnDw0U3RyS7E6qDZtRll8WpKw=.1981b0de-9e62-4601-b895-f6dac301cec1@github.com> References: <1GjpLK1GYB9V9T8Z_qtnDw0U3RyS7E6qDZtRll8WpKw=.1981b0de-9e62-4601-b895-f6dac301cec1@github.com> Message-ID: > jdk.jlink jdk.tools.jimage.JImageTask is using ASM to verify classes > > This patch converts ASM calls to Classfile API. > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 190 commits: - Merge branch 'master' into JDK-8294971-jlink-jimage - Merge branch 'master' into JDK-8294971-jlink-jimage - 8294971: jdk.jlink jdk.tools.jimage.JImageTask is using ASM to verify classes - removed obsolete javadoc from implementation classes - minor fix in CodeBuilder and added test cases to LDCTest - EntryMap::nextPowerOfTwo delegates to Long:numberOfLeadingZeros - fixed CodeBuilder:constantInstruction for -0.0d and -0.0f values and added test - Merge branch 'master' into JDK-8294982 - fixed new lines at end of file - package jdk.internal.classfile.jdktypes moved to jdk.internal.classfile.java.lang.constant - ... and 180 more: https://git.openjdk.org/jdk/compare/e26cc526...37fac1d2 ------------- Changes: https://git.openjdk.org/jdk/pull/12943/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12943&range=01 Stats: 15 lines in 2 files changed: 10 ins; 2 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/12943.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12943/head:pull/12943 PR: https://git.openjdk.org/jdk/pull/12943 From asotona at openjdk.org Fri Mar 10 07:44:09 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 10 Mar 2023 07:44:09 GMT Subject: RFR: 8294972: jdk.jlink internal plugins are heavily using ASM [v3] In-Reply-To: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> Message-ID: > jdk.jlink internal plugins are heavily using ASM > > This patch converts ASM calls to Classfile API. > > Please review. > Thanks, > Adam Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 207 commits: - Merge branch 'master' into JDK-8294972-jlink-plugins - fixed SystemModulesPlugin formatting - 8303624: The java.lang.Thread.FieldHolder can be null for JNI attaching threads Reviewed-by: alanb, dcubed - 8302360: Atomic*.compareAndExchange Javadoc unclear Reviewed-by: martin, dholmes - 8302779: HelidonAppTest.java fails with "assert(_cb == CodeCache::find_blob(pc())) failed: Must be the same" or SIGSEGV Reviewed-by: coleenp, sspitsyn - 8303691: Fedora based devkit build should load more packages from archive location Reviewed-by: mbaesken, erikj - 8303924: ProblemList serviceability/sa/UniqueVtableTest.java on Linux Reviewed-by: dcubed - 8303609: ProblemList serviceability/sa/TestSysProps.java with ZGC Reviewed-by: dcubed - 8289765: JDI EventSet/resume/resume008 failed with "ERROR: suspendCounts don't match for : VirtualThread-unparker" Reviewed-by: sspitsyn, kevinw - 8301074: Replace NULL with nullptr in share/opto/ Reviewed-by: kvn, jwilhelm - ... and 197 more: https://git.openjdk.org/jdk/compare/e26cc526...ec1126f7 ------------- Changes: https://git.openjdk.org/jdk/pull/12944/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12944&range=02 Stats: 1025 lines in 6 files changed: 215 ins; 300 del; 510 mod Patch: https://git.openjdk.org/jdk/pull/12944.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12944/head:pull/12944 PR: https://git.openjdk.org/jdk/pull/12944 From asotona at openjdk.org Fri Mar 10 07:44:12 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 10 Mar 2023 07:44:12 GMT Subject: RFR: 8294972: jdk.jlink internal plugins are heavily using ASM [v3] In-Reply-To: References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> Message-ID: On Thu, 9 Mar 2023 22:38:32 GMT, Mandy Chung wrote: >> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 207 commits: >> >> - Merge branch 'master' into JDK-8294972-jlink-plugins >> - fixed SystemModulesPlugin formatting >> - 8303624: The java.lang.Thread.FieldHolder can be null for JNI attaching threads >> >> Reviewed-by: alanb, dcubed >> - 8302360: Atomic*.compareAndExchange Javadoc unclear >> >> Reviewed-by: martin, dholmes >> - 8302779: HelidonAppTest.java fails with "assert(_cb == CodeCache::find_blob(pc())) failed: Must be the same" or SIGSEGV >> >> Reviewed-by: coleenp, sspitsyn >> - 8303691: Fedora based devkit build should load more packages from archive location >> >> Reviewed-by: mbaesken, erikj >> - 8303924: ProblemList serviceability/sa/UniqueVtableTest.java on Linux >> >> Reviewed-by: dcubed >> - 8303609: ProblemList serviceability/sa/TestSysProps.java with ZGC >> >> Reviewed-by: dcubed >> - 8289765: JDI EventSet/resume/resume008 failed with "ERROR: suspendCounts don't match for : VirtualThread-unparker" >> >> Reviewed-by: sspitsyn, kevinw >> - 8301074: Replace NULL with nullptr in share/opto/ >> >> Reviewed-by: kvn, jwilhelm >> - ... and 197 more: https://git.openjdk.org/jdk/compare/e26cc526...ec1126f7 > > src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 619: > >> 617: "", >> 618: MethodTypeDesc.of(CD_void), >> 619: false); > > nit: extra space > > sorry this might be from the patch I sent you. fixed, thanks. > src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 1644: > >> 1642: CD_SYSTEM_MODULES_MAP, >> 1643: clb -> { >> 1644: clb.withFlags(ACC_FINAL+ACC_SUPER); > > Nit: consistent with line 578 with a space before and after `+` fixed, thanks. ------------- PR: https://git.openjdk.org/jdk/pull/12944 From jpai at openjdk.org Fri Mar 10 07:50:05 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 10 Mar 2023 07:50:05 GMT Subject: RFR: 8303920: Avoid calling out to python in DataDescriptorSignatureMissing test In-Reply-To: References: Message-ID: On Thu, 9 Mar 2023 19:53:44 GMT, Eirik Bjorsnos wrote: > Please review this PR which brings the DataDescriptorSignatureMissing test back to life. > > This test currently calls out to Python to create a test vector ZIP with a Data Descriptor without the recommended but optional signature. The Python dependency has turned out to be very brittle, so the test is currently marked with `@ignore` > > The PR replaces Python callouts with directly creating the test vector ZIP in the test itself. We can then remove the `@ignore`tag and run this useful test automatically. test/jdk/java/util/zip/DataDescriptorSignatureMissing.java line 29: > 27: * @summary Check ability to read zip files created by python zipfile > 28: * implementation, which fails to write optional (but recommended) data > 29: * descriptor signatures. Hello Eirik, I think the summary should no longer have references to python. Since this test was introduced for https://bugs.openjdk.org/browse/JDK-8056934, perhaps we can just change the `@summary` of this test definition to say: > >@summary Verify the ability to read zip files whose local header data descriptor is missing the optional signature ------------- PR: https://git.openjdk.org/jdk/pull/12959 From alanb at openjdk.org Fri Mar 10 07:53:04 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 10 Mar 2023 07:53:04 GMT Subject: RFR: 8303919: Instant.ofEpochMilli says it can throw an exception that it can't In-Reply-To: References: Message-ID: On Thu, 9 Mar 2023 22:07:17 GMT, Roger Riggs wrote: > I see your point, but no one has stumbled into/over it before. > Rationalizing here... > The presence of the exception is a reminder that there are values of epoch milliseconds that `Instant` can not represent. > It is also the case that `long` cannot represent them either. > For example `Instant.MIN.toEpochMilli()` throws and the method `Instant.ofEpochSecond(sec, nanos)` throws with Long.MIN_VALUE and Long.MAX_VALUE. I'm surprised it hasn't come up as declaring that it throws DateTimeException "if the instant exceeds the maximum or minimum instant" is a testable assertion. Maybe as part of this removal there should be an apiNote will some verbiage on what can be represented. ------------- PR: https://git.openjdk.org/jdk/pull/12958 From asotona at openjdk.org Fri Mar 10 07:56:18 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 10 Mar 2023 07:56:18 GMT Subject: RFR: 8294966: jdk.jartool sun.tools.jar.FingerPrint uses ASM to parse class jar entries [v2] In-Reply-To: References: Message-ID: > 8294966: jdk.jartool sun.tools.jar.FingerPrint uses ASM to parse class jar entries > This patch converts it to use Classfile API. > > Please review. > Thanks, > Adam Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 197 commits: - Merge branch 'master' into JDK-8294966-jartool - Merge branch 'master' into JDK-8294966-jartool - FingerPrint fixes Co-authored-by: Mandy Chung - Update src/jdk.jartool/share/classes/sun/tools/jar/FingerPrint.java Co-authored-by: Mandy Chung - Merge branch 'JDK-8294982' into JDK-8294966 - removed obsolete javadoc from implementation classes - minor fix in CodeBuilder and added test cases to LDCTest - EntryMap::nextPowerOfTwo delegates to Long:numberOfLeadingZeros - fixed CodeBuilder:constantInstruction for -0.0d and -0.0f values and added test - Merge branch 'master' into JDK-8294982 - ... and 187 more: https://git.openjdk.org/jdk/compare/e26cc526...f595a905 ------------- Changes: https://git.openjdk.org/jdk/pull/11694/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11694&range=01 Stats: 123 lines in 4 files changed: 49 ins; 40 del; 34 mod Patch: https://git.openjdk.org/jdk/pull/11694.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11694/head:pull/11694 PR: https://git.openjdk.org/jdk/pull/11694 From asotona at openjdk.org Fri Mar 10 07:56:20 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 10 Mar 2023 07:56:20 GMT Subject: RFR: 8294966: jdk.jartool sun.tools.jar.FingerPrint uses ASM to parse class jar entries [v2] In-Reply-To: References: Message-ID: On Thu, 9 Mar 2023 18:16:49 GMT, Mandy Chung wrote: >> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 197 commits: >> >> - Merge branch 'master' into JDK-8294966-jartool >> - Merge branch 'master' into JDK-8294966-jartool >> - FingerPrint fixes >> Co-authored-by: Mandy Chung >> - Update src/jdk.jartool/share/classes/sun/tools/jar/FingerPrint.java >> >> Co-authored-by: Mandy Chung >> - Merge branch 'JDK-8294982' into JDK-8294966 >> - removed obsolete javadoc from implementation classes >> - minor fix in CodeBuilder and added test cases to LDCTest >> - EntryMap::nextPowerOfTwo delegates to Long:numberOfLeadingZeros >> - fixed CodeBuilder:constantInstruction for -0.0d and -0.0f values and added test >> - Merge branch 'master' into JDK-8294982 >> - ... and 187 more: https://git.openjdk.org/jdk/compare/e26cc526...f595a905 > > make/modules/jdk.jartool/Java.gmk line 28: > >> 26: DISABLED_WARNINGS_java += missing-explicit-ctor >> 27: JAVAC_FLAGS += -XDstringConcat=inline >> 28: JAVAC_FLAGS += --enable-preview > > This change is no longer needed. It's not a preview API. Unfortunately patterns in switch statements are still in preview. This flag and participation in preview can be removed once they are finalised. ------------- PR: https://git.openjdk.org/jdk/pull/11694 From duke at openjdk.org Fri Mar 10 08:01:51 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Fri, 10 Mar 2023 08:01:51 GMT Subject: RFR: 8303920: Avoid calling out to python in DataDescriptorSignatureMissing test [v2] In-Reply-To: References: Message-ID: > Please review this PR which brings the DataDescriptorSignatureMissing test back to life. > > This test currently calls out to Python to create a test vector ZIP with a Data Descriptor without the recommended but optional signature. The Python dependency has turned out to be very brittle, so the test is currently marked with `@ignore` > > The PR replaces Python callouts with directly creating the test vector ZIP in the test itself. We can then remove the `@ignore`tag and run this useful test automatically. Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision: Remove reference to python in the @summary of DataDescriptorSignatureMissing ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12959/files - new: https://git.openjdk.org/jdk/pull/12959/files/a145693b..064aa3b9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12959&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12959&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/12959.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12959/head:pull/12959 PR: https://git.openjdk.org/jdk/pull/12959 From duke at openjdk.org Fri Mar 10 08:01:53 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Fri, 10 Mar 2023 08:01:53 GMT Subject: RFR: 8303920: Avoid calling out to python in DataDescriptorSignatureMissing test [v2] In-Reply-To: References: Message-ID: On Fri, 10 Mar 2023 07:47:05 GMT, Jaikiran Pai wrote: >> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove reference to python in the @summary of DataDescriptorSignatureMissing > > test/jdk/java/util/zip/DataDescriptorSignatureMissing.java line 29: > >> 27: * @summary Check ability to read zip files created by python zipfile >> 28: * implementation, which fails to write optional (but recommended) data >> 29: * descriptor signatures. > > Hello Eirik, I think the summary should no longer have references to python. Since this test was introduced for https://bugs.openjdk.org/browse/JDK-8056934, perhaps we can just change the `@summary` of this test definition to say: >> >>@summary Verify the ability to read zip files whose local header data descriptor is missing the optional signature Thanks, I updated the summary according to your suggestion. I left it there to keep the history/context of the test, but I guess that's a bit detailed and is already captured in the bug. ------------- PR: https://git.openjdk.org/jdk/pull/12959 From djelinski at openjdk.org Fri Mar 10 08:06:16 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 10 Mar 2023 08:06:16 GMT Subject: RFR: 8303814: getLastErrorString should avoid charset conversions In-Reply-To: References: Message-ID: The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. ---------------------------------------------------------------------- On Thu, 9 Mar 2023 00:17:42 GMT, Naoto Sato wrote: >> This patch modifies the `getLastErrorString` method to return a `jstring`. Thanks to that we can avoid unnecessary back and forth conversions between Unicode and other charsets on Windows. >> >> Other changes include: >> - the Windows implementation of `getLastErrorString` no longer checks `errno`. I verified all uses of the method and confirmed that `errno` is not used anywhere. >> - While at it, I found and fixed a few calls to `JNU_ThrowIOExceptionWithLastError` that were done in context where `LastError` was not set. >> - jdk.hotspot.agent was modified to use `JNU_ThrowByNameWithLastError` and `JNU_ThrowByName` instead of `getLastErrorString`; the code is expected to have identical behavior. >> - zip_util was modified to return static messages instead of generated ones. The generated messages were not observed anywhere, because they were replaced by a static message in ZIP_Open, which is the only method used by other native code. >> - `getLastErrorString` is no longer exported by libjava. >> >> Tier1-3 tests continue to pass. >> >> No new automated regression test; testing this requires installing a language pack that cannot be displayed in the current code page. >> Tested this manually by installing Chinese language pack on English Windows 11, selecting Chinese language, then checking if the message on exception thrown by `InetAddress.getByName("nonexistent.local");` starts with `"?????????"` (or `"\u4e0d\u77e5\u9053\u8fd9\u6837\u7684\u4e3b\u673a\u3002"`). Without the change, the exception message started with a row of question marks. > > src/java.base/windows/native/libnio/ch/FileDispatcherImpl.c line 208: > >> 206: >> 207: if (result == 0) { >> 208: JNU_ThrowIOExceptionWithLastError(env, "Write failed"); > > Could be replaced with `JNU_ThrowIOException`? If we got here, `WriteFile` just failed and `GetLastError` contains interesting information. `JNU_ThrowIOExceptionWithLastError` will generate specific error message in user's language, `JNU_ThrowIOException` would just throw `Write failed`. I don't think we want to change this. ------------- PR: https://git.openjdk.org/jdk/pull/12922 From duke at openjdk.org Fri Mar 10 08:06:58 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Fri, 10 Mar 2023 08:06:58 GMT Subject: RFR: 8303920: Avoid calling out to python in DataDescriptorSignatureMissing test [v3] In-Reply-To: References: Message-ID: <-62R7ogWVkfo4wvgXd1_hlwNXuqKU-WCNbcp5QLr83k=.8457a3bd-b223-4d32-bd90-8f40461051c7@github.com> > Please review this PR which brings the DataDescriptorSignatureMissing test back to life. > > This test currently calls out to Python to create a test vector ZIP with a Data Descriptor without the recommended but optional signature. The Python dependency has turned out to be very brittle, so the test is currently marked with `@ignore` > > The PR replaces Python callouts with directly creating the test vector ZIP in the test itself. We can then remove the `@ignore`tag and run this useful test automatically. Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision: Use "Signatureless" consistently ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12959/files - new: https://git.openjdk.org/jdk/pull/12959/files/064aa3b9..a20faeea Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12959&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12959&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/12959.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12959/head:pull/12959 PR: https://git.openjdk.org/jdk/pull/12959 From alanb at openjdk.org Fri Mar 10 08:09:15 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 10 Mar 2023 08:09:15 GMT Subject: RFR: 8303392: Runtime.exec and ProcessBuilder.start should use System logger [v4] In-Reply-To: References: <-1i11ZrHHgzUbCSa_RXAcGKNfgtpdui--bltZ4Ujs2A=.f5f1a7e2-d3ec-4f64-9b1e-317ef2f24ef1@github.com> Message-ID: <-4y0sLfwbOEBU-mm14Z5mxV6zR6cDJ-Nhn-tsEXtcX8=.4177617d-8be6-4f99-90b7-8f3466e73b3f@github.com> On Fri, 10 Mar 2023 00:01:51 GMT, Roger Riggs wrote: >> Runtime.exec and ProcessBuilder.start methods create a new operating system process with the program and arguments. Many applications configure a logging subsystem to monitor application events. Logging a process start message with the program, arguments, and stack trace can identify the caller and purpose. >> Logging the process start event is complementary to the process start event generated for JFR (Java Flight Recorder). > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Reorder pid, directory, args in logged message. > Cleanup argument lists in tests. src/java.base/share/classes/java/lang/Runtime.java line 353: > 351: * > 352: * @implNote > 353: * The new process creation is logged by {@link ProcessBuilder#start()}. I agree it is useful to have an implNote here but I don't think it words to just say that it is logged by PB.start. Instead I think it should say that the process created is logged, see PB.start for details. ------------- PR: https://git.openjdk.org/jdk/pull/12862 From jpai at openjdk.org Fri Mar 10 08:18:16 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 10 Mar 2023 08:18:16 GMT Subject: RFR: 8303920: Avoid calling out to python in DataDescriptorSignatureMissing test [v3] In-Reply-To: <-62R7ogWVkfo4wvgXd1_hlwNXuqKU-WCNbcp5QLr83k=.8457a3bd-b223-4d32-bd90-8f40461051c7@github.com> References: <-62R7ogWVkfo4wvgXd1_hlwNXuqKU-WCNbcp5QLr83k=.8457a3bd-b223-4d32-bd90-8f40461051c7@github.com> Message-ID: On Fri, 10 Mar 2023 08:06:58 GMT, Eirik Bjorsnos wrote: >> Please review this PR which brings the DataDescriptorSignatureMissing test back to life. >> >> This test currently calls out to Python to create a test vector ZIP with a Data Descriptor without the recommended but optional signature. The Python dependency has turned out to be very brittle, so the test is currently marked with `@ignore` >> >> The PR replaces Python callouts with directly creating the test vector ZIP in the test itself. We can then remove the `@ignore`tag and run this useful test automatically. > > Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision: > > Use "Signatureless" consistently test/jdk/java/util/zip/DataDescriptorSignatureMissing.java line 2: > 1: /* > 2: * Copyright 2012, 2023 Google, Inc. All Rights Reserved. It's my understanding that unless you are doing this change on behalf of Google, you shouldn't be changing that line. Instead, one has to add another line below that, of the form: Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved. ------------- PR: https://git.openjdk.org/jdk/pull/12959 From duke at openjdk.org Fri Mar 10 08:28:37 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Fri, 10 Mar 2023 08:28:37 GMT Subject: RFR: 8303920: Avoid calling out to python in DataDescriptorSignatureMissing test [v4] In-Reply-To: References: Message-ID: <4Q-ax9X3Bq3AVrB0N32hXXAc94WyxmHb9k95XTG1s7E=.85d073ae-b02d-460b-82e8-8b4ae6acb451@github.com> > Please review this PR which brings the DataDescriptorSignatureMissing test back to life. > > This test currently calls out to Python to create a test vector ZIP with a Data Descriptor without the recommended but optional signature. The Python dependency has turned out to be very brittle, so the test is currently marked with `@ignore` > > The PR replaces Python callouts with directly creating the test vector ZIP in the test itself. We can then remove the `@ignore`tag and run this useful test automatically. Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision: Revert change to Google copyright line, add an Oracle copyright line instead. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12959/files - new: https://git.openjdk.org/jdk/pull/12959/files/a20faeea..16c9ff43 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12959&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12959&range=02-03 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12959.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12959/head:pull/12959 PR: https://git.openjdk.org/jdk/pull/12959 From jpai at openjdk.org Fri Mar 10 08:33:13 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 10 Mar 2023 08:33:13 GMT Subject: RFR: 8303920: Avoid calling out to python in DataDescriptorSignatureMissing test [v4] In-Reply-To: <4Q-ax9X3Bq3AVrB0N32hXXAc94WyxmHb9k95XTG1s7E=.85d073ae-b02d-460b-82e8-8b4ae6acb451@github.com> References: <4Q-ax9X3Bq3AVrB0N32hXXAc94WyxmHb9k95XTG1s7E=.85d073ae-b02d-460b-82e8-8b4ae6acb451@github.com> Message-ID: <9IFUGCZ1K2FQMWzAGw4kTSRYuPx_JOzSze-bnN2c3e8=.20fdade1-3f7e-4264-9088-dd4a183a29f6@github.com> On Fri, 10 Mar 2023 08:28:37 GMT, Eirik Bjorsnos wrote: >> Please review this PR which brings the DataDescriptorSignatureMissing test back to life. >> >> This test currently calls out to Python to create a test vector ZIP with a Data Descriptor without the recommended but optional signature. The Python dependency has turned out to be very brittle, so the test is currently marked with `@ignore` >> >> The PR replaces Python callouts with directly creating the test vector ZIP in the test itself. We can then remove the `@ignore`tag and run this useful test automatically. > > Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision: > > Revert change to Google copyright line, add an Oracle copyright line instead. It's good that this test is being revived and no longer relies on an external tool/program to generate a zip which was triggering the issue in https://bugs.openjdk.org/browse/JDK-8056934. The changes look good to me. In order to verify that without the fix in https://bugs.openjdk.org/browse/JDK-8056934, this test fails (i.e. reproduces the issue), I reverted the fix that was done in that issue (`git revert 3951dda4cf06c6e61e19d3df26a792022c1701b9`) and then built the JDK and ran this updated test. It runs into a NullPointerException within the test because the second entry in the zip is missing after the zip is read through the `ZipInputStream`. Could you add this following patch to your test: diff --git a/test/jdk/java/util/zip/DataDescriptorSignatureMissing.java b/test/jdk/java/util/zip/DataDescriptorSignatureMissing.java index 5efdc59de63..636cecb4851 100644 --- a/test/jdk/java/util/zip/DataDescriptorSignatureMissing.java +++ b/test/jdk/java/util/zip/DataDescriptorSignatureMissing.java @@ -39,6 +39,7 @@ import java.nio.charset.StandardCharsets; import java.util.zip.*; import static org.testng.Assert.assertEquals; +import static org.testng.Assert.assertNotNull; public class DataDescriptorSignatureMissing { @@ -55,10 +56,12 @@ public class DataDescriptorSignatureMissing { try (ZipInputStream in = new ZipInputStream( new ByteArrayInputStream(zip))) { ZipEntry first = in.getNextEntry(); + assertNotNull(first, "Zip file is unexpectedly missing first entry"); assertEquals(first.getName(), "first"); assertEquals(in.readAllBytes(), "first".getBytes(StandardCharsets.UTF_8)); ZipEntry second = in.getNextEntry(); + assertNotNull(second, "Zip file is unexpectedly missing second entry"); assertEquals(second.getName(), "second"); assertEquals(in.readAllBytes(), "second".getBytes(StandardCharsets.UTF_8)); } so that instead of running into a NullPointerException, the test will (rightly) reproduce and report the missing second entry? ------------- PR: https://git.openjdk.org/jdk/pull/12959 From duke at openjdk.org Fri Mar 10 08:33:16 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Fri, 10 Mar 2023 08:33:16 GMT Subject: RFR: 8303920: Avoid calling out to python in DataDescriptorSignatureMissing test [v3] In-Reply-To: References: <-62R7ogWVkfo4wvgXd1_hlwNXuqKU-WCNbcp5QLr83k=.8457a3bd-b223-4d32-bd90-8f40461051c7@github.com> Message-ID: On Fri, 10 Mar 2023 08:14:56 GMT, Jaikiran Pai wrote: >> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision: >> >> Use "Signatureless" consistently > > test/jdk/java/util/zip/DataDescriptorSignatureMissing.java line 2: > >> 1: /* >> 2: * Copyright 2012, 2023 Google, Inc. All Rights Reserved. > > It's my understanding that unless you are doing this change on behalf of Google, you shouldn't be changing that line. Instead, one has to add another line below that, of the form: > > Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved. I have no affiliation to Google. I reverted the change to their copyright line and added an Oracle one. There is very little code left from Martin here (the Zip64 note in the header, the class name and some whitespace), but let's keep it anyhow. ------------- PR: https://git.openjdk.org/jdk/pull/12959 From asotona at openjdk.org Fri Mar 10 08:46:16 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 10 Mar 2023 08:46:16 GMT Subject: RFR: 8294962: java.base jdk.internal.module package uses ASM to modify and write module-info.class [v3] In-Reply-To: References: Message-ID: > 8294962: java.base jdk.internal.module package uses ASM to modify and write module-info.class. > This patch converts it to use Classfile API. > > Please review. > Thanks, > Adam Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 198 commits: - ModuleInfoWriter fixes - ModuleInfoExtender comment fix - Merge branch 'master' into JDK-8294962-internal-module - Update src/java.base/share/classes/jdk/internal/module/ModuleInfoExtender.java Co-authored-by: Mandy Chung - Merge branch 'master' into JDK-8294962-internal-module - fixed jdk.internal.classfile.java.lang.constant package name - Merge branch 'JDK-8294982' into JDK-8294962 - removed obsolete javadoc from implementation classes - minor fix in CodeBuilder and added test cases to LDCTest - EntryMap::nextPowerOfTwo delegates to Long:numberOfLeadingZeros - ... and 188 more: https://git.openjdk.org/jdk/compare/e26cc526...9e366fbd ------------- Changes: https://git.openjdk.org/jdk/pull/11368/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11368&range=02 Stats: 268 lines in 2 files changed: 78 ins; 119 del; 71 mod Patch: https://git.openjdk.org/jdk/pull/11368.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11368/head:pull/11368 PR: https://git.openjdk.org/jdk/pull/11368 From asotona at openjdk.org Fri Mar 10 08:46:22 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 10 Mar 2023 08:46:22 GMT Subject: RFR: 8294962: java.base jdk.internal.module package uses ASM to modify and write module-info.class [v3] In-Reply-To: References: Message-ID: On Thu, 9 Mar 2023 18:36:05 GMT, Mandy Chung wrote: >> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 198 commits: >> >> - ModuleInfoWriter fixes >> - ModuleInfoExtender comment fix >> - Merge branch 'master' into JDK-8294962-internal-module >> - Update src/java.base/share/classes/jdk/internal/module/ModuleInfoExtender.java >> >> Co-authored-by: Mandy Chung >> - Merge branch 'master' into JDK-8294962-internal-module >> - fixed jdk.internal.classfile.java.lang.constant package name >> - Merge branch 'JDK-8294982' into JDK-8294962 >> - removed obsolete javadoc from implementation classes >> - minor fix in CodeBuilder and added test cases to LDCTest >> - EntryMap::nextPowerOfTwo delegates to Long:numberOfLeadingZeros >> - ... and 188 more: https://git.openjdk.org/jdk/compare/e26cc526...9e366fbd > > src/java.base/share/classes/jdk/internal/module/ModuleInfoExtender.java line 170: > >> 168: } >> 169: >> 170: // add ModuleTarget, ModuleResolution and ModuleHashes attributes > > This adds or replaces if the attribute exists. Perhaps just drop "add" from the comment? fixed, thanks. > src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java line 138: > >> 136: for (ModuleDescriptor.Provides p : md.provides()) { >> 137: mb.provides(ClassDesc.of(p.service()), >> 138: p.providers() > > Formatting nit: align `p.providers()` with the first parameter to `mb.provides` - a little confusing with current indentation. fixed, thanks. ------------- PR: https://git.openjdk.org/jdk/pull/11368 From alanb at openjdk.org Fri Mar 10 08:46:19 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 10 Mar 2023 08:46:19 GMT Subject: RFR: 8294962: java.base jdk.internal.module package uses ASM to modify and write module-info.class [v2] In-Reply-To: References: Message-ID: <9mMn-6nrf7d4vlM2c2IPMsER6bKqNx7MWxYElwoZXN4=.b3e089de-ca5f-4f4b-ab0d-8fa90628df38@github.com> On Fri, 10 Mar 2023 07:10:11 GMT, Adam Sotona wrote: >> 8294962: java.base jdk.internal.module package uses ASM to modify and write module-info.class. >> This patch converts it to use Classfile API. >> >> Please review. >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > Update src/java.base/share/classes/jdk/internal/module/ModuleInfoExtender.java > > Co-authored-by: Mandy Chung Maybe it is time to move ModuleInfoWriter to test/lib? I don't think it used by any of the tools now. The tools (jlink, jar, jmod) do use ModuleInfoExtender of course. ------------- PR: https://git.openjdk.org/jdk/pull/11368 From asotona at openjdk.org Fri Mar 10 08:46:25 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 10 Mar 2023 08:46:25 GMT Subject: RFR: 8294962: java.base jdk.internal.module package uses ASM to modify and write module-info.class [v3] In-Reply-To: References: Message-ID: On Thu, 9 Mar 2023 19:41:28 GMT, liach wrote: >> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 198 commits: >> >> - ModuleInfoWriter fixes >> - ModuleInfoExtender comment fix >> - Merge branch 'master' into JDK-8294962-internal-module >> - Update src/java.base/share/classes/jdk/internal/module/ModuleInfoExtender.java >> >> Co-authored-by: Mandy Chung >> - Merge branch 'master' into JDK-8294962-internal-module >> - fixed jdk.internal.classfile.java.lang.constant package name >> - Merge branch 'JDK-8294982' into JDK-8294962 >> - removed obsolete javadoc from implementation classes >> - minor fix in CodeBuilder and added test cases to LDCTest >> - EntryMap::nextPowerOfTwo delegates to Long:numberOfLeadingZeros >> - ... and 188 more: https://git.openjdk.org/jdk/compare/e26cc526...9e366fbd > > src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java line 89: > >> 87: >> 88: int moduleFlags = md.modifiers().stream() >> 89: .map(MODULE_MODS_TO_FLAGS::get) > > The `MODULE_MODS_TO_FLAGS` can be reused in `modifiersToFlags`. Otherwise, it's useless and can be removed. `modifiersToFlags` method is now directly inlined using `MODULE_MODS_TO_FLAGS` stream mapping Thank you. ------------- PR: https://git.openjdk.org/jdk/pull/11368 From asotona at openjdk.org Fri Mar 10 08:46:27 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 10 Mar 2023 08:46:27 GMT Subject: RFR: 8294962: java.base jdk.internal.module package uses ASM to modify and write module-info.class [v3] In-Reply-To: References: Message-ID: On Thu, 9 Mar 2023 22:05:55 GMT, Uwe Schindler wrote: >> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 198 commits: >> >> - ModuleInfoWriter fixes >> - ModuleInfoExtender comment fix >> - Merge branch 'master' into JDK-8294962-internal-module >> - Update src/java.base/share/classes/jdk/internal/module/ModuleInfoExtender.java >> >> Co-authored-by: Mandy Chung >> - Merge branch 'master' into JDK-8294962-internal-module >> - fixed jdk.internal.classfile.java.lang.constant package name >> - Merge branch 'JDK-8294982' into JDK-8294962 >> - removed obsolete javadoc from implementation classes >> - minor fix in CodeBuilder and added test cases to LDCTest >> - EntryMap::nextPowerOfTwo delegates to Long:numberOfLeadingZeros >> - ... and 188 more: https://git.openjdk.org/jdk/compare/e26cc526...9e366fbd > > src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java line 140: > >> 138: p.providers() >> 139: .stream() >> 140: .map(pn -> ClassDesc.of(pn)) > > Change to: `.map(ClassDesc::of)` fixed, thanks. ------------- PR: https://git.openjdk.org/jdk/pull/11368 From duke at openjdk.org Fri Mar 10 08:48:00 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Fri, 10 Mar 2023 08:48:00 GMT Subject: RFR: 8303920: Avoid calling out to python in DataDescriptorSignatureMissing test [v5] In-Reply-To: References: Message-ID: <89KgZwCGnrlWIReYmeqaFGoiDjoVE2AbV3o8ctTrNkc=.7e044cf8-ef9e-4718-a201-c501d3680205@github.com> > Please review this PR which brings the DataDescriptorSignatureMissing test back to life. > > This test currently calls out to Python to create a test vector ZIP with a Data Descriptor without the recommended but optional signature. The Python dependency has turned out to be very brittle, so the test is currently marked with `@ignore` > > The PR replaces Python callouts with directly creating the test vector ZIP in the test itself. We can then remove the `@ignore`tag and run this useful test automatically. Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision: Add assertNotNulls to catch unexpectedly missing entries ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12959/files - new: https://git.openjdk.org/jdk/pull/12959/files/16c9ff43..85eab4a3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12959&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12959&range=03-04 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12959.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12959/head:pull/12959 PR: https://git.openjdk.org/jdk/pull/12959 From duke at openjdk.org Fri Mar 10 08:48:04 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Fri, 10 Mar 2023 08:48:04 GMT Subject: RFR: 8303920: Avoid calling out to python in DataDescriptorSignatureMissing test [v4] In-Reply-To: <4Q-ax9X3Bq3AVrB0N32hXXAc94WyxmHb9k95XTG1s7E=.85d073ae-b02d-460b-82e8-8b4ae6acb451@github.com> References: <4Q-ax9X3Bq3AVrB0N32hXXAc94WyxmHb9k95XTG1s7E=.85d073ae-b02d-460b-82e8-8b4ae6acb451@github.com> Message-ID: On Fri, 10 Mar 2023 08:28:37 GMT, Eirik Bjorsnos wrote: >> Please review this PR which brings the DataDescriptorSignatureMissing test back to life. >> >> This test currently calls out to Python to create a test vector ZIP with a Data Descriptor without the recommended but optional signature. The Python dependency has turned out to be very brittle, so the test is currently marked with `@ignore` >> >> The PR replaces Python callouts with directly creating the test vector ZIP in the test itself. We can then remove the `@ignore`tag and run this useful test automatically. > > Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision: > > Revert change to Google copyright line, add an Oracle copyright line instead. Nice! I added your assertNotNulls and tested with the off-by-one code which gives me the following: test DataDescriptorSignatureMissing.shouldParseSignaturelessDescriptor(): failure java.lang.AssertionError: Zip file is unexpectedly missing second entry expected object to not be null ------------- PR: https://git.openjdk.org/jdk/pull/12959 From asotona at openjdk.org Fri Mar 10 08:48:14 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 10 Mar 2023 08:48:14 GMT Subject: RFR: 8294961: java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes [v6] In-Reply-To: References: Message-ID: <2vZ8IArF00YxvsqkZxg1fZJCv-pvUQRYrepvvVhw1w0=.dcd260a4-f3d6-4797-8e11-e9eb266d460c@github.com> > java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes and this patch converts it to use Classfile API. > > Please review. > > Thank you, > Adam Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 196 commits: - Merge branch 'master' into JDK-8294961-proxy - Merge branch 'master' into JDK-8294961-proxy - Merge branch 'JDK-8294982' into JDK-8294961 - removed obsolete javadoc from implementation classes - minor fix in CodeBuilder and added test cases to LDCTest - EntryMap::nextPowerOfTwo delegates to Long:numberOfLeadingZeros - fixed CodeBuilder:constantInstruction for -0.0d and -0.0f values and added test - Merge branch 'master' into JDK-8294982 - fixed new lines at end of file - package jdk.internal.classfile.jdktypes moved to jdk.internal.classfile.java.lang.constant - ... and 186 more: https://git.openjdk.org/jdk/compare/e26cc526...951b1bc7 ------------- Changes: https://git.openjdk.org/jdk/pull/10991/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10991&range=05 Stats: 465 lines in 2 files changed: 48 ins; 199 del; 218 mod Patch: https://git.openjdk.org/jdk/pull/10991.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10991/head:pull/10991 PR: https://git.openjdk.org/jdk/pull/10991 From asotona at openjdk.org Fri Mar 10 08:51:45 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 10 Mar 2023 08:51:45 GMT Subject: RFR: 8294974: jdk.jshell jdk.jshell.execution.LocalExecutionControl uses ASM to instrument classes [v2] In-Reply-To: References: Message-ID: > 8294974: jdk.jshell jdk.jshell.execution.LocalExecutionControl uses ASM to instrument classes > This patch converts it to use Classfile API. > > Please review. > Thanks, > Adam Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 193 commits: - Merge branch 'master' into JDK-8294974-jshell - Merge branch 'master' into JDK-8294974-jshell - Merge branch 'JDK-8294982' into JDK-8294974 - removed obsolete javadoc from implementation classes - minor fix in CodeBuilder and added test cases to LDCTest - EntryMap::nextPowerOfTwo delegates to Long:numberOfLeadingZeros - fixed CodeBuilder:constantInstruction for -0.0d and -0.0f values and added test - Merge branch 'master' into JDK-8294982 - fixed new lines at end of file - package jdk.internal.classfile.jdktypes moved to jdk.internal.classfile.java.lang.constant - ... and 183 more: https://git.openjdk.org/jdk/compare/e26cc526...f9fb8998 ------------- Changes: https://git.openjdk.org/jdk/pull/11413/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11413&range=01 Stats: 54 lines in 2 files changed: 11 ins; 21 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/11413.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11413/head:pull/11413 PR: https://git.openjdk.org/jdk/pull/11413 From asotona at openjdk.org Fri Mar 10 09:09:11 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 10 Mar 2023 09:09:11 GMT Subject: RFR: 8294966: jdk.jartool sun.tools.jar.FingerPrint uses ASM to parse class jar entries [v3] In-Reply-To: References: Message-ID: > 8294966: jdk.jartool sun.tools.jar.FingerPrint uses ASM to parse class jar entries > This patch converts it to use Classfile API. > > Please review. > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: FingerPrint.maybeNestedClass set final ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11694/files - new: https://git.openjdk.org/jdk/pull/11694/files/f595a905..f2131215 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11694&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11694&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11694.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11694/head:pull/11694 PR: https://git.openjdk.org/jdk/pull/11694 From asotona at openjdk.org Fri Mar 10 09:09:15 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 10 Mar 2023 09:09:15 GMT Subject: RFR: 8294966: jdk.jartool sun.tools.jar.FingerPrint uses ASM to parse class jar entries [v3] In-Reply-To: References: Message-ID: On Thu, 9 Mar 2023 18:19:17 GMT, Mandy Chung wrote: >> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: >> >> FingerPrint.maybeNestedClass set final > > src/jdk.jartool/share/classes/sun/tools/jar/FingerPrint.java line 252: > >> 250: private final int access; >> 251: private final boolean publicClass; >> 252: private boolean maybeNestedClass; > > should be final since this is no longer updated. fixed, thanks. ------------- PR: https://git.openjdk.org/jdk/pull/11694 From jpai at openjdk.org Fri Mar 10 09:18:09 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 10 Mar 2023 09:18:09 GMT Subject: RFR: 8303920: Avoid calling out to python in DataDescriptorSignatureMissing test [v5] In-Reply-To: <89KgZwCGnrlWIReYmeqaFGoiDjoVE2AbV3o8ctTrNkc=.7e044cf8-ef9e-4718-a201-c501d3680205@github.com> References: <89KgZwCGnrlWIReYmeqaFGoiDjoVE2AbV3o8ctTrNkc=.7e044cf8-ef9e-4718-a201-c501d3680205@github.com> Message-ID: On Fri, 10 Mar 2023 08:48:00 GMT, Eirik Bjorsnos wrote: >> Please review this PR which brings the DataDescriptorSignatureMissing test back to life. >> >> This test currently calls out to Python to create a test vector ZIP with a Data Descriptor without the recommended but optional signature. The Python dependency has turned out to be very brittle, so the test is currently marked with `@ignore` >> >> The PR replaces Python callouts with directly creating the test vector ZIP in the test itself. We can then remove the `@ignore`tag and run this useful test automatically. > > Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision: > > Add assertNotNulls to catch unexpectedly missing entries This now looks good to me. Thank you for doing these changes. I'll run this test on our CI just to be sure there isn't any obvious issues. Before integrating, please wait for another review from Lance or others who have more knowledge of this area. ------------- Marked as reviewed by jpai (Reviewer). PR: https://git.openjdk.org/jdk/pull/12959 From duke at openjdk.org Fri Mar 10 09:19:23 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Fri, 10 Mar 2023 09:19:23 GMT Subject: RFR: 8294959: java.base java.lang.Module uses ASM to load module-info.class In-Reply-To: <5_kDTDkNw-ARy8ZmSqn_LOQw5lt-0WqKeHNdGWIBPHs=.ae41b748-0ca7-4492-9fcf-a0682576bc29@github.com> References: <5_kDTDkNw-ARy8ZmSqn_LOQw5lt-0WqKeHNdGWIBPHs=.ae41b748-0ca7-4492-9fcf-a0682576bc29@github.com> Message-ID: On Fri, 25 Nov 2022 14:35:22 GMT, Adam Sotona wrote: > java.base java.lang.Module uses ASM to load module-info.class and this patch converts it to use Classfile API. This PR seems to have broken `make docs`: Generating JDK_API javadoc for 60 modules src/java.base/share/classes/java/lang/Module.java:1596: error: patterns in switch statements are a preview feature and are disabled by default. case AccessFlags af -> clb.withFlags(AccessFlag.INTERFACE, ^ (use --enable-preview to enable patterns in switch statements) ------------- PR: https://git.openjdk.org/jdk/pull/11367 From duke at openjdk.org Fri Mar 10 09:30:15 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Fri, 10 Mar 2023 09:30:15 GMT Subject: RFR: 8303920: Avoid calling out to python in DataDescriptorSignatureMissing test [v5] In-Reply-To: References: <89KgZwCGnrlWIReYmeqaFGoiDjoVE2AbV3o8ctTrNkc=.7e044cf8-ef9e-4718-a201-c501d3680205@github.com> Message-ID: On Fri, 10 Mar 2023 09:15:30 GMT, Jaikiran Pai wrote: > This now looks good to me. Thanks for taking time to do this thorough review and especially for running the regressing case. Much appreciated! I'll wait for a second review before integrating. ------------- PR: https://git.openjdk.org/jdk/pull/12959 From asotona at openjdk.org Fri Mar 10 09:46:33 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 10 Mar 2023 09:46:33 GMT Subject: RFR: 8294959: java.base java.lang.Module uses ASM to load module-info.class In-Reply-To: References: <5_kDTDkNw-ARy8ZmSqn_LOQw5lt-0WqKeHNdGWIBPHs=.ae41b748-0ca7-4492-9fcf-a0682576bc29@github.com> Message-ID: On Fri, 10 Mar 2023 09:16:03 GMT, Eirik Bjorsnos wrote: > This PR seems to have broken `make docs` It has been fixed by https://github.com/openjdk/jdk/pull/12957 ------------- PR: https://git.openjdk.org/jdk/pull/11367 From duke at openjdk.org Fri Mar 10 09:52:32 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Fri, 10 Mar 2023 09:52:32 GMT Subject: RFR: 8294959: java.base java.lang.Module uses ASM to load module-info.class In-Reply-To: <5_kDTDkNw-ARy8ZmSqn_LOQw5lt-0WqKeHNdGWIBPHs=.ae41b748-0ca7-4492-9fcf-a0682576bc29@github.com> References: <5_kDTDkNw-ARy8ZmSqn_LOQw5lt-0WqKeHNdGWIBPHs=.ae41b748-0ca7-4492-9fcf-a0682576bc29@github.com> Message-ID: On Fri, 25 Nov 2022 14:35:22 GMT, Adam Sotona wrote: > java.base java.lang.Module uses ASM to load module-info.class and this patch converts it to use Classfile API. > It has been fixed by #12957 ? ------------- PR: https://git.openjdk.org/jdk/pull/11367 From asotona at openjdk.org Fri Mar 10 10:19:28 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 10 Mar 2023 10:19:28 GMT Subject: Integrated: 8294971: jdk.jlink jdk.tools.jimage.JImageTask is using ASM to verify classes In-Reply-To: <1GjpLK1GYB9V9T8Z_qtnDw0U3RyS7E6qDZtRll8WpKw=.1981b0de-9e62-4601-b895-f6dac301cec1@github.com> References: <1GjpLK1GYB9V9T8Z_qtnDw0U3RyS7E6qDZtRll8WpKw=.1981b0de-9e62-4601-b895-f6dac301cec1@github.com> Message-ID: <7l6vqU_mW0rBxpJa0cPz73dqfFgaHrV3JHa6U4CtCaE=.fe3800ba-f9c0-46d7-aaaf-1d6a04d77753@github.com> On Thu, 9 Mar 2023 11:33:13 GMT, Adam Sotona wrote: > jdk.jlink jdk.tools.jimage.JImageTask is using ASM to verify classes > > This patch converts ASM calls to Classfile API. > > Please review. > > Thanks, > Adam This pull request has now been integrated. Changeset: b1d89f30 Author: Adam Sotona URL: https://git.openjdk.org/jdk/commit/b1d89f30663aed28783e839c5690f46a2b382002 Stats: 15 lines in 2 files changed: 10 ins; 2 del; 3 mod 8294971: jdk.jlink jdk.tools.jimage.JImageTask is using ASM to verify classes Reviewed-by: mchung ------------- PR: https://git.openjdk.org/jdk/pull/12943 From duke at openjdk.org Fri Mar 10 10:28:16 2023 From: duke at openjdk.org (Viktor Klang) Date: Fri, 10 Mar 2023 10:28:16 GMT Subject: RFR: JDK-8302666: Replace CHM with VarHandle in ForeachOrderedTask [v6] In-Reply-To: References: Message-ID: On Thu, 9 Mar 2023 16:05:32 GMT, Paul Sandoz wrote: >> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision: >> >> Removing unnecessary cast of argument to VarHandle getAndSet > > Marked as reviewed by psandoz (Reviewer). @PaulSandoz Perhaps the bot needs another sponsor instruction? ? ------------- PR: https://git.openjdk.org/jdk/pull/12320 From sean.coffey at oracle.com Fri Mar 10 10:39:26 2023 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 10 Mar 2023 10:39:26 +0000 Subject: ZIP entry copy without recompression In-Reply-To: <8E935EC2-9958-4043-863F-13F27B3D50F9@oracle.com> References: <8E935EC2-9958-4043-863F-13F27B3D50F9@oracle.com> Message-ID: I think that's a fine idea Eirik. Definitely has its use cases like you mention. Some jarsigner operations would also benefit from this. I've created https://bugs.openjdk.org/browse/JDK-8303960 to track it. regards, Sean. On 31/01/2023 23:41, Lance Andersen wrote: > I have not add a chance to look or think about this yet but wanted to > know I will > >> On Jan 19, 2023, at 2:03 PM, Eirik Bj?rsn?s wrote: >> >> Hi, >> >> A common use case for java.util.zip in build tools involves copying >> entries from a ZipFile or ZipInputStream to a ZipOutputStream without >> actually modifying the data. >> >> Example use cases include minification (make a JAR with only the >> reachable classes) and merging (combine several JAR files into one >> uberjar). >> >> Inflating an entry just to immediately deflate it again with no >> modifications seems wasteful. >> >> The following draft PR introduces >> ZipFileInflaterInputStream.transferTo which copies compressed ZipFile >> data directly to ZipOutputStream's raw data stream: >> >> https://github.com/openjdk/jdk/pull/12099 >> >> I'm typically seeing a 15 X improvement when copying xalan.jar to a >> ZipOutputStream backed by a buffered FileOutputStream, or 22 X when >> backed by OutputStream.nullOutputStream(). >> >> The PR current stays completely on the happy path and is mostly there >> to experiment and to show the potential performance benefits. There is >> currently not much focus on validation or correctness. Copying files >> to a different path is not supported, neither is copying from a >> ZipInputStream. >> >> I initially considered creating new methods for raw copies, but opted >> to minimize changes to public APIs, that's why I'm overriding >> transferTo. >> >> The PR is not intended for regular review, but as a starting point for >> a discussion about the usefulness of the idea and the general solution >> space. If we can reach consensus on such a discussion, I'll probably >> be happy to work on a more complete PR. >> >> Cheers, >> Eirik. > > > > > > > > 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 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available URL: From lance.andersen at oracle.com Fri Mar 10 11:31:30 2023 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 10 Mar 2023 11:31:30 +0000 Subject: ZIP entry copy without recompression In-Reply-To: References: <8E935EC2-9958-4043-863F-13F27B3D50F9@oracle.com> Message-ID: <84ED4EE5-E97A-485C-982F-813251B5D578@oracle.com> Morning Eirik, Thank you Sean for creating the CR. As of this week, Eirik has author status so he can now create JBS issues ? I believe Jai is going to follow up with you has he started down a similar path earlier this week looking into a jarsigner issue. So please coordinate to avoid duplication. Also, it would probably be worth looking a ZipFS for the same improvement. Thank you again Eirik(and Jai) for looking into this issue Best Lance On Mar 10, 2023, at 5:39 AM, Sean Coffey > wrote: I think that's a fine idea Eirik. Definitely has its use cases like you mention. Some jarsigner operations would also benefit from this. I've created https://bugs.openjdk.org/browse/JDK-8303960 to track it. regards, Sean. On 31/01/2023 23:41, Lance Andersen wrote: I have not add a chance to look or think about this yet but wanted to know I will On Jan 19, 2023, at 2:03 PM, Eirik Bj?rsn?s > wrote: Hi, A common use case for java.util.zip in build tools involves copying entries from a ZipFile or ZipInputStream to a ZipOutputStream without actually modifying the data. Example use cases include minification (make a JAR with only the reachable classes) and merging (combine several JAR files into one uberjar). Inflating an entry just to immediately deflate it again with no modifications seems wasteful. The following draft PR introduces ZipFileInflaterInputStream.transferTo which copies compressed ZipFile data directly to ZipOutputStream's raw data stream: https://github.com/openjdk/jdk/pull/12099 I'm typically seeing a 15 X improvement when copying xalan.jar to a ZipOutputStream backed by a buffered FileOutputStream, or 22 X when backed by OutputStream.nullOutputStream(). The PR current stays completely on the happy path and is mostly there to experiment and to show the potential performance benefits. There is currently not much focus on validation or correctness. Copying files to a different path is not supported, neither is copying from a ZipInputStream. I initially considered creating new methods for raw copies, but opted to minimize changes to public APIs, that's why I'm overriding transferTo. The PR is not intended for regular review, but as a starting point for a discussion about the usefulness of the idea and the general solution space. If we can reach consensus on such a discussion, I'll probably be happy to work on a more complete PR. Cheers, Eirik. 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 [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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: oracle_sig_logo.gif URL: From asotona at openjdk.org Fri Mar 10 12:31:22 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 10 Mar 2023 12:31:22 GMT Subject: RFR: 8294966: jdk.jartool sun.tools.jar.FingerPrint uses ASM to parse class jar entries [v4] In-Reply-To: References: Message-ID: <28ICelV3yP7v0UEv3mCaFfCV5emQizFQbypc2Im8_EI=.2dbb5126-cbd2-4c23-b5c8-c656572e2182@github.com> > 8294966: jdk.jartool sun.tools.jar.FingerPrint uses ASM to parse class jar entries > This patch converts it to use Classfile API. > > Please review. > Thanks, > Adam Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 199 commits: - Merge branch 'master' into JDK-8294966-jartool - FingerPrint.maybeNestedClass set final - Merge branch 'master' into JDK-8294966-jartool - Merge branch 'master' into JDK-8294966-jartool - FingerPrint fixes Co-authored-by: Mandy Chung - Update src/jdk.jartool/share/classes/sun/tools/jar/FingerPrint.java Co-authored-by: Mandy Chung - Merge branch 'JDK-8294982' into JDK-8294966 - removed obsolete javadoc from implementation classes - minor fix in CodeBuilder and added test cases to LDCTest - EntryMap::nextPowerOfTwo delegates to Long:numberOfLeadingZeros - ... and 189 more: https://git.openjdk.org/jdk/compare/b1d89f30...240c0bfc ------------- Changes: https://git.openjdk.org/jdk/pull/11694/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11694&range=03 Stats: 122 lines in 4 files changed: 48 ins; 40 del; 34 mod Patch: https://git.openjdk.org/jdk/pull/11694.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11694/head:pull/11694 PR: https://git.openjdk.org/jdk/pull/11694 From asotona at openjdk.org Fri Mar 10 12:35:31 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 10 Mar 2023 12:35:31 GMT Subject: RFR: 8294974: jdk.jshell jdk.jshell.execution.LocalExecutionControl uses ASM to instrument classes [v3] In-Reply-To: References: Message-ID: > 8294974: jdk.jshell jdk.jshell.execution.LocalExecutionControl uses ASM to instrument classes > This patch converts it to use Classfile API. > > Please review. > Thanks, > Adam Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 194 commits: - Merge branch 'master' into JDK-8294974-jshell - Merge branch 'master' into JDK-8294974-jshell - Merge branch 'master' into JDK-8294974-jshell - Merge branch 'JDK-8294982' into JDK-8294974 - removed obsolete javadoc from implementation classes - minor fix in CodeBuilder and added test cases to LDCTest - EntryMap::nextPowerOfTwo delegates to Long:numberOfLeadingZeros - fixed CodeBuilder:constantInstruction for -0.0d and -0.0f values and added test - Merge branch 'master' into JDK-8294982 - fixed new lines at end of file - ... and 184 more: https://git.openjdk.org/jdk/compare/b1d89f30...070be0a8 ------------- Changes: https://git.openjdk.org/jdk/pull/11413/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11413&range=02 Stats: 55 lines in 2 files changed: 11 ins; 22 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/11413.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11413/head:pull/11413 PR: https://git.openjdk.org/jdk/pull/11413 From asotona at openjdk.org Fri Mar 10 12:45:05 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 10 Mar 2023 12:45:05 GMT Subject: RFR: 8294972: jdk.jlink internal plugins are heavily using ASM [v4] In-Reply-To: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> Message-ID: > jdk.jlink internal plugins are heavily using ASM > > This patch converts ASM calls to Classfile API. > > Please review. > Thanks, > Adam Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 208 commits: - Merge branch 'master' into JDK-8294972-jlink-plugins # Conflicts: # src/java.base/share/classes/module-info.java - Merge branch 'master' into JDK-8294972-jlink-plugins - fixed SystemModulesPlugin formatting - 8303624: The java.lang.Thread.FieldHolder can be null for JNI attaching threads Reviewed-by: alanb, dcubed - 8302360: Atomic*.compareAndExchange Javadoc unclear Reviewed-by: martin, dholmes - 8302779: HelidonAppTest.java fails with "assert(_cb == CodeCache::find_blob(pc())) failed: Must be the same" or SIGSEGV Reviewed-by: coleenp, sspitsyn - 8303691: Fedora based devkit build should load more packages from archive location Reviewed-by: mbaesken, erikj - 8303924: ProblemList serviceability/sa/UniqueVtableTest.java on Linux Reviewed-by: dcubed - 8303609: ProblemList serviceability/sa/TestSysProps.java with ZGC Reviewed-by: dcubed - 8289765: JDI EventSet/resume/resume008 failed with "ERROR: suspendCounts don't match for : VirtualThread-unparker" Reviewed-by: sspitsyn, kevinw - ... and 198 more: https://git.openjdk.org/jdk/compare/b1d89f30...cfc612ec ------------- Changes: https://git.openjdk.org/jdk/pull/12944/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12944&range=03 Stats: 1023 lines in 6 files changed: 213 ins; 300 del; 510 mod Patch: https://git.openjdk.org/jdk/pull/12944.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12944/head:pull/12944 PR: https://git.openjdk.org/jdk/pull/12944 From alanb at openjdk.org Fri Mar 10 12:59:18 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 10 Mar 2023 12:59:18 GMT Subject: RFR: 8303648: Add String.indexOf(String str, int beginIndex, int endIndex) In-Reply-To: References: Message-ID: On Tue, 7 Mar 2023 14:44:32 GMT, Raffaello Giulietti wrote: > As a followup of [JDK-8302590](https://bugs.openjdk.org/browse/JDK-8302590), this issue covers the analogous case for a search of a string rather than a character. src/java.base/share/classes/java/lang/String.java line 2626: > 2624: * On {@link String}s {@code s} and a non-empty {@code str}, for example, > 2625: * {@code s.indexOf(str, fromIndex, s.length())} would throw if > 2626: * {@code fromIndex} were larger than the string length, or were negative. In passing, I think it's more common to put the apiNote after the method description and before the param/return. src/java.base/share/classes/java/lang/String.java line 2634: > 2632: /** > 2633: * Returns the smallest index of an occurrence of the specified substring > 2634: * within the specified index range of {@code this} string. It might be a bit more consistent with other methods to say "the index of the first occurrence". That will make it consistent with the proposed @return text too. Otherwise the proposed wording looks okay to me. ------------- PR: https://git.openjdk.org/jdk/pull/12903 From jlahoda at openjdk.org Fri Mar 10 13:01:19 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 10 Mar 2023 13:01:19 GMT Subject: RFR: 8294974: jdk.jshell jdk.jshell.execution.LocalExecutionControl uses ASM to instrument classes [v3] In-Reply-To: References: Message-ID: On Fri, 10 Mar 2023 12:35:31 GMT, Adam Sotona wrote: >> 8294974: jdk.jshell jdk.jshell.execution.LocalExecutionControl uses ASM to instrument classes >> This patch converts it to use Classfile API. >> >> Please review. >> Thanks, >> Adam > > Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 194 commits: > > - Merge branch 'master' into JDK-8294974-jshell > - Merge branch 'master' into JDK-8294974-jshell > - Merge branch 'master' into JDK-8294974-jshell > - Merge branch 'JDK-8294982' into JDK-8294974 > - removed obsolete javadoc from implementation classes > - minor fix in CodeBuilder and added test cases to LDCTest > - EntryMap::nextPowerOfTwo delegates to Long:numberOfLeadingZeros > - fixed CodeBuilder:constantInstruction for -0.0d and -0.0f values and added test > - Merge branch 'master' into JDK-8294982 > - fixed new lines at end of file > - ... and 184 more: https://git.openjdk.org/jdk/compare/b1d89f30...070be0a8 Looks good to me, with a nit in java.base's module-info. src/java.base/share/classes/module-info.java line 384: > 382: exports sun.util.resources to > 383: jdk.localedata; > 384: Nit: I'd suggest to preserve the empty line (since there's no other change near). ------------- Marked as reviewed by jlahoda (Reviewer). PR: https://git.openjdk.org/jdk/pull/11413 From asotona at openjdk.org Fri Mar 10 13:09:09 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 10 Mar 2023 13:09:09 GMT Subject: RFR: 8294974: jdk.jshell jdk.jshell.execution.LocalExecutionControl uses ASM to instrument classes [v4] In-Reply-To: References: Message-ID: <6LaKFBr-SCYJpC1Zc0r_zjPCdZjrxd95BL4PuOM2keI=.c1ea387d-e654-435a-9b8d-dfd380d803aa@github.com> > 8294974: jdk.jshell jdk.jshell.execution.LocalExecutionControl uses ASM to instrument classes > This patch converts it to use Classfile API. > > Please review. > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: fixed empty line ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11413/files - new: https://git.openjdk.org/jdk/pull/11413/files/070be0a8..f5ce307e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11413&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11413&range=02-03 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11413.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11413/head:pull/11413 PR: https://git.openjdk.org/jdk/pull/11413 From asotona at openjdk.org Fri Mar 10 13:09:12 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 10 Mar 2023 13:09:12 GMT Subject: RFR: 8294974: jdk.jshell jdk.jshell.execution.LocalExecutionControl uses ASM to instrument classes [v2] In-Reply-To: References: Message-ID: On Fri, 10 Mar 2023 12:58:25 GMT, Jan Lahoda wrote: >> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 193 commits: >> >> - Merge branch 'master' into JDK-8294974-jshell >> - Merge branch 'master' into JDK-8294974-jshell >> - Merge branch 'JDK-8294982' into JDK-8294974 >> - removed obsolete javadoc from implementation classes >> - minor fix in CodeBuilder and added test cases to LDCTest >> - EntryMap::nextPowerOfTwo delegates to Long:numberOfLeadingZeros >> - fixed CodeBuilder:constantInstruction for -0.0d and -0.0f values and added test >> - Merge branch 'master' into JDK-8294982 >> - fixed new lines at end of file >> - package jdk.internal.classfile.jdktypes moved to jdk.internal.classfile.java.lang.constant >> - ... and 183 more: https://git.openjdk.org/jdk/compare/e26cc526...f9fb8998 > > src/java.base/share/classes/module-info.java line 384: > >> 382: jdk.jshell; >> 383: exports jdk.internal.classfile.instruction to >> 384: jdk.jshell; > > Nit: I'd suggest to preserve the empty line (since there's no other change near). fixed, thanks. ------------- PR: https://git.openjdk.org/jdk/pull/11413 From rgiulietti at openjdk.org Fri Mar 10 13:35:27 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 10 Mar 2023 13:35:27 GMT Subject: RFR: 8303648: Add String.indexOf(String str, int beginIndex, int endIndex) [v2] In-Reply-To: References: Message-ID: <68mrLyEKJSdenIkvsv1kP6Hbpv5xoRzk8_y-s3flYuk=.f21057a2-2ee2-4844-9f31-0c9300ba4d73@github.com> > As a followup of [JDK-8302590](https://bugs.openjdk.org/browse/JDK-8302590), this issue covers the analogous case for a search of a string rather than a character. Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: 8303648: Add String.indexOf(String str, int beginIndex, int endIndex) Moved @apiNote on indexOf(String,int) before @param/@return. Rephrased first sentence of indexOf(String,int,int). ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12903/files - new: https://git.openjdk.org/jdk/pull/12903/files/dc4cd3f3..5303bea0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12903&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12903&range=00-01 Stats: 12 lines in 1 file changed: 6 ins; 5 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12903.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12903/head:pull/12903 PR: https://git.openjdk.org/jdk/pull/12903 From jlaskey at openjdk.org Fri Mar 10 13:35:50 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 10 Mar 2023 13:35:50 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v44] In-Reply-To: References: Message-ID: <_ts4xtDO0xFOvi6L7tZeqYzVuC3Nx5zq6JgFu-pazWM=.4b432013-5cd6-4f9b-9086-3608f3ec339b@github.com> > Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 61 commits: - Correction - Merge branch 'master' into 8285932 - Merge branch 'master' into 8285932 - Javadoc corrections and bug fix for StringTemplate::combine - Tighten up reporting of string template errors (fewer messages) - Merge branch 'master' into 8285932 - Merge branch 'master' into 8285932 - Minor correction to javadoc - Merge branch 'master' into 8285932 - CSR review - ... and 51 more: https://git.openjdk.org/jdk/compare/68b5eef4...50456b32 ------------- Changes: https://git.openjdk.org/jdk/pull/10889/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=43 Stats: 9552 lines in 81 files changed: 9452 ins; 24 del; 76 mod Patch: https://git.openjdk.org/jdk/pull/10889.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889 PR: https://git.openjdk.org/jdk/pull/10889 From rgiulietti at openjdk.org Fri Mar 10 13:54:15 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 10 Mar 2023 13:54:15 GMT Subject: RFR: 8303648: Add String.indexOf(String str, int beginIndex, int endIndex) [v2] In-Reply-To: References: Message-ID: On Fri, 10 Mar 2023 12:52:21 GMT, Alan Bateman wrote: >> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: >> >> 8303648: Add String.indexOf(String str, int beginIndex, int endIndex) >> >> Moved @apiNote on indexOf(String,int) before @param/@return. >> Rephrased first sentence of indexOf(String,int,int). > > src/java.base/share/classes/java/lang/String.java line 2626: > >> 2624: * On {@link String}s {@code s} and a non-empty {@code str}, for example, >> 2625: * {@code s.indexOf(str, fromIndex, s.length())} would throw if >> 2626: * {@code fromIndex} were larger than the string length, or were negative. > > In passing, I think it's more common to put the apiNote after the method description and before the param/return. Done in new commit > src/java.base/share/classes/java/lang/String.java line 2634: > >> 2632: /** >> 2633: * Returns the smallest index of an occurrence of the specified substring >> 2634: * within the specified index range of {@code this} string. > > It might be a bit more consistent with other methods to say "the index of the first occurrence". That will make it consistent with the proposed @return text too. Otherwise the proposed wording looks okay to me. Done in new commit ------------- PR: https://git.openjdk.org/jdk/pull/12903 From alanb at openjdk.org Fri Mar 10 14:04:23 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 10 Mar 2023 14:04:23 GMT Subject: RFR: 8303485: Replacing os.name for operating system customization In-Reply-To: <-t6DHZsHknyq9__b5jUjWL9KcBbJJE3P4SDO_W56cMo=.aca1b85e-63f9-44f6-bf32-9bfc7d94e5a4@github.com> References: <-t6DHZsHknyq9__b5jUjWL9KcBbJJE3P4SDO_W56cMo=.aca1b85e-63f9-44f6-bf32-9bfc7d94e5a4@github.com> Message-ID: On Fri, 10 Mar 2023 00:08:57 GMT, Justin King wrote: > Has this totally killed of BSD support on the JDK side? I thought building non-macOS BSD was still viable, but perhaps not - certainly not after this change. The macOS port in 7u4 was based on a BSD port and there was a time when it was possible to build. Right now, we have src/hotspot/os/bsd and native code in the libs that is compiled in with _ALLBSD_SOURCE. It's sad to see the BSD port bit rot but if it's not maintained or tested in the OpenJDK project then the changes proposed here may be okay. For porters then know which code needs to be ported is important, ideally there would be a compile or build time if someone significant is missing. ------------- PR: https://git.openjdk.org/jdk/pull/12931 From alanb at openjdk.org Fri Mar 10 14:04:27 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 10 Mar 2023 14:04:27 GMT Subject: RFR: 8303485: Replacing os.name for operating system customization In-Reply-To: References: Message-ID: On Wed, 8 Mar 2023 19:15:16 GMT, Roger Riggs wrote: > Improvements to support OS specific customization for JDK internal use: > - To select values and code; allowing elimination of unused code and values > - Optionally evaluated by build processes, compilation, or archiving (i.e. CDS) > - Simple API to replace adhoc comparisons with `os.name` > - Clear and consistent use across build, runtime, and JDK modules > > The PR includes updates within java.base to use the new API. src/java.base/share/classes/java/util/zip/ZipFile.java line 28: > 26: package java.util.zip; > 27: > 28: import jdk.internal.misc.OperatingSystem; You might want to move this to be with the other imports of jdk.internal. src/java.base/share/classes/jdk/internal/misc/OperatingSystem.java line 23: > 21: * questions. > 22: */ > 23: package jdk.internal.misc; I see there is a follow on PR to see this in several modules. We can't have jdk.internal.misc exported widely as it contains Unsafe and several other important classes. jdk.internal.util may be a better place, at the same of turning that package into a place for random stuff. ------------- PR: https://git.openjdk.org/jdk/pull/12931 From alanb at openjdk.org Fri Mar 10 14:04:29 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 10 Mar 2023 14:04:29 GMT Subject: RFR: 8303485: Replacing os.name for operating system customization In-Reply-To: References: <63bDp4THq-tTVgVGSyKRzBJG5xonppC13R2bsHxrKWg=.8c7aca4a-32ee-4d43-b75a-619038fbc2fb@github.com> Message-ID: On Fri, 10 Mar 2023 02:43:15 GMT, David Holmes wrote: >> Names and branding have changed over the years. >> It may be prudent to remove the name entirely and stick to a 'generic' identification of the OS as the Enum name. > > The current branding is "macOS" and we made a lot of changes in various places (but not all of course) to ensure that we use "macOS". Even if this can change in the future I think starting with the current terminology rather than defining something new, would be much better. I think "macOS" would be better here. Yes, Apple have changed it several times but it has been stable since about 2016. ------------- PR: https://git.openjdk.org/jdk/pull/12931 From jvernee at openjdk.org Fri Mar 10 14:14:18 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 10 Mar 2023 14:14:18 GMT Subject: RFR: 8303684: Lift upcall sharing mechanism to AbstractLinker (mainline) In-Reply-To: References: Message-ID: On Mon, 6 Mar 2023 18:40:47 GMT, Jorn Vernee wrote: > Port of: https://github.com/openjdk/panama-foreign/pull/791 which lifts the sharing mechanism for upcall stubs to AbstractLinker. > > This also speeds up upcall stub linking: @feilongjiang since this contains changes to the RISCV code as well, could you test the patch? Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/12883 From jvernee at openjdk.org Fri Mar 10 14:14:55 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 10 Mar 2023 14:14:55 GMT Subject: RFR: 8303022: "assert(allocates2(pc)) failed: not in CodeBuffer memory" When linking downcall handle [v3] In-Reply-To: References: Message-ID: > The issue is that the size of the code buffer is not large enough to hold the whole stub. > > Proposed solution is to scale the size of the stub with the number of arguments. I've adjusted sizes for both downcall and upcall stubs. I've also dropped the number of relocations, since we're not really using any for downcalls, and for upcalls we only have 1 AFAICS. (the size of the relocations can not be zero however, as that leads to the relocation section [not being initialized][1], and triggering [an assert][2] later when the code blob is copied). > > The way I've determined the new base size and per-argument size for stubs, is by first linking a stub without any arguments to get the required base size, and by then adding 20 `double` arguments to get a rough per-argument size. Both values have wiggle room as well. The sizes can be printed using e.g. `-XX:+LogCompilation`, and then looking for `nep_invoker_blob` and `upcall_stub*` in the log file. This experiment was done on a fastdebug build to account for additional debug code being generated. The included test is designed to try and maximize the size of the generated stub. > > I've also updated `CodeBuffer::log_section_sizes` to print the in-use size, rather than just the capacity and free space. > > [1]: https://github.com/openjdk/jdk/blob/56512cfe1f0682c98ba3488af3d03ccef632c016/src/hotspot/share/asm/codeBuffer.cpp#L119-L121 > [2]: https://github.com/openjdk/jdk/blob/56512cfe1f0682c98ba3488af3d03ccef632c016/src/hotspot/share/asm/codeBuffer.cpp#L675 Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: RISCV changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12908/files - new: https://git.openjdk.org/jdk/pull/12908/files/0a2bc96c..7f467784 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12908&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12908&range=01-02 Stats: 14 lines in 2 files changed: 8 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/12908.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12908/head:pull/12908 PR: https://git.openjdk.org/jdk/pull/12908 From jvernee at openjdk.org Fri Mar 10 14:14:56 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 10 Mar 2023 14:14:56 GMT Subject: RFR: 8303022: "assert(allocates2(pc)) failed: not in CodeBuffer memory" When linking downcall handle [v2] In-Reply-To: References: Message-ID: On Thu, 9 Mar 2023 06:39:47 GMT, Feilong Jiang wrote: >> @vnkozlov Yes, this is true. The only other existing port of this code is RISCV. However, to fix that port properly, someone needs to repeat the experiment on RISCV in order to figure out what the base size and the size per argument should be. >> >> I don't have access to a RISCV machine, so I figured I would file a followup issue for the RISCV maintainers to fix separately. >> >> @feilongjiang Could you comment on this? If you could figure out the needed sizes for RISCV I could add the needed changes to this patch. Otherwise I could file a followup issue if that seems more convenient. TIA > >> @feilongjiang Could you comment on this? If you could figure out the needed sizes for RISCV I could add the needed changes to this patch. Otherwise I could file a followup issue if that seems more convenient. TIA > > Yes, I will take a look to find out the needed size for RISCV. > > Update: > When disabling RVC (compressed instructions) on fastdebug build, `LogCompilation` reveals that downcall stub base will cost ~200 bytes, 256 looks good enough. But for upcall stubs, we need ~1700 bytes when Shenandoah GC is enabled, so 2048 would be a safe base size. `jdk_foreign` on RISC-V board are all passed (release & fastdebug) with the fix of #12950. > > Here is the patch: > [riscv.txt](https://github.com/openjdk/jdk/files/10938297/riscv.txt) @feilongjiang Thanks! I've added the riscv changes. ------------- PR: https://git.openjdk.org/jdk/pull/12908 From erikj at openjdk.org Fri Mar 10 14:15:06 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 10 Mar 2023 14:15:06 GMT Subject: RFR: 8303922: build-test-lib target is broken In-Reply-To: References: Message-ID: On Thu, 9 Mar 2023 20:09:46 GMT, Eirik Bjorsnos wrote: > The Make target 'build-test-lib-target' is broken in a few ways: > > - make/test/BuildTestLib.gmk references the directory $(TEST_LIB_SOURCE_DIR)/sun which does not seem to exist. This can be fixed by removing the reference. > - Some test-lib sources use preview-features which is not enabled by make/test/BuildTestLib.gmk. This is fixed by adding a JAVAC_FLAGS with --enable-preview and also adding 'preview' to DISABLED_WARNINGS > - ASN1Formatter.annotate has a possible lossy conversion from long to int which can be fixed by adding an explicit cast > > This PR fixes the above issues. Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12960 From duke at openjdk.org Fri Mar 10 14:20:03 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Fri, 10 Mar 2023 14:20:03 GMT Subject: RFR: 8303891: Zip64SizeTest could use a sparse file [v3] In-Reply-To: References: Message-ID: > This PR suggests we use a sparse file when the Zip64SizeTest writes a ZIP file with a 5GB entry. > > The size requirement of this test is known to cause problems in some builds, see [JDK-8259866](https://bugs.openjdk.org/browse/JDK-8259866) > > Using a sparse file reduces the disk space requirements of running the test from 5GB to 12K and also reduces the runtime from ~35 seconds to ~3 seconds on my Macbook Pro. Eirik Bjorsnos 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: - Merge branch 'master' into zip64-size-test-sparse - Make test method public - Add a missing "when" in Javadocs for SparseOutputStream - Remove introduced blank line - Remove double whitespace - Rewrite Zip64SizeTest to write to a sparse file ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12948/files - new: https://git.openjdk.org/jdk/pull/12948/files/d3a8d785..883f543f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12948&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12948&range=01-02 Stats: 53410 lines in 360 files changed: 53053 ins; 202 del; 155 mod Patch: https://git.openjdk.org/jdk/pull/12948.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12948/head:pull/12948 PR: https://git.openjdk.org/jdk/pull/12948 From jcking at openjdk.org Fri Mar 10 14:25:20 2023 From: jcking at openjdk.org (Justin King) Date: Fri, 10 Mar 2023 14:25:20 GMT Subject: RFR: 8303485: Replacing os.name for operating system customization In-Reply-To: References: Message-ID: <30LlJRHIs8OjAn9F7y5PYywWjuk2fV8tyG0SfZFHiOM=.3b961b7b-b2e1-488c-8da6-5fb0a586e208@github.com> On Wed, 8 Mar 2023 19:15:16 GMT, Roger Riggs wrote: > Improvements to support OS specific customization for JDK internal use: > - To select values and code; allowing elimination of unused code and values > - Optionally evaluated by build processes, compilation, or archiving (i.e. CDS) > - Simple API to replace adhoc comparisons with `os.name` > - Clear and consistent use across build, runtime, and JDK modules > > The PR includes updates within java.base to use the new API. > > Has this totally killed of BSD support on the JDK side? I thought building non-macOS BSD was still viable, but perhaps not - certainly not after this change. > > The macOS port in 7u4 was based on a BSD port and there was a time when it was possible to build. Right now, we have src/hotspot/os/bsd and native code in the libs that is compiled in with _ALLBSD_SOURCE. It's sad to see the BSD port bit rot but if it's not maintained or tested in the OpenJDK project then the changes proposed here may be okay. For porters then know which code needs to be ported is important, ideally there would be a compile or build time if someone significant is missing. Yes it is unfortunate. It would be nice if NetBSD, FreeBSD, OpenBSD, and friends would collaborate. I think the majority of their changes are fixing build issues and making AWT/Swing use X11 instead of macOS-specific stuff (Quartz or Cocoa or whatever). Maybe I'll go poke them eventually. ------------- PR: https://git.openjdk.org/jdk/pull/12931 From duke at openjdk.org Fri Mar 10 14:34:31 2023 From: duke at openjdk.org (liach) Date: Fri, 10 Mar 2023 14:34:31 GMT Subject: RFR: 8294962: java.base jdk.internal.module package uses ASM to modify and write module-info.class [v3] In-Reply-To: References: Message-ID: <5uuMfD5PWv1BSlzjpn8sc_Ns4wiP5YvkcoVK2gjgcNQ=.f1116d9b-6627-48a2-b589-a402a08b28ca@github.com> On Fri, 10 Mar 2023 08:46:16 GMT, Adam Sotona wrote: >> 8294962: java.base jdk.internal.module package uses ASM to modify and write module-info.class. >> This patch converts it to use Classfile API. >> >> Please review. >> Thanks, >> Adam > > Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 198 commits: > > - ModuleInfoWriter fixes > - ModuleInfoExtender comment fix > - Merge branch 'master' into JDK-8294962-internal-module > - Update src/java.base/share/classes/jdk/internal/module/ModuleInfoExtender.java > > Co-authored-by: Mandy Chung > - Merge branch 'master' into JDK-8294962-internal-module > - fixed jdk.internal.classfile.java.lang.constant package name > - Merge branch 'JDK-8294982' into JDK-8294962 > - removed obsolete javadoc from implementation classes > - minor fix in CodeBuilder and added test cases to LDCTest > - EntryMap::nextPowerOfTwo delegates to Long:numberOfLeadingZeros > - ... and 188 more: https://git.openjdk.org/jdk/compare/e26cc526...9e366fbd src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java line 88: > 86: ModuleAttribute.of(ModuleDesc.of(md.name()), mb -> { > 87: mb.moduleFlags(md.modifiers().stream() > 88: .map(mm -> MODULE_MODS_TO_FLAGS.getOrDefault(mm, 0)) Should we use `mapToInt` instead of a plain `map`? Same for the other flags below. src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java line 124: > 122: > 123: // uses > 124: md.uses().stream().map(sn -> ClassDesc.of(sn)).forEach(mb::uses); map(ClassDesc::of).forEach(... src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java line 150: > 148: > 149: // write ModuleTarget attribute if there is a target platform > 150: if (target != null && target.targetPlatform().length() > 0) { `!target.targetPlatform().isEmpty()` is probably better than a length check. ------------- PR: https://git.openjdk.org/jdk/pull/11368 From fjiang at openjdk.org Fri Mar 10 14:42:15 2023 From: fjiang at openjdk.org (Feilong Jiang) Date: Fri, 10 Mar 2023 14:42:15 GMT Subject: RFR: 8303684: Lift upcall sharing mechanism to AbstractLinker (mainline) In-Reply-To: References: Message-ID: <7tjWTPktEEaaNNOfqL_NG4yHf5comTAIosztj2j7vSA=.949300db-b8e6-42b2-9a0a-fff60899d53d@github.com> On Mon, 6 Mar 2023 18:40:47 GMT, Jorn Vernee wrote: > Port of: https://github.com/openjdk/panama-foreign/pull/791 which lifts the sharing mechanism for upcall stubs to AbstractLinker. > > This also speeds up upcall stub linking: I'll submit a test on RISC-V board to see the results. It may take a while. ------------- PR: https://git.openjdk.org/jdk/pull/12883 From jvernee at openjdk.org Fri Mar 10 14:46:30 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 10 Mar 2023 14:46:30 GMT Subject: Integrated: 8303001: Add test for re-entrant upcalls In-Reply-To: References: Message-ID: On Wed, 8 Mar 2023 15:51:05 GMT, Jorn Vernee wrote: > Add a test that tests re-entrant upcalls, which is a use-case that is uncovered by testing until now. This pull request has now been integrated. Changeset: 6d30bbe6 Author: Jorn Vernee URL: https://git.openjdk.org/jdk/commit/6d30bbe62c10af0f2c80cb1eaac3d171fb7bffcb Stats: 122 lines in 2 files changed: 122 ins; 0 del; 0 mod 8303001: Add test for re-entrant upcalls Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.org/jdk/pull/12927 From turbanoff at gmail.com Fri Mar 10 15:05:41 2023 From: turbanoff at gmail.com (Andrey Turbanov) Date: Fri, 10 Mar 2023 18:05:41 +0300 Subject: Set thread names for threads created sun.nio.ch.AsynchronousChannelGroupImpl#startInternalThread Message-ID: Hello. I've noticed that in the method sun.nio.ch.AsynchronousChannelGroupImpl#startInternalThread JDK code creates threads with default names (Thread-1, Thread-2, etc). It's a good practice to set meaning thread names instead of default ones to simplify debugging and troubleshooting. I wonder if can we improve the method to set _something_ as a thread name? "Thread-3 at 4089" daemon prio=5 tid=0x41 nid=NA runnable java.lang.Thread.State: RUNNABLE at sun.nio.ch.Iocp.getQueuedCompletionStatus(Iocp.java:-1) at sun.nio.ch.Iocp$EventHandlerTask.run(Iocp.java:323) at sun.nio.ch.AsynchronousChannelGroupImpl$1.run(AsynchronousChannelGroupImpl.java:112) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.lang.Thread.run(Thread.java:829) Andrey Turbanov From asotona at openjdk.org Fri Mar 10 15:10:01 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 10 Mar 2023 15:10:01 GMT Subject: RFR: 8294962: java.base jdk.internal.module package uses ASM to modify and write module-info.class [v4] In-Reply-To: References: Message-ID: > 8294962: java.base jdk.internal.module package uses ASM to modify and write module-info.class. > This patch converts it to use Classfile API. > > Please review. > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: ModuleInfoWriter improvements ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11368/files - new: https://git.openjdk.org/jdk/pull/11368/files/9e366fbd..089220bc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11368&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11368&range=02-03 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/11368.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11368/head:pull/11368 PR: https://git.openjdk.org/jdk/pull/11368 From asotona at openjdk.org Fri Mar 10 15:10:08 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 10 Mar 2023 15:10:08 GMT Subject: RFR: 8294962: java.base jdk.internal.module package uses ASM to modify and write module-info.class [v3] In-Reply-To: <5uuMfD5PWv1BSlzjpn8sc_Ns4wiP5YvkcoVK2gjgcNQ=.f1116d9b-6627-48a2-b589-a402a08b28ca@github.com> References: <5uuMfD5PWv1BSlzjpn8sc_Ns4wiP5YvkcoVK2gjgcNQ=.f1116d9b-6627-48a2-b589-a402a08b28ca@github.com> Message-ID: On Fri, 10 Mar 2023 14:28:09 GMT, liach wrote: >> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 198 commits: >> >> - ModuleInfoWriter fixes >> - ModuleInfoExtender comment fix >> - Merge branch 'master' into JDK-8294962-internal-module >> - Update src/java.base/share/classes/jdk/internal/module/ModuleInfoExtender.java >> >> Co-authored-by: Mandy Chung >> - Merge branch 'master' into JDK-8294962-internal-module >> - fixed jdk.internal.classfile.java.lang.constant package name >> - Merge branch 'JDK-8294982' into JDK-8294962 >> - removed obsolete javadoc from implementation classes >> - minor fix in CodeBuilder and added test cases to LDCTest >> - EntryMap::nextPowerOfTwo delegates to Long:numberOfLeadingZeros >> - ... and 188 more: https://git.openjdk.org/jdk/compare/e26cc526...9e366fbd > > src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java line 88: > >> 86: ModuleAttribute.of(ModuleDesc.of(md.name()), mb -> { >> 87: mb.moduleFlags(md.modifiers().stream() >> 88: .map(mm -> MODULE_MODS_TO_FLAGS.getOrDefault(mm, 0)) > > Should we use `mapToInt` instead of a plain `map`? Same for the other flags below. yes, `mapToInt` seems to be better, thanks. > src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java line 124: > >> 122: >> 123: // uses >> 124: md.uses().stream().map(sn -> ClassDesc.of(sn)).forEach(mb::uses); > > map(ClassDesc::of).forEach(... fixed, thanks. > src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java line 150: > >> 148: >> 149: // write ModuleTarget attribute if there is a target platform >> 150: if (target != null && target.targetPlatform().length() > 0) { > > `!target.targetPlatform().isEmpty()` is probably better than a length check. fixed, thanks. ------------- PR: https://git.openjdk.org/jdk/pull/11368 From rriggs at openjdk.org Fri Mar 10 15:15:12 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 10 Mar 2023 15:15:12 GMT Subject: RFR: 8303392: Runtime.exec and ProcessBuilder.start should use System logger [v3] In-Reply-To: References: <-1i11ZrHHgzUbCSa_RXAcGKNfgtpdui--bltZ4Ujs2A=.f5f1a7e2-d3ec-4f64-9b1e-317ef2f24ef1@github.com> Message-ID: On Thu, 9 Mar 2023 20:24:11 GMT, Thomas Stuefe wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Revise logging of ProcessBuilder.start to support DEBUG and TRACE logging. >> Revise the implNote to include a warning about logging security sensistive information. >> DEBUG logs only the command, directory, stack trace, and pid. >> TRACE additionally logs arguments. > > test/jdk/java/lang/ProcessBuilder/ProcessStartLoggingTest.java line 81: > >> 79: File nullDirectory = null; >> 80: File thisDirectory = new File("."); >> 81: > > I started to heavily use different `@test` sections with speaking names instead of running a bunch of test in sequence; the advantage is better parallelization of tests, that I can omit printing out the test name manually (if the test name itself is speaking), and the ability to start individual tests manually. It does come with lots of test sections though. Speakable names can be a plus but I'll stick to the parameterized version for now. Are you refering to JUnit sections or Jtreg sections? ------------- PR: https://git.openjdk.org/jdk/pull/12862 From rriggs at openjdk.org Fri Mar 10 15:27:54 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 10 Mar 2023 15:27:54 GMT Subject: RFR: 8303392: Runtime.exec and ProcessBuilder.start should use System logger [v5] In-Reply-To: <-1i11ZrHHgzUbCSa_RXAcGKNfgtpdui--bltZ4Ujs2A=.f5f1a7e2-d3ec-4f64-9b1e-317ef2f24ef1@github.com> References: <-1i11ZrHHgzUbCSa_RXAcGKNfgtpdui--bltZ4Ujs2A=.f5f1a7e2-d3ec-4f64-9b1e-317ef2f24ef1@github.com> Message-ID: > Runtime.exec and ProcessBuilder.start methods create a new operating system process with the program and arguments. Many applications configure a logging subsystem to monitor application events. Logging a process start message with the program, arguments, and stack trace can identify the caller and purpose. > Logging the process start event is complementary to the process start event generated for JFR (Java Flight Recorder). Roger Riggs has updated the pull request incrementally with two additional commits since the last revision: - Fix one more implNote in Runtime - Improve implNote text in Runtime and ProcessBuilder ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12862/files - new: https://git.openjdk.org/jdk/pull/12862/files/0a5b1901..a073cc8d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12862&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12862&range=03-04 Stats: 11 lines in 2 files changed: 0 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/12862.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12862/head:pull/12862 PR: https://git.openjdk.org/jdk/pull/12862 From stuefe at openjdk.org Fri Mar 10 15:27:56 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 10 Mar 2023 15:27:56 GMT Subject: RFR: 8303392: Runtime.exec and ProcessBuilder.start should use System logger [v3] In-Reply-To: References: <-1i11ZrHHgzUbCSa_RXAcGKNfgtpdui--bltZ4Ujs2A=.f5f1a7e2-d3ec-4f64-9b1e-317ef2f24ef1@github.com> Message-ID: On Fri, 10 Mar 2023 15:11:50 GMT, Roger Riggs wrote: >> test/jdk/java/lang/ProcessBuilder/ProcessStartLoggingTest.java line 81: >> >>> 79: File nullDirectory = null; >>> 80: File thisDirectory = new File("."); >>> 81: >> >> I started to heavily use different `@test` sections with speaking names instead of running a bunch of test in sequence; the advantage is better parallelization of tests, that I can omit printing out the test name manually (if the test name itself is speaking), and the ability to start individual tests manually. It does come with lots of test sections though. > > Speakable names can be a plus but I'll stick to the parameterized version for now. > Are you refering to JUnit sections or Jtreg sections? jtreg sections, as in https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/gtest/MetaspaceGtests.java. I find them very practical, I just wish there were a way to condense them. ------------- PR: https://git.openjdk.org/jdk/pull/12862 From duke at openjdk.org Fri Mar 10 16:04:28 2023 From: duke at openjdk.org (Viktor Klang) Date: Fri, 10 Mar 2023 16:04:28 GMT Subject: Integrated: JDK-8302666: Replace CHM with VarHandle in ForeachOrderedTask In-Reply-To: References: Message-ID: On Tue, 31 Jan 2023 10:57:58 GMT, Viktor Klang wrote: > I noticed when looking at the code that there was no real need to use a CHM to perform the tracking of activation in an ordered fashion on ForEachOrderedTask, but instead a VarHandle can be used, reducing allocations and indirection. This pull request has now been integrated. Changeset: f2a36b4b Author: Viktor Klang Committer: Paul Sandoz URL: https://git.openjdk.org/jdk/commit/f2a36b4b529b1d74ca38633244dda092a15d50ac Stats: 26 lines in 1 file changed: 17 ins; 6 del; 3 mod 8302666: Replace CHM with VarHandle in ForeachOrderedTask Reviewed-by: psandoz ------------- PR: https://git.openjdk.org/jdk/pull/12320 From duke at openjdk.org Fri Mar 10 16:49:27 2023 From: duke at openjdk.org (Glavo) Date: Fri, 10 Mar 2023 16:49:27 GMT Subject: RFR: 8294962: java.base jdk.internal.module package uses ASM to modify and write module-info.class [v4] In-Reply-To: References: Message-ID: On Fri, 10 Mar 2023 15:10:01 GMT, Adam Sotona wrote: >> 8294962: java.base jdk.internal.module package uses ASM to modify and write module-info.class. >> This patch converts it to use Classfile API. >> >> Please review. >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > ModuleInfoWriter improvements The Classfile API looks great. I want to ask if you have any plans to completely replace all uses of `jdk.internal.org.objectweb.asm` and delete its source code from OpenJDK in a short time? ------------- PR: https://git.openjdk.org/jdk/pull/11368 From alanb at openjdk.org Fri Mar 10 17:35:31 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 10 Mar 2023 17:35:31 GMT Subject: RFR: 8294962: java.base jdk.internal.module package uses ASM to modify and write module-info.class [v4] In-Reply-To: References: Message-ID: On Fri, 10 Mar 2023 15:10:01 GMT, Adam Sotona wrote: >> 8294962: java.base jdk.internal.module package uses ASM to modify and write module-info.class. >> This patch converts it to use Classfile API. >> >> Please review. >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > ModuleInfoWriter improvements src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java line 157: > 155: var t = new InvalidModuleDescriptorException(iae.getMessage()); > 156: t.initCause(iae); > 157: throw t; Do happen to remember which test fails if you drop the catching of IAE? I'm asking because InvalidModuleDescriptorException is the exception when parsing a Module attribute, not when writing. ------------- PR: https://git.openjdk.org/jdk/pull/11368 From jlu at openjdk.org Fri Mar 10 17:36:13 2023 From: jlu at openjdk.org (Justin Lu) Date: Fri, 10 Mar 2023 17:36:13 GMT Subject: RFR: 8303917: Update ISO 639 language codes table Message-ID: This PR modifies `java.util.LocaleISOData.isoLanguageTable` to include (name only) changes from up-to-date [ISO 639 data](http://www.loc.gov/standards/iso639-2/php/code_list.php.). In addition, this PR updates the ISO 639 data (generated in 1999) in `Bug4175998Test.java`. This includes modifying the `generate_Tables() `function, since the source data is now stored in a different format. The outdated raw data stored in the bottom of the file was removed. ------------- Commit messages: - Minor changes / cleanup - Update ISO 639 test data - NC updates, revert Moldavian change - 2009-09-01 Name Change - 2008-11-03: Deprecate Moldavian/mo/mol Changes: https://git.openjdk.org/jdk/pull/12980/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12980&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303917 Stats: 843 lines in 2 files changed: 64 ins; 626 del; 153 mod Patch: https://git.openjdk.org/jdk/pull/12980.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12980/head:pull/12980 PR: https://git.openjdk.org/jdk/pull/12980 From jlu at openjdk.org Fri Mar 10 17:42:17 2023 From: jlu at openjdk.org (Justin Lu) Date: Fri, 10 Mar 2023 17:42:17 GMT Subject: Integrated: 8303853: Update ISO 3166 country codes table In-Reply-To: References: Message-ID: On Thu, 9 Mar 2023 17:50:32 GMT, Justin Lu wrote: > This PR incorporates all of the missing updates to ensure that `java.util.LocaleISOData.isoCountryTable` is on par with the official [ISO 3166 data](https://www.iso.org/obp/ui/#search/code/). This pull request has now been integrated. Changeset: a3358b10 Author: Justin Lu Committer: Naoto Sato URL: https://git.openjdk.org/jdk/commit/a3358b10cab44a97404aee8c1d07d580930fd199 Stats: 15 lines in 1 file changed: 0 ins; 0 del; 15 mod 8303853: Update ISO 3166 country codes table Reviewed-by: naoto ------------- PR: https://git.openjdk.org/jdk/pull/12954 From jlu at openjdk.org Fri Mar 10 17:43:23 2023 From: jlu at openjdk.org (Justin Lu) Date: Fri, 10 Mar 2023 17:43:23 GMT Subject: Integrated: 8299088: ClassLoader::defineClass2 throws OOME but JNI exception pending thrown by getUTF In-Reply-To: References: Message-ID: <6-gnEYK1Qr6V3cZnDD_01o09tdSvWlXAzow2wIoPYMM=.2ae0c17a-4df3-433a-868b-8035e26d5307@github.com> On Wed, 8 Mar 2023 22:02:22 GMT, Justin Lu wrote: > This PR removes the JNI Exception pending defect groups in ClassLoader.c. > > `getUTF()` throws an exception and subsequently returns `null`; the exception should either be cleared, or control returned to the JVM. `JNU_ThrowOutOfMemoryError(env, NULL);` should not be called again This pull request has now been integrated. Changeset: 6f54eda4 Author: Justin Lu Committer: Naoto Sato URL: https://git.openjdk.org/jdk/commit/6f54eda4a42a7c27c8eabbdc1c989de7cf246bdb Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod 8299088: ClassLoader::defineClass2 throws OOME but JNI exception pending thrown by getUTF Reviewed-by: mchung, naoto ------------- PR: https://git.openjdk.org/jdk/pull/12934 From mchung at openjdk.org Fri Mar 10 17:52:25 2023 From: mchung at openjdk.org (Mandy Chung) Date: Fri, 10 Mar 2023 17:52:25 GMT Subject: RFR: 8294966: jdk.jartool sun.tools.jar.FingerPrint uses ASM to parse class jar entries [v4] In-Reply-To: <28ICelV3yP7v0UEv3mCaFfCV5emQizFQbypc2Im8_EI=.2dbb5126-cbd2-4c23-b5c8-c656572e2182@github.com> References: <28ICelV3yP7v0UEv3mCaFfCV5emQizFQbypc2Im8_EI=.2dbb5126-cbd2-4c23-b5c8-c656572e2182@github.com> Message-ID: On Fri, 10 Mar 2023 12:31:22 GMT, Adam Sotona wrote: >> 8294966: jdk.jartool sun.tools.jar.FingerPrint uses ASM to parse class jar entries >> This patch converts it to use Classfile API. >> >> Please review. >> Thanks, >> Adam > > Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 199 commits: > > - Merge branch 'master' into JDK-8294966-jartool > - FingerPrint.maybeNestedClass set final > - Merge branch 'master' into JDK-8294966-jartool > - Merge branch 'master' into JDK-8294966-jartool > - FingerPrint fixes > Co-authored-by: Mandy Chung > - Update src/jdk.jartool/share/classes/sun/tools/jar/FingerPrint.java > > Co-authored-by: Mandy Chung > - Merge branch 'JDK-8294982' into JDK-8294966 > - removed obsolete javadoc from implementation classes > - minor fix in CodeBuilder and added test cases to LDCTest > - EntryMap::nextPowerOfTwo delegates to Long:numberOfLeadingZeros > - ... and 189 more: https://git.openjdk.org/jdk/compare/b1d89f30...240c0bfc Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11694 From mchung at openjdk.org Fri Mar 10 17:52:26 2023 From: mchung at openjdk.org (Mandy Chung) Date: Fri, 10 Mar 2023 17:52:26 GMT Subject: RFR: 8294966: jdk.jartool sun.tools.jar.FingerPrint uses ASM to parse class jar entries [v4] In-Reply-To: References: Message-ID: On Fri, 10 Mar 2023 07:51:55 GMT, Adam Sotona wrote: >> make/modules/jdk.jartool/Java.gmk line 28: >> >>> 26: DISABLED_WARNINGS_java += missing-explicit-ctor >>> 27: JAVAC_FLAGS += -XDstringConcat=inline >>> 28: JAVAC_FLAGS += --enable-preview >> >> This change is no longer needed. It's not a preview API. > > Unfortunately patterns in switch statements are still in preview. This flag and participation in preview can be removed once they are finalised. Thanks for the clarification. I forgot about that. ------------- PR: https://git.openjdk.org/jdk/pull/11694 From mullan at openjdk.org Fri Mar 10 17:55:16 2023 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 10 Mar 2023 17:55:16 GMT Subject: RFR: 8303392: Runtime.exec and ProcessBuilder.start should use System logger [v5] In-Reply-To: References: <-1i11ZrHHgzUbCSa_RXAcGKNfgtpdui--bltZ4Ujs2A=.f5f1a7e2-d3ec-4f64-9b1e-317ef2f24ef1@github.com> Message-ID: On Fri, 10 Mar 2023 15:27:54 GMT, Roger Riggs wrote: >> Runtime.exec and ProcessBuilder.start methods create a new operating system process with the program and arguments. Many applications configure a logging subsystem to monitor application events. Logging a process start message with the program, arguments, and stack trace can identify the caller and purpose. >> Logging the process start event is complementary to the process start event generated for JFR (Java Flight Recorder). > > Roger Riggs has updated the pull request incrementally with two additional commits since the last revision: > > - Fix one more implNote in Runtime > - Improve implNote text in Runtime and ProcessBuilder src/java.base/share/classes/java/lang/ProcessBuilder.java line 1302: > 1300: * > 1301: * @implNote > 1302: * Each created process is logged, see {@link ProcessBuilder#start()} for details. This reads as if it is logged by default. Perhaps reword as "Logging of the created process can be enabled, see ..." ------------- PR: https://git.openjdk.org/jdk/pull/12862 From alanb at openjdk.org Fri Mar 10 18:03:25 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 10 Mar 2023 18:03:25 GMT Subject: RFR: 8294962: java.base jdk.internal.module package uses ASM to modify and write module-info.class [v4] In-Reply-To: References: Message-ID: On Thu, 9 Mar 2023 17:59:55 GMT, Mandy Chung wrote: >> Yes, `Classfile::buildModule` contains logic determining if emission of `ModulePackages` is required or not. > > It'd be helpful to add a comment that `ModulePackages` attribute is only emitted if there are packages that aren't exported or open. The ModulePackages attribute is optional and an optimization to avoid scanning the module contents to get the full set of packages. Tooling that creates packaged modules (jar and jmod for now) will want the ModulePackages attribute emitted always. So maybe the Classfile.buildModule methods should be looked at again, at least I think the 2-arg and 3-arg methods should emit the ModulePackages unconditionally, the 1-arg buildModule maybe not. This isn't an issue for ModuleInfoWriter of course as it is only used by tests. ------------- PR: https://git.openjdk.org/jdk/pull/11368 From mchung at openjdk.org Fri Mar 10 18:19:10 2023 From: mchung at openjdk.org (Mandy Chung) Date: Fri, 10 Mar 2023 18:19:10 GMT Subject: RFR: 8303485: Replacing os.name for operating system customization In-Reply-To: References: Message-ID: On Fri, 10 Mar 2023 14:01:04 GMT, Alan Bateman wrote: >> Improvements to support OS specific customization for JDK internal use: >> - To select values and code; allowing elimination of unused code and values >> - Optionally evaluated by build processes, compilation, or archiving (i.e. CDS) >> - Simple API to replace adhoc comparisons with `os.name` >> - Clear and consistent use across build, runtime, and JDK modules >> >> The PR includes updates within java.base to use the new API. > > src/java.base/share/classes/jdk/internal/misc/OperatingSystem.java line 23: > >> 21: * questions. >> 22: */ >> 23: package jdk.internal.misc; > > I see there is a follow on PR to see this in several modules. We can't have jdk.internal.misc exported widely as it contains Unsafe and several other important classes. jdk.internal.util may be a better place, at the same of turning that package into a place for random stuff. Agree. `jdk.internal.platform` can be one option. It can be extended to include platform-related utilities beyond containers. ------------- PR: https://git.openjdk.org/jdk/pull/12931 From mchung at openjdk.org Fri Mar 10 19:44:15 2023 From: mchung at openjdk.org (Mandy Chung) Date: Fri, 10 Mar 2023 19:44:15 GMT Subject: RFR: 8294962: Convert java.base/jdk.internal.module package to use the Classfile API to modify and write module-info.class [v4] In-Reply-To: References: Message-ID: On Fri, 10 Mar 2023 17:59:20 GMT, Alan Bateman wrote: >> It'd be helpful to add a comment that `ModulePackages` attribute is only emitted if there are packages that aren't exported or open. > > The ModulePackages attribute is optional and an optimization to avoid scanning the module contents to get the full set of packages. Tooling that creates packaged modules (jar and jmod for now) will want the ModulePackages attribute emitted always. So maybe the Classfile.buildModule methods should be looked at again, at least I think the 2-arg and 3-arg methods should emit the ModulePackages unconditionally, the 1-arg buildModule maybe not. This isn't an issue for ModuleInfoWriter of course as it is only used by tests. `buildModules` is expected to be called with additional packages but instead it's called with all packages including all exported and open packages. /** * Build a module descriptor into a byte array. * @param moduleAttribute the {@code Module} attribute * @param packages additional module packages * @param handler a handler that receives a {@link ClassBuilder} * @return the classfile bytes */ public static byte[] buildModule(ModuleAttribute moduleAttribute, List packages, Consumer handler) { I checked the implementation that seems to match `@param packages` that expects additional module packages that are not exported nor open. If it intends to take additional packages, it will need to filter the exported and open packages at the callsite. Or the `packages` parameter lists all packages that will be used to create `ModulePackages` attribute. This seems to be easier to understand. ------------- PR: https://git.openjdk.org/jdk/pull/11368 From duke at openjdk.org Fri Mar 10 21:12:01 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Fri, 10 Mar 2023 21:12:01 GMT Subject: RFR: 8303891: Zip64SizeTest could use a sparse file [v4] In-Reply-To: References: Message-ID: > This PR suggests we use a sparse file when the Zip64SizeTest writes a ZIP file with a 5GB entry. > > The size requirement of this test is known to cause problems in some builds, see [JDK-8259866](https://bugs.openjdk.org/browse/JDK-8259866) > > Using a sparse file reduces the disk space requirements of running the test from 5GB to 12K and also reduces the runtime from ~35 seconds to ~3 seconds on my Macbook Pro. Eirik Bjorsnos 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 eight additional commits since the last revision: - Sparse files must be created explicitly on NTFS - Merge branch 'master' into zip64-size-test-sparse - Merge branch 'master' into zip64-size-test-sparse - Make test method public - Add a missing "when" in Javadocs for SparseOutputStream - Remove introduced blank line - Remove double whitespace - Rewrite Zip64SizeTest to write to a sparse file ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12948/files - new: https://git.openjdk.org/jdk/pull/12948/files/883f543f..adcca52c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12948&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12948&range=02-03 Stats: 8146 lines in 184 files changed: 1024 ins; 1302 del; 5820 mod Patch: https://git.openjdk.org/jdk/pull/12948.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12948/head:pull/12948 PR: https://git.openjdk.org/jdk/pull/12948 From rriggs at openjdk.org Fri Mar 10 21:12:35 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 10 Mar 2023 21:12:35 GMT Subject: RFR: 8303648: Add String.indexOf(String str, int beginIndex, int endIndex) [v2] In-Reply-To: <68mrLyEKJSdenIkvsv1kP6Hbpv5xoRzk8_y-s3flYuk=.f21057a2-2ee2-4844-9f31-0c9300ba4d73@github.com> References: <68mrLyEKJSdenIkvsv1kP6Hbpv5xoRzk8_y-s3flYuk=.f21057a2-2ee2-4844-9f31-0c9300ba4d73@github.com> Message-ID: On Fri, 10 Mar 2023 13:35:27 GMT, Raffaello Giulietti wrote: >> As a followup of [JDK-8302590](https://bugs.openjdk.org/browse/JDK-8302590), this issue covers the analogous case for a search of a string rather than a character. > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > 8303648: Add String.indexOf(String str, int beginIndex, int endIndex) > > Moved @apiNote on indexOf(String,int) before @param/@return. > Rephrased first sentence of indexOf(String,int,int). Marked as reviewed by rriggs (Reviewer). src/java.base/share/classes/java/lang/String.java line 2619: > 2617: * If stricter behavior is needed, {@link #indexOf(String, int, int)} > 2618: * should be considered instead. > 2619: * On {@link String}s {@code s} and a non-empty {@code str}, for example, Is both the normal font "s" and the code font "s" needed. I reads ok as "On String s and a non-empty str,"... ------------- PR: https://git.openjdk.org/jdk/pull/12903 From rriggs at openjdk.org Fri Mar 10 21:21:56 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 10 Mar 2023 21:21:56 GMT Subject: RFR: 8303485: Replacing os.name for operating system customization [v2] In-Reply-To: References: Message-ID: > Improvements to support OS specific customization for JDK internal use: > - To select values and code; allowing elimination of unused code and values > - Optionally evaluated by build processes, compilation, or archiving (i.e. CDS) > - Simple API to replace adhoc comparisons with `os.name` > - Clear and consistent use across build, runtime, and JDK modules > > The PR includes updates within java.base to use the new API. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Move OperatingSystem from jdk.internal.misc to jdk.internal.util Rename Mac -> MacOS; isMac() -> isMacOS() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12931/files - new: https://git.openjdk.org/jdk/pull/12931/files/736ab3cc..342f30f2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12931&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12931&range=00-01 Stats: 467 lines in 15 files changed: 210 ins; 235 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/12931.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12931/head:pull/12931 PR: https://git.openjdk.org/jdk/pull/12931 From rriggs at openjdk.org Fri Mar 10 21:34:56 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 10 Mar 2023 21:34:56 GMT Subject: RFR: 8303392: Runtime.exec and ProcessBuilder.start should use System logger [v6] In-Reply-To: <-1i11ZrHHgzUbCSa_RXAcGKNfgtpdui--bltZ4Ujs2A=.f5f1a7e2-d3ec-4f64-9b1e-317ef2f24ef1@github.com> References: <-1i11ZrHHgzUbCSa_RXAcGKNfgtpdui--bltZ4Ujs2A=.f5f1a7e2-d3ec-4f64-9b1e-317ef2f24ef1@github.com> Message-ID: > Runtime.exec and ProcessBuilder.start methods create a new operating system process with the program and arguments. Many applications configure a logging subsystem to monitor application events. Logging a process start message with the program, arguments, and stack trace can identify the caller and purpose. > Logging the process start event is complementary to the process start event generated for JFR (Java Flight Recorder). Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Reword @implNote to indicate logging can be enabled. (But is not by default) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12862/files - new: https://git.openjdk.org/jdk/pull/12862/files/a073cc8d..47c3ab63 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12862&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12862&range=04-05 Stats: 7 lines in 2 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/12862.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12862/head:pull/12862 PR: https://git.openjdk.org/jdk/pull/12862 From mchung at openjdk.org Fri Mar 10 21:48:17 2023 From: mchung at openjdk.org (Mandy Chung) Date: Fri, 10 Mar 2023 21:48:17 GMT Subject: RFR: 8294972: Convert jdk.jlink internal plugins to use the Classfile API [v4] In-Reply-To: References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> Message-ID: On Fri, 10 Mar 2023 12:45:05 GMT, Adam Sotona wrote: >> jdk.jlink internal plugins are heavily using ASM >> >> This patch converts ASM calls to Classfile API. >> >> Please review. >> Thanks, >> Adam > > Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 208 commits: > > - Merge branch 'master' into JDK-8294972-jlink-plugins > > # Conflicts: > # src/java.base/share/classes/module-info.java > - Merge branch 'master' into JDK-8294972-jlink-plugins > - fixed SystemModulesPlugin formatting > - 8303624: The java.lang.Thread.FieldHolder can be null for JNI attaching threads > > Reviewed-by: alanb, dcubed > - 8302360: Atomic*.compareAndExchange Javadoc unclear > > Reviewed-by: martin, dholmes > - 8302779: HelidonAppTest.java fails with "assert(_cb == CodeCache::find_blob(pc())) failed: Must be the same" or SIGSEGV > > Reviewed-by: coleenp, sspitsyn > - 8303691: Fedora based devkit build should load more packages from archive location > > Reviewed-by: mbaesken, erikj > - 8303924: ProblemList serviceability/sa/UniqueVtableTest.java on Linux > > Reviewed-by: dcubed > - 8303609: ProblemList serviceability/sa/TestSysProps.java with ZGC > > Reviewed-by: dcubed > - 8289765: JDI EventSet/resume/resume008 failed with "ERROR: suspendCounts don't match for : VirtualThread-unparker" > > Reviewed-by: sspitsyn, kevinw > - ... and 198 more: https://git.openjdk.org/jdk/compare/b1d89f30...cfc612ec src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/VersionPropsPlugin.java line 158: > 156: }); > 157: } > 158: }); Suggestion: }); } else { clb.with(cle); Other `ClassElement`s need to be added to the builder; otherwise they are dropped. One more thing I notice is that the attributes for example `LineNumberTable` attribute in `` method after transformed are dropped. But this plugin should only transform the code and leave everything else touched. ------------- PR: https://git.openjdk.org/jdk/pull/12944 From rriggs at openjdk.org Fri Mar 10 22:05:16 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 10 Mar 2023 22:05:16 GMT Subject: RFR: 8303814: getLastErrorString should avoid charset conversions In-Reply-To: References: Message-ID: On Wed, 8 Mar 2023 11:30:27 GMT, Daniel Jeli?ski wrote: > This patch modifies the `getLastErrorString` method to return a `jstring`. Thanks to that we can avoid unnecessary back and forth conversions between Unicode and other charsets on Windows. > > Other changes include: > - the Windows implementation of `getLastErrorString` no longer checks `errno`. I verified all uses of the method and confirmed that `errno` is not used anywhere. > - While at it, I found and fixed a few calls to `JNU_ThrowIOExceptionWithLastError` that were done in context where `LastError` was not set. > - jdk.hotspot.agent was modified to use `JNU_ThrowByNameWithLastError` and `JNU_ThrowByName` instead of `getLastErrorString`; the code is expected to have identical behavior. > - zip_util was modified to return static messages instead of generated ones. The generated messages were not observed anywhere, because they were replaced by a static message in ZIP_Open, which is the only method used by other native code. > - `getLastErrorString` is no longer exported by libjava. > > Tier1-3 tests continue to pass. > > No new automated regression test; testing this requires installing a language pack that cannot be displayed in the current code page. > Tested this manually by installing Chinese language pack on English Windows 11, selecting Chinese language, then checking if the message on exception thrown by `InetAddress.getByName("nonexistent.local");` starts with `"?????????"` (or `"\u4e0d\u77e5\u9053\u8fd9\u6837\u7684\u4e3b\u673a\u3002"`). Without the change, the exception message started with a row of question marks. src/java.base/share/native/libjava/jni_util.c line 133: > 131: if (s != NULL) { > 132: jobject x = NULL; > 133: if (messagelen) { Avoid implicit compare with 0; use `messagelen > 0` or similar. src/java.base/share/native/libjava/jni_util.c line 137: > 135: size_t messageextlen = messagelen + 4; > 136: char *str1 = (char *)malloc((messageextlen) * sizeof(char)); > 137: if (str1 == 0) { Use NULL when comparing to a pointer. src/java.base/unix/native/libjava/jni_util_md.c line 69: > 67: if (errno == 0) return NULL; > 68: getErrorString(errno, buf, sizeof(buf)); > 69: return (*buf) ? JNU_NewStringPlatform(env, buf) : NULL; I would have used `buf[0] != 0` since its declared as a local buffer; but this file doesn't have much of a style to follow. ------------- PR: https://git.openjdk.org/jdk/pull/12922 From mchung at openjdk.org Fri Mar 10 22:16:49 2023 From: mchung at openjdk.org (Mandy Chung) Date: Fri, 10 Mar 2023 22:16:49 GMT Subject: RFR: 8294972: Convert jdk.jlink internal plugins to use the Classfile API [v4] In-Reply-To: References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> Message-ID: On Fri, 10 Mar 2023 12:45:05 GMT, Adam Sotona wrote: >> jdk.jlink internal plugins are heavily using ASM >> >> This patch converts ASM calls to Classfile API. >> >> Please review. >> Thanks, >> Adam > > Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 208 commits: > > - Merge branch 'master' into JDK-8294972-jlink-plugins > > # Conflicts: > # src/java.base/share/classes/module-info.java > - Merge branch 'master' into JDK-8294972-jlink-plugins > - fixed SystemModulesPlugin formatting > - 8303624: The java.lang.Thread.FieldHolder can be null for JNI attaching threads > > Reviewed-by: alanb, dcubed > - 8302360: Atomic*.compareAndExchange Javadoc unclear > > Reviewed-by: martin, dholmes > - 8302779: HelidonAppTest.java fails with "assert(_cb == CodeCache::find_blob(pc())) failed: Must be the same" or SIGSEGV > > Reviewed-by: coleenp, sspitsyn > - 8303691: Fedora based devkit build should load more packages from archive location > > Reviewed-by: mbaesken, erikj > - 8303924: ProblemList serviceability/sa/UniqueVtableTest.java on Linux > > Reviewed-by: dcubed > - 8303609: ProblemList serviceability/sa/TestSysProps.java with ZGC > > Reviewed-by: dcubed > - 8289765: JDI EventSet/resume/resume008 failed with "ERROR: suspendCounts don't match for : VirtualThread-unparker" > > Reviewed-by: sspitsyn, kevinw > - ... and 198 more: https://git.openjdk.org/jdk/compare/b1d89f30...cfc612ec src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/StripJavaDebugAttributesPlugin.java line 62: > 60: // XXX. Do we have debug info? Is Asm ready for module-info? > 61: } else { > 62: byte[] content = newClassReader(path, resource, Classfile.Option.processDebug(false)) ASM `ClassReader.SKIP_DEBUG` flag indicates to skip the SourceFile, SourceDebugExtension, LocalVariableTable, LocalVariableTypeTable, LineNumberTable and MethodParameters attributes. `Classfile.Option.processDebug(false)` only skips LocalVariableTable, LocalVariableTypeTable, CHARACTER_RANGE_TABLE attributes. To implement the same behavior as `SKIP_DEBUG`, it needs `Classfile.Option.processLineNumbers(false)` and skipping other attributes. ------------- PR: https://git.openjdk.org/jdk/pull/12944 From naoto at openjdk.org Fri Mar 10 22:17:30 2023 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 10 Mar 2023 22:17:30 GMT Subject: RFR: 8303917: Update ISO 639 language codes table In-Reply-To: References: Message-ID: On Fri, 10 Mar 2023 17:27:11 GMT, Justin Lu wrote: > This PR modifies `java.util.LocaleISOData.isoLanguageTable` to include (name only) changes from up-to-date [ISO 639 data](http://www.loc.gov/standards/iso639-2/php/code_list.php.). > > In addition, this PR updates the ISO 639 data (generated in 1999) in `Bug4175998Test.java`. This includes modifying the `generate_Tables() `function, since the source data is now stored in a different format. The outdated raw data stored in the bottom of the file was removed. Looks good. test/jdk/java/util/Locale/Bug4175998Test.java line 284: > 282: System.out.print("\""+iso639_2B+"\","); > 283: System.out.print("\""+iso639_2T+"\""); > 284: System.out.println("},"); Could be simplified like System.out.printf(""" {"%s","%s","%s"}, """, iso639_1, iso639_2B, iso639_2T); ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.org/jdk/pull/12980 From kvn at openjdk.org Sat Mar 11 00:18:22 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Sat, 11 Mar 2023 00:18:22 GMT Subject: RFR: 8303022: "assert(allocates2(pc)) failed: not in CodeBuffer memory" When linking downcall handle [v3] In-Reply-To: References: Message-ID: On Fri, 10 Mar 2023 14:14:55 GMT, Jorn Vernee wrote: >> The issue is that the size of the code buffer is not large enough to hold the whole stub. >> >> Proposed solution is to scale the size of the stub with the number of arguments. I've adjusted sizes for both downcall and upcall stubs. I've also dropped the number of relocations, since we're not really using any for downcalls, and for upcalls we only have 1 AFAICS. (the size of the relocations can not be zero however, as that leads to the relocation section [not being initialized][1], and triggering [an assert][2] later when the code blob is copied). >> >> The way I've determined the new base size and per-argument size for stubs, is by first linking a stub without any arguments to get the required base size, and by then adding 20 `double` arguments to get a rough per-argument size. Both values have wiggle room as well. The sizes can be printed using e.g. `-XX:+LogCompilation`, and then looking for `nep_invoker_blob` and `upcall_stub*` in the log file. This experiment was done on a fastdebug build to account for additional debug code being generated. The included test is designed to try and maximize the size of the generated stub. >> >> I've also updated `CodeBuffer::log_section_sizes` to print the in-use size, rather than just the capacity and free space. >> >> [1]: https://github.com/openjdk/jdk/blob/56512cfe1f0682c98ba3488af3d03ccef632c016/src/hotspot/share/asm/codeBuffer.cpp#L119-L121 >> [2]: https://github.com/openjdk/jdk/blob/56512cfe1f0682c98ba3488af3d03ccef632c016/src/hotspot/share/asm/codeBuffer.cpp#L675 > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > RISCV changes Good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.org/jdk/pull/12908 From asemenyuk at openjdk.org Sat Mar 11 01:02:25 2023 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Sat, 11 Mar 2023 01:02:25 GMT Subject: RFR: 8299779: Test tools/jpackage/share/jdk/jpackage/tests/MainClassTest.java timed out In-Reply-To: <6VsQikMFY5Fckwv8WB39RDFR5gzqkSwtJOXeF3IEbcg=.0ab0a46e-400c-4383-a0e8-e99d78df54e8@github.com> References: <6VsQikMFY5Fckwv8WB39RDFR5gzqkSwtJOXeF3IEbcg=.0ab0a46e-400c-4383-a0e8-e99d78df54e8@github.com> Message-ID: <_N-hw3wgh2jpg8pKhBxRIEqh8nDKj9TdyZq8ggwxYbE=.829fee29-7a72-4b3b-979f-a57b0eb17569@github.com> On Tue, 7 Mar 2023 00:56:02 GMT, Alexander Matveev wrote: > - Fixed by increasing test timeout. Fix verified on host which reproduced issue. Marked as reviewed by asemenyuk (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12896 From asemenyuk at openjdk.org Sat Mar 11 01:03:21 2023 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Sat, 11 Mar 2023 01:03:21 GMT Subject: RFR: 8299779: Test tools/jpackage/share/jdk/jpackage/tests/MainClassTest.java timed out In-Reply-To: <6VsQikMFY5Fckwv8WB39RDFR5gzqkSwtJOXeF3IEbcg=.0ab0a46e-400c-4383-a0e8-e99d78df54e8@github.com> References: <6VsQikMFY5Fckwv8WB39RDFR5gzqkSwtJOXeF3IEbcg=.0ab0a46e-400c-4383-a0e8-e99d78df54e8@github.com> Message-ID: <_N-hw3wgh2jpg8pKhBxRIEqh8nDKj9TdyZq8ggwxYbE=.b588a009-eda1-4ba6-84d5-1a90e2494ba4@github.com> On Tue, 7 Mar 2023 00:56:02 GMT, Alexander Matveev wrote: > - Fixed by increasing test timeout. Fix verified on host which reproduced issue. Marked as reviewed by asemenyuk (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12896 From almatvee at openjdk.org Sat Mar 11 01:07:30 2023 From: almatvee at openjdk.org (Alexander Matveev) Date: Sat, 11 Mar 2023 01:07:30 GMT Subject: Integrated: 8299779: Test tools/jpackage/share/jdk/jpackage/tests/MainClassTest.java timed out In-Reply-To: <6VsQikMFY5Fckwv8WB39RDFR5gzqkSwtJOXeF3IEbcg=.0ab0a46e-400c-4383-a0e8-e99d78df54e8@github.com> References: <6VsQikMFY5Fckwv8WB39RDFR5gzqkSwtJOXeF3IEbcg=.0ab0a46e-400c-4383-a0e8-e99d78df54e8@github.com> Message-ID: <_jLoVF88ZEGEEmBnJORCS86SKa-rdcn3p89QC9qE4_0=.f5da87a1-9417-4f0f-839a-06d94c63d9d7@github.com> On Tue, 7 Mar 2023 00:56:02 GMT, Alexander Matveev wrote: > - Fixed by increasing test timeout. Fix verified on host which reproduced issue. This pull request has now been integrated. Changeset: 0a4d54f7 Author: Alexander Matveev URL: https://git.openjdk.org/jdk/commit/0a4d54f7ce2ac906a8012ed92c84ed8303cb4b90 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8299779: Test tools/jpackage/share/jdk/jpackage/tests/MainClassTest.java timed out Reviewed-by: asemenyuk ------------- PR: https://git.openjdk.org/jdk/pull/12896 From jvernee at openjdk.org Sat Mar 11 02:23:25 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Sat, 11 Mar 2023 02:23:25 GMT Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function & Memory API (Preview) [v3] In-Reply-To: References: <8b3vVrV22RuhdRoRYacXV0ZeghFGgKkC8S_z-iMrzAQ=.dd84b743-8b51-4281-8f5f-f9eff6207bc7@github.com> Message-ID: <0RrqDfVTh0EmUK3xCInQa1gXbZwdLpd_jY-3TYgdqwo=.e1ca03f4-8e66-4d3d-97f2-59f5bbd7287b@github.com> On Fri, 3 Mar 2023 10:59:32 GMT, Martin Doerr wrote: >> Thanks! I need to find extra time for this. Sounds like a good idea and I may be able to get rid of some nasty code. > > Done by https://github.com/openjdk/jdk/pull/12708/commits/98e242c24c07ea977b7709b9f8d0c10ce87e84c0 (using a record instead of a `VMStorage[][]` because I think this is better readable). Note that it's a bit more complicated. I couldn't use your `dup` trick, because I need to put the value into a GP reg and one half of it to a FP reg. The Panama code doesn't support that (IllegalArgumentException: Invalid operand type: interface java.lang.foreign.MemorySegment. float expected). Thanks, your solution looks good. ------------- PR: https://git.openjdk.org/jdk/pull/12708 From jvernee at openjdk.org Sat Mar 11 02:23:24 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Sat, 11 Mar 2023 02:23:24 GMT Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function & Memory API (Preview) [v3] In-Reply-To: References: <8b3vVrV22RuhdRoRYacXV0ZeghFGgKkC8S_z-iMrzAQ=.dd84b743-8b51-4281-8f5f-f9eff6207bc7@github.com> Message-ID: On Thu, 9 Mar 2023 17:40:02 GMT, Martin Doerr wrote: >> @TheRealMDoerr I've moved the support for structs/unions that are not a power of 2 in size to this repo, so you should be able to merge the master branch to get it now. > > @JornVernee: Thanks! I've merged in your changes. TestArrayStructs is not yet completely working. I will need to investigate. I think I've done most other things you had requested. You may want to take a look at my recent commits. @TheRealMDoerr I've been keeping up with the changes you're making. I just have to look at the new test for HFA's you've added you added (next week). Besides fixing the TestArrayStructs test, do you have anything else you still want to add to this PR? ------------- PR: https://git.openjdk.org/jdk/pull/12708 From fyang at openjdk.org Sat Mar 11 02:44:20 2023 From: fyang at openjdk.org (Fei Yang) Date: Sat, 11 Mar 2023 02:44:20 GMT Subject: RFR: 8303863: RISC-V: TestArrayStructs.java fails after JDK-8303604 In-Reply-To: References: Message-ID: On Thu, 9 Mar 2023 14:39:55 GMT, Feilong Jiang wrote: > [JDK-8303604](https://bugs.openjdk.org/browse/JDK-8303604) fixes an issue with passing structs whose size is not a power of two on SysV and AArch64 platforms. The same issue happens on RISC-V. > > Modifications are unnecessary for `STRUCT_REGISTER_F` and `STRUCT_REGISTER_XF`. If there are no available registers, they will fall back to `STRUCT_REGISTER_X`. > > Testing: > > - [x] TestArrayStructs.java > - [x] jdk_foreign on Unmatched Board (release build) Looks fine to me. ------------- Marked as reviewed by fyang (Reviewer). PR: https://git.openjdk.org/jdk/pull/12950 From fjiang at openjdk.org Sat Mar 11 02:50:20 2023 From: fjiang at openjdk.org (Feilong Jiang) Date: Sat, 11 Mar 2023 02:50:20 GMT Subject: RFR: 8303863: RISC-V: TestArrayStructs.java fails after JDK-8303604 In-Reply-To: References: Message-ID: <8T9Rzc_WPjPWHJ8uOfNB9KEvZ9awXGAJmLALZGRq7B0=.a0160886-202c-4d09-a2e8-edd67ab76c71@github.com> On Thu, 9 Mar 2023 15:07:55 GMT, Jorn Vernee wrote: >> [JDK-8303604](https://bugs.openjdk.org/browse/JDK-8303604) fixes an issue with passing structs whose size is not a power of two on SysV and AArch64 platforms. The same issue happens on RISC-V. >> >> Modifications are unnecessary for `STRUCT_REGISTER_F` and `STRUCT_REGISTER_XF`. If there are no available registers, they will fall back to `STRUCT_REGISTER_X`. >> >> Testing: >> >> - [x] TestArrayStructs.java >> - [x] jdk_foreign on Unmatched Board (release build) > > LGTM @JornVernee @RealFYang -- Thanks! ------------- PR: https://git.openjdk.org/jdk/pull/12950 From duke at openjdk.org Sat Mar 11 03:35:04 2023 From: duke at openjdk.org (liach) Date: Sat, 11 Mar 2023 03:35:04 GMT Subject: RFR: 8288730: Lookup::accessClass(Class) should be generic on the type of `targetClass` Message-ID: Parameterizes `Lookup::accessClass` and `Lookup::ensureInitialized`. Updated an applicable use-site within JDK to benefit from this patch. ------------- Commit messages: - update use sites - 8288730: `Lookup::accessClass(Class)` should be generic on the type of `targetClass` Changes: https://git.openjdk.org/jdk/pull/12984/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12984&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8288730 Stats: 6 lines in 2 files changed: 2 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/12984.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12984/head:pull/12984 PR: https://git.openjdk.org/jdk/pull/12984 From joehw at openjdk.org Sat Mar 11 04:35:51 2023 From: joehw at openjdk.org (Joe Wang) Date: Sat, 11 Mar 2023 04:35:51 GMT Subject: RFR: 8303530: Add system property for custom JAXP configuration file Message-ID: Add a system property, jdk.xml.config.file, to return the path to a custom JAXP configuration file. The current configuration file, jaxp.properties, that the JDK supports will become the default configuration file. CSR: https://bugs.openjdk.org/browse/JDK-8303531 Tests: XML SQE and JCK tests passed. ------------- Commit messages: - 8303530: Add system property for custom JAXP configuration file Changes: https://git.openjdk.org/jdk/pull/12985/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12985&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303530 Stats: 2087 lines in 38 files changed: 1652 ins; 284 del; 151 mod Patch: https://git.openjdk.org/jdk/pull/12985.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12985/head:pull/12985 PR: https://git.openjdk.org/jdk/pull/12985 From fjiang at openjdk.org Sat Mar 11 04:51:28 2023 From: fjiang at openjdk.org (Feilong Jiang) Date: Sat, 11 Mar 2023 04:51:28 GMT Subject: Integrated: 8303863: RISC-V: TestArrayStructs.java fails after JDK-8303604 In-Reply-To: References: Message-ID: On Thu, 9 Mar 2023 14:39:55 GMT, Feilong Jiang wrote: > [JDK-8303604](https://bugs.openjdk.org/browse/JDK-8303604) fixes an issue with passing structs whose size is not a power of two on SysV and AArch64 platforms. The same issue happens on RISC-V. > > Modifications are unnecessary for `STRUCT_REGISTER_F` and `STRUCT_REGISTER_XF`. If there are no available registers, they will fall back to `STRUCT_REGISTER_X`. > > Testing: > > - [x] TestArrayStructs.java > - [x] jdk_foreign on Unmatched Board (release build) This pull request has now been integrated. Changeset: 98a7a60f Author: Feilong Jiang Committer: Fei Yang URL: https://git.openjdk.org/jdk/commit/98a7a60fcb7d1efdba60438df3c468f5320fb64c Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8303863: RISC-V: TestArrayStructs.java fails after JDK-8303604 Reviewed-by: jvernee, fyang ------------- PR: https://git.openjdk.org/jdk/pull/12950 From duke at openjdk.org Sat Mar 11 05:07:55 2023 From: duke at openjdk.org (liach) Date: Sat, 11 Mar 2023 05:07:55 GMT Subject: RFR: 8284871: Use covariant overrides for the resolveConstantDesc(Lookup) method in =?UTF-8?B?c3Vi4oCRaW50ZXJmYWNlcw==?= of java.lang.constant.ConstantDesc Message-ID: <6elA1YOQCqZutbsRVG89Q0C_5-3zu-OHco8_h2z5mKg=.a313ea66-e58d-401b-88a8-c843dcecf218@github.com> Also remove redundant casts to avoid javac warnings. ------------- Commit messages: - Move MethodTypeDesc api notes to MethodTypeDesc - Merge branch 'master' of https://git.openjdk.java.net/jdk into constdesc-override - Remove redundant casts - Covariant override of resolveConstantDesc for Class/MethodType/MethodHandleDesc Changes: https://git.openjdk.org/jdk/pull/12986/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12986&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8284871 Stats: 28 lines in 8 files changed: 18 ins; 4 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/12986.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12986/head:pull/12986 PR: https://git.openjdk.org/jdk/pull/12986 From joehw at openjdk.org Sat Mar 11 05:34:39 2023 From: joehw at openjdk.org (Joe Wang) Date: Sat, 11 Mar 2023 05:34:39 GMT Subject: RFR: 8303530: Add system property for custom JAXP configuration file [v2] In-Reply-To: References: Message-ID: > Add a system property, jdk.xml.config.file, to return the path to a custom JAXP configuration file. The current configuration file, jaxp.properties, that the JDK supports will become the default configuration file. > > CSR: https://bugs.openjdk.org/browse/JDK-8303531 > > Tests: XML SQE and JCK tests passed. Joe Wang has updated the pull request incrementally with one additional commit since the last revision: clean up tests; fix copy&paste error. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12985/files - new: https://git.openjdk.org/jdk/pull/12985/files/7be41bcd..014d99fd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12985&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12985&range=00-01 Stats: 56 lines in 17 files changed: 1 ins; 40 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/12985.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12985/head:pull/12985 PR: https://git.openjdk.org/jdk/pull/12985 From aturbanov at openjdk.org Sat Mar 11 08:16:22 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Sat, 11 Mar 2023 08:16:22 GMT Subject: RFR: 8303684: Lift upcall sharing mechanism to AbstractLinker (mainline) In-Reply-To: References: Message-ID: On Mon, 6 Mar 2023 18:40:47 GMT, Jorn Vernee wrote: > Port of: https://github.com/openjdk/panama-foreign/pull/791 which lifts the sharing mechanism for upcall stubs to AbstractLinker. > > This also speeds up upcall stub linking: src/java.base/share/classes/jdk/internal/foreign/abi/aarch64/windows/WindowsAArch64Linker.java line 61: > 59: @Override > 60: protected UpcallStubFactory arrangeUpcall(MethodType targetType, FunctionDescriptor function) { > 61: return CallArranger.WINDOWS.arrangeUpcall(targetType, function); Suggestion: return CallArranger.WINDOWS.arrangeUpcall(targetType, function); ------------- PR: https://git.openjdk.org/jdk/pull/12883 From duke at openjdk.org Sat Mar 11 08:27:06 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Sat, 11 Mar 2023 08:27:06 GMT Subject: RFR: 8303920: Avoid calling out to python in DataDescriptorSignatureMissing test [v6] In-Reply-To: References: Message-ID: > Please review this PR which brings the DataDescriptorSignatureMissing test back to life. > > This test currently calls out to Python to create a test vector ZIP with a Data Descriptor without the recommended but optional signature. The Python dependency has turned out to be very brittle, so the test is currently marked with `@ignore` > > The PR replaces Python callouts with directly creating the test vector ZIP in the test itself. We can then remove the `@ignore`tag and run this useful test automatically. Eirik Bjorsnos 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 eight additional commits since the last revision: - Merge branch 'master' into signature-less-data-descriptor - Add assertNotNulls to catch unexpectedly missing entries - Revert change to Google copyright line, add an Oracle copyright line instead. - Use "Signatureless" consistently - Remove reference to python in the @summary of DataDescriptorSignatureMissing - Update copyright years - Add method comments - Instead of calling out to python, create a ZIP file and remove the data descriptor signature. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12959/files - new: https://git.openjdk.org/jdk/pull/12959/files/85eab4a3..0fb30670 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12959&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12959&range=04-05 Stats: 8132 lines in 183 files changed: 1014 ins; 1302 del; 5816 mod Patch: https://git.openjdk.org/jdk/pull/12959.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12959/head:pull/12959 PR: https://git.openjdk.org/jdk/pull/12959 From jpai at openjdk.org Sat Mar 11 10:40:19 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 11 Mar 2023 10:40:19 GMT Subject: RFR: 8206890: jlink --endian XXX generates unusable image if endian-ness does not match architecture [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.org/browse/JDK-8206890? > > The `jlink` command allows a `--endian` option to specify the byte order in the generated image. Before this change, when such a image was being launched, the code would assume the byte order in the image to be the native order of the host where the image is being launched. That would result in failure to launch java, as noted in the linked issue. > > The commit in this PR, changes relevant places to not assume native order and instead determine the byte order by reading the magic bytes in the image file's header content. > > A new jtreg test has been added which reproduces the issue and verifies the fix. 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 10 additional commits since the last revision: - Infer endianness for the generated image from the target platform - Revert "8206890: jlink --endian XXX generates unusable image if endian-ness does not match architecture" This reverts commit 4020a37849d04d0638941b36c8953884b933461e. - Revert "take into account SecurityManager checks" This reverts commit 1694f3a02cf470ac3aaef5d8cdeb0a40c0c66b12. - Revert "Alan's input - remove "final" and match the current code style" This reverts commit 7a754a1bcd20f02da33a9f5d3d170ead0675d33c. - Revert "fix jcheck issue - convert tab to space" This reverts commit 2422399094862718ed8e0e9d3de77d9396283fa4. - merge latest master branch - fix jcheck issue - convert tab to space - Alan's input - remove "final" and match the current code style - take into account SecurityManager checks - 8206890: jlink --endian XXX generates unusable image if endian-ness does not match architecture ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11943/files - new: https://git.openjdk.org/jdk/pull/11943/files/24223990..d0f0e0ee Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11943&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11943&range=00-01 Stats: 384736 lines in 5099 files changed: 212681 ins; 120746 del; 51309 mod Patch: https://git.openjdk.org/jdk/pull/11943.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11943/head:pull/11943 PR: https://git.openjdk.org/jdk/pull/11943 From jpai at openjdk.org Sat Mar 11 10:53:20 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 11 Mar 2023 10:53:20 GMT Subject: RFR: 8206890: jlink --endian XXX generates unusable image if endian-ness does not match architecture In-Reply-To: <1HhkAm6zOraN3gQyG4W2NWigKTVfiTr7dSD7dTIVf-g=.e8f89c6a-9efd-4823-97ac-cf131cd26314@github.com> References: <1HhkAm6zOraN3gQyG4W2NWigKTVfiTr7dSD7dTIVf-g=.e8f89c6a-9efd-4823-97ac-cf131cd26314@github.com> Message-ID: On Fri, 20 Jan 2023 14:23:13 GMT, Jaikiran Pai wrote: > Right now the ModuleTarget class file attribute is not enough but a short term fix might be for jlink to have a simple mapping of known ModuleTarget values to endianness. Overall, it's probably low priority as the most likely users of this will be environments building for embedded platforms. I've now updated this PR to revert the previous commits and instead follow this suggestion to infer the endianness of the target platform while generating the image. The updated PR now continues to allow users to provide `--endian` option while generating an image through `jlink`. If any value is provided for that option, the image generation will continue to honour that value. However, if no value is provided for that option, then during image generation, we will determine the endianness of the target platform, by using the (OpenJDK specific) `ModuleTarget` attribute of target `java.base` module's `module-info` class. This determination is best-effort and if the value cannot be determined, then we default to the current platform's endianness (like we have been doing so far). This commit hardcodes the mapping between a `ModuleTarget`'s architecture and endianness and this mapping is borrowed from what we already do in the OpenJDK build file https://github.com/openjdk/jdk/blob/master/make/autoconf/platform.m4#L26 No new tests have been added in this change, because I couldn't think of a way to test the cross platform `jlink` execution. Existing tests in `test/jdk/tools/jlink` continue to pass with this change. I've triggered our CI runs to run the tiered tests to make sure nothing regresses. The commit in this PR doesn't deprecate the --endian option and I think we can do that as a separate issue. ------------- PR: https://git.openjdk.org/jdk/pull/11943 From jpai at openjdk.org Sat Mar 11 11:00:28 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 11 Mar 2023 11:00:28 GMT Subject: RFR: 8304006: jlink should create the jimage file in the native endian for the target platform [v2] In-Reply-To: References: Message-ID: On Sat, 11 Mar 2023 10:40:19 GMT, Jaikiran Pai wrote: >> Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8206890? >> >> The `jlink` command allows a `--endian` option to specify the byte order in the generated image. Before this change, when such a image was being launched, the code would assume the byte order in the image to be the native order of the host where the image is being launched. That would result in failure to launch java, as noted in the linked issue. >> >> The commit in this PR, changes relevant places to not assume native order and instead determine the byte order by reading the magic bytes in the image file's header content. >> >> A new jtreg test has been added which reproduces the issue and verifies the fix. > > 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 10 additional commits since the last revision: > > - Infer endianness for the generated image from the target platform > - Revert "8206890: jlink --endian XXX generates unusable image if endian-ness does not match architecture" > > This reverts commit 4020a37849d04d0638941b36c8953884b933461e. > - Revert "take into account SecurityManager checks" > > This reverts commit 1694f3a02cf470ac3aaef5d8cdeb0a40c0c66b12. > - Revert "Alan's input - remove "final" and match the current code style" > > This reverts commit 7a754a1bcd20f02da33a9f5d3d170ead0675d33c. > - Revert "fix jcheck issue - convert tab to space" > > This reverts commit 2422399094862718ed8e0e9d3de77d9396283fa4. > - merge latest master branch > - fix jcheck issue - convert tab to space > - Alan's input - remove "final" and match the current code style > - take into account SecurityManager checks > - 8206890: jlink --endian XXX generates unusable image if endian-ness does not match architecture I've updated the PR title to now point to the new https://bugs.openjdk.org/browse/JDK-8304006 ------------- PR: https://git.openjdk.org/jdk/pull/11943 From jpai at openjdk.org Sat Mar 11 11:11:05 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 11 Mar 2023 11:11:05 GMT Subject: RFR: 8304006: jlink should create the jimage file in the native endian for the target platform [v3] 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.org/browse/JDK-8206890? > > The `jlink` command allows a `--endian` option to specify the byte order in the generated image. Before this change, when such a image was being launched, the code would assume the byte order in the image to be the native order of the host where the image is being launched. That would result in failure to launch java, as noted in the linked issue. > > The commit in this PR, changes relevant places to not assume native order and instead determine the byte order by reading the magic bytes in the image file's header content. > > A new jtreg test has been added which reproduces the issue and verifies the fix. Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: undo unintentional copyright year change ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11943/files - new: https://git.openjdk.org/jdk/pull/11943/files/d0f0e0ee..cdfd993e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11943&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11943&range=01-02 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11943.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11943/head:pull/11943 PR: https://git.openjdk.org/jdk/pull/11943 From jpai at openjdk.org Sat Mar 11 12:16:04 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 11 Mar 2023 12:16:04 GMT Subject: RFR: 8304006: jlink should create the jimage file in the native endian for the target platform [v4] 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.org/browse/JDK-8206890? > > The `jlink` command allows a `--endian` option to specify the byte order in the generated image. Before this change, when such a image was being launched, the code would assume the byte order in the image to be the native order of the host where the image is being launched. That would result in failure to launch java, as noted in the linked issue. > > The commit in this PR, changes relevant places to not assume native order and instead determine the byte order by reading the magic bytes in the image file's header content. > > A new jtreg test has been added which reproduces the issue and verifies the fix. Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: missed ppc64 from the arch mapping ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11943/files - new: https://git.openjdk.org/jdk/pull/11943/files/cdfd993e..e68c2105 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11943&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11943&range=02-03 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11943.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11943/head:pull/11943 PR: https://git.openjdk.org/jdk/pull/11943 From jvernee at openjdk.org Sat Mar 11 14:14:54 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Sat, 11 Mar 2023 14:14:54 GMT Subject: RFR: 8303684: Lift upcall sharing mechanism to AbstractLinker (mainline) [v2] In-Reply-To: References: Message-ID: > Port of: https://github.com/openjdk/panama-foreign/pull/791 which lifts the sharing mechanism for upcall stubs to AbstractLinker. > > This also speeds up upcall stub linking: Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Remove spurious space Co-authored-by: Andrey Turbanov ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12883/files - new: https://git.openjdk.org/jdk/pull/12883/files/0355ab19..b359e2a0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12883&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12883&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12883.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12883/head:pull/12883 PR: https://git.openjdk.org/jdk/pull/12883 From duke at openjdk.org Sat Mar 11 16:24:35 2023 From: duke at openjdk.org (liach) Date: Sat, 11 Mar 2023 16:24:35 GMT Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator to use the Classfile API to generate proxy classes [v6] In-Reply-To: <2vZ8IArF00YxvsqkZxg1fZJCv-pvUQRYrepvvVhw1w0=.dcd260a4-f3d6-4797-8e11-e9eb266d460c@github.com> References: <2vZ8IArF00YxvsqkZxg1fZJCv-pvUQRYrepvvVhw1w0=.dcd260a4-f3d6-4797-8e11-e9eb266d460c@github.com> Message-ID: On Fri, 10 Mar 2023 08:48:14 GMT, Adam Sotona wrote: >> java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes and this patch converts it to use Classfile API. >> >> Please review. >> >> Thank you, >> Adam > > Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 196 commits: > > - Merge branch 'master' into JDK-8294961-proxy > - Merge branch 'master' into JDK-8294961-proxy > - Merge branch 'JDK-8294982' into JDK-8294961 > - removed obsolete javadoc from implementation classes > - minor fix in CodeBuilder and added test cases to LDCTest > - EntryMap::nextPowerOfTwo delegates to Long:numberOfLeadingZeros > - fixed CodeBuilder:constantInstruction for -0.0d and -0.0f values and added test > - Merge branch 'master' into JDK-8294982 > - fixed new lines at end of file > - package jdk.internal.classfile.jdktypes moved to jdk.internal.classfile.java.lang.constant > - ... and 186 more: https://git.openjdk.org/jdk/compare/e26cc526...951b1bc7 src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 68: > 66: CD_InvocationHandler = ClassDesc.ofInternalName("java/lang/reflect/InvocationHandler"), > 67: CD_Method = ClassDesc.ofInternalName("java/lang/reflect/Method"), > 68: CD_MethodHandles$Lookup = ClassDesc.ofInternalName("java/lang/invoke/MethodHandles$Lookup"), Can reuse CD_MethodHandles_Lookup from ConstantDescs: Suggestion: src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 85: > 83: MTD_ClassLoader = MethodTypeDesc.of(CD_ClassLoader), > 84: MTD_MethodHandles$Lookup = MethodTypeDesc.of(CD_MethodHandles$Lookup), > 85: MTD_MethodHandles$Lookup_MethodHandles$Lookup = MethodTypeDesc.of(CD_MethodHandles$Lookup, CD_MethodHandles$Lookup), Suggestion: MTD_MethodHandles$Lookup = MethodTypeDesc.of(CD_MethodHandles_Lookup), MTD_MethodHandles$Lookup_MethodHandles$Lookup = MethodTypeDesc.of(CD_MethodHandles_Lookup, CD_MethodHandles_Lookup), src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 426: > 424: */ > 425: localCache.computeIfAbsent(classDesc, cd -> { > 426: try { This probably can be a factory method in ClassHierarchyResolver too, by examining the reflection API via a ClassLoader/Lookup. I'm inclined to submit a patch for improvement. Also, why does ProxyGenerator come with a custom ClassHierarchyResolver while InnerClassLambdaMetafactory in 8294960 #12945 doesn't? src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 602: > 600: .block(blockBuilder -> blockBuilder > 601: .aload(cob.parameterSlot(0)) > 602: .invokevirtual(CD_MethodHandles$Lookup, "lookupClass", MTD_Class) Suggestion: .invokevirtual(CD_MethodHandles_Lookup, "lookupClass", MTD_Class) src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 606: > 604: .if_acmpne(blockBuilder.breakLabel()) > 605: .aload(cob.parameterSlot(0)) > 606: .invokevirtual(CD_MethodHandles$Lookup, "hasFullPrivilegeAccess", MTD_boolean) Suggestion: .invokevirtual(CD_MethodHandles_Lookup, "hasFullPrivilegeAccess", MTD_boolean) src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 613: > 611: .dup() > 612: .aload(cob.parameterSlot(0)) > 613: .invokevirtual(CD_MethodHandles$Lookup, "toString", MTD_String) Suggestion: .invokevirtual(CD_MethodHandles_Lookup, "toString", MTD_String) ------------- PR: https://git.openjdk.org/jdk/pull/10991 From alanb at openjdk.org Sat Mar 11 17:03:30 2023 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 11 Mar 2023 17:03:30 GMT Subject: RFR: 8294962: Convert java.base/jdk.internal.module package to use the Classfile API to modify and write module-info.class [v4] In-Reply-To: References: Message-ID: On Fri, 10 Mar 2023 19:30:45 GMT, Mandy Chung wrote: >> The ModulePackages attribute is optional and an optimization to avoid scanning the module contents to get the full set of packages. Tooling that creates packaged modules (jar and jmod for now) will want the ModulePackages attribute emitted always. So maybe the Classfile.buildModule methods should be looked at again, at least I think the 2-arg and 3-arg methods should emit the ModulePackages unconditionally, the 1-arg buildModule maybe not. This isn't an issue for ModuleInfoWriter of course as it is only used by tests. > > `buildModules` is expected to be called with additional packages but instead it's called with all packages including all exported and open packages. > > > /** > * Build a module descriptor into a byte array. > * @param moduleAttribute the {@code Module} attribute > * @param packages additional module packages > * @param handler a handler that receives a {@link ClassBuilder} > * @return the classfile bytes > */ > public static byte[] buildModule(ModuleAttribute moduleAttribute, > List packages, > Consumer handler) { > > > I checked the implementation that seems to match `@param packages` that expects additional module packages that are not exported nor open. If it intends to take additional packages, it will need to filter the exported and open packages at the callsite. > > Or the `packages` parameter lists all packages that will be used to create `ModulePackages` attribute. This seems to be easier to understand. Maybe the variants of Classfile.buildModule need to be looked at again. For the usage here, buildModule(ModuleAttribute, Consumer) would be more useful as it would allow all of the additional attributes to be emitted in the handler rather than having buildModule making the decision on whether to emit the ModulePackages attribute. ------------- PR: https://git.openjdk.org/jdk/pull/11368 From jwaters at openjdk.org Sat Mar 11 18:43:22 2023 From: jwaters at openjdk.org (Julian Waters) Date: Sat, 11 Mar 2023 18:43:22 GMT Subject: RFR: 8303922: build-test-lib target is broken In-Reply-To: References: Message-ID: On Thu, 9 Mar 2023 20:09:46 GMT, Eirik Bjorsnos wrote: > The Make target 'build-test-lib-target' is broken in a few ways: > > - make/test/BuildTestLib.gmk references the directory $(TEST_LIB_SOURCE_DIR)/sun which does not seem to exist. This can be fixed by removing the reference. > - Some test-lib sources use preview-features which is not enabled by make/test/BuildTestLib.gmk. This is fixed by adding a JAVAC_FLAGS with --enable-preview and also adding 'preview' to DISABLED_WARNINGS > - ASN1Formatter.annotate has a possible lossy conversion from long to int which can be fixed by adding an explicit cast > > This PR fixes the above issues. Marked as reviewed by jwaters (Committer). Looks ok to me, good work :) ------------- PR: https://git.openjdk.org/jdk/pull/12960 From duke at openjdk.org Sat Mar 11 18:47:29 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Sat, 11 Mar 2023 18:47:29 GMT Subject: Integrated: 8303922: build-test-lib target is broken In-Reply-To: References: Message-ID: On Thu, 9 Mar 2023 20:09:46 GMT, Eirik Bjorsnos wrote: > The Make target 'build-test-lib-target' is broken in a few ways: > > - make/test/BuildTestLib.gmk references the directory $(TEST_LIB_SOURCE_DIR)/sun which does not seem to exist. This can be fixed by removing the reference. > - Some test-lib sources use preview-features which is not enabled by make/test/BuildTestLib.gmk. This is fixed by adding a JAVAC_FLAGS with --enable-preview and also adding 'preview' to DISABLED_WARNINGS > - ASN1Formatter.annotate has a possible lossy conversion from long to int which can be fixed by adding an explicit cast > > This PR fixes the above issues. This pull request has now been integrated. Changeset: c313e1ac Author: Eirik Bjorsnos Committer: Julian Waters URL: https://git.openjdk.org/jdk/commit/c313e1ac7b3305b1c012755de4e94728b17e2505 Stats: 8 lines in 2 files changed: 2 ins; 0 del; 6 mod 8303922: build-test-lib target is broken Reviewed-by: erikj, jwaters ------------- PR: https://git.openjdk.org/jdk/pull/12960 From duke at openjdk.org Sat Mar 11 19:55:30 2023 From: duke at openjdk.org (liach) Date: Sat, 11 Mar 2023 19:55:30 GMT Subject: RFR: 8294962: Convert java.base/jdk.internal.module package to use the Classfile API to modify and write module-info.class [v4] In-Reply-To: References: Message-ID: On Fri, 10 Mar 2023 16:46:35 GMT, Glavo wrote: > The Classfile API looks great. I want to ask if you have any plans to completely replace all uses of `jdk.internal.org.objectweb.asm` and delete its source code from OpenJDK in a short time? I guess yes. https://bugs.openjdk.org/browse/JDK-8294957 would be a good place to track the progress. As the overview JBS issue mentions, there are other ad-hoc utilities that read class files, such as proprietary libraries. In addition, [asmtools](https://github.com/openjdk/asmtools) which generates some assemblies can be migrated to Classfile API as well in the future. ------------- PR: https://git.openjdk.org/jdk/pull/11368 From duke at openjdk.org Sun Mar 12 08:46:15 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Sun, 12 Mar 2023 08:46:15 GMT Subject: RFR: 8304020: Speed up test/jdk/java/util/zip/ZipFile/TestTooManyEntries.java and clarify its purpose Message-ID: <8Imbn5098NjdJMPtI2UD7BNSP3oRM4q8vB5_Lq1pLhs=.4686073b-207c-4e3b-b6c0-6227037b11b6@github.com> Please review this test which speeds up TestTooManyEntries and clarifies its purpose: - The name 'TestTooManyEntries' does not clearly convey the purpose of the test. What is tested here is the validation that the total CEN size fits in a Java byte array. Suggested rename: CenSizeTooLarge - The test creates DEFLATED entries which incurs zlib costs and File Data / Data Descriptors for no additional benefit. We can use STORED instead. - The name of entries is generated by calling UUID.randomUUID, we could use simple counter instead. - The produced file is unnecessarily large. We know how large a CEN entry is, let's take advantage of that to create a file with the minimal size. - The summary and comments of the test can be improved to help explain the purpose of the test and how we reach the limit being tested. The speedups here reduced the runtime of this test from 6 min 58 sec to 3 min 35 sec on my Macbook pro. The produced ZIP size was reduced from 6000000098 bytes to 3655383762 bytes. ------------- Commit messages: - Update copyright years - Speed up TestTooManyEntries, clarify its purpose and rename it to CenSizeTooLarge Changes: https://git.openjdk.org/jdk/pull/12991/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12991&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304020 Stats: 175 lines in 2 files changed: 86 ins; 89 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12991.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12991/head:pull/12991 PR: https://git.openjdk.org/jdk/pull/12991 From alanb at openjdk.org Sun Mar 12 09:19:21 2023 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 12 Mar 2023 09:19:21 GMT Subject: RFR: 8304006: jlink should create the jimage file in the native endian for the target platform [v4] In-Reply-To: References: Message-ID: On Sat, 11 Mar 2023 12:16:04 GMT, Jaikiran Pai wrote: >> Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8206890? >> >> The `jlink` command allows a `--endian` option to specify the byte order in the generated image. Before this change, when such a image was being launched, the code would assume the byte order in the image to be the native order of the host where the image is being launched. That would result in failure to launch java, as noted in the linked issue. >> >> The commit in this PR, changes relevant places to not assume native order and instead determine the byte order by reading the magic bytes in the image file's header content. >> >> A new jtreg test has been added which reproduces the issue and verifies the fix. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > missed ppc64 from the arch mapping Thanks for dropping the changes to the jimage code and changing this to choose the endianness when cross linking. src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 827: > 825: if (ref instanceof ModuleReferenceImpl modRefImpl > 826: && modRefImpl.moduleTarget() != null) { > 827: targetPlatform = modRefImpl.moduleTarget().targetPlatform(); It might be better to only look for the ModuleTarget attribute cross linking. modsPaths.get("java.base") will give you the path to the packaged module for java.base, getDefaultModulePath() will give you the location of the packaged modules in the current execution environment. If getDefaultModulePath() is the parent of the location containing java.base then it can use the current endianness. Also just to say that if it would be an error if java.base is not in the Configuration, same thing if there is no packaged module for java.base. src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 928: > 926: "s390x", "sh", > 927: "sparc", "sparcv9" -> ByteOrder.BIG_ENDIAN; > 928: default -> ByteOrder.nativeOrder(); When cross linking and the target platform is unknown then it might be better to have this fail rather than defaulting to the endianness of the current platform, otherwise this risks create a run-time image that is not usable. I see you've listed a bunch of unknown platforms in the list. If getNativeEndianOfTargetPlatform fails when it encounters an unknown platform then help downstream porters to know that there is something to look at here. ------------- PR: https://git.openjdk.org/jdk/pull/11943 From duke at openjdk.org Sun Mar 12 09:48:04 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Sun, 12 Mar 2023 09:48:04 GMT Subject: RFR: 8304020: Speed up test/jdk/java/util/zip/ZipFile/TestTooManyEntries.java and clarify its purpose [v2] In-Reply-To: <8Imbn5098NjdJMPtI2UD7BNSP3oRM4q8vB5_Lq1pLhs=.4686073b-207c-4e3b-b6c0-6227037b11b6@github.com> References: <8Imbn5098NjdJMPtI2UD7BNSP3oRM4q8vB5_Lq1pLhs=.4686073b-207c-4e3b-b6c0-6227037b11b6@github.com> Message-ID: > Please review this PR which speeds up TestTooManyEntries and clarifies its purpose: > > - The name 'TestTooManyEntries' does not clearly convey the purpose of the test. What is tested here is the validation that the total CEN size fits in a Java byte array. Suggested rename: CenSizeTooLarge > - The test creates DEFLATED entries which incurs zlib costs and File Data / Data Descriptors for no additional benefit. We can use STORED instead. > - The name of entries is generated by calling UUID.randomUUID, we could use simple counter instead. > - The produced file is unnecessarily large. We know how large a CEN entry is, let's take advantage of that to create a file with the minimal size. > - The summary and comments of the test can be improved to help explain the purpose of the test and how we reach the limit being tested. > > These speedups reduced the runtime from 6 min 58 sec to 3 min 35 sec on my Macbook Pro. The produced ZIP size was reduced from 6000000098 bytes to 3655383762 bytes. Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision: Set modification time using ZipEntry.setLocalTime avoids the default time calculation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12991/files - new: https://git.openjdk.org/jdk/pull/12991/files/864b93b3..e1425614 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12991&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12991&range=00-01 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12991.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12991/head:pull/12991 PR: https://git.openjdk.org/jdk/pull/12991 From duke at openjdk.org Sun Mar 12 10:00:50 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Sun, 12 Mar 2023 10:00:50 GMT Subject: RFR: 8304020: Speed up test/jdk/java/util/zip/ZipFile/TestTooManyEntries.java and clarify its purpose [v3] In-Reply-To: <8Imbn5098NjdJMPtI2UD7BNSP3oRM4q8vB5_Lq1pLhs=.4686073b-207c-4e3b-b6c0-6227037b11b6@github.com> References: <8Imbn5098NjdJMPtI2UD7BNSP3oRM4q8vB5_Lq1pLhs=.4686073b-207c-4e3b-b6c0-6227037b11b6@github.com> Message-ID: > Please review this PR which speeds up TestTooManyEntries and clarifies its purpose: > > - The name 'TestTooManyEntries' does not clearly convey the purpose of the test. What is tested here is the validation that the total CEN size fits in a Java byte array. Suggested rename: CenSizeTooLarge > - The test creates DEFLATED entries which incurs zlib costs and File Data / Data Descriptors for no additional benefit. We can use STORED instead. > - By create a single LocalDateTime and setting it with `ZipEntry.setTimeLocal`, we can avoid time zone calculations. > - The name of entries is generated by calling UUID.randomUUID, we could use simple counter instead. > - The produced file is unnecessarily large. We know how large a CEN entry is, let's take advantage of that to create a file with the minimal size. > - The summary and comments of the test can be improved to help explain the purpose of the test and how we reach the limit being tested. > > These speedups reduced the runtime from 4 min 17 sec to 1 min 54 sec on my Macbook Pro. The produced ZIP size was reduced from 6000000098 bytes to 3655383762 bytes. Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision: Use Integer.toString instead of Long.toString ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12991/files - new: https://git.openjdk.org/jdk/pull/12991/files/e1425614..2397cede Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12991&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12991&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12991.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12991/head:pull/12991 PR: https://git.openjdk.org/jdk/pull/12991 From lancea at openjdk.org Sun Mar 12 11:16:19 2023 From: lancea at openjdk.org (Lance Andersen) Date: Sun, 12 Mar 2023 11:16:19 GMT Subject: RFR: 8304020: Speed up test/jdk/java/util/zip/ZipFile/TestTooManyEntries.java and clarify its purpose [v3] In-Reply-To: References: <8Imbn5098NjdJMPtI2UD7BNSP3oRM4q8vB5_Lq1pLhs=.4686073b-207c-4e3b-b6c0-6227037b11b6@github.com> Message-ID: On Sun, 12 Mar 2023 10:00:50 GMT, Eirik Bjorsnos wrote: >> Please review this PR which speeds up TestTooManyEntries and clarifies its purpose: >> >> - The name 'TestTooManyEntries' does not clearly convey the purpose of the test. What is tested is the validation that the total CEN size fits in a Java byte array. Suggested rename: CenSizeTooLarge >> - The test creates DEFLATED entries which incurs zlib costs and File Data / Data Descriptors for no additional benefit. We can use STORED instead. >> - By creating a single LocalDateTime and setting it with `ZipEntry.setTimeLocal`, we can avoid repeated time zone calculations. >> - The name of entries is generated by calling UUID.randomUUID, we could use simple counter instead. >> - The produced file is unnecessarily large. We know how large a CEN entry is, let's take advantage of that to create a file with the minimal size. >> - The summary and comments of the test can be improved to help explain the purpose of the test and how we reach the limit being tested. >> >> These speedups reduced the runtime from 4 min 17 sec to 1 min 54 sec on my Macbook Pro. The produced ZIP size was reduced from 5.7 GB to 3.5 GB. > > Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision: > > Use Integer.toString instead of Long.toString I think the changes look good overall. Thank you for this. I am not sure that the `@requires` is needed at this point. ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.org/jdk/pull/12991 From duke at openjdk.org Sun Mar 12 11:24:17 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Sun, 12 Mar 2023 11:24:17 GMT Subject: RFR: 8304020: Speed up test/jdk/java/util/zip/ZipFile/TestTooManyEntries.java and clarify its purpose [v3] In-Reply-To: References: <8Imbn5098NjdJMPtI2UD7BNSP3oRM4q8vB5_Lq1pLhs=.4686073b-207c-4e3b-b6c0-6227037b11b6@github.com> Message-ID: On Sun, 12 Mar 2023 11:13:51 GMT, Lance Andersen wrote: > I think the changes look good overall. Thank you for this. I am not sure that the `@requires` is needed at this point. I think it is still needed. ZipOutputStream needs to keep all entries in memory until it can write the CEN entries. I tried reducing it to 7GB, but that failed with OutOfMemoryError. ------------- PR: https://git.openjdk.org/jdk/pull/12991 From alanb at openjdk.org Sun Mar 12 11:54:21 2023 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 12 Mar 2023 11:54:21 GMT Subject: RFR: 8304020: Speed up test/jdk/java/util/zip/ZipFile/TestTooManyEntries.java and clarify its purpose [v3] In-Reply-To: References: <8Imbn5098NjdJMPtI2UD7BNSP3oRM4q8vB5_Lq1pLhs=.4686073b-207c-4e3b-b6c0-6227037b11b6@github.com> Message-ID: On Sun, 12 Mar 2023 10:00:50 GMT, Eirik Bjorsnos wrote: >> Please review this PR which speeds up TestTooManyEntries and clarifies its purpose: >> >> - The name 'TestTooManyEntries' does not clearly convey the purpose of the test. What is tested is the validation that the total CEN size fits in a Java byte array. Suggested rename: CenSizeTooLarge >> - The test creates DEFLATED entries which incurs zlib costs and File Data / Data Descriptors for no additional benefit. We can use STORED instead. >> - By creating a single LocalDateTime and setting it with `ZipEntry.setTimeLocal`, we can avoid repeated time zone calculations. >> - The name of entries is generated by calling UUID.randomUUID, we could use simple counter instead. >> - The produced file is unnecessarily large. We know how large a CEN entry is, let's take advantage of that to create a file with the minimal size. >> - The summary and comments of the test can be improved to help explain the purpose of the test and how we reach the limit being tested. >> >> These speedups reduced the runtime from 4 min 17 sec to 1 min 54 sec on my Macbook Pro. The produced ZIP size was reduced from 5.7 GB to 3.5 GB. > > Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision: > > Use Integer.toString instead of Long.toString It would be great if we could change this to be an automatic test. Maybe we could create a sub-directory in test/jdk/java/util/zip/ZipFile for the resource hogs and put this here, exclude this directory from tier1, and add it to tier2_part2. ------------- PR: https://git.openjdk.org/jdk/pull/12991 From duke at openjdk.org Sun Mar 12 11:54:22 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Sun, 12 Mar 2023 11:54:22 GMT Subject: RFR: 8304020: Speed up test/jdk/java/util/zip/ZipFile/TestTooManyEntries.java and clarify its purpose [v3] In-Reply-To: References: <8Imbn5098NjdJMPtI2UD7BNSP3oRM4q8vB5_Lq1pLhs=.4686073b-207c-4e3b-b6c0-6227037b11b6@github.com> Message-ID: On Sun, 12 Mar 2023 10:00:50 GMT, Eirik Bjorsnos wrote: >> Please review this PR which speeds up TestTooManyEntries and clarifies its purpose: >> >> - The name 'TestTooManyEntries' does not clearly convey the purpose of the test. What is tested is the validation that the total CEN size fits in a Java byte array. Suggested rename: CenSizeTooLarge >> - The test creates DEFLATED entries which incurs zlib costs and File Data / Data Descriptors for no additional benefit. We can use STORED instead. >> - By creating a single LocalDateTime and setting it with `ZipEntry.setTimeLocal`, we can avoid repeated time zone calculations. >> - The name of entries is generated by calling UUID.randomUUID, we could use simple counter instead. >> - The produced file is unnecessarily large. We know how large a CEN entry is, let's take advantage of that to create a file with the minimal size. >> - The summary and comments of the test can be improved to help explain the purpose of the test and how we reach the limit being tested. >> >> These speedups reduced the runtime from 4 min 17 sec to 1 min 54 sec on my Macbook Pro. The produced ZIP size was reduced from 5.7 GB to 3.5 GB. > > Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision: > > Use Integer.toString instead of Long.toString Here's a wild idea: We could inject large extra fields on the CEN entries to inflate the size of each CEN entry. This means we get away with much fewer CEN entries which again means much less memory. Also, writing mostly empty extra data seems to be really fast, at least on my Macbook Pro. For me, the test now run without the `@requires' and completes in less than 5 seconds. The cost is slightly more complicated code. But perhaps still worth the added complexity? @BeforeTest public void setup() throws IOException { hugeZipFile = new File("cen-too-large.zip"); hugeZipFile.deleteOnExit(); // Length of generated entry names int nameLength = 10; // We use a large extra field to get away with fewer CEN headers byte[] extra = makeLargeExtra(); // The size of a single CEN header, including name and extra field int cenHeaderSize = ZipFile.CENHDR + nameLength + extra.length; // Determine the number of entries needed to exceed the MAX_CEN_SIZE int numEntries = (MAX_CEN_SIZE / cenHeaderSize) + 1; ZipEntry[] entries = new ZipEntry[numEntries]; try (ZipOutputStream zip = new ZipOutputStream(new BufferedOutputStream(new FileOutputStream(hugeZipFile)))) { // Creating the LocalDataTime once allows faster processing LocalDateTime time = LocalDateTime.now(); // Add entries until MAX_CEN_SIZE is reached for (int i = 0; i < numEntries; i++) { String name = Integer.toString(i); name = "0".repeat(nameLength -name.length()) + name; ZipEntry entry = entries[i] = new ZipEntry(name); // Use STORED for faster processing entry.setMethod(ZipEntry.STORED); entry.setSize(0); entry.setCrc(0); entry.setTimeLocal(time); zip.putNextEntry(entry); } zip.closeEntry(); for (ZipEntry entry : entries) { entry.setExtra(extra); } } } /** * Make an extra field with an 'unknown' tag and the maximum possible data size * @return */ private static byte[] makeLargeExtra() { byte[] extra = new byte[Short.MAX_VALUE]; ByteBuffer buffer = ByteBuffer.wrap(extra).order(ByteOrder.LITTLE_ENDIAN); buffer.putShort((short) 0x9902); // 'unknown' tag buffer.putShort((short) (extra.length - 2 * Short.BYTES)); // Data size return extra; } ------------- PR: https://git.openjdk.org/jdk/pull/12991 From jlaskey at openjdk.org Sun Mar 12 12:03:21 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Sun, 12 Mar 2023 12:03:21 GMT Subject: RFR: 8304006: jlink should create the jimage file in the native endian for the target platform [v3] In-Reply-To: References: Message-ID: On Sat, 11 Mar 2023 11:11:05 GMT, Jaikiran Pai wrote: >> Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8206890? >> >> The `jlink` command allows a `--endian` option to specify the byte order in the generated image. Before this change, when such a image was being launched, the code would assume the byte order in the image to be the native order of the host where the image is being launched. That would result in failure to launch java, as noted in the linked issue. >> >> The commit in this PR, changes relevant places to not assume native order and instead determine the byte order by reading the magic bytes in the image file's header content. >> >> A new jtreg test has been added which reproduces the issue and verifies the fix. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > undo unintentional copyright year change Changes requested by jlaskey (Reviewer). src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 916: > 914: } > 915: String archName = targetPlatform.substring(index + 1); > 916: return switch (archName) { Not that keen having this table buried in code. It's something that should be at the build level, maybe read from a resource? ------------- PR: https://git.openjdk.org/jdk/pull/11943 From duke at openjdk.org Sun Mar 12 12:05:19 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Sun, 12 Mar 2023 12:05:19 GMT Subject: RFR: 8304020: Speed up test/jdk/java/util/zip/ZipFile/TestTooManyEntries.java and clarify its purpose [v3] In-Reply-To: References: <8Imbn5098NjdJMPtI2UD7BNSP3oRM4q8vB5_Lq1pLhs=.4686073b-207c-4e3b-b6c0-6227037b11b6@github.com> Message-ID: On Sun, 12 Mar 2023 11:47:47 GMT, Alan Bateman wrote: > It would be great if we could change this to be an automatic test. Maybe we could create a sub-directory in test/jdk/java/util/zip/ZipFile for the resource hogs and put this here, exclude this directory from tier1, and add it to tier2_part2. With the changes described in my previous comment, I think we could make this test automatic (unless the 2GB file is a concern?) ------------- PR: https://git.openjdk.org/jdk/pull/12991 From duke at openjdk.org Sun Mar 12 14:00:23 2023 From: duke at openjdk.org (Michael Osipov) Date: Sun, 12 Mar 2023 14:00:23 GMT Subject: RFR: 8303485: Replacing os.name for operating system customization In-Reply-To: <30LlJRHIs8OjAn9F7y5PYywWjuk2fV8tyG0SfZFHiOM=.3b961b7b-b2e1-488c-8da6-5fb0a586e208@github.com> References: <30LlJRHIs8OjAn9F7y5PYywWjuk2fV8tyG0SfZFHiOM=.3b961b7b-b2e1-488c-8da6-5fb0a586e208@github.com> Message-ID: On Fri, 10 Mar 2023 14:22:17 GMT, Justin King wrote: > > > Has this totally killed of BSD support on the JDK side? I thought building non-macOS BSD was still viable, but perhaps not - certainly not after this change. > > > > > > The macOS port in 7u4 was based on a BSD port and there was a time when it was possible to build. Right now, we have src/hotspot/os/bsd and native code in the libs that is compiled in with _ALLBSD_SOURCE. It's sad to see the BSD port bit rot but if it's not maintained or tested in the OpenJDK project then the changes proposed here may be okay. For porters then know which code needs to be ported is important, ideally there would be a compile or build time if someone significant is missing. > > Yes it is unfortunate. It would be nice if NetBSD, FreeBSD, OpenBSD, and friends would collaborate. I think the majority of their changes are fixing build issues and making AWT/Swing use X11 instead of macOS-specific stuff (Quartz or Cocoa or whatever). Maybe I'll go poke them eventually. I bet @battleblow has tried, but that wasn't fruitful with the OpenJDK team. ------------- PR: https://git.openjdk.org/jdk/pull/12931 From duke at openjdk.org Sun Mar 12 14:00:26 2023 From: duke at openjdk.org (Michael Osipov) Date: Sun, 12 Mar 2023 14:00:26 GMT Subject: RFR: 8303485: Replacing os.name for operating system customization [v2] In-Reply-To: References: Message-ID: On Fri, 10 Mar 2023 21:21:56 GMT, Roger Riggs wrote: >> Improvements to support OS specific customization for JDK internal use: >> - To select values and code; allowing elimination of unused code and values >> - Optionally evaluated by build processes, compilation, or archiving (i.e. CDS) >> - Simple API to replace adhoc comparisons with `os.name` >> - Clear and consistent use across build, runtime, and JDK modules >> >> The PR includes updates within java.base to use the new API. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Move OperatingSystem from jdk.internal.misc to jdk.internal.util > Rename Mac -> MacOS; isMac() -> isMacOS() This looks wrong because it would leave out a lot of ports which this solution cannot cover. Rephrased: An exhaustive list of values to an non-exhaustive amount of systems just feels wrong. ------------- PR: https://git.openjdk.org/jdk/pull/12931 From lancea at openjdk.org Sun Mar 12 14:15:20 2023 From: lancea at openjdk.org (Lance Andersen) Date: Sun, 12 Mar 2023 14:15:20 GMT Subject: RFR: 8304020: Speed up test/jdk/java/util/zip/ZipFile/TestTooManyEntries.java and clarify its purpose [v3] In-Reply-To: References: <8Imbn5098NjdJMPtI2UD7BNSP3oRM4q8vB5_Lq1pLhs=.4686073b-207c-4e3b-b6c0-6227037b11b6@github.com> Message-ID: On Sun, 12 Mar 2023 10:00:50 GMT, Eirik Bjorsnos wrote: >> Please review this PR which speeds up TestTooManyEntries and clarifies its purpose: >> >> - The name 'TestTooManyEntries' does not clearly convey the purpose of the test. What is tested is the validation that the total CEN size fits in a Java byte array. Suggested rename: CenSizeTooLarge >> - The test creates DEFLATED entries which incurs zlib costs and File Data / Data Descriptors for no additional benefit. We can use STORED instead. >> - By creating a single LocalDateTime and setting it with `ZipEntry.setTimeLocal`, we can avoid repeated time zone calculations. >> - The name of entries is generated by calling UUID.randomUUID, we could use simple counter instead. >> - The produced file is unnecessarily large. We know how large a CEN entry is, let's take advantage of that to create a file with the minimal size. >> - The summary and comments of the test can be improved to help explain the purpose of the test and how we reach the limit being tested. >> >> These speedups reduced the runtime from 4 min 17 sec to 1 min 54 sec on my Macbook Pro. The produced ZIP size was reduced from 5.7 GB to 3.5 GB. > > Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision: > > Use Integer.toString instead of Long.toString > Here's a wild idea: > > We could inject large extra fields on the CEN entries to inflate the size of each CEN entry. This means we get away with much fewer CEN entries which again means much less memory. Also, writing mostly empty extra data seems to be really fast, at least on my Macbook Pro. > > For me, the test now run without the `@requires' and completes in less than 5 seconds. > > The cost is slightly more complicated code. But perhaps still worth the added complexity? > > ```java > @BeforeTest > public void setup() throws IOException { > hugeZipFile = new File("cen-too-large.zip"); > hugeZipFile.deleteOnExit(); > > // Length of generated entry names > int nameLength = 10; > > // We use a large extra field to get away with fewer CEN headers > byte[] extra = makeLargeExtra(); > > // The size of a single CEN header, including name and extra field > int cenHeaderSize = ZipFile.CENHDR + nameLength + extra.length; > > // Determine the number of entries needed to exceed the MAX_CEN_SIZE > int numEntries = (MAX_CEN_SIZE / cenHeaderSize) + 1; > > ZipEntry[] entries = new ZipEntry[numEntries]; > try (ZipOutputStream zip = new ZipOutputStream(new BufferedOutputStream(new FileOutputStream(hugeZipFile)))) { > // Creating the LocalDataTime once allows faster processing > LocalDateTime time = LocalDateTime.now(); > // Add entries until MAX_CEN_SIZE is reached > for (int i = 0; i < numEntries; i++) { > String name = Integer.toString(i); > name = "0".repeat(nameLength -name.length()) + name; > ZipEntry entry = entries[i] = new ZipEntry(name); > // Use STORED for faster processing > entry.setMethod(ZipEntry.STORED); > entry.setSize(0); > entry.setCrc(0); > entry.setTimeLocal(time); > zip.putNextEntry(entry); > } > zip.closeEntry(); > for (ZipEntry entry : entries) { > entry.setExtra(extra); > } > } > } > > /** > * Make an extra field with an 'unknown' tag and the maximum possible data size > * @return > */ > private static byte[] makeLargeExtra() { > byte[] extra = new byte[Short.MAX_VALUE]; > ByteBuffer buffer = ByteBuffer.wrap(extra).order(ByteOrder.LITTLE_ENDIAN); > buffer.putShort((short) 0x9902); // 'unknown' tag > buffer.putShort((short) (extra.length - 2 * Short.BYTES)); // Data size > return extra; > } > ``` I think this is probably OK. I would probably create a constant with the Data Size to make it clearer and add more of a detailed comment of this method (laying out the structure of the Extra field) along with pointing to 4.6.1 of the APP.note ------------- PR: https://git.openjdk.org/jdk/pull/12991 From duke at openjdk.org Sun Mar 12 17:01:08 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Sun, 12 Mar 2023 17:01:08 GMT Subject: RFR: 8304020: Speed up test/jdk/java/util/zip/ZipFile/TestTooManyEntries.java and clarify its purpose [v4] In-Reply-To: <8Imbn5098NjdJMPtI2UD7BNSP3oRM4q8vB5_Lq1pLhs=.4686073b-207c-4e3b-b6c0-6227037b11b6@github.com> References: <8Imbn5098NjdJMPtI2UD7BNSP3oRM4q8vB5_Lq1pLhs=.4686073b-207c-4e3b-b6c0-6227037b11b6@github.com> Message-ID: <6c-gSmah_ZWIT3nPgyclNFcZr6tFpBKwW2grmMJB__U=.d05294c9-baff-414a-a5e9-71d4ee7d2049@github.com> > Please review this PR which speeds up TestTooManyEntries and clarifies its purpose: > > - The name 'TestTooManyEntries' does not clearly convey the purpose of the test. What is tested is the validation that the total CEN size fits in a Java byte array. Suggested rename: CenSizeTooLarge > - The test creates DEFLATED entries which incurs zlib costs and File Data / Data Descriptors for no additional benefit. We can use STORED instead. > - By creating a single LocalDateTime and setting it with `ZipEntry.setTimeLocal`, we can avoid repeated time zone calculations. > - The name of entries is generated by calling UUID.randomUUID, we could use simple counter instead. > - The produced file is unnecessarily large. We know how large a CEN entry is, let's take advantage of that to create a file with the minimal size. > - The summary and comments of the test can be improved to help explain the purpose of the test and how we reach the limit being tested. > > These speedups reduced the runtime from 4 min 17 sec to 1 min 54 sec on my Macbook Pro. The produced ZIP size was reduced from 5.7 GB to 3.5 GB. Eirik Bjorsnos has updated the pull request incrementally with three additional commits since the last revision: - Give test method a long, meaningful name - Remove blank line - Make CEN headers maximally large such that we need fewer of them and save memory ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12991/files - new: https://git.openjdk.org/jdk/pull/12991/files/2397cede..0ac4b652 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12991&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12991&range=02-03 Stats: 78 lines in 1 file changed: 65 ins; 1 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/12991.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12991/head:pull/12991 PR: https://git.openjdk.org/jdk/pull/12991 From martin at openjdk.org Sun Mar 12 17:01:13 2023 From: martin at openjdk.org (Martin Buchholz) Date: Sun, 12 Mar 2023 17:01:13 GMT Subject: RFR: 8304020: Speed up test/jdk/java/util/zip/ZipFile/TestTooManyEntries.java and clarify its purpose [v3] In-Reply-To: References: <8Imbn5098NjdJMPtI2UD7BNSP3oRM4q8vB5_Lq1pLhs=.4686073b-207c-4e3b-b6c0-6227037b11b6@github.com> Message-ID: On Sun, 12 Mar 2023 10:00:50 GMT, Eirik Bjorsnos wrote: >> Please review this PR which speeds up TestTooManyEntries and clarifies its purpose: >> >> - The name 'TestTooManyEntries' does not clearly convey the purpose of the test. What is tested is the validation that the total CEN size fits in a Java byte array. Suggested rename: CenSizeTooLarge >> - The test creates DEFLATED entries which incurs zlib costs and File Data / Data Descriptors for no additional benefit. We can use STORED instead. >> - By creating a single LocalDateTime and setting it with `ZipEntry.setTimeLocal`, we can avoid repeated time zone calculations. >> - The name of entries is generated by calling UUID.randomUUID, we could use simple counter instead. >> - The produced file is unnecessarily large. We know how large a CEN entry is, let's take advantage of that to create a file with the minimal size. >> - The summary and comments of the test can be improved to help explain the purpose of the test and how we reach the limit being tested. >> >> These speedups reduced the runtime from 4 min 17 sec to 1 min 54 sec on my Macbook Pro. The produced ZIP size was reduced from 5.7 GB to 3.5 GB. > > Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision: > > Use Integer.toString instead of Long.toString Marked as reviewed by martin (Reviewer). test/jdk/java/util/zip/ZipFile/CenSizeTooLarge.java line 67: > 65: // Add entries until MAX_CEN_SIZE is reached > 66: for (int i = 0; cenSize < MAX_CEN_SIZE; i++) { > 67: String name = Integer.toString(i); Consider making fewer but larger entries by generating large metadata. Most obviously by making names in length close to the 64k metadata limit. or by adding some fixed large extra field to each entry. test/jdk/java/util/zip/ZipFile/CenSizeTooLarge.java line 70: > 68: ZipEntry entry = new ZipEntry(name); > 69: // Use STORED for faster processing > 70: entry.setMethod(ZipEntry.STORED); it's a little surprising that STORED vs DEFLATED here makes much of a difference because there's no file contents to be compressed. test/jdk/java/util/zip/ZipFile/CenSizeTooLarge.java line 86: > 84: */ > 85: @Test > 86: public void test() { I've learned to always give test methods long meaningful names, e.g. centralDirectoryTooLargeToFitInByteArray ------------- PR: https://git.openjdk.org/jdk/pull/12991 From duke at openjdk.org Sun Mar 12 17:01:15 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Sun, 12 Mar 2023 17:01:15 GMT Subject: RFR: 8304020: Speed up test/jdk/java/util/zip/ZipFile/TestTooManyEntries.java and clarify its purpose [v3] In-Reply-To: References: <8Imbn5098NjdJMPtI2UD7BNSP3oRM4q8vB5_Lq1pLhs=.4686073b-207c-4e3b-b6c0-6227037b11b6@github.com> Message-ID: On Sun, 12 Mar 2023 16:41:33 GMT, Martin Buchholz wrote: >> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision: >> >> Use Integer.toString instead of Long.toString > > test/jdk/java/util/zip/ZipFile/CenSizeTooLarge.java line 67: > >> 65: // Add entries until MAX_CEN_SIZE is reached >> 66: for (int i = 0; cenSize < MAX_CEN_SIZE; i++) { >> 67: String name = Integer.toString(i); > > Consider making fewer but larger entries by generating large metadata. > Most obviously by making names in length close to the 64k metadata limit. > or by adding some fixed large extra field to each entry. Oh no, you reviewed just seconds before I pushed an update which does just that. I use a maximally sized extra field which makes the test run in 4 seconds using 12MB (measured using Runtime.freeMemory) of memory in the main loop. Could I bother you to review the update version? > test/jdk/java/util/zip/ZipFile/CenSizeTooLarge.java line 70: > >> 68: ZipEntry entry = new ZipEntry(name); >> 69: // Use STORED for faster processing >> 70: entry.setMethod(ZipEntry.STORED); > > it's a little surprising that STORED vs DEFLATED here makes much of a difference because there's no file contents to be compressed. Well, there is! ZipOutputStream will output an 'empty final' DEFLATE block, followed by a 16-byte data descriptor. Take a look at PR #12899 which suggests adding an apiNote recommending the use of STORED for this reason. > test/jdk/java/util/zip/ZipFile/CenSizeTooLarge.java line 86: > >> 84: */ >> 85: @Test >> 86: public void test() { > > I've learned to always give test methods long meaningful names, e.g. centralDirectoryTooLargeToFitInByteArray Thanks, I did actually?not notice that myself, good idea! ------------- PR: https://git.openjdk.org/jdk/pull/12991 From duke at openjdk.org Sun Mar 12 17:03:19 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Sun, 12 Mar 2023 17:03:19 GMT Subject: RFR: 8304020: Speed up test/jdk/java/util/zip/ZipFile/TestTooManyEntries.java and clarify its purpose [v3] In-Reply-To: References: <8Imbn5098NjdJMPtI2UD7BNSP3oRM4q8vB5_Lq1pLhs=.4686073b-207c-4e3b-b6c0-6227037b11b6@github.com> Message-ID: On Sun, 12 Mar 2023 14:12:08 GMT, Lance Andersen wrote: > I think this is probably OK. I would probably create a constant with the Data Size to make it clearer and add more of a detailed comment of this method (laying out the structure of the Extra field) along with pointing to 4.6.1 of the APP.note I pushed an implementation of this with improved comments, referencing APPNOTE.txt and using more constants where appropriate. I also remembered that ZIP shorts are unsigned, so we can double the size of the extra field for an extra little gain in performance/memory usage. Take a look at it, I'm sure there is room for improvements in my comments. ------------- PR: https://git.openjdk.org/jdk/pull/12991 From duke at openjdk.org Sun Mar 12 17:14:43 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Sun, 12 Mar 2023 17:14:43 GMT Subject: RFR: 8304020: Speed up test/jdk/java/util/zip/ZipFile/TestTooManyEntries.java and clarify its purpose [v5] In-Reply-To: <8Imbn5098NjdJMPtI2UD7BNSP3oRM4q8vB5_Lq1pLhs=.4686073b-207c-4e3b-b6c0-6227037b11b6@github.com> References: <8Imbn5098NjdJMPtI2UD7BNSP3oRM4q8vB5_Lq1pLhs=.4686073b-207c-4e3b-b6c0-6227037b11b6@github.com> Message-ID: > Please review this PR which speeds up TestTooManyEntries and clarifies its purpose: > > - The name 'TestTooManyEntries' does not clearly convey the purpose of the test. What is tested is the validation that the total CEN size fits in a Java byte array. Suggested rename: CenSizeTooLarge > - The test creates DEFLATED entries which incurs zlib costs and File Data / Data Descriptors for no additional benefit. We can use STORED instead. > - By creating a single LocalDateTime and setting it with `ZipEntry.setTimeLocal`, we can avoid repeated time zone calculations. > - The name of entries is generated by calling UUID.randomUUID, we could use simple counter instead. > - The produced file is unnecessarily large. We know how large a CEN entry is, let's take advantage of that to create a file with the minimal size. > - The summary and comments of the test can be improved to help explain the purpose of the test and how we reach the limit being tested. > > These speedups reduced the runtime from 4 min 17 sec to 1 min 54 sec on my Macbook Pro. The produced ZIP size was reduced from 5.7 GB to 3.5 GB. Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision: Spell 'specified' correctly ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12991/files - new: https://git.openjdk.org/jdk/pull/12991/files/0ac4b652..8969de16 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12991&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12991&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12991.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12991/head:pull/12991 PR: https://git.openjdk.org/jdk/pull/12991 From duke at openjdk.org Sun Mar 12 21:25:46 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Sun, 12 Mar 2023 21:25:46 GMT Subject: RFR: 8304020: Speed up test/jdk/java/util/zip/ZipFile/TestTooManyEntries.java and clarify its purpose [v6] In-Reply-To: <8Imbn5098NjdJMPtI2UD7BNSP3oRM4q8vB5_Lq1pLhs=.4686073b-207c-4e3b-b6c0-6227037b11b6@github.com> References: <8Imbn5098NjdJMPtI2UD7BNSP3oRM4q8vB5_Lq1pLhs=.4686073b-207c-4e3b-b6c0-6227037b11b6@github.com> Message-ID: > Please review this PR which speeds up TestTooManyEntries and clarifies its purpose: > > - The name 'TestTooManyEntries' does not clearly convey the purpose of the test. What is tested is the validation that the total CEN size fits in a Java byte array. Suggested rename: CenSizeTooLarge > - The test creates DEFLATED entries which incurs zlib costs and File Data / Data Descriptors for no additional benefit. We can use STORED instead. > - By creating a single LocalDateTime and setting it with `ZipEntry.setTimeLocal`, we can avoid repeated time zone calculations. > - The name of entries is generated by calling UUID.randomUUID, we could use simple counter instead. > - The produced file is unnecessarily large. We know how large a CEN entry is, let's take advantage of that to create a file with the minimal size. > - By adding a maximally large extra field to the CEN entries, we get away with fewer CEN records and save memory > - The summary and comments of the test can be improved to help explain the purpose of the test and how we reach the limit being tested. > > These speedups reduced the runtime from 4 min 17 sec to 4 seconds on my Macbook Pro. The produced ZIP size was reduced from 5.7 GB to 2 GB. Memory consumption is down from 8GB to something like 12MB. Eirik Bjorsnos has updated the pull request incrementally with two additional commits since the last revision: - MAX_EXTRA_FIELD_SIZE can be better expressed as 0xFFFF - Bring back '@requires sun.arch.data.model == 64' for now ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12991/files - new: https://git.openjdk.org/jdk/pull/12991/files/8969de16..a1a77192 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12991&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12991&range=04-05 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/12991.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12991/head:pull/12991 PR: https://git.openjdk.org/jdk/pull/12991 From duke at openjdk.org Sun Mar 12 21:28:59 2023 From: duke at openjdk.org (iaroslavski) Date: Sun, 12 Mar 2023 21:28:59 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v19] 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) * Use uninitialized array for buffers ------------- Changes: - all: https://git.openjdk.org/jdk/pull/3938/files - new: https://git.openjdk.org/jdk/pull/3938/files/203610a5..4f6ece03 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=3938&range=18 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=3938&range=17-18 Stats: 98 lines in 4 files changed: 8 ins; 14 del; 76 mod Patch: https://git.openjdk.org/jdk/pull/3938.diff Fetch: git fetch https://git.openjdk.org/jdk pull/3938/head:pull/3938 PR: https://git.openjdk.org/jdk/pull/3938 From martin at openjdk.org Mon Mar 13 01:34:22 2023 From: martin at openjdk.org (Martin Buchholz) Date: Mon, 13 Mar 2023 01:34:22 GMT Subject: RFR: 8304020: Speed up test/jdk/java/util/zip/ZipFile/TestTooManyEntries.java and clarify its purpose [v6] In-Reply-To: References: <8Imbn5098NjdJMPtI2UD7BNSP3oRM4q8vB5_Lq1pLhs=.4686073b-207c-4e3b-b6c0-6227037b11b6@github.com> Message-ID: On Sun, 12 Mar 2023 21:25:46 GMT, Eirik Bjorsnos wrote: >> Please review this PR which speeds up TestTooManyEntries and clarifies its purpose: >> >> - The name 'TestTooManyEntries' does not clearly convey the purpose of the test. What is tested is the validation that the total CEN size fits in a Java byte array. Suggested rename: CenSizeTooLarge >> - The test creates DEFLATED entries which incurs zlib costs and File Data / Data Descriptors for no additional benefit. We can use STORED instead. >> - By creating a single LocalDateTime and setting it with `ZipEntry.setTimeLocal`, we can avoid repeated time zone calculations. >> - The name of entries is generated by calling UUID.randomUUID, we could use simple counter instead. >> - The produced file is unnecessarily large. We know how large a CEN entry is, let's take advantage of that to create a file with the minimal size. >> - By adding a maximally large extra field to the CEN entries, we get away with fewer CEN records and save memory >> - The summary and comments of the test can be improved to help explain the purpose of the test and how we reach the limit being tested. >> >> These speedups reduced the runtime from 4 min 17 sec to 4 seconds on my Macbook Pro. The produced ZIP size was reduced from 5.7 GB to 2 GB. Memory consumption is down from 8GB to something like 12MB. > > Eirik Bjorsnos has updated the pull request incrementally with two additional commits since the last revision: > > - MAX_EXTRA_FIELD_SIZE can be better expressed as 0xFFFF > - Bring back '@requires sun.arch.data.model == 64' for now test/jdk/java/util/zip/ZipFile/CenSizeTooLarge.java line 53: > 51: > 52: // Maximum size (unsigned short) of an extra field allowed by the standard > 53: static final int MAX_EXTRA_FIELD_SIZE = 0XFFFF; 4.4.10 file name length: (2 bytes) 4.4.11 extra field length: (2 bytes) 4.4.12 file comment length: (2 bytes) The length of the file name, extra field, and comment fields respectively. The combined length of any directory record and these three fields SHOULD NOT generally exceed 65,535 bytes. ------------- PR: https://git.openjdk.org/jdk/pull/12991 From duke at openjdk.org Mon Mar 13 03:21:22 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Mon, 13 Mar 2023 03:21:22 GMT Subject: RFR: 8304020: Speed up test/jdk/java/util/zip/ZipFile/TestTooManyEntries.java and clarify its purpose [v6] In-Reply-To: References: <8Imbn5098NjdJMPtI2UD7BNSP3oRM4q8vB5_Lq1pLhs=.4686073b-207c-4e3b-b6c0-6227037b11b6@github.com> Message-ID: On Mon, 13 Mar 2023 01:31:20 GMT, Martin Buchholz wrote: >> Eirik Bjorsnos has updated the pull request incrementally with two additional commits since the last revision: >> >> - MAX_EXTRA_FIELD_SIZE can be better expressed as 0xFFFF >> - Bring back '@requires sun.arch.data.model == 64' for now > > test/jdk/java/util/zip/ZipFile/CenSizeTooLarge.java line 53: > >> 51: >> 52: // Maximum size (unsigned short) of an extra field allowed by the standard >> 53: static final int MAX_EXTRA_FIELD_SIZE = 0XFFFF; > > 4.4.10 file name length: (2 bytes) > 4.4.11 extra field length: (2 bytes) > 4.4.12 file comment length: (2 bytes) > > The length of the file name, extra field, and comment > fields respectively. The combined length of any > directory record and these three fields SHOULD NOT > generally exceed 65,535 bytes. `The combined length of any directory record and these three fields SHOULD NOT generally exceed 65,535 bytes.` I was not aware of this 'combined length' clause. Are you suggesting we take this into account in this test? I feel that would be somewhat strange, given that this constraint seems not be be enforced at all by ZipEntry or ZipOutputStream: ZipEntry(String name): if (name.length() > 0xFFFF) { throw new IllegalArgumentException("entry name too long"); } ZipOutputStream.writeCEN: if (commentBytes != null) { writeBytes(commentBytes, 0, Math.min(commentBytes.length, 0xffff)); } ------------- PR: https://git.openjdk.org/jdk/pull/12991 From duke at openjdk.org Mon Mar 13 08:21:23 2023 From: duke at openjdk.org (liach) Date: Mon, 13 Mar 2023 08:21:23 GMT Subject: RFR: 8304031: Classfile API cannot encode Primitive Class as Condy Message-ID: <6SEB6ZAh2b0ayMCo5EfvOW-adtsAysbf1Zk6qBbh2SI=.96417080-f2a8-424d-9a26-0ed68f6b33ac@github.com> Without this patch, the Classfile API tries to encode PrimitiveClassDesc as CONSTANT_Class_info and error in `toInternalName`. ------------- Commit messages: - 8304031: Classfile API cannot encode Primitive Class as Condy Changes: https://git.openjdk.org/jdk/pull/12996/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12996&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304031 Stats: 74 lines in 2 files changed: 73 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12996.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12996/head:pull/12996 PR: https://git.openjdk.org/jdk/pull/12996 From cstein at openjdk.org Mon Mar 13 08:24:05 2023 From: cstein at openjdk.org (Christian Stein) Date: Mon, 13 Mar 2023 08:24:05 GMT Subject: RFR: JDK-8304036: Use CommandLine class from shared module Message-ID: This pull request addresses the open ends left by [JDK-8236919](https://bugs.openjdk.org/browse/JDK-8236919): - #11272 Changes: - [x] Extend list of targeted exports of `jdk.internal.opt/jdk.internal.opt` to `jdk.compiler` and `jdk.javadoc` - [x] Use shared `CommandLine.java` in `jdk.compiler` module - [x] Use shared `CommandLine.java` in `jdk.javadoc` module - [x] Remove `CommandLine.java` from `jdk.compiler` module ------------- Commit messages: - Add missing import - JDK-8304036: Use CommandLine class from shared module Changes: https://git.openjdk.org/jdk/pull/12997/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12997&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304036 Stats: 310 lines in 6 files changed: 7 ins; 297 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/12997.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12997/head:pull/12997 PR: https://git.openjdk.org/jdk/pull/12997 From rgiulietti at openjdk.org Mon Mar 13 09:27:55 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Mon, 13 Mar 2023 09:27:55 GMT Subject: RFR: 8303648: Add String.indexOf(String str, int beginIndex, int endIndex) [v3] In-Reply-To: References: Message-ID: > As a followup of [JDK-8302590](https://bugs.openjdk.org/browse/JDK-8302590), this issue covers the analogous case for a search of a string rather than a character. Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: 8303648: Add String.indexOf(String str, int beginIndex, int endIndex) English grammar correction. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12903/files - new: https://git.openjdk.org/jdk/pull/12903/files/5303bea0..b644469b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12903&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12903&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12903.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12903/head:pull/12903 PR: https://git.openjdk.org/jdk/pull/12903 From duke at openjdk.org Mon Mar 13 09:31:26 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Mon, 13 Mar 2023 09:31:26 GMT Subject: RFR: 8304020: Speed up test/jdk/java/util/zip/ZipFile/TestTooManyEntries.java and clarify its purpose [v6] In-Reply-To: References: <8Imbn5098NjdJMPtI2UD7BNSP3oRM4q8vB5_Lq1pLhs=.4686073b-207c-4e3b-b6c0-6227037b11b6@github.com> Message-ID: On Sun, 12 Mar 2023 21:25:46 GMT, Eirik Bjorsnos wrote: >> Please review this PR which speeds up TestTooManyEntries and clarifies its purpose: >> >> - The name 'TestTooManyEntries' does not clearly convey the purpose of the test. What is tested is the validation that the total CEN size fits in a Java byte array. Suggested rename: CenSizeTooLarge >> - The test creates DEFLATED entries which incurs zlib costs and File Data / Data Descriptors for no additional benefit. We can use STORED instead. >> - By creating a single LocalDateTime and setting it with `ZipEntry.setTimeLocal`, we can avoid repeated time zone calculations. >> - The name of entries is generated by calling UUID.randomUUID, we could use simple counter instead. >> - The produced file is unnecessarily large. We know how large a CEN entry is, let's take advantage of that to create a file with the minimal size. >> - By adding a maximally large extra field to the CEN entries, we get away with fewer CEN records and save memory >> - The summary and comments of the test can be improved to help explain the purpose of the test and how we reach the limit being tested. >> >> These speedups reduced the runtime from 4 min 17 sec to 4 seconds on my Macbook Pro. The produced ZIP size was reduced from 5.7 GB to 2 GB. Memory consumption is down from 8GB to something like 12MB. > > Eirik Bjorsnos has updated the pull request incrementally with two additional commits since the last revision: > > - MAX_EXTRA_FIELD_SIZE can be better expressed as 0xFFFF > - Bring back '@requires sun.arch.data.model == 64' for now The test now runs fast with much less memory, but still consumes 2GB of disk space. I brought back `@requires (sun.arch.data.model == "64")`, is this required for files > 2GB? We could bring down the consumed disk space to 131MB by using a sparse file. Whether this is worth pursuing depends on whether the 2GB file is considered problematic. Here's the SparseFileOutputStream used to bring the size down to 131MB: /** * By writing mostly extra fields as sparse 'holes', we can save disk space * used by this test from ~2GB to ~131MB */ private static class SparseOutputStream extends FilterOutputStream { private final byte[] extra; private final FileChannel channel; public SparseOutputStream(byte[] extra, FileChannel channel) { super(new BufferedOutputStream(Channels.newOutputStream(channel))); this.extra = extra; this.channel = channel; } @Override public void write(byte[] b, int off, int len) throws IOException { if (b == extra && off == 0 && len == extra.length) { // Write extra field header out.write(b, off, EXTRA_HEADER_LENGTH); out.flush(); // The data is all zeros, we can advance the position instead channel.position(channel.position() + len - EXTRA_HEADER_LENGTH); } else { out.write(b, off, len); } } } ------------- PR: https://git.openjdk.org/jdk/pull/12991 From djelinski at openjdk.org Mon Mar 13 09:48:19 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 13 Mar 2023 09:48:19 GMT Subject: RFR: 8303814: getLastErrorString should avoid charset conversions [v2] In-Reply-To: References: Message-ID: > This patch modifies the `getLastErrorString` method to return a `jstring`. Thanks to that we can avoid unnecessary back and forth conversions between Unicode and other charsets on Windows. > > Other changes include: > - the Windows implementation of `getLastErrorString` no longer checks `errno`. I verified all uses of the method and confirmed that `errno` is not used anywhere. > - While at it, I found and fixed a few calls to `JNU_ThrowIOExceptionWithLastError` that were done in context where `LastError` was not set. > - jdk.hotspot.agent was modified to use `JNU_ThrowByNameWithLastError` and `JNU_ThrowByName` instead of `getLastErrorString`; the code is expected to have identical behavior. > - zip_util was modified to return static messages instead of generated ones. The generated messages were not observed anywhere, because they were replaced by a static message in ZIP_Open, which is the only method used by other native code. > - `getLastErrorString` is no longer exported by libjava. > > Tier1-3 tests continue to pass. > > No new automated regression test; testing this requires installing a language pack that cannot be displayed in the current code page. > Tested this manually by installing Chinese language pack on English Windows 11, selecting Chinese language, then checking if the message on exception thrown by `InetAddress.getByName("nonexistent.local");` starts with `"?????????"` (or `"\u4e0d\u77e5\u9053\u8fd9\u6837\u7684\u4e3b\u673a\u3002"`). Without the change, the exception message started with a row of question marks. Daniel Jeli?ski has updated the pull request incrementally with three additional commits since the last revision: - Address review comments - Mention that the returned text is static and thread safe - Define buffer size ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12922/files - new: https://git.openjdk.org/jdk/pull/12922/files/8ab8d729..ea91b651 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12922&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12922&range=00-01 Stats: 8 lines in 4 files changed: 2 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/12922.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12922/head:pull/12922 PR: https://git.openjdk.org/jdk/pull/12922 From djelinski at openjdk.org Mon Mar 13 09:48:22 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 13 Mar 2023 09:48:22 GMT Subject: RFR: 8303814: getLastErrorString should avoid charset conversions [v2] In-Reply-To: References: Message-ID: On Fri, 10 Mar 2023 21:47:45 GMT, Roger Riggs wrote: >> Daniel Jeli?ski has updated the pull request incrementally with three additional commits since the last revision: >> >> - Address review comments >> - Mention that the returned text is static and thread safe >> - Define buffer size > > src/java.base/share/native/libjava/jni_util.c line 133: > >> 131: if (s != NULL) { >> 132: jobject x = NULL; >> 133: if (messagelen) { > > Avoid implicit compare with 0; use `messagelen > 0` or similar. preexisting, but fixed. ------------- PR: https://git.openjdk.org/jdk/pull/12922 From djelinski at openjdk.org Mon Mar 13 09:48:27 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 13 Mar 2023 09:48:27 GMT Subject: RFR: 8303814: getLastErrorString should avoid charset conversions [v2] In-Reply-To: References: Message-ID: On Thu, 9 Mar 2023 18:08:32 GMT, Naoto Sato wrote: >> Daniel Jeli?ski has updated the pull request incrementally with three additional commits since the last revision: >> >> - Address review comments >> - Mention that the returned text is static and thread safe >> - Define buffer size > > src/java.base/share/native/libzip/zip_util.c line 767: > >> 765: * or NULL if an error occurred. If a zip error occurred then *pmsg will >> 766: * be set to the error message text if pmsg != 0. Otherwise, *pmsg will be >> 767: * set to NULL. Caller doesn't need to free the error message. > > I'd put some more context here why the caller does not need to free. (as it is a static text) Added; also mentioned that we want the buffer to be thread-safe. Let me know if that's what you had in mind. > src/java.base/windows/native/libjava/jni_util_md.c line 80: > >> 78: 0, >> 79: buf, >> 80: sizeof(buf) / sizeof(WCHAR), > > Maybe better to #define the size 256 so that this division is not needed. done ------------- PR: https://git.openjdk.org/jdk/pull/12922 From alanb at openjdk.org Mon Mar 13 10:03:50 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 13 Mar 2023 10:03:50 GMT Subject: RFR: 8303530: Add system property for custom JAXP configuration file [v2] In-Reply-To: References: Message-ID: On Sat, 11 Mar 2023 05:34:39 GMT, Joe Wang wrote: >> Add a system property, jdk.xml.config.file, to return the path to a custom JAXP configuration file. The current configuration file, jaxp.properties, that the JDK supports will become the default configuration file. >> >> CSR: https://bugs.openjdk.org/browse/JDK-8303531 >> >> Tests: XML SQE and JCK tests passed. > > Joe Wang has updated the pull request incrementally with one additional commit since the last revision: > > clean up tests; fix copy&paste error. src/java.xml/share/classes/javax/xml/XMLConstants.java line 247: > 245: * configuration file. > 246: * If the file exists and the system property is specified, its value will > 247: * be used to override the default of the property. This follows the documenting of the equivalent system property but that text doesn't say what it overrides. I think it overrides the default value but does not override programmatic use. The new text documents that the configuration file can be used. It is a bit clearer that it overrides the default value but doesn't say anything about programmatic use. The reader will also wonder if the system property overrides the configuration file or the other way around. So I think my point is that the precedent needs to clearly documented, maybe it document the ordering in one place and have each property reference it. In the case of XMLConstants, then it might also be simpler to put the text in the class description rather than having it repeated in every property - maybe experiment with that to see if it helps or not. In passing, I assume these links can be use `{@docRoot}/java.xml/module-summary.html`. src/java.xml/share/classes/javax/xml/catalog/CatalogFeatures.java line 171: > 169: * system properties, and > 170: * configuration file, > 171: * with a preference in the same order. You may need to clarify the preference order a bit further, is is left-to-right or right-to-left in this list? ------------- PR: https://git.openjdk.org/jdk/pull/12985 From alanb at openjdk.org Mon Mar 13 10:06:57 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 13 Mar 2023 10:06:57 GMT Subject: RFR: 8303530: Add system property for custom JAXP configuration file [v2] In-Reply-To: References: Message-ID: On Sat, 11 Mar 2023 05:34:39 GMT, Joe Wang wrote: >> Add a system property, jdk.xml.config.file, to return the path to a custom JAXP configuration file. The current configuration file, jaxp.properties, that the JDK supports will become the default configuration file. >> >> CSR: https://bugs.openjdk.org/browse/JDK-8303531 >> >> Tests: XML SQE and JCK tests passed. > > Joe Wang has updated the pull request incrementally with one additional commit since the last revision: > > clean up tests; fix copy&paste error. src/java.xml/share/classes/javax/xml/catalog/CatalogFeatures.java line 183: > 181: * configuration file. > 182: * In case of multiple interfaces, the latest in a procedure shall take preference. > 183: * For {@link Feature#FILES}, this means that the URI(s) specified through the methods "multiple interfaces" and "the latest in a procedure" aren't very clear here. If the setup for this section documents the precedence order more clearly then it will make it easier to word this section. ------------- PR: https://git.openjdk.org/jdk/pull/12985 From alanb at openjdk.org Mon Mar 13 10:14:12 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 13 Mar 2023 10:14:12 GMT Subject: RFR: 8303530: Add system property for custom JAXP configuration file [v2] In-Reply-To: References: Message-ID: On Sat, 11 Mar 2023 05:34:39 GMT, Joe Wang wrote: >> Add a system property, jdk.xml.config.file, to return the path to a custom JAXP configuration file. The current configuration file, jaxp.properties, that the JDK supports will become the default configuration file. >> >> CSR: https://bugs.openjdk.org/browse/JDK-8303531 >> >> Tests: XML SQE and JCK tests passed. > > Joe Wang has updated the pull request incrementally with one additional commit since the last revision: > > clean up tests; fix copy&paste error. src/java.xml/share/classes/module-info.java line 31: > 29: * > 30: *

Configuration File

> 31: * The java.xml (JAXP) Configuration File is used for configuring factories in the The first sentence of the module description defines "JAXP" as the abbreviation for "Java API for XML Processing" so the usage looks a bit strange. Maybe the introduction to this section should say that the XML processing APIs in this module allow a configuration file the XML processors. ------------- PR: https://git.openjdk.org/jdk/pull/12985 From asotona at openjdk.org Mon Mar 13 10:17:59 2023 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 13 Mar 2023 10:17:59 GMT Subject: Integrated: 8294966: Convert jdk.jartool/sun.tools.jar.FingerPrint to use the ClassFile API to parse JAR entries In-Reply-To: References: Message-ID: On Thu, 15 Dec 2022 14:56:03 GMT, Adam Sotona wrote: > 8294966: Convert jdk.jartool/sun.tools.jar.FingerPrint to use the ClassFile API to parse JAR entries > > Please review. > Thanks, > Adam This pull request has now been integrated. Changeset: 25e7ac22 Author: Adam Sotona URL: https://git.openjdk.org/jdk/commit/25e7ac226a3be9c064c0a65c398a8165596150f7 Stats: 122 lines in 4 files changed: 48 ins; 40 del; 34 mod 8294966: Convert jdk.jartool/sun.tools.jar.FingerPrint to use the ClassFile API to parse JAR entries Reviewed-by: mchung ------------- PR: https://git.openjdk.org/jdk/pull/11694 From jpai at openjdk.org Mon Mar 13 10:32:06 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 13 Mar 2023 10:32:06 GMT Subject: RFR: 8304006: jlink should create the jimage file in the native endian for the target platform [v5] 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.org/browse/JDK-8206890? > > The `jlink` command allows a `--endian` option to specify the byte order in the generated image. Before this change, when such a image was being launched, the code would assume the byte order in the image to be the native order of the host where the image is being launched. That would result in failure to launch java, as noted in the linked issue. > > The commit in this PR, changes relevant places to not assume native order and instead determine the byte order by reading the magic bytes in the image file's header content. > > A new jtreg test has been added which reproduces the issue and verifies the fix. Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision: - only include known supported arch - Alan's suggestion - look into the ModuleTarget attribute in module-info.class only if this is a cross-platform image generation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11943/files - new: https://git.openjdk.org/jdk/pull/11943/files/e68c2105..bad17122 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11943&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11943&range=03-04 Stats: 79 lines in 2 files changed: 52 ins; 4 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/11943.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11943/head:pull/11943 PR: https://git.openjdk.org/jdk/pull/11943 From jpai at openjdk.org Mon Mar 13 10:32:13 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 13 Mar 2023 10:32:13 GMT Subject: RFR: 8304006: jlink should create the jimage file in the native endian for the target platform [v4] In-Reply-To: References: Message-ID: On Sun, 12 Mar 2023 08:55:19 GMT, Alan Bateman wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> missed ppc64 from the arch mapping > > src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 827: > >> 825: if (ref instanceof ModuleReferenceImpl modRefImpl >> 826: && modRefImpl.moduleTarget() != null) { >> 827: targetPlatform = modRefImpl.moduleTarget().targetPlatform(); > > It might be better to only look for the ModuleTarget attribute when cross linking. modsPaths.get("java.base") will give you the path to the packaged module for java.base, getDefaultModulePath() will give you the location of the packaged modules in the current execution environment. If getDefaultModulePath() is the parent of the location containing java.base then it can use the current endianness. > > Also just to say that if it would be an error if java.base is not in the Configuration, same thing if there is no packaged module for java.base. Hello Alan, > If getDefaultModulePath() is the parent of the location containing java.base then it can use the current endianness. I've now updated this PR to implement this suggestion. The `ModuleTarget` attribute in java.base's `module-info.class` will only be checked if the java.base isn't from the current execution environment's default jmods location. ------------- PR: https://git.openjdk.org/jdk/pull/11943 From jpai at openjdk.org Mon Mar 13 10:32:15 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 13 Mar 2023 10:32:15 GMT Subject: RFR: 8304006: jlink should create the jimage file in the native endian for the target platform [v4] In-Reply-To: References: Message-ID: On Mon, 13 Mar 2023 10:26:23 GMT, Jaikiran Pai wrote: >> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 827: >> >>> 825: if (ref instanceof ModuleReferenceImpl modRefImpl >>> 826: && modRefImpl.moduleTarget() != null) { >>> 827: targetPlatform = modRefImpl.moduleTarget().targetPlatform(); >> >> It might be better to only look for the ModuleTarget attribute when cross linking. modsPaths.get("java.base") will give you the path to the packaged module for java.base, getDefaultModulePath() will give you the location of the packaged modules in the current execution environment. If getDefaultModulePath() is the parent of the location containing java.base then it can use the current endianness. >> >> Also just to say that if it would be an error if java.base is not in the Configuration, same thing if there is no packaged module for java.base. > > Hello Alan, > >> If getDefaultModulePath() is the parent of the location containing java.base then it can use the current endianness. > > I've now updated this PR to implement this suggestion. The `ModuleTarget` attribute in java.base's `module-info.class` will only be checked if the java.base isn't from the current execution environment's default jmods location. > Also just to say that if it would be an error if java.base is not in the Configuration, same thing if there is no packaged module for java.base. I've now added `assert`s to expect this module to be present. ------------- PR: https://git.openjdk.org/jdk/pull/11943 From jpai at openjdk.org Mon Mar 13 10:35:27 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 13 Mar 2023 10:35:27 GMT Subject: RFR: 8304006: jlink should create the jimage file in the native endian for the target platform [v4] In-Reply-To: References: Message-ID: <5Ge5TYwQa-eWk1ozGWIRnPttv8VmqYn4Ko0_C4BcGAY=.6ef51a2a-04e6-4f17-8263-98615d33b1ef@github.com> On Sun, 12 Mar 2023 09:15:20 GMT, Alan Bateman wrote: > When cross linking and the target platform is unknown then it might be better to have this fail rather than defaulting to the endianness of the current platform, otherwise this risks create a run-time image that is not usable. I wasn't sure if we wanted to fail such cases when generating the image, but like you say, the generate image would be unusable anyway. I've now followed your suggestion to fail in such cases. > I see you've listed a bunch of unknown platforms in the list. If getNativeEndianOfTargetPlatform fails when it encounters an unknown platform then help downstream porters to know that there is something to look at here. I borrowed that list from our current build file here https://github.com/openjdk/jdk/blob/master/make/autoconf/platform.m4#L26. I think it's likely that it isn't the current supported list of platforms. I checked the `porters-dev` mailing list and I see that recently we have created this wiki which lists the supported platforms https://wiki.openjdk.org/display/HotSpot/Ports. Based on that I've trimmed down this list in the code (I continue to include `loongarch64` because I recently saw some PR which dealt with that architecture in mainline). Having said that, it might be that this too isn't the fully accurate list, so please let me know if this needs additional changes. ------------- PR: https://git.openjdk.org/jdk/pull/11943 From jpai at openjdk.org Mon Mar 13 10:40:39 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 13 Mar 2023 10:40:39 GMT Subject: RFR: 8304006: jlink should create the jimage file in the native endian for the target platform [v3] In-Reply-To: References: Message-ID: On Sat, 11 Mar 2023 11:38:43 GMT, Jim Laskey wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> undo unintentional copyright year change > > src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 916: > >> 914: } >> 915: String archName = targetPlatform.substring(index + 1); >> 916: return switch (archName) { > > Not that keen having this table buried in code. It's something that should be at the build level, maybe read from a resource? Hello Jim, yes it feels odd to be listing it in the code here. Adding it as a runtime resource (like a properties file?) too seems a bit odd to me. Perhaps this should be written out during build to some templated Java file which can then be used in this code? Something like a `SupportedPlatforms.java.template` file under the `jdk.tools.jlink.internal` package which has a: ``` java ByteOrder getByteOrder(String platform) method which gets generated during the build? Either way, I think there would then need to be a build file of officially supported platforms which can be sourced into that template file. I'm not too familiar with the porting process, is there such a precendence for it? Do porters update such files to add to the list as a supported platform? ------------- PR: https://git.openjdk.org/jdk/pull/11943 From asotona at openjdk.org Mon Mar 13 11:10:32 2023 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 13 Mar 2023 11:10:32 GMT Subject: RFR: 8294974: Convert jdk.jshell/jdk.jshell.execution.LocalExecutionControl to use the Classfile API to instrument classes [v5] In-Reply-To: References: Message-ID: > 8294974: jdk.jshell jdk.jshell.execution.LocalExecutionControl uses ASM to instrument classes > This patch converts it to use Classfile API. > > Please review. > Thanks, > Adam Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 197 commits: - increased jtreg maxOutputSize for Classfile API tests - Merge branch 'master' into JDK-8294974 # Conflicts: # src/java.base/share/classes/module-info.java - fixed empty line - Merge branch 'master' into JDK-8294974-jshell - Merge branch 'master' into JDK-8294974-jshell - Merge branch 'master' into JDK-8294974-jshell - Merge branch 'JDK-8294982' into JDK-8294974 - removed obsolete javadoc from implementation classes - minor fix in CodeBuilder and added test cases to LDCTest - EntryMap::nextPowerOfTwo delegates to Long:numberOfLeadingZeros - ... and 187 more: https://git.openjdk.org/jdk/compare/25e7ac22...9ddfefb0 ------------- Changes: https://git.openjdk.org/jdk/pull/11413/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11413&range=04 Stats: 55 lines in 3 files changed: 11 ins; 21 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/11413.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11413/head:pull/11413 PR: https://git.openjdk.org/jdk/pull/11413 From alanb at openjdk.org Mon Mar 13 11:37:23 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 13 Mar 2023 11:37:23 GMT Subject: RFR: 8303530: Add system property for custom JAXP configuration file [v2] In-Reply-To: References: Message-ID: On Sat, 11 Mar 2023 05:34:39 GMT, Joe Wang wrote: >> Add a system property, jdk.xml.config.file, to return the path to a custom JAXP configuration file. The current configuration file, jaxp.properties, that the JDK supports will become the default configuration file. >> >> CSR: https://bugs.openjdk.org/browse/JDK-8303531 >> >> Tests: XML SQE and JCK tests passed. > > Joe Wang has updated the pull request incrementally with one additional commit since the last revision: > > clean up tests; fix copy&paste error. src/java.xml/share/classes/javax/xml/stream/XMLEventFactory.java line 139: > 137: * Use the value of the property {@code factoryId} set in the > 138: * configuration file, > 139: * stax.properties or jaxp.properties by default. If the file exists and Is it time to drop all references to stax.properties from the API docs? src/java.xml/share/classes/module-info.java line 89: > 87: * the StAX factories for the Factory Lookup Mechanism > 88: * only. The files, if exist, are typically located in the {@code conf} > 89: * directory of the Java installation. If jdk.xml.config.file is not set, should the reader assume it's default value is ${java.home}/conf/jaxp.properties? If so, they this is an implementation specific default, right? ------------- PR: https://git.openjdk.org/jdk/pull/12985 From asotona at openjdk.org Mon Mar 13 13:46:24 2023 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 13 Mar 2023 13:46:24 GMT Subject: RFR: 8294962: Convert java.base/jdk.internal.module package to use the Classfile API to modify and write module-info.class [v4] In-Reply-To: References: Message-ID: <6ElqezMc7McFhcHQsB0oTaoSII7RJ569icRg-mT4-3g=.6d902eed-42d0-4578-ba6b-aebc20856dc1@github.com> On Sat, 11 Mar 2023 17:00:18 GMT, Alan Bateman wrote: >> `buildModules` is expected to be called with additional packages but instead it's called with all packages including all exported and open packages. >> >> >> /** >> * Build a module descriptor into a byte array. >> * @param moduleAttribute the {@code Module} attribute >> * @param packages additional module packages >> * @param handler a handler that receives a {@link ClassBuilder} >> * @return the classfile bytes >> */ >> public static byte[] buildModule(ModuleAttribute moduleAttribute, >> List packages, >> Consumer handler) { >> >> >> I checked the implementation that seems to match `@param packages` that expects additional module packages that are not exported nor open. If it intends to take additional packages, it will need to filter the exported and open packages at the callsite. >> >> Or the `packages` parameter lists all packages that will be used to create `ModulePackages` attribute. This seems to be easier to understand. > > Maybe the variants of Classfile.buildModule need to be looked at again. For the usage here, buildModule(ModuleAttribute, Consumer) would be more useful as it would allow all of the additional attributes to be emitted in the handler rather than having buildModule making the decision on whether to emit the ModulePackages attribute. `Classfile::buildModule` is a helper method simplifying the major use case - building valid module with minimal user effort and knowledge. It emits `ModulePackages` if there are any packages specified and not exported nor opened. That is the configuration which JVM expects and majority of users are not aware of. Other module-specific attributes can be added in the underlying handler, using `ClassBuilder::with`. A different building approach can be used in cases (which I would like to know more about) where even `ModulePackages` attribute needs to be "customised" or provided unconditionally. It is always possible to build module as a class using `Classfile::build` from scratch and provide all the attributes manually. ------------- PR: https://git.openjdk.org/jdk/pull/11368 From asotona at openjdk.org Mon Mar 13 13:50:40 2023 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 13 Mar 2023 13:50:40 GMT Subject: RFR: 8294962: Convert java.base/jdk.internal.module package to use the Classfile API to modify and write module-info.class [v4] In-Reply-To: <6ElqezMc7McFhcHQsB0oTaoSII7RJ569icRg-mT4-3g=.6d902eed-42d0-4578-ba6b-aebc20856dc1@github.com> References: <6ElqezMc7McFhcHQsB0oTaoSII7RJ569icRg-mT4-3g=.6d902eed-42d0-4578-ba6b-aebc20856dc1@github.com> Message-ID: On Mon, 13 Mar 2023 13:43:22 GMT, Adam Sotona wrote: >> Maybe the variants of Classfile.buildModule need to be looked at again. For the usage here, buildModule(ModuleAttribute, Consumer) would be more useful as it would allow all of the additional attributes to be emitted in the handler rather than having buildModule making the decision on whether to emit the ModulePackages attribute. > > `Classfile::buildModule` is a helper method simplifying the major use case - building valid module with minimal user effort and knowledge. It emits `ModulePackages` if there are any packages specified and not exported nor opened. That is the configuration which JVM expects and majority of users are not aware of. > Other module-specific attributes can be added in the underlying handler, using `ClassBuilder::with`. > > A different building approach can be used in cases (which I would like to know more about) where even `ModulePackages` attribute needs to be "customised" or provided unconditionally. It is always possible to build module as a class using `Classfile::build` from scratch and provide all the attributes manually. Or another approach for the specific use cases might be to use `Classfile::buildModule` with empty list of packages and then provide custom `ModulePackagesAttribute` to the handler directly. ------------- PR: https://git.openjdk.org/jdk/pull/11368 From rriggs at openjdk.org Mon Mar 13 14:15:17 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 13 Mar 2023 14:15:17 GMT Subject: RFR: 8303485: Replacing os.name for operating system customization [v2] In-Reply-To: References: Message-ID: On Fri, 10 Mar 2023 21:21:56 GMT, Roger Riggs wrote: >> Improvements to support OS specific customization for JDK internal use: >> - To select values and code; allowing elimination of unused code and values >> - Optionally evaluated by build processes, compilation, or archiving (i.e. CDS) >> - Simple API to replace adhoc comparisons with `os.name` >> - Clear and consistent use across build, runtime, and JDK modules >> >> The PR includes updates within java.base to use the new API. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Move OperatingSystem from jdk.internal.misc to jdk.internal.util > Rename Mac -> MacOS; isMac() -> isMacOS() A quick look at the freebsd port (jdk19) shows about 19k lines of new code or changes across 294 files, config, makefiles, hotspot and other native code. Pretty much what you'd expect in terms of api differences, configuration differences, and alternate implementations. The changes are done with ifdefs in native code, adding enumeration cases where necessary, and testing of os.name. Changing to an equivalent test for operating system is a lateral move. ------------- PR: https://git.openjdk.org/jdk/pull/12931 From alanb at openjdk.org Mon Mar 13 14:21:58 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 13 Mar 2023 14:21:58 GMT Subject: RFR: 8294962: Convert java.base/jdk.internal.module package to use the Classfile API to modify and write module-info.class [v4] In-Reply-To: References: <6ElqezMc7McFhcHQsB0oTaoSII7RJ569icRg-mT4-3g=.6d902eed-42d0-4578-ba6b-aebc20856dc1@github.com> Message-ID: On Mon, 13 Mar 2023 13:47:31 GMT, Adam Sotona wrote: >> `Classfile::buildModule` is a helper method simplifying the major use case - building valid module with minimal user effort and knowledge. It emits `ModulePackages` if there are any packages specified and not exported nor opened. That is the configuration which JVM expects and majority of users are not aware of. >> Other module-specific attributes can be added in the underlying handler, using `ClassBuilder::with`. >> >> A different building approach can be used in cases (which I would like to know more about) where even `ModulePackages` attribute needs to be "customised" or provided unconditionally. It is always possible to build module as a class using `Classfile::build` from scratch and provide all the attributes manually. > > Or another approach for the specific use cases might be to use `Classfile::buildModule` with empty list of packages and then provide custom `ModulePackagesAttribute` to the handler directly. > `Classfile::buildModule` is a helper method simplifying the major use case - building valid module with minimal user effort and knowledge. It emits `ModulePackages` if there are any packages specified and not exported nor opened. That is the configuration which JVM expects and majority of users are not aware of. ModulePackages is a performance optimization. When present, the value is the set of packages in the module. If not present, the module contents need to be scanned to discover the set of packages. I think it's just a bit too surprising for Classfile::buildModule to emit the ModulePackages attribute sometimes and not others. I think it would be better to change is so that calling it with ModuleAttribute will emit a Module attribute. The overloads that take a Module plus a set of packages can emit a Module + ModulePackage unconditionally. ------------- PR: https://git.openjdk.org/jdk/pull/11368 From alanb at openjdk.org Mon Mar 13 14:46:26 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 13 Mar 2023 14:46:26 GMT Subject: RFR: 8304006: jlink should create the jimage file in the native endian for the target platform [v5] In-Reply-To: References: Message-ID: On Mon, 13 Mar 2023 10:32:06 GMT, Jaikiran Pai wrote: >> Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8206890? >> >> The `jlink` command allows a `--endian` option to specify the byte order in the generated image. Before this change, when such a image was being launched, the code would assume the byte order in the image to be the native order of the host where the image is being launched. That would result in failure to launch java, as noted in the linked issue. >> >> The commit in this PR, changes relevant places to not assume native order and instead determine the byte order by reading the magic bytes in the image file's header content. >> >> A new jtreg test has been added which reproduces the issue and verifies the fix. > > Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision: > > - only include known supported arch > - Alan's suggestion - look into the ModuleTarget attribute in module-info.class only if this is a cross-platform image generation src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 897: > 895: (PrivilegedExceptionAction) () -> Files.isSameFile(javaBasePath, > 896: currentPlatformJmods.resolve(Path.of("java.base.jmod")))); > 897: } catch (PrivilegedActionException e) { jlink doesn't run with a security manager so no need for the AccessController.doPriv. Assuming the name of the jmod file is probably okay. src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 976: > 974: default -> null; > 975: }; > 976: } To add to Jim's comment, the other thing we think about here is mapping the value of the ModuleTarget attribute to endianness, meaning don't parse it to extract the architecture. ------------- PR: https://git.openjdk.org/jdk/pull/11943 From jcking at openjdk.org Mon Mar 13 15:02:40 2023 From: jcking at openjdk.org (Justin King) Date: Mon, 13 Mar 2023 15:02:40 GMT Subject: RFR: 8303485: Replacing os.name for operating system customization [v2] In-Reply-To: References: Message-ID: On Fri, 10 Mar 2023 21:21:56 GMT, Roger Riggs wrote: >> Improvements to support OS specific customization for JDK internal use: >> - To select values and code; allowing elimination of unused code and values >> - Optionally evaluated by build processes, compilation, or archiving (i.e. CDS) >> - Simple API to replace adhoc comparisons with `os.name` >> - Clear and consistent use across build, runtime, and JDK modules >> >> The PR includes updates within java.base to use the new API. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Move OperatingSystem from jdk.internal.misc to jdk.internal.util > Rename Mac -> MacOS; isMac() -> isMacOS() This PR moves in the right direction. Just disappointing that common ground has not been met with BSD-like port maintainers to get changes into mainline. However that is unrelated to this PR, so ignore me. :) ------------- PR: https://git.openjdk.org/jdk/pull/12931 From jpai at openjdk.org Mon Mar 13 15:03:42 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 13 Mar 2023 15:03:42 GMT Subject: RFR: 8304006: jlink should create the jimage file in the native endian for the target platform [v5] In-Reply-To: References: Message-ID: On Mon, 13 Mar 2023 14:43:35 GMT, Alan Bateman wrote: > To add to Jim's comment, the other thing we think about here is mapping the value of the ModuleTarget attribute to endianness, meaning don't parse it to extract the architecture. So that would then mean updating the build file where we create these jmod file(s) to use a value for `--target-platform` that even includes the endianness in the string value, example: `aix-ppc64-big` and `macos-aarch64-little`. So a change here https://github.com/openjdk/jdk/blob/master/make/CreateJmods.gmk#L252. Did I understand it correctly? (Of course, need to make sure that new format doesn't break expectation of existing code which parses that string) ------------- PR: https://git.openjdk.org/jdk/pull/11943 From alanb at openjdk.org Mon Mar 13 15:07:22 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 13 Mar 2023 15:07:22 GMT Subject: RFR: 8294972: Convert jdk.jlink internal plugins to use the Classfile API [v4] In-Reply-To: References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> Message-ID: On Fri, 10 Mar 2023 12:45:05 GMT, Adam Sotona wrote: >> jdk.jlink internal plugins are heavily using ASM >> >> This patch converts ASM calls to Classfile API. >> >> Please review. >> Thanks, >> Adam > > Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 208 commits: > > - Merge branch 'master' into JDK-8294972-jlink-plugins > > # Conflicts: > # src/java.base/share/classes/module-info.java > - Merge branch 'master' into JDK-8294972-jlink-plugins > - fixed SystemModulesPlugin formatting > - 8303624: The java.lang.Thread.FieldHolder can be null for JNI attaching threads > > Reviewed-by: alanb, dcubed > - 8302360: Atomic*.compareAndExchange Javadoc unclear > > Reviewed-by: martin, dholmes > - 8302779: HelidonAppTest.java fails with "assert(_cb == CodeCache::find_blob(pc())) failed: Must be the same" or SIGSEGV > > Reviewed-by: coleenp, sspitsyn > - 8303691: Fedora based devkit build should load more packages from archive location > > Reviewed-by: mbaesken, erikj > - 8303924: ProblemList serviceability/sa/UniqueVtableTest.java on Linux > > Reviewed-by: dcubed > - 8303609: ProblemList serviceability/sa/TestSysProps.java with ZGC > > Reviewed-by: dcubed > - 8289765: JDI EventSet/resume/resume008 failed with "ERROR: suspendCounts don't match for : VirtualThread-unparker" > > Reviewed-by: sspitsyn, kevinw > - ... and 198 more: https://git.openjdk.org/jdk/compare/b1d89f30...cfc612ec I've done a first pass over the SystemModulesPlugins. There are >1000 of changes to that plugin but it looks quite good. src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 75: > 73: import jdk.internal.module.ModuleTarget; > 74: > 75: import jdk.internal.classfile.attribute.ModulePackagesAttribute; I don't think this is directly used. src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 866: > 864: } > 865: > 866: MethodTypeDesc desc = MethodTypeDesc.ofDescriptor("(Ljava/lang/Object;Ljava/lang/Object;)Ljava/util/Map$Entry;"); It would be helpful if some of the overly long lines could be trimmed down a bit as it's really hard to look at changes side-by-side. ------------- PR: https://git.openjdk.org/jdk/pull/12944 From alanb at openjdk.org Mon Mar 13 15:10:28 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 13 Mar 2023 15:10:28 GMT Subject: RFR: 8304006: jlink should create the jimage file in the native endian for the target platform [v5] In-Reply-To: References: Message-ID: On Mon, 13 Mar 2023 14:59:13 GMT, Jaikiran Pai wrote: > So that would then mean updating the build file where we create these jmod file(s) to use a value for `--target-platform` that even includes the endianness in the string value, example: `aix-ppc64-big` and `macos-aarch64-little`. So a change here https://github.com/openjdk/jdk/blob/master/make/CreateJmods.gmk#L252. Did I understand it correctly? No, I meant a simple mapping of the current ModuleTarget values to endianness. Maybe some day we'll extend tor replace the ModuleTarget attribute to include information on endian, hard vs. soft float, and other arch details. Not for this PR. ------------- PR: https://git.openjdk.org/jdk/pull/11943 From rriggs at openjdk.org Mon Mar 13 15:10:31 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 13 Mar 2023 15:10:31 GMT Subject: RFR: 8303814: getLastErrorString should avoid charset conversions [v2] In-Reply-To: References: Message-ID: <88rPs699hRVHL_w1dIfbGgp5fhsoP9a4aTXqtuXZD8g=.1a441cba-0807-4de1-9174-92e2eeff3dad@github.com> On Mon, 13 Mar 2023 09:48:19 GMT, Daniel Jeli?ski wrote: >> This patch modifies the `getLastErrorString` method to return a `jstring`. Thanks to that we can avoid unnecessary back and forth conversions between Unicode and other charsets on Windows. >> >> Other changes include: >> - the Windows implementation of `getLastErrorString` no longer checks `errno`. I verified all uses of the method and confirmed that `errno` is not used anywhere. >> - While at it, I found and fixed a few calls to `JNU_ThrowIOExceptionWithLastError` that were done in context where `LastError` was not set. >> - jdk.hotspot.agent was modified to use `JNU_ThrowByNameWithLastError` and `JNU_ThrowByName` instead of `getLastErrorString`; the code is expected to have identical behavior. >> - zip_util was modified to return static messages instead of generated ones. The generated messages were not observed anywhere, because they were replaced by a static message in ZIP_Open, which is the only method used by other native code. >> - `getLastErrorString` is no longer exported by libjava. >> >> Tier1-3 tests continue to pass. >> >> No new automated regression test; testing this requires installing a language pack that cannot be displayed in the current code page. >> Tested this manually by installing Chinese language pack on English Windows 11, selecting Chinese language, then checking if the message on exception thrown by `InetAddress.getByName("nonexistent.local");` starts with `"?????????"` (or `"\u4e0d\u77e5\u9053\u8fd9\u6837\u7684\u4e3b\u673a\u3002"`). Without the change, the exception message started with a row of question marks. > > Daniel Jeli?ski has updated the pull request incrementally with three additional commits since the last revision: > > - Address review comments > - Mention that the returned text is static and thread safe > - Define buffer size LGTM for some pre-existing code style inconsistencies. src/java.base/share/native/libzip/zip_util.c line 812: > 810: > 811: if (strlen(name) >= PATH_MAX) { > 812: if (pmsg) { Some pre-existing references to pmsg still use implicit comparison, though not material to this PR, can you update them to compare with NULL. ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.org/jdk/pull/12922 From jpai at openjdk.org Mon Mar 13 15:27:30 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 13 Mar 2023 15:27:30 GMT Subject: RFR: 8304006: jlink should create the jimage file in the native endian for the target platform [v6] In-Reply-To: References: Message-ID: <9Keoe8e-r28Wvm7m3efgyq4k3fM6cs2mfA3be59DA28=.3b086c7d-5a36-4b34-a63c-721c12571df0@github.com> > Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8206890? > > The `jlink` command allows a `--endian` option to specify the byte order in the generated image. Before this change, when such a image was being launched, the code would assume the byte order in the image to be the native order of the host where the image is being launched. That would result in failure to launch java, as noted in the linked issue. > > The commit in this PR, changes relevant places to not assume native order and instead determine the byte order by reading the magic bytes in the image file's header content. > > A new jtreg test has been added which reproduces the issue and verifies the fix. Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: no need for security manager checks in jlink ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11943/files - new: https://git.openjdk.org/jdk/pull/11943/files/bad17122..0888ca11 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11943&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11943&range=04-05 Stats: 16 lines in 1 file changed: 0 ins; 12 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/11943.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11943/head:pull/11943 PR: https://git.openjdk.org/jdk/pull/11943 From alanb at openjdk.org Mon Mar 13 15:34:04 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 13 Mar 2023 15:34:04 GMT Subject: RFR: 8304006: jlink should create the jimage file in the native endian for the target platform [v6] In-Reply-To: <9Keoe8e-r28Wvm7m3efgyq4k3fM6cs2mfA3be59DA28=.3b086c7d-5a36-4b34-a63c-721c12571df0@github.com> References: <9Keoe8e-r28Wvm7m3efgyq4k3fM6cs2mfA3be59DA28=.3b086c7d-5a36-4b34-a63c-721c12571df0@github.com> Message-ID: On Mon, 13 Mar 2023 15:27:30 GMT, Jaikiran Pai wrote: >> Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8206890? >> >> The `jlink` command allows a `--endian` option to specify the byte order in the generated image. Before this change, when such a image was being launched, the code would assume the byte order in the image to be the native order of the host where the image is being launched. That would result in failure to launch java, as noted in the linked issue. >> >> The commit in this PR, changes relevant places to not assume native order and instead determine the byte order by reading the magic bytes in the image file's header content. >> >> A new jtreg test has been added which reproduces the issue and verifies the fix. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > no need for security manager checks in jlink src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 889: > 887: // the "java.base" module file used to create the image > 888: return Files.isSameFile(javaBasePath, > 889: currentPlatformJmods.resolve(Path.of("java.base.jmod"))); You can reduce this to resolve("java.base.jmod"). ------------- PR: https://git.openjdk.org/jdk/pull/11943 From jpai at openjdk.org Mon Mar 13 15:34:08 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 13 Mar 2023 15:34:08 GMT Subject: RFR: 8304006: jlink should create the jimage file in the native endian for the target platform [v5] In-Reply-To: References: Message-ID: On Mon, 13 Mar 2023 14:42:26 GMT, Alan Bateman wrote: > jlink doesn't run with a security manager so no need for the AccessController.doPriv. Thank you for that detail - I've now removed the SecurityManager checks from this newly introduced code. > Assuming the name of the jmod file is probably okay. Were you thinking of exploded builds? I'm not too familiar with exploded builds, but after you commented here about the `.jmod` extension, I checked the existing code in `JLinkTask` and I can see that we seem to allow the module to be packaged as a `.jar` too, like here https://github.com/openjdk/jdk/blob/master/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java#L834. Do you think this cross platform image creation would be relevant/used with exploded builds and if so, should I update the PR to address it? ------------- PR: https://git.openjdk.org/jdk/pull/11943 From jpai at openjdk.org Mon Mar 13 15:39:11 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 13 Mar 2023 15:39:11 GMT Subject: RFR: 8304006: jlink should create the jimage file in the native endian for the target platform [v5] In-Reply-To: References: Message-ID: On Mon, 13 Mar 2023 15:28:49 GMT, Jaikiran Pai wrote: > Do you think this cross platform image creation would be relevant/used with exploded builds and if so, should I update the PR to address it? Actually, now that I think about it, this `isJavaBaseFromCurrentPlatform()` method will get executed even for regular (same platform) image generation. Which means if the `java.base` module file doesn't end in a `.jmod` extension then this part of the code can run into `java.nio.file.NoSuchFileException` . I will generate an exploded build and see if anything needs to be done. ------------- PR: https://git.openjdk.org/jdk/pull/11943 From alanb at openjdk.org Mon Mar 13 15:54:57 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 13 Mar 2023 15:54:57 GMT Subject: RFR: 8304006: jlink should create the jimage file in the native endian for the target platform [v5] In-Reply-To: References: Message-ID: On Mon, 13 Mar 2023 15:34:51 GMT, Jaikiran Pai wrote: >>> jlink doesn't run with a security manager so no need for the AccessController.doPriv. >> >> Thank you for that detail - I've now removed the SecurityManager checks from this newly introduced code. >> >>> Assuming the name of the jmod file is probably okay. >> >> Were you thinking of exploded builds? I'm not too familiar with exploded builds, but after you commented here about the `.jmod` extension, I checked the existing code in `JLinkTask` and I can see that we seem to allow the module to be packaged as a `.jar` too, like here https://github.com/openjdk/jdk/blob/master/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java#L834. Do you think this cross platform image creation would be relevant/used with exploded builds and if so, should I update the PR to address it? > >> Do you think this cross platform image creation would be relevant/used with exploded builds and if so, should I update the PR to address it? > > Actually, now that I think about it, this `isJavaBaseFromCurrentPlatform()` method will get executed even for regular (same platform) image generation. Which means if the `java.base` module file doesn't end in a `.jmod` extension then this part of the code can run into `java.nio.file.NoSuchFileException` . I will generate an exploded build and see if anything needs to be done. > Were you thinking of exploded builds? No, the exploded builds don't have the packages modules so you should get an error like this: Error: --module-path is not specified and this runtime image does not contain jmods directory. ------------- PR: https://git.openjdk.org/jdk/pull/11943 From djelinski at openjdk.org Mon Mar 13 15:55:27 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 13 Mar 2023 15:55:27 GMT Subject: RFR: 8303814: getLastErrorString should avoid charset conversions [v3] In-Reply-To: References: Message-ID: > This patch modifies the `getLastErrorString` method to return a `jstring`. Thanks to that we can avoid unnecessary back and forth conversions between Unicode and other charsets on Windows. > > Other changes include: > - the Windows implementation of `getLastErrorString` no longer checks `errno`. I verified all uses of the method and confirmed that `errno` is not used anywhere. > - While at it, I found and fixed a few calls to `JNU_ThrowIOExceptionWithLastError` that were done in context where `LastError` was not set. > - jdk.hotspot.agent was modified to use `JNU_ThrowByNameWithLastError` and `JNU_ThrowByName` instead of `getLastErrorString`; the code is expected to have identical behavior. > - zip_util was modified to return static messages instead of generated ones. The generated messages were not observed anywhere, because they were replaced by a static message in ZIP_Open, which is the only method used by other native code. > - `getLastErrorString` is no longer exported by libjava. > > Tier1-3 tests continue to pass. > > No new automated regression test; testing this requires installing a language pack that cannot be displayed in the current code page. > Tested this manually by installing Chinese language pack on English Windows 11, selecting Chinese language, then checking if the message on exception thrown by `InetAddress.getByName("nonexistent.local");` starts with `"?????????"` (or `"\u4e0d\u77e5\u9053\u8fd9\u6837\u7684\u4e3b\u673a\u3002"`). Without the change, the exception message started with a row of question marks. Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: Use NULL where appropriate ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12922/files - new: https://git.openjdk.org/jdk/pull/12922/files/ea91b651..efd72a1d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12922&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12922&range=01-02 Stats: 12 lines in 1 file changed: 0 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/12922.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12922/head:pull/12922 PR: https://git.openjdk.org/jdk/pull/12922 From asotona at openjdk.org Mon Mar 13 15:56:36 2023 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 13 Mar 2023 15:56:36 GMT Subject: Integrated: 8294974: Convert jdk.jshell/jdk.jshell.execution.LocalExecutionControl to use the Classfile API to instrument classes In-Reply-To: References: Message-ID: On Tue, 29 Nov 2022 12:27:15 GMT, Adam Sotona wrote: > 8294974: jdk.jshell jdk.jshell.execution.LocalExecutionControl uses ASM to instrument classes > This patch converts it to use Classfile API. > > Please review. > Thanks, > Adam This pull request has now been integrated. Changeset: a95bc7ac Author: Adam Sotona URL: https://git.openjdk.org/jdk/commit/a95bc7acd091b287af02485434e1e55ba1e0369d Stats: 55 lines in 3 files changed: 11 ins; 21 del; 23 mod 8294974: Convert jdk.jshell/jdk.jshell.execution.LocalExecutionControl to use the Classfile API to instrument classes Reviewed-by: jlahoda ------------- PR: https://git.openjdk.org/jdk/pull/11413 From djelinski at openjdk.org Mon Mar 13 16:01:05 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 13 Mar 2023 16:01:05 GMT Subject: RFR: 8303814: getLastErrorString should avoid charset conversions [v2] In-Reply-To: <88rPs699hRVHL_w1dIfbGgp5fhsoP9a4aTXqtuXZD8g=.1a441cba-0807-4de1-9174-92e2eeff3dad@github.com> References: <88rPs699hRVHL_w1dIfbGgp5fhsoP9a4aTXqtuXZD8g=.1a441cba-0807-4de1-9174-92e2eeff3dad@github.com> Message-ID: On Mon, 13 Mar 2023 15:05:04 GMT, Roger Riggs wrote: >> Daniel Jeli?ski has updated the pull request incrementally with three additional commits since the last revision: >> >> - Address review comments >> - Mention that the returned text is static and thread safe >> - Define buffer size > > src/java.base/share/native/libzip/zip_util.c line 812: > >> 810: >> 811: if (strlen(name) >= PATH_MAX) { >> 812: if (pmsg) { > > Some pre-existing references to pmsg still use implicit comparison, though not material to this PR, can you update them to compare with NULL. done. ------------- PR: https://git.openjdk.org/jdk/pull/12922 From jpai at openjdk.org Mon Mar 13 16:01:23 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 13 Mar 2023 16:01:23 GMT Subject: RFR: 8304006: jlink should create the jimage file in the native endian for the target platform [v6] In-Reply-To: References: <9Keoe8e-r28Wvm7m3efgyq4k3fM6cs2mfA3be59DA28=.3b086c7d-5a36-4b34-a63c-721c12571df0@github.com> Message-ID: On Mon, 13 Mar 2023 15:30:59 GMT, Alan Bateman wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> no need for security manager checks in jlink > > src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 889: > >> 887: // the "java.base" module file used to create the image >> 888: return Files.isSameFile(javaBasePath, >> 889: currentPlatformJmods.resolve(Path.of("java.base.jmod"))); > > You can reduce this to resolve("java.base.jmod"). Done ------------- PR: https://git.openjdk.org/jdk/pull/11943 From jpai at openjdk.org Mon Mar 13 16:01:20 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 13 Mar 2023 16:01:20 GMT Subject: RFR: 8304006: jlink should create the jimage file in the native endian for the target platform [v7] 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.org/browse/JDK-8206890? > > The `jlink` command allows a `--endian` option to specify the byte order in the generated image. Before this change, when such a image was being launched, the code would assume the byte order in the image to be the native order of the host where the image is being launched. That would result in failure to launch java, as noted in the linked issue. > > The commit in this PR, changes relevant places to not assume native order and instead determine the byte order by reading the magic bytes in the image file's header content. > > A new jtreg test has been added which reproduces the issue and verifies the fix. Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: Path.resolve(String) instead of Path.resolve(Path) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11943/files - new: https://git.openjdk.org/jdk/pull/11943/files/0888ca11..d64969a8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11943&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11943&range=05-06 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11943.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11943/head:pull/11943 PR: https://git.openjdk.org/jdk/pull/11943 From duke at openjdk.org Mon Mar 13 16:03:24 2023 From: duke at openjdk.org (liach) Date: Mon, 13 Mar 2023 16:03:24 GMT Subject: RFR: 8304031: Classfile API cannot encode Primitive Class as Condy In-Reply-To: <6SEB6ZAh2b0ayMCo5EfvOW-adtsAysbf1Zk6qBbh2SI=.96417080-f2a8-424d-9a26-0ed68f6b33ac@github.com> References: <6SEB6ZAh2b0ayMCo5EfvOW-adtsAysbf1Zk6qBbh2SI=.96417080-f2a8-424d-9a26-0ed68f6b33ac@github.com> Message-ID: On Mon, 13 Mar 2023 08:13:44 GMT, liach wrote: > Without this patch, the Classfile API tries to encode PrimitiveClassDesc as CONSTANT_Class_info and error in `toInternalName`. @asotona Would you mind review this? ------------- PR: https://git.openjdk.org/jdk/pull/12996 From jpai at openjdk.org Mon Mar 13 16:22:30 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 13 Mar 2023 16:22:30 GMT Subject: RFR: 8304006: jlink should create the jimage file in the native endian for the target platform [v8] 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.org/browse/JDK-8206890? > > The `jlink` command allows a `--endian` option to specify the byte order in the generated image. Before this change, when such a image was being launched, the code would assume the byte order in the image to be the native order of the host where the image is being launched. That would result in failure to launch java, as noted in the linked issue. > > The commit in this PR, changes relevant places to not assume native order and instead determine the byte order by reading the magic bytes in the image file's header content. > > A new jtreg test has been added which reproduces the issue and verifies the fix. Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: don't hardcode the .jmod extension while determining java.base module location ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11943/files - new: https://git.openjdk.org/jdk/pull/11943/files/d64969a8..da590e9d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11943&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11943&range=06-07 Stats: 9 lines in 1 file changed: 6 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/11943.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11943/head:pull/11943 PR: https://git.openjdk.org/jdk/pull/11943 From jpai at openjdk.org Mon Mar 13 16:22:31 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 13 Mar 2023 16:22:31 GMT Subject: RFR: 8304006: jlink should create the jimage file in the native endian for the target platform [v5] In-Reply-To: References: Message-ID: <1yomfjgQYAPw2aDq8w-g0iu_f_7DYwbouCCE24tHeHM=.85b4e86f-4282-4f41-a10a-9ed5ca106ddd@github.com> On Mon, 13 Mar 2023 15:51:46 GMT, Alan Bateman wrote: >>> Do you think this cross platform image creation would be relevant/used with exploded builds and if so, should I update the PR to address it? >> >> Actually, now that I think about it, this `isJavaBaseFromCurrentPlatform()` method will get executed even for regular (same platform) image generation. Which means if the `java.base` module file doesn't end in a `.jmod` extension then this part of the code can run into `java.nio.file.NoSuchFileException` . I will generate an exploded build and see if anything needs to be done. > >> Were you thinking of exploded builds? > > No, the exploded builds don't have the packaged modules so you should get an error like this: > > Error: --module-path is not specified and this runtime image does not contain jmods directory. I decided to remove the use of hardcoded `.jmod` extension while checking the paths. I have updated the PR to use a slightly different technique which doesn't require using hardcode file names for determining if this a cross-platform image generation. Manual testing shows that this change continues to work fine when identifying cross-platform image generation. Existing automated tests too pass fine for same platform image generation. ------------- PR: https://git.openjdk.org/jdk/pull/11943 From mdoerr at openjdk.org Mon Mar 13 16:23:21 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 13 Mar 2023 16:23:21 GMT Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function & Memory API (Preview) [v3] In-Reply-To: References: <8b3vVrV22RuhdRoRYacXV0ZeghFGgKkC8S_z-iMrzAQ=.dd84b743-8b51-4281-8f5f-f9eff6207bc7@github.com> Message-ID: On Sat, 11 Mar 2023 02:20:31 GMT, Jorn Vernee wrote: >> @JornVernee: Thanks! I've merged in your changes. TestArrayStructs is not yet completely working. I will need to investigate. I think I've done most other things you had requested. You may want to take a look at my recent commits. > > @TheRealMDoerr I've been keeping up with the changes you're making. I just have to look at the new test for HFA's you've added you added (next week). > > Besides fixing the TestArrayStructs test, do you have anything else you still want to add to this PR? @JornVernee: I guess I should add a couple of Upcalls to my new test. Otherwise, I have only planned to fix `TestArrayStructs`. Further changes (and maybe new tests) can still get done when working on Big Endian / AIX or when there is a demand. I'm currently wondering about the `TestArrayStructs` failures. Passing arrays with up to 7 elements seems to work fine. When I pass 8 elements, the last element of `capturedArgs` gets observed as 0. When I pass more than 8 elements, element 5 and 6 of `capturedArgs` get observed as 0. `DowncallLinker.invokeInterpBindings` has the correct `args`, but `UpcallLinker.invokeInterpBindings` doesn't receive the correct values as `lowLevelArgs`. They contain the wrong zeros. The remaining elements look correct. Do you have an idea what could be going wrong? Otherwise, I'll have to continue debugging. ------------- PR: https://git.openjdk.org/jdk/pull/12708 From asotona at openjdk.org Mon Mar 13 16:37:14 2023 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 13 Mar 2023 16:37:14 GMT Subject: RFR: 8294972: Convert jdk.jlink internal plugins to use the Classfile API [v5] In-Reply-To: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> Message-ID: <1Hvz-uSoqcz-UZ-flssiFVDxOOzp9mmwrqvj0B7i0Q0=.cb03e884-e33b-463f-bfa6-8edbda7668c5@github.com> > jdk.jlink internal plugins are heavily using ASM > > This patch converts ASM calls to Classfile API. > > Please review. > Thanks, > Adam Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 209 commits: - Merge branch 'master' into JDK-8294972-jlink-plugins # Conflicts: # src/java.base/share/classes/module-info.java - Merge branch 'master' into JDK-8294972-jlink-plugins # Conflicts: # src/java.base/share/classes/module-info.java - Merge branch 'master' into JDK-8294972-jlink-plugins - fixed SystemModulesPlugin formatting - 8303624: The java.lang.Thread.FieldHolder can be null for JNI attaching threads Reviewed-by: alanb, dcubed - 8302360: Atomic*.compareAndExchange Javadoc unclear Reviewed-by: martin, dholmes - 8302779: HelidonAppTest.java fails with "assert(_cb == CodeCache::find_blob(pc())) failed: Must be the same" or SIGSEGV Reviewed-by: coleenp, sspitsyn - 8303691: Fedora based devkit build should load more packages from archive location Reviewed-by: mbaesken, erikj - 8303924: ProblemList serviceability/sa/UniqueVtableTest.java on Linux Reviewed-by: dcubed - 8303609: ProblemList serviceability/sa/TestSysProps.java with ZGC Reviewed-by: dcubed - ... and 199 more: https://git.openjdk.org/jdk/compare/a95bc7ac...5042a093 ------------- Changes: https://git.openjdk.org/jdk/pull/12944/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12944&range=04 Stats: 1026 lines in 6 files changed: 210 ins; 302 del; 514 mod Patch: https://git.openjdk.org/jdk/pull/12944.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12944/head:pull/12944 PR: https://git.openjdk.org/jdk/pull/12944 From jvernee at openjdk.org Mon Mar 13 16:40:18 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 13 Mar 2023 16:40:18 GMT Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function & Memory API (Preview) [v3] In-Reply-To: References: <8b3vVrV22RuhdRoRYacXV0ZeghFGgKkC8S_z-iMrzAQ=.dd84b743-8b51-4281-8f5f-f9eff6207bc7@github.com> Message-ID: <1OXigMWnfCHCkxCI3D29NpgIpgG36Ltlnry1eytOPow=.5f423637-0a12-454e-a31c-57b2fc11123f@github.com> On Mon, 13 Mar 2023 16:20:22 GMT, Martin Doerr wrote: > I guess I should add a couple of Upcalls to my new test. Otherwise, I have only planned to fix TestArrayStructs. Further changes (and maybe new tests) can still get done when working on Big Endian / AIX or when there is a demand. Okay. The reason I ask is because we are looking to get started with the JEP PR, but it might be nice to wrap up this PR first, to avoid any merge conflicts. I also have https://github.com/openjdk/jdk/pull/12883 which would need changes to the PPC call arranger/linker as well (though, it's a pretty simple refactor). I'm trying to figure out what the best order to do things in is. > I'm currently wondering about the TestArrayStructs failures. Passing arrays with up to 7 elements seems to work fine. When I pass 8 elements, the last element of capturedArgs gets observed as 0. When I pass more than 8 elements, element 5 and 6 of capturedArgs get observed as 0. DowncallLinker.invokeInterpBindings has the correct args, but UpcallLinker.invokeInterpBindings doesn't receive the correct values as lowLevelArgs. They contain the wrong zeros. The remaining elements look correct. Do you have an idea what could be going wrong? Otherwise, I'll have to continue debugging. This sounds like there might be a mismatch between the Java and native side. I suggest looking at the assembly generated for the native function for the failing case, and seeing if it matches what is generated by CallArranger. Here is also where adding a CallArranger test can be useful (in test/jdk/java/foreign/callarranger), to test whether the resulting bindings match your expectation for that function descriptor. Also, you might want to check the layout the native compiler uses for the particular struct, and verify that it matches the Java side. (i.e. there's no weird padding or something, it's just a struct of 8 bytes). ------------- PR: https://git.openjdk.org/jdk/pull/12708 From naoto at openjdk.org Mon Mar 13 16:47:52 2023 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 13 Mar 2023 16:47:52 GMT Subject: RFR: 8303814: getLastErrorString should avoid charset conversions [v3] In-Reply-To: References: Message-ID: On Mon, 13 Mar 2023 15:55:27 GMT, Daniel Jeli?ski wrote: >> This patch modifies the `getLastErrorString` method to return a `jstring`. Thanks to that we can avoid unnecessary back and forth conversions between Unicode and other charsets on Windows. >> >> Other changes include: >> - the Windows implementation of `getLastErrorString` no longer checks `errno`. I verified all uses of the method and confirmed that `errno` is not used anywhere. >> - While at it, I found and fixed a few calls to `JNU_ThrowIOExceptionWithLastError` that were done in context where `LastError` was not set. >> - jdk.hotspot.agent was modified to use `JNU_ThrowByNameWithLastError` and `JNU_ThrowByName` instead of `getLastErrorString`; the code is expected to have identical behavior. >> - zip_util was modified to return static messages instead of generated ones. The generated messages were not observed anywhere, because they were replaced by a static message in ZIP_Open, which is the only method used by other native code. >> - `getLastErrorString` is no longer exported by libjava. >> >> Tier1-3 tests continue to pass. >> >> No new automated regression test; testing this requires installing a language pack that cannot be displayed in the current code page. >> Tested this manually by installing Chinese language pack on English Windows 11, selecting Chinese language, then checking if the message on exception thrown by `InetAddress.getByName("nonexistent.local");` starts with `"?????????"` (or `"\u4e0d\u77e5\u9053\u8fd9\u6837\u7684\u4e3b\u673a\u3002"`). Without the change, the exception message started with a row of question marks. > > Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: > > Use NULL where appropriate Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12922 From jvernee at openjdk.org Mon Mar 13 16:57:43 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 13 Mar 2023 16:57:43 GMT Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function & Memory API (Preview) [v14] In-Reply-To: References: Message-ID: On Thu, 9 Mar 2023 17:29:37 GMT, Martin Doerr wrote: >> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification". >> >> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `` (2.2.4 Variable Argument Lists). >> >> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only. >> >> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Will get addressed separately: [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017) >> >> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests. >> >> I had to make changes to shared code and code for other platforms: >> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons: >> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that. >> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64. >> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian! >> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit. > > Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: > > Introduce ABIv2CallArranger for linux ppc64le. test/jdk/java/foreign/TestHFA.java line 32: > 30: * @enablePreview > 31: * @requires ((os.arch == "amd64" | os.arch == "x86_64") & sun.arch.data.model == "64") | os.arch == "aarch64" | os.arch == "ppc64le" | os.arch == "riscv64" > 32: * @requires !vm.musl Not sure if this test should be disabled on musl? ------------- PR: https://git.openjdk.org/jdk/pull/12708 From jlu at openjdk.org Mon Mar 13 16:58:09 2023 From: jlu at openjdk.org (Justin Lu) Date: Mon, 13 Mar 2023 16:58:09 GMT Subject: RFR: 8303917: Update ISO 639 language codes table [v2] In-Reply-To: References: Message-ID: > This PR modifies `java.util.LocaleISOData.isoLanguageTable` to include (name only) changes from up-to-date [ISO 639 data](http://www.loc.gov/standards/iso639-2/php/code_list.php.). > > In addition, this PR updates the ISO 639 data (generated in 1999) in `Bug4175998Test.java`. This includes modifying the `generate_Tables() `function, since the source data is now stored in a different format. The outdated raw data stored in the bottom of the file was removed. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: Simplfy print statements ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12980/files - new: https://git.openjdk.org/jdk/pull/12980/files/5000c261..a43f9f4e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12980&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12980&range=00-01 Stats: 5 lines in 1 file changed: 0 ins; 2 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/12980.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12980/head:pull/12980 PR: https://git.openjdk.org/jdk/pull/12980 From jvernee at openjdk.org Mon Mar 13 16:59:59 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 13 Mar 2023 16:59:59 GMT Subject: RFR: 8303022: "assert(allocates2(pc)) failed: not in CodeBuffer memory" When linking downcall handle [v3] In-Reply-To: References: Message-ID: On Sat, 11 Mar 2023 00:15:10 GMT, Vladimir Kozlov wrote: >> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: >> >> RISCV changes > > Good. @vnkozlov Does this need another reviewer? ------------- PR: https://git.openjdk.org/jdk/pull/12908 From asotona at openjdk.org Mon Mar 13 17:18:00 2023 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 13 Mar 2023 17:18:00 GMT Subject: RFR: 8294962: Convert java.base/jdk.internal.module package to use the Classfile API to modify and write module-info.class [v4] In-Reply-To: References: <6ElqezMc7McFhcHQsB0oTaoSII7RJ569icRg-mT4-3g=.6d902eed-42d0-4578-ba6b-aebc20856dc1@github.com> Message-ID: On Mon, 13 Mar 2023 14:18:55 GMT, Alan Bateman wrote: >> Or another approach for the specific use cases might be to use `Classfile::buildModule` with empty list of packages and then provide custom `ModulePackagesAttribute` to the handler directly. > >> `Classfile::buildModule` is a helper method simplifying the major use case - building valid module with minimal user effort and knowledge. It emits `ModulePackages` if there are any packages specified and not exported nor opened. That is the configuration which JVM expects and majority of users are not aware of. > > ModulePackages is a performance optimization. When present, the value is the set of packages in the module. If not present, the module contents need to be scanned to discover the set of packages. I think it's just a bit too surprising for Classfile::buildModule to emit the ModulePackages attribute sometimes and not others. I think it would be better to change is so that calling it with ModuleAttribute will emit a Module attribute. The overloads that take a Module plus a set of packages can emit a Module + ModulePackage unconditionally. I see, I'll move the "packages magic" back from Classfile API to the `ModuleInfoWriter` and correct the API accordingly. ------------- PR: https://git.openjdk.org/jdk/pull/11368 From joehw at openjdk.org Mon Mar 13 18:02:21 2023 From: joehw at openjdk.org (Joe Wang) Date: Mon, 13 Mar 2023 18:02:21 GMT Subject: RFR: 8303530: Add system property for custom JAXP configuration file [v2] In-Reply-To: References: Message-ID: <6vWKfDJwZMPh3KI3FXPiQ_dvDQs90Jm4Vaev9leWxl0=.ce3ebc52-a413-4bd2-8cca-cffd63d1e3fa@github.com> On Mon, 13 Mar 2023 09:58:51 GMT, Alan Bateman wrote: >> Joe Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> clean up tests; fix copy&paste error. > > src/java.xml/share/classes/javax/xml/XMLConstants.java line 247: > >> 245: * configuration file. >> 246: * If the file exists and the system property is specified, its value will >> 247: * be used to override the default of the property. > > This follows the documenting of the equivalent system property but that text doesn't say what it overrides. I think it overrides the default value but does not override programmatic use. The new text documents that the configuration file can be used. It is a bit clearer that it overrides the default value but doesn't say anything about programmatic use. The reader will also wonder if the system property overrides the configuration file or the other way around. So I think my point is that the precedent needs to clearly documented, maybe it document the ordering in one place and have each property reference it. In the case of XMLConstants, then it might also be simpler to put the text in the class description rather than having it repeated in every property - maybe experiment with that to see if it helps or not. > > In passing, I assume these links can be use `{@docRoot}/java.xml/module-summary.html`. I'll rewrite the "configuration file" section in the module description to include a general override procedure to discuss "scope and order" and have these properties point to that. Thanks for the pointer, that link to the module-summary looks cleaner. ------------- PR: https://git.openjdk.org/jdk/pull/12985 From joehw at openjdk.org Mon Mar 13 18:05:28 2023 From: joehw at openjdk.org (Joe Wang) Date: Mon, 13 Mar 2023 18:05:28 GMT Subject: RFR: 8303530: Add system property for custom JAXP configuration file [v2] In-Reply-To: References: Message-ID: On Mon, 13 Mar 2023 10:01:21 GMT, Alan Bateman wrote: >> Joe Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> clean up tests; fix copy&paste error. > > src/java.xml/share/classes/javax/xml/catalog/CatalogFeatures.java line 171: > >> 169: * system properties, and >> 170: * configuration file, >> 171: * with a preference in the same order. > > You may need to clarify the preference order a bit further, is is left-to-right or right-to-left in this list? The order was described in the Scope and Order section below the table. The columns here are definitions. I'll see if I can make it clearer, along with what to be added to the module summary. ------------- PR: https://git.openjdk.org/jdk/pull/12985 From kvn at openjdk.org Mon Mar 13 18:05:28 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 13 Mar 2023 18:05:28 GMT Subject: RFR: 8303022: "assert(allocates2(pc)) failed: not in CodeBuffer memory" When linking downcall handle [v3] In-Reply-To: References: Message-ID: On Sat, 11 Mar 2023 00:15:10 GMT, Vladimir Kozlov wrote: >> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: >> >> RISCV changes > > Good. > @vnkozlov Does this need another reviewer? Yes, it is not trivial ------------- PR: https://git.openjdk.org/jdk/pull/12908 From joehw at openjdk.org Mon Mar 13 18:12:46 2023 From: joehw at openjdk.org (Joe Wang) Date: Mon, 13 Mar 2023 18:12:46 GMT Subject: RFR: 8303530: Add system property for custom JAXP configuration file [v2] In-Reply-To: References: Message-ID: On Mon, 13 Mar 2023 10:03:52 GMT, Alan Bateman wrote: >> Joe Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> clean up tests; fix copy&paste error. > > src/java.xml/share/classes/javax/xml/catalog/CatalogFeatures.java line 183: > >> 181: * configuration file. >> 182: * In case of multiple interfaces, the latest in a procedure shall take preference. >> 183: * For {@link Feature#FILES}, this means that the URI(s) specified through the methods > > "multiple interfaces" and "the latest in a procedure" aren't very clear here. If the setup for this section documents the precedence order more clearly then it will make it easier to word this section. We have two options here: - drop the discussion about "multiple interfaces", and leave it to the CatalogManager to make it clear; - add some sample code While we'll be adding a general Scope and Order, this is specific to the Catalog API. I'll try option 1. ------------- PR: https://git.openjdk.org/jdk/pull/12985 From joehw at openjdk.org Mon Mar 13 18:25:00 2023 From: joehw at openjdk.org (Joe Wang) Date: Mon, 13 Mar 2023 18:25:00 GMT Subject: RFR: 8303530: Add system property for custom JAXP configuration file [v2] In-Reply-To: References: Message-ID: On Mon, 13 Mar 2023 11:28:15 GMT, Alan Bateman wrote: >> Joe Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> clean up tests; fix copy&paste error. > > src/java.xml/share/classes/javax/xml/stream/XMLEventFactory.java line 139: > >> 137: * Use the value of the property {@code factoryId} set in the >> 138: * configuration file, >> 139: * stax.properties or jaxp.properties by default. If the file exists and > > Is it time to drop all references to stax.properties from the API docs? Will drop it. > src/java.xml/share/classes/module-info.java line 31: > >> 29: * >> 30: *

Configuration File

>> 31: * The java.xml (JAXP) Configuration File is used for configuring factories in the > > The first sentence of the module description defines "JAXP" as the abbreviation for "Java API for XML Processing" so the usage looks a bit strange. Maybe the introduction to this section should say that the XML processing APIs in this module allow a configuration file the XML processors. Sounds good, will update that. I was trying to assign the configuration file a unique name so that it can be referenced clearly. ------------- PR: https://git.openjdk.org/jdk/pull/12985 From joehw at openjdk.org Mon Mar 13 18:28:10 2023 From: joehw at openjdk.org (Joe Wang) Date: Mon, 13 Mar 2023 18:28:10 GMT Subject: RFR: 8303530: Add system property for custom JAXP configuration file [v2] In-Reply-To: References: Message-ID: On Mon, 13 Mar 2023 11:34:50 GMT, Alan Bateman wrote: >> Joe Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> clean up tests; fix copy&paste error. > > src/java.xml/share/classes/module-info.java line 89: > >> 87: * the StAX factories for the Factory Lookup Mechanism >> 88: * only. The files, if exist, are typically located in the {@code conf} >> 89: * directory of the Java installation. > > If jdk.xml.config.file is not set, should the reader assume it's default value is ${java.home}/conf/jaxp.properties? If so, they this is an implementation specific default, right? Both API and Impl, will make it clearer, and add a section under the implNote section. ------------- PR: https://git.openjdk.org/jdk/pull/12985 From alanb at openjdk.org Mon Mar 13 18:49:47 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 13 Mar 2023 18:49:47 GMT Subject: RFR: 8294962: Convert java.base/jdk.internal.module package to use the Classfile API to modify and write module-info.class [v4] In-Reply-To: References: <6ElqezMc7McFhcHQsB0oTaoSII7RJ569icRg-mT4-3g=.6d902eed-42d0-4578-ba6b-aebc20856dc1@github.com> Message-ID: On Mon, 13 Mar 2023 17:15:21 GMT, Adam Sotona wrote: > I see, I'll move the "packages magic" back from Classfile API to the `ModuleInfoWriter` and correct the API accordingly. I would need to check the history in the jake repo but I think it dates from a prototype version of that attribute that only listed the concealed packages. I think it should be okay to just drop this from ModuleInfoWriter now. As I mentioned in another comment, the only user now is tests so you should able to just remove this code so that it doesn't generate the ModulePackages attributes. ------------- PR: https://git.openjdk.org/jdk/pull/11368 From asotona at openjdk.org Mon Mar 13 19:01:30 2023 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 13 Mar 2023 19:01:30 GMT Subject: RFR: 8303910: jdk/classfile/CorpusTest.java failed 1 of 6754 tests Message-ID: jdk/classfile/CorpusTest.java rarely fails in 1 of 6754 parametrised parallel junit tests The root cause seems to be thread-unsafe lazy initialisation of `TypeKind.newarraycodeToTypeTag` in `TypeKind::fromNewArrayCode`. Provided patch replaces that lazy-initialized helper array with switch expression. Please review. Thanks, Adam ------------- Commit messages: - 8303910: jdk/classfile/CorpusTest.java failed 1 of 6754 tests Changes: https://git.openjdk.org/jdk/pull/13004/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13004&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303910 Stats: 13 lines in 1 file changed: 4 ins; 2 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/13004.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13004/head:pull/13004 PR: https://git.openjdk.org/jdk/pull/13004 From duke at openjdk.org Mon Mar 13 19:08:15 2023 From: duke at openjdk.org (liach) Date: Mon, 13 Mar 2023 19:08:15 GMT Subject: RFR: 8303910: jdk/classfile/CorpusTest.java failed 1 of 6754 tests In-Reply-To: References: Message-ID: <7pb62rwmAgzId6p0H6RBF7Uhk0KM6e6sdVlTkvXnQcc=.ae4398d4-04fd-401f-9fc6-e42edc86747b@github.com> On Mon, 13 Mar 2023 18:54:11 GMT, Adam Sotona wrote: > jdk/classfile/CorpusTest.java rarely fails in 1 of 6754 parametrised parallel junit tests > > The root cause seems to be thread-unsafe lazy initialisation of `TypeKind.newarraycodeToTypeTag` in `TypeKind::fromNewArrayCode`. Provided patch replaces that lazy-initialized helper array with switch expression. > > Please review. > > Thanks, > Adam src/java.base/share/classes/jdk/internal/classfile/TypeKind.java line 112: > 110: case 10 -> TypeKind.IntType; > 111: case 11 -> TypeKind.LongType; > 112: default -> throw new IllegalStateException("Bad new array code: " + newarraycode); Should throw `IllegalArgumentException` to be more informative ------------- PR: https://git.openjdk.org/jdk/pull/13004 From mchung at openjdk.org Mon Mar 13 19:21:10 2023 From: mchung at openjdk.org (Mandy Chung) Date: Mon, 13 Mar 2023 19:21:10 GMT Subject: RFR: 8294962: Convert java.base/jdk.internal.module package to use the Classfile API to modify and write module-info.class [v4] In-Reply-To: References: <6ElqezMc7McFhcHQsB0oTaoSII7RJ569icRg-mT4-3g=.6d902eed-42d0-4578-ba6b-aebc20856dc1@github.com> Message-ID: <3gnb4-KkpWqdb4YqSFXpZuP66t2Mn5Nv_S0wGaPYtrw=.0c005ae3-be04-4bab-984f-67da2bff86a8@github.com> On Mon, 13 Mar 2023 18:46:28 GMT, Alan Bateman wrote: >> I see, I'll move the "packages magic" back from Classfile API to the `ModuleInfoWriter` and correct the API accordingly. > >> I see, I'll move the "packages magic" back from Classfile API to the `ModuleInfoWriter` and correct the API accordingly. > > I would need to check the history in the jake repo but I think it dates from a prototype version of that attribute that only listed the concealed packages. I think it should be okay to just drop this from ModuleInfoWriter now. As I mentioned in another comment, the only user now is tests so you should able to just remove this code so that it doesn't generate the ModulePackages attributes. > I think it would be better to change is so that calling it with ModuleAttribute will emit a Module attribute. The overloads that take a Module plus a set of packages can emit a Module + ModulePackage unconditionally. I'm fine with this. `buildModule(ModuleAttribute moduleAttribute, List packages, Consumer handler)` would emit `ModulePackages` unconditionally. It means that it would need another `buildModule` variant that takes ModuleAttribute and handler only if no `ModulePackages` is generated. ------------- PR: https://git.openjdk.org/jdk/pull/11368 From kvn at openjdk.org Mon Mar 13 19:26:08 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 13 Mar 2023 19:26:08 GMT Subject: RFR: 8303431: [JVMCI] libgraal annotation API [v5] In-Reply-To: References: Message-ID: <94K1Ap5beXB44rCRuHL4PZfbSFizd93ZrFlyG9sTXj4=.e89d2ec7-f8ff-4be7-8f19-dbc2034f1934@github.com> On Wed, 8 Mar 2023 22:59:23 GMT, Doug Simon wrote: >> This PR extends JVMCI with new API (`jdk.vm.ci.meta.Annotated`) for accessing annotations. The main differences from `java.lang.reflect.AnnotatedElement` are: >> * Each `Annotated` method explicitly specifies the annotation type(s) for which it wants annotation data. That is, there is no direct equivalent of `AnnotatedElement.getAnnotations()`. >> * Annotation data is returned in a map-like object (of type `jdk.vm.ci.meta.AnnotationData`) instead of in an `Annotation` object. This works better for libgraal as it avoids the need for annotation types to be loaded and included in libgraal. >> >> To demonstrate the new API, here's an example in terms `java.lang.reflect.AnnotatedElement` (which `ResolvedJavaType` implements): >> >> ResolvedJavaMethod method = ...; >> ExplodeLoop a = method.getAnnotation(ExplodeLoop.class); >> return switch (a.kind()) { >> case FULL_UNROLL -> LoopExplosionKind.FULL_UNROLL; >> case FULL_UNROLL_UNTIL_RETURN -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN; >> ... >> } >> >> >> The same code using the new API: >> >> >> ResolvedJavaMethod method = ...; >> ResolvedJavaType explodeLoopType = ...; >> AnnotationData a = method.getAnnotationDataFor(explodeLoopType); >> return switch (a.getEnum("kind").getName()) { >> case "FULL_UNROLL" -> LoopExplosionKind.FULL_UNROLL; >> case "FULL_UNROLL_UNTIL_RETURN" -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN; >> ... >> } >> >> >> The implementation relies on new methods in `jdk.internal.vm.VMSupport` for parsing annotations and serializing/deserializing to/from a byte array. This allows the annotation data to be passed from the HotSpot heap to the libgraal heap. > > Doug Simon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Merge remote-tracking branch 'openjdk-jdk/master' into JDK-8303431 > - switched to use of lists and maps instead of arrays > - fixed whitespace > - added support for inherited annotations > - Merge branch 'master' into JDK-8303431 > - made AnnotationDataDecoder package-private > - add annotation API to JVMCI test/jdk/jdk/internal/vm/TestTranslatedException.java line 61: > 59: encodeDecode(throwable); > 60: } > 61: Why this was removed? ------------- PR: https://git.openjdk.org/jdk/pull/12810 From kvn at openjdk.org Mon Mar 13 19:31:20 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 13 Mar 2023 19:31:20 GMT Subject: RFR: 8303431: [JVMCI] libgraal annotation API [v5] In-Reply-To: References: Message-ID: <4aRnY_K2BIlWr4MII9PaMop0Qi2gqcvSSn7Heqlxuvw=.063e4544-5fcd-4fab-9b2c-3bcaeffcd381@github.com> On Wed, 8 Mar 2023 22:59:23 GMT, Doug Simon wrote: >> This PR extends JVMCI with new API (`jdk.vm.ci.meta.Annotated`) for accessing annotations. The main differences from `java.lang.reflect.AnnotatedElement` are: >> * Each `Annotated` method explicitly specifies the annotation type(s) for which it wants annotation data. That is, there is no direct equivalent of `AnnotatedElement.getAnnotations()`. >> * Annotation data is returned in a map-like object (of type `jdk.vm.ci.meta.AnnotationData`) instead of in an `Annotation` object. This works better for libgraal as it avoids the need for annotation types to be loaded and included in libgraal. >> >> To demonstrate the new API, here's an example in terms `java.lang.reflect.AnnotatedElement` (which `ResolvedJavaType` implements): >> >> ResolvedJavaMethod method = ...; >> ExplodeLoop a = method.getAnnotation(ExplodeLoop.class); >> return switch (a.kind()) { >> case FULL_UNROLL -> LoopExplosionKind.FULL_UNROLL; >> case FULL_UNROLL_UNTIL_RETURN -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN; >> ... >> } >> >> >> The same code using the new API: >> >> >> ResolvedJavaMethod method = ...; >> ResolvedJavaType explodeLoopType = ...; >> AnnotationData a = method.getAnnotationDataFor(explodeLoopType); >> return switch (a.getEnum("kind").getName()) { >> case "FULL_UNROLL" -> LoopExplosionKind.FULL_UNROLL; >> case "FULL_UNROLL_UNTIL_RETURN" -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN; >> ... >> } >> >> >> The implementation relies on new methods in `jdk.internal.vm.VMSupport` for parsing annotations and serializing/deserializing to/from a byte array. This allows the annotation data to be passed from the HotSpot heap to the libgraal heap. > > Doug Simon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Merge remote-tracking branch 'openjdk-jdk/master' into JDK-8303431 > - switched to use of lists and maps instead of arrays > - fixed whitespace > - added support for inherited annotations > - Merge branch 'master' into JDK-8303431 > - made AnnotationDataDecoder package-private > - add annotation API to JVMCI I looked on Hotspot, JVMCI and VMSupport.java changes. But you need to ask Tom to look on JVMCI changes in details. And someone from core-libs who familiar with Annotations have to comment on your implementation in general because I am not expert. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.org/jdk/pull/12810 From asotona at openjdk.org Mon Mar 13 19:47:56 2023 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 13 Mar 2023 19:47:56 GMT Subject: RFR: 8304031: Classfile API cannot encode Primitive Class as Condy In-Reply-To: <6SEB6ZAh2b0ayMCo5EfvOW-adtsAysbf1Zk6qBbh2SI=.96417080-f2a8-424d-9a26-0ed68f6b33ac@github.com> References: <6SEB6ZAh2b0ayMCo5EfvOW-adtsAysbf1Zk6qBbh2SI=.96417080-f2a8-424d-9a26-0ed68f6b33ac@github.com> Message-ID: On Mon, 13 Mar 2023 08:13:44 GMT, liach wrote: > Without this patch, the Classfile API tries to encode PrimitiveClassDesc as CONSTANT_Class_info and error in `toInternalName`. Looks good, thanks for catching and fixing it. ------------- Marked as reviewed by asotona (Committer). PR: https://git.openjdk.org/jdk/pull/12996 From asotona at openjdk.org Mon Mar 13 20:02:27 2023 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 13 Mar 2023 20:02:27 GMT Subject: RFR: 8294962: Convert java.base/jdk.internal.module package to use the Classfile API to modify and write module-info.class [v4] In-Reply-To: <3gnb4-KkpWqdb4YqSFXpZuP66t2Mn5Nv_S0wGaPYtrw=.0c005ae3-be04-4bab-984f-67da2bff86a8@github.com> References: <6ElqezMc7McFhcHQsB0oTaoSII7RJ569icRg-mT4-3g=.6d902eed-42d0-4578-ba6b-aebc20856dc1@github.com> <3gnb4-KkpWqdb4YqSFXpZuP66t2Mn5Nv_S0wGaPYtrw=.0c005ae3-be04-4bab-984f-67da2bff86a8@github.com> Message-ID: On Mon, 13 Mar 2023 19:18:26 GMT, Mandy Chung wrote: >>> I see, I'll move the "packages magic" back from Classfile API to the `ModuleInfoWriter` and correct the API accordingly. >> >> I would need to check the history in the jake repo but I think it dates from a prototype version of that attribute that only listed the concealed packages. I think it should be okay to just drop this from ModuleInfoWriter now. As I mentioned in another comment, the only user now is tests so you should able to just remove this code so that it doesn't generate the ModulePackages attributes. > >> I think it would be better to change is so that calling it with ModuleAttribute will emit a Module attribute. The overloads that take a Module plus a set of packages can emit a Module + ModulePackage unconditionally. > > I'm fine with this. > > `buildModule(ModuleAttribute moduleAttribute, List packages, Consumer handler)` would emit `ModulePackages` unconditionally. It means that it would need another `buildModule` variant that takes ModuleAttribute and handler only if no `ModulePackages` is generated. `buildModule` argument `List packages` was explicitly added only for the purpose of this conditional packages calculation. If the `ModulePackages` attribute is optional and its content is not calculated, there is no more reason for this argument. I would propose to reduce the method to `buildModule(ModuleAttribute moduleAttribute, Consumer handler)`. `ModulePackages` should be then built using regular approach inside the handler: `classBuilder.with(ModulePackagesAttribute.of(...));`. ------------- PR: https://git.openjdk.org/jdk/pull/11368 From mchung at openjdk.org Mon Mar 13 20:13:04 2023 From: mchung at openjdk.org (Mandy Chung) Date: Mon, 13 Mar 2023 20:13:04 GMT Subject: RFR: 8288730: Lookup::accessClass(Class) should be generic on the type of targetClass In-Reply-To: References: Message-ID: On Sat, 11 Mar 2023 03:28:16 GMT, liach wrote: > Parameterizes `Lookup::accessClass` and `Lookup::ensureInitialized`. Updated an applicable use-site within JDK to benefit from this patch. This change looks fine. Adding a type parameter of a method is binary compatible. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.org/jdk/pull/12984 From dnsimon at openjdk.org Mon Mar 13 20:27:09 2023 From: dnsimon at openjdk.org (Doug Simon) Date: Mon, 13 Mar 2023 20:27:09 GMT Subject: RFR: 8303431: [JVMCI] libgraal annotation API [v5] In-Reply-To: <94K1Ap5beXB44rCRuHL4PZfbSFizd93ZrFlyG9sTXj4=.e89d2ec7-f8ff-4be7-8f19-dbc2034f1934@github.com> References: <94K1Ap5beXB44rCRuHL4PZfbSFizd93ZrFlyG9sTXj4=.e89d2ec7-f8ff-4be7-8f19-dbc2034f1934@github.com> Message-ID: On Mon, 13 Mar 2023 19:23:39 GMT, Vladimir Kozlov wrote: >> Doug Simon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: >> >> - Merge remote-tracking branch 'openjdk-jdk/master' into JDK-8303431 >> - switched to use of lists and maps instead of arrays >> - fixed whitespace >> - added support for inherited annotations >> - Merge branch 'master' into JDK-8303431 >> - made AnnotationDataDecoder package-private >> - add annotation API to JVMCI > > test/jdk/jdk/internal/vm/TestTranslatedException.java line 61: > >> 59: encodeDecode(throwable); >> 60: } >> 61: > > Why this was removed? Because it does exactly the same thing as `encodeDecodeTest`. It should have been cleaned up in the original PR that introduced this test. ------------- PR: https://git.openjdk.org/jdk/pull/12810 From mdoerr at openjdk.org Mon Mar 13 21:00:31 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 13 Mar 2023 21:00:31 GMT Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function & Memory API (Preview) [v3] In-Reply-To: <1OXigMWnfCHCkxCI3D29NpgIpgG36Ltlnry1eytOPow=.5f423637-0a12-454e-a31c-57b2fc11123f@github.com> References: <8b3vVrV22RuhdRoRYacXV0ZeghFGgKkC8S_z-iMrzAQ=.dd84b743-8b51-4281-8f5f-f9eff6207bc7@github.com> <1OXigMWnfCHCkxCI3D29NpgIpgG36Ltlnry1eytOPow=.5f423637-0a12-454e-a31c-57b2fc11123f@github.com> Message-ID: <8I_sDu55v8ThrFyF4mMWbKOOKeGkfYvqo66JLNnULUY=.830fe48d-b65f-437c-82fa-9e7dac76c7ab@github.com> On Mon, 13 Mar 2023 16:37:18 GMT, Jorn Vernee wrote: > > I'm currently wondering about the TestArrayStructs failures. Passing arrays with up to 7 elements seems to work fine. When I pass 8 elements, the last element of capturedArgs gets observed as 0. When I pass more than 8 elements, element 5 and 6 of capturedArgs get observed as 0. > > DowncallLinker.invokeInterpBindings has the correct args, but UpcallLinker.invokeInterpBindings doesn't receive the correct values as lowLevelArgs. They contain the wrong zeros. The remaining elements look correct. > > Do you have an idea what could be going wrong? Otherwise, I'll have to continue debugging. > > This sounds like there might be a mismatch between the Java and native side. I suggest looking at the assembly generated for the native function for the failing case, and seeing if it matches what is generated by CallArranger. Here is also where adding a CallArranger test can be useful (in test/jdk/java/foreign/callarranger), to test whether the resulting bindings match your expectation for that function descriptor. > > Also, you might want to check the layout the native compiler uses for the particular struct, and verify that it matches the Java side. (i.e. there's no weird padding or something, it's just a struct of 8 bytes). Note that argument and return value passing works. I'm getting all values back. So, the native side seems to be ok. Only (one or two) values in `returnBox` are broken. ------------- PR: https://git.openjdk.org/jdk/pull/12708 From asotona at openjdk.org Mon Mar 13 21:02:51 2023 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 13 Mar 2023 21:02:51 GMT Subject: RFR: 8303910: jdk/classfile/CorpusTest.java failed 1 of 6754 tests [v2] In-Reply-To: References: Message-ID: > jdk/classfile/CorpusTest.java rarely fails in 1 of 6754 parametrised parallel junit tests > > The root cause seems to be thread-unsafe lazy initialisation of `TypeKind.newarraycodeToTypeTag` in `TypeKind::fromNewArrayCode`. Provided patch replaces that lazy-initialized helper array with switch expression. > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: throwing IllegalArgumentException instead of IllegalStateException ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13004/files - new: https://git.openjdk.org/jdk/pull/13004/files/f6291c1d..b8631e12 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13004&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13004&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13004.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13004/head:pull/13004 PR: https://git.openjdk.org/jdk/pull/13004 From asotona at openjdk.org Mon Mar 13 21:02:54 2023 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 13 Mar 2023 21:02:54 GMT Subject: RFR: 8303910: jdk/classfile/CorpusTest.java failed 1 of 6754 tests [v2] In-Reply-To: <7pb62rwmAgzId6p0H6RBF7Uhk0KM6e6sdVlTkvXnQcc=.ae4398d4-04fd-401f-9fc6-e42edc86747b@github.com> References: <7pb62rwmAgzId6p0H6RBF7Uhk0KM6e6sdVlTkvXnQcc=.ae4398d4-04fd-401f-9fc6-e42edc86747b@github.com> Message-ID: On Mon, 13 Mar 2023 19:04:45 GMT, liach wrote: >> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: >> >> throwing IllegalArgumentException instead of IllegalStateException > > src/java.base/share/classes/jdk/internal/classfile/TypeKind.java line 112: > >> 110: case 10 -> TypeKind.IntType; >> 111: case 11 -> TypeKind.LongType; >> 112: default -> throw new IllegalStateException("Bad new array code: " + newarraycode); > > Should throw `IllegalArgumentException` to be more informative Right, I've changed it on both places in `TypeKind`, thanks. ------------- PR: https://git.openjdk.org/jdk/pull/13004 From mchung at openjdk.org Mon Mar 13 21:05:10 2023 From: mchung at openjdk.org (Mandy Chung) Date: Mon, 13 Mar 2023 21:05:10 GMT Subject: RFR: 8294962: Convert java.base/jdk.internal.module package to use the Classfile API to modify and write module-info.class [v4] In-Reply-To: References: <6ElqezMc7McFhcHQsB0oTaoSII7RJ569icRg-mT4-3g=.6d902eed-42d0-4578-ba6b-aebc20856dc1@github.com> <3gnb4-KkpWqdb4YqSFXpZuP66t2Mn5Nv_S0wGaPYtrw=.0c005ae3-be04-4bab-984f-67da2bff86a8@github.com> Message-ID: On Mon, 13 Mar 2023 19:59:18 GMT, Adam Sotona wrote: >>> I think it would be better to change is so that calling it with ModuleAttribute will emit a Module attribute. The overloads that take a Module plus a set of packages can emit a Module + ModulePackage unconditionally. >> >> I'm fine with this. >> >> `buildModule(ModuleAttribute moduleAttribute, List packages, Consumer handler)` would emit `ModulePackages` unconditionally. It means that it would need another `buildModule` variant that takes ModuleAttribute and handler only if no `ModulePackages` is generated. > > `buildModule` argument `List packages` was explicitly added only for the purpose of this conditional packages calculation. If the `ModulePackages` attribute is optional and its content is not calculated, there is no more reason for this argument. > I would propose to reduce the method to `buildModule(ModuleAttribute moduleAttribute, Consumer handler)`. `ModulePackages` should be then built using regular approach inside the handler: `classBuilder.with(ModulePackagesAttribute.of(...));`. Taking out the variant with ` packages` is a simplification. Adding `ModulePackagesAttribute` is straight-forward. ------------- PR: https://git.openjdk.org/jdk/pull/11368 From naoto at openjdk.org Mon Mar 13 21:25:51 2023 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 13 Mar 2023 21:25:51 GMT Subject: RFR: 8303018: Unicode Emoji Properties Message-ID: Proposing accessor methods to Emoji properties defined in [Unicode Technical Standard #51](https://unicode.org/reports/tr51/) in `java.lang.Character` class. This is per a request from the client group, as well as refining the currently existing ad-hoc emoji implementation in regex. A CSR has also been drafted, and I would appreciate reviews for it too. ------------- Commit messages: - Clean-up - UTR -> UTS - prepared javadoc - added a test case - 8303018: Unicode Emoji Properties Changes: https://git.openjdk.org/jdk/pull/13006/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13006&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303018 Stats: 869 lines in 19 files changed: 592 ins; 254 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/13006.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13006/head:pull/13006 PR: https://git.openjdk.org/jdk/pull/13006 From rriggs at openjdk.org Mon Mar 13 22:58:52 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 13 Mar 2023 22:58:52 GMT Subject: RFR: 8303485: Replacing os.name for operating system customization [v2] In-Reply-To: <6b9jyeOfI5HBQ4YzYcpHfnXF6xxOuxYbHNlTk2NsEQc=.bd28cb3d-b743-40b5-8ad4-7df8ea62950f@github.com> References: <9GNYcmdPMby8pBH09OhJmHnliaM2nHwFrpQhJRfS8-c=.23fa8a24-7464-43a4-a153-5a45a4ca7c85@github.com> <0-ToBuOoraKiwwuK4eU4PlgOerOeHBB6fJHbuOv-hE4=.7b521903-2d77-4c19-ada6-bcd17db9d37c@github.com> <6b9jyeOfI5HBQ4YzYcpHfnXF6xxOuxYbHNlTk2NsEQc=.bd28cb3d-b743-40b5-8ad4-7df8ea62950f@github.com> Message-ID: On Fri, 10 Mar 2023 05:42:18 GMT, David Holmes wrote: >> Good point. `OperatingSystemProps.java` can be a OS-specific class like: >> >> src/java.base/macosx/classes/jdk/internal/misc/OperatingSystemProps.java >> linux/classes/jdk/internal/misc/OperatingSystemProps.java >> windows/classes/jdk/internal/misc/OperatingSystemProps.java >> >> >> OTOH, if we include `os.arch`, that would need to be a template. A single template file to include both OS and ARCH would do it. > > I was literally thinking of the `#if[xx]` conditional compilation facility rather than an OS specific file, but okay ... The stream preprocessor (SPP) is more involved than the simple substitutions used to insert the target os into the template. ------------- PR: https://git.openjdk.org/jdk/pull/12931 From duke at openjdk.org Mon Mar 13 23:04:48 2023 From: duke at openjdk.org (liach) Date: Mon, 13 Mar 2023 23:04:48 GMT Subject: RFR: 8303910: jdk/classfile/CorpusTest.java failed 1 of 6754 tests [v2] In-Reply-To: References: Message-ID: On Mon, 13 Mar 2023 21:02:51 GMT, Adam Sotona wrote: >> jdk/classfile/CorpusTest.java rarely fails in 1 of 6754 parametrised parallel junit tests >> >> The root cause seems to be thread-unsafe lazy initialisation of `TypeKind.newarraycodeToTypeTag` in `TypeKind::fromNewArrayCode`. Provided patch replaces that lazy-initialized helper array with switch expression. >> >> Please review. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > throwing IllegalArgumentException instead of IllegalStateException Marked as reviewed by liach at github.com (no known OpenJDK username). ------------- PR: https://git.openjdk.org/jdk/pull/13004 From brian.burkhalter at oracle.com Mon Mar 13 23:16:09 2023 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 13 Mar 2023 23:16:09 +0000 Subject: String encoding to ByteBuffer In-Reply-To: <1127337400.2205617.1677454797231@email.ionos.com> References: <1127337400.2205617.1677454797231@email.ionos.com> Message-ID: <82795151-C155-4D44-B875-E27F7E81E70C@oracle.com> Redirecting to nio-dev which is the more appropriate forum for this topic. > On Feb 26, 2023, at 3:39 PM, Carl M wrote: > > I'm looking into adding a fast path case for encoding Strings into ByteBuffers, and wanted to get feedback on a possible approach. My use case is taking mostly-ASCII, UTF-8 Strings and writing them to the disk/network. To do this today, there are two approaches which both have drawbacks: > > 1. Use String.getBytes(StandardCharsets.UTF_8), and call ByteBuffer.put(). The downside of this approach is that I need to make a copy of the String's byte[] value. The upside of this approach is that ByteBuffer uses the intrinsic copy methods, which are fast. > > 2. Wrap the String in a CharBuffer, and call CharsetEncoder.encode(CharBuffer, ByteBuffer). This avoids copying the String value. However, when using the UTF_8 encoder, there is no fastpath for writing to direct ByteBuffers. sun.nio.cs.UTF_8.encodeLoop() only has fast paths for when the destination is array based. This allocates less memory, but is overall slower in my JMH benchmark. > > To fix this, I looked at adding an overload to CharsetEncoder to accept a String (or a CharSequence), and a ByteBuffer as a destination. However, this is not easily doable, since it's hard to call it in a loop. In the case that the String overflows the BB, the caller needs to be able to provide a new BB and resume from where they left off. The CharBuffer approach works here because it keeps the position last read, and can resume from there. > > To encode a String, we need to know that the character index written to resume with a larger buffer. However, the return type on CharsetEncoder's encode method is a CoderResult. The length() method on this can't be called for underflow cases. This means that there isn't a usable return type here (neither int nor CoderResult can be used). > > Another, almost-possible solution I was considering adding a special case to UTF_8 for direct buffer destinations, and a corresponding JLA.encodeASCII overload that accepts a ByteBuffer. The challenge here is that a wrapped CharBuffer doesn't have an array, and so doesn't get the fast path copying. > > The reason I am reaching out here is that I am looking for feedback on my analysis of the existing API. I am wondering what API compromises could be made to fast path writing Strings to direct buffers, which I feel is probably a common operation. The only reasonable way I can see to implement is a new return type, which also seems undesirable as well. > > Carl From mchung at openjdk.org Mon Mar 13 23:23:17 2023 From: mchung at openjdk.org (Mandy Chung) Date: Mon, 13 Mar 2023 23:23:17 GMT Subject: RFR: 8304006: jlink should create the jimage file in the native endian for the target platform [v8] In-Reply-To: References: Message-ID: On Mon, 13 Mar 2023 16:22:30 GMT, Jaikiran Pai wrote: >> Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8206890? >> >> The `jlink` command allows a `--endian` option to specify the byte order in the generated image. Before this change, when such a image was being launched, the code would assume the byte order in the image to be the native order of the host where the image is being launched. That would result in failure to launch java, as noted in the linked issue. >> >> The commit in this PR, changes relevant places to not assume native order and instead determine the byte order by reading the magic bytes in the image file's header content. >> >> A new jtreg test has been added which reproduces the issue and verifies the fix. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > don't hardcode the .jmod extension while determining java.base module location src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 834: > 832: // find the target platform's arch and thus its endianness from the java.base > 833: // module's ModuleTarget attribute > 834: Optional javaBase = cf.findModule("java.base"); `ModuleTarget` is read by `DefaultImageReader::storeFiles` as well. Perhaps it should be refactored so that the target `Platform` can be passed to `DefaultImageBuilder`. src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 953: > 951: // and supported for creating an image through jlink. Else returns null. > 952: private static ByteOrder getNativeEndianOfTargetPlatform(String targetPlatform) { > 953: int index = targetPlatform.indexOf("-"); // of the form - `Platform::parsePlatform` is the utility method to parse `ModuleTarget`. It can be updated to include additional architectures. ------------- PR: https://git.openjdk.org/jdk/pull/11943 From duke at openjdk.org Mon Mar 13 23:51:14 2023 From: duke at openjdk.org (ExE Boss) Date: Mon, 13 Mar 2023 23:51:14 GMT Subject: RFR: 8304031: Classfile API cannot encode Primitive Class as Condy In-Reply-To: <6SEB6ZAh2b0ayMCo5EfvOW-adtsAysbf1Zk6qBbh2SI=.96417080-f2a8-424d-9a26-0ed68f6b33ac@github.com> References: <6SEB6ZAh2b0ayMCo5EfvOW-adtsAysbf1Zk6qBbh2SI=.96417080-f2a8-424d-9a26-0ed68f6b33ac@github.com> Message-ID: On Mon, 13 Mar 2023 08:13:44 GMT, liach wrote: > Without this patch, the Classfile API tries to encode PrimitiveClassDesc as CONSTANT_Class_info and error in `toInternalName`. Arguably, the?`instanceof?DynamicConstantDesc` check?should go?first, as?there?can be?only?one?superclass, but?multiple implemented?interfaces. ------------- PR: https://git.openjdk.org/jdk/pull/12996 From duke at openjdk.org Mon Mar 13 23:55:57 2023 From: duke at openjdk.org (liach) Date: Mon, 13 Mar 2023 23:55:57 GMT Subject: RFR: 8304031: Classfile API cannot encode Primitive Class as Condy In-Reply-To: References: <6SEB6ZAh2b0ayMCo5EfvOW-adtsAysbf1Zk6qBbh2SI=.96417080-f2a8-424d-9a26-0ed68f6b33ac@github.com> Message-ID: On Mon, 13 Mar 2023 23:46:58 GMT, ExE Boss wrote: > Arguably, the?`instanceof?DynamicConstantDesc` check?should go?first, as?there?can be?only?one?superclass, but?multiple implemented?interfaces. I think this ordering is rather ranked by their relative frequency in bytecode. Having integer constants to undergo `instanceof DynamicConstantDesc` checks would be less efficient. ------------- PR: https://git.openjdk.org/jdk/pull/12996 From prr at openjdk.org Tue Mar 14 00:48:10 2023 From: prr at openjdk.org (Phil Race) Date: Tue, 14 Mar 2023 00:48:10 GMT Subject: RFR: 8303018: Unicode Emoji Properties In-Reply-To: References: Message-ID: On Mon, 13 Mar 2023 21:16:24 GMT, Naoto Sato wrote: > Proposing accessor methods to Emoji properties defined in [Unicode Technical Standard #51](https://unicode.org/reports/tr51/) in `java.lang.Character` class. This is per a request from the client group, as well as refining the currently existing ad-hoc emoji implementation in regex. A CSR has also been drafted, and I would appreciate reviews for it too. Not at all familiar with all these templates but everything I do understand lgtm :-) ------------- Marked as reviewed by prr (Reviewer). PR: https://git.openjdk.org/jdk/pull/13006 From jpai at openjdk.org Tue Mar 14 02:09:31 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 14 Mar 2023 02:09:31 GMT Subject: RFR: 8303910: jdk/classfile/CorpusTest.java failed 1 of 6754 tests [v2] In-Reply-To: References: Message-ID: On Mon, 13 Mar 2023 21:02:51 GMT, Adam Sotona wrote: >> jdk/classfile/CorpusTest.java rarely fails in 1 of 6754 parametrised parallel junit tests >> >> The root cause seems to be thread-unsafe lazy initialisation of `TypeKind.newarraycodeToTypeTag` in `TypeKind::fromNewArrayCode`. Provided patch replaces that lazy-initialized helper array with switch expression. >> >> Please review. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > throwing IllegalArgumentException instead of IllegalStateException Looks OK to me. ------------- Marked as reviewed by jpai (Reviewer). PR: https://git.openjdk.org/jdk/pull/13004 From duke at openjdk.org Tue Mar 14 02:52:11 2023 From: duke at openjdk.org (liach) Date: Tue, 14 Mar 2023 02:52:11 GMT Subject: RFR: 8294977: Convert test/jdk/java tests from ASM library to Classfile API Message-ID: Summaries: 1. A few recommendations about updating the constant API is made at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000233.html and I may update this patch shall the API changes be integrated before 2. One ASM library-specific test, `LambdaAsm` is removed. Others have their code generation infrastructure upgraded from ASM to Classfile API. 3. Most tests are included in tier1, but some are not: In `:jdk_io`: (tier2, part 2) test/jdk/java/io/Serializable/records/SerialPersistentFieldsTest.java test/jdk/java/io/Serializable/records/ProhibitedMethods.java test/jdk/java/io/Serializable/records/BadCanonicalCtrTest.java In `:jdk_instrument`: (tier 3) test/jdk/java/lang/instrument/RetransformAgent.java test/jdk/java/lang/instrument/NativeMethodPrefixAgent.java test/jdk/java/lang/instrument/asmlib/Instrumentor.java @asotona Would you mind reviewing? ------------- Commit messages: - Convert test/jdk/java ASM tests to classfile api Changes: https://git.openjdk.org/jdk/pull/13009/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13009&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294977 Stats: 1913 lines in 31 files changed: 283 ins; 888 del; 742 mod Patch: https://git.openjdk.org/jdk/pull/13009.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13009/head:pull/13009 PR: https://git.openjdk.org/jdk/pull/13009 From jvernee at openjdk.org Tue Mar 14 03:05:41 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 14 Mar 2023 03:05:41 GMT Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function & Memory API (Preview) [v3] In-Reply-To: <8I_sDu55v8ThrFyF4mMWbKOOKeGkfYvqo66JLNnULUY=.830fe48d-b65f-437c-82fa-9e7dac76c7ab@github.com> References: <8b3vVrV22RuhdRoRYacXV0ZeghFGgKkC8S_z-iMrzAQ=.dd84b743-8b51-4281-8f5f-f9eff6207bc7@github.com> <1OXigMWnfCHCkxCI3D29NpgIpgG36Ltlnry1eytOPow=.5f423637-0a12-454e-a31c-57b2fc11123f@github.com> <8I_sDu55v8ThrFyF4mMWbKOOKeGkfYvqo66 JLNnULUY=.830fe48d-b65f-437c-82fa-9e7dac76c7ab@github.com> Message-ID: On Mon, 13 Mar 2023 20:57:22 GMT, Martin Doerr wrote: > Note that argument and return value passing works. I'm getting all values back. So, the native side seems to be ok. Only (one or two) values in `returnBox` are broken. You mean you tested by returning each element of the array one by one? If so, that rules out an issue with the downcall, or the struct not being in the right format (in the register), I think. I suggest checking the bindings generated for the upcall, and seeing if they match what the native code does. This could be done in `jshell` for instance: $ .\build\windows-fastdebug\images\jdk\bin\jshell.exe --enable-preview '--add-exports=java.base/jdk.internal.foreign.abi.x64.windows=ALL-UNNAMED' '--add-exports=java.base/jdk.internal.foreign.abi=ALL-UNNAMED' jshell> import java.lang.foreign.* jshell> import java.lang.invoke.* jshell> import static java.lang.foreign.ValueLayout.* jshell> import jdk.internal.foreign.abi.x64.windows.CallArranger jshell> MemoryLayout.structLayout(MemoryLayout.sequenceLayout(8, JAVA_BYTE)) $5 ==> [[8:b8]] jshell> FunctionDescriptor.of($5, $5, JAVA_BYTE, JAVA_BYTE, JAVA_BYTE, JAVA_BYTE, JAVA_BYTE, JAVA_BYTE, JAVA_BYTE, JAVA_BYTE) $6 ==> ([[8:b8]]b8b8b8b8b8b8b8b8)[[8:b8]] jshell> CallArranger.getBindings($6.toMethodType(), $6, true) $7 ==> Bindings[callingSequence=jdk.internal.foreign.abi.CallingSequence at 396e2f39, isInMemoryReturn=false] jshell> System.out.println($7.callingSequence().asString()) CallingSequence: { callerMethodType: (long,int,int,int,int,int,int,int,int)long calleeMethodType: (MemorySegment,byte,byte,byte,byte,byte,byte,byte,byte)MemorySegment FunctionDescriptor: ([[8:b8]]b8b8b8b8b8b8b8b8)[[8:b8]] Argument Bindings: 0: [Allocate[size=8, alignment=1], Dup[], VMLoad[storage=VMStorage[type=0, segmentMaskOrSize=15, indexOrOffset=1, debugName=rcx], type=long], BufferStore[offset=0, type=long, byteWidth=8]] 1: [VMLoad[storage=VMStorage[type=0, segmentMaskOrSize=15, indexOrOffset=2, debugName=rdx], type=int], INT_TO_BYTE] 2: [VMLoad[storage=VMStorage[type=0, segmentMaskOrSize=15, indexOrOffset=8, debugName=r8], type=int], INT_TO_BYTE] 3: [VMLoad[storage=VMStorage[type=0, segmentMaskOrSize=15, indexOrOffset=9, debugName=r9], type=int], INT_TO_BYTE] 4: [VMLoad[storage=VMStorage[type=3, segmentMaskOrSize=8, indexOrOffset=0, debugName=Stack at 0], type=int], INT_TO_BYTE] 5: [VMLoad[storage=VMStorage[type=3, segmentMaskOrSize=8, indexOrOffset=8, debugName=Stack at 8], type=int], INT_TO_BYTE] 6: [VMLoad[storage=VMStorage[type=3, segmentMaskOrSize=8, indexOrOffset=16, debugName=Stack at 16], type=int], INT_TO_BYTE] 7: [VMLoad[storage=VMStorage[type=3, segmentMaskOrSize=8, indexOrOffset=24, debugName=Stack at 24], type=int], INT_TO_BYTE] 8: [VMLoad[storage=VMStorage[type=3, segmentMaskOrSize=8, indexOrOffset=32, debugName=Stack at 32], type=int], INT_TO_BYTE] Return bindings: [BufferLoad[offset=0, type=long, byteWidth=8], VMStore[storage=VMStorage[type=0, segmentMaskOrSize=15, indexOrOffset=0, debugName=rax], type=long]] } ------------- PR: https://git.openjdk.org/jdk/pull/12708 From duke at openjdk.org Tue Mar 14 04:33:54 2023 From: duke at openjdk.org (Glavo) Date: Tue, 14 Mar 2023 04:33:54 GMT Subject: RFR: 8303485: Replacing os.name for operating system customization [v2] In-Reply-To: References: Message-ID: On Fri, 10 Mar 2023 21:21:56 GMT, Roger Riggs wrote: >> Improvements to support OS specific customization for JDK internal use: >> - To select values and code; allowing elimination of unused code and values >> - Optionally evaluated by build processes, compilation, or archiving (i.e. CDS) >> - Simple API to replace adhoc comparisons with `os.name` >> - Clear and consistent use across build, runtime, and JDK modules >> >> The PR includes updates within java.base to use the new API. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Move OperatingSystem from jdk.internal.misc to jdk.internal.util > Rename Mac -> MacOS; isMac() -> isMacOS() src/java.base/unix/classes/sun/net/PortConfig.java line 64: > 62: break; > 63: default: > 64: throw new InternalError( I think it needs to be indented here. ------------- PR: https://git.openjdk.org/jdk/pull/12931 From never at openjdk.org Tue Mar 14 07:12:18 2023 From: never at openjdk.org (Tom Rodriguez) Date: Tue, 14 Mar 2023 07:12:18 GMT Subject: RFR: 8303431: [JVMCI] libgraal annotation API [v5] In-Reply-To: References: Message-ID: On Wed, 8 Mar 2023 22:59:23 GMT, Doug Simon wrote: >> This PR extends JVMCI with new API (`jdk.vm.ci.meta.Annotated`) for accessing annotations. The main differences from `java.lang.reflect.AnnotatedElement` are: >> * Each `Annotated` method explicitly specifies the annotation type(s) for which it wants annotation data. That is, there is no direct equivalent of `AnnotatedElement.getAnnotations()`. >> * Annotation data is returned in a map-like object (of type `jdk.vm.ci.meta.AnnotationData`) instead of in an `Annotation` object. This works better for libgraal as it avoids the need for annotation types to be loaded and included in libgraal. >> >> To demonstrate the new API, here's an example in terms `java.lang.reflect.AnnotatedElement` (which `ResolvedJavaType` implements): >> >> ResolvedJavaMethod method = ...; >> ExplodeLoop a = method.getAnnotation(ExplodeLoop.class); >> return switch (a.kind()) { >> case FULL_UNROLL -> LoopExplosionKind.FULL_UNROLL; >> case FULL_UNROLL_UNTIL_RETURN -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN; >> ... >> } >> >> >> The same code using the new API: >> >> >> ResolvedJavaMethod method = ...; >> ResolvedJavaType explodeLoopType = ...; >> AnnotationData a = method.getAnnotationDataFor(explodeLoopType); >> return switch (a.getEnum("kind").getName()) { >> case "FULL_UNROLL" -> LoopExplosionKind.FULL_UNROLL; >> case "FULL_UNROLL_UNTIL_RETURN" -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN; >> ... >> } >> >> >> The implementation relies on new methods in `jdk.internal.vm.VMSupport` for parsing annotations and serializing/deserializing to/from a byte array. This allows the annotation data to be passed from the HotSpot heap to the libgraal heap. > > Doug Simon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Merge remote-tracking branch 'openjdk-jdk/master' into JDK-8303431 > - switched to use of lists and maps instead of arrays > - fixed whitespace > - added support for inherited annotations > - Merge branch 'master' into JDK-8303431 > - made AnnotationDataDecoder package-private > - add annotation API to JVMCI The JVMCI changes look ok to me. src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 2699: > 2697: typeArrayOop ba = typeArrayOop(res); > 2698: int ba_len = ba->length(); > 2699: if (ba_len <= 256) { Is this really necessary? Resource allocation is very cheap. src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/meta/Annotated.java line 40: > 38: * annotations of this element. > 39: * > 40: * If this element is a class, then {@link Inherited} annotations are included in set of in the set ------------- Marked as reviewed by never (Reviewer). PR: https://git.openjdk.org/jdk/pull/12810 From alanb at openjdk.org Tue Mar 14 08:00:09 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 14 Mar 2023 08:00:09 GMT Subject: RFR: 8294977: Convert test/jdk/java tests from ASM library to Classfile API In-Reply-To: References: Message-ID: On Tue, 14 Mar 2023 02:43:41 GMT, liach wrote: > Summaries: > 1. A few recommendations about updating the constant API is made at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000233.html and I may update this patch shall the API changes be integrated before > 2. One ASM library-specific test, `LambdaAsm` is removed. Others have their code generation infrastructure upgraded from ASM to Classfile API. > 3. Most tests are included in tier1, but some are not: > In `:jdk_io`: (tier2, part 2) > > test/jdk/java/io/Serializable/records/SerialPersistentFieldsTest.java > test/jdk/java/io/Serializable/records/ProhibitedMethods.java > test/jdk/java/io/Serializable/records/BadCanonicalCtrTest.java > > In `:jdk_instrument`: (tier 3) > > test/jdk/java/lang/instrument/RetransformAgent.java > test/jdk/java/lang/instrument/NativeMethodPrefixAgent.java > test/jdk/java/lang/instrument/asmlib/Instrumentor.java > > > @asotona Would you mind reviewing? Good to see these tests converted, just a few nits about trying to keep the code/style consistent with the existing code/style where possible. test/jdk/java/lang/ModuleTests/AnnotationsTest.java line 146: > 144: */ > 145: static byte[] addDeprecated(byte[] bytes, boolean forRemoval, String since) { > 146: return Classfile.parse(bytes).transform(ClassTransform.ACCEPT_ALL.andThen(ClassTransform.endHandler(clb -> { The conversion of this test okay but would be good if you split up the overly long lines as they are inconsistent with everything else in this test and makes it annoying to look at the changes side-by-side. test/jdk/java/lang/invoke/defineHiddenClass/BasicTest.java line 282: > 280: > 281: assertTrue(hc.isHidden()); > 282: assertEquals(hc.getModifiers(), accessFlags.stream().mapToInt(AccessFlag::mask).reduce(AccessFlag.PUBLIC.mask(), (a, b) -> a | b)); Do you mind splitting this line too, it's 140+ characters long so impossible to look at the changes side-by-side. test/jdk/java/util/ServiceLoader/BadProvidersTest.java line 216: > 214: clb.withSuperclass(CD_Object); > 215: clb.withFlags(AccessFlag.PUBLIC, AccessFlag.SUPER); > 216: var provider$1Desc = ClassDesc.of("p", "ProviderFactory$1"); This is class descriptor for ProviderFactory$1, not "Provider" so maybe rename this to providerFactory1 or something a bit clearer. ------------- PR: https://git.openjdk.org/jdk/pull/13009 From Alan.Bateman at oracle.com Tue Mar 14 08:03:20 2023 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 14 Mar 2023 08:03:20 +0000 Subject: String encoding to ByteBuffer In-Reply-To: <82795151-C155-4D44-B875-E27F7E81E70C@oracle.com> References: <1127337400.2205617.1677454797231@email.ionos.com> <82795151-C155-4D44-B875-E27F7E81E70C@oracle.com> Message-ID: <557b48d8-1690-dea3-e9a3-97e96cce9ef4@oracle.com> On 13/03/2023 23:16, Brian Burkhalter wrote: > Redirecting to nio-dev which is the more appropriate forum for this topic. > There have been a couple of explorations into this, one was Richard Warburton's prototype [1]. There are a couple of follow-up threads about this on core-libs-dev and nio-dev, including explorations into additions to CharsetEncoder. -Alan [1] https://mail.openjdk.org/pipermail/core-libs-dev/2014-September/028837.html From alanb at openjdk.org Tue Mar 14 08:16:16 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 14 Mar 2023 08:16:16 GMT Subject: RFR: 8303018: Unicode Emoji Properties In-Reply-To: References: Message-ID: On Mon, 13 Mar 2023 21:16:24 GMT, Naoto Sato wrote: > Proposing accessor methods to Emoji properties defined in [Unicode Technical Standard #51](https://unicode.org/reports/tr51/) in `java.lang.Character` class. This is per a request from the client group, as well as refining the currently existing ad-hoc emoji implementation in regex. A CSR has also been drafted, and I would appreciate reviews for it too. src/java.base/share/classes/java/lang/Character.java line 10803: > 10801: /** > 10802: * Determines if the specified character (Unicode code point) has the > 10803: * Emoji Presentation by default. "has the Emoji Presentation", should that be "has the Emoji Presentation property"? src/java.base/share/classes/java/lang/Character.java line 10887: > 10885: * @since 21 > 10886: */ > 10887: public static boolean isExtendedPictographic(int codePoint) { Is there a "cut 'n paste" error here, it looks like the description has been copied from isEmojiComponent. ------------- PR: https://git.openjdk.org/jdk/pull/13006 From alanb at openjdk.org Tue Mar 14 08:32:36 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 14 Mar 2023 08:32:36 GMT Subject: RFR: 8304006: jlink should create the jimage file in the native endian for the target platform [v8] In-Reply-To: References: Message-ID: On Mon, 13 Mar 2023 23:07:13 GMT, Mandy Chung wrote: > `Platform::parsePlatform` is the utility method to parse `ModuleTarget`. It can be updated to include additional architectures. Alternatively, don't parse it. If we go with Jim's suggestion of a resource file then it is just a simple mapping of the ModuleTarget value, e.g the entry for macox-x64 would be: macos-amd64.endianness = little ------------- PR: https://git.openjdk.org/jdk/pull/11943 From asotona at openjdk.org Tue Mar 14 08:38:58 2023 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 14 Mar 2023 08:38:58 GMT Subject: Integrated: 8303910: jdk/classfile/CorpusTest.java failed 1 of 6754 tests In-Reply-To: References: Message-ID: On Mon, 13 Mar 2023 18:54:11 GMT, Adam Sotona wrote: > jdk/classfile/CorpusTest.java rarely fails in 1 of 6754 parametrised parallel junit tests > > The root cause seems to be thread-unsafe lazy initialisation of `TypeKind.newarraycodeToTypeTag` in `TypeKind::fromNewArrayCode`. Provided patch replaces that lazy-initialized helper array with switch expression. > > Please review. > > Thanks, > Adam This pull request has now been integrated. Changeset: 43eca1dc Author: Adam Sotona URL: https://git.openjdk.org/jdk/commit/43eca1dcb197e3615b6077a5d8aef28f32a7724c Stats: 14 lines in 1 file changed: 4 ins; 2 del; 8 mod 8303910: jdk/classfile/CorpusTest.java failed 1 of 6754 tests Reviewed-by: jpai ------------- PR: https://git.openjdk.org/jdk/pull/13004 From stsypanov at openjdk.org Tue Mar 14 09:24:09 2023 From: stsypanov at openjdk.org (Sergey Tsypanov) Date: Tue, 14 Mar 2023 09:24:09 GMT Subject: RFR: JDK-8302323 Add repeat methods to StringBuilder/StringBuffer [v8] In-Reply-To: References: Message-ID: On Fri, 3 Mar 2023 19:04:22 GMT, Jim Laskey wrote: >> Add the ability to repeatedly append char and CharSequence data to StringBuilder/StringBuffer. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Expand test for StringBuffer and illegal code points Should we also have overloaded method accepting position to insert repeated value? Smth like `repeat(int pos, char c, int count)`? ------------- PR: https://git.openjdk.org/jdk/pull/12728 From duke at openjdk.org Tue Mar 14 09:38:07 2023 From: duke at openjdk.org (Glavo) Date: Tue, 14 Mar 2023 09:38:07 GMT Subject: RFR: 8294982: Implementation of Classfile API [v58] In-Reply-To: References: Message-ID: On Wed, 8 Mar 2023 08:50:24 GMT, Adam Sotona wrote: >> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. >> >> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. >> >> Classfile API development is tracked at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch >> >> Development branch of consolidated JDK class files parsing, generating, and transforming is at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch >> >> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available. >> >> Please take you time to review this non-trivial JDK addition. >> >> Thank you, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > removed obsolete javadoc from implementation classes I ported the Classfile API implemented in this PR back to Java 17 and published it to Maven Central as a standalone library: https://github.com/Glavo/classfile Some of my senior developer friends are trying to replace ASM with it. If I get any feedback, I'll report it to you. ------------- PR: https://git.openjdk.org/jdk/pull/10982 From redestad at openjdk.org Tue Mar 14 10:25:19 2023 From: redestad at openjdk.org (Claes Redestad) Date: Tue, 14 Mar 2023 10:25:19 GMT Subject: RFR: JDK-8302323 Add repeat methods to StringBuilder/StringBuffer [v8] In-Reply-To: References: Message-ID: On Fri, 3 Mar 2023 19:04:22 GMT, Jim Laskey wrote: >> Add the ability to repeatedly append char and CharSequence data to StringBuilder/StringBuffer. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Expand test for StringBuffer and illegal code points It seems reasonable to consider analogous `insert` methods. Perhaps a more consistent naming scheme would be `appendRepeated` and `insertRepeated`? (The precedent for `repeat` in `String::repeat` is there, but is kind of weak since it's clear in that case that we're not mutating internal state) src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1832: > 1830: if (isLatin1 && StringLatin1.canEncode(c)) { > 1831: byte b = (byte)c; > 1832: for (int index = this.count; index < limit; index++) { This loop could even be replaced with `Arrays.fill(value, this.count, limit, b)` - a plausible candidate for intrinsification? There's an added range check in that method, however, but that shouldn't be too hard for the JIT to eliminate. ------------- PR: https://git.openjdk.org/jdk/pull/12728 From duke at openjdk.org Tue Mar 14 12:04:03 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Tue, 14 Mar 2023 12:04:03 GMT Subject: RFR: 8302872: Speed up StringLatin1.regionMatchesCI_UTF16 [v2] In-Reply-To: <4SMUYcB8RTO3-nB444DCUHNcdDCmcO7WtCBCf7Gc9KM=.c8f2ab0b-1b72-461b-88e8-135318e092cc@github.com> References: <4SMUYcB8RTO3-nB444DCUHNcdDCmcO7WtCBCf7Gc9KM=.c8f2ab0b-1b72-461b-88e8-135318e092cc@github.com> Message-ID: > This PR continues the efforts from #12632 to speed up case-insensitive string matching. > > We now tackle case-insensitive comparison of mixed-coder strings, implemented in `StringLatin1.regionMatchesCI_UTF16` > > Key insights: > > - If the UTF16 code point is also in latin1 range, we can leverage improvements from 12632 directly by calling `CharacterDataLatin1.equalsIgnoreCase` > - There are exactly 7 non-latin1 Unicode code points which case fold into the latin1 range. We can special-case our comparison of these code points by adding the method `CharacterDataLatin1.latin1CaseFold`. > - To avoid checking of `a == b` twice, this check is lifted out of `CharacterDataLatin1.equalsIgnoreCase` and the two callers are updated to check that `a != b` before calling the method. > > For completeness, the RegionMatches test is updated to also compare Turkic dotted/dotless 'i's against the uppercase ASCII 'I', not just the lowercase one. Not stricktly related to the purpose of this PR, but it did help catch a regression introduced in an earlier iteration of the PR. > > To guard against regressions caused by future changes to the set of Unicode code points folding into latin1, a new test is added to `EqualsIgnoreCase` which identifies all such code points and verifies they are compared correcty. > > Performance is tested for matching and mismatching cases of selected code point pairs picked from the ASCII letter, ASCII number, latin1 letter and non-latin Unicode letter ranges. Results in the first comment below. Eirik Bjorsnos has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits: - Merge branch 'master' into regionmatches-mixed-speedup - Inline local variable - latin1CaseFold was moved to CharacterDataLatin1 - Move latin1CaseFold to CharacterDataLatin1 - Improve latin1CaseFold javadocs - Simplify comments - Prefer fast matching by comparing for equality before checking latin1 range - Improve Javadocs of latin1CaseFold - Be consistent in comments - CharacterData.latin1LowerCase was renamed to latin1CaseFold - ... and 14 more: https://git.openjdk.org/jdk/compare/6d30bbe6...2340f8b5 ------------- Changes: https://git.openjdk.org/jdk/pull/12637/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12637&range=01 Stats: 169 lines in 5 files changed: 155 ins; 2 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/12637.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12637/head:pull/12637 PR: https://git.openjdk.org/jdk/pull/12637 From asotona at openjdk.org Tue Mar 14 12:55:38 2023 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 14 Mar 2023 12:55:38 GMT Subject: RFR: 8294962: Convert java.base/jdk.internal.module package to use the Classfile API to modify and write module-info.class [v5] In-Reply-To: References: Message-ID: > 8294962: java.base jdk.internal.module package uses ASM to modify and write module-info.class. > This patch converts it to use Classfile API. > > Please review. > Thanks, > Adam Adam Sotona has updated the pull request incrementally with five additional commits since the last revision: - fixed ModuleDescriptorTest::testReadsWithBadPackageFinder to use Classfile API directly to generate modules descriptor without ModulePackagesAttribute - ModuleInfoWriter converted to support invalid module names and emit ModulePackagesAttribute if packages are provided - fixed Classfile API tests - added ModuleAttribute::of(ModuleEntry, Consumer) - removed obsolete Classfile.buildModule method argument List and obsolete method overrides ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11368/files - new: https://git.openjdk.org/jdk/pull/11368/files/089220bc..da280b0b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11368&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11368&range=03-04 Stats: 134 lines in 7 files changed: 41 ins; 50 del; 43 mod Patch: https://git.openjdk.org/jdk/pull/11368.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11368/head:pull/11368 PR: https://git.openjdk.org/jdk/pull/11368 From erikj at openjdk.org Tue Mar 14 13:19:17 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 14 Mar 2023 13:19:17 GMT Subject: RFR: 8303018: Unicode Emoji Properties In-Reply-To: References: Message-ID: On Mon, 13 Mar 2023 21:16:24 GMT, Naoto Sato wrote: > Proposing accessor methods to Emoji properties defined in [Unicode Technical Standard #51](https://unicode.org/reports/tr51/) in `java.lang.Character` class. This is per a request from the client group, as well as refining the currently existing ad-hoc emoji implementation in regex. A CSR has also been drafted, and I would appreciate reviews for it too. Build changes look ok. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.org/jdk/pull/13006 From rriggs at openjdk.org Tue Mar 14 14:14:30 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 14 Mar 2023 14:14:30 GMT Subject: RFR: 8303485: Replacing os.name for operating system customization [v3] In-Reply-To: References: Message-ID: <6dSxY-deX1RXY46V7U4snk2q5o5j8OkfMwVfAEQU_-k=.1a44c94e-0ccb-4e95-915e-3b83ec1bf88b@github.com> > Improvements to support OS specific customization for JDK internal use: > - To select values and code; allowing elimination of unused code and values > - Optionally evaluated by build processes, compilation, or archiving (i.e. CDS) > - Simple API to replace adhoc comparisons with `os.name` > - Clear and consistent use across build, runtime, and JDK modules > > The PR includes updates within java.base to use the new API. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Fix indentation and improve exception message ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12931/files - new: https://git.openjdk.org/jdk/pull/12931/files/342f30f2..be27adb0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12931&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12931&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12931.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12931/head:pull/12931 PR: https://git.openjdk.org/jdk/pull/12931 From rriggs at openjdk.org Tue Mar 14 14:14:50 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 14 Mar 2023 14:14:50 GMT Subject: RFR: 8303392: Runtime.exec and ProcessBuilder.start should use System logger [v6] In-Reply-To: References: <-1i11ZrHHgzUbCSa_RXAcGKNfgtpdui--bltZ4Ujs2A=.f5f1a7e2-d3ec-4f64-9b1e-317ef2f24ef1@github.com> Message-ID: On Fri, 10 Mar 2023 21:34:56 GMT, Roger Riggs wrote: >> Runtime.exec and ProcessBuilder.start methods create a new operating system process with the program and arguments. Many applications configure a logging subsystem to monitor application events. Logging a process start message with the program, arguments, and stack trace can identify the caller and purpose. >> Logging the process start event is complementary to the process start event generated for JFR (Java Flight Recorder). > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Reword @implNote to indicate logging can be enabled. (But is not by default) Please review the CSR: [JDK-8303392](https://bugs.openjdk.org/browse/JDK-8303392) ------------- PR: https://git.openjdk.org/jdk/pull/12862 From duke at openjdk.org Tue Mar 14 14:39:48 2023 From: duke at openjdk.org (liach) Date: Tue, 14 Mar 2023 14:39:48 GMT Subject: RFR: 8304139: Add , , and main method constants to ClassDescs Message-ID: Add String constants INIT_NAME, CLASS_INIT_NAME, MTD_void for the names and method type of instance and class initializers; add String constant MAIN_NAME and MTD_void_StringArray for the name and method type of main method. Update occurrences of and in core libraries API specification to refer to these constants. The occurrences in code elsewhere will be converted separately for there are too many. See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000233.html ------------- Commit messages: - Add constants for initializers and main Changes: https://git.openjdk.org/jdk/pull/13020/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13020&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304139 Stats: 85 lines in 7 files changed: 64 ins; 0 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/13020.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13020/head:pull/13020 PR: https://git.openjdk.org/jdk/pull/13020 From alanb at openjdk.org Tue Mar 14 14:50:40 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 14 Mar 2023 14:50:40 GMT Subject: RFR: 8294962: Convert java.base/jdk.internal.module package to use the Classfile API to modify and write module-info.class [v5] In-Reply-To: References: Message-ID: On Tue, 14 Mar 2023 12:55:38 GMT, Adam Sotona wrote: >> 8294962: java.base jdk.internal.module package uses ASM to modify and write module-info.class. >> This patch converts it to use Classfile API. >> >> Please review. >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with five additional commits since the last revision: > > - fixed ModuleDescriptorTest::testReadsWithBadPackageFinder to use Classfile API directly to generate modules descriptor without ModulePackagesAttribute > - ModuleInfoWriter converted to support invalid module names and emit ModulePackagesAttribute if packages are provided > - fixed Classfile API tests > - added ModuleAttribute::of(ModuleEntry, Consumer) > - removed obsolete Classfile.buildModule method argument List and obsolete method overrides Marked as reviewed by alanb (Reviewer). src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 293: > 291: } > 292: > 293: public static final int MAGIC_NUMBER = 0xCAFEBABE; Dropping the packages parameter and the buildModuleTo overloads looks good. src/java.base/share/classes/jdk/internal/module/ModuleInfoExtender.java line 199: > 197: clb.accept(cle); > 198: } > 199: })); Updated ModuleInfoExtender looks okay. src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java line 167: > 165: clb.with(ModuleTargetAttribute.of(target.targetPlatform())); > 166: } > 167: }); The update ModuleInfoWriter looks fine. test/jdk/java/lang/module/ModuleDescriptorTest.java line 1375: > 1373: ModuleAttribute.of(ModuleDesc.of("foo"), mb -> mb > 1374: .requires(ModuleDesc.of("java.base"), 0, null) > 1375: .exports(PackageDesc.of("p"), 0)))); If you split this up into two or third steps then it would be easier to read/debug. ------------- PR: https://git.openjdk.org/jdk/pull/11368 From alanb at openjdk.org Tue Mar 14 15:16:39 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 14 Mar 2023 15:16:39 GMT Subject: RFR: 8303485: Replacing os.name for operating system customization [v3] In-Reply-To: <6dSxY-deX1RXY46V7U4snk2q5o5j8OkfMwVfAEQU_-k=.1a44c94e-0ccb-4e95-915e-3b83ec1bf88b@github.com> References: <6dSxY-deX1RXY46V7U4snk2q5o5j8OkfMwVfAEQU_-k=.1a44c94e-0ccb-4e95-915e-3b83ec1bf88b@github.com> Message-ID: On Tue, 14 Mar 2023 14:14:30 GMT, Roger Riggs wrote: >> Improvements to support OS specific customization for JDK internal use: >> - To select values and code; allowing elimination of unused code and values >> - Optionally evaluated by build processes, compilation, or archiving (i.e. CDS) >> - Simple API to replace adhoc comparisons with `os.name` >> - Clear and consistent use across build, runtime, and JDK modules >> >> The PR includes updates within java.base to use the new API. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Fix indentation and improve exception message src/java.base/share/classes/jdk/internal/util/OperatingSystem.java line 29: > 27: > 28: /** > 29: * Enumeration of operating system types and testing for the current OS. Would it be more correct to say an enumerating of operating system names rather than types? src/java.base/unix/classes/java/lang/ProcessImpl.java line 405: > 403: > 404: case Windows: throw new AssertionError("Unsupported platform: " + > 405: OperatingSystem.current()); This is switch on a enum so if a new port is added then this will just fall through silently, whereas I think you want it to fail. ------------- PR: https://git.openjdk.org/jdk/pull/12931 From asotona at openjdk.org Tue Mar 14 15:27:50 2023 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 14 Mar 2023 15:27:50 GMT Subject: RFR: 8294972: Convert jdk.jlink internal plugins to use the Classfile API [v6] In-Reply-To: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> Message-ID: > jdk.jlink internal plugins are heavily using ASM > > This patch converts ASM calls to Classfile API. > > Please review. > Thanks, > Adam Adam Sotona has updated the pull request incrementally with three additional commits since the last revision: - long lines wrapped - StripJavaDebugAttributesPlugin transformation fixed - VersionPropsPlugin transformation fixed ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12944/files - new: https://git.openjdk.org/jdk/pull/12944/files/5042a093..5fe8c7f4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12944&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12944&range=04-05 Stats: 94 lines in 3 files changed: 27 ins; 18 del; 49 mod Patch: https://git.openjdk.org/jdk/pull/12944.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12944/head:pull/12944 PR: https://git.openjdk.org/jdk/pull/12944 From asotona at openjdk.org Tue Mar 14 15:27:53 2023 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 14 Mar 2023 15:27:53 GMT Subject: RFR: 8294972: Convert jdk.jlink internal plugins to use the Classfile API [v4] In-Reply-To: References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> Message-ID: On Fri, 10 Mar 2023 22:14:00 GMT, Mandy Chung wrote: >> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 208 commits: >> >> - Merge branch 'master' into JDK-8294972-jlink-plugins >> >> # Conflicts: >> # src/java.base/share/classes/module-info.java >> - Merge branch 'master' into JDK-8294972-jlink-plugins >> - fixed SystemModulesPlugin formatting >> - 8303624: The java.lang.Thread.FieldHolder can be null for JNI attaching threads >> >> Reviewed-by: alanb, dcubed >> - 8302360: Atomic*.compareAndExchange Javadoc unclear >> >> Reviewed-by: martin, dholmes >> - 8302779: HelidonAppTest.java fails with "assert(_cb == CodeCache::find_blob(pc())) failed: Must be the same" or SIGSEGV >> >> Reviewed-by: coleenp, sspitsyn >> - 8303691: Fedora based devkit build should load more packages from archive location >> >> Reviewed-by: mbaesken, erikj >> - 8303924: ProblemList serviceability/sa/UniqueVtableTest.java on Linux >> >> Reviewed-by: dcubed >> - 8303609: ProblemList serviceability/sa/TestSysProps.java with ZGC >> >> Reviewed-by: dcubed >> - 8289765: JDI EventSet/resume/resume008 failed with "ERROR: suspendCounts don't match for : VirtualThread-unparker" >> >> Reviewed-by: sspitsyn, kevinw >> - ... and 198 more: https://git.openjdk.org/jdk/compare/b1d89f30...cfc612ec > > src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/StripJavaDebugAttributesPlugin.java line 62: > >> 60: // XXX. Do we have debug info? Is Asm ready for module-info? >> 61: } else { >> 62: byte[] content = newClassReader(path, resource, Classfile.Option.processDebug(false)) > > ASM `ClassReader.SKIP_DEBUG` flag indicates to skip the SourceFile, SourceDebugExtension, LocalVariableTable, LocalVariableTypeTable, LineNumberTable and MethodParameters attributes. > > `Classfile.Option.processDebug(false)` only skips LocalVariableTable, LocalVariableTypeTable, CHARACTER_RANGE_TABLE attributes. To implement the same behavior as `SKIP_DEBUG`, it needs `Classfile.Option.processLineNumbers(false)` and skipping other attributes. Right, I'll fix it, thanks. > src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/VersionPropsPlugin.java line 158: > >> 156: }); >> 157: } >> 158: }); > > Suggestion: > > }); > } else { > clb.with(cle); > > > Other `ClassElement`s need to be added to the builder; otherwise they are dropped. > > One more thing I notice is that the attributes for example `LineNumberTable` attribute in `` method after transformed are dropped. But this plugin should only transform the code and leave everything else touched. Yes, this transformation is incomplete and not using the latest Classfile API patterns. I'll update it, thanks. ------------- PR: https://git.openjdk.org/jdk/pull/12944 From asotona at openjdk.org Tue Mar 14 15:27:57 2023 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 14 Mar 2023 15:27:57 GMT Subject: RFR: 8294972: Convert jdk.jlink internal plugins to use the Classfile API [v4] In-Reply-To: References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> Message-ID: On Mon, 13 Mar 2023 14:51:08 GMT, Alan Bateman wrote: >> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 208 commits: >> >> - Merge branch 'master' into JDK-8294972-jlink-plugins >> >> # Conflicts: >> # src/java.base/share/classes/module-info.java >> - Merge branch 'master' into JDK-8294972-jlink-plugins >> - fixed SystemModulesPlugin formatting >> - 8303624: The java.lang.Thread.FieldHolder can be null for JNI attaching threads >> >> Reviewed-by: alanb, dcubed >> - 8302360: Atomic*.compareAndExchange Javadoc unclear >> >> Reviewed-by: martin, dholmes >> - 8302779: HelidonAppTest.java fails with "assert(_cb == CodeCache::find_blob(pc())) failed: Must be the same" or SIGSEGV >> >> Reviewed-by: coleenp, sspitsyn >> - 8303691: Fedora based devkit build should load more packages from archive location >> >> Reviewed-by: mbaesken, erikj >> - 8303924: ProblemList serviceability/sa/UniqueVtableTest.java on Linux >> >> Reviewed-by: dcubed >> - 8303609: ProblemList serviceability/sa/TestSysProps.java with ZGC >> >> Reviewed-by: dcubed >> - 8289765: JDI EventSet/resume/resume008 failed with "ERROR: suspendCounts don't match for : VirtualThread-unparker" >> >> Reviewed-by: sspitsyn, kevinw >> - ... and 198 more: https://git.openjdk.org/jdk/compare/b1d89f30...cfc612ec > > src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 75: > >> 73: import jdk.internal.module.ModuleTarget; >> 74: >> 75: import jdk.internal.classfile.attribute.ModulePackagesAttribute; > > I don't think this is directly used. `ModulePackagesAttribute` is actually used in the code. > src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 866: > >> 864: } >> 865: >> 866: MethodTypeDesc desc = MethodTypeDesc.ofDescriptor("(Ljava/lang/Object;Ljava/lang/Object;)Ljava/util/Map$Entry;"); > > It would be helpful if some of the overly long lines could be trimmed down a bit as it's really hard to look at changes side-by-side. I'll fix it, thanks. ------------- PR: https://git.openjdk.org/jdk/pull/12944 From alanb at openjdk.org Tue Mar 14 15:43:58 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 14 Mar 2023 15:43:58 GMT Subject: RFR: 8303392: Runtime.exec and ProcessBuilder.start should use System logger [v6] In-Reply-To: References: <-1i11ZrHHgzUbCSa_RXAcGKNfgtpdui--bltZ4Ujs2A=.f5f1a7e2-d3ec-4f64-9b1e-317ef2f24ef1@github.com> Message-ID: <-j9AzEcELMFQ7KD-aaZp8dnuKSO8pJCIkNn5vGE22X8=.a6c9da48-3827-4feb-af70-7843cfd97c18@github.com> On Fri, 10 Mar 2023 21:34:56 GMT, Roger Riggs wrote: >> Runtime.exec and ProcessBuilder.start methods create a new operating system process with the program and arguments. Many applications configure a logging subsystem to monitor application events. Logging a process start message with the program, arguments, and stack trace can identify the caller and purpose. >> Logging the process start event is complementary to the process start event generated for JFR (Java Flight Recorder). > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Reword @implNote to indicate logging can be enabled. (But is not by default) Marked as reviewed by alanb (Reviewer). src/java.base/share/classes/java/lang/ProcessBuilder.java line 194: > 192: { > 193: // Lazily and racy initialize when needed, racy is ok, any logger is ok > 194: private static System.Logger LOGGER ; Minor nit, there's a space before the semi-colon. src/java.base/share/classes/java/lang/ProcessBuilder.java line 205: > 203: System.Logger logger = System.getLogger("java.lang.ProcessBuilder"); > 204: return logger.isLoggable(System.Logger.Level.DEBUG) ? logger : null; > 205: } Is initLogger left over from a previous iteration? ------------- PR: https://git.openjdk.org/jdk/pull/12862 From asotona at openjdk.org Tue Mar 14 15:47:33 2023 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 14 Mar 2023 15:47:33 GMT Subject: RFR: 8294962: Convert java.base/jdk.internal.module package to use the Classfile API to modify and write module-info.class [v6] In-Reply-To: References: Message-ID: <0GZplW4gyCygkZwU4DTw6IX1vKOMXZ0PfIIFgdUSG2k=.d7f7225b-ff8e-4f8e-8f9c-36d3a45cc031@github.com> > 8294962: java.base jdk.internal.module package uses ASM to modify and write module-info.class. > This patch converts it to use Classfile API. > > Please review. > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: fixed formatting ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11368/files - new: https://git.openjdk.org/jdk/pull/11368/files/da280b0b..64498771 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11368&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11368&range=04-05 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/11368.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11368/head:pull/11368 PR: https://git.openjdk.org/jdk/pull/11368 From naoto at openjdk.org Tue Mar 14 15:49:56 2023 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 14 Mar 2023 15:49:56 GMT Subject: RFR: 8303018: Unicode Emoji Properties [v2] In-Reply-To: References: Message-ID: > Proposing accessor methods to Emoji properties defined in [Unicode Technical Standard #51](https://unicode.org/reports/tr51/) in `java.lang.Character` class. This is per a request from the client group, as well as refining the currently existing ad-hoc emoji implementation in regex. A CSR has also been drafted, and I would appreciate reviews for it too. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Fixed method descriptions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13006/files - new: https://git.openjdk.org/jdk/pull/13006/files/4b2a2418..0b7b7296 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13006&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13006&range=00-01 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/13006.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13006/head:pull/13006 PR: https://git.openjdk.org/jdk/pull/13006 From naoto at openjdk.org Tue Mar 14 15:50:00 2023 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 14 Mar 2023 15:50:00 GMT Subject: RFR: 8303018: Unicode Emoji Properties [v2] In-Reply-To: References: Message-ID: On Tue, 14 Mar 2023 08:13:11 GMT, Alan Bateman wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed method descriptions > > src/java.base/share/classes/java/lang/Character.java line 10803: > >> 10801: /** >> 10802: * Determines if the specified character (Unicode code point) has the >> 10803: * Emoji Presentation by default. > > "has the Emoji Presentation", should that be "has the Emoji Presentation property"? Fixed this one as well > src/java.base/share/classes/java/lang/Character.java line 10887: > >> 10885: * @since 21 >> 10886: */ >> 10887: public static boolean isExtendedPictographic(int codePoint) { > > Is there a "cut 'n paste" error here, it looks like the description has been copied from isEmojiComponent. My bad. You are right. Corrected. ------------- PR: https://git.openjdk.org/jdk/pull/13006 From dnsimon at openjdk.org Tue Mar 14 15:56:48 2023 From: dnsimon at openjdk.org (Doug Simon) Date: Tue, 14 Mar 2023 15:56:48 GMT Subject: RFR: 8303431: [JVMCI] libgraal annotation API [v5] In-Reply-To: References: Message-ID: On Tue, 14 Mar 2023 06:28:20 GMT, Tom Rodriguez wrote: >> Doug Simon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: >> >> - Merge remote-tracking branch 'openjdk-jdk/master' into JDK-8303431 >> - switched to use of lists and maps instead of arrays >> - fixed whitespace >> - added support for inherited annotations >> - Merge branch 'master' into JDK-8303431 >> - made AnnotationDataDecoder package-private >> - add annotation API to JVMCI > > src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 2699: > >> 2697: typeArrayOop ba = typeArrayOop(res); >> 2698: int ba_len = ba->length(); >> 2699: if (ba_len <= 256) { > > Is this really necessary? Resource allocation is very cheap. Ok, good point. I'll remove the optimization. ------------- PR: https://git.openjdk.org/jdk/pull/12810 From duke at openjdk.org Tue Mar 14 15:57:35 2023 From: duke at openjdk.org (Thiago Henrique =?UTF-8?B?SMO8cG5lcg==?=) Date: Tue, 14 Mar 2023 15:57:35 GMT Subject: RFR: 8304148: Remapping a class with Invokedynamic constant loses static bootstrap arguments Message-ID: 8304148: Remapping a class with Invokedynamic constant loses static bootstrap arguments ------------- Commit messages: - Remove extra new line - Copy static bootstrap arguments Changes: https://git.openjdk.org/jdk/pull/13021/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13021&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304148 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13021.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13021/head:pull/13021 PR: https://git.openjdk.org/jdk/pull/13021 From duke at openjdk.org Tue Mar 14 15:57:37 2023 From: duke at openjdk.org (liach) Date: Tue, 14 Mar 2023 15:57:37 GMT Subject: RFR: 8304148: Remapping a class with Invokedynamic constant loses static bootstrap arguments In-Reply-To: References: Message-ID: On Tue, 14 Mar 2023 14:51:34 GMT, Thiago Henrique H?pner wrote: > 8304148: Remapping a class with Invokedynamic constant loses static bootstrap arguments Created a JBS issue for you at https://bugs.openjdk.org/browse/JDK-8304148 ------------- PR: https://git.openjdk.org/jdk/pull/13021 From dnsimon at openjdk.org Tue Mar 14 16:06:06 2023 From: dnsimon at openjdk.org (Doug Simon) Date: Tue, 14 Mar 2023 16:06:06 GMT Subject: RFR: 8303431: [JVMCI] libgraal annotation API [v6] In-Reply-To: References: Message-ID: <0hYs21V1ZWB8o92CfvkEW3i0dZKkeW8kYGQu0p6xvtM=.e76da2cd-dbe5-4da2-a6cb-775f081b9a6a@github.com> > This PR extends JVMCI with new API (`jdk.vm.ci.meta.Annotated`) for accessing annotations. The main differences from `java.lang.reflect.AnnotatedElement` are: > * Each `Annotated` method explicitly specifies the annotation type(s) for which it wants annotation data. That is, there is no direct equivalent of `AnnotatedElement.getAnnotations()`. > * Annotation data is returned in a map-like object (of type `jdk.vm.ci.meta.AnnotationData`) instead of in an `Annotation` object. This works better for libgraal as it avoids the need for annotation types to be loaded and included in libgraal. > > To demonstrate the new API, here's an example in terms `java.lang.reflect.AnnotatedElement` (which `ResolvedJavaType` implements): > > ResolvedJavaMethod method = ...; > ExplodeLoop a = method.getAnnotation(ExplodeLoop.class); > return switch (a.kind()) { > case FULL_UNROLL -> LoopExplosionKind.FULL_UNROLL; > case FULL_UNROLL_UNTIL_RETURN -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN; > ... > } > > > The same code using the new API: > > > ResolvedJavaMethod method = ...; > ResolvedJavaType explodeLoopType = ...; > AnnotationData a = method.getAnnotationDataFor(explodeLoopType); > return switch (a.getEnum("kind").getName()) { > case "FULL_UNROLL" -> LoopExplosionKind.FULL_UNROLL; > case "FULL_UNROLL_UNTIL_RETURN" -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN; > ... > } > > > The implementation relies on new methods in `jdk.internal.vm.VMSupport` for parsing annotations and serializing/deserializing to/from a byte array. This allows the annotation data to be passed from the HotSpot heap to the libgraal heap. Doug Simon has updated the pull request incrementally with one additional commit since the last revision: addressed review feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12810/files - new: https://git.openjdk.org/jdk/pull/12810/files/a85fa13a..abaf2375 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12810&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12810&range=04-05 Stats: 10 lines in 2 files changed: 0 ins; 9 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12810.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12810/head:pull/12810 PR: https://git.openjdk.org/jdk/pull/12810 From duke at openjdk.org Tue Mar 14 17:02:44 2023 From: duke at openjdk.org (liach) Date: Tue, 14 Mar 2023 17:02:44 GMT Subject: RFR: 8294972: Convert jdk.jlink internal plugins to use the Classfile API [v6] In-Reply-To: References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> Message-ID: On Tue, 14 Mar 2023 15:27:50 GMT, Adam Sotona wrote: >> jdk.jlink internal plugins are heavily using ASM >> >> This patch converts ASM calls to Classfile API. >> >> Please review. >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with three additional commits since the last revision: > > - long lines wrapped > - StripJavaDebugAttributesPlugin transformation fixed > - VersionPropsPlugin transformation fixed src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 614: > 612: private void genConstructor(ClassBuilder clb) { > 613: clb.withMethod("", MethodTypeDesc.of(CD_void), > 614: ACC_PUBLIC, mb -> mb.withFlags(ACC_PUBLIC).withCode( cob -> { Why `withFlags(ACC_PUBLIC)` when the flags is already given in `withMethod`'s 3rd argument? Same for occurrences below. src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 615: > 613: clb.withMethod("", MethodTypeDesc.of(CD_void), > 614: ACC_PUBLIC, mb -> mb.withFlags(ACC_PUBLIC).withCode( cob -> { > 615: cob.loadInstruction(TypeKind.ReferenceType, 0); What's the basis for using `loadInstruction(ReferenceType, 0)` over `aload(0)`, etc.? I think, at least for constructors, we won't have other TypeKinds, so we can safely use `aload(0)` `return_()`, and this is what the original ASM code used. src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 894: > 892: // use Set.of(Object[]) when there are more than 2 elements > 893: // use Set.of(Object) or Set.of(Object, Object) when fewer > 894: if (size > 2) { Set.of can take up to 10 arguments, but this may be off topic. src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 916: > 914: sb.append("Ljava/lang/Object;"); > 915: } > 916: sb.append(")Ljava/util/Set;"); The construction of the Set.of method type should move away from StringBuilder. It can be as: var mtdArgs = new ClassDesc[size]; Arrays.fill(mtdArgs, CD_Object); MethodTypeDesc mtd = MethodTypeDesc.of(CD_Set, mtdArgs); ------------- PR: https://git.openjdk.org/jdk/pull/12944 From duke at openjdk.org Tue Mar 14 17:12:59 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Tue, 14 Mar 2023 17:12:59 GMT Subject: RFR: 8303018: Unicode Emoji Properties [v2] In-Reply-To: References: Message-ID: On Tue, 14 Mar 2023 15:49:56 GMT, Naoto Sato wrote: >> Proposing accessor methods to Emoji properties defined in [Unicode Technical Standard #51](https://unicode.org/reports/tr51/) in `java.lang.Character` class. This is per a request from the client group, as well as refining the currently existing ad-hoc emoji implementation in regex. A CSR has also been drafted, and I would appreciate reviews for it too. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Fixed method descriptions make/jdk/src/classes/build/tools/generatecharacter/GenerateCharacter.java line 215: > 213: maskEmojiComponent = 0x040000000000L, > 214: maskExtendedPictographic = 0x080000000000L; > 215: Would be nice the have the '=' aligned in the same column as the ones above, or at least have the emoji ones align with each other. ------------- PR: https://git.openjdk.org/jdk/pull/13006 From mchung at openjdk.org Tue Mar 14 17:14:24 2023 From: mchung at openjdk.org (Mandy Chung) Date: Tue, 14 Mar 2023 17:14:24 GMT Subject: RFR: 8294962: Convert java.base/jdk.internal.module package to use the Classfile API to modify and write module-info.class [v6] In-Reply-To: <0GZplW4gyCygkZwU4DTw6IX1vKOMXZ0PfIIFgdUSG2k=.d7f7225b-ff8e-4f8e-8f9c-36d3a45cc031@github.com> References: <0GZplW4gyCygkZwU4DTw6IX1vKOMXZ0PfIIFgdUSG2k=.d7f7225b-ff8e-4f8e-8f9c-36d3a45cc031@github.com> Message-ID: On Tue, 14 Mar 2023 15:47:33 GMT, Adam Sotona wrote: >> 8294962: java.base jdk.internal.module package uses ASM to modify and write module-info.class. >> This patch converts it to use Classfile API. >> >> Please review. >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > fixed formatting src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java line 150: > 148: // packages > 149: var packages = md.packages().stream().sorted().map(PackageDesc::of).toList(); > 150: if (!packages.isEmpty()) { This check should be `if (md.packages().size() > exportedOrOpen)` or a bug in ModuleInfoWriter? ------------- PR: https://git.openjdk.org/jdk/pull/11368 From duke at openjdk.org Tue Mar 14 17:20:11 2023 From: duke at openjdk.org (liach) Date: Tue, 14 Mar 2023 17:20:11 GMT Subject: RFR: 8304161: Add TypeKind.from to derive from TypeDescriptor.OfField Message-ID: Such an API allows creating TypeKind from both Class and ClassDesc than having to call descriptorString() explicitly at every use site. See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000240.html for context. Upgraded usages of `fromDescriptor` to `from` in applicable use sites in Classfile API and its tests. ------------- Commit messages: - 8304161: Add TypeKind.from to derive from TypeDescriptor.OfField Changes: https://git.openjdk.org/jdk/pull/13024/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13024&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304161 Stats: 17 lines in 6 files changed: 10 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/13024.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13024/head:pull/13024 PR: https://git.openjdk.org/jdk/pull/13024 From djelinski at openjdk.org Tue Mar 14 17:22:18 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 14 Mar 2023 17:22:18 GMT Subject: Integrated: 8303814: getLastErrorString should avoid charset conversions In-Reply-To: References: Message-ID: On Wed, 8 Mar 2023 11:30:27 GMT, Daniel Jeli?ski wrote: > This patch modifies the `getLastErrorString` method to return a `jstring`. Thanks to that we can avoid unnecessary back and forth conversions between Unicode and other charsets on Windows. > > Other changes include: > - the Windows implementation of `getLastErrorString` no longer checks `errno`. I verified all uses of the method and confirmed that `errno` is not used anywhere. > - While at it, I found and fixed a few calls to `JNU_ThrowIOExceptionWithLastError` that were done in context where `LastError` was not set. > - jdk.hotspot.agent was modified to use `JNU_ThrowByNameWithLastError` and `JNU_ThrowByName` instead of `getLastErrorString`; the code is expected to have identical behavior. > - zip_util was modified to return static messages instead of generated ones. The generated messages were not observed anywhere, because they were replaced by a static message in ZIP_Open, which is the only method used by other native code. > - `getLastErrorString` is no longer exported by libjava. > > Tier1-3 tests continue to pass. > > No new automated regression test; testing this requires installing a language pack that cannot be displayed in the current code page. > Tested this manually by installing Chinese language pack on English Windows 11, selecting Chinese language, then checking if the message on exception thrown by `InetAddress.getByName("nonexistent.local");` starts with `"?????????"` (or `"\u4e0d\u77e5\u9053\u8fd9\u6837\u7684\u4e3b\u673a\u3002"`). Without the change, the exception message started with a row of question marks. This pull request has now been integrated. Changeset: baf11e73 Author: Daniel Jeli?ski URL: https://git.openjdk.org/jdk/commit/baf11e734f7b5308490edc74f3168744c0857b24 Stats: 151 lines in 8 files changed: 21 ins; 44 del; 86 mod 8303814: getLastErrorString should avoid charset conversions Reviewed-by: naoto, cjplummer, rriggs ------------- PR: https://git.openjdk.org/jdk/pull/12922 From alanb at openjdk.org Tue Mar 14 17:23:32 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 14 Mar 2023 17:23:32 GMT Subject: RFR: 8294962: Convert java.base/jdk.internal.module package to use the Classfile API to modify and write module-info.class [v6] In-Reply-To: References: <0GZplW4gyCygkZwU4DTw6IX1vKOMXZ0PfIIFgdUSG2k=.d7f7225b-ff8e-4f8e-8f9c-36d3a45cc031@github.com> Message-ID: On Tue, 14 Mar 2023 17:10:07 GMT, Mandy Chung wrote: >> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed formatting > > src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java line 150: > >> 148: // packages >> 149: var packages = md.packages().stream().sorted().map(PackageDesc::of).toList(); >> 150: if (!packages.isEmpty()) { > > This check should be `if (md.packages().size() > exportedOrOpen)` or a bug in ModuleInfoWriter? An oddity in ModuleInfoWriter that I think dates from when a prototype version of this attribute contains the set of concealed packages. There's no need for ModuleInfoWriter to emit the ModulePackages attribute, Adam has chosen to have it emit it. It has implications for one test for ModuleDescriptor.read, and he's changed that. ------------- PR: https://git.openjdk.org/jdk/pull/11368 From mchung at openjdk.org Tue Mar 14 17:23:33 2023 From: mchung at openjdk.org (Mandy Chung) Date: Tue, 14 Mar 2023 17:23:33 GMT Subject: RFR: 8294962: Convert java.base/jdk.internal.module package to use the Classfile API to modify and write module-info.class [v6] In-Reply-To: References: <0GZplW4gyCygkZwU4DTw6IX1vKOMXZ0PfIIFgdUSG2k=.d7f7225b-ff8e-4f8e-8f9c-36d3a45cc031@github.com> Message-ID: On Tue, 14 Mar 2023 17:17:10 GMT, Alan Bateman wrote: >> src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java line 150: >> >>> 148: // packages >>> 149: var packages = md.packages().stream().sorted().map(PackageDesc::of).toList(); >>> 150: if (!packages.isEmpty()) { >> >> This check should be `if (md.packages().size() > exportedOrOpen)` or a bug in ModuleInfoWriter? > > An oddity in ModuleInfoWriter that I think dates from when a prototype version of this attribute contains the set of concealed packages. There's no need for ModuleInfoWriter to emit the ModulePackages attribute, Adam has chosen to have it emit it. It has implications for one test for ModuleDescriptor.read, and he's changed that. Ok. We should move this out to the test library as you suggested since it's only used by the tests. I will create a JBS issue for it. ------------- PR: https://git.openjdk.org/jdk/pull/11368 From mchung at openjdk.org Tue Mar 14 17:23:29 2023 From: mchung at openjdk.org (Mandy Chung) Date: Tue, 14 Mar 2023 17:23:29 GMT Subject: RFR: 8294962: Convert java.base/jdk.internal.module package to use the Classfile API to modify and write module-info.class [v6] In-Reply-To: <0GZplW4gyCygkZwU4DTw6IX1vKOMXZ0PfIIFgdUSG2k=.d7f7225b-ff8e-4f8e-8f9c-36d3a45cc031@github.com> References: <0GZplW4gyCygkZwU4DTw6IX1vKOMXZ0PfIIFgdUSG2k=.d7f7225b-ff8e-4f8e-8f9c-36d3a45cc031@github.com> Message-ID: On Tue, 14 Mar 2023 15:47:33 GMT, Adam Sotona wrote: >> 8294962: java.base jdk.internal.module package uses ASM to modify and write module-info.class. >> This patch converts it to use Classfile API. >> >> Please review. >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > fixed formatting Looks good to me. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.org/jdk/pull/11368 From alanb at openjdk.org Tue Mar 14 17:29:06 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 14 Mar 2023 17:29:06 GMT Subject: RFR: 8303018: Unicode Emoji Properties [v2] In-Reply-To: References: Message-ID: On Tue, 14 Mar 2023 15:43:13 GMT, Naoto Sato wrote: > Fixed this one as well Spec update looks good. I suppose I have to use an emoji to react to that ? ------------- PR: https://git.openjdk.org/jdk/pull/13006 From duke at openjdk.org Tue Mar 14 17:34:32 2023 From: duke at openjdk.org (ExE Boss) Date: Tue, 14 Mar 2023 17:34:32 GMT Subject: RFR: 8304031: Classfile API cannot encode Primitive Class as Condy In-Reply-To: <6SEB6ZAh2b0ayMCo5EfvOW-adtsAysbf1Zk6qBbh2SI=.96417080-f2a8-424d-9a26-0ed68f6b33ac@github.com> References: <6SEB6ZAh2b0ayMCo5EfvOW-adtsAysbf1Zk6qBbh2SI=.96417080-f2a8-424d-9a26-0ed68f6b33ac@github.com> Message-ID: On Mon, 13 Mar 2023 08:13:44 GMT, liach wrote: > Without this patch, the Classfile API tries to encode PrimitiveClassDesc as CONSTANT_Class_info and error in `toInternalName`. I?meant?that `instanceof?DynamicConstantDesc` would?go?after concrete?classes (`Integer`, `Long`, `Float`, `Double`, and?`String`), but?before the?`ConstantDesc`?interfaces. ------------- PR: https://git.openjdk.org/jdk/pull/12996 From duke at openjdk.org Tue Mar 14 17:40:50 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Tue, 14 Mar 2023 17:40:50 GMT Subject: RFR: 8303018: Unicode Emoji Properties [v2] In-Reply-To: References: Message-ID: On Tue, 14 Mar 2023 15:49:56 GMT, Naoto Sato wrote: >> Proposing accessor methods to Emoji properties defined in [Unicode Technical Standard #51](https://unicode.org/reports/tr51/) in `java.lang.Character` class. This is per a request from the client group, as well as refining the currently existing ad-hoc emoji implementation in regex. A CSR has also been drafted, and I would appreciate reviews for it too. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Fixed method descriptions Would it make sense to add something like the following to `GenerateCharacter.propertiesComments`? if ((val & maskEmoji) == maskEmoji) { result.append(", emoji "); } if ((val & maskEmojiPresentation) == maskEmojiPresentation) { result.append(", emojiPresentation "); } if ((val & maskEmojiModifier) == maskEmojiModifier) { result.append(", emojiModifier "); } if ((val & maskEmojiModifierBase) == maskEmojiModifierBase) { result.append(", emojiModifierBase "); } if ((val & maskEmojiComponent) == maskEmojiComponent) { result.append(", emojiComponent "); } if ((val & maskExtendedPictographic) == maskExtendedPictographic) { result.append(", extendedPictographic "); } This updates the comments of the B table to something like this sample: 0x0000, // 34 unassigned, L 0x0440, // 35 unassigned, L, emoji , emojiComponent 0x0000, // 36 unassigned, L ------------- PR: https://git.openjdk.org/jdk/pull/13006 From jwaters at openjdk.org Tue Mar 14 17:50:01 2023 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 14 Mar 2023 17:50:01 GMT Subject: RFR: 8303814: getLastErrorString should avoid charset conversions [v3] In-Reply-To: References: Message-ID: On Mon, 13 Mar 2023 15:55:27 GMT, Daniel Jeli?ski wrote: >> This patch modifies the `getLastErrorString` method to return a `jstring`. Thanks to that we can avoid unnecessary back and forth conversions between Unicode and other charsets on Windows. >> >> Other changes include: >> - the Windows implementation of `getLastErrorString` no longer checks `errno`. I verified all uses of the method and confirmed that `errno` is not used anywhere. >> - While at it, I found and fixed a few calls to `JNU_ThrowIOExceptionWithLastError` that were done in context where `LastError` was not set. >> - jdk.hotspot.agent was modified to use `JNU_ThrowByNameWithLastError` and `JNU_ThrowByName` instead of `getLastErrorString`; the code is expected to have identical behavior. >> - zip_util was modified to return static messages instead of generated ones. The generated messages were not observed anywhere, because they were replaced by a static message in ZIP_Open, which is the only method used by other native code. >> - `getLastErrorString` is no longer exported by libjava. >> >> Tier1-3 tests continue to pass. >> >> No new automated regression test; testing this requires installing a language pack that cannot be displayed in the current code page. >> Tested this manually by installing Chinese language pack on English Windows 11, selecting Chinese language, then checking if the message on exception thrown by `InetAddress.getByName("nonexistent.local");` starts with `"?????????"` (or `"\u4e0d\u77e5\u9053\u8fd9\u6837\u7684\u4e3b\u673a\u3002"`). Without the change, the exception message started with a row of question marks. > > Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: > > Use NULL where appropriate The change in Windows behaviour seems like a worrying gotcha that someone using the method might be trapped by (C library errors and system errors are reported for Unix while only WINAPI is returned on Windows). Although this has already been pushed I'd still like to mention that me and Thomas did have quite a bit of discussion regarding the conundrum on Windows about whether to report both when the error routines are called or have separate methods/mechanism to select either, see [8292016](https://bugs.openjdk.org/browse/JDK-8292016?filter=-1) ------------- PR: https://git.openjdk.org/jdk/pull/12922 From mchung at openjdk.org Tue Mar 14 18:04:14 2023 From: mchung at openjdk.org (Mandy Chung) Date: Tue, 14 Mar 2023 18:04:14 GMT Subject: RFR: 8294972: Convert jdk.jlink internal plugins to use the Classfile API [v4] In-Reply-To: References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> Message-ID: On Tue, 14 Mar 2023 15:22:04 GMT, Adam Sotona wrote: >> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/StripJavaDebugAttributesPlugin.java line 62: >> >>> 60: // XXX. Do we have debug info? Is Asm ready for module-info? >>> 61: } else { >>> 62: byte[] content = newClassReader(path, resource, Classfile.Option.processDebug(false)) >> >> ASM `ClassReader.SKIP_DEBUG` flag indicates to skip the SourceFile, SourceDebugExtension, LocalVariableTable, LocalVariableTypeTable, LineNumberTable and MethodParameters attributes. >> >> `Classfile.Option.processDebug(false)` only skips LocalVariableTable, LocalVariableTypeTable, CHARACTER_RANGE_TABLE attributes. To implement the same behavior as `SKIP_DEBUG`, it needs `Classfile.Option.processLineNumbers(false)` and skipping other attributes. > > Right, I'll fix it, thanks. Looks like `LineNumberTable` is not stripped even with `Option.processLineNumbers(false)`. ------------- PR: https://git.openjdk.org/jdk/pull/12944 From rriggs at openjdk.org Tue Mar 14 18:08:08 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 14 Mar 2023 18:08:08 GMT Subject: RFR: 8303392: Runtime.exec and ProcessBuilder.start should use System logger [v7] In-Reply-To: <-1i11ZrHHgzUbCSa_RXAcGKNfgtpdui--bltZ4Ujs2A=.f5f1a7e2-d3ec-4f64-9b1e-317ef2f24ef1@github.com> References: <-1i11ZrHHgzUbCSa_RXAcGKNfgtpdui--bltZ4Ujs2A=.f5f1a7e2-d3ec-4f64-9b1e-317ef2f24ef1@github.com> Message-ID: > Runtime.exec and ProcessBuilder.start methods create a new operating system process with the program and arguments. Many applications configure a logging subsystem to monitor application events. Logging a process start message with the program, arguments, and stack trace can identify the caller and purpose. > Logging the process start event is complementary to the process start event generated for JFR (Java Flight Recorder). Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Remove dead code and whitespace removal. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12862/files - new: https://git.openjdk.org/jdk/pull/12862/files/47c3ab63..32f05be9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12862&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12862&range=05-06 Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12862.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12862/head:pull/12862 PR: https://git.openjdk.org/jdk/pull/12862 From djelinski at openjdk.org Tue Mar 14 18:20:17 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 14 Mar 2023 18:20:17 GMT Subject: RFR: 8303814: getLastErrorString should avoid charset conversions [v3] In-Reply-To: References: Message-ID: On Mon, 13 Mar 2023 15:55:27 GMT, Daniel Jeli?ski wrote: >> This patch modifies the `getLastErrorString` method to return a `jstring`. Thanks to that we can avoid unnecessary back and forth conversions between Unicode and other charsets on Windows. >> >> Other changes include: >> - the Windows implementation of `getLastErrorString` no longer checks `errno`. I verified all uses of the method and confirmed that `errno` is not used anywhere. >> - While at it, I found and fixed a few calls to `JNU_ThrowIOExceptionWithLastError` that were done in context where `LastError` was not set. >> - jdk.hotspot.agent was modified to use `JNU_ThrowByNameWithLastError` and `JNU_ThrowByName` instead of `getLastErrorString`; the code is expected to have identical behavior. >> - zip_util was modified to return static messages instead of generated ones. The generated messages were not observed anywhere, because they were replaced by a static message in ZIP_Open, which is the only method used by other native code. >> - `getLastErrorString` is no longer exported by libjava. >> >> Tier1-3 tests continue to pass. >> >> No new automated regression test; testing this requires installing a language pack that cannot be displayed in the current code page. >> Tested this manually by installing Chinese language pack on English Windows 11, selecting Chinese language, then checking if the message on exception thrown by `InetAddress.getByName("nonexistent.local");` starts with `"?????????"` (or `"\u4e0d\u77e5\u9053\u8fd9\u6837\u7684\u4e3b\u673a\u3002"`). Without the change, the exception message started with a row of question marks. > > Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: > > Use NULL where appropriate we never use any of the JNU_XXX functions to report errno on Windows as far as I could tell. And even if we did, we'd need to call SetLastError(0) before JNU_Throw to make it work, which we never did. I think we're ok here. ------------- PR: https://git.openjdk.org/jdk/pull/12922 From rriggs at openjdk.org Tue Mar 14 18:21:33 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 14 Mar 2023 18:21:33 GMT Subject: RFR: 8303485: Replacing os.name for operating system customization [v4] In-Reply-To: References: Message-ID: > Improvements to support OS specific customization for JDK internal use: > - To select values and code; allowing elimination of unused code and values > - Optionally evaluated by build processes, compilation, or archiving (i.e. CDS) > - Simple API to replace adhoc comparisons with `os.name` > - Clear and consistent use across build, runtime, and JDK modules > > The PR includes updates within java.base to use the new API. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Cover default case in switch on OS. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12931/files - new: https://git.openjdk.org/jdk/pull/12931/files/be27adb0..ead84379 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12931&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12931&range=02-03 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12931.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12931/head:pull/12931 PR: https://git.openjdk.org/jdk/pull/12931 From rriggs at openjdk.org Tue Mar 14 18:21:36 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 14 Mar 2023 18:21:36 GMT Subject: RFR: 8303485: Replacing os.name for operating system customization [v3] In-Reply-To: References: <6dSxY-deX1RXY46V7U4snk2q5o5j8OkfMwVfAEQU_-k=.1a44c94e-0ccb-4e95-915e-3b83ec1bf88b@github.com> Message-ID: On Tue, 14 Mar 2023 15:04:47 GMT, Alan Bateman wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix indentation and improve exception message > > src/java.base/share/classes/jdk/internal/util/OperatingSystem.java line 29: > >> 27: >> 28: /** >> 29: * Enumeration of operating system types and testing for the current OS. > > Would it be more correct to say an enumerating of operating system names rather than types? It is more OS type or kind than name; there are multiple distros that are Linux, i.e. Ubuntu, Fedora, Oracle Linux, etc.. It is not equivalent to `os.name`. ------------- PR: https://git.openjdk.org/jdk/pull/12931 From duke at openjdk.org Tue Mar 14 18:30:40 2023 From: duke at openjdk.org (liach) Date: Tue, 14 Mar 2023 18:30:40 GMT Subject: RFR: 8304031: Classfile API cannot encode Primitive Class as Condy In-Reply-To: References: <6SEB6ZAh2b0ayMCo5EfvOW-adtsAysbf1Zk6qBbh2SI=.96417080-f2a8-424d-9a26-0ed68f6b33ac@github.com> Message-ID: On Tue, 14 Mar 2023 17:32:00 GMT, ExE Boss wrote: > I?meant?that `instanceof?DynamicConstantDesc` would?go?after concrete?classes (`Integer`, `Long`, `Float`, `Double`, and?`String`), but?before the?`ConstantDesc`?interfaces. Still not feasible to make ReferenceClassDescImpl to go through all these previous instanceof checks. ------------- PR: https://git.openjdk.org/jdk/pull/12996 From duke at openjdk.org Tue Mar 14 18:31:54 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Tue, 14 Mar 2023 18:31:54 GMT Subject: RFR: 8303485: Replacing os.name for operating system customization [v3] In-Reply-To: References: <6dSxY-deX1RXY46V7U4snk2q5o5j8OkfMwVfAEQU_-k=.1a44c94e-0ccb-4e95-915e-3b83ec1bf88b@github.com> Message-ID: On Tue, 14 Mar 2023 18:15:46 GMT, Roger Riggs wrote: >> src/java.base/share/classes/jdk/internal/util/OperatingSystem.java line 29: >> >>> 27: >>> 28: /** >>> 29: * Enumeration of operating system types and testing for the current OS. >> >> Would it be more correct to say an enumerating of operating system names rather than types? > > It is more OS type or kind than name; there are multiple distros that are Linux, i.e. Ubuntu, Fedora, Oracle Linux, etc.. > It is not equivalent to `os.name`. 'Operating system families' seems well-established ? https://en.wikipedia.org/wiki/Category:Operating_system_families ------------- PR: https://git.openjdk.org/jdk/pull/12931 From mdoerr at openjdk.org Tue Mar 14 20:33:34 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 14 Mar 2023 20:33:34 GMT Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function & Memory API (Preview) [v15] In-Reply-To: References: Message-ID: > Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification". > > This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `` (2.2.4 Variable Argument Lists). > > Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only. > > There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Will get addressed separately: [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017) > > The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests. > > I had to make changes to shared code and code for other platforms: > 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons: > - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that. > - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64. > - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian! > 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit. Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: Allow TestHFA to run on musl. Add Upcalls. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12708/files - new: https://git.openjdk.org/jdk/pull/12708/files/2e4e269e..364a84ed Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=13-14 Stats: 208 lines in 2 files changed: 204 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/12708.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12708/head:pull/12708 PR: https://git.openjdk.org/jdk/pull/12708 From mdoerr at openjdk.org Tue Mar 14 20:33:40 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 14 Mar 2023 20:33:40 GMT Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function & Memory API (Preview) [v14] In-Reply-To: References: Message-ID: On Mon, 13 Mar 2023 14:31:19 GMT, Jorn Vernee wrote: >> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: >> >> Introduce ABIv2CallArranger for linux ppc64le. > > test/jdk/java/foreign/TestHFA.java line 32: > >> 30: * @enablePreview >> 31: * @requires ((os.arch == "amd64" | os.arch == "x86_64") & sun.arch.data.model == "64") | os.arch == "aarch64" | os.arch == "ppc64le" | os.arch == "riscv64" >> 32: * @requires !vm.musl > > Not sure if this test should be disabled on musl? Changed with https://github.com/openjdk/jdk/pull/12708/commits/364a84edc416abd5f1318f78057c92720fe96990. Plus added Upcalls. ------------- PR: https://git.openjdk.org/jdk/pull/12708 From rriggs at openjdk.org Tue Mar 14 21:46:46 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 14 Mar 2023 21:46:46 GMT Subject: RFR: 8303018: Unicode Emoji Properties [v2] In-Reply-To: References: Message-ID: On Tue, 14 Mar 2023 15:49:56 GMT, Naoto Sato wrote: >> Proposing accessor methods to Emoji properties defined in [Unicode Technical Standard #51](https://unicode.org/reports/tr51/) in `java.lang.Character` class. This is per a request from the client group, as well as refining the currently existing ad-hoc emoji implementation in regex. A CSR has also been drafted, and I would appreciate reviews for it too. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Fixed method descriptions Looks good. There are opportunities to modernize the code, but maybe separately. make/jdk/src/classes/build/tools/generatecharacter/EmojiData.java line 99: > 97: case "Emoji_Component" -> EMOJI_COMPONENT; > 98: case "Extended_Pictographic" -> EXTENDED_PICTOGRAPHIC; > 99: default -> throw new InternalError(); It would be useful to include the "type" as the exception argument. It give some idea as to the corruption or missing case. make/jdk/src/classes/build/tools/generatecharacter/GenerateCharacter.java line 214: > 212: maskEmojiModifierBase = 0x020000000000L, > 213: maskEmojiComponent = 0x040000000000L, > 214: maskExtendedPictographic = 0x080000000000L; It would be good to leverage a common definition (perhaps a bit number) here and in EmojiData.java and build the constants with <<< shifts. make/jdk/src/classes/build/tools/generatecharacter/GenerateCharacter.java line 810: > 808: if (x.equals("maskEmojiModifierBase")) return "0x" + hex4(maskEmojiModifierBase >> 32); > 809: if (x.equals("maskEmojiComponent")) return "0x" + hex4(maskEmojiComponent >> 32); > 810: if (x.equals("maskExtendedPictographic")) return "0x" + hex4(maskExtendedPictographic >> 32); An upgrade would be to modify hex4(), hexNN() to use `HexFormat.of().toUpperCase().toHexDigits((short)xxx)` The HexFormat is reusable and would avoid creating extra strings. Perhaps also create a method that combines the repetitive shift and prefixing. This if...then... sequence could be an expression switch (x) {...}. ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.org/jdk/pull/13006 From jlu at openjdk.org Tue Mar 14 22:25:22 2023 From: jlu at openjdk.org (Justin Lu) Date: Tue, 14 Mar 2023 22:25:22 GMT Subject: RFR: 8225641: Calendar.roll(int field) does not work correctly for WEEK_OF_YEAR Message-ID: This PR fixes the bug which occurred when `Calendar.roll(WEEK_OF_YEAR)` rolled into a minimal first week with an invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo. For example, Rolling _Monday, 30 December 2019_ by 1 week produced _Monday, 31 December 2018_, which is incorrect. This is because `WEEK_OF_YEAR` is rolled from 52 to 1, and the original `DAY_OF_WEEK` is 1. However, there is no Monday in week 1 of 2019. This is exposed when a future method calls `Calendar.complete()`, which eventually calculates a `fixedDate` with the invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo. To prevent this, a check is added for rolls into week 1, which determines if the first week is minimal. If it is indeed minimal, then it is checked if `DAY_OF_WEEK` exists in that week, if not, `WEEK_OF_YEAR` must be incremented by one. After the fix, Rolling _Monday, 30 December 2019_ by 1 week produces _Monday, 7 January 2019_ ------------- Commit messages: - method positioning - Bug fix to GregCal with accompanying test Changes: https://git.openjdk.org/jdk/pull/13031/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13031&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8225641 Stats: 167 lines in 2 files changed: 165 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13031.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13031/head:pull/13031 PR: https://git.openjdk.org/jdk/pull/13031 From mdoerr at openjdk.org Tue Mar 14 22:30:22 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 14 Mar 2023 22:30:22 GMT Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function & Memory API (Preview) [v16] In-Reply-To: References: Message-ID: > Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification". > > This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `` (2.2.4 Variable Argument Lists). > > Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only. > > There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Will get addressed separately: [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017) > > The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests. > > I had to make changes to shared code and code for other platforms: > 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons: > - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that. > - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64. > - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian! > 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit. Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: Fix storing 32 bit integers into Java frames. Enable TestArrayStructs. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12708/files - new: https://git.openjdk.org/jdk/pull/12708/files/364a84ed..9173af20 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=14-15 Stats: 14 lines in 2 files changed: 5 ins; 3 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/12708.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12708/head:pull/12708 PR: https://git.openjdk.org/jdk/pull/12708 From mdoerr at openjdk.org Tue Mar 14 22:34:47 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 14 Mar 2023 22:34:47 GMT Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function & Memory API (Preview) [v16] In-Reply-To: References: Message-ID: On Tue, 14 Mar 2023 22:30:22 GMT, Martin Doerr wrote: >> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification". >> >> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `` (2.2.4 Variable Argument Lists). >> >> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only. >> >> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Will get addressed separately: [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017) >> >> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests. >> >> I had to make changes to shared code and code for other platforms: >> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons: >> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that. >> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64. >> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian! >> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit. > > Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: > > Fix storing 32 bit integers into Java frames. Enable TestArrayStructs. Thanks for the hint. Using `jshell` is a good idea. { callerMethodType: (long,int,int,int,int,int,int,int,int)long calleeMethodType: (MemorySegment,byte,byte,byte,byte,byte,byte,byte,byte)MemorySegment FunctionDescriptor: ([[8:b8]]b8b8b8b8b8b8b8b8)[[8:b8]] Argument Bindings: 0: [Allocate[size=8, alignment=1], Dup[], VMLoad[storage=VMStorage[type=0, segmentMaskOrSize=3, indexOrOffset=3, debugName=r3], type=long], BufferStore[offset=0, type=long, byteWidth=8]] 1: [VMLoad[storage=VMStorage[type=0, segmentMaskOrSize=3, indexOrOffset=4, debugName=r4], type=int], INT_TO_BYTE] 2: [VMLoad[storage=VMStorage[type=0, segmentMaskOrSize=3, indexOrOffset=5, debugName=r5], type=int], INT_TO_BYTE] 3: [VMLoad[storage=VMStorage[type=0, segmentMaskOrSize=3, indexOrOffset=6, debugName=r6], type=int], INT_TO_BYTE] 4: [VMLoad[storage=VMStorage[type=0, segmentMaskOrSize=3, indexOrOffset=7, debugName=r7], type=int], INT_TO_BYTE] 5: [VMLoad[storage=VMStorage[type=0, segmentMaskOrSize=3, indexOrOffset=8, debugName=r8], type=int], INT_TO_BYTE] 6: [VMLoad[storage=VMStorage[type=0, segmentMaskOrSize=3, indexOrOffset=9, debugName=r9], type=int], INT_TO_BYTE] 7: [VMLoad[storage=VMStorage[type=0, segmentMaskOrSize=3, indexOrOffset=10, debugName=r10], type=int], INT_TO_BYTE] 8: [VMLoad[storage=VMStorage[type=2, segmentMaskOrSize=8, indexOrOffset=64, debugName=Stack at 64], type=int], INT_TO_BYTE] Return: [BufferLoad[offset=0, type=long, byteWidth=8], VMStore[storage=VMStorage[type=0, segmentMaskOrSize=3, indexOrOffset=3, debugName=r3], type=long]] } I have fixed the issue and enabled the test. My code still contained an old assumption which doesn't hold for the cases I had implemented more recently. So, this PR is probably complete. I'll rerun tests and wait for 2 reviews. ------------- PR: https://git.openjdk.org/jdk/pull/12708 From mdoerr at openjdk.org Tue Mar 14 22:55:51 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 14 Mar 2023 22:55:51 GMT Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function & Memory API (Preview) [v16] In-Reply-To: References: Message-ID: On Tue, 14 Mar 2023 22:30:22 GMT, Martin Doerr wrote: >> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification". >> >> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `` (2.2.4 Variable Argument Lists). >> >> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only. >> >> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Will get addressed separately: [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017) >> >> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests. >> >> I had to make changes to shared code and code for other platforms: >> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons: >> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that. >> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64. >> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian! >> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit. > > Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: > > Fix storing 32 bit integers into Java frames. Enable TestArrayStructs. Btw. the new cases in which we use int and short accesses when byteWidth is not a power of 2 are never unaligned AFAICS. I guess _UNALIGNED is unnecessary in the JAVA_INT_UNALIGNED and JAVA_SHORT_UNALIGNED. They are always aligned wrt. to their size. ------------- PR: https://git.openjdk.org/jdk/pull/12708 From duke at openjdk.org Wed Mar 15 02:26:15 2023 From: duke at openjdk.org (liach) Date: Wed, 15 Mar 2023 02:26:15 GMT Subject: RFR: 8304181: Constant Descriptors for MethodHandles::classData and classDataAt Message-ID: Add Constant Descriptors for DirectMethodHandleDesc of MethodHandles::classData and classDataAt in ConstantDescs. This facilitates easier access of class data via condy in Classfile API-generated bytecode. Most other constant bootstrap methods provided in the JDK, notably from `ConstantBootstraps`, already have constant descriptors in ConstantDescs. Context: https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000235.html ------------- Commit messages: - ConstantDescs for MethodHandles.classData and classDataAt Changes: https://git.openjdk.org/jdk/pull/13033/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13033&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304181 Stats: 16 lines in 1 file changed: 16 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13033.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13033/head:pull/13033 PR: https://git.openjdk.org/jdk/pull/13033 From duke at openjdk.org Wed Mar 15 02:37:05 2023 From: duke at openjdk.org (liach) Date: Wed, 15 Mar 2023 02:37:05 GMT Subject: RFR: 8302822: Method/Field/Constructor/RecordComponent::getGenericInfo() is not thread safe [v2] In-Reply-To: <1sDlqlKVNOobyFy71f7ud5uL8_WcMPi1qKNa4ltxFQ0=.63cffbd7-e11a-4d7d-9362-cf215a7584ce@github.com> References: <1sDlqlKVNOobyFy71f7ud5uL8_WcMPi1qKNa4ltxFQ0=.63cffbd7-e11a-4d7d-9362-cf215a7584ce@github.com> Message-ID: > 8302822: Method/Field/Constructor/RecordComponent::getGenericInfo() is not thread safe liach 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: - Make the repositories volatile like in Class - Merge branch 'master' of https://git.openjdk.java.net/jdk into generic-info-thread-safe - Merge branch 'master' of https://git.openjdk.java.net/jdk into generic-info-thread-safe - 8302822: Method/Field/Constructor/RecordComponent::getGenericInfo() is not thread safe ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12643/files - new: https://git.openjdk.org/jdk/pull/12643/files/f8e05eff..85f2f350 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12643&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12643&range=00-01 Stats: 147955 lines in 2252 files changed: 106276 ins; 22901 del; 18778 mod Patch: https://git.openjdk.org/jdk/pull/12643.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12643/head:pull/12643 PR: https://git.openjdk.org/jdk/pull/12643 From duke at openjdk.org Wed Mar 15 02:52:25 2023 From: duke at openjdk.org (liach) Date: Wed, 15 Mar 2023 02:52:25 GMT Subject: RFR: 8302822: Method/Field/Constructor/RecordComponent::getGenericInfo() is not thread safe [v2] In-Reply-To: References: <1sDlqlKVNOobyFy71f7ud5uL8_WcMPi1qKNa4ltxFQ0=.63cffbd7-e11a-4d7d-9362-cf215a7584ce@github.com> Message-ID: On Wed, 15 Mar 2023 02:37:05 GMT, liach wrote: >> 8302822: Method/Field/Constructor/RecordComponent::getGenericInfo() is not thread safe > > liach 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: > > - Make the repositories volatile like in Class > - Merge branch 'master' of https://git.openjdk.java.net/jdk into generic-info-thread-safe > - Merge branch 'master' of https://git.openjdk.java.net/jdk into generic-info-thread-safe > - 8302822: Method/Field/Constructor/RecordComponent::getGenericInfo() is not thread safe I've updated the fields to be volatile. > > I would also be concerned about the guarantee of idempotency from the factory method - I hope its requirements in that area are clearly documented. > > The spec for the getGenericXXX methods are "Return a" rather than "Return the" so there shouldn't be any expectation on identity. The question about idempotency might be worth checking into as the underlying factory for reflective generic type objects does interact with the defining class loader. These objects should always be resolving types with the class loader of the declaring class in [CoreReflectionsFctory::getDeclsLoader](https://github.com/openjdk/jdk/blob/065d3e0d58c96b8a84f3c02bb8704fab6459eaa7/src/java.base/share/classes/sun/reflect/generics/factory/CoreReflectionFactory.java#L61), so the resolved Class instances should be always the same. As far as I see, Type instances are otherwise compared by equals instead of identity, so returning distinct but equal type instances should be safe. ------------- PR: https://git.openjdk.org/jdk/pull/12643 From duke at openjdk.org Wed Mar 15 04:09:04 2023 From: duke at openjdk.org (liach) Date: Wed, 15 Mar 2023 04:09:04 GMT Subject: RFR: 8294977: Convert test/jdk/java tests from ASM library to Classfile API [v2] In-Reply-To: References: Message-ID: > Summaries: > 1. A few recommendations about updating the constant API is made at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000233.html and I may update this patch shall the API changes be integrated before > 2. One ASM library-specific test, `LambdaAsm` is removed. Others have their code generation infrastructure upgraded from ASM to Classfile API. > 3. Most tests are included in tier1, but some are not: > In `:jdk_io`: (tier2, part 2) > > test/jdk/java/io/Serializable/records/SerialPersistentFieldsTest.java > test/jdk/java/io/Serializable/records/ProhibitedMethods.java > test/jdk/java/io/Serializable/records/BadCanonicalCtrTest.java > > In `:jdk_instrument`: (tier 3) > > test/jdk/java/lang/instrument/RetransformAgent.java > test/jdk/java/lang/instrument/NativeMethodPrefixAgent.java > test/jdk/java/lang/instrument/asmlib/Instrumentor.java > > > @asotona Would you mind reviewing? liach has updated the pull request incrementally with one additional commit since the last revision: Shorten lines, move from mask() to ACC_ constants, other misc improvements ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13009/files - new: https://git.openjdk.org/jdk/pull/13009/files/837ea4bb..c6536bf9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13009&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13009&range=00-01 Stats: 196 lines in 19 files changed: 59 ins; 26 del; 111 mod Patch: https://git.openjdk.org/jdk/pull/13009.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13009/head:pull/13009 PR: https://git.openjdk.org/jdk/pull/13009 From lmesnik at openjdk.org Wed Mar 15 05:50:18 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 15 Mar 2023 05:50:18 GMT Subject: RFR: 8303697: ProcessTools doesn't print last line of process output In-Reply-To: <2yj8kBz0HKn3QwV6awfX7bwl1IgBqBiRza-ABtJwCzo=.22255150-b358-4def-88a5-ed2ebc0de129@github.com> References: <2yj8kBz0HKn3QwV6awfX7bwl1IgBqBiRza-ABtJwCzo=.22255150-b358-4def-88a5-ed2ebc0de129@github.com> Message-ID: On Wed, 15 Mar 2023 05:41:33 GMT, Leonid Mesnik wrote: > The StreamPumper is fixed to process the last line even it is not finishes with '\n' or '\r'. The test included. Testing with tier1-3 also to verify that tests are not broken. The ByteArrayOutputStream is moved into try block just to close it as any other stream. Doesn't affect execution. ------------- PR: https://git.openjdk.org/jdk/pull/13034 From lmesnik at openjdk.org Wed Mar 15 05:50:17 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 15 Mar 2023 05:50:17 GMT Subject: RFR: 8303697: ProcessTools doesn't print last line of process output Message-ID: <2yj8kBz0HKn3QwV6awfX7bwl1IgBqBiRza-ABtJwCzo=.22255150-b358-4def-88a5-ed2ebc0de129@github.com> The StreamPumper is fixed to process the last line even it is not finishes with '\n' or '\r'. The test included. Testing with tier1-3 also to verify that tests are not broken. ------------- Commit messages: - fix - 8303697 Changes: https://git.openjdk.org/jdk/pull/13034/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13034&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303697 Stats: 76 lines in 2 files changed: 72 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/13034.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13034/head:pull/13034 PR: https://git.openjdk.org/jdk/pull/13034 From joehw at openjdk.org Wed Mar 15 06:15:49 2023 From: joehw at openjdk.org (Joe Wang) Date: Wed, 15 Mar 2023 06:15:49 GMT Subject: RFR: 8303530: Add system property for custom JAXP configuration file [v3] In-Reply-To: References: Message-ID: <20jsXM6mMBnpiJgrujPSRH-MwrM5YLZAWFq7UzbhjR0=.52269f87-2a5e-4bf4-bf35-f9b1ab594665@github.com> > Add a system property, jdk.xml.config.file, to return the path to a custom JAXP configuration file. The current configuration file, jaxp.properties, that the JDK supports will become the default configuration file. > > CSR: https://bugs.openjdk.org/browse/JDK-8303531 > > Tests: XML SQE and JCK tests passed. Joe Wang has updated the pull request incrementally with one additional commit since the last revision: update config file description; add a general scope and order section; move value definition for external properties to class description ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12985/files - new: https://git.openjdk.org/jdk/pull/12985/files/014d99fd..43407bdc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12985&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12985&range=01-02 Stats: 392 lines in 23 files changed: 112 ins; 175 del; 105 mod Patch: https://git.openjdk.org/jdk/pull/12985.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12985/head:pull/12985 PR: https://git.openjdk.org/jdk/pull/12985 From jpai at openjdk.org Wed Mar 15 06:34:11 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 15 Mar 2023 06:34:11 GMT Subject: RFR: 8304225: Remove javax/script/Test7.java from ProblemList Message-ID: Can I please get a review of this change which removes `javax/script/Test7.java` from the ProblemList? As noted in https://bugs.openjdk.org/browse/JDK-8304225, this test no longer fails and passes just like the other tests in `javax/script` directory with: ----------System.out:(4/60)---------- Test7 Warning: No js engine found; test vacuously passes. With this proposed change, relevant tier testing has been run to verify that the original reported issue which caused this test to be problem listed https://bugs.openjdk.org/browse/JDK-8239361 is no longer seen. ------------- Commit messages: - 8304225: Remove javax/script/Test7.java from ProblemList Changes: https://git.openjdk.org/jdk/pull/13035/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13035&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304225 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13035.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13035/head:pull/13035 PR: https://git.openjdk.org/jdk/pull/13035 From dholmes at openjdk.org Wed Mar 15 06:59:19 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 15 Mar 2023 06:59:19 GMT Subject: RFR: 8303697: ProcessTools doesn't print last line of process output In-Reply-To: <2yj8kBz0HKn3QwV6awfX7bwl1IgBqBiRza-ABtJwCzo=.22255150-b358-4def-88a5-ed2ebc0de129@github.com> References: <2yj8kBz0HKn3QwV6awfX7bwl1IgBqBiRza-ABtJwCzo=.22255150-b358-4def-88a5-ed2ebc0de129@github.com> Message-ID: On Wed, 15 Mar 2023 05:41:33 GMT, Leonid Mesnik wrote: > The StreamPumper is fixed to process the last line even it is not finishes with '\n' or '\r'. The test included. Testing with tier1-3 also to verify that tests are not broken. Not clear on this one sorry. I would have thought the: if (lastcrlf == -1) { was supposed to handle lines without final \n. But I really can't follow this code. test/lib-test/jdk/test/lib/process/ProcessToolsLastLineTest.java line 56: > 54: test("ARG1\nARG2\n"); > 55: test("\nARG1\nARG2\n"); > 56: test("\nARG1\nVERYVERYLONGLINEVERYVERYLONGLINEVERYVERYLONGLINEVERYVERYLONGLINEVERYVERYLONGLINE" + "" + Probably easier/clearer to use String.repeat to create as long a line as you want. ------------- PR: https://git.openjdk.org/jdk/pull/13034 From asotona at openjdk.org Wed Mar 15 07:13:42 2023 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 15 Mar 2023 07:13:42 GMT Subject: Integrated: 8294962: Convert java.base/jdk.internal.module package to use the Classfile API to modify and write module-info.class In-Reply-To: References: Message-ID: <1eP1ruLZF8CtFJRc6e3RziE39I596m1LtXNPXIR-EHA=.5aacd492-c69b-47a1-8541-0770242bbc52@github.com> On Fri, 25 Nov 2022 14:38:55 GMT, Adam Sotona wrote: > 8294962: java.base jdk.internal.module package uses ASM to modify and write module-info.class. > This patch converts it to use Classfile API. > > Please review. > Thanks, > Adam This pull request has now been integrated. Changeset: 714b5f03 Author: Adam Sotona URL: https://git.openjdk.org/jdk/commit/714b5f036fc70d8d1d4d3ec8777fe95cffc0fe5b Stats: 323 lines in 8 files changed: 78 ins; 127 del; 118 mod 8294962: Convert java.base/jdk.internal.module package to use the Classfile API to modify and write module-info.class Reviewed-by: alanb, mchung ------------- PR: https://git.openjdk.org/jdk/pull/11368 From asotona at openjdk.org Wed Mar 15 08:54:08 2023 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 15 Mar 2023 08:54:08 GMT Subject: RFR: 8304164: jdk/classfile/CorpusTest.java still fails after JDK-8303910 Message-ID: <4dGeKShy_LOubsC25eMQQfnOcF58QbIkQwdU7dRmB7s=.685dd7c4-0ee5-4970-9c2a-eb7b656a5b3f@github.com> Massive parallel execution of parametrised CorpusTest junit tests revealed race condition in `ClassHierarchyImpl.CachedClassHierarchyResolver::getClassInfo`. The race condition may skip calculation of the ClassHierarchyInfo. In this specific case it caused SegmentScope not being identified as an interface and verify error on assignability between declared method return type and actual returned type has been emitted by the test. Proposed patch fixes the race condition in `ClassHierarchyImpl.CachedClassHierarchyResolver::getClassInfo`. Please review. Thank you, Adam ------------- Commit messages: - 8304164: jdk/classfile/CorpusTest.java still fails after JDK-8303910 Changes: https://git.openjdk.org/jdk/pull/13037/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13037&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304164 Stats: 9 lines in 1 file changed: 6 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/13037.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13037/head:pull/13037 PR: https://git.openjdk.org/jdk/pull/13037 From duke at openjdk.org Wed Mar 15 11:47:15 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Wed, 15 Mar 2023 11:47:15 GMT Subject: RFR: 8304245: Speed up CharacterData.of by avoiding bit shifting in the latin1 fast-path test Message-ID: <-mhNL4ascuO9KdhZ-L0jRng9dxvp78p_FWNrg6VUaKo=.1f6c5ec1-cde3-4acd-a2c4-c2fd0933c480@github.com> By avoiding a bit shift operation for the latin1 fast-path test, we can speed up the `java.lang.CharacterData.of` method by ~25% for latin1 code points. The latin1 test is currently implemented as `ch >>> 8 == 0`. We can replace this with `ch >= 0 && ch <= 0xFF` for a noticable performance gain (especially for ASCII chars): This methods is called frequently by various property-determining methods in `java.lang.Character` like `isLowerCase`, `isDigit` etc, so one should expect improvements for all these methods. Performance is tested using the `Characters.isDigit` benchmark using the digits '0' (decimal 48, in CharacterDataLatin1) and '\u0660' (decimal 1632, in CharacterData00): Baseline: Benchmark (codePoint) Mode Cnt Score Error Units Characters.isDigit 48 avgt 15 0.870 ? 0.011 ns/op Characters.isDigit 1632 avgt 15 2.168 ? 0.017 ns/op PR: Benchmark (codePoint) Mode Cnt Score Error Units Characters.isDigit 48 avgt 15 0.654 ? 0.007 ns/op Characters.isDigit 1632 avgt 15 2.032 ? 0.019 ns/op ------------- Commit messages: - Update copyright year - Avoid bit shifting in the CharacterDataLatin1 fast-path Changes: https://git.openjdk.org/jdk/pull/13040/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13040&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304245 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13040.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13040/head:pull/13040 PR: https://git.openjdk.org/jdk/pull/13040 From stsypanov at openjdk.org Wed Mar 15 11:52:20 2023 From: stsypanov at openjdk.org (Sergey Tsypanov) Date: Wed, 15 Mar 2023 11:52:20 GMT Subject: RFR: 8304245: Speed up CharacterData.of by avoiding bit shifting in the latin1 fast-path test In-Reply-To: <-mhNL4ascuO9KdhZ-L0jRng9dxvp78p_FWNrg6VUaKo=.1f6c5ec1-cde3-4acd-a2c4-c2fd0933c480@github.com> References: <-mhNL4ascuO9KdhZ-L0jRng9dxvp78p_FWNrg6VUaKo=.1f6c5ec1-cde3-4acd-a2c4-c2fd0933c480@github.com> Message-ID: On Wed, 15 Mar 2023 11:26:21 GMT, Eirik Bjorsnos wrote: > By avoiding a bit shift operation for the latin1 fast-path test, we can speed up the `java.lang.CharacterData.of` method by ~25% for latin1 code points. > > The latin1 test is currently implemented as `ch >>> 8 == 0`. We can replace this with `ch >= 0 && ch <= 0xFF` for a noticable performance gain (especially for Latin1 code points): > > This method is called frequently by various property-determining methods in `java.lang.Character` like `isLowerCase`, `isDigit` etc, so one should expect improvements for all these methods. > > Performance is tested using the `Characters.isDigit` benchmark using the digits '0' (decimal 48, in CharacterDataLatin1) and '\u0660' (decimal 1632, in CharacterData00): > > Baseline: > > > Benchmark (codePoint) Mode Cnt Score Error Units > Characters.isDigit 48 avgt 15 0.870 ? 0.011 ns/op > Characters.isDigit 1632 avgt 15 2.168 ? 0.017 ns/op > > PR: > > > Benchmark (codePoint) Mode Cnt Score Error Units > Characters.isDigit 48 avgt 15 0.654 ? 0.007 ns/op > Characters.isDigit 1632 avgt 15 2.032 ? 0.019 ns/op Marked as reviewed by stsypanov (Author). ------------- PR: https://git.openjdk.org/jdk/pull/13040 From mbaesken at openjdk.org Wed Mar 15 11:53:18 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 15 Mar 2023 11:53:18 GMT Subject: RFR: JDK-8304063: tools/jpackage/share/AppLauncherEnvTest.java fails when checking LD_LIBRARY_PATH Message-ID: The test fails on Alpine Linux 3.17, when checking the environment variable LD_LIBRARY_PATH; looks like the actual env variable is much longer than the test expects. It turned out that at least on Linux (probably also on other OS like AIX) the actual env variable has the expected string at it's end, but might contain more path entries ( LD_LIBRARY_PATH can be adjusted by jvm - https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/libjli/java_md.c ). ------------- Commit messages: - JDK-8304063 Changes: https://git.openjdk.org/jdk/pull/13041/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13041&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304063 Stats: 9 lines in 1 file changed: 6 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/13041.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13041/head:pull/13041 PR: https://git.openjdk.org/jdk/pull/13041 From redestad at openjdk.org Wed Mar 15 12:03:20 2023 From: redestad at openjdk.org (Claes Redestad) Date: Wed, 15 Mar 2023 12:03:20 GMT Subject: RFR: 8304245: Speed up CharacterData.of by avoiding bit shifting in the latin1 fast-path test In-Reply-To: <-mhNL4ascuO9KdhZ-L0jRng9dxvp78p_FWNrg6VUaKo=.1f6c5ec1-cde3-4acd-a2c4-c2fd0933c480@github.com> References: <-mhNL4ascuO9KdhZ-L0jRng9dxvp78p_FWNrg6VUaKo=.1f6c5ec1-cde3-4acd-a2c4-c2fd0933c480@github.com> Message-ID: <48pbcrbZmBQO6J80QbsguXOnjkWpcvYAHoJeuRJkJxM=.8c5a9e01-2793-4161-9dab-dee7a1b95d52@github.com> On Wed, 15 Mar 2023 11:26:21 GMT, Eirik Bjorsnos wrote: > By avoiding a bit shift operation for the latin1 fast-path test, we can speed up the `java.lang.CharacterData.of` method by ~25% for latin1 code points. > > The latin1 test is currently implemented as `ch >>> 8 == 0`. We can replace this with `ch >= 0 && ch <= 0xFF` for a noticable performance gain (especially for Latin1 code points): > > This method is called frequently by various property-determining methods in `java.lang.Character` like `isLowerCase`, `isDigit` etc, so one should expect improvements for all these methods. > > Performance is tested using the `Characters.isDigit` benchmark using the digits '0' (decimal 48, in CharacterDataLatin1) and '\u0660' (decimal 1632, in CharacterData00): > > Baseline: > > > Benchmark (codePoint) Mode Cnt Score Error Units > Characters.isDigit 48 avgt 15 0.870 ? 0.011 ns/op > Characters.isDigit 1632 avgt 15 2.168 ? 0.017 ns/op > > PR: > > > Benchmark (codePoint) Mode Cnt Score Error Units > Characters.isDigit 48 avgt 15 0.654 ? 0.007 ns/op > Characters.isDigit 1632 avgt 15 2.032 ? 0.019 ns/op Nice one! src/java.base/share/classes/java/lang/CharacterData.java line 72: > 70: > 71: static final CharacterData of(int ch) { > 72: if (ch >= 0 && ch <= 0xFF) { // fast-path Maybereducing to a single branch with a mask op helps further? Or maybe the JIT already effectively does that: `if (ch && 0xFFFFFF00 == 0) {` ------------- Marked as reviewed by redestad (Reviewer). PR: https://git.openjdk.org/jdk/pull/13040 From asotona at openjdk.org Wed Mar 15 12:08:07 2023 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 15 Mar 2023 12:08:07 GMT Subject: RFR: 8294972: Convert jdk.jlink internal plugins to use the Classfile API [v7] In-Reply-To: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> Message-ID: > jdk.jlink internal plugins are heavily using ASM > > This patch converts ASM calls to Classfile API. > > Please review. > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: fixed StripJavaDebugAttribute to drop line numbers from code ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12944/files - new: https://git.openjdk.org/jdk/pull/12944/files/5fe8c7f4..91bf43f6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12944&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12944&range=05-06 Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/12944.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12944/head:pull/12944 PR: https://git.openjdk.org/jdk/pull/12944 From stsypanov at openjdk.org Wed Mar 15 12:10:23 2023 From: stsypanov at openjdk.org (Sergey Tsypanov) Date: Wed, 15 Mar 2023 12:10:23 GMT Subject: RFR: 8304245: Speed up CharacterData.of by avoiding bit shifting in the latin1 fast-path test In-Reply-To: <48pbcrbZmBQO6J80QbsguXOnjkWpcvYAHoJeuRJkJxM=.8c5a9e01-2793-4161-9dab-dee7a1b95d52@github.com> References: <-mhNL4ascuO9KdhZ-L0jRng9dxvp78p_FWNrg6VUaKo=.1f6c5ec1-cde3-4acd-a2c4-c2fd0933c480@github.com> <48pbcrbZmBQO6J80QbsguXOnjkWpcvYAHoJeuRJkJxM=.8c5a9e01-2793-4161-9dab-dee7a1b95d52@github.com> Message-ID: On Wed, 15 Mar 2023 11:58:14 GMT, Claes Redestad wrote: >> By avoiding a bit shift operation for the latin1 fast-path test, we can speed up the `java.lang.CharacterData.of` method by ~25% for latin1 code points. >> >> The latin1 test is currently implemented as `ch >>> 8 == 0`. We can replace this with `ch >= 0 && ch <= 0xFF` for a noticable performance gain (especially for Latin1 code points): >> >> This method is called frequently by various property-determining methods in `java.lang.Character` like `isLowerCase`, `isDigit` etc, so one should expect improvements for all these methods. >> >> Performance is tested using the `Characters.isDigit` benchmark using the digits '0' (decimal 48, in CharacterDataLatin1) and '\u0660' (decimal 1632, in CharacterData00): >> >> Baseline: >> >> >> Benchmark (codePoint) Mode Cnt Score Error Units >> Characters.isDigit 48 avgt 15 0.870 ? 0.011 ns/op >> Characters.isDigit 1632 avgt 15 2.168 ? 0.017 ns/op >> >> PR: >> >> >> Benchmark (codePoint) Mode Cnt Score Error Units >> Characters.isDigit 48 avgt 15 0.654 ? 0.007 ns/op >> Characters.isDigit 1632 avgt 15 2.032 ? 0.019 ns/op > > src/java.base/share/classes/java/lang/CharacterData.java line 72: > >> 70: >> 71: static final CharacterData of(int ch) { >> 72: if (ch >= 0 && ch <= 0xFF) { // fast-path > > Maybereducing to a single branch with a mask op helps further? Or maybe the JIT already effectively does that: > > `if (ch && 0xFFFFFF00 == 0) {` Btw, I think we can do the same for `StringLatin1.canEncode()` ------------- PR: https://git.openjdk.org/jdk/pull/13040 From asotona at openjdk.org Wed Mar 15 12:10:30 2023 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 15 Mar 2023 12:10:30 GMT Subject: RFR: 8294972: Convert jdk.jlink internal plugins to use the Classfile API [v4] In-Reply-To: References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> Message-ID: On Tue, 14 Mar 2023 18:00:51 GMT, Mandy Chung wrote: >> Right, I'll fix it, thanks. > > Looks like `LineNumberTable` is not stripped even with `Option.processLineNumbers(false)`. Yes, I forgot to transform code elements, where `Classfile.Option.processLineNumbers(false)` option is applied. Thanks for catching it. We may also consider a new form of transformation allowing to filter code attributes without inflation of all code elements (in the Classfile API). ------------- PR: https://git.openjdk.org/jdk/pull/12944 From redestad at openjdk.org Wed Mar 15 12:15:22 2023 From: redestad at openjdk.org (Claes Redestad) Date: Wed, 15 Mar 2023 12:15:22 GMT Subject: RFR: 8304245: Speed up CharacterData.of by avoiding bit shifting in the latin1 fast-path test In-Reply-To: References: <-mhNL4ascuO9KdhZ-L0jRng9dxvp78p_FWNrg6VUaKo=.1f6c5ec1-cde3-4acd-a2c4-c2fd0933c480@github.com> <48pbcrbZmBQO6J80QbsguXOnjkWpcvYAHoJeuRJkJxM=.8c5a9e01-2793-4161-9dab-dee7a1b95d52@github.com> Message-ID: On Wed, 15 Mar 2023 12:07:12 GMT, Sergey Tsypanov wrote: >> src/java.base/share/classes/java/lang/CharacterData.java line 72: >> >>> 70: >>> 71: static final CharacterData of(int ch) { >>> 72: if (ch >= 0 && ch <= 0xFF) { // fast-path >> >> Maybereducing to a single branch with a mask op helps further? Or maybe the JIT already effectively does that: >> >> `if (ch && 0xFFFFFF00 == 0) {` > > Btw, I think we can do the same for `StringLatin1.canEncode()` It seems reasonable to keep these two in sync, yes. (`CharacterData.of` could even call into `StringLatin1.canEncode`, unless that's cause for some performance anomaly) ------------- PR: https://git.openjdk.org/jdk/pull/13040 From duke at openjdk.org Wed Mar 15 12:19:21 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Wed, 15 Mar 2023 12:19:21 GMT Subject: RFR: 8304245: Speed up CharacterData.of by avoiding bit shifting in the latin1 fast-path test In-Reply-To: References: <-mhNL4ascuO9KdhZ-L0jRng9dxvp78p_FWNrg6VUaKo=.1f6c5ec1-cde3-4acd-a2c4-c2fd0933c480@github.com> <48pbcrbZmBQO6J80QbsguXOnjkWpcvYAHoJeuRJkJxM=.8c5a9e01-2793-4161-9dab-dee7a1b95d52@github.com> Message-ID: On Wed, 15 Mar 2023 12:13:00 GMT, Claes Redestad wrote: >> Btw, I think we can do the same for `StringLatin1.canEncode()` > > It seems reasonable to keep these two in sync, yes. (`CharacterData.of` could even call into `StringLatin1.canEncode`, unless that's cause for some performance anomaly) > `if (ch && 0xFFFFFF00 == 0) {` This seems to perform similar to baseline: Benchmark (codePoint) Mode Cnt Score Error Units Characters.isDigit 48 avgt 15 0.890 ? 0.025 ns/op Characters.isDigit 1632 avgt 15 2.174 ? 0.011 ns/op Would be interesting to check the performance on non-Intel architectures. If you want to give it a spin on your M1, here's the benchmark command I used: `make test TEST='micro:java.lang.Characters.isDigit' MICRO="OPTIONS=-p codePoint=48,1632"` ------------- PR: https://git.openjdk.org/jdk/pull/13040 From duke at openjdk.org Wed Mar 15 12:24:35 2023 From: duke at openjdk.org (duke) Date: Wed, 15 Mar 2023 12:24:35 GMT Subject: Withdrawn: 8203035: Implement equals() and hashCode() for Throwable In-Reply-To: References: Message-ID: <65U5pPjQ4KldLsD7pRfWMOMs0jvqJV4K2cfPxbv_6U0=.85fe7674-5e27-4373-9d10-289c64052a26@github.com> On Sat, 10 Dec 2022 18:11:30 GMT, Victor Toni wrote: > Being able to compare instances of Throwable allows simple detection of exceptions raised by the same circumstances. Comparison allows for reduction of excessive logging e.g. in hotspots without requiring custom code to compare Throwables. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/11624 From duke at openjdk.org Wed Mar 15 12:31:21 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Wed, 15 Mar 2023 12:31:21 GMT Subject: RFR: 8304245: Speed up CharacterData.of by avoiding bit shifting in the latin1 fast-path test In-Reply-To: References: <-mhNL4ascuO9KdhZ-L0jRng9dxvp78p_FWNrg6VUaKo=.1f6c5ec1-cde3-4acd-a2c4-c2fd0933c480@github.com> <48pbcrbZmBQO6J80QbsguXOnjkWpcvYAHoJeuRJkJxM=.8c5a9e01-2793-4161-9dab-dee7a1b95d52@github.com> Message-ID: <-G0bjp7QOP42BCRs1n2G6mxJSExj76GroacBjkQoWuo=.05e993a5-f012-4c6b-8c49-4c74d8e35b39@github.com> On Wed, 15 Mar 2023 12:15:39 GMT, Eirik Bjorsnos wrote: >> It seems reasonable to keep these two in sync, yes. (`CharacterData.of` could even call into `StringLatin1.canEncode`, unless that's cause for some performance anomaly) > >> `if (ch && 0xFFFFFF00 == 0) {` > > This seems to perform similar to baseline: > > > Benchmark (codePoint) Mode Cnt Score Error Units > Characters.isDigit 48 avgt 15 0.890 ? 0.025 ns/op > Characters.isDigit 1632 avgt 15 2.174 ? 0.011 ns/op > > > Would be interesting to check the performance on non-Intel architectures. If you want to give it a spin on your M1, here's the benchmark command I used: > > `make test TEST='micro:java.lang.Characters.isDigit' MICRO="OPTIONS=-p codePoint=48,1632"` > It seems reasonable to keep these two in sync, yes. (`CharacterData.of` could even call into `StringLatin1.canEncode`, unless that's cause for some performance anomaly) If I update `StringLatin1.canEncode` and call into that from `CharacterData.of`, I observe no regression for the Latin1 case, but a significant regression for the non-Latin1 case. I have no idea how to explain that: Benchmark (codePoint) Mode Cnt Score Error Units Characters.isDigit 48 avgt 15 0.675 ? 0.029 ns/op Characters.isDigit 1632 avgt 15 2.435 ? 0.032 ns/op ------------- PR: https://git.openjdk.org/jdk/pull/13040 From duke at openjdk.org Wed Mar 15 12:40:19 2023 From: duke at openjdk.org (Francesco Nigro) Date: Wed, 15 Mar 2023 12:40:19 GMT Subject: RFR: 8304245: Speed up CharacterData.of by avoiding bit shifting in the latin1 fast-path test In-Reply-To: <-G0bjp7QOP42BCRs1n2G6mxJSExj76GroacBjkQoWuo=.05e993a5-f012-4c6b-8c49-4c74d8e35b39@github.com> References: <-mhNL4ascuO9KdhZ-L0jRng9dxvp78p_FWNrg6VUaKo=.1f6c5ec1-cde3-4acd-a2c4-c2fd0933c480@github.com> <48pbcrbZmBQO6J80QbsguXOnjkWpcvYAHoJeuRJkJxM=.8c5a9e01-2793-4161-9dab-dee7a1b95d52@github.com> <-G0bjp7QOP42BCRs1n2G6mxJSExj76GroacBjkQoWuo=.05e993a5-f012-4c6b-8c49-4c74d8e35b39@github.com> Message-ID: On Wed, 15 Mar 2023 12:28:05 GMT, Eirik Bjorsnos wrote: >>> `if (ch && 0xFFFFFF00 == 0) {` >> >> This seems to perform similar to baseline: >> >> >> Benchmark (codePoint) Mode Cnt Score Error Units >> Characters.isDigit 48 avgt 15 0.890 ? 0.025 ns/op >> Characters.isDigit 1632 avgt 15 2.174 ? 0.011 ns/op >> >> >> Would be interesting to check the performance on non-Intel architectures. If you want to give it a spin on your M1, here's the benchmark command I used: >> >> `make test TEST='micro:java.lang.Characters.isDigit' MICRO="OPTIONS=-p codePoint=48,1632"` > >> It seems reasonable to keep these two in sync, yes. (`CharacterData.of` could even call into `StringLatin1.canEncode`, unless that's cause for some performance anomaly) > > If I update `StringLatin1.canEncode` and call into that from `CharacterData.of`, I observe no regression for the Latin1 case, but a significant regression for the non-Latin1 case. I have no idea how to explain that: > > > Benchmark (codePoint) Mode Cnt Score Error Units > Characters.isDigit 48 avgt 15 0.675 ? 0.029 ns/op > Characters.isDigit 1632 avgt 15 2.435 ? 0.032 ns/op Can you check what happen adding much more inputs to the dataset that includes non-latin chars as well and use `-prof perfnorm` to check what `perf` report re branches/branch-misses? You can use SplittableRandom to pre-populate an array of inputs which sequence is "random" but still allow deterministic benchmarking and feed the benchmark method cycling the pre-computed inputs ------------- PR: https://git.openjdk.org/jdk/pull/13040 From duke at openjdk.org Wed Mar 15 13:45:31 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Wed, 15 Mar 2023 13:45:31 GMT Subject: RFR: 8304245: Speed up CharacterData.of by avoiding bit shifting in the latin1 fast-path test In-Reply-To: References: <-mhNL4ascuO9KdhZ-L0jRng9dxvp78p_FWNrg6VUaKo=.1f6c5ec1-cde3-4acd-a2c4-c2fd0933c480@github.com> <48pbcrbZmBQO6J80QbsguXOnjkWpcvYAHoJeuRJkJxM=.8c5a9e01-2793-4161-9dab-dee7a1b95d52@github.com> <-G0bjp7QOP42BCRs1n2G6mxJSExj76GroacBjkQoWuo=.05e993a5-f012-4c6b-8c49-4c74d8e35b39@github.com> Message-ID: <1jnPSPh1W0Lme04llPDlejKeFmNOH2eL5fNmyUgN_Ns=.b4021466-157a-49ab-bd08-71c0ec9312dd@github.com> On Wed, 15 Mar 2023 12:37:24 GMT, Francesco Nigro wrote: >>> It seems reasonable to keep these two in sync, yes. (`CharacterData.of` could even call into `StringLatin1.canEncode`, unless that's cause for some performance anomaly) >> >> If I update `StringLatin1.canEncode` and call into that from `CharacterData.of`, I observe no regression for the Latin1 case, but a significant regression for the non-Latin1 case. I have no idea how to explain that: >> >> >> Benchmark (codePoint) Mode Cnt Score Error Units >> Characters.isDigit 48 avgt 15 0.675 ? 0.029 ns/op >> Characters.isDigit 1632 avgt 15 2.435 ? 0.032 ns/op > > Can you check what happen adding much more inputs to the dataset including non-latin chars as well and use `-prof perfnorm` to check what `perf` report re branches/branch-misses? > > You can use `SplittableRandom` to pre-populate an array of inputs which sequence is "random" but still allow deterministic benchmarking and feed the benchmark method by cycling the pre-computed inputs. > In the real world I expect `isDigit` to happen on different input types and both having C2 with both branches places based on prev inputs distribution and a confused branch-predictor to allow comparing vs something that looks a bit nearest to the real world (TBD, I know). > I expect in that case that a single cmp + mask to work better depending on latin input distribution/occurrence I created a randomized version of `Characters.isDigit` which tests with code points picked at random such that any category (Latin1, negative, different planes, unassiged) are equally probable. Baseline: Benchmark (codePoint) Mode Cnt Score Error Units Characters.isDigitRandom 1632 avgt 15 5.503 ? 0.371 ns/op Current PR: Benchmark (codePoint) Mode Cnt Score Error Units Characters.isDigitRandom 1632 avgt 15 5.393 ? 0.336 ns/op Using StringLatin1.canEncode: Benchmark (codePoint) Mode Cnt Score Error Units Characters.isDigitRandom 1632 avgt 15 5.377 ? 0.322 ns/op Seems the PR still has a small improvement for this scenario. The StringLatin1.canEncode regression disappears. In the real world ASCII/Latin1 seems to dominate most data, so this scenario is perhaps not very realistic. I'm running this on a Mac, so cannot try `-prof perfnorm`. ------------- PR: https://git.openjdk.org/jdk/pull/13040 From duke at openjdk.org Wed Mar 15 13:54:19 2023 From: duke at openjdk.org (Francesco Nigro) Date: Wed, 15 Mar 2023 13:54:19 GMT Subject: RFR: 8304245: Speed up CharacterData.of by avoiding bit shifting in the latin1 fast-path test In-Reply-To: <1jnPSPh1W0Lme04llPDlejKeFmNOH2eL5fNmyUgN_Ns=.b4021466-157a-49ab-bd08-71c0ec9312dd@github.com> References: <-mhNL4ascuO9KdhZ-L0jRng9dxvp78p_FWNrg6VUaKo=.1f6c5ec1-cde3-4acd-a2c4-c2fd0933c480@github.com> <48pbcrbZmBQO6J80QbsguXOnjkWpcvYAHoJeuRJkJxM=.8c5a9e01-2793-4161-9dab-dee7a1b95d52@github.com> <-G0bjp7QOP42BCRs1n2G6mxJSExj76GroacBjkQoWuo=.05e993a5-f012-4c6b-8c49-4c74d8e35b39@github.com> <1jnPSPh1W0Lme04llPDlejKeFmNOH2eL5fNmyUgN_Ns=.b4021466-157a-49ab-bd08-71c0ec9312dd@github.com> Message-ID: On Wed, 15 Mar 2023 13:42:22 GMT, Eirik Bjorsnos wrote: >> Can you check what happen adding much more inputs to the dataset including non-latin chars as well and use `-prof perfnorm` to check what `perf` report re branches/branch-misses? >> >> You can use `SplittableRandom` to pre-populate an array of inputs which sequence is "random" but still allow deterministic benchmarking and feed the benchmark method by cycling the pre-computed inputs. >> In the real world I expect `isDigit` to happen on different input types and both having C2 with both branches places based on prev inputs distribution and a confused branch-predictor to allow comparing vs something that looks a bit nearest to the real world (TBD, I know). >> I expect in that case that a single cmp + mask to work better depending on latin input distribution/occurrence > > I created a randomized version of `Characters.isDigit` which tests with code points picked at random such that any category (Latin1, negative, different planes, unassiged) are equally probable. > > Baseline: > > > Benchmark (codePoint) Mode Cnt Score Error Units > Characters.isDigitRandom 1632 avgt 15 5.503 ? 0.371 ns/op > > > Current PR: > > > Benchmark (codePoint) Mode Cnt Score Error Units > Characters.isDigitRandom 1632 avgt 15 5.393 ? 0.336 ns/op > > > Using StringLatin1.canEncode: > > > Benchmark (codePoint) Mode Cnt Score Error Units > Characters.isDigitRandom 1632 avgt 15 5.377 ? 0.322 ns/op > > > Seems the PR still has a small improvement for this scenario. The StringLatin1.canEncode regression disappears. > > In the real world ASCII/Latin1 seems to dominate most data, so this scenario is perhaps not very realistic. > > I'm running this on a Mac, so cannot try `-prof perfnorm`. Many thanks to have tried, yep, I was curious indeed re the "StringLatin1.canEncode regression" case. I would still modify the benchmark to use inputs (I know that will make it memory bound sadly, due to reading inputs - but the size of such inputs can be a benchmark parameter, together with the bias eg "latin","mix", "non-latin") "semi-randomly" generated based on the mentioned strategies/biases. It will benefit future tests on this, although could be provided as a separate PR. ------------- PR: https://git.openjdk.org/jdk/pull/13040 From lmesnik at openjdk.org Wed Mar 15 14:23:06 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 15 Mar 2023 14:23:06 GMT Subject: RFR: 8303697: ProcessTools doesn't print last line of process output [v2] In-Reply-To: <2yj8kBz0HKn3QwV6awfX7bwl1IgBqBiRza-ABtJwCzo=.22255150-b358-4def-88a5-ed2ebc0de129@github.com> References: <2yj8kBz0HKn3QwV6awfX7bwl1IgBqBiRza-ABtJwCzo=.22255150-b358-4def-88a5-ed2ebc0de129@github.com> Message-ID: > The StreamPumper is fixed to process the last line even it is not finishes with '\n' or '\r'. The test included. Testing with tier1-3 also to verify that tests are not broken. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: fixed test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13034/files - new: https://git.openjdk.org/jdk/pull/13034/files/2f33a8c4..7e0305d1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13034&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13034&range=00-01 Stats: 12 lines in 1 file changed: 2 ins; 8 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13034.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13034/head:pull/13034 PR: https://git.openjdk.org/jdk/pull/13034 From lmesnik at openjdk.org Wed Mar 15 14:26:25 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 15 Mar 2023 14:26:25 GMT Subject: RFR: 8303697: ProcessTools doesn't print last line of process output [v2] In-Reply-To: References: <2yj8kBz0HKn3QwV6awfX7bwl1IgBqBiRza-ABtJwCzo=.22255150-b358-4def-88a5-ed2ebc0de129@github.com> Message-ID: On Wed, 15 Mar 2023 14:23:06 GMT, Leonid Mesnik wrote: >> The StreamPumper is fixed to process the last line even it is not finishes with '\n' or '\r'. The test included. Testing with tier1-3 also to verify that tests are not broken. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > fixed test test/lib/jdk/test/lib/process/StreamPumper.java line 145: > 143: } > 144: } > 145: final String line = lineBos.toString(); The code in 'lastcrlf == -1' as well as in 'lastcrlf < len - 1' writes remaining buf into lineBos. This lineBos is used to make line which is processed in line 127. However, if the stream is emptied then the chunk after last '\n' is written in in the lineBos but we never reach line 127 to call processLine for it. ------------- PR: https://git.openjdk.org/jdk/pull/13034 From duke at openjdk.org Wed Mar 15 14:31:06 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Wed, 15 Mar 2023 14:31:06 GMT Subject: RFR: 8304245: Speed up CharacterData.of by avoiding bit shifting in the latin1 fast-path test [v2] In-Reply-To: <48pbcrbZmBQO6J80QbsguXOnjkWpcvYAHoJeuRJkJxM=.8c5a9e01-2793-4161-9dab-dee7a1b95d52@github.com> References: <-mhNL4ascuO9KdhZ-L0jRng9dxvp78p_FWNrg6VUaKo=.1f6c5ec1-cde3-4acd-a2c4-c2fd0933c480@github.com> <48pbcrbZmBQO6J80QbsguXOnjkWpcvYAHoJeuRJkJxM=.8c5a9e01-2793-4161-9dab-dee7a1b95d52@github.com> Message-ID: On Wed, 15 Mar 2023 12:00:59 GMT, Claes Redestad wrote: >> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision: >> >> Update StringLatin1.canEncode to sync with same test in CharacterData.of > > Nice one! @cl4es Do you agree that the StringLatin1.canEncode change should be included in this PR? If so, can you approve the latest update? ------------- PR: https://git.openjdk.org/jdk/pull/13040 From duke at openjdk.org Wed Mar 15 14:31:03 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Wed, 15 Mar 2023 14:31:03 GMT Subject: RFR: 8304245: Speed up CharacterData.of by avoiding bit shifting in the latin1 fast-path test [v2] In-Reply-To: <-mhNL4ascuO9KdhZ-L0jRng9dxvp78p_FWNrg6VUaKo=.1f6c5ec1-cde3-4acd-a2c4-c2fd0933c480@github.com> References: <-mhNL4ascuO9KdhZ-L0jRng9dxvp78p_FWNrg6VUaKo=.1f6c5ec1-cde3-4acd-a2c4-c2fd0933c480@github.com> Message-ID: <4LTvtBGCy0mN2jf74mViiDZ9ci8VQS44uA-hXHjV0KI=.c9715dc2-1d87-4f49-ac4c-ff6fa25bb583@github.com> > By avoiding a bit shift operation for the latin1 fast-path test, we can speed up the `java.lang.CharacterData.of` method by ~25% for latin1 code points. > > The latin1 test is currently implemented as `ch >>> 8 == 0`. We can replace this with `ch >= 0 && ch <= 0xFF` for a noticable performance gain (especially for Latin1 code points): > > This method is called frequently by various property-determining methods in `java.lang.Character` like `isLowerCase`, `isDigit` etc, so one should expect improvements for all these methods. > > Performance is tested using the `Characters.isDigit` benchmark using the digits '0' (decimal 48, in CharacterDataLatin1) and '\u0660' (decimal 1632, in CharacterData00): > > Baseline: > > > Benchmark (codePoint) Mode Cnt Score Error Units > Characters.isDigit 48 avgt 15 0.870 ? 0.011 ns/op > Characters.isDigit 1632 avgt 15 2.168 ? 0.017 ns/op > > PR: > > > Benchmark (codePoint) Mode Cnt Score Error Units > Characters.isDigit 48 avgt 15 0.654 ? 0.007 ns/op > Characters.isDigit 1632 avgt 15 2.032 ? 0.019 ns/op Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision: Update StringLatin1.canEncode to sync with same test in CharacterData.of ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13040/files - new: https://git.openjdk.org/jdk/pull/13040/files/0174440e..0baf690e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13040&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13040&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13040.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13040/head:pull/13040 PR: https://git.openjdk.org/jdk/pull/13040 From duke at openjdk.org Wed Mar 15 14:31:09 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Wed, 15 Mar 2023 14:31:09 GMT Subject: RFR: 8304245: Speed up CharacterData.of by avoiding bit shifting in the latin1 fast-path test [v2] In-Reply-To: References: <-mhNL4ascuO9KdhZ-L0jRng9dxvp78p_FWNrg6VUaKo=.1f6c5ec1-cde3-4acd-a2c4-c2fd0933c480@github.com> <48pbcrbZmBQO6J80QbsguXOnjkWpcvYAHoJeuRJkJxM=.8c5a9e01-2793-4161-9dab-dee7a1b95d52@github.com> <-G0bjp7QOP42BCRs1n2G6mxJSExj76GroacBjkQoWuo=.05e993a5-f012-4c6b-8c49-4c74d8e35b39@github.com> <1jnPSPh1W0Lme04llPDlejKeFmNOH2eL5fNmyUgN_Ns=.b4021466-157a-49ab-bd08-71c0ec9312dd@github.com> Message-ID: On Wed, 15 Mar 2023 13:50:44 GMT, Francesco Nigro wrote: >> I created a randomized version of `Characters.isDigit` which tests with code points picked at random such that any category (Latin1, negative, different planes, unassiged) are equally probable. >> >> Baseline: >> >> >> Benchmark (codePoint) Mode Cnt Score Error Units >> Characters.isDigitRandom 1632 avgt 15 5.503 ? 0.371 ns/op >> >> >> Current PR: >> >> >> Benchmark (codePoint) Mode Cnt Score Error Units >> Characters.isDigitRandom 1632 avgt 15 5.393 ? 0.336 ns/op >> >> >> Using StringLatin1.canEncode: >> >> >> Benchmark (codePoint) Mode Cnt Score Error Units >> Characters.isDigitRandom 1632 avgt 15 5.377 ? 0.322 ns/op >> >> >> Seems the PR still has a small improvement for this scenario. The StringLatin1.canEncode regression disappears. >> >> In the real world ASCII/Latin1 seems to dominate most data, so this scenario is perhaps not very realistic. >> >> I'm running this on a Mac, so cannot try `-prof perfnorm`. > > Many thanks to have tried, yep, I was curious indeed re the "StringLatin1.canEncode regression" case. > I would still modify the benchmark to use inputs (I know that will make it memory bound sadly, due to reading inputs - but the size of such inputs can be a benchmark parameter, together with the bias eg "latin","mix", "non-latin") "semi-randomly" generated based on the mentioned strategies/biases. > It will benefit future tests on this, although could be provided as a separate PR. > The StringLatin1.canEncode regression disappears. I mixed things up so StringLatin1.canEncode was benchmarked without the updated code. Here are updated benchmark results: Baseline: Benchmark (codePoint) Mode Cnt Score Error Units Characters.isDigitRandom 1632 avgt 15 5.437 ? 0.235 ns/op PR: Benchmark (codePoint) Mode Cnt Score Error Units Characters.isDigitRandom 1632 avgt 15 5.319 ? 0.341 ns/op StringLatin1.canEncode: Benchmark (codePoint) Mode Cnt Score Error Units Characters.isDigitRandom 1632 avgt 15 5.447 ? 0.304 ns/op ``` So it seems using StringLatin1.canEncode still might have a regression also in the randomized input case. For this PR, I suggest we update StringLatin1.canEncode to be in sync with CharacterData.of, without one calling the other. If anyone wants to investigate the regression further, than can be done outside this PR. I have independently verified that StringLatin1.canEncode sees performance improvements using the StringIndexOf benchmark. ------------- PR: https://git.openjdk.org/jdk/pull/13040 From stsypanov at openjdk.org Wed Mar 15 14:40:23 2023 From: stsypanov at openjdk.org (Sergey Tsypanov) Date: Wed, 15 Mar 2023 14:40:23 GMT Subject: RFR: 8304245: Speed up CharacterData.of by avoiding bit shifting in the latin1 fast-path test [v2] In-Reply-To: <4LTvtBGCy0mN2jf74mViiDZ9ci8VQS44uA-hXHjV0KI=.c9715dc2-1d87-4f49-ac4c-ff6fa25bb583@github.com> References: <-mhNL4ascuO9KdhZ-L0jRng9dxvp78p_FWNrg6VUaKo=.1f6c5ec1-cde3-4acd-a2c4-c2fd0933c480@github.com> <4LTvtBGCy0mN2jf74mViiDZ9ci8VQS44uA-hXHjV0KI=.c9715dc2-1d87-4f49-ac4c-ff6fa25bb583@github.com> Message-ID: On Wed, 15 Mar 2023 14:31:03 GMT, Eirik Bjorsnos wrote: >> By avoiding a bit shift operation for the latin1 fast-path test, we can speed up the `java.lang.CharacterData.of` method by ~25% for latin1 code points. >> >> The latin1 test is currently implemented as `ch >>> 8 == 0`. We can replace this with `ch >= 0 && ch <= 0xFF` for a noticable performance gain (especially for Latin1 code points): >> >> This method is called frequently by various property-determining methods in `java.lang.Character` like `isLowerCase`, `isDigit` etc, so one should expect improvements for all these methods. >> >> Performance is tested using the `Characters.isDigit` benchmark using the digits '0' (decimal 48, in CharacterDataLatin1) and '\u0660' (decimal 1632, in CharacterData00): >> >> Baseline: >> >> >> Benchmark (codePoint) Mode Cnt Score Error Units >> Characters.isDigit 48 avgt 15 0.870 ? 0.011 ns/op >> Characters.isDigit 1632 avgt 15 2.168 ? 0.017 ns/op >> >> PR: >> >> >> Benchmark (codePoint) Mode Cnt Score Error Units >> Characters.isDigit 48 avgt 15 0.654 ? 0.007 ns/op >> Characters.isDigit 1632 avgt 15 2.032 ? 0.019 ns/op > > Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision: > > Update StringLatin1.canEncode to sync with same test in CharacterData.of Marked as reviewed by stsypanov (Author). ------------- PR: https://git.openjdk.org/jdk/pull/13040 From duke at openjdk.org Wed Mar 15 15:00:25 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Wed, 15 Mar 2023 15:00:25 GMT Subject: RFR: 8304245: Speed up CharacterData.of by avoiding bit shifting in the latin1 fast-path test [v2] In-Reply-To: <4LTvtBGCy0mN2jf74mViiDZ9ci8VQS44uA-hXHjV0KI=.c9715dc2-1d87-4f49-ac4c-ff6fa25bb583@github.com> References: <-mhNL4ascuO9KdhZ-L0jRng9dxvp78p_FWNrg6VUaKo=.1f6c5ec1-cde3-4acd-a2c4-c2fd0933c480@github.com> <4LTvtBGCy0mN2jf74mViiDZ9ci8VQS44uA-hXHjV0KI=.c9715dc2-1d87-4f49-ac4c-ff6fa25bb583@github.com> Message-ID: On Wed, 15 Mar 2023 14:31:03 GMT, Eirik Bjorsnos wrote: >> By avoiding a bit shift operation for the latin1 fast-path test, we can speed up the `java.lang.CharacterData.of` method by ~25% for latin1 code points. >> >> The latin1 test is currently implemented as `ch >>> 8 == 0`. We can replace this with `ch >= 0 && ch <= 0xFF` for a noticable performance gain (especially for Latin1 code points): >> >> This method is called frequently by various property-determining methods in `java.lang.Character` like `isLowerCase`, `isDigit` etc, so one should expect improvements for all these methods. >> >> Performance is tested using the `Characters.isDigit` benchmark using the digits '0' (decimal 48, in CharacterDataLatin1) and '\u0660' (decimal 1632, in CharacterData00): >> >> Baseline: >> >> >> Benchmark (codePoint) Mode Cnt Score Error Units >> Characters.isDigit 48 avgt 15 0.870 ? 0.011 ns/op >> Characters.isDigit 1632 avgt 15 2.168 ? 0.017 ns/op >> >> PR: >> >> >> Benchmark (codePoint) Mode Cnt Score Error Units >> Characters.isDigit 48 avgt 15 0.654 ? 0.007 ns/op >> Characters.isDigit 1632 avgt 15 2.032 ? 0.019 ns/op > > Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision: > > Update StringLatin1.canEncode to sync with same test in CharacterData.of Just for fun, I tried with a benchmark where the code point is Latin1 in every other call: @Benchmark public void isDigitVarying(Blackhole blackhole) { blackhole.consume(Character.isDigit(48)); blackhole.consume(Character.isDigit(1632)); } With this benchmark, there is no difference between the baseline, the PR and using StringLatin1.canEncode: Baseline: Benchmark (codePoint) Mode Cnt Score Error Units Characters.isDigitVarying 1632 avgt 15 1.198 ? 0.056 ns/op PR: Benchmark (codePoint) Mode Cnt Score Error Units Characters.isDigitVarying 1632 avgt 15 1.195 ? 0.058 ns/op StringLatin1.canEncode: Benchmark (codePoint) Mode Cnt Score Error Units Characters.isDigitVarying 1632 avgt 15 1.193 ? 0.055 ns/op ``` At this point, I'm starting to wonder a bit if the performance benefits suggested by this PR might be dubious and will only surface in very narrow benchmarks. On the other hand, it does not seem harmful either. What do people think? ------------- PR: https://git.openjdk.org/jdk/pull/13040 From qamai at openjdk.org Wed Mar 15 15:00:28 2023 From: qamai at openjdk.org (Quan Anh Mai) Date: Wed, 15 Mar 2023 15:00:28 GMT Subject: RFR: 8304245: Speed up CharacterData.of by avoiding bit shifting in the latin1 fast-path test [v2] In-Reply-To: References: <-mhNL4ascuO9KdhZ-L0jRng9dxvp78p_FWNrg6VUaKo=.1f6c5ec1-cde3-4acd-a2c4-c2fd0933c480@github.com> <48pbcrbZmBQO6J80QbsguXOnjkWpcvYAHoJeuRJkJxM=.8c5a9e01-2793-4161-9dab-dee7a1b95d52@github.com> <-G0bjp7QOP42BCRs1n2G6mxJSExj76GroacBjkQoWuo=.05e993a5-f012-4c6b-8c49-4c74d8e35b39@github.com> <1jnPSPh1W0Lme04llPDlejKeFmNOH2eL5fNmyUgN_Ns=.b4021466-157a-49ab-bd08-71c0ec9312dd@github.com> Message-ID: On Wed, 15 Mar 2023 14:23:35 GMT, Eirik Bjorsnos wrote: >> Many thanks to have tried, yep, I was curious indeed re the "StringLatin1.canEncode regression" case. >> I would still modify the benchmark to use inputs (I know that will make it memory bound sadly, due to reading inputs - but the size of such inputs can be a benchmark parameter, together with the bias eg "latin","mix", "non-latin") "semi-randomly" generated based on the mentioned strategies/biases. >> It will benefit future tests on this, although could be provided as a separate PR. > >> The StringLatin1.canEncode regression disappears. > > I mixed things up so StringLatin1.canEncode was benchmarked without the updated code. > > Here are updated benchmark results: > > > Baseline: > > > Benchmark (codePoint) Mode Cnt Score Error Units > Characters.isDigitRandom 1632 avgt 15 5.437 ? 0.235 ns/op > > > PR: > > > Benchmark (codePoint) Mode Cnt Score Error Units > Characters.isDigitRandom 1632 avgt 15 5.319 ? 0.341 ns/op > > > StringLatin1.canEncode: > > > Benchmark (codePoint) Mode Cnt Score Error Units > Characters.isDigitRandom 1632 avgt 15 5.447 ? 0.304 ns/op > ``` > > So it seems using StringLatin1.canEncode still might have a regression also in the randomized input case. > > For this PR, I suggest we update StringLatin1.canEncode to be in sync with CharacterData.of, without one calling the other. If anyone wants to investigate the regression further, than can be done outside this PR. > > I have independently verified that StringLatin1.canEncode sees performance improvements using the StringIndexOf benchmark. We can do `Integer.compareUnsigned(ch, 0xFF) <= 0` ------------- PR: https://git.openjdk.org/jdk/pull/13040 From duke at openjdk.org Wed Mar 15 15:10:29 2023 From: duke at openjdk.org (Francesco Nigro) Date: Wed, 15 Mar 2023 15:10:29 GMT Subject: RFR: 8304245: Speed up CharacterData.of by avoiding bit shifting in the latin1 fast-path test [v2] In-Reply-To: References: <-mhNL4ascuO9KdhZ-L0jRng9dxvp78p_FWNrg6VUaKo=.1f6c5ec1-cde3-4acd-a2c4-c2fd0933c480@github.com> <4LTvtBGCy0mN2jf74mViiDZ9ci8VQS44uA-hXHjV0KI=.c9715dc2-1d87-4f49-ac4c-ff6fa25bb583@github.com> Message-ID: On Wed, 15 Mar 2023 14:56:28 GMT, Eirik Bjorsnos wrote: >> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision: >> >> Update StringLatin1.canEncode to sync with same test in CharacterData.of > > Just for fun, I tried with a benchmark where the code point is Latin1 in every other call: > > > @Benchmark > public void isDigitVarying(Blackhole blackhole) { > blackhole.consume(Character.isDigit(48)); > blackhole.consume(Character.isDigit(1632)); > } > > > With this benchmark, there is no difference between the baseline, the PR and using StringLatin1.canEncode: > > Baseline: > > > Benchmark (codePoint) Mode Cnt Score Error Units > Characters.isDigitVarying 1632 avgt 15 1.198 ? 0.056 ns/op > > > PR: > > > Benchmark (codePoint) Mode Cnt Score Error Units > Characters.isDigitVarying 1632 avgt 15 1.195 ? 0.058 ns/op > > > StringLatin1.canEncode: > > > Benchmark (codePoint) Mode Cnt Score Error Units > Characters.isDigitVarying 1632 avgt 15 1.193 ? 0.055 ns/op > ``` > > At this point, I'm starting to wonder a bit if the performance benefits suggested by this PR might be dubious and will only surface in very narrow benchmarks. On the other hand, it does not seem harmful either. What do people think? @eirbjo I suggest to add `-prof perfasm` and see what's going on; I suspect it's better that inputs are loaded from `@State` field...and don't use `BlackHole` but combine the results of the 2 operations (although I remember that compiler assisted black holes are not as noisy as I'm used to observe with JDK 11 ones) ------------- PR: https://git.openjdk.org/jdk/pull/13040 From duke at openjdk.org Wed Mar 15 15:13:24 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Wed, 15 Mar 2023 15:13:24 GMT Subject: RFR: 8304245: Speed up CharacterData.of by avoiding bit shifting in the latin1 fast-path test [v2] In-Reply-To: References: <-mhNL4ascuO9KdhZ-L0jRng9dxvp78p_FWNrg6VUaKo=.1f6c5ec1-cde3-4acd-a2c4-c2fd0933c480@github.com> <48pbcrbZmBQO6J80QbsguXOnjkWpcvYAHoJeuRJkJxM=.8c5a9e01-2793-4161-9dab-dee7a1b95d52@github.com> <-G0bjp7QOP42BCRs1n2G6mxJSExj76GroacBjkQoWuo=.05e993a5-f012-4c6b-8c49-4c74d8e35b39@github.com> <1jnPSPh1W0Lme04llPDlejKeFmNOH2eL5fNmyUgN_Ns=.b4021466-157a-49ab-bd08-71c0ec9312dd@github.com> Message-ID: <4m6unzqJyeoeWDRGNSMXOZq9ysa1JfUldlHhrXz5xTY=.58f68d2c-4ab2-4357-aa83-3c88e7a8ba0f@github.com> On Wed, 15 Mar 2023 14:57:43 GMT, Quan Anh Mai wrote: >>> The StringLatin1.canEncode regression disappears. >> >> I mixed things up so StringLatin1.canEncode was benchmarked without the updated code. >> >> Here are updated benchmark results: >> >> >> Baseline: >> >> >> Benchmark (codePoint) Mode Cnt Score Error Units >> Characters.isDigitRandom 1632 avgt 15 5.437 ? 0.235 ns/op >> >> >> PR: >> >> >> Benchmark (codePoint) Mode Cnt Score Error Units >> Characters.isDigitRandom 1632 avgt 15 5.319 ? 0.341 ns/op >> >> >> StringLatin1.canEncode: >> >> >> Benchmark (codePoint) Mode Cnt Score Error Units >> Characters.isDigitRandom 1632 avgt 15 5.447 ? 0.304 ns/op >> ``` >> >> So it seems using StringLatin1.canEncode still might have a regression also in the randomized input case. >> >> For this PR, I suggest we update StringLatin1.canEncode to be in sync with CharacterData.of, without one calling the other. If anyone wants to investigate the regression further, than can be done outside this PR. >> >> I have independently verified that StringLatin1.canEncode sees performance improvements using the StringIndexOf benchmark. > > We can do `Integer.compareUnsigned(ch, 0xFF) <= 0` We could, but benchmarks show no performance improvements over the current PR. I think the current code is perhaps slightly more readable. ------------- PR: https://git.openjdk.org/jdk/pull/13040 From duke at openjdk.org Wed Mar 15 15:53:49 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Wed, 15 Mar 2023 15:53:49 GMT Subject: RFR: 8304245: Speed up CharacterData.of by avoiding bit shifting in the latin1 fast-path test [v2] In-Reply-To: References: <-mhNL4ascuO9KdhZ-L0jRng9dxvp78p_FWNrg6VUaKo=.1f6c5ec1-cde3-4acd-a2c4-c2fd0933c480@github.com> <4LTvtBGCy0mN2jf74mViiDZ9ci8VQS44uA-hXHjV0KI=.c9715dc2-1d87-4f49-ac4c-ff6fa25bb583@github.com> Message-ID: On Wed, 15 Mar 2023 14:56:28 GMT, Eirik Bjorsnos wrote: >> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision: >> >> Update StringLatin1.canEncode to sync with same test in CharacterData.of > > Just for fun, I tried with a benchmark where the code point is Latin1 in every other call: > > > @Benchmark > public void isDigitVarying(Blackhole blackhole) { > blackhole.consume(Character.isDigit(48)); > blackhole.consume(Character.isDigit(1632)); > } > > > With this benchmark, there is no difference between the baseline, the PR and using StringLatin1.canEncode: > > Baseline: > > > Benchmark (codePoint) Mode Cnt Score Error Units > Characters.isDigitVarying 1632 avgt 15 1.198 ? 0.056 ns/op > > > PR: > > > Benchmark (codePoint) Mode Cnt Score Error Units > Characters.isDigitVarying 1632 avgt 15 1.195 ? 0.058 ns/op > > > StringLatin1.canEncode: > > > Benchmark (codePoint) Mode Cnt Score Error Units > Characters.isDigitVarying 1632 avgt 15 1.193 ? 0.055 ns/op > ``` > > At this point, I'm starting to wonder a bit if the performance benefits suggested by this PR might be dubious and will only surface in very narrow benchmarks. On the other hand, it does not seem harmful either. What do people think? > @eirbjo I suggest to add `-prof perfasm` and see what's going on; I suspect it's better that inputs are loaded from `@State` field...and don't use `BlackHole` but combine the results of the 2 operations (although I remember that compiler assisted black holes are not as noisy as I'm used to observe with JDK 11 ones) I think I'm done with benchmarking for this PR. Any StringLatin1.canEncode method call regression can be solved outside this PR. The PR as it stands seems to have some benefit for Latin1-only apps/use cases, which I think is not uncommon. Any benefit for mixed?cases are more dubious, but don't seem to hurt. ------------- PR: https://git.openjdk.org/jdk/pull/13040 From jlu at openjdk.org Wed Mar 15 16:08:03 2023 From: jlu at openjdk.org (Justin Lu) Date: Wed, 15 Mar 2023 16:08:03 GMT Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native Message-ID: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii. In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file. ------------- Commit messages: - Write to ASCII - Read in .properties as UTF-8, but write to LRB .java as ISO-8859-1 - Compile class with ascii (Not ready to make system wide change) - Toggle UTF-8 for javac option in JavaCompilation.gmk - CompileProperties converts in UTF-8 - Convert .properties from ISO-8859-1 to UTF-8 Changes: https://git.openjdk.org/jdk/pull/12726/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12726&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301991 Stats: 29093 lines in 490 files changed: 6 ins; 0 del; 29087 mod Patch: https://git.openjdk.org/jdk/pull/12726.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12726/head:pull/12726 PR: https://git.openjdk.org/jdk/pull/12726 From jlu at openjdk.org Wed Mar 15 16:08:07 2023 From: jlu at openjdk.org (Justin Lu) Date: Wed, 15 Mar 2023 16:08:07 GMT Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native In-Reply-To: References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com> Message-ID: <_dP9N3UNWa82tfLVEapoSFJjbvMmlyP21ZbuL0NjTDU=.3685af0b-31a0-42aa-86b0-5098bda72766@github.com> On Tue, 7 Mar 2023 23:15:14 GMT, Jonathan Gibbons wrote: >> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii. >> >> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file. > > make/langtools/tools/compileproperties/CompileProperties.java line 252: > >> 250: try { >> 251: writer = new BufferedWriter( >> 252: new OutputStreamWriter(new FileOutputStream(outputPath), StandardCharsets.ISO_8859_1)); > > Using ISO_8859_1 seems strange. > Since these are generated files, you could write them as UTF-8 and then override the default javac option for ascii when compiling _just_ these files. > > Or else just stay with ascii; no one should be looking at these files! Will stick with your latter solution, as since the .properties files were converted via native2ascii, it makes sense to write out via ascii. ------------- PR: https://git.openjdk.org/jdk/pull/12726 From jjg at openjdk.org Wed Mar 15 16:08:06 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Wed, 15 Mar 2023 16:08:06 GMT Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native In-Reply-To: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com> References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com> Message-ID: On Thu, 23 Feb 2023 09:04:23 GMT, Justin Lu wrote: > This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii. > > In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file. make/langtools/tools/compileproperties/CompileProperties.java line 252: > 250: try { > 251: writer = new BufferedWriter( > 252: new OutputStreamWriter(new FileOutputStream(outputPath), StandardCharsets.ISO_8859_1)); Using ISO_8859_1 seems strange. Since these are generated files, you could write them as UTF-8 and then override the default javac option for ascii when compiling _just_ these files. Or else just stay with ascii; no one should be looking at these files! ------------- PR: https://git.openjdk.org/jdk/pull/12726 From duke at openjdk.org Wed Mar 15 16:21:33 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Wed, 15 Mar 2023 16:21:33 GMT Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native In-Reply-To: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com> References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com> Message-ID: <1I9v8d2OiyLfQVCozGYVRhAi3AotqGuRUhsNj0VCsUk=.e673ca33-d24f-4aab-908e-a5c0bfa3bf7c@github.com> On Thu, 23 Feb 2023 09:04:23 GMT, Justin Lu wrote: > This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii. > > In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file. test/jdk/java/util/ResourceBundle/Bug6204853.properties line 1: > 1: # This file should probably be excluded because it's used in a test that relates to UTF-8 encoding (or not) of property files. ------------- PR: https://git.openjdk.org/jdk/pull/12726 From asotona at openjdk.org Wed Mar 15 16:42:53 2023 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 15 Mar 2023 16:42:53 GMT Subject: RFR: 8294972: Convert jdk.jlink internal plugins to use the Classfile API [v8] In-Reply-To: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> Message-ID: > jdk.jlink internal plugins are heavily using ASM > > This patch converts ASM calls to Classfile API. > > Please review. > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: fixed SystemModulesPlugin ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12944/files - new: https://git.openjdk.org/jdk/pull/12944/files/91bf43f6..49c80bcd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12944&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12944&range=06-07 Stats: 372 lines in 1 file changed: 38 ins; 21 del; 313 mod Patch: https://git.openjdk.org/jdk/pull/12944.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12944/head:pull/12944 PR: https://git.openjdk.org/jdk/pull/12944 From asotona at openjdk.org Wed Mar 15 16:43:00 2023 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 15 Mar 2023 16:43:00 GMT Subject: RFR: 8294972: Convert jdk.jlink internal plugins to use the Classfile API [v6] In-Reply-To: References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> Message-ID: On Tue, 14 Mar 2023 16:34:59 GMT, Chen Liang wrote: >> Adam Sotona has updated the pull request incrementally with three additional commits since the last revision: >> >> - long lines wrapped >> - StripJavaDebugAttributesPlugin transformation fixed >> - VersionPropsPlugin transformation fixed > > src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 614: > >> 612: private void genConstructor(ClassBuilder clb) { >> 613: clb.withMethod("", MethodTypeDesc.of(CD_void), >> 614: ACC_PUBLIC, mb -> mb.withFlags(ACC_PUBLIC).withCode( cob -> { > > Why `withFlags(ACC_PUBLIC)` when the flags is already given in `withMethod`'s 3rd argument? Same for occurrences below. It has been redundant, now more effective `withMethodBody` method is used. > src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 615: > >> 613: clb.withMethod("", MethodTypeDesc.of(CD_void), >> 614: ACC_PUBLIC, mb -> mb.withFlags(ACC_PUBLIC).withCode( cob -> { >> 615: cob.loadInstruction(TypeKind.ReferenceType, 0); > > What's the basis for using `loadInstruction(ReferenceType, 0)` over `aload(0)`, etc.? I think, at least for constructors, we won't have other TypeKinds, so we can safely use `aload(0)` `return_()`, and this is what the original ASM code used. The whole syntax used in `SystemModulesPlugin` deserved a refresh. `loadInstruction(ReferenceType, 0)` is a generic pattern used before more convenient `aload(0)` has been added to `CodeBuilder`. Now it is fixed, thanks. > src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 916: > >> 914: sb.append("Ljava/lang/Object;"); >> 915: } >> 916: sb.append(")Ljava/util/Set;"); > > The construction of the Set.of method type should move away from StringBuilder. It can be as: > > var mtdArgs = new ClassDesc[size]; > Arrays.fill(mtdArgs, CD_Object); > MethodTypeDesc mtd = MethodTypeDesc.of(CD_Set, mtdArgs); Applied, thanks. ------------- PR: https://git.openjdk.org/jdk/pull/12944 From vlivanov at openjdk.org Wed Mar 15 16:54:33 2023 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Wed, 15 Mar 2023 16:54:33 GMT Subject: RFR: 8303022: "assert(allocates2(pc)) failed: not in CodeBuffer memory" When linking downcall handle [v3] In-Reply-To: References: Message-ID: On Fri, 10 Mar 2023 14:14:55 GMT, Jorn Vernee wrote: >> The issue is that the size of the code buffer is not large enough to hold the whole stub. >> >> Proposed solution is to scale the size of the stub with the number of arguments. I've adjusted sizes for both downcall and upcall stubs. I've also dropped the number of relocations, since we're not really using any for downcalls, and for upcalls we only have 1 AFAICS. (the size of the relocations can not be zero however, as that leads to the relocation section [not being initialized][1], and triggering [an assert][2] later when the code blob is copied). >> >> The way I've determined the new base size and per-argument size for stubs, is by first linking a stub without any arguments to get the required base size, and by then adding 20 `double` arguments to get a rough per-argument size. Both values have wiggle room as well. The sizes can be printed using e.g. `-XX:+LogCompilation`, and then looking for `nep_invoker_blob` and `upcall_stub*` in the log file. This experiment was done on a fastdebug build to account for additional debug code being generated. The included test is designed to try and maximize the size of the generated stub. >> >> I've also updated `CodeBuffer::log_section_sizes` to print the in-use size, rather than just the capacity and free space. >> >> [1]: https://github.com/openjdk/jdk/blob/56512cfe1f0682c98ba3488af3d03ccef632c016/src/hotspot/share/asm/codeBuffer.cpp#L119-L121 >> [2]: https://github.com/openjdk/jdk/blob/56512cfe1f0682c98ba3488af3d03ccef632c016/src/hotspot/share/asm/codeBuffer.cpp#L675 > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > RISCV changes Looks good. ------------- Marked as reviewed by vlivanov (Reviewer). PR: https://git.openjdk.org/jdk/pull/12908 From jvernee at openjdk.org Wed Mar 15 17:17:51 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 15 Mar 2023 17:17:51 GMT Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function & Memory API (Preview) [v16] In-Reply-To: References: Message-ID: On Tue, 14 Mar 2023 22:30:22 GMT, Martin Doerr wrote: >> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification". >> >> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `` (2.2.4 Variable Argument Lists). >> >> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only. >> >> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Will get addressed separately: [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017) >> >> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests. >> >> I had to make changes to shared code and code for other platforms: >> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons: >> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that. >> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64. >> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian! >> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit. > > Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: > > Fix storing 32 bit integers into Java frames. Enable TestArrayStructs. src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/TypeClass.java line 2: > 1: /* > 2: * Copyright (c) 2022, 2023 Oracle and/or its affiliates. All rights reserved. The copyright header here is missing a comma after the second year: Suggestion: * Copyright (c) 2022, 2023, Oracle and/or its affiliates. All rights reserved. ------------- PR: https://git.openjdk.org/jdk/pull/12708 From jvernee at openjdk.org Wed Mar 15 17:27:32 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 15 Mar 2023 17:27:32 GMT Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function & Memory API (Preview) [v16] In-Reply-To: References: Message-ID: On Tue, 14 Mar 2023 22:52:44 GMT, Martin Doerr wrote: > Btw. the new cases in which we use int and short accesses when byteWidth is not a power of 2 are never unaligned AFAICS. I guess _UNALIGNED is unnecessary in the JAVA_INT_UNALIGNED and JAVA_SHORT_UNALIGNED. They are always aligned wrt. to their size. They are not necessarily aligned, for instance of the struct we are given is not aligned itself (at least in the reading case). Though we currently reject that case in AbstractLinker, it is something we might want to allow, and we have been looking at that as of late, for instance to pass packed structs to native code. FWIW, using the unaligned variant effectively just turns off the alignment checks we do. So we have less safety, in theory. There should be no performance difference though just from using the _UNALIGNED layout. ------------- PR: https://git.openjdk.org/jdk/pull/12708 From dnsimon at openjdk.org Wed Mar 15 18:03:33 2023 From: dnsimon at openjdk.org (Doug Simon) Date: Wed, 15 Mar 2023 18:03:33 GMT Subject: RFR: 8303431: [JVMCI] libgraal annotation API [v6] In-Reply-To: <0hYs21V1ZWB8o92CfvkEW3i0dZKkeW8kYGQu0p6xvtM=.e76da2cd-dbe5-4da2-a6cb-775f081b9a6a@github.com> References: <0hYs21V1ZWB8o92CfvkEW3i0dZKkeW8kYGQu0p6xvtM=.e76da2cd-dbe5-4da2-a6cb-775f081b9a6a@github.com> Message-ID: On Tue, 14 Mar 2023 16:06:06 GMT, Doug Simon wrote: >> This PR extends JVMCI with new API (`jdk.vm.ci.meta.Annotated`) for accessing annotations. The main differences from `java.lang.reflect.AnnotatedElement` are: >> * All methods in the `Annotated` interface explicitly specify requested annotation type(s). That is, there is no equivalent of `AnnotatedElement.getAnnotations()`. >> * Annotation data is returned in a map-like object (of type `jdk.vm.ci.meta.AnnotationData`) instead of in an `Annotation` object. This works better for libgraal as it avoids the need for annotation types to be loaded and included in libgraal. >> >> To demonstrate the new API, here's an example in terms `java.lang.reflect.AnnotatedElement` (which `ResolvedJavaType` implements): >> >> ResolvedJavaMethod method = ...; >> ExplodeLoop a = method.getAnnotation(ExplodeLoop.class); >> return switch (a.kind()) { >> case FULL_UNROLL -> LoopExplosionKind.FULL_UNROLL; >> case FULL_UNROLL_UNTIL_RETURN -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN; >> ... >> } >> >> >> The same code using the new API: >> >> >> ResolvedJavaMethod method = ...; >> ResolvedJavaType explodeLoopType = ...; >> AnnotationData a = method.getAnnotationDataFor(explodeLoopType); >> return switch (a.getEnum("kind").getName()) { >> case "FULL_UNROLL" -> LoopExplosionKind.FULL_UNROLL; >> case "FULL_UNROLL_UNTIL_RETURN" -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN; >> ... >> } >> >> >> The implementation relies on new methods in `jdk.internal.vm.VMSupport` for parsing annotations and serializing/deserializing to/from a byte array. This allows the annotation data to be passed from the HotSpot heap to the libgraal heap. > > Doug Simon has updated the pull request incrementally with one additional commit since the last revision: > > addressed review feedback @jddarcy would you be able to help review this PR? Based on git log, you are knowledgeable in `sun.reflect.annotation`. If not, please suggest who else I can reach out to for a review. ------------- PR: https://git.openjdk.org/jdk/pull/12810 From pminborg at openjdk.org Wed Mar 15 18:17:00 2023 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 15 Mar 2023 18:17:00 GMT Subject: RFR: 8304283: Modernize the switch statements in jdk.internal.foreign Message-ID: <69yyuUfAG5P3fNCzQ44xtTBqWQEZbdqfQS3Z-u9Vk6w=.d94b0b09-197c-4992-b7ff-a9f943ef3b59@github.com> This PR proposes changing old-type switch statements to newer forms of switch. ------------- Commit messages: - Update copyright years - Modernize the switch statements in jdk.internal.foreign Changes: https://git.openjdk.org/jdk/pull/13047/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13047&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304283 Stats: 214 lines in 8 files changed: 23 ins; 96 del; 95 mod Patch: https://git.openjdk.org/jdk/pull/13047.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13047/head:pull/13047 PR: https://git.openjdk.org/jdk/pull/13047 From naoto at openjdk.org Wed Mar 15 18:21:11 2023 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 15 Mar 2023 18:21:11 GMT Subject: RFR: 8303018: Unicode Emoji Properties [v3] In-Reply-To: References: Message-ID: > Proposing accessor methods to Emoji properties defined in [Unicode Technical Standard #51](https://unicode.org/reports/tr51/) in `java.lang.Character` class. This is per a request from the client group, as well as refining the currently existing ad-hoc emoji implementation in regex. A CSR has also been drafted, and I would appreciate reviews for it too. Naoto Sato has updated the pull request incrementally with two additional commits since the last revision: - InternalError message/mask constants cleanup - Indentation/print comment fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13006/files - new: https://git.openjdk.org/jdk/pull/13006/files/0b7b7296..6b4eef94 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13006&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13006&range=01-02 Stats: 66 lines in 2 files changed: 36 ins; 9 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/13006.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13006/head:pull/13006 PR: https://git.openjdk.org/jdk/pull/13006 From naoto at openjdk.org Wed Mar 15 18:23:26 2023 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 15 Mar 2023 18:23:26 GMT Subject: RFR: 8303018: Unicode Emoji Properties [v2] In-Reply-To: References: Message-ID: On Tue, 14 Mar 2023 17:09:54 GMT, Eirik Bjorsnos wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed method descriptions > > make/jdk/src/classes/build/tools/generatecharacter/GenerateCharacter.java line 215: > >> 213: maskEmojiComponent = 0x040000000000L, >> 214: maskExtendedPictographic = 0x080000000000L; >> 215: > > Would be nice the have the '=' aligned in the same column as the ones above, or at least have the emoji ones align with each other. Thanks. Indentation aligned, and although in production `-string` is used so comments are not emitted, added information for `B` table in `GenerateCharacter.propertiesComments` for consistency. ------------- PR: https://git.openjdk.org/jdk/pull/13006 From naoto at openjdk.org Wed Mar 15 18:23:24 2023 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 15 Mar 2023 18:23:24 GMT Subject: RFR: 8303018: Unicode Emoji Properties [v2] In-Reply-To: References: Message-ID: <5NaAAMFK5xFh97si1SRoq7H4Yu_34y6eieQvfIP_1eg=.c0bc4aab-8178-4eec-993b-078bcf198940@github.com> On Tue, 14 Mar 2023 20:47:55 GMT, Roger Riggs wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed method descriptions > > make/jdk/src/classes/build/tools/generatecharacter/EmojiData.java line 99: > >> 97: case "Emoji_Component" -> EMOJI_COMPONENT; >> 98: case "Extended_Pictographic" -> EXTENDED_PICTOGRAPHIC; >> 99: default -> throw new InternalError(); > > It would be useful to include the "type" as the exception argument. It give some idea as to the corruption or missing case. Added `type` to the error message > make/jdk/src/classes/build/tools/generatecharacter/GenerateCharacter.java line 214: > >> 212: maskEmojiModifierBase = 0x020000000000L, >> 213: maskEmojiComponent = 0x040000000000L, >> 214: maskExtendedPictographic = 0x080000000000L; > > It would be good to leverage a common definition (perhaps a bit number) here and in EmojiData.java > and build the constants with <<< shifts. Good point. I managed to get rid of the constants in `EmojiData` altogether, by using the constants in `GenerateCharacter`. Used the bit numbers to construct constants. > make/jdk/src/classes/build/tools/generatecharacter/GenerateCharacter.java line 810: > >> 808: if (x.equals("maskEmojiModifierBase")) return "0x" + hex4(maskEmojiModifierBase >> 32); >> 809: if (x.equals("maskEmojiComponent")) return "0x" + hex4(maskEmojiComponent >> 32); >> 810: if (x.equals("maskExtendedPictographic")) return "0x" + hex4(maskExtendedPictographic >> 32); > > An upgrade would be to modify hex4(), hexNN() to use `HexFormat.of().toUpperCase().toHexDigits((short)xxx)` > The HexFormat is reusable and would avoid creating extra strings. > Perhaps also create a method that combines the repetitive shift and prefixing. > > This if...then... sequence could be an expression switch (x) {...}. It would be good, but it would be for another day IMO. ------------- PR: https://git.openjdk.org/jdk/pull/13006 From rgiulietti at openjdk.org Wed Mar 15 18:24:57 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 15 Mar 2023 18:24:57 GMT Subject: RFR: 8291598: Matcher.appendReplacement should not create new StringBuilder instances Message-ID: Remove instantiation of `StringBuilder` ------------- Commit messages: - 8291598: Matcher.appendReplacement should not create new StringBuilder instances Changes: https://git.openjdk.org/jdk/pull/13048/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13048&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291598 Stats: 152 lines in 1 file changed: 62 ins; 52 del; 38 mod Patch: https://git.openjdk.org/jdk/pull/13048.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13048/head:pull/13048 PR: https://git.openjdk.org/jdk/pull/13048 From rgiulietti at openjdk.org Wed Mar 15 18:24:57 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 15 Mar 2023 18:24:57 GMT Subject: RFR: 8291598: Matcher.appendReplacement should not create new StringBuilder instances In-Reply-To: References: Message-ID: On Wed, 15 Mar 2023 18:15:02 GMT, Raffaello Giulietti wrote: > Remove instantiation of `StringBuilder` Benchmark for the example in the documentation for `Matcher.appendReplacement()` before Benchmark Mode Cnt Score Error Units AppendReplacement.testAppendReplacement avgt 15 177.029 ? 6.294 ns/op after Benchmark Mode Cnt Score Error Units AppendReplacement.testAppendReplacement avgt 15 142.373 ? 1.684 ns/op Same example, but with pattern `"(cat)"` (1 capturing group), matcher on the input repeated 1000 times, and replacement string `"$1dog$1cat$1mouse"` (3 back references). before Benchmark Mode Cnt Score Error Units AppendReplacement.testAppendReplacement avgt 15 262576.335 ? 3718.905 ns/op after Benchmark Mode Cnt Score Error Units AppendReplacement.testAppendReplacement avgt 15 225700.642 ? 683.721 ns/op ------------- PR: https://git.openjdk.org/jdk/pull/13048 From mcimadamore at openjdk.org Wed Mar 15 18:39:27 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 15 Mar 2023 18:39:27 GMT Subject: RFR: 8304283: Modernize the switch statements in jdk.internal.foreign In-Reply-To: <69yyuUfAG5P3fNCzQ44xtTBqWQEZbdqfQS3Z-u9Vk6w=.d94b0b09-197c-4992-b7ff-a9f943ef3b59@github.com> References: <69yyuUfAG5P3fNCzQ44xtTBqWQEZbdqfQS3Z-u9Vk6w=.d94b0b09-197c-4992-b7ff-a9f943ef3b59@github.com> Message-ID: On Wed, 15 Mar 2023 18:10:29 GMT, Per Minborg wrote: > This PR proposes changing old-type switch statements to newer forms of switch. Overall looks good. I've added a couple of optional comments for your consideration. src/java.base/share/classes/jdk/internal/foreign/abi/CallingSequenceBuilder.java line 208: > 206: static boolean isUnbox(Binding binding) { > 207: return switch (binding) { > 208: case Binding.VMStore unused -> true; I wonder... here it might be better to capture the box/unbox nature of a binding in a virtual method in the binding class? E.g. isBox(), isUnbox() ? src/java.base/share/classes/jdk/internal/foreign/abi/riscv64/linux/TypeClass.java line 112: > 110: return flatten(sequenceLayout.elementLayout()).mul(elementCount); > 111: } > 112: case null, default -> throw new IllegalStateException("Cannot get here: " + layout); Since the default throws, and the switch w/o a `case null` also throws, do we need the `case null` here? ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.org/jdk/pull/13047 From asemenyuk at openjdk.org Wed Mar 15 18:40:25 2023 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 15 Mar 2023 18:40:25 GMT Subject: RFR: JDK-8304063: tools/jpackage/share/AppLauncherEnvTest.java fails when checking LD_LIBRARY_PATH In-Reply-To: References: Message-ID: On Wed, 15 Mar 2023 11:46:22 GMT, Matthias Baesken wrote: > The test fails on Alpine Linux 3.17, when checking the environment variable LD_LIBRARY_PATH; looks like the actual env variable is much longer than the test expects. It turned out that at least on Linux (probably also on other OS like AIX) the actual env variable has the expected string at it's end, but might contain more path entries ( LD_LIBRARY_PATH can be adjusted by jvm - https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/libjli/java_md.c ). Changes requested by asemenyuk (Reviewer). test/jdk/tools/jpackage/share/AppLauncherEnvTest.java line 93: > 91: } else { > 92: TKit.assertEquals(expectedEnvVarValue, actualEnvVarValue, msg); > 93: } I'd keep the check as a single statement: TKit.assertTextStream(expectedEnvVarValue) .predicate(TKit.isLinux() ? String::endsWith : String::equals) .label(String.format("value of %s env variable", envVarName)) .apply(Stream.of(actualEnvVarValue)); It also will produce a nicer log record than `TKit.assertTrue(false, msg);` ------------- PR: https://git.openjdk.org/jdk/pull/13041 From rgiulietti at openjdk.org Wed Mar 15 18:47:09 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 15 Mar 2023 18:47:09 GMT Subject: RFR: 8291598: Matcher.appendReplacement should not create new StringBuilder instances [v2] In-Reply-To: References: Message-ID: > Remove instantiation of `StringBuilder` Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: 8291598: Matcher.appendReplacement should not create new StringBuilder instances Fix copyright year ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13048/files - new: https://git.openjdk.org/jdk/pull/13048/files/ea2eebe9..c9432a69 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13048&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13048&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13048.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13048/head:pull/13048 PR: https://git.openjdk.org/jdk/pull/13048 From mdoerr at openjdk.org Wed Mar 15 18:53:08 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 15 Mar 2023 18:53:08 GMT Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function & Memory API (Preview) [v17] In-Reply-To: References: Message-ID: > Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification". > > This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `` (2.2.4 Variable Argument Lists). > > Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only. > > There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Will get addressed separately: [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017) > > The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests. > > I had to make changes to shared code and code for other platforms: > 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons: > - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that. > - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64. > - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian! > 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit. Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: Fix Copyright format. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12708/files - new: https://git.openjdk.org/jdk/pull/12708/files/9173af20..5320f895 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=15-16 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12708.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12708/head:pull/12708 PR: https://git.openjdk.org/jdk/pull/12708 From rriggs at openjdk.org Wed Mar 15 19:03:23 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 15 Mar 2023 19:03:23 GMT Subject: RFR: 8291598: Matcher.appendReplacement should not create new StringBuilder instances [v2] In-Reply-To: References: Message-ID: On Wed, 15 Mar 2023 18:47:09 GMT, Raffaello Giulietti wrote: >> Remove instantiation of `StringBuilder` > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > 8291598: Matcher.appendReplacement should not create new StringBuilder instances > > Fix copyright year src/java.base/share/classes/java/util/regex/Matcher.java line 1066: > 1064: } else { > 1065: break; > 1066: } Possibly remove another SB allocation; remember start and end and use `replacement.substring(start, end)`. ------------- PR: https://git.openjdk.org/jdk/pull/13048 From rriggs at openjdk.org Wed Mar 15 19:07:30 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 15 Mar 2023 19:07:30 GMT Subject: RFR: 8303018: Unicode Emoji Properties [v3] In-Reply-To: References: Message-ID: On Wed, 15 Mar 2023 18:21:11 GMT, Naoto Sato wrote: >> Proposing accessor methods to Emoji properties defined in [Unicode Technical Standard #51](https://unicode.org/reports/tr51/) in `java.lang.Character` class. This is per a request from the client group, as well as refining the currently existing ad-hoc emoji implementation in regex. A CSR has also been drafted, and I would appreciate reviews for it too. > > Naoto Sato has updated the pull request incrementally with two additional commits since the last revision: > > - InternalError message/mask constants cleanup > - Indentation/print comment fix Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/13006 From jvernee at openjdk.org Wed Mar 15 19:12:27 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 15 Mar 2023 19:12:27 GMT Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function & Memory API (Preview) [v17] In-Reply-To: References: Message-ID: On Wed, 15 Mar 2023 18:53:08 GMT, Martin Doerr wrote: >> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification". >> >> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `` (2.2.4 Variable Argument Lists). >> >> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only. >> >> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Will get addressed separately: [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017) >> >> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests. >> >> I had to make changes to shared code and code for other platforms: >> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons: >> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that. >> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64. >> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian! >> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit. > > Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: > > Fix Copyright format. Marked as reviewed by jvernee (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12708 From darcy at openjdk.org Wed Mar 15 19:26:21 2023 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 15 Mar 2023 19:26:21 GMT Subject: RFR: 8303431: [JVMCI] libgraal annotation API [v6] In-Reply-To: References: <0hYs21V1ZWB8o92CfvkEW3i0dZKkeW8kYGQu0p6xvtM=.e76da2cd-dbe5-4da2-a6cb-775f081b9a6a@github.com> Message-ID: On Wed, 15 Mar 2023 18:00:49 GMT, Doug Simon wrote: > @jddarcy would you be able to help review this PR? Based on git log, you are knowledgeable in `sun.reflect.annotation`. If not, please suggest who else I can reach out to for a review. I can take a look at this, but it will be at least a few days before I can swap it in. I've also worked on the annotation-reading API in javax.lang.model. I assume https://bugs.openjdk.org/browse/JDK-8303431 recounts the motivation behind this change? ------------- PR: https://git.openjdk.org/jdk/pull/12810 From jvernee at openjdk.org Wed Mar 15 19:57:20 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 15 Mar 2023 19:57:20 GMT Subject: RFR: 8304283: Modernize the switch statements in jdk.internal.foreign In-Reply-To: References: <69yyuUfAG5P3fNCzQ44xtTBqWQEZbdqfQS3Z-u9Vk6w=.d94b0b09-197c-4992-b7ff-a9f943ef3b59@github.com> Message-ID: On Wed, 15 Mar 2023 18:33:34 GMT, Maurizio Cimadamore wrote: >> This PR proposes changing old-type switch statements to newer forms of switch. > > src/java.base/share/classes/jdk/internal/foreign/abi/CallingSequenceBuilder.java line 208: > >> 206: static boolean isUnbox(Binding binding) { >> 207: return switch (binding) { >> 208: case Binding.VMStore unused -> true; > > I wonder... here it might be better to capture the box/unbox nature of a binding in a virtual method in the binding class? E.g. isBox(), isUnbox() ? I prefer this approach, to be honest, since the logic for all the different binding operators is in one place. It gives an overview of which operators are expected in an unboxing recipe. Making them virtual methods would put quite a bit of visual distance between the different `true`/`false` values. I've been through the Binding file quite a bit, and the amount of scrolling/searching needed to find a particular implementation is kind of annoying. ------------- PR: https://git.openjdk.org/jdk/pull/13047 From jvernee at openjdk.org Wed Mar 15 19:57:22 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 15 Mar 2023 19:57:22 GMT Subject: RFR: 8304283: Modernize the switch statements in jdk.internal.foreign In-Reply-To: References: <69yyuUfAG5P3fNCzQ44xtTBqWQEZbdqfQS3Z-u9Vk6w=.d94b0b09-197c-4992-b7ff-a9f943ef3b59@github.com> Message-ID: <0pDRCzjilphX4cQpCKSEg4sEs7n8bppsURdXaS4DfrA=.e820dc48-661c-4b93-b817-1fe70d15ca13@github.com> On Wed, 15 Mar 2023 19:33:19 GMT, Jorn Vernee wrote: >> src/java.base/share/classes/jdk/internal/foreign/abi/CallingSequenceBuilder.java line 208: >> >>> 206: static boolean isUnbox(Binding binding) { >>> 207: return switch (binding) { >>> 208: case Binding.VMStore unused -> true; >> >> I wonder... here it might be better to capture the box/unbox nature of a binding in a virtual method in the binding class? E.g. isBox(), isUnbox() ? > > I prefer this approach, to be honest, since the logic for all the different binding operators is in one place. It gives an overview of which operators are expected in an unboxing recipe. Making them virtual methods would put quite a bit of visual distance between the different `true`/`false` values. > > I've been through the Binding file quite a bit, and the amount of scrolling/searching needed to find a particular implementation is kind of annoying. To pull on that string some more. I think we should move the implementations of various Binding::verify methods here, or perhaps into a separate BindingVerifier class. Ditto for the Binding::interpret implementations. They could be moved to BindingInterpreter. The Binding class would just be left as a simple bag of records + documentation for each operator. The main motivation for this would be that, if you're looking at e.g. interpretation in `Binding`, there's a lot of noise that you have to filter through. I think it makes more sense to group these things into classes (for specialization/verification/interpretation), where all the code in a class is logically related. ------------- PR: https://git.openjdk.org/jdk/pull/13047 From jvernee at openjdk.org Wed Mar 15 19:57:24 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 15 Mar 2023 19:57:24 GMT Subject: RFR: 8304283: Modernize the switch statements in jdk.internal.foreign In-Reply-To: <69yyuUfAG5P3fNCzQ44xtTBqWQEZbdqfQS3Z-u9Vk6w=.d94b0b09-197c-4992-b7ff-a9f943ef3b59@github.com> References: <69yyuUfAG5P3fNCzQ44xtTBqWQEZbdqfQS3Z-u9Vk6w=.d94b0b09-197c-4992-b7ff-a9f943ef3b59@github.com> Message-ID: On Wed, 15 Mar 2023 18:10:29 GMT, Per Minborg wrote: > This PR proposes changing old-type switch statements to newer forms of switch. src/java.base/share/classes/jdk/internal/foreign/abi/CallingSequenceBuilder.java line 219: > 217: case Binding.Cast unused-> true; > 218: }; > 219: } I'd go a bit further here and visually organize the cases as well. Also, using a static import for `Binding.*`: Suggestion: static boolean isUnbox(Binding binding) { return switch (binding) { case VMStore unused -> true; case BufferLoad unused -> true; case Copy unused -> true; case UnboxAddress unused -> true; case Dup unused -> true; case Cast unused -> true; case VMLoad unused -> false; case BufferStore unused -> false; case Allocate unused -> false; case BoxAddress unused -> false; }; } It's a bit unfortunate that we need variable names as well. ------------- PR: https://git.openjdk.org/jdk/pull/13047 From rgiulietti at openjdk.org Wed Mar 15 20:01:05 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 15 Mar 2023 20:01:05 GMT Subject: RFR: 8291598: Matcher.appendReplacement should not create new StringBuilder instances [v3] In-Reply-To: References: Message-ID: > Remove instantiation of `StringBuilder` Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: 8291598: Matcher.appendReplacement should not create new StringBuilder instances Removed other allocations of StringBuilder when processing named groups in replacement string. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13048/files - new: https://git.openjdk.org/jdk/pull/13048/files/c9432a69..4b5ac595 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13048&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13048&range=01-02 Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/13048.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13048/head:pull/13048 PR: https://git.openjdk.org/jdk/pull/13048 From rgiulietti at openjdk.org Wed Mar 15 20:01:10 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 15 Mar 2023 20:01:10 GMT Subject: RFR: 8291598: Matcher.appendReplacement should not create new StringBuilder instances [v2] In-Reply-To: References: Message-ID: On Wed, 15 Mar 2023 18:55:35 GMT, Roger Riggs wrote: >> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: >> >> 8291598: Matcher.appendReplacement should not create new StringBuilder instances >> >> Fix copyright year > > src/java.base/share/classes/java/util/regex/Matcher.java line 1066: > >> 1064: } else { >> 1065: break; >> 1066: } > > Possibly remove another SB allocation; remember start and end and use `replacement.substring(start, end)`. Thanks @RogerRiggs, addressed in latest commit. ------------- PR: https://git.openjdk.org/jdk/pull/13048 From naoto at openjdk.org Wed Mar 15 20:02:29 2023 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 15 Mar 2023 20:02:29 GMT Subject: RFR: 8225641: Calendar.roll(int field) does not work correctly for WEEK_OF_YEAR In-Reply-To: References: Message-ID: On Tue, 14 Mar 2023 22:16:45 GMT, Justin Lu wrote: > This PR fixes the bug which occurred when `Calendar.roll(WEEK_OF_YEAR)` rolled into a minimal first week with an invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo. > > For example, Rolling _Monday, 30 December 2019_ by 1 week produced _Monday, 31 December 2018_, which is incorrect. This is because `WEEK_OF_YEAR` is rolled from 52 to 1, and the original `DAY_OF_WEEK` is 1. However, there is no Monday in week 1 of 2019. This is exposed when a future method calls `Calendar.complete()`, which eventually calculates a `fixedDate` with the invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo. > > To prevent this, a check is added for rolls into week 1, which determines if the first week is minimal. If it is indeed minimal, then it is checked if `DAY_OF_WEEK` exists in that week, if not, `WEEK_OF_YEAR` must be incremented by one. > > After the fix, Rolling _Monday, 30 December 2019_ by 1 week produces _Monday, 7 January 2019_ Hi Justin, Thanks for the fix. Still reviewing the changes, but here are some comments I have noticed: src/java.base/share/classes/java/util/GregorianCalendar.java line 1314: > 1312: // current DAY_OF_WEEK > 1313: if (newWeekOfYear == 1 && isInvalidWeek1()) { > 1314: newWeekOfYear+=1; is `+1` always correct? Does it work when the amount is negative? src/java.base/share/classes/java/util/GregorianCalendar.java line 3030: > 3028: } > 3029: } > 3030: Are these `GregorianCalendar` specific? What about other calendars? test/jdk/java/util/Calendar/RollToMinWeek.java line 30: > 28: * is rolled into a minimal week 1 > 29: * @run junit RollToMinWeek > 30: */ Have you considered adding test cases into `test/jdk/java/util/Calendar/CalendarTestScripts`, instead of creating a single-purpose test case? test/jdk/java/util/Calendar/RollToMinWeek.java line 79: > 77: return Stream.of( > 78: // Test a variety of rolls that previously produced incorrect results > 79: Arguments.of(buildCalendar(27, 11, 2020, Locale.ENGLISH), The first day of week depends on the region, not the language. In fact, I would prefer explicitly specifying it via a locale like `en-US-u-fw-mon`, and testing all the weekdays. test/jdk/java/util/Calendar/RollToMinWeek.java line 95: > 93: > 94: private static Calendar buildCalendar(int day, int month, int year, Locale locale) { > 95: Calendar calendar = Calendar.getInstance(locale); If the fix is `GregorianCalendar` specific, should it check the type? ------------- PR: https://git.openjdk.org/jdk/pull/13031 From naoto at openjdk.org Wed Mar 15 20:04:21 2023 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 15 Mar 2023 20:04:21 GMT Subject: RFR: 8304225: Remove javax/script/Test7.java from ProblemList In-Reply-To: References: Message-ID: On Wed, 15 Mar 2023 06:16:17 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which removes `javax/script/Test7.java` from the ProblemList? > > As noted in https://bugs.openjdk.org/browse/JDK-8304225, this test no longer fails and passes just like the other tests in `javax/script` directory with: > > > ----------System.out:(4/60)---------- > > Test7 > > Warning: No js engine found; test vacuously passes. > > > With this proposed change, relevant tier testing has been run to verify that the original reported issue which caused this test to be problem listed https://bugs.openjdk.org/browse/JDK-8239361 is no longer seen. Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/13035 From naoto at openjdk.org Wed Mar 15 20:23:23 2023 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 15 Mar 2023 20:23:23 GMT Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native In-Reply-To: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com> References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com> Message-ID: On Thu, 23 Feb 2023 09:04:23 GMT, Justin Lu wrote: > This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii. > > In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file. test/jdk/java/text/Format/NumberFormat/CurrencySymbols.properties line 156: > 154: zh=\u00A4 > 155: zh_CN=\uFFE5 > 156: zh_HK=HK$ Why are they not encoded into UTF-8 native? ------------- PR: https://git.openjdk.org/jdk/pull/12726 From dnsimon at openjdk.org Wed Mar 15 20:37:22 2023 From: dnsimon at openjdk.org (Doug Simon) Date: Wed, 15 Mar 2023 20:37:22 GMT Subject: RFR: 8303431: [JVMCI] libgraal annotation API [v6] In-Reply-To: References: <0hYs21V1ZWB8o92CfvkEW3i0dZKkeW8kYGQu0p6xvtM=.e76da2cd-dbe5-4da2-a6cb-775f081b9a6a@github.com> Message-ID: On Wed, 15 Mar 2023 19:23:52 GMT, Joe Darcy wrote: > I assume https://bugs.openjdk.org/browse/JDK-8303431 recounts the motivation behind this change? Yes, it does. Thanks in advance. ------------- PR: https://git.openjdk.org/jdk/pull/12810 From duke at openjdk.org Wed Mar 15 20:46:21 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Wed, 15 Mar 2023 20:46:21 GMT Subject: RFR: 8303018: Unicode Emoji Properties [v3] In-Reply-To: References: Message-ID: On Wed, 15 Mar 2023 18:21:11 GMT, Naoto Sato wrote: >> Proposing accessor methods to Emoji properties defined in [Unicode Technical Standard #51](https://unicode.org/reports/tr51/) in `java.lang.Character` class. This is per a request from the client group, as well as refining the currently existing ad-hoc emoji implementation in regex. A CSR has also been drafted, and I would appreciate reviews for it too. > > Naoto Sato has updated the pull request incrementally with two additional commits since the last revision: > > - InternalError message/mask constants cleanup > - Indentation/print comment fix Unrelated side note: Reviewing this PR inspired me to see if one could generate more efficient switch expressions for the CharacterDataLatin1 methods as replacement for the property lookup / masking done today. This seemed to give a small improvements on benchmarks and also collapsed a few methods to simply "return false". Could be something to explore at a later point. ------------- PR: https://git.openjdk.org/jdk/pull/13006 From jvernee at openjdk.org Wed Mar 15 20:53:28 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 15 Mar 2023 20:53:28 GMT Subject: RFR: 8303022: "assert(allocates2(pc)) failed: not in CodeBuffer memory" When linking downcall handle [v3] In-Reply-To: References: Message-ID: On Fri, 10 Mar 2023 14:14:55 GMT, Jorn Vernee wrote: >> The issue is that the size of the code buffer is not large enough to hold the whole stub. >> >> Proposed solution is to scale the size of the stub with the number of arguments. I've adjusted sizes for both downcall and upcall stubs. I've also dropped the number of relocations, since we're not really using any for downcalls, and for upcalls we only have 1 AFAICS. (the size of the relocations can not be zero however, as that leads to the relocation section [not being initialized][1], and triggering [an assert][2] later when the code blob is copied). >> >> The way I've determined the new base size and per-argument size for stubs, is by first linking a stub without any arguments to get the required base size, and by then adding 20 `double` arguments to get a rough per-argument size. Both values have wiggle room as well. The sizes can be printed using e.g. `-XX:+LogCompilation`, and then looking for `nep_invoker_blob` and `upcall_stub*` in the log file. This experiment was done on a fastdebug build to account for additional debug code being generated. The included test is designed to try and maximize the size of the generated stub. >> >> I've also updated `CodeBuffer::log_section_sizes` to print the in-use size, rather than just the capacity and free space. >> >> [1]: https://github.com/openjdk/jdk/blob/56512cfe1f0682c98ba3488af3d03ccef632c016/src/hotspot/share/asm/codeBuffer.cpp#L119-L121 >> [2]: https://github.com/openjdk/jdk/blob/56512cfe1f0682c98ba3488af3d03ccef632c016/src/hotspot/share/asm/codeBuffer.cpp#L675 > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > RISCV changes Thanks for the reviews. I'm running one more round of tests before integrating. ------------- PR: https://git.openjdk.org/jdk/pull/12908 From jvernee at openjdk.org Wed Mar 15 20:55:31 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 15 Mar 2023 20:55:31 GMT Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function & Memory API (Preview) [v16] In-Reply-To: References: Message-ID: On Tue, 14 Mar 2023 22:52:44 GMT, Martin Doerr wrote: >> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix storing 32 bit integers into Java frames. Enable TestArrayStructs. > > Btw. the new cases in which we use int and short accesses when byteWidth is not a power of 2 are never unaligned AFAICS. I guess _UNALIGNED is unnecessary in the JAVA_INT_UNALIGNED and JAVA_SHORT_UNALIGNED. They are always aligned wrt. to their size. @TheRealMDoerr I've approved the PR. I suggest for a second reviewer to try and get someone who knows the PPC port. ------------- PR: https://git.openjdk.org/jdk/pull/12708 From jvernee at openjdk.org Wed Mar 15 21:13:18 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 15 Mar 2023 21:13:18 GMT Subject: RFR: 8304180: Constant Descriptors for MethodHandles::classData and classDataAt In-Reply-To: References: Message-ID: <6l9fkaH2piv4nrNFeSjEdEfVLwpbd3mamCOo9RqCuWk=.884a7a83-4e1b-40b6-aa2e-9fd120628478@github.com> On Wed, 15 Mar 2023 02:18:37 GMT, Chen Liang wrote: > Add Constant Descriptors for DirectMethodHandleDesc of MethodHandles::classData and classDataAt in ConstantDescs. This facilitates easier access of class data via condy in Classfile API-generated bytecode. Most other constant bootstrap methods provided in the JDK, notably from `ConstantBootstraps`, already have constant descriptors in ConstantDescs. > > Context: https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000235.html Looks good. I've added myself as a reviewer on the CSR as well. ------------- Marked as reviewed by jvernee (Reviewer). PR: https://git.openjdk.org/jdk/pull/13033 From jvernee at openjdk.org Wed Mar 15 21:21:19 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 15 Mar 2023 21:21:19 GMT Subject: RFR: 8304180: Constant Descriptors for MethodHandles::classData and classDataAt In-Reply-To: References: Message-ID: On Wed, 15 Mar 2023 02:18:37 GMT, Chen Liang wrote: > Add Constant Descriptors for DirectMethodHandleDesc of MethodHandles::classData and classDataAt in ConstantDescs. This facilitates easier access of class data via condy in Classfile API-generated bytecode. Most other constant bootstrap methods provided in the JDK, notably from `ConstantBootstraps`, already have constant descriptors in ConstantDescs. > > Context: https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000235.html P.S. we don't seem to have a test for this class at the moment (except indirectly), but it might be nice to add a test that iterates over all the fields in this class, and tries to resolve them, to make sure that that works. ------------- PR: https://git.openjdk.org/jdk/pull/13033 From jvernee at openjdk.org Wed Mar 15 21:25:19 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 15 Mar 2023 21:25:19 GMT Subject: RFR: 8304161: Add TypeKind.from to derive from TypeDescriptor.OfField In-Reply-To: References: Message-ID: On Tue, 14 Mar 2023 17:12:50 GMT, Chen Liang wrote: > Such an API allows creating TypeKind from both Class and ClassDesc than having to call descriptorString() explicitly at every use site. > > See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000240.html for context. > > Upgraded usages of `fromDescriptor` to `from` in applicable use sites in Classfile API and its tests. LGTM. I think @briangoetz might want to weigh in on this as well. ------------- Marked as reviewed by jvernee (Reviewer). PR: https://git.openjdk.org/jdk/pull/13024 From briangoetz at openjdk.org Wed Mar 15 21:29:19 2023 From: briangoetz at openjdk.org (Brian Goetz) Date: Wed, 15 Mar 2023 21:29:19 GMT Subject: RFR: 8304161: Add TypeKind.from to derive from TypeDescriptor.OfField In-Reply-To: References: Message-ID: On Tue, 14 Mar 2023 17:12:50 GMT, Chen Liang wrote: > Such an API allows creating TypeKind from both Class and ClassDesc than having to call descriptorString() explicitly at every use site. > > See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000240.html for context. > > Upgraded usages of `fromDescriptor` to `from` in applicable use sites in Classfile API and its tests. +1 ------------- PR: https://git.openjdk.org/jdk/pull/13024 From naoto at openjdk.org Wed Mar 15 21:34:23 2023 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 15 Mar 2023 21:34:23 GMT Subject: RFR: 8303018: Unicode Emoji Properties [v3] In-Reply-To: References: Message-ID: On Wed, 15 Mar 2023 20:43:22 GMT, Eirik Bjorsnos wrote: > Unrelated side note: Reviewing this PR inspired me to see if one could generate more efficient switch expressions for the CharacterDataLatin1 methods as replacement for the property lookup / masking done today. This seemed to give a small improvements on benchmarks and also collapsed a few methods to simply "return false". Could be something to explore at a later point. Yeah, agree. `Latin1` can be (should be?) fast-path'ed as always. ------------- PR: https://git.openjdk.org/jdk/pull/13006 From mchung at openjdk.org Wed Mar 15 22:33:30 2023 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 15 Mar 2023 22:33:30 GMT Subject: RFR: 8294972: Convert jdk.jlink internal plugins to use the Classfile API [v8] In-Reply-To: References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> Message-ID: On Wed, 15 Mar 2023 16:42:53 GMT, Adam Sotona wrote: >> jdk.jlink internal plugins are heavily using ASM >> >> This patch converts ASM calls to Classfile API. >> >> Please review. >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > fixed SystemModulesPlugin These convenient methods really simplify it and improve the readability. This patch seems to fix `BasicTest.java` test failure I mentioned to you offline. What was the issue with the previous revision? $ JTwork/scratch/mysmallimage/bin/java -Xlog:init=debug -m test/jdk.test.Test Error occurred during initialization of boot layer java.lang.InternalError: java.lang.ClassNotFoundException: jdk/internal/module/SystemModules$all at java.base/jdk.internal.module.SystemModuleFinders.systemModules(SystemModuleFinders.java:132) at java.base/jdk.internal.module.ModuleBootstrap.boot2(ModuleBootstrap.java:228) at java.base/jdk.internal.module.ModuleBootstrap.boot(ModuleBootstrap.java:174) at java.base/java.lang.System.initPhase2(System.java:2222) Caused by: java.lang.ClassNotFoundException: jdk/internal/module/SystemModules$all at java.base/java.lang.Class.forName0(Native Method) at java.base/java.lang.Class.forName(Class.java:391) at java.base/java.lang.Class.forName(Class.java:382) at java.base/jdk.internal.module.SystemModuleFinders.systemModules(SystemModuleFinders.java:129) ... 3 more ------------- PR: https://git.openjdk.org/jdk/pull/12944 From mchung at openjdk.org Wed Mar 15 22:37:30 2023 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 15 Mar 2023 22:37:30 GMT Subject: RFR: 8294972: Convert jdk.jlink internal plugins to use the Classfile API [v6] In-Reply-To: References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> Message-ID: On Wed, 15 Mar 2023 16:37:54 GMT, Adam Sotona wrote: >> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 614: >> >>> 612: private void genConstructor(ClassBuilder clb) { >>> 613: clb.withMethod("", MethodTypeDesc.of(CD_void), >>> 614: ACC_PUBLIC, mb -> mb.withFlags(ACC_PUBLIC).withCode( cob -> { >> >> Why `withFlags(ACC_PUBLIC)` when the flags is already given in `withMethod`'s 3rd argument? Same for occurrences below. > > It has been redundant, now more effective `withMethodBody` method is used. I also had the same comment in PR [12945](https://github.com/openjdk/jdk/pull/12945). Similar change should apply to PR 12945. ------------- PR: https://git.openjdk.org/jdk/pull/12944 From lmesnik at openjdk.org Wed Mar 15 22:49:57 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 15 Mar 2023 22:49:57 GMT Subject: RFR: 8303697: ProcessTools doesn't print last line of process output [v3] In-Reply-To: <2yj8kBz0HKn3QwV6awfX7bwl1IgBqBiRza-ABtJwCzo=.22255150-b358-4def-88a5-ed2ebc0de129@github.com> References: <2yj8kBz0HKn3QwV6awfX7bwl1IgBqBiRza-ABtJwCzo=.22255150-b358-4def-88a5-ed2ebc0de129@github.com> Message-ID: <442V2D4DoDQ4AOZyi4o-l-SEVx85z-KYeFGwDw5hJjM=.5b686eee-802a-4a6c-bce3-a128061fbaf5@github.com> > The StreamPumper is fixed to process the last line even it is not finishes with '\n' or '\r'. The test included. Testing with tier1-3 also to verify that tests are not broken. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: comments added ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13034/files - new: https://git.openjdk.org/jdk/pull/13034/files/7e0305d1..aa12782b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13034&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13034&range=01-02 Stats: 7 lines in 1 file changed: 5 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13034.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13034/head:pull/13034 PR: https://git.openjdk.org/jdk/pull/13034 From jvernee at openjdk.org Wed Mar 15 23:46:31 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 15 Mar 2023 23:46:31 GMT Subject: Integrated: 8303022: "assert(allocates2(pc)) failed: not in CodeBuffer memory" When linking downcall handle In-Reply-To: References: Message-ID: <31Rotf1DBSLQIaqV1yNIo0DmVi8aB3KXojPEGvrrj1w=.ed94ce07-7664-4efa-93e0-acb83dbb95d0@github.com> On Tue, 7 Mar 2023 18:02:41 GMT, Jorn Vernee wrote: > The issue is that the size of the code buffer is not large enough to hold the whole stub. > > Proposed solution is to scale the size of the stub with the number of arguments. I've adjusted sizes for both downcall and upcall stubs. I've also dropped the number of relocations, since we're not really using any for downcalls, and for upcalls we only have 1 AFAICS. (the size of the relocations can not be zero however, as that leads to the relocation section [not being initialized][1], and triggering [an assert][2] later when the code blob is copied). > > The way I've determined the new base size and per-argument size for stubs, is by first linking a stub without any arguments to get the required base size, and by then adding 20 `double` arguments to get a rough per-argument size. Both values have wiggle room as well. The sizes can be printed using e.g. `-XX:+LogCompilation`, and then looking for `nep_invoker_blob` and `upcall_stub*` in the log file. This experiment was done on a fastdebug build to account for additional debug code being generated. The included test is designed to try and maximize the size of the generated stub. > > I've also updated `CodeBuffer::log_section_sizes` to print the in-use size, rather than just the capacity and free space. > > [1]: https://github.com/openjdk/jdk/blob/56512cfe1f0682c98ba3488af3d03ccef632c016/src/hotspot/share/asm/codeBuffer.cpp#L119-L121 > [2]: https://github.com/openjdk/jdk/blob/56512cfe1f0682c98ba3488af3d03ccef632c016/src/hotspot/share/asm/codeBuffer.cpp#L675 This pull request has now been integrated. Changeset: 2b81faeb Author: Jorn Vernee URL: https://git.openjdk.org/jdk/commit/2b81faeb3514060e6c8c950ef4e39e299c43199d Stats: 102 lines in 8 files changed: 81 ins; 0 del; 21 mod 8303022: "assert(allocates2(pc)) failed: not in CodeBuffer memory" When linking downcall handle Reviewed-by: kvn, vlivanov ------------- PR: https://git.openjdk.org/jdk/pull/12908 From mchung at openjdk.org Thu Mar 16 02:46:29 2023 From: mchung at openjdk.org (Mandy Chung) Date: Thu, 16 Mar 2023 02:46:29 GMT Subject: RFR: 8294972: Convert jdk.jlink internal plugins to use the Classfile API [v8] In-Reply-To: References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> Message-ID: On Wed, 15 Mar 2023 16:42:53 GMT, Adam Sotona wrote: >> jdk.jlink internal plugins are heavily using ASM >> >> This patch converts ASM calls to Classfile API. >> >> Please review. >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > fixed SystemModulesPlugin src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/IncludeLocalesPlugin.java line 160: > 158: resource.type().equals(ResourcePoolEntry.Type.CLASS_OR_RESOURCE)) { > 159: byte[] bytes = resource.contentBytes(); > 160: if (newClassReader(path, bytes).interfaces().stream() `IncludeLocalesPluginTest.java` test is failing. Adding `-J-Djlink.debug=true` will get the stack trace: Failed to parse class file: /jdk.localedata/sun/text/resources/ext/LineBreakIteratorData_th java.lang.IllegalStateException: Bad magic number at java.base/jdk.internal.classfile.impl.ClassReaderImpl.(ClassReaderImpl.java:94) at java.base/jdk.internal.classfile.impl.ClassImpl.(ClassImpl.java:68) at java.base/jdk.internal.classfile.Classfile.parse(Classfile.java:165) at jdk.jlink/jdk.tools.jlink.internal.plugins.AbstractPlugin.newClassReader(AbstractPlugin.java:105) at jdk.jlink/jdk.tools.jlink.internal.plugins.IncludeLocalesPlugin.lambda$transform$5(IncludeLocalesPlugin.java:161) at jdk.jlink/jdk.tools.jlink.plugin.ResourcePool.lambda$transformAndCopy$0(ResourcePool.java:112) at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133) at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1924) at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762) at jdk.jlink/jdk.tools.jlink.plugin.ResourcePool.transformAndCopy(ResourcePool.java:111) at jdk.jlink/jdk.tools.jlink.internal.plugins.IncludeLocalesPlugin.transform(IncludeLocalesPlugin.java:154) at jdk.jlink/jdk.tools.jlink.internal.ImagePluginStack.visitResources(ImagePluginStack.java:262) at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.generateJImage(ImageFileCreator.java:184) at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.writeImage(ImageFileCreator.java:163) at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.create(ImageFileCreator.java:100) at jdk.jlink/jdk.tools.jlink.internal.JlinkTask$ImageHelper.retrieve(JlinkTask.java:889) at jdk.jlink/jdk.tools.jlink.internal.ImagePluginStack.operate(ImagePluginStack.java:194) at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImage(JlinkTask.java:452) at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:292) at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:56) at jdk.jlink/jdk.tools.jlink.internal.Main.main(Main.java:34) Dumping class file 26549-include-locales//jdk.localedata/sun/text/resources/ext/LineBreakIteratorData_th java.lang.IllegalStateException: Bad magic number at java.base/jdk.internal.classfile.impl.ClassReaderImpl.(ClassReaderImpl.java:94) at java.base/jdk.internal.classfile.impl.ClassImpl.(ClassImpl.java:68) at java.base/jdk.internal.classfile.Classfile.parse(Classfile.java:165) at jdk.jlink/jdk.tools.jlink.internal.plugins.AbstractPlugin.newClassReader(AbstractPlugin.java:105) at jdk.jlink/jdk.tools.jlink.internal.plugins.IncludeLocalesPlugin.lambda$transform$5(IncludeLocalesPlugin.java:161) at jdk.jlink/jdk.tools.jlink.plugin.ResourcePool.lambda$transformAndCopy$0(ResourcePool.java:112) at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133) at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1924) at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762) at jdk.jlink/jdk.tools.jlink.plugin.ResourcePool.transformAndCopy(ResourcePool.java:111) at jdk.jlink/jdk.tools.jlink.internal.plugins.IncludeLocalesPlugin.transform(IncludeLocalesPlugin.java:154) at jdk.jlink/jdk.tools.jlink.internal.ImagePluginStack.visitResources(ImagePluginStack.java:262) at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.generateJImage(ImageFileCreator.java:184) at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.writeImage(ImageFileCreator.java:163) at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.create(ImageFileCreator.java:100) at jdk.jlink/jdk.tools.jlink.internal.JlinkTask$ImageHelper.retrieve(JlinkTask.java:889) at jdk.jlink/jdk.tools.jlink.internal.ImagePluginStack.operate(ImagePluginStack.java:194) at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImage(JlinkTask.java:452) at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:292) at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:56) at jdk.jlink/jdk.tools.jlink.internal.Main.main(Main.java:34) ``` Apparently `/jdk.localedata/sun/text/resources/ext/LineBreakIteratorData_th` is not a valid class file. Using ASM `ClassReader` to parse this resource file succeeds because it does not do much of the class file validation. Instead the ClassFile API throws `IllegalStateException` as it has a bad magic number. @naotoj what is the file format of this `LineBreakIteratorData_th` file? ------------- PR: https://git.openjdk.org/jdk/pull/12944 From dholmes at openjdk.org Thu Mar 16 04:43:22 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 16 Mar 2023 04:43:22 GMT Subject: RFR: 8303697: ProcessTools doesn't print last line of process output [v3] In-Reply-To: <442V2D4DoDQ4AOZyi4o-l-SEVx85z-KYeFGwDw5hJjM=.5b686eee-802a-4a6c-bce3-a128061fbaf5@github.com> References: <2yj8kBz0HKn3QwV6awfX7bwl1IgBqBiRza-ABtJwCzo=.22255150-b358-4def-88a5-ed2ebc0de129@github.com> <442V2D4DoDQ4AOZyi4o-l-SEVx85z-KYeFGwDw5hJjM=.5b686eee-802a-4a6c-bce3-a128061fbaf5@github.com> Message-ID: <7a55yrOkgaBFFSRs_4gRTos5baERHoFuaXu4J29ioWI=.b35f6aa7-0102-4ca0-83d7-e1abe66800fb@github.com> On Wed, 15 Mar 2023 22:49:57 GMT, Leonid Mesnik wrote: >> The StreamPumper is fixed to process the last line even it is not finishes with '\n' or '\r'. The test included. Testing with tier1-3 also to verify that tests are not broken. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > comments added A few minor suggestions. The additional commentary is very helpful. Figuring out exactly how this code works is painful. Thanks. test/lib-test/jdk/test/lib/process/ProcessToolsLastLineTest.java line 50: > 48: > 49: // The line which exceeds internal StreamPumper buffer (256 bytes) > 50: String VERY_LONG_LINE = "VERYLONGLINE".repeat(30); It might be a bit more obvious that this does exceed 256 by simply doing: String veryLongLine = "X".repeat(257); test/lib-test/jdk/test/lib/process/ProcessToolsLastLineTest.java line 54: > 52: System.out.print(args[0]); > 53: } else { > 54: test("ARG1"); Some boundary testing here would be: test("\n"); test("\nARG1"); test("\nARG1\n"); test("ARG1/n"); test("ARG1"); test/lib/jdk/test/lib/process/StreamPumper.java line 99: > 97: * Implements Thread.run(). Continuously read from {@code in} and write to > 98: * {@code out} until {@code in} has reached end of stream. > 99: * Additionally this method also split data read from buffer into the lines and process each line using linePumps. A few grammatical nits. I suggest: > Additionally this method also splits the data read from the buffer into lines, and processes each line using linePumps. test/lib/jdk/test/lib/process/StreamPumper.java line 138: > 136: } > 137: // The remaining after last '\n' (lastcrlf position) buffer data is written into lineBos. > 138: // The end of this line from next buffer is concatenated to this data in the next iteration. In trying to help my own understanding here I suggest: // If no crlf was found, or there was additional data after the last crlf was found, then write the leftover data // in lineBos. If there is more data to read it will be concatenated with the current data on the next iteration. // If there is no more data, or no more crlf found, all the remaining data will be processed after the loop, as the // final line. test/lib/jdk/test/lib/process/StreamPumper.java line 149: > 147: } > 148: // Process data remaining after last '\n' in the last buffer. > 149: // It is already written in the lineBos buffer but not processed because '\n' hasn't been met. Suggestion: // If there was no terminating crlf the remaining data has been written to lineBos, but this final line of data // now needs to be processed by the linePumper. ------------- PR: https://git.openjdk.org/jdk/pull/13034 From dholmes at openjdk.org Thu Mar 16 04:43:26 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 16 Mar 2023 04:43:26 GMT Subject: RFR: 8303697: ProcessTools doesn't print last line of process output [v2] In-Reply-To: References: <2yj8kBz0HKn3QwV6awfX7bwl1IgBqBiRza-ABtJwCzo=.22255150-b358-4def-88a5-ed2ebc0de129@github.com> Message-ID: On Wed, 15 Mar 2023 14:23:43 GMT, Leonid Mesnik wrote: >> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed test > > test/lib/jdk/test/lib/process/StreamPumper.java line 145: > >> 143: } >> 144: } >> 145: final String line = lineBos.toString(); > > The code in 'lastcrlf == -1' as well as in 'lastcrlf < len - 1' writes remaining buf into lineBos. This lineBos is used to make line which is processed in line 127. > However, if the stream is emptied then the chunk after last '\n' is written in in the lineBos but we never reach line 127 to call processLine for it. Thanks for the additional offline explanations about this code. ------------- PR: https://git.openjdk.org/jdk/pull/13034 From sspitsyn at openjdk.org Thu Mar 16 05:24:59 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 16 Mar 2023 05:24:59 GMT Subject: RFR: 8304303: implement VirtualThread class notifyJvmti methods as C2 intrinsics Message-ID: <-Pt3zLSu1Y2GYeM8XEivglUyDVXlAqMIA42-_zEnHlo=.7dd40f19-160a-4f11-8702-99c69a9b9923@github.com> This is needed for performance improvements in support of virtual threads. The update includes the following: 1. Refactored the `VirtualThread` native methods: `notifyJvmtiMountBegin` and `notifyJvmtiMountEnd` => `notifyJvmtiMount` `notifyJvmtiUnmountBegin` and `notifyJvmtiUnmountEnd` => `notifyJvmtiUnmount` 2. Still useful implementation of old native methods is moved from `jvm.cpp` to `jvmtiThreadState.cpp`: `JVM_VirtualThreadMountStart` => `VTMS_mount_begin` `JVM_VirtualThreadMountEnd` => `VTMS_mount_end` `JVM_VirtualThreadUnmountStart` = > `VTMS_unmount_begin` `JVM_VirtualThreadUnmountEnd` => `VTMS_mount_end` 3. Intrinsified the `VirtualThread` native methods: `notifyJvmtiMount`, `notifyJvmtiUnmount`, `notifyJvmtiHideFrames`. 4. Removed the`VirtualThread` static boolean state variable `notifyJvmtiEvents` and its support in `javaClasses`. 5. Added static boolean state variable `_VTMS_notify_jvmti_events` to the jvmtiVTMSTransitionDisabler class as a replacement of the `VirtualThread` `notifyJvmtiEvents` variable. Implementing the same methods as C1 intrinsics can be needed in the future but is a low priority for now. Testing: - Ran mach5 tiers 1-6. No regressions were found. ------------- Commit messages: - fix traling spaces in a couple of files - minor update for VTMS_notify_jvmti_events variable - 8304303: implement VirtualThread class notifyJvmti methods as C2 intrinsics Changes: https://git.openjdk.org/jdk/pull/13054/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13054&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304303 Stats: 438 lines in 20 files changed: 265 ins; 125 del; 48 mod Patch: https://git.openjdk.org/jdk/pull/13054.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13054/head:pull/13054 PR: https://git.openjdk.org/jdk/pull/13054 From tobias.hartmann at oracle.com Thu Mar 16 06:20:33 2023 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 16 Mar 2023 07:20:33 +0100 Subject: jtreg test test/jdk/java/lang/StackWalker/StackWalkTest.java fails after jtreg commit 7903373 In-Reply-To: References: Message-ID: <4847e074-5a12-7a33-a9fb-d7e412943078@oracle.com> Hi Kosta, Thanks again for the report! This test is owned by core-libs/java.lang, I'm forwarding to core-libs-dev and CC'ing Leonid, the author of https://bugs.openjdk.org/browse/CODETOOLS-7903373. I can see these failures in our testing as well but no one filed a bug yet. I filed: https://bugs.openjdk.org/browse/JDK-8304314 Best regards, Tobias On 15.03.23 22:40, Kosta Stojiljkovic wrote: > Dear all, > > The test in ..test/jdk/java/lang/StackWalker/StackWalkTest.java fails with the latest jtreg build, with the following error: > > ... > recursion chain > ... > ... > ... > at StackWalkTest$Test.call(StackWalkTest.java:223) > at StackWalkTest.runTest(StackWalkTest.java:270) > at StackWalkTest.main(StackWalkTest.java:325) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) > at java.base/java.lang.reflect.Method.invoke(Method.java:578) > at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) > at java.base/java.lang.Thread.run(Thread.java:1623) > Caused by: java.lang.IndexOutOfBoundsException: Index: 1004, Size: 1004 > at java.base/java.util.LinkedList.checkElementIndex(LinkedList.java:559) > at java.base/java.util.LinkedList.get(LinkedList.java:480) > at StackRecorderUtil.compareFrame(StackRecorderUtil.java:64) > at StackWalkTest.consume(StackWalkTest.java:145) > ... 1018 more > > JavaTest Message: Test threw exception: java.lang.RuntimeException: extra non-infra stack frame at count 1004: > > --------------------------- > > In essence, the test detects an extra non-infra stack frame for the MainWrapper$MainTask's frame. The test should disregard MainTask's stack frame, since it's coming from an infrastructure class - com.sun.javatest.regtest.agent.MainWrapper. The code correctly checks if the stack frame belongs to the mentioned infrastructure class, but it also looks for the inner class - com.sun.javatest.regtest.agent.MainWrapper$MainThread. > > I believe the problem comes from the following commit (7903373) to the jtreg repository: https://github.com/openjdk/jtreg/commit/5b9e661eb6ee9dd9a9d2690986bbf9ce303a8f03 > > This commit changed the name of the class MainThread to MainTask, thus making the hardcoded check in the StackWalkTest fail to recognize this extra stack frame as an infra frame. > > Could you please try to reproduce and let me know if I am missing or misunderstanding something. > > Best, > Kosta Stojiljkovic From stuefe at openjdk.org Thu Mar 16 06:22:21 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 16 Mar 2023 06:22:21 GMT Subject: RFR: 8303697: ProcessTools doesn't print last line of process output [v3] In-Reply-To: <442V2D4DoDQ4AOZyi4o-l-SEVx85z-KYeFGwDw5hJjM=.5b686eee-802a-4a6c-bce3-a128061fbaf5@github.com> References: <2yj8kBz0HKn3QwV6awfX7bwl1IgBqBiRza-ABtJwCzo=.22255150-b358-4def-88a5-ed2ebc0de129@github.com> <442V2D4DoDQ4AOZyi4o-l-SEVx85z-KYeFGwDw5hJjM=.5b686eee-802a-4a6c-bce3-a128061fbaf5@github.com> Message-ID: On Wed, 15 Mar 2023 22:49:57 GMT, Leonid Mesnik wrote: >> The StreamPumper is fixed to process the last line even it is not finishes with '\n' or '\r'. The test included. Testing with tier1-3 also to verify that tests are not broken. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > comments added That also affects OutputAnalyzer, right? Does this affect parsing or is this only printing? Anyway, patch looks good to me, modulo of what David wrote. If you fix his remarks, its good to me. ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.org/jdk/pull/13034 From sspitsyn at openjdk.org Thu Mar 16 07:11:00 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 16 Mar 2023 07:11:00 GMT Subject: RFR: 8304303: implement VirtualThread class notifyJvmti methods as C2 intrinsics [v2] In-Reply-To: <-Pt3zLSu1Y2GYeM8XEivglUyDVXlAqMIA42-_zEnHlo=.7dd40f19-160a-4f11-8702-99c69a9b9923@github.com> References: <-Pt3zLSu1Y2GYeM8XEivglUyDVXlAqMIA42-_zEnHlo=.7dd40f19-160a-4f11-8702-99c69a9b9923@github.com> Message-ID: > This is needed for performance improvements in support of virtual threads. > The update includes the following: > > 1. Refactored the `VirtualThread` native methods: > `notifyJvmtiMountBegin` and `notifyJvmtiMountEnd` => `notifyJvmtiMount` > `notifyJvmtiUnmountBegin` and `notifyJvmtiUnmountEnd` => `notifyJvmtiUnmount` > 2. Still useful implementation of old native methods is moved from `jvm.cpp` to `jvmtiThreadState.cpp`: > `JVM_VirtualThreadMountStart` => `VTMS_mount_begin` > `JVM_VirtualThreadMountEnd` => `VTMS_mount_end` > `JVM_VirtualThreadUnmountStart` = > `VTMS_unmount_begin` > `JVM_VirtualThreadUnmountEnd` => `VTMS_mount_end` > 3. Intrinsified the `VirtualThread` native methods: `notifyJvmtiMount`, `notifyJvmtiUnmount`, `notifyJvmtiHideFrames`. > 4. Removed the`VirtualThread` static boolean state variable `notifyJvmtiEvents` and its support in `javaClasses`. > 5. Added static boolean state variable `_VTMS_notify_jvmti_events` to the jvmtiVTMSTransitionDisabler class as a replacement of the `VirtualThread` `notifyJvmtiEvents` variable. > > Implementing the same methods as C1 intrinsics can be needed in the future but is a low priority for now. > > Testing: > - Ran mach5 tiers 1-6. No regressions were found. Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: include jniHandles.hpp into sharedRuntime.cpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13054/files - new: https://git.openjdk.org/jdk/pull/13054/files/8a379320..397b6337 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13054&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13054&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13054.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13054/head:pull/13054 PR: https://git.openjdk.org/jdk/pull/13054 From asotona at openjdk.org Thu Mar 16 07:54:32 2023 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 16 Mar 2023 07:54:32 GMT Subject: RFR: 8294972: Convert jdk.jlink internal plugins to use the Classfile API [v8] In-Reply-To: References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> Message-ID: On Thu, 16 Mar 2023 02:43:39 GMT, Mandy Chung wrote: >> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed SystemModulesPlugin > > src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/IncludeLocalesPlugin.java line 160: > >> 158: resource.type().equals(ResourcePoolEntry.Type.CLASS_OR_RESOURCE)) { >> 159: byte[] bytes = resource.contentBytes(); >> 160: if (newClassReader(path, bytes).interfaces().stream() > > `IncludeLocalesPluginTest.java` test is failing. Adding `-J-Djlink.debug=true` will get the stack trace: > > > Failed to parse class file: /jdk.localedata/sun/text/resources/ext/LineBreakIteratorData_th > java.lang.IllegalStateException: Bad magic number > at java.base/jdk.internal.classfile.impl.ClassReaderImpl.(ClassReaderImpl.java:94) > at java.base/jdk.internal.classfile.impl.ClassImpl.(ClassImpl.java:68) > at java.base/jdk.internal.classfile.Classfile.parse(Classfile.java:165) > at jdk.jlink/jdk.tools.jlink.internal.plugins.AbstractPlugin.newClassReader(AbstractPlugin.java:105) > at jdk.jlink/jdk.tools.jlink.internal.plugins.IncludeLocalesPlugin.lambda$transform$5(IncludeLocalesPlugin.java:161) > at jdk.jlink/jdk.tools.jlink.plugin.ResourcePool.lambda$transformAndCopy$0(ResourcePool.java:112) > at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133) > at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1924) > at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762) > at jdk.jlink/jdk.tools.jlink.plugin.ResourcePool.transformAndCopy(ResourcePool.java:111) > at jdk.jlink/jdk.tools.jlink.internal.plugins.IncludeLocalesPlugin.transform(IncludeLocalesPlugin.java:154) > at jdk.jlink/jdk.tools.jlink.internal.ImagePluginStack.visitResources(ImagePluginStack.java:262) > at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.generateJImage(ImageFileCreator.java:184) > at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.writeImage(ImageFileCreator.java:163) > at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.create(ImageFileCreator.java:100) > at jdk.jlink/jdk.tools.jlink.internal.JlinkTask$ImageHelper.retrieve(JlinkTask.java:889) > at jdk.jlink/jdk.tools.jlink.internal.ImagePluginStack.operate(ImagePluginStack.java:194) > at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImage(JlinkTask.java:452) > at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:292) > at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:56) > at jdk.jlink/jdk.tools.jlink.internal.Main.main(Main.java:34) > Dumping class file 26549-include-locales//jdk.localedata/sun/text/resources/ext/LineBreakIteratorData_th > ``` > > Apparently `/jdk.localedata/sun/text/resources/ext/LineBreakIteratorData_th` is not a valid class file. Using ASM `ClassReader` to parse this resource file succeeds because it does not do much of the class file validation. Instead the ClassFile API throws `IllegalStateException` as it has a bad magic number. > > @naotoj what is the file format of this `LineBreakIteratorData_th` file? This plugin does not fit to the Classfile API use cases portfolio at all. Here it is only needed to get interfaces list out of the constant pool and then the Utf8 CP entries are in-place modified. That is out of the Classfile API or ASM capabilities. Bad magic number is not the only difference, both libraries fail whenever touching even headers of any other standard classfile elements, only constant pool and interfaces seem to be "safe". I can prepare very simple standalone helper class dealing with this case to remove ASM dependency. However knowing more about the file format is always useful :) ------------- PR: https://git.openjdk.org/jdk/pull/12944 From asotona at openjdk.org Thu Mar 16 08:04:29 2023 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 16 Mar 2023 08:04:29 GMT Subject: RFR: 8294972: Convert jdk.jlink internal plugins to use the Classfile API [v8] In-Reply-To: References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> Message-ID: <1dQeb877u95GXqbNlCfF4mkOuL8kK_Ghdtp0pRTpAeU=.92c11524-264c-48fb-b75c-6d5f95cbca4a@github.com> On Wed, 15 Mar 2023 22:31:01 GMT, Mandy Chung wrote: > What was the issue with the previous revision? The only conversion bug I found during the code reformat/revision was missing `className.replace('/', '.')` and after that the test pass. https://github.com/openjdk/jdk/blob/49c80bcd9ad6ddd85cffc4176ad8b070105eb3f3/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java#L1746 ------------- PR: https://git.openjdk.org/jdk/pull/12944 From pminborg at openjdk.org Thu Mar 16 08:21:55 2023 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 16 Mar 2023 08:21:55 GMT Subject: RFR: 8304283: Modernize the switch statements in jdk.internal.foreign [v2] In-Reply-To: <69yyuUfAG5P3fNCzQ44xtTBqWQEZbdqfQS3Z-u9Vk6w=.d94b0b09-197c-4992-b7ff-a9f943ef3b59@github.com> References: <69yyuUfAG5P3fNCzQ44xtTBqWQEZbdqfQS3Z-u9Vk6w=.d94b0b09-197c-4992-b7ff-a9f943ef3b59@github.com> Message-ID: > This PR proposes changing old-type switch statements to newer forms of switch. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Reintroduce missing comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13047/files - new: https://git.openjdk.org/jdk/pull/13047/files/779d1ee2..e9b157e7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13047&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13047&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13047.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13047/head:pull/13047 PR: https://git.openjdk.org/jdk/pull/13047 From duke at openjdk.org Thu Mar 16 08:22:15 2023 From: duke at openjdk.org (Varada M) Date: Thu, 16 Mar 2023 08:22:15 GMT Subject: RFR: 8304320: java.base does not export jdk.internal.org.objectweb.asm to module jdk.jshell Message-ID: jdk/test/jdk/tools/jimage/VerifyJimage.java is failing because the module java.base is not exporting jdk.internal.org.objectweb.asm to module jdk.jshell. Reported Issue : [JDK-8304320](https://bugs.openjdk.org/browse/JDK-8304320) ------------- Commit messages: - exporting jdk.internal.org.objectweb.asm to module jdk.jshell Changes: https://git.openjdk.org/jdk/pull/13057/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13057&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304320 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13057.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13057/head:pull/13057 PR: https://git.openjdk.org/jdk/pull/13057 From mdoerr at openjdk.org Thu Mar 16 08:36:39 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Thu, 16 Mar 2023 08:36:39 GMT Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function & Memory API (Preview) [v16] In-Reply-To: References: Message-ID: On Tue, 14 Mar 2023 22:52:44 GMT, Martin Doerr wrote: >> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix storing 32 bit integers into Java frames. Enable TestArrayStructs. > > Btw. the new cases in which we use int and short accesses when byteWidth is not a power of 2 are never unaligned AFAICS. I guess _UNALIGNED is unnecessary in the JAVA_INT_UNALIGNED and JAVA_SHORT_UNALIGNED. They are always aligned wrt. to their size. > @TheRealMDoerr I've approved the PR. I suggest for a second reviewer to try and get someone who knows the PPC port. Thanks for the review! I guess I should also wait for your 2 PRs to be integrated, so I can merge and adapt. ------------- PR: https://git.openjdk.org/jdk/pull/12708 From alanb at openjdk.org Thu Mar 16 08:46:20 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 16 Mar 2023 08:46:20 GMT Subject: RFR: 8304320: java.base does not export jdk.internal.org.objectweb.asm to module jdk.jshell In-Reply-To: References: Message-ID: On Thu, 16 Mar 2023 08:14:25 GMT, Varada M wrote: > jdk/test/jdk/tools/jimage/VerifyJimage.java is failing because the module java.base is not exporting jdk.internal.org.objectweb.asm to module jdk.jshell. > > Reported Issue : [JDK-8304320](https://bugs.openjdk.org/browse/JDK-8304320) jshell was migrated to new the class file API in JDK-8294974 so it shouldn't have any references to ASM anymore. Would it be possible to check if you have a mismatch between your build and the test? ------------- PR: https://git.openjdk.org/jdk/pull/13057 From mbaesken at openjdk.org Thu Mar 16 09:08:08 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 16 Mar 2023 09:08:08 GMT Subject: RFR: JDK-8304063: tools/jpackage/share/AppLauncherEnvTest.java fails when checking LD_LIBRARY_PATH [v2] In-Reply-To: References: Message-ID: > The test fails on Alpine Linux 3.17, when checking the environment variable LD_LIBRARY_PATH; looks like the actual env variable is much longer than the test expects. It turned out that at least on Linux (probably also on other OS like AIX) the actual env variable has the expected string at it's end, but might contain more path entries ( LD_LIBRARY_PATH can be adjusted by jvm - https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/libjli/java_md.c ). Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: redo check ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13041/files - new: https://git.openjdk.org/jdk/pull/13041/files/ce1890fc..d1066109 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13041&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13041&range=00-01 Stats: 9 lines in 1 file changed: 1 ins; 4 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/13041.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13041/head:pull/13041 PR: https://git.openjdk.org/jdk/pull/13041 From mbaesken at openjdk.org Thu Mar 16 09:08:10 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 16 Mar 2023 09:08:10 GMT Subject: RFR: JDK-8304063: tools/jpackage/share/AppLauncherEnvTest.java fails when checking LD_LIBRARY_PATH [v2] In-Reply-To: References: Message-ID: On Wed, 15 Mar 2023 18:37:51 GMT, Alexey Semenyuk wrote: >> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: >> >> redo check > > test/jdk/tools/jpackage/share/AppLauncherEnvTest.java line 93: > >> 91: } else { >> 92: TKit.assertEquals(expectedEnvVarValue, actualEnvVarValue, msg); >> 93: } > > I'd keep the check as a single statement: > > TKit.assertTextStream(expectedEnvVarValue) > .predicate(TKit.isLinux() ? String::endsWith : String::equals) > .label(String.format("value of %s env variable", envVarName)) > .apply(Stream.of(actualEnvVarValue)); > > > It also will produce a nicer log record than `TKit.assertTrue(false, msg);` Hi Alexey, I adjusted the check following your advice . ------------- PR: https://git.openjdk.org/jdk/pull/13041 From mcimadamore at openjdk.org Thu Mar 16 09:43:20 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 16 Mar 2023 09:43:20 GMT Subject: RFR: 8304283: Modernize the switch statements in jdk.internal.foreign [v2] In-Reply-To: References: <69yyuUfAG5P3fNCzQ44xtTBqWQEZbdqfQS3Z-u9Vk6w=.d94b0b09-197c-4992-b7ff-a9f943ef3b59@github.com> Message-ID: <5W-zmDHlDg19PeFDURP4n6LNMgt09O-JEMe2VGx11dU=.d883870c-fb2d-4f85-8ae8-190beec18498@github.com> On Wed, 15 Mar 2023 19:38:53 GMT, Jorn Vernee wrote: >> Per Minborg has updated the pull request incrementally with one additional commit since the last revision: >> >> Reintroduce missing comment > > src/java.base/share/classes/jdk/internal/foreign/abi/CallingSequenceBuilder.java line 219: > >> 217: case Binding.Cast unused-> true; >> 218: }; >> 219: } > > I'd go a bit further here and visually organize the cases as well. Also, using a static import for `Binding.*`: > > Suggestion: > > static boolean isUnbox(Binding binding) { > return switch (binding) { > case VMStore unused -> true; > case BufferLoad unused -> true; > case Copy unused -> true; > case UnboxAddress unused -> true; > case Dup unused -> true; > case Cast unused -> true; > > case VMLoad unused -> false; > case BufferStore unused -> false; > case Allocate unused -> false; > case BoxAddress unused -> false; > }; > } > > > It's a bit unfortunate that we need variable names as well. While I agree that some "visitor" methods would be better dealt with using patterns, I remain unconvinced about the box/unbox classification being modeled as an "operation". That's because it's a static property of the binding - e.g. given a binding you know whether it can be used for box/unbox/both/none. If this was an enum, I would encode it as a boolean field and never look back. Also note how the javadoc for Binding itself makes quite a lot of comments on box/unbox nature of bindings, and how they can have different semantics depending on the direction. To me it feels like that distinction is a first class citizen in Binding. Perhaps, pulling together the various strings, it would maybe possible to define very simple records for the various bindings, with no verification and interpretation code (e.g. leave that to some pattern-based visitor somewhere else). But I think I would still expect a binding class to know whether it's used for unbox or not w/o having to run a complex operation all the time (given that the property is a constant of the binding class). The fact that we're using records for bindings and we can't have an abstract class also biases the decision a bit (otherwise we could simply use a bunch of constructor parameters to encode the box/unbox properties). That said, this is all subjective. I don't have super strong opinion on this. The code above looks a tad odd to me, but I can live with it. ------------- PR: https://git.openjdk.org/jdk/pull/13047 From asotona at openjdk.org Thu Mar 16 10:21:03 2023 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 16 Mar 2023 10:21:03 GMT Subject: RFR: 8294972: Convert jdk.jlink internal plugins to use the Classfile API [v9] In-Reply-To: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> Message-ID: <2FC_ZpxPPtdxf2jtZNRgPiB_Pcegq_aaZdk0_ugIGZw=.5dba06ac-19d9-4d54-8252-dcf674ef2121@github.com> > jdk.jlink internal plugins are heavily using ASM > > This patch converts ASM calls to Classfile API. > > Please review. > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: implementation of custom ResourceHelper in IncludeLocalesPlugin ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12944/files - new: https://git.openjdk.org/jdk/pull/12944/files/49c80bcd..ee508f78 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12944&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12944&range=07-08 Stats: 87 lines in 1 file changed: 49 ins; 19 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/12944.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12944/head:pull/12944 PR: https://git.openjdk.org/jdk/pull/12944 From asotona at openjdk.org Thu Mar 16 10:47:01 2023 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 16 Mar 2023 10:47:01 GMT Subject: RFR: 8294972: Convert jdk.jlink internal plugins to use the Classfile API [v10] In-Reply-To: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> Message-ID: > jdk.jlink internal plugins are heavily using ASM > > This patch converts ASM calls to Classfile API. > > Please review. > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: remaining cleanup in SystemModulesPlugin ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12944/files - new: https://git.openjdk.org/jdk/pull/12944/files/ee508f78..3dbe1e57 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12944&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12944&range=08-09 Stats: 34 lines in 1 file changed: 1 ins; 1 del; 32 mod Patch: https://git.openjdk.org/jdk/pull/12944.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12944/head:pull/12944 PR: https://git.openjdk.org/jdk/pull/12944 From pminborg at openjdk.org Thu Mar 16 11:25:18 2023 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 16 Mar 2023 11:25:18 GMT Subject: RFR: 8304283: Modernize the switch statements in jdk.internal.foreign [v2] In-Reply-To: <5W-zmDHlDg19PeFDURP4n6LNMgt09O-JEMe2VGx11dU=.d883870c-fb2d-4f85-8ae8-190beec18498@github.com> References: <69yyuUfAG5P3fNCzQ44xtTBqWQEZbdqfQS3Z-u9Vk6w=.d94b0b09-197c-4992-b7ff-a9f943ef3b59@github.com> <5W-zmDHlDg19PeFDURP4n6LNMgt09O-JEMe2VGx11dU=.d883870c-fb2d-4f85-8ae8-190beec18498@github.com> Message-ID: On Thu, 16 Mar 2023 09:40:30 GMT, Maurizio Cimadamore wrote: >> src/java.base/share/classes/jdk/internal/foreign/abi/CallingSequenceBuilder.java line 219: >> >>> 217: case Binding.Cast unused-> true; >>> 218: }; >>> 219: } >> >> I'd go a bit further here and visually organize the cases as well. Also, using a static import for `Binding.*`: >> >> Suggestion: >> >> static boolean isUnbox(Binding binding) { >> return switch (binding) { >> case VMStore unused -> true; >> case BufferLoad unused -> true; >> case Copy unused -> true; >> case UnboxAddress unused -> true; >> case Dup unused -> true; >> case Cast unused -> true; >> >> case VMLoad unused -> false; >> case BufferStore unused -> false; >> case Allocate unused -> false; >> case BoxAddress unused -> false; >> }; >> } >> >> >> It's a bit unfortunate that we need variable names as well. > > While I agree that some "visitor" methods would be better dealt with using patterns, I remain unconvinced about the box/unbox classification being modeled as an "operation". That's because it's a static property of the binding - e.g. given a binding you know whether it can be used for box/unbox/both/none. If this was an enum, I would encode it as a boolean field and never look back. Also note how the javadoc for Binding itself makes quite a lot of comments on box/unbox nature of bindings, and how they can have different semantics depending on the direction. To me it feels like that distinction is a first class citizen in Binding. > > Perhaps, pulling together the various strings, it would maybe possible to define very simple records for the various bindings, with no verification and interpretation code (e.g. leave that to some pattern-based visitor somewhere else). But I think I would still expect a binding class to know whether it's used for unbox or not w/o having to run a complex operation all the time (given that the property is a constant of the binding class). The fact that we're using records for bindings and we can't have an abstract class also biases the decision a bit (otherwise we could simply use a bunch of constructor parameters to encode the box/unbox properties). > > That said, this is all subjective. I don't have super strong opinion on this. The code above looks a tad odd to me, but I can live with it. I've spoken to the Amber persons and soon we will be able to do: static boolean isBox(Binding binding) { return switch (binding) { case VMLoad _, Copy _, Allocate _, BoxAddress _, BufferStore _, Dup _, Cast _-> true; case VMStore _, BufferLoad _, UnboxAddress _ -> false; }; } ------------- PR: https://git.openjdk.org/jdk/pull/13047 From pminborg at openjdk.org Thu Mar 16 11:25:21 2023 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 16 Mar 2023 11:25:21 GMT Subject: RFR: 8304283: Modernize the switch statements in jdk.internal.foreign [v2] In-Reply-To: References: <69yyuUfAG5P3fNCzQ44xtTBqWQEZbdqfQS3Z-u9Vk6w=.d94b0b09-197c-4992-b7ff-a9f943ef3b59@github.com> Message-ID: On Wed, 15 Mar 2023 18:34:50 GMT, Maurizio Cimadamore wrote: >> Per Minborg has updated the pull request incrementally with one additional commit since the last revision: >> >> Reintroduce missing comment > > src/java.base/share/classes/jdk/internal/foreign/abi/riscv64/linux/TypeClass.java line 112: > >> 110: return flatten(sequenceLayout.elementLayout()).mul(elementCount); >> 111: } >> 112: case null, default -> throw new IllegalStateException("Cannot get here: " + layout); > > Since the default throws, and the switch w/o a `case null` also throws, do we need the `case null` here? No. Null is not needed. I will remove it. ------------- PR: https://git.openjdk.org/jdk/pull/13047 From pminborg at openjdk.org Thu Mar 16 12:07:48 2023 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 16 Mar 2023 12:07:48 GMT Subject: RFR: 8304283: Modernize the switch statements in jdk.internal.foreign [v3] In-Reply-To: <69yyuUfAG5P3fNCzQ44xtTBqWQEZbdqfQS3Z-u9Vk6w=.d94b0b09-197c-4992-b7ff-a9f943ef3b59@github.com> References: <69yyuUfAG5P3fNCzQ44xtTBqWQEZbdqfQS3Z-u9Vk6w=.d94b0b09-197c-4992-b7ff-a9f943ef3b59@github.com> Message-ID: > This PR proposes changing old-type switch statements to newer forms of switch. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Update after comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13047/files - new: https://git.openjdk.org/jdk/pull/13047/files/e9b157e7..f20f3516 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13047&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13047&range=01-02 Stats: 37 lines in 2 files changed: 12 ins; 0 del; 25 mod Patch: https://git.openjdk.org/jdk/pull/13047.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13047/head:pull/13047 PR: https://git.openjdk.org/jdk/pull/13047 From jlaskey at openjdk.org Thu Mar 16 12:07:57 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 16 Mar 2023 12:07:57 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v45] In-Reply-To: References: Message-ID: > Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 62 commits: - Merge branch 'master' into 8285932 - Correction - Merge branch 'master' into 8285932 - Merge branch 'master' into 8285932 - Javadoc corrections and bug fix for StringTemplate::combine - Tighten up reporting of string template errors (fewer messages) - Merge branch 'master' into 8285932 - Merge branch 'master' into 8285932 - Minor correction to javadoc - Merge branch 'master' into 8285932 - ... and 52 more: https://git.openjdk.org/jdk/compare/7277bb19...d6947fd4 ------------- Changes: https://git.openjdk.org/jdk/pull/10889/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=44 Stats: 9552 lines in 81 files changed: 9452 ins; 24 del; 76 mod Patch: https://git.openjdk.org/jdk/pull/10889.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889 PR: https://git.openjdk.org/jdk/pull/10889 From pminborg at openjdk.org Thu Mar 16 12:16:08 2023 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 16 Mar 2023 12:16:08 GMT Subject: RFR: 8304283: Modernize the switch statements in jdk.internal.foreign [v4] In-Reply-To: <69yyuUfAG5P3fNCzQ44xtTBqWQEZbdqfQS3Z-u9Vk6w=.d94b0b09-197c-4992-b7ff-a9f943ef3b59@github.com> References: <69yyuUfAG5P3fNCzQ44xtTBqWQEZbdqfQS3Z-u9Vk6w=.d94b0b09-197c-4992-b7ff-a9f943ef3b59@github.com> Message-ID: > This PR proposes changing old-type switch statements to newer forms of switch. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Pretty case statements ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13047/files - new: https://git.openjdk.org/jdk/pull/13047/files/f20f3516..4c9fea71 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13047&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13047&range=02-03 Stats: 35 lines in 4 files changed: 10 ins; 0 del; 25 mod Patch: https://git.openjdk.org/jdk/pull/13047.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13047/head:pull/13047 PR: https://git.openjdk.org/jdk/pull/13047 From pminborg at openjdk.org Thu Mar 16 12:16:10 2023 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 16 Mar 2023 12:16:10 GMT Subject: Integrated: 8304283: Modernize the switch statements in jdk.internal.foreign In-Reply-To: <69yyuUfAG5P3fNCzQ44xtTBqWQEZbdqfQS3Z-u9Vk6w=.d94b0b09-197c-4992-b7ff-a9f943ef3b59@github.com> References: <69yyuUfAG5P3fNCzQ44xtTBqWQEZbdqfQS3Z-u9Vk6w=.d94b0b09-197c-4992-b7ff-a9f943ef3b59@github.com> Message-ID: <2WHACWniHa8QVNm61HiCkEZKdZKfrMe6WhKM94Yi9_Y=.e18b11da-dc2e-4653-b040-d8db4186079b@github.com> On Wed, 15 Mar 2023 18:10:29 GMT, Per Minborg wrote: > This PR proposes changing old-type switch statements to newer forms of switch. This pull request has now been integrated. Changeset: dfc7214a Author: Per Minborg URL: https://git.openjdk.org/jdk/commit/dfc7214a3ed28f679d7404954d5602f6aa6e1699 Stats: 250 lines in 8 files changed: 45 ins; 95 del; 110 mod 8304283: Modernize the switch statements in jdk.internal.foreign Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.org/jdk/pull/13047 From jvernee at openjdk.org Thu Mar 16 12:26:19 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 16 Mar 2023 12:26:19 GMT Subject: RFR: 8303684: Lift upcall sharing mechanism to AbstractLinker (mainline) [v3] In-Reply-To: References: Message-ID: > Port of: https://github.com/openjdk/panama-foreign/pull/791 which lifts the sharing mechanism for upcall stubs to AbstractLinker. Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: - Merge branch 'master' into LazyUpcalls - Remove spurious space Co-authored-by: Andrey Turbanov - update benchmark - update copyright years - 8302346: Lift upcall sharing mechanism to AbstractLinker Reviewed-by: mcimadamore ------------- Changes: https://git.openjdk.org/jdk/pull/12883/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12883&range=02 Stats: 154 lines in 16 files changed: 54 ins; 34 del; 66 mod Patch: https://git.openjdk.org/jdk/pull/12883.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12883/head:pull/12883 PR: https://git.openjdk.org/jdk/pull/12883 From jvernee at openjdk.org Thu Mar 16 12:32:33 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 16 Mar 2023 12:32:33 GMT Subject: Integrated: 8303684: Lift upcall sharing mechanism to AbstractLinker (mainline) In-Reply-To: References: Message-ID: On Mon, 6 Mar 2023 18:40:47 GMT, Jorn Vernee wrote: > Port of: https://github.com/openjdk/panama-foreign/pull/791 which lifts the sharing mechanism for upcall stubs to AbstractLinker. This pull request has now been integrated. Changeset: d4eb3953 Author: Jorn Vernee URL: https://git.openjdk.org/jdk/commit/d4eb395335260bcab95de557142e93f47a671301 Stats: 154 lines in 16 files changed: 54 ins; 34 del; 66 mod 8303684: Lift upcall sharing mechanism to AbstractLinker (mainline) Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.org/jdk/pull/12883 From liach at openjdk.org Thu Mar 16 12:34:26 2023 From: liach at openjdk.org (Chen Liang) Date: Thu, 16 Mar 2023 12:34:26 GMT Subject: Integrated: 8304161: Add TypeKind.from to derive from TypeDescriptor.OfField In-Reply-To: References: Message-ID: On Tue, 14 Mar 2023 17:12:50 GMT, Chen Liang wrote: > Such an API allows creating TypeKind from both Class and ClassDesc than having to call descriptorString() explicitly at every use site. > > See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000240.html for context. > > Upgraded usages of `fromDescriptor` to `from` in applicable use sites in Classfile API and its tests. This pull request has now been integrated. Changeset: 7dbab81d Author: Chen Liang Committer: Jorn Vernee URL: https://git.openjdk.org/jdk/commit/7dbab81d3c06efb1225c4d57ad3eb4960fcf5cc6 Stats: 17 lines in 6 files changed: 10 ins; 0 del; 7 mod 8304161: Add TypeKind.from to derive from TypeDescriptor.OfField Reviewed-by: jvernee ------------- PR: https://git.openjdk.org/jdk/pull/13024 From jvernee at openjdk.org Thu Mar 16 12:37:28 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 16 Mar 2023 12:37:28 GMT Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function & Memory API (Preview) [v17] In-Reply-To: References: Message-ID: On Wed, 15 Mar 2023 18:53:08 GMT, Martin Doerr wrote: >> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification". >> >> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `` (2.2.4 Variable Argument Lists). >> >> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only. >> >> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Will get addressed separately: [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017) >> >> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests. >> >> I had to make changes to shared code and code for other platforms: >> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons: >> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that. >> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64. >> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian! >> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit. > > Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: > > Fix Copyright format. Ok, I've gone ahead and integrated: https://github.com/openjdk/jdk/pull/12883 & https://github.com/openjdk/jdk/pull/12908 That's all I had at the moment. I think the rest will come with the JEP PR. ------------- PR: https://git.openjdk.org/jdk/pull/12708 From mchhipa at openjdk.org Thu Mar 16 12:39:21 2023 From: mchhipa at openjdk.org (Mahendra Chhipa) Date: Thu, 16 Mar 2023 12:39:21 GMT Subject: RFR: JDK-8295859 Update Manual Test Groups In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 21:34:28 GMT, Bill Huang wrote: > The purpose of this task is to add the difference between -manual jdk_core and jdk_core_manual to the jdk_core_manual test goal. Furthermore, in order to streamline the manual test execution process, a new test group called jdk_core_manual_human has been created for manual tests that demand extra preparation or test input. test/jdk/TEST.groups line 644: > 642: > 643: jdk_core_manual_human = \ > 644: :jdk_core_manual_requires_human_input \ Move tests from jdk_core_manual_requires_human_input group to here. And remove jdk_core_manual_requires_human_input this group. test/jdk/TEST.groups line 647: > 645: :jdk_core_manual_requires_root_privilege > 646: > 647: jdk_core_manual_requires_human_input = \ Move tests from this group to jdk_core_manual_human group, and remove this group. ------------- PR: https://git.openjdk.org/jdk/pull/12840 From asotona at openjdk.org Thu Mar 16 13:10:04 2023 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 16 Mar 2023 13:10:04 GMT Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator to use the Classfile API to generate proxy classes [v7] In-Reply-To: References: Message-ID: > java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes and this patch converts it to use Classfile API. > > Please review. > > Thank you, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: Apply suggestions from code review Co-authored-by: liach <7806504+liach at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10991/files - new: https://git.openjdk.org/jdk/pull/10991/files/951b1bc7..fc1380ac Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10991&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10991&range=05-06 Stats: 6 lines in 1 file changed: 0 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/10991.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10991/head:pull/10991 PR: https://git.openjdk.org/jdk/pull/10991 From mdoerr at openjdk.org Thu Mar 16 13:15:18 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Thu, 16 Mar 2023 13:15:18 GMT Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function & Memory API (Preview) [v18] In-Reply-To: References: Message-ID: > Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification". > > This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `` (2.2.4 Variable Argument Lists). > > Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only. > > There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Will get addressed separately: [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017) > > The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests. > > I had to make changes to shared code and code for other platforms: > 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons: > - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that. > - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64. > - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian! > 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit. Martin Doerr has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: - Merge branch 'master' into PPC64_Panama - Fix Copyright format. - Fix storing 32 bit integers into Java frames. Enable TestArrayStructs. - Allow TestHFA to run on musl. Add Upcalls. - Introduce ABIv2CallArranger for linux ppc64le. - Remove LinuxPPC64CallArranger.java because it doesn't contain anything. - The merge change has messed up some includes in the tests. Revert. - Remove STRUCT_REFERENCE which was incorrectly taken from aarch64. Pass size to bufferLoad/Store. Enable TestNested.java. - Merge remote-tracking branch 'origin' into PPC64_Panama - Handle HFA corner cases with overlapping registers in Java. - ... and 8 more: https://git.openjdk.org/jdk/compare/7dbab81d...944742b5 ------------- Changes: https://git.openjdk.org/jdk/pull/12708/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=17 Stats: 2434 lines in 61 files changed: 2324 ins; 1 del; 109 mod Patch: https://git.openjdk.org/jdk/pull/12708.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12708/head:pull/12708 PR: https://git.openjdk.org/jdk/pull/12708 From asemenyuk at openjdk.org Thu Mar 16 13:16:25 2023 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Thu, 16 Mar 2023 13:16:25 GMT Subject: RFR: JDK-8304063: tools/jpackage/share/AppLauncherEnvTest.java fails when checking LD_LIBRARY_PATH [v2] In-Reply-To: References: Message-ID: On Thu, 16 Mar 2023 09:08:08 GMT, Matthias Baesken wrote: >> The test fails on Alpine Linux 3.17, when checking the environment variable LD_LIBRARY_PATH; looks like the actual env variable is much longer than the test expects. It turned out that at least on Linux (probably also on other OS like AIX) the actual env variable has the expected string at it's end, but might contain more path entries ( LD_LIBRARY_PATH can be adjusted by jvm - https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/libjli/java_md.c ). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > redo check Marked as reviewed by asemenyuk (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/13041 From asemenyuk at openjdk.org Thu Mar 16 13:16:29 2023 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Thu, 16 Mar 2023 13:16:29 GMT Subject: RFR: JDK-8304063: tools/jpackage/share/AppLauncherEnvTest.java fails when checking LD_LIBRARY_PATH [v2] In-Reply-To: References: Message-ID: On Thu, 16 Mar 2023 09:03:36 GMT, Matthias Baesken wrote: >> test/jdk/tools/jpackage/share/AppLauncherEnvTest.java line 93: >> >>> 91: } else { >>> 92: TKit.assertEquals(expectedEnvVarValue, actualEnvVarValue, msg); >>> 93: } >> >> I'd keep the check as a single statement: >> >> TKit.assertTextStream(expectedEnvVarValue) >> .predicate(TKit.isLinux() ? String::endsWith : String::equals) >> .label(String.format("value of %s env variable", envVarName)) >> .apply(Stream.of(actualEnvVarValue)); >> >> >> It also will produce a nicer log record than `TKit.assertTrue(false, msg);` > > Hi Alexey, I adjusted the check following your advice . Thank you! ------------- PR: https://git.openjdk.org/jdk/pull/13041 From mdoerr at openjdk.org Thu Mar 16 13:26:20 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Thu, 16 Mar 2023 13:26:20 GMT Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function & Memory API (Preview) [v19] In-Reply-To: References: Message-ID: > Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification". > > This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `` (2.2.4 Variable Argument Lists). > > Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only. > > There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Will get addressed separately: [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017) > > The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests. > > I had to make changes to shared code and code for other platforms: > 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons: > - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that. > - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64. > - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian! > 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit. Martin Doerr has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits: - Merge branch 'openjdk:master' into PPC64_Panama - Merge branch 'master' into PPC64_Panama - Fix Copyright format. - Fix storing 32 bit integers into Java frames. Enable TestArrayStructs. - Allow TestHFA to run on musl. Add Upcalls. - Introduce ABIv2CallArranger for linux ppc64le. - Remove LinuxPPC64CallArranger.java because it doesn't contain anything. - The merge change has messed up some includes in the tests. Revert. - Remove STRUCT_REFERENCE which was incorrectly taken from aarch64. Pass size to bufferLoad/Store. Enable TestNested.java. - Merge remote-tracking branch 'origin' into PPC64_Panama - ... and 9 more: https://git.openjdk.org/jdk/compare/f6291520...2f2f41be ------------- Changes: https://git.openjdk.org/jdk/pull/12708/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=18 Stats: 2434 lines in 61 files changed: 2324 ins; 1 del; 109 mod Patch: https://git.openjdk.org/jdk/pull/12708.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12708/head:pull/12708 PR: https://git.openjdk.org/jdk/pull/12708 From asotona at openjdk.org Thu Mar 16 13:27:37 2023 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 16 Mar 2023 13:27:37 GMT Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator to use the Classfile API to generate proxy classes [v6] In-Reply-To: References: <2vZ8IArF00YxvsqkZxg1fZJCv-pvUQRYrepvvVhw1w0=.dcd260a4-f3d6-4797-8e11-e9eb266d460c@github.com> Message-ID: On Sat, 11 Mar 2023 13:45:23 GMT, Chen Liang wrote: >> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 196 commits: >> >> - Merge branch 'master' into JDK-8294961-proxy >> - Merge branch 'master' into JDK-8294961-proxy >> - Merge branch 'JDK-8294982' into JDK-8294961 >> - removed obsolete javadoc from implementation classes >> - minor fix in CodeBuilder and added test cases to LDCTest >> - EntryMap::nextPowerOfTwo delegates to Long:numberOfLeadingZeros >> - fixed CodeBuilder:constantInstruction for -0.0d and -0.0f values and added test >> - Merge branch 'master' into JDK-8294982 >> - fixed new lines at end of file >> - package jdk.internal.classfile.jdktypes moved to jdk.internal.classfile.java.lang.constant >> - ... and 186 more: https://git.openjdk.org/jdk/compare/e26cc526...951b1bc7 > > src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 426: > >> 424: */ >> 425: localCache.computeIfAbsent(classDesc, cd -> { >> 426: try { > > This probably can be a factory method in ClassHierarchyResolver too, by examining the reflection API via a ClassLoader/Lookup. I'm inclined to submit a patch for improvement. > > Also, why does ProxyGenerator come with a custom ClassHierarchyResolver while InnerClassLambdaMetafactory in 8294960 #12945 doesn't? Possible extensions of `ClassHierarchyResolver` factories, or maybe even extensions of the default resolver are on the table and I just planned to open this discussion. Here is specific case where original code passes `ClassLoader` down to to the ASM engine for class hierarchy resolution based on class loading. Classfile API has more flexibility in that area and can resolve class hierarchy based on provided minimal information. Default class hierarchy resolution is fast-scanning of classfiles provided by ClassLoader as resources. It is not necessary to resolve all dependencies nor load the classes. However this is one of the cases where I'm not sure the default does it right. The above code turns default class hierarchy resolution back to the original class-loading approach. In `InnerClassLambdaMetafactory` I didn't observed any `ClassLoader` beeing passed down to ASM, so it rely on the defaults. The right solution may be to extend the default class hierarchy resolution to fall back to class-loading when the resource form of the class is not available. A factory method can just replicate the same behavior with provided different `ClassLoader`. I'm open to any comments and suggestions. ------------- PR: https://git.openjdk.org/jdk/pull/10991 From leonid.mesnik at oracle.com Thu Mar 16 13:29:07 2023 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Thu, 16 Mar 2023 13:29:07 +0000 Subject: jtreg test test/jdk/java/lang/StackWalker/StackWalkTest.java fails after jtreg commit 7903373 In-Reply-To: <4847e074-5a12-7a33-a9fb-d7e412943078@oracle.com> References: <4847e074-5a12-7a33-a9fb-d7e412943078@oracle.com> Message-ID: Hi I?ve sent fix out for review: https://github.com/openjdk/jdk/pull/13058 Leonid From: Tobias Hartmann Date: Thursday, March 16, 2023 at 12:20 AM To: Kosta Stojiljkovic , core-libs-dev at openjdk.org Cc: Leonid Mesnik Subject: Re: jtreg test test/jdk/java/lang/StackWalker/StackWalkTest.java fails after jtreg commit 7903373 Hi Kosta, Thanks again for the report! This test is owned by core-libs/java.lang, I'm forwarding to core-libs-dev and CC'ing Leonid, the author of https://bugs.openjdk.org/browse/CODETOOLS-7903373. I can see these failures in our testing as well but no one filed a bug yet. I filed: https://bugs.openjdk.org/browse/JDK-8304314 Best regards, Tobias On 15.03.23 22:40, Kosta Stojiljkovic wrote: > Dear all, > > The test in ..test/jdk/java/lang/StackWalker/StackWalkTest.java fails with the latest jtreg build, with the following error: > > ... > recursion chain > ... > ... > ... > at StackWalkTest$Test.call(StackWalkTest.java:223) > at StackWalkTest.runTest(StackWalkTest.java:270) > at StackWalkTest.main(StackWalkTest.java:325) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) > at java.base/java.lang.reflect.Method.invoke(Method.java:578) > at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) > at java.base/java.lang.Thread.run(Thread.java:1623) > Caused by: java.lang.IndexOutOfBoundsException: Index: 1004, Size: 1004 > at java.base/java.util.LinkedList.checkElementIndex(LinkedList.java:559) > at java.base/java.util.LinkedList.get(LinkedList.java:480) > at StackRecorderUtil.compareFrame(StackRecorderUtil.java:64) > at StackWalkTest.consume(StackWalkTest.java:145) > ... 1018 more > > JavaTest Message: Test threw exception: java.lang.RuntimeException: extra non-infra stack frame at count 1004: > > --------------------------- > > In essence, the test detects an extra non-infra stack frame for the MainWrapper$MainTask's frame. The test should disregard MainTask's stack frame, since it's coming from an infrastructure class - com.sun.javatest.regtest.agent.MainWrapper. The code correctly checks if the stack frame belongs to the mentioned infrastructure class, but it also looks for the inner class - com.sun.javatest.regtest.agent.MainWrapper$MainThread. > > I believe the problem comes from the following commit (7903373) to the jtreg repository: https://github.com/openjdk/jtreg/commit/5b9e661eb6ee9dd9a9d2690986bbf9ce303a8f03 > > This commit changed the name of the class MainThread to MainTask, thus making the hardcoded check in the StackWalkTest fail to recognize this extra stack frame as an infra frame. > > Could you please try to reproduce and let me know if I am missing or misunderstanding something. > > Best, > Kosta Stojiljkovic -------------- next part -------------- An HTML attachment was scrubbed... URL: From lmesnik at openjdk.org Thu Mar 16 13:34:09 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 16 Mar 2023 13:34:09 GMT Subject: RFR: 8304314: StackWalkTest.java fails after CODETOOLS-7903373 Message-ID: The test depends on the jtreg stack and should be updated. The fix is backported from loom repo where jtreg with CODETOOLS-7903373 is used. Tested with current promoted jtreg (without CODETOOLS-7903373) by running test. ------------- Commit messages: - 8304314: StackWalkTest.java fails after CODETOOLS-7903373 Changes: https://git.openjdk.org/jdk/pull/13058/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13058&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304314 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13058.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13058/head:pull/13058 PR: https://git.openjdk.org/jdk/pull/13058 From duke at openjdk.org Thu Mar 16 13:43:13 2023 From: duke at openjdk.org (Viktor Klang) Date: Thu, 16 Mar 2023 13:43:13 GMT Subject: RFR: JDK-8303742: CompletableFuture.orTimeout leaks if the future completes exceptionally Message-ID: Addresses the situation where exceptional completion of `orTimeout`:ed CompletableFutures wouldn't cancel the timeout task which could lead to memory leaks if done frequently enough with long enough timeout durations. Fix discussed with @DougLea ------------- Commit messages: - Adding a regression test for 8303742 - Addressing JDK-8303742 by removing the check for a null exception in Canceller Changes: https://git.openjdk.org/jdk/pull/13059/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13059&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303742 Stats: 50 lines in 2 files changed: 49 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13059.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13059/head:pull/13059 PR: https://git.openjdk.org/jdk/pull/13059 From asotona at openjdk.org Thu Mar 16 13:59:21 2023 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 16 Mar 2023 13:59:21 GMT Subject: RFR: 8294977: Convert test/jdk/java tests from ASM library to Classfile API [v2] In-Reply-To: References: Message-ID: On Wed, 15 Mar 2023 04:09:04 GMT, Chen Liang wrote: >> Summaries: >> 1. A few recommendations about updating the constant API is made at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000233.html and I may update this patch shall the API changes be integrated before >> 2. One ASM library-specific test, `LambdaAsm` is removed. Others have their code generation infrastructure upgraded from ASM to Classfile API. >> 3. Most tests are included in tier1, but some are not: >> In `:jdk_io`: (tier2, part 2) >> >> test/jdk/java/io/Serializable/records/SerialPersistentFieldsTest.java >> test/jdk/java/io/Serializable/records/ProhibitedMethods.java >> test/jdk/java/io/Serializable/records/BadCanonicalCtrTest.java >> >> In `:jdk_instrument`: (tier 3) >> >> test/jdk/java/lang/instrument/RetransformAgent.java >> test/jdk/java/lang/instrument/NativeMethodPrefixAgent.java >> test/jdk/java/lang/instrument/asmlib/Instrumentor.java >> >> >> @asotona Would you mind reviewing? > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Shorten lines, move from mask() to ACC_ constants, other misc improvements test/jdk/java/lang/Class/getSimpleName/GetSimpleNameTest.java line 174: > 172: clb.withSuperclass(CD_Object); > 173: clb.withFlags(AccessFlag.PUBLIC, AccessFlag.SUPER); > 174: clb.accept(InnerClassesAttribute.of( During the API discussions there was slightly more recommended to use `ClasfileBuilder::with` over `ClasfileBuilder::accept`, however it is just a cosmetic difference. ------------- PR: https://git.openjdk.org/jdk/pull/13009 From asotona at openjdk.org Thu Mar 16 14:10:05 2023 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 16 Mar 2023 14:10:05 GMT Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator to use the Classfile API to generate proxy classes [v8] In-Reply-To: References: Message-ID: <3kBciCxRCIB6SOdq1ZnbEfFTZeSy_CsNvWyUZyPGrmA=.4211cae3-26c8-4041-ac00-c516bc5f5a63@github.com> > java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes and this patch converts it to use Classfile API. > > Please review. > > Thank you, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: improved method descriptor construction ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10991/files - new: https://git.openjdk.org/jdk/pull/10991/files/fc1380ac..2b23276a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10991&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10991&range=06-07 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10991.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10991/head:pull/10991 PR: https://git.openjdk.org/jdk/pull/10991 From alanb at openjdk.org Thu Mar 16 14:13:23 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 16 Mar 2023 14:13:23 GMT Subject: RFR: 8304314: StackWalkTest.java fails after CODETOOLS-7903373 In-Reply-To: References: Message-ID: On Thu, 16 Mar 2023 13:26:35 GMT, Leonid Mesnik wrote: > The test depends on the jtreg stack and should be updated. > The fix is backported from loom repo where jtreg with CODETOOLS-7903373 is used. > Tested with current promoted jtreg (without CODETOOLS-7903373) by running test. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/13058 From kostasto at proton.me Thu Mar 16 14:14:17 2023 From: kostasto at proton.me (Kosta Stojiljkovic) Date: Thu, 16 Mar 2023 14:14:17 +0000 Subject: jtreg test test/jdk/java/lang/StackWalker/StackWalkTest.java fails after jtreg commit 7903373 In-Reply-To: References: <4847e074-5a12-7a33-a9fb-d7e412943078@oracle.com> Message-ID: Thanks Leonid! Kosta ------- Original Message ------- On Thursday, March 16th, 2023 at 2:29 PM, Leonid Mesnik wrote: > Hi > > I?ve sent fix out for review: https://github.com/openjdk/jdk/pull/13058 > > Leonid > > From: Tobias Hartmann > Date: Thursday, March 16, 2023 at 12:20 AM > To: Kosta Stojiljkovic , core-libs-dev at openjdk.org > Cc: Leonid Mesnik > Subject: Re: jtreg test test/jdk/java/lang/StackWalker/StackWalkTest.java fails after jtreg commit 7903373 > > Hi Kosta, > > Thanks again for the report! This test is owned by core-libs/java.lang, I'm forwarding to > core-libs-dev and CC'ing Leonid, the author of https://bugs.openjdk.org/browse/CODETOOLS-7903373. > > I can see these failures in our testing as well but no one filed a bug yet. I filed: > https://bugs.openjdk.org/browse/JDK-8304314 > > Best regards, > Tobias > > > On 15.03.23 22:40, Kosta Stojiljkovic wrote: > > Dear all, > > > > The test in ..test/jdk/java/lang/StackWalker/StackWalkTest.java fails with the latest jtreg build, with the following error: > > > > ... > > recursion chain > > ... > > ... > > ... > >???????? at StackWalkTest$Test.call(StackWalkTest.java:223) > >??????? at StackWalkTest.runTest(StackWalkTest.java:270) > >??????? at StackWalkTest.main(StackWalkTest.java:325) > >??????? at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) > >??????? at java.base/java.lang.reflect.Method.invoke(Method.java:578) > >??????? at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) > >??????? at java.base/java.lang.Thread.run(Thread.java:1623) > > Caused by: java.lang.IndexOutOfBoundsException: Index: 1004, Size: 1004 > >??????? at java.base/java.util.LinkedList.checkElementIndex(LinkedList.java:559) > >??????? at java.base/java.util.LinkedList.get(LinkedList.java:480) > >??????? at StackRecorderUtil.compareFrame(StackRecorderUtil.java:64) > >??????? at StackWalkTest.consume(StackWalkTest.java:145) > >??????? ... 1018 more > > > > JavaTest Message: Test threw exception: java.lang.RuntimeException: extra non-infra stack frame at count 1004: > > > > --------------------------- > > > > In essence, the test detects an extra non-infra stack frame for the MainWrapper$MainTask's frame. The test should disregard MainTask's stack frame, since it's coming from an infrastructure class - com.sun.javatest.regtest.agent.MainWrapper. The code correctly checks if the stack frame belongs to the mentioned infrastructure class, but it also looks for the inner class - com.sun.javatest.regtest.agent.MainWrapper$MainThread. > > > > I believe the problem comes from the following commit (7903373) to the jtreg repository: https://github.com/openjdk/jtreg/commit/5b9e661eb6ee9dd9a9d2690986bbf9ce303a8f03 > > > > This commit changed the name of the class MainThread to MainTask, thus making the hardcoded check in the StackWalkTest fail to recognize this extra stack frame as an infra frame. > > > > Could you please try to reproduce and let me know if I am missing or misunderstanding something. > > > > Best, > > Kosta Stojiljkovic From mdoerr at openjdk.org Thu Mar 16 14:17:12 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Thu, 16 Mar 2023 14:17:12 GMT Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function & Memory API (Preview) [v20] In-Reply-To: References: Message-ID: <6zPly5eBW4Y9v5qD0VKBSigBod2OJeqKoymR_TEogO4=.88f854ce-6a35-4022-a363-1e617bbbd823@github.com> > Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification". > > This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `` (2.2.4 Variable Argument Lists). > > Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only. > > There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Will get addressed separately: [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017) > > The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests. > > I had to make changes to shared code and code for other platforms: > 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons: > - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that. > - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64. > - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian! > 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit. Martin Doerr has updated the pull request incrementally with two additional commits since the last revision: - Adaptation for JDK-8303022. - Adaptation for JDK-8303684. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12708/files - new: https://git.openjdk.org/jdk/pull/12708/files/2f2f41be..a21f6cfb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=19 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=18-19 Stats: 23 lines in 5 files changed: 9 ins; 3 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/12708.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12708/head:pull/12708 PR: https://git.openjdk.org/jdk/pull/12708 From asotona at openjdk.org Thu Mar 16 14:17:30 2023 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 16 Mar 2023 14:17:30 GMT Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator to use the Classfile API to generate proxy classes [v3] In-Reply-To: References: <6MQUzvBb7NdEBp2zu0FjIRVWNYw9INz7yXbqAAZU-vo=.c6a832a8-248f-4c5b-a36e-8b18f6c5a0b7@github.com> Message-ID: On Thu, 9 Mar 2023 14:41:47 GMT, Chen Liang wrote: >> Isn't the "unrelated process such as generating lambda forms" critical for the `ProxyGenerator` functionality? > > More accurately, I mean the overhead generated by this: https://github.com/openjdk/jdk/blob/1e9942aa112edca33f964db127df6c9ce41e86ff/src/java.base/share/classes/java/lang/invoke/MethodType.java#L408 > > That method type construction is somewhat expensive and involves extra work besides simply storing the return class and the parameter classes. fixed, thanks. ------------- PR: https://git.openjdk.org/jdk/pull/10991 From asotona at openjdk.org Thu Mar 16 14:22:19 2023 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 16 Mar 2023 14:22:19 GMT Subject: RFR: 8294977: Convert test/jdk/java tests from ASM library to Classfile API [v2] In-Reply-To: References: Message-ID: <-jdVuSccJFgRr097u55X_v7lxZu2ZnQkZMSDZddnO_4=.abc0fb6c-ba84-49d4-bb43-2c0dd8ecf249@github.com> On Wed, 15 Mar 2023 04:09:04 GMT, Chen Liang wrote: >> Summaries: >> 1. A few recommendations about updating the constant API is made at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000233.html and I may update this patch shall the API changes be integrated before >> 2. One ASM library-specific test, `LambdaAsm` is removed. Others have their code generation infrastructure upgraded from ASM to Classfile API. >> 3. Most tests are included in tier1, but some are not: >> In `:jdk_io`: (tier2, part 2) >> >> test/jdk/java/io/Serializable/records/SerialPersistentFieldsTest.java >> test/jdk/java/io/Serializable/records/ProhibitedMethods.java >> test/jdk/java/io/Serializable/records/BadCanonicalCtrTest.java >> >> In `:jdk_instrument`: (tier 3) >> >> test/jdk/java/lang/instrument/RetransformAgent.java >> test/jdk/java/lang/instrument/NativeMethodPrefixAgent.java >> test/jdk/java/lang/instrument/asmlib/Instrumentor.java >> >> >> @asotona Would you mind reviewing? > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Shorten lines, move from mask() to ACC_ constants, other misc improvements I like the easy way I can read the tests code now even I don't know them. They look great :) ------------- PR: https://git.openjdk.org/jdk/pull/13009 From mdoerr at openjdk.org Thu Mar 16 14:42:10 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Thu, 16 Mar 2023 14:42:10 GMT Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function & Memory API (Preview) [v21] In-Reply-To: References: Message-ID: > Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification". > > This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `` (2.2.4 Variable Argument Lists). > > Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only. > > There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Will get addressed separately: [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017) > > The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests. > > I had to make changes to shared code and code for other platforms: > 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons: > - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that. > - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64. > - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian! > 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit. Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: Move ABIv2CallArranger out of linux subdirectory. ABIv1/2 does match the AIX/linux separation. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12708/files - new: https://git.openjdk.org/jdk/pull/12708/files/a21f6cfb..4666aa22 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=20 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=19-20 Stats: 81 lines in 3 files changed: 40 ins; 40 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12708.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12708/head:pull/12708 PR: https://git.openjdk.org/jdk/pull/12708 From mdoerr at openjdk.org Thu Mar 16 14:42:12 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Thu, 16 Mar 2023 14:42:12 GMT Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function & Memory API (Preview) [v20] In-Reply-To: <6zPly5eBW4Y9v5qD0VKBSigBod2OJeqKoymR_TEogO4=.88f854ce-6a35-4022-a363-1e617bbbd823@github.com> References: <6zPly5eBW4Y9v5qD0VKBSigBod2OJeqKoymR_TEogO4=.88f854ce-6a35-4022-a363-1e617bbbd823@github.com> Message-ID: <2ly6-8MdohRIteqaZsBXJd5R6FxhhmsAv4pwdIaZPW4=.77a93182-17bc-4149-99fb-2c6064c297eb@github.com> On Thu, 16 Mar 2023 14:17:12 GMT, Martin Doerr wrote: >> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification". >> >> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `` (2.2.4 Variable Argument Lists). >> >> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only. >> >> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Will get addressed separately: [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017) >> >> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests. >> >> I had to make changes to shared code and code for other platforms: >> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons: >> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that. >> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64. >> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian! >> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit. > > Martin Doerr has updated the pull request incrementally with two additional commits since the last revision: > > - Adaptation for JDK-8303022. > - Adaptation for JDK-8303684. Rebasing + minor cleanup done. Tests are passing. ------------- PR: https://git.openjdk.org/jdk/pull/12708 From alanb at openjdk.org Thu Mar 16 14:53:21 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 16 Mar 2023 14:53:21 GMT Subject: RFR: 8294977: Convert test/jdk/java tests from ASM library to Classfile API [v2] In-Reply-To: References: Message-ID: On Tue, 14 Mar 2023 07:53:25 GMT, Alan Bateman wrote: > This is class descriptor for ProviderFactory$1, not "Provider" so maybe rename this to providerFactory1 or something a bit clearer. The updated version looks good. I assume you'll do a pass over the updated tests to bump their copyright date as this is the first change in 2023 for many of these tests. ------------- PR: https://git.openjdk.org/jdk/pull/13009 From liach at openjdk.org Thu Mar 16 15:03:58 2023 From: liach at openjdk.org (Chen Liang) Date: Thu, 16 Mar 2023 15:03:58 GMT Subject: RFR: 8294977: Convert test/jdk/java tests from ASM library to Classfile API [v3] In-Reply-To: References: Message-ID: <9JGfanhjEcfkxJkObHi7of2axEP2J0eGlaDK7-DHQtI=.d22d8ee6-5897-4947-bc71-7da98248034d@github.com> > Summaries: > 1. A few recommendations about updating the constant API is made at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000233.html and I may update this patch shall the API changes be integrated before > 2. One ASM library-specific test, `LambdaAsm` is removed. Others have their code generation infrastructure upgraded from ASM to Classfile API. > 3. Most tests are included in tier1, but some are not: > In `:jdk_io`: (tier2, part 2) > > test/jdk/java/io/Serializable/records/SerialPersistentFieldsTest.java > test/jdk/java/io/Serializable/records/ProhibitedMethods.java > test/jdk/java/io/Serializable/records/BadCanonicalCtrTest.java > > In `:jdk_instrument`: (tier 3) > > test/jdk/java/lang/instrument/RetransformAgent.java > test/jdk/java/lang/instrument/NativeMethodPrefixAgent.java > test/jdk/java/lang/instrument/asmlib/Instrumentor.java > > > @asotona Would you mind reviewing? Chen Liang 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: - Fix failed LambdaStackTrace test, use more convenient APIs - Merge branch 'master' of https://git.openjdk.java.net/jdk into invoke-test-classfile - Shorten lines, move from mask() to ACC_ constants, other misc improvements - Convert test/jdk/java ASM tests to classfile api ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13009/files - new: https://git.openjdk.org/jdk/pull/13009/files/c6536bf9..a50b94f9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13009&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13009&range=01-02 Stats: 68505 lines in 534 files changed: 42498 ins; 18129 del; 7878 mod Patch: https://git.openjdk.org/jdk/pull/13009.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13009/head:pull/13009 PR: https://git.openjdk.org/jdk/pull/13009 From liach at openjdk.org Thu Mar 16 15:23:30 2023 From: liach at openjdk.org (Chen Liang) Date: Thu, 16 Mar 2023 15:23:30 GMT Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator to use the Classfile API to generate proxy classes [v6] In-Reply-To: References: <2vZ8IArF00YxvsqkZxg1fZJCv-pvUQRYrepvvVhw1w0=.dcd260a4-f3d6-4797-8e11-e9eb266d460c@github.com> Message-ID: <_BTRFrVE38PLXm9f7EPoh4y7Ikrb2nHF50Y82tfCEro=.43cd3219-0d45-42a4-aebb-c39f9536e088@github.com> On Thu, 16 Mar 2023 13:21:38 GMT, Adam Sotona wrote: >> src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 426: >> >>> 424: */ >>> 425: localCache.computeIfAbsent(classDesc, cd -> { >>> 426: try { >> >> This probably can be a factory method in ClassHierarchyResolver too, by examining the reflection API via a ClassLoader/Lookup. I'm inclined to submit a patch for improvement. >> >> Also, why does ProxyGenerator come with a custom ClassHierarchyResolver while InnerClassLambdaMetafactory in 8294960 #12945 doesn't? > > Possible extensions of `ClassHierarchyResolver` factories, or maybe even extensions of the default resolver are on the table and I just planned to open this discussion. > > Here is specific case where original code passes `ClassLoader` down to to the ASM engine for class hierarchy resolution based on class loading. > > Classfile API has more flexibility in that area and can resolve class hierarchy based on provided minimal information. Default class hierarchy resolution is fast-scanning of classfiles provided by ClassLoader as resources. It is not necessary to resolve all dependencies nor load the classes. However this is one of the cases where I'm not sure the default does it right. The above code turns default class hierarchy resolution back to the original class-loading approach. > > In `InnerClassLambdaMetafactory` I didn't observed any `ClassLoader` beeing passed down to ASM, so it rely on the defaults. > > The right solution may be to extend the default class hierarchy resolution to fall back to class-loading when the resource form of the class is not available. A factory method can just replicate the same behavior with provided different `ClassLoader`. > > I'm open to any comments and suggestions. I was thinking of implementing a class resolution via Reflection API with the `MethodHandles.Lookup` passed into `LambdaMetafactory` for correctness. Could it be that Lambda bytecode is too simple (as it's just calling a method handle in an instance method and a constructor, in a class extending Object and implementing a few interfaces) so the class hierarchy resolution wasn't critical? ------------- PR: https://git.openjdk.org/jdk/pull/10991 From liach at openjdk.org Thu Mar 16 15:23:53 2023 From: liach at openjdk.org (Chen Liang) Date: Thu, 16 Mar 2023 15:23:53 GMT Subject: RFR: 8294977: Convert test/jdk/java tests from ASM library to Classfile API [v4] In-Reply-To: References: Message-ID: > Summaries: > 1. A few recommendations about updating the constant API is made at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000233.html and I may update this patch shall the API changes be integrated before > 2. One ASM library-specific test, `LambdaAsm` is removed. Others have their code generation infrastructure upgraded from ASM to Classfile API. > 3. Most tests are included in tier1, but some are not: > In `:jdk_io`: (tier2, part 2) > > test/jdk/java/io/Serializable/records/SerialPersistentFieldsTest.java > test/jdk/java/io/Serializable/records/ProhibitedMethods.java > test/jdk/java/io/Serializable/records/BadCanonicalCtrTest.java > > In `:jdk_instrument`: (tier 3) > > test/jdk/java/lang/instrument/RetransformAgent.java > test/jdk/java/lang/instrument/NativeMethodPrefixAgent.java > test/jdk/java/lang/instrument/asmlib/Instrumentor.java > > > @asotona Would you mind reviewing? Chen Liang has updated the pull request incrementally with one additional commit since the last revision: formatting ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13009/files - new: https://git.openjdk.org/jdk/pull/13009/files/a50b94f9..09bbe4d5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13009&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13009&range=02-03 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13009.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13009/head:pull/13009 PR: https://git.openjdk.org/jdk/pull/13009 From liach at openjdk.org Thu Mar 16 15:34:58 2023 From: liach at openjdk.org (Chen Liang) Date: Thu, 16 Mar 2023 15:34:58 GMT Subject: RFR: 8294977: Convert test/jdk/java tests from ASM library to Classfile API [v5] In-Reply-To: References: Message-ID: > Summaries: > 1. A few recommendations about updating the constant API is made at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000233.html and I may update this patch shall the API changes be integrated before > 2. One ASM library-specific test, `LambdaAsm` is removed. Others have their code generation infrastructure upgraded from ASM to Classfile API. > 3. Most tests are included in tier1, but some are not: > In `:jdk_io`: (tier2, part 2) > > test/jdk/java/io/Serializable/records/SerialPersistentFieldsTest.java > test/jdk/java/io/Serializable/records/ProhibitedMethods.java > test/jdk/java/io/Serializable/records/BadCanonicalCtrTest.java > > In `:jdk_instrument`: (tier 3) > > test/jdk/java/lang/instrument/RetransformAgent.java > test/jdk/java/lang/instrument/NativeMethodPrefixAgent.java > test/jdk/java/lang/instrument/asmlib/Instrumentor.java > > > @asotona Would you mind reviewing? Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Fix LambdaStackTrace after running ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13009/files - new: https://git.openjdk.org/jdk/pull/13009/files/09bbe4d5..a728c9de Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13009&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13009&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13009.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13009/head:pull/13009 PR: https://git.openjdk.org/jdk/pull/13009 From liach at openjdk.org Thu Mar 16 15:34:59 2023 From: liach at openjdk.org (Chen Liang) Date: Thu, 16 Mar 2023 15:34:59 GMT Subject: RFR: 8294977: Convert test/jdk/java tests from ASM library to Classfile API [v5] In-Reply-To: References: Message-ID: <-_EfAIuz6dKVBcqAq0pu6EnhIL5Qo_Qr7hXNdu4oJ2Q=.849415b7-db1e-444f-8026-7d7f3e5f48c4@github.com> On Thu, 16 Mar 2023 14:50:14 GMT, Alan Bateman wrote: >> test/jdk/java/util/ServiceLoader/BadProvidersTest.java line 216: >> >>> 214: clb.withSuperclass(CD_Object); >>> 215: clb.withFlags(AccessFlag.PUBLIC, AccessFlag.SUPER); >>> 216: var provider$1Desc = ClassDesc.of("p", "ProviderFactory$1"); >> >> This is class descriptor for ProviderFactory$1, not "Provider" so maybe rename this to providerFactory1 or something a bit clearer. > >> This is class descriptor for ProviderFactory$1, not "Provider" so maybe rename this to providerFactory1 or something a bit clearer. > > The updated version looks good. I assume you'll do a pass over the updated tests to bump their copyright date as this is the first change in 2023 for many of these tests. Yes, the copyright years are updated. Tested Serializable, instrument, and LambdaStackTrace as of "[Fix LambdaStackTrace after running](https://github.com/openjdk/jdk/pull/13009/commits/a728c9de1ff684bd30726eb8ea6e7a674cb5a140)" ------------- PR: https://git.openjdk.org/jdk/pull/13009 From jpai at openjdk.org Thu Mar 16 15:37:08 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 16 Mar 2023 15:37:08 GMT Subject: RFR: 8304225: Remove javax/script/Test7.java from ProblemList In-Reply-To: References: Message-ID: On Wed, 15 Mar 2023 06:16:17 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which removes `javax/script/Test7.java` from the ProblemList? > > As noted in https://bugs.openjdk.org/browse/JDK-8304225, this test no longer fails and passes just like the other tests in `javax/script` directory with: > > > ----------System.out:(4/60)---------- > > Test7 > > Warning: No js engine found; test vacuously passes. > > > With this proposed change, relevant tier testing has been run to verify that the original reported issue which caused this test to be problem listed https://bugs.openjdk.org/browse/JDK-8239361 is no longer seen. Thank you Naoto for the review. ------------- PR: https://git.openjdk.org/jdk/pull/13035 From jpai at openjdk.org Thu Mar 16 15:37:10 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 16 Mar 2023 15:37:10 GMT Subject: Integrated: 8304225: Remove javax/script/Test7.java from ProblemList In-Reply-To: References: Message-ID: On Wed, 15 Mar 2023 06:16:17 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which removes `javax/script/Test7.java` from the ProblemList? > > As noted in https://bugs.openjdk.org/browse/JDK-8304225, this test no longer fails and passes just like the other tests in `javax/script` directory with: > > > ----------System.out:(4/60)---------- > > Test7 > > Warning: No js engine found; test vacuously passes. > > > With this proposed change, relevant tier testing has been run to verify that the original reported issue which caused this test to be problem listed https://bugs.openjdk.org/browse/JDK-8239361 is no longer seen. This pull request has now been integrated. Changeset: 2f23c80e Author: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/2f23c80e0de44815d26a7d541701e16c9c1d32bc Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod 8304225: Remove javax/script/Test7.java from ProblemList Reviewed-by: naoto ------------- PR: https://git.openjdk.org/jdk/pull/13035 From mchung at openjdk.org Thu Mar 16 16:05:37 2023 From: mchung at openjdk.org (Mandy Chung) Date: Thu, 16 Mar 2023 16:05:37 GMT Subject: RFR: 8304314: StackWalkTest.java fails after CODETOOLS-7903373 In-Reply-To: References: Message-ID: On Thu, 16 Mar 2023 13:26:35 GMT, Leonid Mesnik wrote: > The test depends on the jtreg stack and should be updated. > The fix is backported from loom repo where jtreg with CODETOOLS-7903373 is used. > Tested with current promoted jtreg (without CODETOOLS-7903373) by running test. Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/13058 From naoto at openjdk.org Thu Mar 16 16:09:11 2023 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 16 Mar 2023 16:09:11 GMT Subject: RFR: 8294972: Convert jdk.jlink internal plugins to use the Classfile API [v8] In-Reply-To: References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> Message-ID: On Thu, 16 Mar 2023 07:51:25 GMT, Adam Sotona wrote: >> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/IncludeLocalesPlugin.java line 160: >> >>> 158: resource.type().equals(ResourcePoolEntry.Type.CLASS_OR_RESOURCE)) { >>> 159: byte[] bytes = resource.contentBytes(); >>> 160: if (newClassReader(path, bytes).interfaces().stream() >> >> `IncludeLocalesPluginTest.java` test is failing. Adding `-J-Djlink.debug=true` will get the stack trace: >> >> >> Failed to parse class file: /jdk.localedata/sun/text/resources/ext/LineBreakIteratorData_th >> java.lang.IllegalStateException: Bad magic number >> at java.base/jdk.internal.classfile.impl.ClassReaderImpl.(ClassReaderImpl.java:94) >> at java.base/jdk.internal.classfile.impl.ClassImpl.(ClassImpl.java:68) >> at java.base/jdk.internal.classfile.Classfile.parse(Classfile.java:165) >> at jdk.jlink/jdk.tools.jlink.internal.plugins.AbstractPlugin.newClassReader(AbstractPlugin.java:105) >> at jdk.jlink/jdk.tools.jlink.internal.plugins.IncludeLocalesPlugin.lambda$transform$5(IncludeLocalesPlugin.java:161) >> at jdk.jlink/jdk.tools.jlink.plugin.ResourcePool.lambda$transformAndCopy$0(ResourcePool.java:112) >> at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133) >> at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1924) >> at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762) >> at jdk.jlink/jdk.tools.jlink.plugin.ResourcePool.transformAndCopy(ResourcePool.java:111) >> at jdk.jlink/jdk.tools.jlink.internal.plugins.IncludeLocalesPlugin.transform(IncludeLocalesPlugin.java:154) >> at jdk.jlink/jdk.tools.jlink.internal.ImagePluginStack.visitResources(ImagePluginStack.java:262) >> at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.generateJImage(ImageFileCreator.java:184) >> at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.writeImage(ImageFileCreator.java:163) >> at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.create(ImageFileCreator.java:100) >> at jdk.jlink/jdk.tools.jlink.internal.JlinkTask$ImageHelper.retrieve(JlinkTask.java:889) >> at jdk.jlink/jdk.tools.jlink.internal.ImagePluginStack.operate(ImagePluginStack.java:194) >> at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImage(JlinkTask.java:452) >> at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:292) >> at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:56) >> at jdk.jlink/jdk.tools.jlink.internal.Main.main(Main.java:34) >> Dumping class file 26549-include-locales//jdk.localedata/sun/text/resources/ext/LineBreakIteratorData_th >> ``` >> >> Apparently `/jdk.localedata/sun/text/resources/ext/LineBreakIteratorData_th` is not a valid class file. Using ASM `ClassReader` to parse this resource file succeeds because it does not do much of the class file validation. Instead the ClassFile API throws `IllegalStateException` as it has a bad magic number. >> >> @naotoj what is the file format of this `LineBreakIteratorData_th` file? > > This plugin does not fit to the Classfile API use cases portfolio at all. Here it is only needed to get interfaces list out of the constant pool and then the Utf8 CP entries are in-place modified. That is out of the Classfile API or ASM capabilities. Bad magic number is not the only difference, both libraries fail whenever touching even headers of any other standard classfile elements, only constant pool and interfaces seem to be "safe". > I can prepare very simple standalone helper class dealing with this case to remove ASM dependency. > However knowing more about the file format is always useful :) The file `LineBreakIteratorData_th` is not a class file, thus the exception is appropriate. This plugin test is trying to verify the integrity of the generated jimage, not only the required class files for the specified locale, but also the required resources as such. The file itself is a binary file that the BreakIterator uses internally. ------------- PR: https://git.openjdk.org/jdk/pull/12944 From mchung at openjdk.org Thu Mar 16 16:21:57 2023 From: mchung at openjdk.org (Mandy Chung) Date: Thu, 16 Mar 2023 16:21:57 GMT Subject: RFR: 8294972: Convert jdk.jlink internal plugins to use the Classfile API [v8] In-Reply-To: References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> Message-ID: On Thu, 16 Mar 2023 16:06:15 GMT, Naoto Sato wrote: >> This plugin does not fit to the Classfile API use cases portfolio at all. Here it is only needed to get interfaces list out of the constant pool and then the Utf8 CP entries are in-place modified. That is out of the Classfile API or ASM capabilities. Bad magic number is not the only difference, both libraries fail whenever touching even headers of any other standard classfile elements, only constant pool and interfaces seem to be "safe". >> I can prepare very simple standalone helper class dealing with this case to remove ASM dependency. >> However knowing more about the file format is always useful :) > > The file `LineBreakIteratorData_th` is not a class file, thus the exception is appropriate. This plugin test is trying to verify the integrity of the generated jimage, not only the required class files for the specified locale, but also the required resources as such. The file itself is a binary file that the BreakIterator uses internally. @naotoj as these localedata resource files are not `.class`, the plugin should not use ASM (or Classfile API) to parse it but ASM ClassReader just happens to work. Is the format documented anywhere? @asotona I agree that this ASM dependency should be replaced with a simple class to parse the localedata resources. We can create a follow-up issue to document or validate the file format if appropriate. ------------- PR: https://git.openjdk.org/jdk/pull/12944 From duke at openjdk.org Thu Mar 16 16:57:13 2023 From: duke at openjdk.org (Varada M) Date: Thu, 16 Mar 2023 16:57:13 GMT Subject: RFR: 8304320: java.base does not export jdk.internal.org.objectweb.asm to module jdk.jshell In-Reply-To: References: Message-ID: On Thu, 16 Mar 2023 08:43:46 GMT, Alan Bateman wrote: > jshell was migrated to new the class file API in JDK-8294974 so it shouldn't have any references to ASM anymore. Would it be possible to check if you have a mismatch between your build and the test? Hi @AlanBateman. The changes from JDK-8294974 are there on this branch [module-info.java](https://github.com/varada1110/jdk/blob/verify_jimage/src/java.base/share/classes/module-info.java), [LocalExecutionControl.java](https://github.com/varada1110/jdk/blob/verify_jimage/src/jdk.jshell/share/classes/jdk/jshell/execution/LocalExecutionControl.java) ------------- PR: https://git.openjdk.org/jdk/pull/13057 From naoto at openjdk.org Thu Mar 16 17:04:33 2023 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 16 Mar 2023 17:04:33 GMT Subject: RFR: 8294972: Convert jdk.jlink internal plugins to use the Classfile API [v8] In-Reply-To: References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> Message-ID: On Thu, 16 Mar 2023 16:18:46 GMT, Mandy Chung wrote: >> The file `LineBreakIteratorData_th` is not a class file, thus the exception is appropriate. This plugin test is trying to verify the integrity of the generated jimage, not only the required class files for the specified locale, but also the required resources as such. The file itself is a binary file that the BreakIterator uses internally. > > @naotoj as these localedata resource files are not `.class`, the plugin should not use ASM (or Classfile API) to parse it but ASM ClassReader just happens to work. Is the format documented anywhere? > > @asotona I agree that this ASM dependency should be replaced with a simple class to parse the localedata resources. We can create a follow-up issue to document or validate the file format if appropriate. There is no common binary format for "localedata", the file in question is the custom format specific for `BreakIterator`, ancient code from Taligent. IIUC, only description of the format is in the source: https://github.com/openjdk/jdk/blob/2f23c80e0de44815d26a7d541701e16c9c1d32bc/src/java.base/share/classes/sun/text/RuleBasedBreakIterator.java#L325 ------------- PR: https://git.openjdk.org/jdk/pull/12944 From liach at openjdk.org Thu Mar 16 17:13:31 2023 From: liach at openjdk.org (Chen Liang) Date: Thu, 16 Mar 2023 17:13:31 GMT Subject: RFR: 8304360: Test to ensure ConstantDescs fields work Message-ID: https://github.com/openjdk/jdk/pull/13033#issuecomment-1470857327 Add a test to validate that all constants in ConstantDescs can be resolved with a minimally-trusted lookup, and select constants represent the objects they claim to be. ------------- Commit messages: - Whitespace - constantdescs field tests Changes: https://git.openjdk.org/jdk/pull/13064/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13064&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304360 Stats: 138 lines in 1 file changed: 138 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13064.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13064/head:pull/13064 PR: https://git.openjdk.org/jdk/pull/13064 From jvernee at openjdk.org Thu Mar 16 18:17:36 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 16 Mar 2023 18:17:36 GMT Subject: RFR: 8304360: Test to ensure ConstantDescs fields work In-Reply-To: References: Message-ID: On Thu, 16 Mar 2023 16:58:53 GMT, Chen Liang wrote: > https://github.com/openjdk/jdk/pull/13033#issuecomment-1470857327 > > Add a test to validate that all constants in ConstantDescs can be resolved with a minimally-trusted lookup, and select constants represent the objects they claim to be. test/jdk/java/lang/constant/ConstantDescsTest.java line 65: > 63: */ > 64: @Test > 65: public void validateAllFields() throws ReflectiveOperationException { It might be nice to use a `@DataProvider` to feed in the different ConstantDescs and expected resolved values. Saves on some of the duplication. ------------- PR: https://git.openjdk.org/jdk/pull/13064 From jlu at openjdk.org Thu Mar 16 18:19:29 2023 From: jlu at openjdk.org (Justin Lu) Date: Thu, 16 Mar 2023 18:19:29 GMT Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v2] In-Reply-To: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com> References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com> Message-ID: > This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii. > > In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file. Justin Lu has updated the pull request incrementally with four additional commits since the last revision: - Bug6204853 should not be converted - Copyright year for CompileProperties - Redo translation for CS.properties - Spot convert CurrencySymbols.properties ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12726/files - new: https://git.openjdk.org/jdk/pull/12726/files/1e798f24..6d6bffe8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12726&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12726&range=00-01 Stats: 92 lines in 4 files changed: 0 ins; 0 del; 92 mod Patch: https://git.openjdk.org/jdk/pull/12726.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12726/head:pull/12726 PR: https://git.openjdk.org/jdk/pull/12726 From jlu at openjdk.org Thu Mar 16 18:21:40 2023 From: jlu at openjdk.org (Justin Lu) Date: Thu, 16 Mar 2023 18:21:40 GMT Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v2] In-Reply-To: References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com> Message-ID: On Thu, 16 Mar 2023 18:19:29 GMT, Justin Lu wrote: >> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii. >> >> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file. > > Justin Lu has updated the pull request incrementally with four additional commits since the last revision: > > - Bug6204853 should not be converted > - Copyright year for CompileProperties > - Redo translation for CS.properties > - Spot convert CurrencySymbols.properties test/jdk/java/text/Format/NumberFormat/CurrencySymbols.properties line 1: > 1: # Conversion did not work as expected, addressing right now. ------------- PR: https://git.openjdk.org/jdk/pull/12726 From jlu at openjdk.org Thu Mar 16 18:21:43 2023 From: jlu at openjdk.org (Justin Lu) Date: Thu, 16 Mar 2023 18:21:43 GMT Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v2] In-Reply-To: References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com> Message-ID: On Wed, 15 Mar 2023 20:19:51 GMT, Naoto Sato wrote: >> Justin Lu has updated the pull request incrementally with four additional commits since the last revision: >> >> - Bug6204853 should not be converted >> - Copyright year for CompileProperties >> - Redo translation for CS.properties >> - Spot convert CurrencySymbols.properties > > test/jdk/java/text/Format/NumberFormat/CurrencySymbols.properties line 156: > >> 154: zh=\u00A4 >> 155: zh_CN=\uFFE5 >> 156: zh_HK=HK$ > > Why are they not encoded into UTF-8 native? Not sure, thank you for catching it. Working on it right now. ------------- PR: https://git.openjdk.org/jdk/pull/12726 From jlu at openjdk.org Thu Mar 16 18:21:46 2023 From: jlu at openjdk.org (Justin Lu) Date: Thu, 16 Mar 2023 18:21:46 GMT Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v2] In-Reply-To: <1I9v8d2OiyLfQVCozGYVRhAi3AotqGuRUhsNj0VCsUk=.e673ca33-d24f-4aab-908e-a5c0bfa3bf7c@github.com> References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com> <1I9v8d2OiyLfQVCozGYVRhAi3AotqGuRUhsNj0VCsUk=.e673ca33-d24f-4aab-908e-a5c0bfa3bf7c@github.com> Message-ID: <_6WBGo5CQBseDEjMv16qCWmodFlYOO4gsT9WbON7ddA=.f94339a4-8893-47e4-8bb1-f28a8807ad9d@github.com> On Wed, 15 Mar 2023 16:18:44 GMT, Archie L. Cobbs wrote: >> Justin Lu has updated the pull request incrementally with four additional commits since the last revision: >> >> - Bug6204853 should not be converted >> - Copyright year for CompileProperties >> - Redo translation for CS.properties >> - Spot convert CurrencySymbols.properties > > test/jdk/java/util/ResourceBundle/Bug6204853.properties line 1: > >> 1: # > > This file should probably be excluded because it's used in a test that relates to UTF-8 encoding (or not) of property files. Thank you, removed the changes for this file ------------- PR: https://git.openjdk.org/jdk/pull/12726 From jlu at openjdk.org Thu Mar 16 18:35:51 2023 From: jlu at openjdk.org (Justin Lu) Date: Thu, 16 Mar 2023 18:35:51 GMT Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v3] In-Reply-To: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com> References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com> Message-ID: > This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii. > > In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file. Justin Lu has updated the pull request incrementally with two additional commits since the last revision: - Reconvert CS.properties to UTF-8 - Revert all changes to CurrencySymbols.properties ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12726/files - new: https://git.openjdk.org/jdk/pull/12726/files/6d6bffe8..7119830b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12726&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12726&range=01-02 Stats: 87 lines in 1 file changed: 0 ins; 0 del; 87 mod Patch: https://git.openjdk.org/jdk/pull/12726.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12726/head:pull/12726 PR: https://git.openjdk.org/jdk/pull/12726 From jlu at openjdk.org Thu Mar 16 18:35:54 2023 From: jlu at openjdk.org (Justin Lu) Date: Thu, 16 Mar 2023 18:35:54 GMT Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v3] In-Reply-To: References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com> Message-ID: On Thu, 16 Mar 2023 18:31:23 GMT, Justin Lu wrote: >> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii. >> >> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file. > > Justin Lu has updated the pull request incrementally with two additional commits since the last revision: > > - Reconvert CS.properties to UTF-8 > - Revert all changes to CurrencySymbols.properties test/jdk/java/text/Format/NumberFormat/CurrencySymbols.properties line 1: > 1: # CurrencySymbols.properties is fully converted to UTF-8 now ------------- PR: https://git.openjdk.org/jdk/pull/12726 From liach at openjdk.org Thu Mar 16 18:40:12 2023 From: liach at openjdk.org (Chen Liang) Date: Thu, 16 Mar 2023 18:40:12 GMT Subject: RFR: 8304360: Test to ensure ConstantDescs fields work [v2] In-Reply-To: References: Message-ID: <9T9a5BeZ3OQEKvzEpWaaaBpBbrjPtGBFLeJNMLeoJm8=.caf64685-a487-4c30-984e-8feeed952515@github.com> > https://github.com/openjdk/jdk/pull/13033#issuecomment-1470857327 > > Add a test to validate that all constants in ConstantDescs can be resolved with a minimally-trusted lookup, and select constants represent the objects they claim to be. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Switch to DataProvider ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13064/files - new: https://git.openjdk.org/jdk/pull/13064/files/73605ffc..af7127f5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13064&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13064&range=00-01 Stats: 110 lines in 1 file changed: 56 ins; 50 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/13064.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13064/head:pull/13064 PR: https://git.openjdk.org/jdk/pull/13064 From liach at openjdk.org Thu Mar 16 18:40:17 2023 From: liach at openjdk.org (Chen Liang) Date: Thu, 16 Mar 2023 18:40:17 GMT Subject: RFR: 8304360: Test to ensure ConstantDescs fields work [v2] In-Reply-To: References: Message-ID: On Thu, 16 Mar 2023 18:12:23 GMT, Jorn Vernee wrote: >> Chen Liang has updated the pull request incrementally with one additional commit since the last revision: >> >> Switch to DataProvider > > test/jdk/java/lang/constant/ConstantDescsTest.java line 65: > >> 63: */ >> 64: @Test >> 65: public void validateAllFields() throws ReflectiveOperationException { > > It might be nice to use a `@DataProvider` to feed in the different ConstantDescs and expected resolved values. Saves on some of the duplication. Done. Replaced `assertSame` with `assertEquals` as future constant descs may resolve to equals-based than identity-based constants. ------------- PR: https://git.openjdk.org/jdk/pull/13064 From mchung at openjdk.org Thu Mar 16 18:43:34 2023 From: mchung at openjdk.org (Mandy Chung) Date: Thu, 16 Mar 2023 18:43:34 GMT Subject: RFR: 8294972: Convert jdk.jlink internal plugins to use the Classfile API [v8] In-Reply-To: References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> Message-ID: On Thu, 16 Mar 2023 17:00:59 GMT, Naoto Sato wrote: >> @naotoj as these localedata resource files are not `.class`, the plugin should not use ASM (or Classfile API) to parse it but ASM ClassReader just happens to work. Is the format documented anywhere? >> >> @asotona I agree that this ASM dependency should be replaced with a simple class to parse the localedata resources. We can create a follow-up issue to document or validate the file format if appropriate. > > There is no common binary format for "localedata", the file in question is the custom format specific for `BreakIterator`, ancient code from Taligent. IIUC, only description of the format is in the source: https://github.com/openjdk/jdk/blob/2f23c80e0de44815d26a7d541701e16c9c1d32bc/src/java.base/share/classes/sun/text/RuleBasedBreakIterator.java#L325 I further clarified with Naoto and I now understand the problem. The plugin intends to transform `.class` that implements `LocaleDataMetaInfo` in `jdk.localedata` module. It's a bug in the plugin `--include-locales=*` which will read all resources from `jdk.localedata` with ASM ClassReader and the plugin just happens to work. The plugin should only read `.class` entries or specific `LocaleDataMetaInfo` implementation classes. I created https://bugs.openjdk.org/browse/JDK-8304367 that Naoto will help fixing. @asotona your previous version converting it to ClassFile API should work after JDK-8304367. ------------- PR: https://git.openjdk.org/jdk/pull/12944 From jlu at openjdk.org Thu Mar 16 18:44:29 2023 From: jlu at openjdk.org (Justin Lu) Date: Thu, 16 Mar 2023 18:44:29 GMT Subject: RFR: 8225641: Calendar.roll(int field) does not work correctly for WEEK_OF_YEAR In-Reply-To: References: Message-ID: On Wed, 15 Mar 2023 19:53:07 GMT, Naoto Sato wrote: >> This PR fixes the bug which occurred when `Calendar.roll(WEEK_OF_YEAR)` rolled into a minimal first week with an invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo. >> >> For example, Rolling _Monday, 30 December 2019_ by 1 week produced _Monday, 31 December 2018_, which is incorrect. This is because `WEEK_OF_YEAR` is rolled from 52 to 1, and the original `DAY_OF_WEEK` is 1. However, there is no Monday in week 1 of 2019. This is exposed when a future method calls `Calendar.complete()`, which eventually calculates a `fixedDate` with the invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo. >> >> To prevent this, a check is added for rolls into week 1, which determines if the first week is minimal. If it is indeed minimal, then it is checked if `DAY_OF_WEEK` exists in that week, if not, `WEEK_OF_YEAR` must be incremented by one. >> >> After the fix, Rolling _Monday, 30 December 2019_ by 1 week produces _Monday, 7 January 2019_ > > test/jdk/java/util/Calendar/RollToMinWeek.java line 30: > >> 28: * is rolled into a minimal week 1 >> 29: * @run junit RollToMinWeek >> 30: */ > > Have you considered adding test cases into `test/jdk/java/util/Calendar/CalendarTestScripts`, instead of creating a single-purpose test case? Will take a look at the existing .cts files and see if it would be advantageous to add test cases there ------------- PR: https://git.openjdk.org/jdk/pull/13031 From jlu at openjdk.org Thu Mar 16 18:48:23 2023 From: jlu at openjdk.org (Justin Lu) Date: Thu, 16 Mar 2023 18:48:23 GMT Subject: RFR: 8225641: Calendar.roll(int field) does not work correctly for WEEK_OF_YEAR In-Reply-To: References: Message-ID: <8YW1fWa2eJf9MrcWzgQWke7pvgREQSkoFD8r1ojRPk4=.95bdb334-114c-432c-950f-ba46241c4950@github.com> On Wed, 15 Mar 2023 19:50:46 GMT, Naoto Sato wrote: >> This PR fixes the bug which occurred when `Calendar.roll(WEEK_OF_YEAR)` rolled into a minimal first week with an invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo. >> >> For example, Rolling _Monday, 30 December 2019_ by 1 week produced _Monday, 31 December 2018_, which is incorrect. This is because `WEEK_OF_YEAR` is rolled from 52 to 1, and the original `DAY_OF_WEEK` is 1. However, there is no Monday in week 1 of 2019. This is exposed when a future method calls `Calendar.complete()`, which eventually calculates a `fixedDate` with the invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo. >> >> To prevent this, a check is added for rolls into week 1, which determines if the first week is minimal. If it is indeed minimal, then it is checked if `DAY_OF_WEEK` exists in that week, if not, `WEEK_OF_YEAR` must be incremented by one. >> >> After the fix, Rolling _Monday, 30 December 2019_ by 1 week produces _Monday, 7 January 2019_ > > src/java.base/share/classes/java/util/GregorianCalendar.java line 3030: > >> 3028: } >> 3029: } >> 3030: > > Are these `GregorianCalendar` specific? What about other calendars? Good point, these are _probably_ applicable to the other calendars, will take another look there. ------------- PR: https://git.openjdk.org/jdk/pull/13031 From mchung at openjdk.org Thu Mar 16 19:13:07 2023 From: mchung at openjdk.org (Mandy Chung) Date: Thu, 16 Mar 2023 19:13:07 GMT Subject: RFR: 8304180: Constant Descriptors for MethodHandles::classData and classDataAt In-Reply-To: References: Message-ID: On Wed, 15 Mar 2023 02:18:37 GMT, Chen Liang wrote: > Add Constant Descriptors for DirectMethodHandleDesc of MethodHandles::classData and classDataAt in ConstantDescs. This facilitates easier access of class data via condy in Classfile API-generated bytecode. Most other constant bootstrap methods provided in the JDK, notably from `ConstantBootstraps`, already have constant descriptors in ConstantDescs. > > Context: https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000235.html This looks good. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.org/jdk/pull/13033 From alanb at openjdk.org Thu Mar 16 19:14:05 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 16 Mar 2023 19:14:05 GMT Subject: RFR: 8297605: DelayQueue javadoc is confusing In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 20:00:56 GMT, Martin Buchholz wrote: > Inviting @DougLea and @viktorklang-ora to review. > > As usual, I couldn't resist more fiddling. > - Added missing tests for take, remove(), remove(Object). > - Improved DelayQueueTest's testing infrastructure > - added more test assertions > - linkified new javadoc definitions Wordy but clear, I think it's okay. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.org/jdk/pull/12838 From mchung at openjdk.org Thu Mar 16 19:19:47 2023 From: mchung at openjdk.org (Mandy Chung) Date: Thu, 16 Mar 2023 19:19:47 GMT Subject: RFR: 8304360: Test to ensure ConstantDescs fields work [v2] In-Reply-To: <9T9a5BeZ3OQEKvzEpWaaaBpBbrjPtGBFLeJNMLeoJm8=.caf64685-a487-4c30-984e-8feeed952515@github.com> References: <9T9a5BeZ3OQEKvzEpWaaaBpBbrjPtGBFLeJNMLeoJm8=.caf64685-a487-4c30-984e-8feeed952515@github.com> Message-ID: <34qLJmYeHjUUYfQpvb-yrv991j-99e3DdpFZu2Gy8hA=.4774e68b-8dc4-4610-a87e-7816a16df6df@github.com> On Thu, 16 Mar 2023 18:40:12 GMT, Chen Liang wrote: >> https://github.com/openjdk/jdk/pull/13033#issuecomment-1470857327 >> >> Add a test to validate that all constants in ConstantDescs can be resolved with a minimally-trusted lookup, and select constants represent the objects they claim to be. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Switch to DataProvider Thanks for adding the test. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.org/jdk/pull/13064 From alanb at openjdk.org Thu Mar 16 19:35:19 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 16 Mar 2023 19:35:19 GMT Subject: RFR: JDK-8303742: CompletableFuture.orTimeout leaks if the future completes exceptionally In-Reply-To: References: Message-ID: On Thu, 16 Mar 2023 13:37:10 GMT, Viktor Klang wrote: > Addresses the situation where exceptional completion of `orTimeout`:ed CompletableFutures wouldn't cancel the timeout task which could lead to memory leaks if done frequently enough with long enough timeout durations. > > Fix discussed with @DougLea The update to CF looks good. The test looks okay it as it fails in a few seconds without the change. ------------- PR: https://git.openjdk.org/jdk/pull/13059 From jvernee at openjdk.org Thu Mar 16 19:35:20 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 16 Mar 2023 19:35:20 GMT Subject: RFR: 8304360: Test to ensure ConstantDescs fields work [v2] In-Reply-To: <9T9a5BeZ3OQEKvzEpWaaaBpBbrjPtGBFLeJNMLeoJm8=.caf64685-a487-4c30-984e-8feeed952515@github.com> References: <9T9a5BeZ3OQEKvzEpWaaaBpBbrjPtGBFLeJNMLeoJm8=.caf64685-a487-4c30-984e-8feeed952515@github.com> Message-ID: On Thu, 16 Mar 2023 18:40:12 GMT, Chen Liang wrote: >> https://github.com/openjdk/jdk/pull/13033#issuecomment-1470857327 >> >> Add a test to validate that all constants in ConstantDescs can be resolved with a minimally-trusted lookup, and select constants represent the objects they claim to be. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Switch to DataProvider Marked as reviewed by jvernee (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/13064 From duke at openjdk.org Thu Mar 16 19:35:21 2023 From: duke at openjdk.org (ExE Boss) Date: Thu, 16 Mar 2023 19:35:21 GMT Subject: RFR: 8304360: Test to ensure ConstantDescs fields work [v2] In-Reply-To: <9T9a5BeZ3OQEKvzEpWaaaBpBbrjPtGBFLeJNMLeoJm8=.caf64685-a487-4c30-984e-8feeed952515@github.com> References: <9T9a5BeZ3OQEKvzEpWaaaBpBbrjPtGBFLeJNMLeoJm8=.caf64685-a487-4c30-984e-8feeed952515@github.com> Message-ID: On Thu, 16 Mar 2023 18:40:12 GMT, Chen Liang wrote: >> https://github.com/openjdk/jdk/pull/13033#issuecomment-1470857327 >> >> Add a test to validate that all constants in ConstantDescs can be resolved with a minimally-trusted lookup, and select constants represent the objects they claim to be. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Switch to DataProvider There should probably also?be?tests for?the?[`DirectMethodHandleDesc`]?fields which?inspect the?[`MethodHandleInfo`] obtained?using [`MethodHandles::reflectAs?(Class,?MethodHandle)`]. [`DirectMethodHandleDesc`]: https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/lang/constant/DirectMethodHandleDesc.html [`MethodHandleInfo`]: https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/lang/invoke/MethodHandleInfo.html [`MethodHandles::reflectAs?(Class,?MethodHandle)`]: https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/lang/invoke/MethodHandles.html#reflectAs(java.lang.Class,java.lang.invoke.MethodHandle) ------------- PR: https://git.openjdk.org/jdk/pull/13064 From liach at openjdk.org Thu Mar 16 19:45:48 2023 From: liach at openjdk.org (Chen Liang) Date: Thu, 16 Mar 2023 19:45:48 GMT Subject: RFR: 8304360: Test to ensure ConstantDescs fields work [v2] In-Reply-To: <9T9a5BeZ3OQEKvzEpWaaaBpBbrjPtGBFLeJNMLeoJm8=.caf64685-a487-4c30-984e-8feeed952515@github.com> References: <9T9a5BeZ3OQEKvzEpWaaaBpBbrjPtGBFLeJNMLeoJm8=.caf64685-a487-4c30-984e-8feeed952515@github.com> Message-ID: On Thu, 16 Mar 2023 18:40:12 GMT, Chen Liang wrote: >> https://github.com/openjdk/jdk/pull/13033#issuecomment-1470857327 >> >> Add a test to validate that all constants in ConstantDescs can be resolved with a minimally-trusted lookup, and select constants represent the objects they claim to be. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Switch to DataProvider > There should probably also?be?tests for?the?[`DirectMethodHandleDesc`](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/lang/constant/DirectMethodHandleDesc.html)?fields which?inspect the?[`MethodHandleInfo`](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/lang/invoke/MethodHandleInfo.html) obtained?using [`MethodHandles::reflectAs?(Class,?MethodHandle)`](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/lang/invoke/MethodHandles.html#reflectAs(java.lang.Class,java.lang.invoke.MethodHandle)). Don't think this is worth it: 1. This requires extra String literals in the test for method names, which is way more error-prone than the other constant literals checked by the compiler. 2. If a method handle desc is wrong, a typo would usually make the desc invalid than refer to another method, which is already guarded by the second test. ------------- PR: https://git.openjdk.org/jdk/pull/13064 From aturbanov at openjdk.org Thu Mar 16 20:15:45 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 16 Mar 2023 20:15:45 GMT Subject: RFR: JDK-8303742: CompletableFuture.orTimeout leaks if the future completes exceptionally In-Reply-To: References: Message-ID: On Thu, 16 Mar 2023 13:37:10 GMT, Viktor Klang wrote: > Addresses the situation where exceptional completion of `orTimeout`:ed CompletableFutures wouldn't cancel the timeout task which could lead to memory leaks if done frequently enough with long enough timeout durations. > > Fix discussed with @DougLea test/jdk/java/util/concurrent/CompletableFuture/CompletableFutureOrTimeoutExceptionallyTest.java line 45: > 43: var startTime = System.currentTimeMillis(); > 44: var testRunTime = Duration.ofSeconds(10).toMillis(); > 45: while((System.currentTimeMillis() - startTime) < testRunTime) { Suggestion: while ((System.currentTimeMillis() - startTime) < testRunTime) { ------------- PR: https://git.openjdk.org/jdk/pull/13059 From naoto at openjdk.org Thu Mar 16 20:48:31 2023 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 16 Mar 2023 20:48:31 GMT Subject: RFR: 8294972: Convert jdk.jlink internal plugins to use the Classfile API [v8] In-Reply-To: References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> Message-ID: On Thu, 16 Mar 2023 18:40:16 GMT, Mandy Chung wrote: >> There is no common binary format for "localedata", the file in question is the custom format specific for `BreakIterator`, ancient code from Taligent. IIUC, only description of the format is in the source: https://github.com/openjdk/jdk/blob/2f23c80e0de44815d26a7d541701e16c9c1d32bc/src/java.base/share/classes/sun/text/RuleBasedBreakIterator.java#L325 > > I further clarified with Naoto and I now understand the problem. The plugin intends to transform `.class` that implements `LocaleDataMetaInfo` in `jdk.localedata` module. It's a bug in the plugin `--include-locales=*` which will read all resources from `jdk.localedata` with ASM ClassReader and the plugin just happens to work. The plugin should only read `.class` entries or specific `LocaleDataMetaInfo` implementation classes. I created https://bugs.openjdk.org/browse/JDK-8304367 that Naoto will help fixing. > > @asotona your previous version converting it to ClassFile API should work after JDK-8304367. Submitted: https://github.com/openjdk/jdk/pull/13067 ------------- PR: https://git.openjdk.org/jdk/pull/12944 From naoto at openjdk.org Thu Mar 16 20:52:19 2023 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 16 Mar 2023 20:52:19 GMT Subject: RFR: 8304367: jlink --include-locales=* attempts to parse non .class resource files with classfile reader Message-ID: <-CFwdEf9n350xgKQWZmfFp0MxqrWoobQ8mHyUXdWDPQ=.4a4e678b-40fb-4eb3-a5a7-52156d9df2a4@github.com> This is a blocker for [JDK-8294972](https://bugs.openjdk.org/browse/JDK-8294972). The fix is to weed out non-class files for calling `ClassReader` by checking the file extension. Regression tests are not provided as it is not possible to detect the fix from the artifact jimage, but manually confirmed it would effectively weed out `LineBreakIteratorData_th`, `WordBreakIteratorData_th`, and `thai_dict` files by running `IncludeLocalesPluginTest.java`. ------------- Commit messages: - 8304367: jlink --include-locales=* attempts to parse non .class resource files with classfile reader Changes: https://git.openjdk.org/jdk/pull/13067/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13067&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304367 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13067.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13067/head:pull/13067 PR: https://git.openjdk.org/jdk/pull/13067 From mchung at openjdk.org Thu Mar 16 20:52:33 2023 From: mchung at openjdk.org (Mandy Chung) Date: Thu, 16 Mar 2023 20:52:33 GMT Subject: RFR: 8304139: Add , , and main method constants to ClassDescs In-Reply-To: References: Message-ID: On Tue, 14 Mar 2023 14:30:32 GMT, Chen Liang wrote: > Add String constants INIT_NAME, CLASS_INIT_NAME, MTD_void for the names and method type of instance and class initializers; add String constant MAIN_NAME and MTD_void_StringArray for the name and method type of main method. > > Update occurrences of and in core libraries API specification to refer to these constants. The occurrences in code elsewhere will be converted separately for there are too many. > > See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000233.html src/java.base/share/classes/java/lang/constant/ConstantDescs.java line 288: > 286: /** > 287: * The special name of instance initialization methods, {@value}. They > 288: * typically correspond to constructors. What about this to describe the signature: Suggestion: * The special name of instance initialization methods, {@value}. An instance * initialization method has this special name and is {@code void}. src/java.base/share/classes/java/lang/constant/ConstantDescs.java line 297: > 295: /** > 296: * The special name of class initialization methods, {@value}. They > 297: * typically correspond to static initializers. Suggestion: * The special name of class initialization methods, {@value}. A class * initialization method has this special name, {@link AccessFlag#STATIC * ACC_STATIC} flag set and is {@link #MTD_void void} taking no arguments. src/java.base/share/classes/java/lang/constant/ConstantDescs.java line 315: > 313: * @since 21 > 314: */ > 315: public static final MethodTypeDesc MTD_void = MethodTypeDesc.of(CD_void); This is a generic method type descriptor and not restrict to initialization methods. So I think no need to mention that "This is the method type of initialization methods ..." and `@jvms, @see and @jls" references. Maybe it can be as simple as: Nominal descriptor representing the method descriptor {@code ()V}, taking no argument and returning {@code void}. src/java.base/share/classes/java/lang/constant/ConstantDescs.java line 326: > 324: * @since 21 > 325: */ > 326: public static final String MAIN_NAME = "main"; I'm not sure if predefined constants for "main" and its method type descriptor are highly needed. ------------- PR: https://git.openjdk.org/jdk/pull/13020 From duke at openjdk.org Thu Mar 16 20:56:00 2023 From: duke at openjdk.org (Viktor Klang) Date: Thu, 16 Mar 2023 20:56:00 GMT Subject: RFR: JDK-8303742: CompletableFuture.orTimeout leaks if the future completes exceptionally [v2] In-Reply-To: References: Message-ID: > Addresses the situation where exceptional completion of `orTimeout`:ed CompletableFutures wouldn't cancel the timeout task which could lead to memory leaks if done frequently enough with long enough timeout durations. > > Fix discussed with @DougLea Viktor Klang has updated the pull request incrementally with one additional commit since the last revision: Update test/jdk/java/util/concurrent/CompletableFuture/CompletableFutureOrTimeoutExceptionallyTest.java Co-authored-by: Andrey Turbanov ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13059/files - new: https://git.openjdk.org/jdk/pull/13059/files/d46a6bed..15e8fcc2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13059&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13059&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13059.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13059/head:pull/13059 PR: https://git.openjdk.org/jdk/pull/13059 From prappo at openjdk.org Thu Mar 16 20:56:00 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Thu, 16 Mar 2023 20:56:00 GMT Subject: RFR: JDK-8303742: CompletableFuture.orTimeout leaks if the future completes exceptionally [v2] In-Reply-To: References: Message-ID: On Thu, 16 Mar 2023 20:51:37 GMT, Viktor Klang wrote: >> Addresses the situation where exceptional completion of `orTimeout`:ed CompletableFutures wouldn't cancel the timeout task which could lead to memory leaks if done frequently enough with long enough timeout durations. >> >> Fix discussed with @DougLea > > Viktor Klang has updated the pull request incrementally with one additional commit since the last revision: > > Update test/jdk/java/util/concurrent/CompletableFuture/CompletableFutureOrTimeoutExceptionallyTest.java > > Co-authored-by: Andrey Turbanov test/jdk/java/util/concurrent/CompletableFuture/CompletableFutureOrTimeoutExceptionallyTest.java line 44: > 42: void testOrTimeoutWithCompleteExceptionallyDoesNotLeak() throws Exception { > 43: var startTime = System.currentTimeMillis(); > 44: var testRunTime = Duration.ofSeconds(10).toMillis(); This "create completable futures in a loop for t seconds" seems a bit brittle. Would 10 or 20 seconds be enough for a typical test machine to fail with OOME? Could this be improved by requiring a minimum number of CF instances to be created? Maybe finishing when t seconds have elapsed _and_ n instances have been created. Separately, as with any timeouts, consider a monotonic clock. ------------- PR: https://git.openjdk.org/jdk/pull/13059 From liach at openjdk.org Thu Mar 16 20:58:35 2023 From: liach at openjdk.org (Chen Liang) Date: Thu, 16 Mar 2023 20:58:35 GMT Subject: Integrated: 8304360: Test to ensure ConstantDescs fields work In-Reply-To: References: Message-ID: <65kxtWpgW-6u3OpC1OW9uTX6ZvHIgI1evkxWUolhzCc=.ea17179c-710a-47d9-a07e-00664c1c0074@github.com> On Thu, 16 Mar 2023 16:58:53 GMT, Chen Liang wrote: > https://github.com/openjdk/jdk/pull/13033#issuecomment-1470857327 > > Add a test to validate that all constants in ConstantDescs can be resolved with a minimally-trusted lookup, and select constants represent the objects they claim to be. This pull request has now been integrated. Changeset: 2e987d79 Author: Chen Liang Committer: Jorn Vernee URL: https://git.openjdk.org/jdk/commit/2e987d798aa27321207325a18971f80219695e24 Stats: 144 lines in 1 file changed: 144 ins; 0 del; 0 mod 8304360: Test to ensure ConstantDescs fields work Reviewed-by: mchung, jvernee ------------- PR: https://git.openjdk.org/jdk/pull/13064 From mchung at openjdk.org Thu Mar 16 21:01:20 2023 From: mchung at openjdk.org (Mandy Chung) Date: Thu, 16 Mar 2023 21:01:20 GMT Subject: RFR: 8304367: jlink --include-locales=* attempts to parse non .class resource files with classfile reader In-Reply-To: <-CFwdEf9n350xgKQWZmfFp0MxqrWoobQ8mHyUXdWDPQ=.4a4e678b-40fb-4eb3-a5a7-52156d9df2a4@github.com> References: <-CFwdEf9n350xgKQWZmfFp0MxqrWoobQ8mHyUXdWDPQ=.4a4e678b-40fb-4eb3-a5a7-52156d9df2a4@github.com> Message-ID: On Thu, 16 Mar 2023 20:43:38 GMT, Naoto Sato wrote: > This is a blocker for [JDK-8294972](https://bugs.openjdk.org/browse/JDK-8294972). The fix is to weed out non-class files for calling `ClassReader` by checking the file extension. Regression tests are not provided as it is not possible to detect the fix from the artifact jimage, but manually confirmed it would effectively weed out `LineBreakIteratorData_th`, `WordBreakIteratorData_th`, and `thai_dict` files by running `IncludeLocalesPluginTest.java`. Marked as reviewed by mchung (Reviewer). > confirmed it would effectively weed out `LineBreakIteratorData_th`, `WordBreakIteratorData_th`, and `thai_dict` files by running IncludeLocalesPluginTest.java. I think you meant these files are filtered out but they remain in the resulting image. ------------- PR: https://git.openjdk.org/jdk/pull/13067 From lancea at openjdk.org Thu Mar 16 21:01:21 2023 From: lancea at openjdk.org (Lance Andersen) Date: Thu, 16 Mar 2023 21:01:21 GMT Subject: RFR: 8304367: jlink --include-locales=* attempts to parse non .class resource files with classfile reader In-Reply-To: <-CFwdEf9n350xgKQWZmfFp0MxqrWoobQ8mHyUXdWDPQ=.4a4e678b-40fb-4eb3-a5a7-52156d9df2a4@github.com> References: <-CFwdEf9n350xgKQWZmfFp0MxqrWoobQ8mHyUXdWDPQ=.4a4e678b-40fb-4eb3-a5a7-52156d9df2a4@github.com> Message-ID: On Thu, 16 Mar 2023 20:43:38 GMT, Naoto Sato wrote: > This is a blocker for [JDK-8294972](https://bugs.openjdk.org/browse/JDK-8294972). The fix is to weed out non-class files for calling `ClassReader` by checking the file extension. Regression tests are not provided as it is not possible to detect the fix from the artifact jimage, but manually confirmed it would effectively weed out `LineBreakIteratorData_th`, `WordBreakIteratorData_th`, and `thai_dict` files by running `IncludeLocalesPluginTest.java`. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/13067 From naoto at openjdk.org Thu Mar 16 21:01:24 2023 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 16 Mar 2023 21:01:24 GMT Subject: RFR: 8304367: jlink --include-locales=* attempts to parse non .class resource files with classfile reader In-Reply-To: References: <-CFwdEf9n350xgKQWZmfFp0MxqrWoobQ8mHyUXdWDPQ=.4a4e678b-40fb-4eb3-a5a7-52156d9df2a4@github.com> Message-ID: <0UWG9H8v2hzPuHjgdbUd2nytQePb081uiNUCS-SdSbw=.b8cc23f9-15f8-4f01-b5cf-201e4358f61e@github.com> On Thu, 16 Mar 2023 20:54:49 GMT, Mandy Chung wrote: > > confirmed it would effectively weed out `LineBreakIteratorData_th`, `WordBreakIteratorData_th`, and `thai_dict` files by running IncludeLocalesPluginTest.java. > > I think you meant these files are filtered out but they remain in the resulting image. Yes ------------- PR: https://git.openjdk.org/jdk/pull/13067 From duke at openjdk.org Thu Mar 16 21:12:51 2023 From: duke at openjdk.org (Viktor Klang) Date: Thu, 16 Mar 2023 21:12:51 GMT Subject: RFR: JDK-8303742: CompletableFuture.orTimeout leaks if the future completes exceptionally [v2] In-Reply-To: References: Message-ID: On Thu, 16 Mar 2023 20:51:29 GMT, Pavel Rappo wrote: >> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision: >> >> Update test/jdk/java/util/concurrent/CompletableFuture/CompletableFutureOrTimeoutExceptionallyTest.java >> >> Co-authored-by: Andrey Turbanov > > test/jdk/java/util/concurrent/CompletableFuture/CompletableFutureOrTimeoutExceptionallyTest.java line 44: > >> 42: void testOrTimeoutWithCompleteExceptionallyDoesNotLeak() throws Exception { >> 43: var startTime = System.currentTimeMillis(); >> 44: var testRunTime = Duration.ofSeconds(10).toMillis(); > > This "create completable futures in a loop for t seconds" seems a bit brittle. Would 10 or 20 seconds be enough for a typical test machine to fail with OOME? Could this be improved by requiring a minimum number of CF instances to be created? Maybe finishing when t seconds have elapsed _and_ n instances have been created. > > Separately, as with any timeouts, consider a monotonic clock. @pavelrappo Both good points?I'm updating it to use nanoTime + requiring 5M iterations of the loop to be safer. ------------- PR: https://git.openjdk.org/jdk/pull/13059 From prappo at openjdk.org Thu Mar 16 21:25:47 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Thu, 16 Mar 2023 21:25:47 GMT Subject: RFR: JDK-8303742: CompletableFuture.orTimeout leaks if the future completes exceptionally [v3] In-Reply-To: References: Message-ID: On Thu, 16 Mar 2023 21:21:51 GMT, Viktor Klang wrote: >> Addresses the situation where exceptional completion of `orTimeout`:ed CompletableFutures wouldn't cancel the timeout task which could lead to memory leaks if done frequently enough with long enough timeout durations. >> >> Fix discussed with @DougLea > > Viktor Klang has updated the pull request incrementally with one additional commit since the last revision: > > Making the test for orTimeout+completeExceptionally only based on iterations and not duration. test/jdk/java/util/concurrent/CompletableFuture/CompletableFutureOrTimeoutExceptionallyTest.java line 2: > 1: /* > 2: * Copyright (c) 2019, 2023, Oracle and/or its affiliates. All rights reserved. 2019? ------------- PR: https://git.openjdk.org/jdk/pull/13059 From duke at openjdk.org Thu Mar 16 21:25:44 2023 From: duke at openjdk.org (Viktor Klang) Date: Thu, 16 Mar 2023 21:25:44 GMT Subject: RFR: JDK-8303742: CompletableFuture.orTimeout leaks if the future completes exceptionally [v3] In-Reply-To: References: Message-ID: > Addresses the situation where exceptional completion of `orTimeout`:ed CompletableFutures wouldn't cancel the timeout task which could lead to memory leaks if done frequently enough with long enough timeout durations. > > Fix discussed with @DougLea Viktor Klang has updated the pull request incrementally with one additional commit since the last revision: Making the test for orTimeout+completeExceptionally only based on iterations and not duration. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13059/files - new: https://git.openjdk.org/jdk/pull/13059/files/15e8fcc2..05619280 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13059&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13059&range=01-02 Stats: 5 lines in 1 file changed: 1 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/13059.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13059/head:pull/13059 PR: https://git.openjdk.org/jdk/pull/13059 From duke at openjdk.org Thu Mar 16 21:25:49 2023 From: duke at openjdk.org (Viktor Klang) Date: Thu, 16 Mar 2023 21:25:49 GMT Subject: RFR: JDK-8303742: CompletableFuture.orTimeout leaks if the future completes exceptionally [v3] In-Reply-To: References: Message-ID: On Thu, 16 Mar 2023 20:51:29 GMT, Pavel Rappo wrote: >> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision: >> >> Making the test for orTimeout+completeExceptionally only based on iterations and not duration. > > test/jdk/java/util/concurrent/CompletableFuture/CompletableFutureOrTimeoutExceptionallyTest.java line 44: > >> 42: void testOrTimeoutWithCompleteExceptionallyDoesNotLeak() throws Exception { >> 43: var startTime = System.currentTimeMillis(); >> 44: var testRunTime = Duration.ofSeconds(10).toMillis(); > > This "create completable futures in a loop for t seconds" seems a bit brittle. Would 10 or 20 seconds be enough for a typical test machine to fail with OOME? Could this be improved by requiring a minimum number of CF instances to be created? Maybe finishing when t seconds have elapsed _and_ n instances have been created. > > Separately, as with any timeouts, consider a monotonic clock. @pavelrappo After some extra thought I have skipped the duration-need and instead determined the threshold for OOME and added a loop counter that counts to 4x that to make sure if it fails it fails. ------------- PR: https://git.openjdk.org/jdk/pull/13059 From naoto at openjdk.org Thu Mar 16 21:30:04 2023 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 16 Mar 2023 21:30:04 GMT Subject: RFR: 8304367: jlink --include-locales=* attempts to parse non .class resource files with classfile reader [v2] In-Reply-To: <-CFwdEf9n350xgKQWZmfFp0MxqrWoobQ8mHyUXdWDPQ=.4a4e678b-40fb-4eb3-a5a7-52156d9df2a4@github.com> References: <-CFwdEf9n350xgKQWZmfFp0MxqrWoobQ8mHyUXdWDPQ=.4a4e678b-40fb-4eb3-a5a7-52156d9df2a4@github.com> Message-ID: > This is a blocker for [JDK-8294972](https://bugs.openjdk.org/browse/JDK-8294972). The fix is to weed out non-class files for calling `ClassReader` by checking the file extension. Regression tests are not provided as it is not possible to detect the fix from the artifact jimage, but manually confirmed it would effectively weed out `LineBreakIteratorData_th`, `WordBreakIteratorData_th`, and `thai_dict` files by running `IncludeLocalesPluginTest.java`. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: eliminate redundant call ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13067/files - new: https://git.openjdk.org/jdk/pull/13067/files/d7ad21cb..b837e4d8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13067&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13067&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13067.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13067/head:pull/13067 PR: https://git.openjdk.org/jdk/pull/13067 From almatvee at openjdk.org Thu Mar 16 21:57:31 2023 From: almatvee at openjdk.org (Alexander Matveev) Date: Thu, 16 Mar 2023 21:57:31 GMT Subject: RFR: JDK-8304063: tools/jpackage/share/AppLauncherEnvTest.java fails when checking LD_LIBRARY_PATH [v2] In-Reply-To: References: Message-ID: <2tuW_VNMrWCrvXokNMq-lEgIuRsAFpIMcB0ECmWsTKs=.1f81314f-8dd6-4470-a14b-98356f57146e@github.com> On Thu, 16 Mar 2023 09:08:08 GMT, Matthias Baesken wrote: >> The test fails on Alpine Linux 3.17, when checking the environment variable LD_LIBRARY_PATH; looks like the actual env variable is much longer than the test expects. It turned out that at least on Linux (probably also on other OS like AIX) the actual env variable has the expected string at it's end, but might contain more path entries ( LD_LIBRARY_PATH can be adjusted by jvm - https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/libjli/java_md.c ). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > redo check Marked as reviewed by almatvee (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/13041 From mchung at openjdk.org Thu Mar 16 22:01:16 2023 From: mchung at openjdk.org (Mandy Chung) Date: Thu, 16 Mar 2023 22:01:16 GMT Subject: RFR: 8294972: Convert jdk.jlink internal plugins to use the Classfile API [v10] In-Reply-To: References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> Message-ID: On Thu, 16 Mar 2023 10:47:01 GMT, Adam Sotona wrote: >> jdk.jlink internal plugins are heavily using ASM >> >> This patch converts ASM calls to Classfile API. >> >> Please review. >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > remaining cleanup in SystemModulesPlugin Looks good. I reviewed the changes in all plugins except IncludeLocalePlugin and will re-review it once you restore to the previous version. src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 79: > 77: import jdk.internal.classfile.ClassBuilder; > 78: import jdk.internal.classfile.Classfile; > 79: import jdk.internal.classfile.Opcode; this import is unused now. src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 577: > 575: * Generate SystemModules class > 576: */ > 577: public byte[] getClassWriter(Configuration cf) { This method no longer returns a class writer and should be renamed. What about `genClassBytes`? ------------- PR: https://git.openjdk.org/jdk/pull/12944 From mchung at openjdk.org Thu Mar 16 22:05:48 2023 From: mchung at openjdk.org (Mandy Chung) Date: Thu, 16 Mar 2023 22:05:48 GMT Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator to use the Classfile API to generate proxy classes [v6] In-Reply-To: <_BTRFrVE38PLXm9f7EPoh4y7Ikrb2nHF50Y82tfCEro=.43cd3219-0d45-42a4-aebb-c39f9536e088@github.com> References: <2vZ8IArF00YxvsqkZxg1fZJCv-pvUQRYrepvvVhw1w0=.dcd260a4-f3d6-4797-8e11-e9eb266d460c@github.com> <_BTRFrVE38PLXm9f7EPoh4y7Ikrb2nHF50Y82tfCEro=.43cd3219-0d45-42a4-aebb-c39f9536e088@github.com> Message-ID: On Thu, 16 Mar 2023 15:20:27 GMT, Chen Liang wrote: >> Possible extensions of `ClassHierarchyResolver` factories, or maybe even extensions of the default resolver are on the table and I just planned to open this discussion. >> >> Here is specific case where original code passes `ClassLoader` down to to the ASM engine for class hierarchy resolution based on class loading. >> >> Classfile API has more flexibility in that area and can resolve class hierarchy based on provided minimal information. Default class hierarchy resolution is fast-scanning of classfiles provided by ClassLoader as resources. It is not necessary to resolve all dependencies nor load the classes. However this is one of the cases where I'm not sure the default does it right. The above code turns default class hierarchy resolution back to the original class-loading approach. >> >> In `InnerClassLambdaMetafactory` I didn't observed any `ClassLoader` beeing passed down to ASM, so it rely on the defaults. >> >> The right solution may be to extend the default class hierarchy resolution to fall back to class-loading when the resource form of the class is not available. A factory method can just replicate the same behavior with provided different `ClassLoader`. >> >> I'm open to any comments and suggestions. > > I was thinking of implementing a class resolution via Reflection API with the `MethodHandles.Lookup` passed into `LambdaMetafactory` for correctness. Could it be that Lambda bytecode is too simple (as it's just calling a method handle in an instance method and a constructor, in a class extending Object and implementing a few interfaces) so the class hierarchy resolution wasn't critical? > In InnerClassLambdaMetafactory I didn't observed any ClassLoader beeing passed down to ASM, so it rely on the defaults. This is right. A lambda proxy is defined with the same class loader of the caller's class. For dynamic proxies, it is generated using the class loader specified via `newProxyInstance(ClassLoader loader, Class[] interfaces, InvocationHandler h)` which should be used for class resolution. ------------- PR: https://git.openjdk.org/jdk/pull/10991 From darcy at openjdk.org Thu Mar 16 22:15:31 2023 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 16 Mar 2023 22:15:31 GMT Subject: RFR: 8294137: Review running times of java.math tests [v2] In-Reply-To: References: <-dxso8siPUKzTOOKkoA5_2EAn7ACb_XJSYdQ_Af-4_I=.2e9f8478-f224-491e-a299-c59f9f373ff2@github.com> Message-ID: On Thu, 2 Mar 2023 22:35:52 GMT, Brian Burkhalter wrote: >> Break up `BigIntegerTest` and `SymmetricRangeTests` into subsets which are run quasi-randomly as a function of second within the minute at the time the test is running. `LargeValueExceptions` does not appear amenable to this treatment. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8303269: Use Random instead of Calendar to select test subset Hmm. What do you think about an idiom where it would be easy (through a small source change at least) to run all the subtests? So the default selection could look for, say, a bit in position N being set rather than the selector being N. ------------- PR: https://git.openjdk.org/jdk/pull/12819 From lancea at openjdk.org Thu Mar 16 22:16:21 2023 From: lancea at openjdk.org (Lance Andersen) Date: Thu, 16 Mar 2023 22:16:21 GMT Subject: RFR: 8304367: jlink --include-locales=* attempts to parse non .class resource files with classfile reader [v2] In-Reply-To: References: <-CFwdEf9n350xgKQWZmfFp0MxqrWoobQ8mHyUXdWDPQ=.4a4e678b-40fb-4eb3-a5a7-52156d9df2a4@github.com> Message-ID: On Thu, 16 Mar 2023 21:30:04 GMT, Naoto Sato wrote: >> This is a blocker for [JDK-8294972](https://bugs.openjdk.org/browse/JDK-8294972). The fix is to weed out non-class files for calling `ClassReader` by checking the file extension. Regression tests are not provided as it is not possible to detect the fix from the artifact jimage, but manually confirmed it would effectively weed out `LineBreakIteratorData_th`, `WordBreakIteratorData_th`, and `thai_dict` files by running `IncludeLocalesPluginTest.java`. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > eliminate redundant call Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/13067 From jvernee at openjdk.org Thu Mar 16 23:08:20 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 16 Mar 2023 23:08:20 GMT Subject: RFR: 8304320: java.base does not export jdk.internal.org.objectweb.asm to module jdk.jshell In-Reply-To: References: Message-ID: On Thu, 16 Mar 2023 08:14:25 GMT, Varada M wrote: > jdk/test/jdk/tools/jimage/VerifyJimage.java is failing because the module java.base is not exporting jdk.internal.org.objectweb.asm to module jdk.jshell. > > Reported Issue : [JDK-8304320](https://bugs.openjdk.org/browse/JDK-8304320) I agree with Alan that it seems like there is more going on here. jshell should not need a dependency on ASM anymore. I am not able to reproduce this failure locally with the latest `master`, and when I look in `build\jdk\modules\jdk.jshell\jdk\jshell\execution` I don't see a `jdk.jshell.execution.LocalExecutionControl$1$1` class file. (However, it is there in old jdk builds I have lying around. Likely when the class still contained reference to ASM). Do you have such a file in that location? I think perhaps the file is left over from a previous build, and is getting included in the jimage file by accident. Have you tried a clean build as well? ------------- PR: https://git.openjdk.org/jdk/pull/13057 From almatvee at openjdk.org Thu Mar 16 23:32:05 2023 From: almatvee at openjdk.org (Alexander Matveev) Date: Thu, 16 Mar 2023 23:32:05 GMT Subject: RFR: 8298995: tools/jpackage/share/AddLauncherTest.java#id1 failed "AddLauncherTest.test; checks=53" Message-ID: This is similar to many other issues we had with `hdiutil` failures. Fixed in similar way by repeating `hdiutil` command. Cannot confirm that it will resolve this issue, but similar issues got resolved by repeating command. Also, switched writing output from `hdiutil` to file. It is known issue that execution of `hdiutil` can hang if output is not written to file. ------------- Commit messages: - 8298995: tools/jpackage/share/AddLauncherTest.java#id1 failed "AddLauncherTest.test; checks=53" Changes: https://git.openjdk.org/jdk/pull/13002/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13002&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298995 Stats: 49 lines in 2 files changed: 31 ins; 0 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/13002.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13002/head:pull/13002 PR: https://git.openjdk.org/jdk/pull/13002 From lmesnik at openjdk.org Fri Mar 17 00:02:12 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 17 Mar 2023 00:02:12 GMT Subject: RFR: 8303697: ProcessTools doesn't print last line of process output [v4] In-Reply-To: <2yj8kBz0HKn3QwV6awfX7bwl1IgBqBiRza-ABtJwCzo=.22255150-b358-4def-88a5-ed2ebc0de129@github.com> References: <2yj8kBz0HKn3QwV6awfX7bwl1IgBqBiRza-ABtJwCzo=.22255150-b358-4def-88a5-ed2ebc0de129@github.com> Message-ID: > The StreamPumper is fixed to process the last line even it is not finishes with '\n' or '\r'. The test included. Testing with tier1-3 also to verify that tests are not broken. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: fixed test and comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13034/files - new: https://git.openjdk.org/jdk/pull/13034/files/aa12782b..47df1034 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13034&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13034&range=02-03 Stats: 17 lines in 2 files changed: 11 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/13034.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13034/head:pull/13034 PR: https://git.openjdk.org/jdk/pull/13034 From lmesnik at openjdk.org Fri Mar 17 00:02:38 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 17 Mar 2023 00:02:38 GMT Subject: RFR: 8303697: ProcessTools doesn't print last line of process output [v3] In-Reply-To: References: <2yj8kBz0HKn3QwV6awfX7bwl1IgBqBiRza-ABtJwCzo=.22255150-b358-4def-88a5-ed2ebc0de129@github.com> <442V2D4DoDQ4AOZyi4o-l-SEVx85z-KYeFGwDw5hJjM=.5b686eee-802a-4a6c-bce3-a128061fbaf5@github.com> Message-ID: <5TOdkPxx5AoxojXZvlzIBNo_oW91WpmZ_ksO7zu9j2U=.a033cc77-6e4d-450a-bba8-3dfd018a9956@github.com> On Thu, 16 Mar 2023 06:19:14 GMT, Thomas Stuefe wrote: >> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: >> >> comments added > > That also affects OutputAnalyzer, right? Does this affect parsing or is this only printing? > > Anyway, patch looks good to me, modulo of what David wrote. If you fix his remarks, its good to me. @tstuefe Thank you for review. This issue is not related to OutputAnalyzer, I think. However it affects any line processing in ProcessTools.startProcess() and not only printing. ------------- PR: https://git.openjdk.org/jdk/pull/13034 From jvernee at openjdk.org Fri Mar 17 00:10:31 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 17 Mar 2023 00:10:31 GMT Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function & Memory API (Preview) [v21] In-Reply-To: References: Message-ID: <4-GOVkzGTUqypflffoXoeF9zAlBleE_1zxV3LfcVHow=.afc0426b-2b97-4b02-9ecc-e2d11a1f8a7e@github.com> On Thu, 16 Mar 2023 14:42:10 GMT, Martin Doerr wrote: >> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification". >> >> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `` (2.2.4 Variable Argument Lists). >> >> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only. >> >> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Will get addressed separately: [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017) >> >> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests. >> >> I had to make changes to shared code and code for other platforms: >> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons: >> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that. >> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64. >> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian! >> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit. > > Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: > > Move ABIv2CallArranger out of linux subdirectory. ABIv1/2 does match the AIX/linux separation. Marked as reviewed by jvernee (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12708 From liach at openjdk.org Fri Mar 17 00:25:50 2023 From: liach at openjdk.org (Chen Liang) Date: Fri, 17 Mar 2023 00:25:50 GMT Subject: RFR: 8304139: Add , , and main method constants to ClassDescs [v2] In-Reply-To: References: Message-ID: > Add String constants INIT_NAME, CLASS_INIT_NAME, MTD_void for the names and method type of instance and class initializers; add String constant MAIN_NAME and MTD_void_StringArray for the name and method type of main method. > > Update occurrences of and in core libraries API specification to refer to these constants. The occurrences in code elsewhere will be converted separately for there are too many. > > See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000233.html Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Apply suggestions from code review Co-authored-by: Mandy Chung ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13020/files - new: https://git.openjdk.org/jdk/pull/13020/files/51bb77c6..8dc51b8e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13020&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13020&range=00-01 Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/13020.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13020/head:pull/13020 PR: https://git.openjdk.org/jdk/pull/13020 From liach at openjdk.org Fri Mar 17 00:43:04 2023 From: liach at openjdk.org (Chen Liang) Date: Fri, 17 Mar 2023 00:43:04 GMT Subject: RFR: 8304139: Add , , and main method constants to ClassDescs [v3] In-Reply-To: References: Message-ID: > Add String constants INIT_NAME, CLASS_INIT_NAME, MTD_void for the names and method type of instance and class initializers; add String constant MAIN_NAME and MTD_void_StringArray for the name and method type of main method. > > Update occurrences of and in core libraries API specification to refer to these constants. The occurrences in code elsewhere will be converted separately for there are too many. > > See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000233.html Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Remove main related constants, update specification for initialization constants ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13020/files - new: https://git.openjdk.org/jdk/pull/13020/files/8dc51b8e..9838e462 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13020&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13020&range=01-02 Stats: 37 lines in 1 file changed: 0 ins; 30 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/13020.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13020/head:pull/13020 PR: https://git.openjdk.org/jdk/pull/13020 From liach at openjdk.org Fri Mar 17 00:49:32 2023 From: liach at openjdk.org (Chen Liang) Date: Fri, 17 Mar 2023 00:49:32 GMT Subject: RFR: 8304139: Add and method constants to ConstantDescs [v3] In-Reply-To: References: Message-ID: On Thu, 16 Mar 2023 20:43:30 GMT, Mandy Chung wrote: >> Chen Liang has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove main related constants, update specification for initialization constants > > src/java.base/share/classes/java/lang/constant/ConstantDescs.java line 315: > >> 313: * @since 21 >> 314: */ >> 315: public static final MethodTypeDesc MTD_void = MethodTypeDesc.of(CD_void); > > This is a generic method type descriptor and not restrict to initialization methods. So I think no need to mention that "This is the method type of initialization methods ..." and `@jvms, @see and @jls" references. > > Maybe it can be as simple as: > > > > Nominal descriptor representing the method descriptor {@code ()V}, > taking no argument and returning {@code void}. Done. Also updated issue description after removing main method constants. ------------- PR: https://git.openjdk.org/jdk/pull/13020 From sspitsyn at openjdk.org Fri Mar 17 01:36:47 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 17 Mar 2023 01:36:47 GMT Subject: RFR: 8304303: implement VirtualThread class notifyJvmti methods as C2 intrinsics [v3] In-Reply-To: <-Pt3zLSu1Y2GYeM8XEivglUyDVXlAqMIA42-_zEnHlo=.7dd40f19-160a-4f11-8702-99c69a9b9923@github.com> References: <-Pt3zLSu1Y2GYeM8XEivglUyDVXlAqMIA42-_zEnHlo=.7dd40f19-160a-4f11-8702-99c69a9b9923@github.com> Message-ID: > This is needed for performance improvements in support of virtual threads. > The update includes the following: > > 1. Refactored the `VirtualThread` native methods: > `notifyJvmtiMountBegin` and `notifyJvmtiMountEnd` => `notifyJvmtiMount` > `notifyJvmtiUnmountBegin` and `notifyJvmtiUnmountEnd` => `notifyJvmtiUnmount` > 2. Still useful implementation of old native methods is moved from `jvm.cpp` to `jvmtiThreadState.cpp`: > `JVM_VirtualThreadMountStart` => `VTMS_mount_begin` > `JVM_VirtualThreadMountEnd` => `VTMS_mount_end` > `JVM_VirtualThreadUnmountStart` = > `VTMS_unmount_begin` > `JVM_VirtualThreadUnmountEnd` => `VTMS_mount_end` > 3. Intrinsified the `VirtualThread` native methods: `notifyJvmtiMount`, `notifyJvmtiUnmount`, `notifyJvmtiHideFrames`. > 4. Removed the`VirtualThread` static boolean state variable `notifyJvmtiEvents` and its support in `javaClasses`. > 5. Added static boolean state variable `_VTMS_notify_jvmti_events` to the jvmtiVTMSTransitionDisabler class as a replacement of the `VirtualThread` `notifyJvmtiEvents` variable. > > Implementing the same methods as C1 intrinsics can be needed in the future but is a low priority for now. > > Testing: > - Ran mach5 tiers 1-6. No regressions were found. Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: address pre-review comments from Leonid ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13054/files - new: https://git.openjdk.org/jdk/pull/13054/files/397b6337..f3692263 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13054&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13054&range=01-02 Stats: 22 lines in 2 files changed: 14 ins; 4 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/13054.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13054/head:pull/13054 PR: https://git.openjdk.org/jdk/pull/13054 From dholmes at openjdk.org Fri Mar 17 04:48:23 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 17 Mar 2023 04:48:23 GMT Subject: RFR: 8303697: ProcessTools doesn't print last line of process output [v4] In-Reply-To: References: <2yj8kBz0HKn3QwV6awfX7bwl1IgBqBiRza-ABtJwCzo=.22255150-b358-4def-88a5-ed2ebc0de129@github.com> Message-ID: On Fri, 17 Mar 2023 00:02:12 GMT, Leonid Mesnik wrote: >> The StreamPumper is fixed to process the last line even it is not finishes with '\n' or '\r'. The test included. Testing with tier1-3 also to verify that tests are not broken. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > fixed test and comments One minor correction in the test otherwise looks good. Thanks. test/lib-test/jdk/test/lib/process/ProcessToolsLastLineTest.java line 57: > 55: test("\nARG1"); > 56: test("\nARG1\n"); > 57: test("ARG1/n"); Sorry there was a typo in my suggestion - should be "ARG1\n" ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/13034 From lmesnik at openjdk.org Fri Mar 17 05:47:08 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 17 Mar 2023 05:47:08 GMT Subject: RFR: 8303697: ProcessTools doesn't print last line of process output [v5] In-Reply-To: <2yj8kBz0HKn3QwV6awfX7bwl1IgBqBiRza-ABtJwCzo=.22255150-b358-4def-88a5-ed2ebc0de129@github.com> References: <2yj8kBz0HKn3QwV6awfX7bwl1IgBqBiRza-ABtJwCzo=.22255150-b358-4def-88a5-ed2ebc0de129@github.com> Message-ID: > The StreamPumper is fixed to process the last line even it is not finishes with '\n' or '\r'. The test included. Testing with tier1-3 also to verify that tests are not broken. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: typo fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13034/files - new: https://git.openjdk.org/jdk/pull/13034/files/47df1034..a1d7be0b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13034&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13034&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13034.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13034/head:pull/13034 PR: https://git.openjdk.org/jdk/pull/13034 From jpai at openjdk.org Fri Mar 17 05:52:19 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 17 Mar 2023 05:52:19 GMT Subject: RFR: 8304164: jdk/classfile/CorpusTest.java still fails after JDK-8303910 In-Reply-To: <4dGeKShy_LOubsC25eMQQfnOcF58QbIkQwdU7dRmB7s=.685dd7c4-0ee5-4970-9c2a-eb7b656a5b3f@github.com> References: <4dGeKShy_LOubsC25eMQQfnOcF58QbIkQwdU7dRmB7s=.685dd7c4-0ee5-4970-9c2a-eb7b656a5b3f@github.com> Message-ID: On Wed, 15 Mar 2023 08:44:34 GMT, Adam Sotona wrote: > Massive parallel execution of parametrised CorpusTest junit tests revealed race condition in `ClassHierarchyImpl.CachedClassHierarchyResolver::getClassInfo`. > > The race condition may skip calculation of the ClassHierarchyInfo. In this specific case it caused SegmentScope not being identified as an interface and verify error on assignability between declared method return type and actual returned type has been emitted by the test. > > Proposed patch fixes the race condition in `ClassHierarchyImpl.CachedClassHierarchyResolver::getClassInfo`. > > Please review. > > Thank you, > Adam Marked as reviewed by jpai (Reviewer). src/java.base/share/classes/jdk/internal/classfile/impl/ClassHierarchyImpl.java line 133: > 131: //using NOPE to distinguish between null value and non-existent record in the cache > 132: //this code is on JDK bootstrap critical path, so cannot use lambdas here > 133: var res = resolvedCache.getOrDefault(classDesc, NOPE); `resolvedCache` is a `Collections.synchronizedMap` backed by a `HashMap`. So the `getOrDefault()` (internally) synchronizes on the `resolvedCache` instance itself and thus this operation would be thread safe in context of access to this cache in rest of this code. So what you propose here looks good to me. ------------- PR: https://git.openjdk.org/jdk/pull/13037 From jpai at openjdk.org Fri Mar 17 06:05:24 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 17 Mar 2023 06:05:24 GMT Subject: RFR: 8304367: jlink --include-locales=* attempts to parse non .class resource files with classfile reader [v2] In-Reply-To: References: <-CFwdEf9n350xgKQWZmfFp0MxqrWoobQ8mHyUXdWDPQ=.4a4e678b-40fb-4eb3-a5a7-52156d9df2a4@github.com> Message-ID: <8vOKnTeNDQloyutOoHK7OMrHYeNy425ZSw9k-_GVsqc=.3b5adf0c-8842-4061-a815-305653119ebd@github.com> On Thu, 16 Mar 2023 21:30:04 GMT, Naoto Sato wrote: >> This is a blocker for [JDK-8294972](https://bugs.openjdk.org/browse/JDK-8294972). The fix is to weed out non-class files for calling `ClassReader` by checking the file extension. Regression tests are not provided as it is not possible to detect the fix from the artifact jimage, but manually confirmed it would effectively weed out `LineBreakIteratorData_th`, `WordBreakIteratorData_th`, and `thai_dict` files by running `IncludeLocalesPluginTest.java`. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > eliminate redundant call Marked as reviewed by jpai (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/13067 From liangchenblue at gmail.com Fri Mar 17 06:24:38 2023 From: liangchenblue at gmail.com (-) Date: Fri, 17 Mar 2023 01:24:38 -0500 Subject: Reverse operation of ClassDesc::of Message-ID: While using ClassDesc, I find that it is somewhat hard to convert it to a binary or internal name as calling substring makes the code much more complex, especially when we know that the given ClassDesc is a class or interface. Thus, I propose an API serving as the inverse of ClassDesc::of(String), which takes a binary name from Class::getName and returns a ClassDesc of a class or interface. The new API would be parallel to existing Class::getName, and I am tempted to call it ClassDesc::getName. In addition, it may be of interest to expand the legal inputs of ClassDesc::of(String) to accept whatever Class::forName(String) does, notably array classes with names like [Ljava.lang.Object; or [I. Chen Liang From jpai at openjdk.org Fri Mar 17 06:37:21 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 17 Mar 2023 06:37:21 GMT Subject: RFR: JDK-8303742: CompletableFuture.orTimeout leaks if the future completes exceptionally [v3] In-Reply-To: References: Message-ID: On Thu, 16 Mar 2023 21:25:44 GMT, Viktor Klang wrote: >> Addresses the situation where exceptional completion of `orTimeout`:ed CompletableFutures wouldn't cancel the timeout task which could lead to memory leaks if done frequently enough with long enough timeout durations. >> >> Fix discussed with @DougLea > > Viktor Klang has updated the pull request incrementally with one additional commit since the last revision: > > Making the test for orTimeout+completeExceptionally only based on iterations and not duration. Hello Viktor, the changes look good to me. Looking at the code, I see that this issue will also affect the `completeOnTimeout(...)` method on the `CompletableFuture`. Would you want to enhance the test to include a test for this method too? The following test method which tests this `completeOnTimeout()` reproduces the leak (and thus the OOM) without your fix: @Test void testCompleteOnTimeoutWithCompleteExceptionallyDoesNotLeak() { var count = 0L; while(count < 2_000_000) { new CompletableFuture<>().completeOnTimeout(null, 12, TimeUnit.HOURS).completeExceptionally(new RuntimeException("This is fine")); ++count; } } ------------- PR: https://git.openjdk.org/jdk/pull/13059 From mbaesken at openjdk.org Fri Mar 17 07:59:54 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 17 Mar 2023 07:59:54 GMT Subject: RFR: JDK-8304063: tools/jpackage/share/AppLauncherEnvTest.java fails when checking LD_LIBRARY_PATH [v2] In-Reply-To: References: Message-ID: <63rvPQ_-ixF8cqOHONMhwx1HnXAVSdQr9ovUAdV5RlA=.c59ae71a-aa61-46a1-a3cd-a951a4a1883d@github.com> On Thu, 16 Mar 2023 09:08:08 GMT, Matthias Baesken wrote: >> The test fails on Alpine Linux 3.17, when checking the environment variable LD_LIBRARY_PATH; looks like the actual env variable is much longer than the test expects. It turned out that at least on Linux (probably also on other OS like AIX) the actual env variable has the expected string at it's end, but might contain more path entries ( LD_LIBRARY_PATH can be adjusted by jvm - https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/libjli/java_md.c ). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > redo check Thanks for the reviews ! ------------- PR: https://git.openjdk.org/jdk/pull/13041 From mbaesken at openjdk.org Fri Mar 17 07:59:56 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 17 Mar 2023 07:59:56 GMT Subject: Integrated: JDK-8304063: tools/jpackage/share/AppLauncherEnvTest.java fails when checking LD_LIBRARY_PATH In-Reply-To: References: Message-ID: On Wed, 15 Mar 2023 11:46:22 GMT, Matthias Baesken wrote: > The test fails on Alpine Linux 3.17, when checking the environment variable LD_LIBRARY_PATH; looks like the actual env variable is much longer than the test expects. It turned out that at least on Linux (probably also on other OS like AIX) the actual env variable has the expected string at it's end, but might contain more path entries ( LD_LIBRARY_PATH can be adjusted by jvm - https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/libjli/java_md.c ). This pull request has now been integrated. Changeset: ebac7eec Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/ebac7eec8e5923c66a80cbd66e79c354f30a07a3 Stats: 6 lines in 1 file changed: 3 ins; 0 del; 3 mod 8304063: tools/jpackage/share/AppLauncherEnvTest.java fails when checking LD_LIBRARY_PATH Reviewed-by: asemenyuk, almatvee ------------- PR: https://git.openjdk.org/jdk/pull/13041 From aturbanov at openjdk.org Fri Mar 17 08:13:12 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Fri, 17 Mar 2023 08:13:12 GMT Subject: RFR: 8294977: Convert test/jdk/java tests from ASM library to Classfile API [v5] In-Reply-To: References: Message-ID: On Thu, 16 Mar 2023 15:34:58 GMT, Chen Liang wrote: >> Summaries: >> 1. A few recommendations about updating the constant API is made at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000233.html and I may update this patch shall the API changes be integrated before >> 2. One ASM library-specific test, `LambdaAsm` is removed. Others have their code generation infrastructure upgraded from ASM to Classfile API. >> 3. Most tests are included in tier1, but some are not: >> In `:jdk_io`: (tier2, part 2) >> >> test/jdk/java/io/Serializable/records/SerialPersistentFieldsTest.java >> test/jdk/java/io/Serializable/records/ProhibitedMethods.java >> test/jdk/java/io/Serializable/records/BadCanonicalCtrTest.java >> >> In `:jdk_instrument`: (tier 3) >> >> test/jdk/java/lang/instrument/RetransformAgent.java >> test/jdk/java/lang/instrument/NativeMethodPrefixAgent.java >> test/jdk/java/lang/instrument/asmlib/Instrumentor.java >> >> >> @asotona Would you mind reviewing? > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Fix LambdaStackTrace after running test/jdk/java/lang/invoke/8022701/MHIllegalAccess.java line 50: > 48: public class MHIllegalAccess { > 49: > 50: public static void main(String[] args) throws Throwable { Suggestion: public static void main(String[] args) throws Throwable { ------------- PR: https://git.openjdk.org/jdk/pull/13009 From duke at openjdk.org Fri Mar 17 08:59:37 2023 From: duke at openjdk.org (Viktor Klang) Date: Fri, 17 Mar 2023 08:59:37 GMT Subject: RFR: JDK-8303742: CompletableFuture.orTimeout leaks if the future completes exceptionally [v4] In-Reply-To: References: Message-ID: > Addresses the situation where exceptional completion of `orTimeout`:ed CompletableFutures wouldn't cancel the timeout task which could lead to memory leaks if done frequently enough with long enough timeout durations. > > Fix discussed with @DougLea Viktor Klang has updated the pull request incrementally with one additional commit since the last revision: Adding a test for completeOnTimeout cancelling tasks when completeExceptionally ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13059/files - new: https://git.openjdk.org/jdk/pull/13059/files/05619280..e2c1c366 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13059&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13059&range=02-03 Stats: 13 lines in 1 file changed: 12 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13059.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13059/head:pull/13059 PR: https://git.openjdk.org/jdk/pull/13059 From duke at openjdk.org Fri Mar 17 08:59:41 2023 From: duke at openjdk.org (Viktor Klang) Date: Fri, 17 Mar 2023 08:59:41 GMT Subject: RFR: JDK-8303742: CompletableFuture.orTimeout leaks if the future completes exceptionally [v3] In-Reply-To: References: Message-ID: <1KqiDWkB1F6p4t8D1V_L7MyynSUkHgsgCozyGMn2j1U=.a933b32d-7d1e-4616-8812-9f22014b9706@github.com> On Fri, 17 Mar 2023 06:34:03 GMT, Jaikiran Pai wrote: >> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision: >> >> Making the test for orTimeout+completeExceptionally only based on iterations and not duration. > > Hello Viktor, the changes look good to me. Looking at the code, I see that this issue will also affect the `completeOnTimeout(...)` method on the `CompletableFuture`. Would you want to enhance the test to include a test for this method too? The following test method which tests this `completeOnTimeout()` reproduces the leak (and thus the OOM) without your fix: > > > @Test > void testCompleteOnTimeoutWithCompleteExceptionallyDoesNotLeak() { > var count = 0L; > while(count < 2_000_000) { > new CompletableFuture<>().completeOnTimeout(null, 12, TimeUnit.HOURS).completeExceptionally(new RuntimeException("This is fine")); > ++count; > > } > } @jaikiran Excellent catch, you're right?I've added such a test case as well to this PR. ? ------------- PR: https://git.openjdk.org/jdk/pull/13059 From duke at openjdk.org Fri Mar 17 08:59:43 2023 From: duke at openjdk.org (Viktor Klang) Date: Fri, 17 Mar 2023 08:59:43 GMT Subject: RFR: JDK-8303742: CompletableFuture.orTimeout leaks if the future completes exceptionally [v4] In-Reply-To: References: Message-ID: On Fri, 17 Mar 2023 08:55:39 GMT, Viktor Klang wrote: >> Addresses the situation where exceptional completion of `orTimeout`:ed CompletableFutures wouldn't cancel the timeout task which could lead to memory leaks if done frequently enough with long enough timeout durations. >> >> Fix discussed with @DougLea > > Viktor Klang has updated the pull request incrementally with one additional commit since the last revision: > > Adding a test for completeOnTimeout cancelling tasks when completeExceptionally test/jdk/java/util/concurrent/CompletableFuture/CompletableFutureOrTimeoutExceptionallyTest.java line 2: > 1: /* > 2: * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved. @jaikiran @pavelrappo Copyright year fixed as well ? ------------- PR: https://git.openjdk.org/jdk/pull/13059 From aturbanov at openjdk.org Fri Mar 17 09:01:59 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Fri, 17 Mar 2023 09:01:59 GMT Subject: RFR: JDK-8303742: CompletableFuture.orTimeout leaks if the future completes exceptionally [v4] In-Reply-To: References: Message-ID: On Fri, 17 Mar 2023 08:59:37 GMT, Viktor Klang wrote: >> Addresses the situation where exceptional completion of `orTimeout`:ed CompletableFutures wouldn't cancel the timeout task which could lead to memory leaks if done frequently enough with long enough timeout durations. >> >> Fix discussed with @DougLea > > Viktor Klang has updated the pull request incrementally with one additional commit since the last revision: > > Adding a test for completeOnTimeout cancelling tasks when completeExceptionally test/jdk/java/util/concurrent/CompletableFuture/CompletableFutureOrTimeoutExceptionallyTest.java line 44: > 42: void testOrTimeoutWithCompleteExceptionallyDoesNotLeak() { > 43: var count = 0L; > 44: while(count < 2_000_000) { Nit Suggestion: while (count < 2_000_000) { test/jdk/java/util/concurrent/CompletableFuture/CompletableFutureOrTimeoutExceptionallyTest.java line 56: > 54: void testCompleteOnTimeoutWithCompleteExceptionallyDoesNotLeak() { > 55: var count = 0L; > 56: while(count < 2_000_000) { Nit Suggestion: while (count < 2_000_000) { ------------- PR: https://git.openjdk.org/jdk/pull/13059 From jpai at openjdk.org Fri Mar 17 09:05:10 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 17 Mar 2023 09:05:10 GMT Subject: RFR: JDK-8303742: CompletableFuture.orTimeout leaks if the future completes exceptionally [v4] In-Reply-To: References: Message-ID: On Fri, 17 Mar 2023 08:59:37 GMT, Viktor Klang wrote: >> Addresses the situation where exceptional completion of `orTimeout`:ed CompletableFutures wouldn't cancel the timeout task which could lead to memory leaks if done frequently enough with long enough timeout durations. >> >> Fix discussed with @DougLea > > Viktor Klang has updated the pull request incrementally with one additional commit since the last revision: > > Adding a test for completeOnTimeout cancelling tasks when completeExceptionally Thank you Viktor for the updates. This looks good to me. ------------- Marked as reviewed by jpai (Reviewer). PR: https://git.openjdk.org/jdk/pull/13059 From duke at openjdk.org Fri Mar 17 09:18:07 2023 From: duke at openjdk.org (Viktor Klang) Date: Fri, 17 Mar 2023 09:18:07 GMT Subject: RFR: JDK-8303742: CompletableFuture.orTimeout leaks if the future completes exceptionally [v5] In-Reply-To: References: Message-ID: <2Eh3cVRTJ67Ea0iGLjtAH3Yw06fRMgAK6gbaQVmR_2o=.12d5f51c-8664-4572-b773-e50023676824@github.com> > Addresses the situation where exceptional completion of `orTimeout`:ed CompletableFutures wouldn't cancel the timeout task which could lead to memory leaks if done frequently enough with long enough timeout durations. > > Fix discussed with @DougLea Viktor Klang has updated the pull request incrementally with one additional commit since the last revision: while-statement formatting update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13059/files - new: https://git.openjdk.org/jdk/pull/13059/files/e2c1c366..71b67aea Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13059&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13059&range=03-04 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13059.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13059/head:pull/13059 PR: https://git.openjdk.org/jdk/pull/13059 From alanb at openjdk.org Fri Mar 17 09:24:55 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 17 Mar 2023 09:24:55 GMT Subject: RFR: JDK-8303742: CompletableFuture.orTimeout leaks if the future completes exceptionally [v5] In-Reply-To: <2Eh3cVRTJ67Ea0iGLjtAH3Yw06fRMgAK6gbaQVmR_2o=.12d5f51c-8664-4572-b773-e50023676824@github.com> References: <2Eh3cVRTJ67Ea0iGLjtAH3Yw06fRMgAK6gbaQVmR_2o=.12d5f51c-8664-4572-b773-e50023676824@github.com> Message-ID: <99BFbKpyGDm5-nIqS19DuMjCVFeVsRcgv8khQ0X0JhQ=.f4aa1d01-bdd1-490d-aa6d-4ed37c288b88@github.com> On Fri, 17 Mar 2023 09:18:07 GMT, Viktor Klang wrote: >> Addresses the situation where exceptional completion of `orTimeout`:ed CompletableFutures wouldn't cancel the timeout task which could lead to memory leaks if done frequently enough with long enough timeout durations. >> >> Fix discussed with @DougLea > > Viktor Klang has updated the pull request incrementally with one additional commit since the last revision: > > while-statement formatting update test/jdk/java/util/concurrent/CompletableFuture/CompletableFutureOrTimeoutExceptionallyTest.java line 58: > 56: while (count < 2_000_000) { > 57: new CompletableFuture<>().completeOnTimeout(null, 12, TimeUnit.HOURS).completeExceptionally(new RuntimeException("This is fine")); > 58: ++count; Doing 2m iterations vs. original test to run for 10s is fine, assuming there is a OOME with a 128Mb heap. If I were editing this test then I'd probably split the overly long lines to make future side-by-side diffs easier to look at. ------------- PR: https://git.openjdk.org/jdk/pull/13059 From duke at openjdk.org Fri Mar 17 09:52:55 2023 From: duke at openjdk.org (Viktor Klang) Date: Fri, 17 Mar 2023 09:52:55 GMT Subject: RFR: JDK-8303742: CompletableFuture.orTimeout leaks if the future completes exceptionally [v5] In-Reply-To: <99BFbKpyGDm5-nIqS19DuMjCVFeVsRcgv8khQ0X0JhQ=.f4aa1d01-bdd1-490d-aa6d-4ed37c288b88@github.com> References: <2Eh3cVRTJ67Ea0iGLjtAH3Yw06fRMgAK6gbaQVmR_2o=.12d5f51c-8664-4572-b773-e50023676824@github.com> <99BFbKpyGDm5-nIqS19DuMjCVFeVsRcgv8khQ0X0JhQ=.f4aa1d01-bdd1-490d-aa6d-4ed37c288b88@github.com> Message-ID: On Fri, 17 Mar 2023 09:21:48 GMT, Alan Bateman wrote: >> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision: >> >> while-statement formatting update > > test/jdk/java/util/concurrent/CompletableFuture/CompletableFutureOrTimeoutExceptionallyTest.java line 58: > >> 56: while (count < 2_000_000) { >> 57: new CompletableFuture<>().completeOnTimeout(null, 12, TimeUnit.HOURS).completeExceptionally(new RuntimeException("This is fine")); >> 58: ++count; > > Doing 2m iterations vs. original test to run for 10s is fine, assuming there is a OOME with a 128Mb heap. If I were editing this test then I'd probably split the overly long lines to make future side-by-side diffs easier to look at. @AlanBateman Indeed?I was able to get the problem reproduced at way lower (several factors) number of allocations for this test, so I purposely made the final number much higher to really make sure it'd trigger if it was broken. I'll reformat the while-body to be a bit easier on the eye for diffs. ? ------------- PR: https://git.openjdk.org/jdk/pull/13059 From duke at openjdk.org Fri Mar 17 09:52:51 2023 From: duke at openjdk.org (Viktor Klang) Date: Fri, 17 Mar 2023 09:52:51 GMT Subject: RFR: JDK-8303742: CompletableFuture.orTimeout leaks if the future completes exceptionally [v6] In-Reply-To: References: Message-ID: > Addresses the situation where exceptional completion of `orTimeout`:ed CompletableFutures wouldn't cancel the timeout task which could lead to memory leaks if done frequently enough with long enough timeout durations. > > Fix discussed with @DougLea Viktor Klang has updated the pull request incrementally with one additional commit since the last revision: Reformatting the while-body to be more legible in diffs, and inlining the counter incrementation. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13059/files - new: https://git.openjdk.org/jdk/pull/13059/files/71b67aea..80680bee Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13059&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13059&range=04-05 Stats: 8 lines in 1 file changed: 2 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/13059.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13059/head:pull/13059 PR: https://git.openjdk.org/jdk/pull/13059 From sspitsyn at openjdk.org Fri Mar 17 10:31:46 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 17 Mar 2023 10:31:46 GMT Subject: RFR: 8304303: implement VirtualThread class notifyJvmti methods as C2 intrinsics [v4] In-Reply-To: <-Pt3zLSu1Y2GYeM8XEivglUyDVXlAqMIA42-_zEnHlo=.7dd40f19-160a-4f11-8702-99c69a9b9923@github.com> References: <-Pt3zLSu1Y2GYeM8XEivglUyDVXlAqMIA42-_zEnHlo=.7dd40f19-160a-4f11-8702-99c69a9b9923@github.com> Message-ID: <-kZ3wf7zOt0zABMfgibzmuT5VHuROnTA92lkqbhitbE=.fd934229-b4a6-469a-9c4b-ac9f26efd80f@github.com> > This is needed for performance improvements in support of virtual threads. > The update includes the following: > > 1. Refactored the `VirtualThread` native methods: > `notifyJvmtiMountBegin` and `notifyJvmtiMountEnd` => `notifyJvmtiMount` > `notifyJvmtiUnmountBegin` and `notifyJvmtiUnmountEnd` => `notifyJvmtiUnmount` > 2. Still useful implementation of old native methods is moved from `jvm.cpp` to `jvmtiThreadState.cpp`: > `JVM_VirtualThreadMountStart` => `VTMS_mount_begin` > `JVM_VirtualThreadMountEnd` => `VTMS_mount_end` > `JVM_VirtualThreadUnmountStart` = > `VTMS_unmount_begin` > `JVM_VirtualThreadUnmountEnd` => `VTMS_mount_end` > 3. Intrinsified the `VirtualThread` native methods: `notifyJvmtiMount`, `notifyJvmtiUnmount`, `notifyJvmtiHideFrames`. > 4. Removed the`VirtualThread` static boolean state variable `notifyJvmtiEvents` and its support in `javaClasses`. > 5. Added static boolean state variable `_VTMS_notify_jvmti_events` to the jvmtiVTMSTransitionDisabler class as a replacement of the `VirtualThread` `notifyJvmtiEvents` variable. > > Implementing the same methods as C1 intrinsics can be needed in the future but is a low priority for now. > > Testing: > - Ran mach5 tiers 1-6. No regressions were found. Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: minor tweaks in intrisics implementation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13054/files - new: https://git.openjdk.org/jdk/pull/13054/files/f3692263..8233f0ab Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13054&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13054&range=02-03 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/13054.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13054/head:pull/13054 PR: https://git.openjdk.org/jdk/pull/13054 From jai.forums2013 at gmail.com Fri Mar 17 11:00:09 2023 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Fri, 17 Mar 2023 16:30:09 +0530 Subject: Current state = CODING_END, new state = FLUSHED? In-Reply-To: References: Message-ID: Hello Peter, Looking at the linked issue and the stacktrace presented there, this appears to be related to java.util.zip code.? I've moved this thread to core-libs-dev which is where discussions related to java.util.zip happen. The stacktrace is as follows: Caused by: java.lang.IllegalStateException: Current state = CODING_END, new state = FLUSHED ??? at java.nio.charset.CharsetDecoder.throwIllegalStateException (CharsetDecoder.java:998) ??? at java.nio.charset.CharsetDecoder.flush (CharsetDecoder.java:681) ??? at java.nio.charset.CharsetDecoder.decode (CharsetDecoder.java:810) ??? at java.util.zip.ZipCoder.normalizedHashDecode (ZipCoder.java:136) ??? at java.util.zip.ZipCoder$UTF8ZipCoder.normalizedHash (ZipCoder.java:228) ??? at java.util.zip.ZipFile$Source.initCEN (ZipFile.java:1527) ??? at java.util.zip.ZipFile$Source. (ZipFile.java:1249) ??? at java.util.zip.ZipFile$Source.get (ZipFile.java:1211) ??? at java.util.zip.ZipFile$CleanableResource. (ZipFile.java:701) ??? at java.util.zip.ZipFile. (ZipFile.java:240) ??? at java.util.zip.ZipFile. (ZipFile.java:171) ??? at java.util.jar.JarFile. (JarFile.java:347) ??? at jdk.internal.loader.URLClassPath$JarLoader.getJarFile (URLClassPath.java:816) Additional details in that issue state that the JDK being used is Java 15. There have been code changes in this piece of code in java.util.zip.ZipFile since then. In fact, in the current mainline (and recent releases) I don't see initCEN calling the ZipCoder. Would you be able to test this against more recent releases (preferably Java 19) and see if it is still reproducible? -Jaikiran On 17/03/23 4:09 pm, Peter Rader wrote: > I have been requested to ask if you feel responsible to fix this bug. > Caused by: java.lang.IllegalStateException: Current state = > CODING_END, new state = FLUSHED > ? ? at java.nio.charset.CharsetDecoder.throwIllegalStateException > (CharsetDecoder.java:998) > ? ? at java.nio.charset.CharsetDecoder.flush (CharsetDecoder.java:681) > ? ? at java.nio.charset.CharsetDecoder.decode (CharsetDecoder.java:810) > ? ? at java.util.zip.ZipCoder.normalizedHashDecode (ZipCoder.java:136) > ? ? at java.util.zip.ZipCoder$UTF8ZipCoder.normalizedHash > (ZipCoder.java:228) > Original ticket: https://issues.apache.org/jira/browse/MNG-7742 > Kind regards > > Peter Rader > -- > Fachinformatiker AE / IT Software Developer > Peter Rader > Wilsnacker Strasse 17 > 10559 Berlin - GERMANY > Tel: 0049 (0)30 / 6 29 33 29 6 > Fax: 0049 (0)30 / 6 29 33 29 6 > Handy: 0049 (0)176 / 87 521 576 > Handy: 0049 (0)176 / 47 876 303 -------------- next part -------------- An HTML attachment was scrubbed... URL: From eirbjo at gmail.com Fri Mar 17 11:27:36 2023 From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=) Date: Fri, 17 Mar 2023 12:27:36 +0100 Subject: Current state = CODING_END, new state = FLUSHED? In-Reply-To: References: Message-ID: On Fri, Mar 17, 2023 at 12:00?PM Jaikiran Pai wrote: > Additional details in that issue state that the JDK being used is Java 15. > There have been code changes in this piece of code in java.util.zip.ZipFile > since then. > Looks to me like an instance of JDK-8260010 [1], which was a thread-safety regression introduced (probably by me) in JDK-8243469 [2]. The fix was backported to 15, not sure which build it was included in. MNG-7742 indicates that Amazon Corretto is being used here. If a JVM upgrade doesn't help, then maybe Amazon never backported the fix..? Claes, do you have anything to add? [1] https://bugs.openjdk.org/browse/JDK-8260010 [2] https://bugs.openjdk.org/browse/JDK-8243469 Eirik. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eirbjo at gmail.com Fri Mar 17 11:42:49 2023 From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=) Date: Fri, 17 Mar 2023 12:42:49 +0100 Subject: Current state = CODING_END, new state = FLUSHED? In-Reply-To: References: Message-ID: > > The fix was backported to 15, not sure which build it was included in. > Sorry, seems the fix was backported to 16, not 15. The recommendation would still be the same: Upgrade to a more recent JDK release. 17 is the current LTS release. Eirik. -------------- next part -------------- An HTML attachment was scrubbed... URL: From asotona at openjdk.org Fri Mar 17 11:44:06 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 17 Mar 2023 11:44:06 GMT Subject: RFR: 8294972: Convert jdk.jlink internal plugins to use the Classfile API [v11] In-Reply-To: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> Message-ID: > jdk.jlink internal plugins are heavily using ASM > > This patch converts ASM calls to Classfile API. > > Please review. > Thanks, > Adam Adam Sotona has updated the pull request incrementally with three additional commits since the last revision: - SystemModulesPlugin::genClassBytes rename - SystemModulesPlugin::getClassBytes rename - Revert "implementation of custom ResourceHelper in IncludeLocalesPlugin" ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12944/files - new: https://git.openjdk.org/jdk/pull/12944/files/3dbe1e57..f01475a4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12944&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12944&range=09-10 Stats: 91 lines in 2 files changed: 20 ins; 49 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/12944.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12944/head:pull/12944 PR: https://git.openjdk.org/jdk/pull/12944 From asotona at openjdk.org Fri Mar 17 11:44:10 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 17 Mar 2023 11:44:10 GMT Subject: RFR: 8294972: Convert jdk.jlink internal plugins to use the Classfile API [v8] In-Reply-To: References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> Message-ID: On Thu, 16 Mar 2023 20:45:24 GMT, Naoto Sato wrote: >> I further clarified with Naoto and I now understand the problem. The plugin intends to transform `.class` that implements `LocaleDataMetaInfo` in `jdk.localedata` module. It's a bug in the plugin `--include-locales=*` which will read all resources from `jdk.localedata` with ASM ClassReader and the plugin just happens to work. The plugin should only read `.class` entries or specific `LocaleDataMetaInfo` implementation classes. I created https://bugs.openjdk.org/browse/JDK-8304367 that Naoto will help fixing. >> >> @asotona your previous version converting it to ClassFile API should work after JDK-8304367. > > Submitted: https://github.com/openjdk/jdk/pull/13067 I've reverted `IncludeLocalesPlugin` to previous version, plus minor fixes and together with #13067 the `IncludeLocalesPluginTest` is passing. Thank you. ------------- PR: https://git.openjdk.org/jdk/pull/12944 From asotona at openjdk.org Fri Mar 17 11:44:15 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 17 Mar 2023 11:44:15 GMT Subject: RFR: 8294972: Convert jdk.jlink internal plugins to use the Classfile API [v10] In-Reply-To: References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> Message-ID: On Thu, 16 Mar 2023 21:49:28 GMT, Mandy Chung wrote: >> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: >> >> remaining cleanup in SystemModulesPlugin > > src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 79: > >> 77: import jdk.internal.classfile.ClassBuilder; >> 78: import jdk.internal.classfile.Classfile; >> 79: import jdk.internal.classfile.Opcode; > > this import is unused now. fixed, thanks. > src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 577: > >> 575: * Generate SystemModules class >> 576: */ >> 577: public byte[] getClassWriter(Configuration cf) { > > This method no longer returns a class writer and should be renamed. What about `genClassBytes`? renamed to `genClassBytes` as proposed, thanks. ------------- PR: https://git.openjdk.org/jdk/pull/12944 From asotona at openjdk.org Fri Mar 17 11:50:22 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 17 Mar 2023 11:50:22 GMT Subject: RFR: 8304164: jdk/classfile/CorpusTest.java still fails after JDK-8303910 In-Reply-To: References: <4dGeKShy_LOubsC25eMQQfnOcF58QbIkQwdU7dRmB7s=.685dd7c4-0ee5-4970-9c2a-eb7b656a5b3f@github.com> Message-ID: On Fri, 17 Mar 2023 05:49:45 GMT, Jaikiran Pai wrote: >> Massive parallel execution of parametrised CorpusTest junit tests revealed race condition in `ClassHierarchyImpl.CachedClassHierarchyResolver::getClassInfo`. >> >> The race condition may skip calculation of the ClassHierarchyInfo. In this specific case it caused SegmentScope not being identified as an interface and verify error on assignability between declared method return type and actual returned type has been emitted by the test. >> >> Proposed patch fixes the race condition in `ClassHierarchyImpl.CachedClassHierarchyResolver::getClassInfo`. >> >> Please review. >> >> Thank you, >> Adam > > src/java.base/share/classes/jdk/internal/classfile/impl/ClassHierarchyImpl.java line 133: > >> 131: //using NOPE to distinguish between null value and non-existent record in the cache >> 132: //this code is on JDK bootstrap critical path, so cannot use lambdas here >> 133: var res = resolvedCache.getOrDefault(classDesc, NOPE); > > `resolvedCache` is a `Collections.synchronizedMap` backed by a `HashMap`. So the `getOrDefault()` (internally) synchronizes on the `resolvedCache` instance itself and thus this operation would be thread safe in context of access to this cache in rest of this code. So what you propose here looks good to me. Thank you. ------------- PR: https://git.openjdk.org/jdk/pull/13037 From asotona at openjdk.org Fri Mar 17 11:50:25 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 17 Mar 2023 11:50:25 GMT Subject: Integrated: 8304164: jdk/classfile/CorpusTest.java still fails after JDK-8303910 In-Reply-To: <4dGeKShy_LOubsC25eMQQfnOcF58QbIkQwdU7dRmB7s=.685dd7c4-0ee5-4970-9c2a-eb7b656a5b3f@github.com> References: <4dGeKShy_LOubsC25eMQQfnOcF58QbIkQwdU7dRmB7s=.685dd7c4-0ee5-4970-9c2a-eb7b656a5b3f@github.com> Message-ID: On Wed, 15 Mar 2023 08:44:34 GMT, Adam Sotona wrote: > Massive parallel execution of parametrised CorpusTest junit tests revealed race condition in `ClassHierarchyImpl.CachedClassHierarchyResolver::getClassInfo`. > > The race condition may skip calculation of the ClassHierarchyInfo. In this specific case it caused SegmentScope not being identified as an interface and verify error on assignability between declared method return type and actual returned type has been emitted by the test. > > Proposed patch fixes the race condition in `ClassHierarchyImpl.CachedClassHierarchyResolver::getClassInfo`. > > Please review. > > Thank you, > Adam This pull request has now been integrated. Changeset: b2639e1d Author: Adam Sotona URL: https://git.openjdk.org/jdk/commit/b2639e1d6246a7e1aab1d9d15add7979adf40766 Stats: 9 lines in 1 file changed: 6 ins; 0 del; 3 mod 8304164: jdk/classfile/CorpusTest.java still fails after JDK-8303910 Reviewed-by: jpai ------------- PR: https://git.openjdk.org/jdk/pull/13037 From lmesnik at openjdk.org Fri Mar 17 13:46:54 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 17 Mar 2023 13:46:54 GMT Subject: Integrated: 8304314: StackWalkTest.java fails after CODETOOLS-7903373 In-Reply-To: References: Message-ID: On Thu, 16 Mar 2023 13:26:35 GMT, Leonid Mesnik wrote: > The test depends on the jtreg stack and should be updated. > The fix is backported from loom repo where jtreg with CODETOOLS-7903373 is used. > Tested with current promoted jtreg (without CODETOOLS-7903373) by running test. This pull request has now been integrated. Changeset: d5a15070 Author: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/d5a150706e9070557533135489a73fc8cefc0cec Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8304314: StackWalkTest.java fails after CODETOOLS-7903373 Reviewed-by: alanb, mchung ------------- PR: https://git.openjdk.org/jdk/pull/13058 From lmesnik at openjdk.org Fri Mar 17 13:49:32 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 17 Mar 2023 13:49:32 GMT Subject: Integrated: 8303697: ProcessTools doesn't print last line of process output In-Reply-To: <2yj8kBz0HKn3QwV6awfX7bwl1IgBqBiRza-ABtJwCzo=.22255150-b358-4def-88a5-ed2ebc0de129@github.com> References: <2yj8kBz0HKn3QwV6awfX7bwl1IgBqBiRza-ABtJwCzo=.22255150-b358-4def-88a5-ed2ebc0de129@github.com> Message-ID: On Wed, 15 Mar 2023 05:41:33 GMT, Leonid Mesnik wrote: > The StreamPumper is fixed to process the last line even it is not finishes with '\n' or '\r'. The test included. Testing with tier1-3 also to verify that tests are not broken. This pull request has now been integrated. Changeset: 8d2ebf24 Author: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/8d2ebf248e2884fbf138b603ae82f81bd0926cf3 Stats: 87 lines in 2 files changed: 82 ins; 0 del; 5 mod 8303697: ProcessTools doesn't print last line of process output Reviewed-by: dholmes, stuefe ------------- PR: https://git.openjdk.org/jdk/pull/13034 From liach at openjdk.org Fri Mar 17 14:57:35 2023 From: liach at openjdk.org (Chen Liang) Date: Fri, 17 Mar 2023 14:57:35 GMT Subject: RFR: 8294977: Convert test/jdk/java tests from ASM library to Classfile API [v6] In-Reply-To: References: Message-ID: > Summaries: > 1. A few recommendations about updating the constant API is made at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000233.html and I may update this patch shall the API changes be integrated before > 2. One ASM library-specific test, `LambdaAsm` is removed. Others have their code generation infrastructure upgraded from ASM to Classfile API. > 3. Most tests are included in tier1, but some are not: > In `:jdk_io`: (tier2, part 2) > > test/jdk/java/io/Serializable/records/SerialPersistentFieldsTest.java > test/jdk/java/io/Serializable/records/ProhibitedMethods.java > test/jdk/java/io/Serializable/records/BadCanonicalCtrTest.java > > In `:jdk_instrument`: (tier 3) > > test/jdk/java/lang/instrument/RetransformAgent.java > test/jdk/java/lang/instrument/NativeMethodPrefixAgent.java > test/jdk/java/lang/instrument/asmlib/Instrumentor.java > > > @asotona Would you mind reviewing? Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Update test/jdk/java/lang/invoke/8022701/MHIllegalAccess.java Co-authored-by: Andrey Turbanov ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13009/files - new: https://git.openjdk.org/jdk/pull/13009/files/a728c9de..271cb98d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13009&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13009&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13009.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13009/head:pull/13009 PR: https://git.openjdk.org/jdk/pull/13009 From aturbanov at openjdk.org Fri Mar 17 14:57:44 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Fri, 17 Mar 2023 14:57:44 GMT Subject: RFR: 8303431: [JVMCI] libgraal annotation API [v6] In-Reply-To: <0hYs21V1ZWB8o92CfvkEW3i0dZKkeW8kYGQu0p6xvtM=.e76da2cd-dbe5-4da2-a6cb-775f081b9a6a@github.com> References: <0hYs21V1ZWB8o92CfvkEW3i0dZKkeW8kYGQu0p6xvtM=.e76da2cd-dbe5-4da2-a6cb-775f081b9a6a@github.com> Message-ID: On Tue, 14 Mar 2023 16:06:06 GMT, Doug Simon wrote: >> This PR extends JVMCI with new API (`jdk.vm.ci.meta.Annotated`) for accessing annotations. The main differences from `java.lang.reflect.AnnotatedElement` are: >> * All methods in the `Annotated` interface explicitly specify requested annotation type(s). That is, there is no equivalent of `AnnotatedElement.getAnnotations()`. >> * Annotation data is returned in a map-like object (of type `jdk.vm.ci.meta.AnnotationData`) instead of in an `Annotation` object. This works better for libgraal as it avoids the need for annotation types to be loaded and included in libgraal. >> >> To demonstrate the new API, here's an example in terms `java.lang.reflect.AnnotatedElement` (which `ResolvedJavaType` implements): >> >> ResolvedJavaMethod method = ...; >> ExplodeLoop a = method.getAnnotation(ExplodeLoop.class); >> return switch (a.kind()) { >> case FULL_UNROLL -> LoopExplosionKind.FULL_UNROLL; >> case FULL_UNROLL_UNTIL_RETURN -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN; >> ... >> } >> >> >> The same code using the new API: >> >> >> ResolvedJavaMethod method = ...; >> ResolvedJavaType explodeLoopType = ...; >> AnnotationData a = method.getAnnotationDataFor(explodeLoopType); >> return switch (a.getEnum("kind").getName()) { >> case "FULL_UNROLL" -> LoopExplosionKind.FULL_UNROLL; >> case "FULL_UNROLL_UNTIL_RETURN" -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN; >> ... >> } >> >> >> The implementation relies on new methods in `jdk.internal.vm.VMSupport` for parsing annotations and serializing/deserializing to/from a byte array. This allows the annotation data to be passed from the HotSpot heap to the libgraal heap. > > Doug Simon has updated the pull request incrementally with one additional commit since the last revision: > > addressed review feedback src/java.base/share/classes/jdk/internal/vm/VMSupport.java line 237: > 235: try { > 236: ByteArrayOutputStream baos = new ByteArrayOutputStream(128); > 237: try(DataOutputStream dos = new DataOutputStream(baos)) { nit Suggestion: try (DataOutputStream dos = new DataOutputStream(baos)) { src/java.base/share/classes/jdk/internal/vm/VMSupport.java line 564: > 562: } else if (length <= 127) { > 563: dos.writeByte((byte) (0x80 | length)); > 564: } else { nit Suggestion: } else { ------------- PR: https://git.openjdk.org/jdk/pull/12810 From bpb at openjdk.org Fri Mar 17 15:18:09 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 17 Mar 2023 15:18:09 GMT Subject: RFR: 8294137: Review running times of java.math tests [v2] In-Reply-To: References: <-dxso8siPUKzTOOKkoA5_2EAn7ACb_XJSYdQ_Af-4_I=.2e9f8478-f224-491e-a299-c59f9f373ff2@github.com> Message-ID: On Thu, 16 Mar 2023 22:12:43 GMT, Joe Darcy wrote: > [...] an idiom where it would be easy (through a small source change at least) to run all the subtests? Addressed in 8c666401ba68ed477e3d5f6088dae67fd73270a6. ------------- PR: https://git.openjdk.org/jdk/pull/12819 From bpb at openjdk.org Fri Mar 17 15:18:07 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 17 Mar 2023 15:18:07 GMT Subject: RFR: 8294137: Review running times of java.math tests [v3] In-Reply-To: <-dxso8siPUKzTOOKkoA5_2EAn7ACb_XJSYdQ_Af-4_I=.2e9f8478-f224-491e-a299-c59f9f373ff2@github.com> References: <-dxso8siPUKzTOOKkoA5_2EAn7ACb_XJSYdQ_Af-4_I=.2e9f8478-f224-491e-a299-c59f9f373ff2@github.com> Message-ID: > Break up `BigIntegerTest` and `SymmetricRangeTests` into subsets which are run quasi-randomly as a function of second within the minute at the time the test is running. `LargeValueExceptions` does not appear amenable to this treatment. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8303269: Add a means to run all subtests if desired ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12819/files - new: https://git.openjdk.org/jdk/pull/12819/files/ca998b8e..8c666401 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12819&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12819&range=01-02 Stats: 46 lines in 2 files changed: 18 ins; 15 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/12819.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12819/head:pull/12819 PR: https://git.openjdk.org/jdk/pull/12819 From dnsimon at openjdk.org Fri Mar 17 15:38:49 2023 From: dnsimon at openjdk.org (Doug Simon) Date: Fri, 17 Mar 2023 15:38:49 GMT Subject: RFR: 8303431: [JVMCI] libgraal annotation API [v7] In-Reply-To: References: Message-ID: > This PR extends JVMCI with new API (`jdk.vm.ci.meta.Annotated`) for accessing annotations. The main differences from `java.lang.reflect.AnnotatedElement` are: > * All methods in the `Annotated` interface explicitly specify requested annotation type(s). That is, there is no equivalent of `AnnotatedElement.getAnnotations()`. > * Annotation data is returned in a map-like object (of type `jdk.vm.ci.meta.AnnotationData`) instead of in an `Annotation` object. This works better for libgraal as it avoids the need for annotation types to be loaded and included in libgraal. > > To demonstrate the new API, here's an example in terms `java.lang.reflect.AnnotatedElement` (which `ResolvedJavaType` implements): > > ResolvedJavaMethod method = ...; > ExplodeLoop a = method.getAnnotation(ExplodeLoop.class); > return switch (a.kind()) { > case FULL_UNROLL -> LoopExplosionKind.FULL_UNROLL; > case FULL_UNROLL_UNTIL_RETURN -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN; > ... > } > > > The same code using the new API: > > > ResolvedJavaMethod method = ...; > ResolvedJavaType explodeLoopType = ...; > AnnotationData a = method.getAnnotationDataFor(explodeLoopType); > return switch (a.getEnum("kind").getName()) { > case "FULL_UNROLL" -> LoopExplosionKind.FULL_UNROLL; > case "FULL_UNROLL_UNTIL_RETURN" -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN; > ... > } > > > The implementation relies on new methods in `jdk.internal.vm.VMSupport` for parsing annotations and serializing/deserializing to/from a byte array. This allows the annotation data to be passed from the HotSpot heap to the libgraal heap. Doug Simon has updated the pull request incrementally with one additional commit since the last revision: [skip ci] formatting fixes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12810/files - new: https://git.openjdk.org/jdk/pull/12810/files/abaf2375..32131796 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12810&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12810&range=05-06 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/12810.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12810/head:pull/12810 PR: https://git.openjdk.org/jdk/pull/12810 From naoto at openjdk.org Fri Mar 17 15:48:18 2023 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 17 Mar 2023 15:48:18 GMT Subject: Integrated: 8304367: jlink --include-locales=* attempts to parse non .class resource files with classfile reader In-Reply-To: <-CFwdEf9n350xgKQWZmfFp0MxqrWoobQ8mHyUXdWDPQ=.4a4e678b-40fb-4eb3-a5a7-52156d9df2a4@github.com> References: <-CFwdEf9n350xgKQWZmfFp0MxqrWoobQ8mHyUXdWDPQ=.4a4e678b-40fb-4eb3-a5a7-52156d9df2a4@github.com> Message-ID: On Thu, 16 Mar 2023 20:43:38 GMT, Naoto Sato wrote: > This is a blocker for [JDK-8294972](https://bugs.openjdk.org/browse/JDK-8294972). The fix is to weed out non-class files for calling `ClassReader` by checking the file extension. Regression tests are not provided as it is not possible to detect the fix from the artifact jimage, but manually confirmed it would effectively weed out `LineBreakIteratorData_th`, `WordBreakIteratorData_th`, and `thai_dict` files by running `IncludeLocalesPluginTest.java`. This pull request has now been integrated. Changeset: 4486f1b7 Author: Naoto Sato URL: https://git.openjdk.org/jdk/commit/4486f1b72047dcdb2877cb3c9b4ca02f6cd008e9 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod 8304367: jlink --include-locales=* attempts to parse non .class resource files with classfile reader Reviewed-by: mchung, lancea, jpai ------------- PR: https://git.openjdk.org/jdk/pull/13067 From naoto at openjdk.org Fri Mar 17 16:09:52 2023 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 17 Mar 2023 16:09:52 GMT Subject: RFR: 8294972: Convert jdk.jlink internal plugins to use the Classfile API [v8] In-Reply-To: References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> Message-ID: On Fri, 17 Mar 2023 11:35:52 GMT, Adam Sotona wrote: >> Submitted: https://github.com/openjdk/jdk/pull/13067 > > I've reverted `IncludeLocalesPlugin` to previous version, plus minor fixes and together with #13067 the `IncludeLocalesPluginTest` is passing. > Thank you. The fix to `IncludeLocalesPlugin` has been integrated. @asotona would you please check that the exception is not thrown with your changes? ------------- PR: https://git.openjdk.org/jdk/pull/12944 From duke at openjdk.org Fri Mar 17 16:23:47 2023 From: duke at openjdk.org (Varada M) Date: Fri, 17 Mar 2023 16:23:47 GMT Subject: RFR: 8304320: java.base does not export jdk.internal.org.objectweb.asm to module jdk.jshell In-Reply-To: References: Message-ID: On Thu, 16 Mar 2023 08:43:46 GMT, Alan Bateman wrote: >> jdk/test/jdk/tools/jimage/VerifyJimage.java is failing because the module java.base is not exporting jdk.internal.org.objectweb.asm to module jdk.jshell. >> >> Reported Issue : [JDK-8304320](https://bugs.openjdk.org/browse/JDK-8304320) > > jshell was migrated to new the class file API in JDK-8294974 so it shouldn't have any references to ASM anymore. Would it be possible to check if you have a mismatch between your build and the test? @AlanBateman @JornVernee I did a clean build and now the test is passing.The error might have caused because of stale classes. Thanks for the correction. I will close this PR. ------------- PR: https://git.openjdk.org/jdk/pull/13057 From duke at openjdk.org Fri Mar 17 16:28:11 2023 From: duke at openjdk.org (Varada M) Date: Fri, 17 Mar 2023 16:28:11 GMT Subject: Withdrawn: 8304320: java.base does not export jdk.internal.org.objectweb.asm to module jdk.jshell In-Reply-To: References: Message-ID: On Thu, 16 Mar 2023 08:14:25 GMT, Varada M wrote: > jdk/test/jdk/tools/jimage/VerifyJimage.java is failing because the module java.base is not exporting jdk.internal.org.objectweb.asm to module jdk.jshell. > > Reported Issue : [JDK-8304320](https://bugs.openjdk.org/browse/JDK-8304320) This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/13057 From asotona at openjdk.org Fri Mar 17 17:01:43 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 17 Mar 2023 17:01:43 GMT Subject: RFR: 8294972: Convert jdk.jlink internal plugins to use the Classfile API [v12] In-Reply-To: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> Message-ID: <0XMnqSxriFou4zaFeHS3ECf43vk6skDCm9xnW6zrhoI=.572a6897-d370-4a5d-b8ff-72a0e479efbe@github.com> > jdk.jlink internal plugins are heavily using ASM > > This patch converts ASM calls to Classfile API. > > Please review. > Thanks, > Adam Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 220 commits: - Merge branch 'master' into JDK-8294972-jlink-plugins - SystemModulesPlugin::genClassBytes rename - SystemModulesPlugin::getClassBytes rename - Revert "implementation of custom ResourceHelper in IncludeLocalesPlugin" - remaining cleanup in SystemModulesPlugin - implementation of custom ResourceHelper in IncludeLocalesPlugin - fixed SystemModulesPlugin - fixed StripJavaDebugAttribute to drop line numbers from code - long lines wrapped - StripJavaDebugAttributesPlugin transformation fixed - ... and 210 more: https://git.openjdk.org/jdk/compare/4486f1b7...4e5b9651 ------------- Changes: https://git.openjdk.org/jdk/pull/12944/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12944&range=11 Stats: 1033 lines in 6 files changed: 216 ins; 278 del; 539 mod Patch: https://git.openjdk.org/jdk/pull/12944.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12944/head:pull/12944 PR: https://git.openjdk.org/jdk/pull/12944 From asotona at openjdk.org Fri Mar 17 17:01:45 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 17 Mar 2023 17:01:45 GMT Subject: RFR: 8294972: Convert jdk.jlink internal plugins to use the Classfile API [v8] In-Reply-To: References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> Message-ID: On Fri, 17 Mar 2023 16:06:53 GMT, Naoto Sato wrote: >> I've reverted `IncludeLocalesPlugin` to previous version, plus minor fixes and together with #13067 the `IncludeLocalesPluginTest` is passing. >> Thank you. > > The fix to `IncludeLocalesPlugin` has been integrated. @asotona would you please check that the exception is not thrown with your changes? Yes, I can confirm the test now passes. ------------- PR: https://git.openjdk.org/jdk/pull/12944 From naoto at openjdk.org Fri Mar 17 17:01:48 2023 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 17 Mar 2023 17:01:48 GMT Subject: RFR: 8294972: Convert jdk.jlink internal plugins to use the Classfile API [v8] In-Reply-To: References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> Message-ID: On Fri, 17 Mar 2023 16:56:16 GMT, Adam Sotona wrote: >> The fix to `IncludeLocalesPlugin` has been integrated. @asotona would you please check that the exception is not thrown with your changes? > > Yes, I can confirm the test now passes. Great! Thanks for checking ------------- PR: https://git.openjdk.org/jdk/pull/12944 From mchung at openjdk.org Fri Mar 17 17:34:24 2023 From: mchung at openjdk.org (Mandy Chung) Date: Fri, 17 Mar 2023 17:34:24 GMT Subject: RFR: 8294972: Convert jdk.jlink internal plugins to use the Classfile API [v12] In-Reply-To: <0XMnqSxriFou4zaFeHS3ECf43vk6skDCm9xnW6zrhoI=.572a6897-d370-4a5d-b8ff-72a0e479efbe@github.com> References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> <0XMnqSxriFou4zaFeHS3ECf43vk6skDCm9xnW6zrhoI=.572a6897-d370-4a5d-b8ff-72a0e479efbe@github.com> Message-ID: On Fri, 17 Mar 2023 17:01:43 GMT, Adam Sotona wrote: >> jdk.jlink internal plugins are heavily using ASM >> >> This patch converts ASM calls to Classfile API. >> >> Please review. >> Thanks, >> Adam > > Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 220 commits: > > - Merge branch 'master' into JDK-8294972-jlink-plugins > - SystemModulesPlugin::genClassBytes rename > - SystemModulesPlugin::getClassBytes rename > - Revert "implementation of custom ResourceHelper in IncludeLocalesPlugin" > - remaining cleanup in SystemModulesPlugin > - implementation of custom ResourceHelper in IncludeLocalesPlugin > - fixed SystemModulesPlugin > - fixed StripJavaDebugAttribute to drop line numbers from code > - long lines wrapped > - StripJavaDebugAttributesPlugin transformation fixed > - ... and 210 more: https://git.openjdk.org/jdk/compare/4486f1b7...4e5b9651 src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/IncludeLocalesPlugin.java line 309: > 307: TAG_INVOKEDYNAMIC -> offset += 5; > 308: case TAG_LONG, > 309: TAG_DOUBLE -> {offset += 9; cpSlot++;} //additional slot for double and long entries should this add the default case and throw to prepare for future change? ------------- PR: https://git.openjdk.org/jdk/pull/12944 From vlivanov at openjdk.org Fri Mar 17 17:36:09 2023 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Fri, 17 Mar 2023 17:36:09 GMT Subject: RFR: 8304303: implement VirtualThread class notifyJvmti methods as C2 intrinsics [v4] In-Reply-To: <-kZ3wf7zOt0zABMfgibzmuT5VHuROnTA92lkqbhitbE=.fd934229-b4a6-469a-9c4b-ac9f26efd80f@github.com> References: <-Pt3zLSu1Y2GYeM8XEivglUyDVXlAqMIA42-_zEnHlo=.7dd40f19-160a-4f11-8702-99c69a9b9923@github.com> <-kZ3wf7zOt0zABMfgibzmuT5VHuROnTA92lkqbhitbE=.fd934229-b4a6-469a-9c4b-ac9f26efd80f@github.com> Message-ID: On Fri, 17 Mar 2023 10:31:46 GMT, Serguei Spitsyn wrote: >> This is needed for performance improvements in support of virtual threads. >> The update includes the following: >> >> 1. Refactored the `VirtualThread` native methods: >> `notifyJvmtiMountBegin` and `notifyJvmtiMountEnd` => `notifyJvmtiMount` >> `notifyJvmtiUnmountBegin` and `notifyJvmtiUnmountEnd` => `notifyJvmtiUnmount` >> 2. Still useful implementation of old native methods is moved from `jvm.cpp` to `jvmtiThreadState.cpp`: >> `JVM_VirtualThreadMountStart` => `VTMS_mount_begin` >> `JVM_VirtualThreadMountEnd` => `VTMS_mount_end` >> `JVM_VirtualThreadUnmountStart` = > `VTMS_unmount_begin` >> `JVM_VirtualThreadUnmountEnd` => `VTMS_mount_end` >> 3. Intrinsified the `VirtualThread` native methods: `notifyJvmtiMount`, `notifyJvmtiUnmount`, `notifyJvmtiHideFrames`. >> 4. Removed the`VirtualThread` static boolean state variable `notifyJvmtiEvents` and its support in `javaClasses`. >> 5. Added static boolean state variable `_VTMS_notify_jvmti_events` to the jvmtiVTMSTransitionDisabler class as a replacement of the `VirtualThread` `notifyJvmtiEvents` variable. >> >> Implementing the same methods as C1 intrinsics can be needed in the future but is a low priority for now. >> >> Testing: >> - Ran mach5 tiers 1-6. No regressions were found. > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > minor tweaks in intrisics implementation Overall, compiler changes look good. Any performance numbers to justify the intrinsification? ------------- Marked as reviewed by vlivanov (Reviewer). PR: https://git.openjdk.org/jdk/pull/13054 From mchung at openjdk.org Fri Mar 17 18:11:08 2023 From: mchung at openjdk.org (Mandy Chung) Date: Fri, 17 Mar 2023 18:11:08 GMT Subject: RFR: 8304139: Add and method constants to ConstantDescs [v3] In-Reply-To: References: Message-ID: On Fri, 17 Mar 2023 00:43:04 GMT, Chen Liang wrote: >> Add String constants INIT_NAME, CLASS_INIT_NAME, MTD_void for the names and method type of instance and class initializers, as they are frequently used in the Classfile API. In addition, they appear frequently in the JDK itself as well. >> >> Update occurrences of and in core libraries API specification to refer to these constants. The occurrences in code elsewhere will be converted separately for there are too many. >> >> See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000233.html > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Remove main related constants, update specification for initialization constants Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/13020 From liach at openjdk.org Fri Mar 17 18:25:46 2023 From: liach at openjdk.org (Chen Liang) Date: Fri, 17 Mar 2023 18:25:46 GMT Subject: RFR: 8304425: ClassHierarchyResolver from Reflection Message-ID: <08Hy6pEhV75yr_F4mCP-dkKOKMCSoFxWI2E7OnM4iyQ=.cfa14992-8e94-4d6d-bdf9-e6689549c83e@github.com> Add API to explore Class Hierarchy with a `ClassLoader` or a `Lookup` with proper privileges, with tests. This addition is useful in case classes at runtime are not loaded from the system class loader, such as Proxy. This is also useful to APIs that generate bytecode with a `Lookup` object, such as a custom single-abstract-method class implementations from a method handle. See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000249.html as well. Current questions, which I wish to discuss with @asotona: 1. Should the resolver fail fast on `IllegalAccessException` from the lookup? This usually indicates the hierarchy resolver is set up improperly, and proceeding may simply yield verification errors in class loading that are hard to track. For bytecode-generating APIs, throwing access errors for the Lookup eagerly is also more preferable than later silent generation failure. 2. Whether the default resolver should be reading from jrt alone, reflection alone, or jrt then reflection. I personally believe reflection alone is more reliable, for classes may redefined with instrumentation or jfr, which may not be reflected in the system resources. 3. In addition, I don't think chaining system class loader reflection after system resource retrieval is really meaningful: is there any case where reflection always works while the system resource retrieval always fails? ------------- Commit messages: - 8304425: ClassHierarchyResolver from Reflection - ClassHierarchyResolver using Reflection Changes: https://git.openjdk.org/jdk/pull/13082/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13082&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304425 Stats: 139 lines in 5 files changed: 129 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/13082.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13082/head:pull/13082 PR: https://git.openjdk.org/jdk/pull/13082 From sspitsyn at openjdk.org Fri Mar 17 18:36:18 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 17 Mar 2023 18:36:18 GMT Subject: RFR: 8304303: implement VirtualThread class notifyJvmti methods as C2 intrinsics [v4] In-Reply-To: References: <-Pt3zLSu1Y2GYeM8XEivglUyDVXlAqMIA42-_zEnHlo=.7dd40f19-160a-4f11-8702-99c69a9b9923@github.com> <-kZ3wf7zOt0zABMfgibzmuT5VHuROnTA92lkqbhitbE=.fd934229-b4a6-469a-9c4b-ac9f26efd80f@github.com> Message-ID: On Fri, 17 Mar 2023 17:33:46 GMT, Vladimir Ivanov wrote: > Overall, compiler changes look good. > Any performance numbers to justify the intrinsification? Thank you for review and your guidance and help with C2 intrinsification! My goal was to move the notifyJvmtiEvents checks from Java to VM side without a performance penalty. I do not observe any performance degradation with customized Skynet benchmark executing 5 million virtual threads. Used `time` utility to measure total execution time (in milliseconds) of 10 runs on Oracle Linux server: - without intrinsics: 6083, 5405, 5270, 5700, 5004, 5402, 5536, 5031, 4902, 5124 - with intrinsics: 5904, 5287, 5470, 5672, 5298, 5053, 6154, 4992, 6237, 5155 ------------- PR: https://git.openjdk.org/jdk/pull/13054 From jlu at openjdk.org Fri Mar 17 19:19:30 2023 From: jlu at openjdk.org (Justin Lu) Date: Fri, 17 Mar 2023 19:19:30 GMT Subject: RFR: 8225641: Calendar.roll(int field) does not work correctly for WEEK_OF_YEAR In-Reply-To: References: Message-ID: On Tue, 14 Mar 2023 22:16:45 GMT, Justin Lu wrote: > This PR fixes the bug which occurred when `Calendar.roll(WEEK_OF_YEAR)` rolled into a minimal first week with an invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo. > > For example, Rolling _Monday, 30 December 2019_ by 1 week produced _Monday, 31 December 2018_, which is incorrect. This is because `WEEK_OF_YEAR` is rolled from 52 to 1, and the original `DAY_OF_WEEK` is 1. However, there is no Monday in week 1 of 2019. This is exposed when a future method calls `Calendar.complete()`, which eventually calculates a `fixedDate` with the invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo. > > To prevent this, a check is added for rolls into week 1, which determines if the first week is minimal. If it is indeed minimal, then it is checked if `DAY_OF_WEEK` exists in that week, if not, `WEEK_OF_YEAR` must be incremented by one. > > After the fix, Rolling _Monday, 30 December 2019_ by 1 week produces _Monday, 7 January 2019_ Although this issue applies to Gregorian Calendar, it appears it may also occur with a Japanese Calendar under the right circumstances. `{$$$ Failed: Rolled: "Sunday, 29 December 1" by 1 week, expecting: "Sunday, 5 May 1", but got: "Saturday, 5 January 31"}` The Reiwa era begins on May 1st, 2019. Rolling the last Sunday of 2019 by 1 week, one would expect the resultant date to be the first Sunday of the Reiwai period (the 5th of May, 2019). However, a completely wrong date is returned, and the calendar actually rolls back an era into Heisei. Looking into it further, as well as the other calendars ------------- PR: https://git.openjdk.org/jdk/pull/13031 From jlu at openjdk.org Fri Mar 17 20:28:13 2023 From: jlu at openjdk.org (Justin Lu) Date: Fri, 17 Mar 2023 20:28:13 GMT Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v4] In-Reply-To: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com> References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com> Message-ID: > This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii. > > In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: Adjust CF test to read in with UTF-8 to fix failing test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12726/files - new: https://git.openjdk.org/jdk/pull/12726/files/7119830b..007c78a7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12726&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12726&range=02-03 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12726.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12726/head:pull/12726 PR: https://git.openjdk.org/jdk/pull/12726 From angorya at openjdk.org Fri Mar 17 20:34:00 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 17 Mar 2023 20:34:00 GMT Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v4] In-Reply-To: References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com> Message-ID: <-3wtWK_Pdt1fqDnSjbS6JTGLwboJi7Tw2sV0v7LQ3Os=.7036d0b0-2524-43bc-a82d-640f29fd35a0@github.com> On Fri, 17 Mar 2023 20:28:13 GMT, Justin Lu wrote: >> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii. >> >> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > Adjust CF test to read in with UTF-8 to fix failing test make/jdk/src/classes/build/tools/compileproperties/CompileProperties.java line 226: > 224: Properties p = new Properties(); > 225: try { > 226: FileInputStream input = new FileInputStream(propertiesPath); Should this stream be closed in a finally { } block? ------------- PR: https://git.openjdk.org/jdk/pull/12726 From naoto at openjdk.org Fri Mar 17 21:05:18 2023 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 17 Mar 2023 21:05:18 GMT Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v4] In-Reply-To: <-3wtWK_Pdt1fqDnSjbS6JTGLwboJi7Tw2sV0v7LQ3Os=.7036d0b0-2524-43bc-a82d-640f29fd35a0@github.com> References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com> <-3wtWK_Pdt1fqDnSjbS6JTGLwboJi7Tw2sV0v7LQ3Os=.7036d0b0-2524-43bc-a82d-640f29fd35a0@github.com> Message-ID: On Fri, 17 Mar 2023 20:31:27 GMT, Andy Goryachev wrote: >> Justin Lu has updated the pull request incrementally with one additional commit since the last revision: >> >> Adjust CF test to read in with UTF-8 to fix failing test > > make/jdk/src/classes/build/tools/compileproperties/CompileProperties.java line 226: > >> 224: Properties p = new Properties(); >> 225: try { >> 226: FileInputStream input = new FileInputStream(propertiesPath); > > Should this stream be closed in a finally { } block? or better be `try-with-resources`? ------------- PR: https://git.openjdk.org/jdk/pull/12726 From weijun at openjdk.org Fri Mar 17 21:52:23 2023 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 17 Mar 2023 21:52:23 GMT Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v4] In-Reply-To: References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com> Message-ID: <1JBZe7nrM-HsVEItfK-3GPeXoX_glyM9SL4ZACUbLwk=.3a3cf62b-0960-4b03-80aa-2756bd1636dc@github.com> On Fri, 17 Mar 2023 20:28:13 GMT, Justin Lu wrote: >> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii. >> >> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > Adjust CF test to read in with UTF-8 to fix failing test make/jdk/src/classes/build/tools/compileproperties/CompileProperties.java line 326: > 324: outBuffer.append(toHex((aChar >> 8) & 0xF)); > 325: outBuffer.append(toHex((aChar >> 4) & 0xF)); > 326: outBuffer.append(toHex(aChar & 0xF)); Sorry I don't know when this tool is called, but why is it still writing in `\unnnn` style? ------------- PR: https://git.openjdk.org/jdk/pull/12726 From weijun at openjdk.org Fri Mar 17 21:56:23 2023 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 17 Mar 2023 21:56:23 GMT Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v4] In-Reply-To: <1JBZe7nrM-HsVEItfK-3GPeXoX_glyM9SL4ZACUbLwk=.3a3cf62b-0960-4b03-80aa-2756bd1636dc@github.com> References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com> <1JBZe7nrM-HsVEItfK-3GPeXoX_glyM9SL4ZACUbLwk=.3a3cf62b-0960-4b03-80aa-2756bd1636dc@github.com> Message-ID: On Fri, 17 Mar 2023 21:49:33 GMT, Weijun Wang wrote: >> Justin Lu has updated the pull request incrementally with one additional commit since the last revision: >> >> Adjust CF test to read in with UTF-8 to fix failing test > > make/jdk/src/classes/build/tools/compileproperties/CompileProperties.java line 326: > >> 324: outBuffer.append(toHex((aChar >> 8) & 0xF)); >> 325: outBuffer.append(toHex((aChar >> 4) & 0xF)); >> 326: outBuffer.append(toHex(aChar & 0xF)); > > Sorry I don't know when this tool is called, but why is it still writing in `\unnnn` style? I probably understand it now, source code still needs escaping. When can we put in UTF-8 there as well? ------------- PR: https://git.openjdk.org/jdk/pull/12726 From mchung at openjdk.org Fri Mar 17 22:08:56 2023 From: mchung at openjdk.org (Mandy Chung) Date: Fri, 17 Mar 2023 22:08:56 GMT Subject: RFR: JDK-8304163: Move jdk.internal.module.ModuleInfoWriter to the test library Message-ID: `ModuleInfoWriter` is not used by the runtime. Move it to the test library as `jdk.test.lib.util.ModuleInfoWriter`. The tests are updated to use the test library instead. `ModuleInfoWriter` depends on `jdk.internal.module` types and the Classfile API. Hence `@modules java.base/jdk.internal.classfile` and other classfile subpackages are added. ------------- Commit messages: - JDK-8304163: Move jdk.internal.module.ModuleInfoWriter to the test library Changes: https://git.openjdk.org/jdk/pull/13085/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13085&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304163 Stats: 146 lines in 17 files changed: 87 ins; 15 del; 44 mod Patch: https://git.openjdk.org/jdk/pull/13085.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13085/head:pull/13085 PR: https://git.openjdk.org/jdk/pull/13085 From jlu at openjdk.org Fri Mar 17 22:27:48 2023 From: jlu at openjdk.org (Justin Lu) Date: Fri, 17 Mar 2023 22:27:48 GMT Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v5] In-Reply-To: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com> References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com> Message-ID: > This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii. > > In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: Close streams when finished loading into props ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12726/files - new: https://git.openjdk.org/jdk/pull/12726/files/007c78a7..19b91e6b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12726&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12726&range=03-04 Stats: 15 lines in 3 files changed: 6 ins; 1 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/12726.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12726/head:pull/12726 PR: https://git.openjdk.org/jdk/pull/12726 From asemenyuk at openjdk.org Fri Mar 17 23:47:18 2023 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 17 Mar 2023 23:47:18 GMT Subject: RFR: 8298995: tools/jpackage/share/AddLauncherTest.java#id1 failed "AddLauncherTest.test; checks=53" In-Reply-To: References: Message-ID: <8ClsXMKxAIGwTCMq5LfW5KvBTGb6idbaXNYGaQoNlI8=.78916c87-cc59-4de8-8471-06d50658f564@github.com> On Mon, 13 Mar 2023 16:50:51 GMT, Alexander Matveev wrote: > This is similar to many other issues we had with `hdiutil` failures. Fixed in similar way by repeating `hdiutil` command. Cannot confirm that it will resolve this issue, but similar issues got resolved by repeating command. Also, switched writing output from `hdiutil` to file. It is known issue that execution of `hdiutil` can hang if output is not written to file. Marked as reviewed by asemenyuk (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/13002 From almatvee at openjdk.org Sat Mar 18 00:05:29 2023 From: almatvee at openjdk.org (Alexander Matveev) Date: Sat, 18 Mar 2023 00:05:29 GMT Subject: Integrated: 8298995: tools/jpackage/share/AddLauncherTest.java#id1 failed "AddLauncherTest.test; checks=53" In-Reply-To: References: Message-ID: <9dBww_SGNxw0Kxj_479BpEpaQE_39MXNDsfGNUsDkjk=.5fcaa3cb-fd88-499e-95a7-05b1c4275a33@github.com> On Mon, 13 Mar 2023 16:50:51 GMT, Alexander Matveev wrote: > This is similar to many other issues we had with `hdiutil` failures. Fixed in similar way by repeating `hdiutil` command. Cannot confirm that it will resolve this issue, but similar issues got resolved by repeating command. Also, switched writing output from `hdiutil` to file. It is known issue that execution of `hdiutil` can hang if output is not written to file. This pull request has now been integrated. Changeset: c56f011b Author: Alexander Matveev URL: https://git.openjdk.org/jdk/commit/c56f011baa4ce7f44661f6ade8e313f812730c02 Stats: 49 lines in 2 files changed: 31 ins; 0 del; 18 mod 8298995: tools/jpackage/share/AddLauncherTest.java#id1 failed "AddLauncherTest.test; checks=53" Reviewed-by: asemenyuk ------------- PR: https://git.openjdk.org/jdk/pull/13002 From jpai at openjdk.org Sat Mar 18 00:34:20 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 18 Mar 2023 00:34:20 GMT Subject: RFR: JDK-8304163: Move jdk.internal.module.ModuleInfoWriter to the test library In-Reply-To: References: Message-ID: On Fri, 17 Mar 2023 22:01:46 GMT, Mandy Chung wrote: > `ModuleInfoWriter` is not used by the runtime. Move it to the test library as `jdk.test.lib.util.ModuleInfoWriter`. The tests are updated to use the test library instead. `ModuleInfoWriter` depends on `jdk.internal.module` types and the Classfile API. Hence `@modules java.base/jdk.internal.classfile` and other classfile subpackages are added. The changes look good to me ------------- Marked as reviewed by jpai (Reviewer). PR: https://git.openjdk.org/jdk/pull/13085 From zjx001202 at gmail.com Sat Mar 18 07:41:13 2023 From: zjx001202 at gmail.com (Glavo) Date: Sat, 18 Mar 2023 15:41:13 +0800 Subject: Track Classfile API changes on the classfile-api-dev mailing list Message-ID: Hi everyone, I extracted Classfile API from JDK, ported it back to Java 17, and published it to Maven Central as a standalone library. Here is its repository: https://github.com/Glavo/classfile (I've posted the above on classfile-api-dev, but I don't see it in the mailing list archives. I don't know if it was sent successfully, so I'll repeat it here) To maintain it, I am very concerned about changes to the Classfile API and sync the changes to the above repository. Unfortunately, the Classfile API does not appear to have a specific JBS label, and I cannot track related PRs from the classfile-api-dev, so I have to check the history of the Classfile API source folder at regular intervals. In order to facilitate tracking, I hope that a label will be assigned to the Classfile API and send relevant PR notification emails to the classfile-api-dev mailing list. Is that okay? Glavo -------------- next part -------------- An HTML attachment was scrubbed... URL: From alanb at openjdk.org Sat Mar 18 10:59:19 2023 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 18 Mar 2023 10:59:19 GMT Subject: RFR: JDK-8304163: Move jdk.internal.module.ModuleInfoWriter to the test library In-Reply-To: References: Message-ID: On Fri, 17 Mar 2023 22:01:46 GMT, Mandy Chung wrote: > `ModuleInfoWriter` is not used by the runtime. Move it to the test library as `jdk.test.lib.util.ModuleInfoWriter`. The tests are updated to use the test library instead. `ModuleInfoWriter` depends on `jdk.internal.module` types and the Classfile API. Hence `@modules java.base/jdk.internal.classfile` and other classfile subpackages are added. Thanks for moving this to the test lib. On the tag ordering, the reason some of these tests had @modules before @library was just to recommend ordering in the tag tag spec (https://openjdk.org/jtreg/tag-spec.html#ORDER). ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.org/jdk/pull/13085 From alanb at openjdk.org Sat Mar 18 11:27:20 2023 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 18 Mar 2023 11:27:20 GMT Subject: RFR: 8304303: implement VirtualThread class notifyJvmti methods as C2 intrinsics [v4] In-Reply-To: <-kZ3wf7zOt0zABMfgibzmuT5VHuROnTA92lkqbhitbE=.fd934229-b4a6-469a-9c4b-ac9f26efd80f@github.com> References: <-Pt3zLSu1Y2GYeM8XEivglUyDVXlAqMIA42-_zEnHlo=.7dd40f19-160a-4f11-8702-99c69a9b9923@github.com> <-kZ3wf7zOt0zABMfgibzmuT5VHuROnTA92lkqbhitbE=.fd934229-b4a6-469a-9c4b-ac9f26efd80f@github.com> Message-ID: <-OJbhkKU3EtSS8E31eEd62h3-x5Szpl_Hk0apm1a6aQ=.687c660f-bc13-41cd-bc63-c59ca60300f0@github.com> On Fri, 17 Mar 2023 10:31:46 GMT, Serguei Spitsyn wrote: >> This is needed for future performance/scalability improvements in JVMTI support of virtual threads. >> The update includes the following: >> >> 1. Refactored the `VirtualThread` native methods: >> `notifyJvmtiMountBegin` and `notifyJvmtiMountEnd` => `notifyJvmtiMount` >> `notifyJvmtiUnmountBegin` and `notifyJvmtiUnmountEnd` => `notifyJvmtiUnmount` >> 2. Still useful implementation of old native methods is moved from `jvm.cpp` to `jvmtiThreadState.cpp`: >> `JVM_VirtualThreadMountStart` => `VTMS_mount_begin` >> `JVM_VirtualThreadMountEnd` => `VTMS_mount_end` >> `JVM_VirtualThreadUnmountStart` = > `VTMS_unmount_begin` >> `JVM_VirtualThreadUnmountEnd` => `VTMS_mount_end` >> 3. Intrinsified the `VirtualThread` native methods: `notifyJvmtiMount`, `notifyJvmtiUnmount`, `notifyJvmtiHideFrames`. >> 4. Removed the`VirtualThread` static boolean state variable `notifyJvmtiEvents` and its support in `javaClasses`. >> 5. Added static boolean state variable `_VTMS_notify_jvmti_events` to the jvmtiVTMSTransitionDisabler class as a replacement of the `VirtualThread` `notifyJvmtiEvents` variable. >> >> Implementing the same methods as C1 intrinsics can be needed in the future but is a low priority for now. >> >> Testing: >> - Ran mach5 tiers 1-6. No regressions were found. > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > minor tweaks in intrisics implementation The most important case is when there is no JVMTI env. If I read the changes correctly, the overhead for park/continue changes from one volatile-read (notifyJvmtiEvents) to two plain-writes (JavaThread::_is_in_VTMS_transition). If a JVMTI env has been created then there is no benefit for the moment as there is still a call into the runtime to interact with JvmtiVTMSTransitionDisabler. So I think you are saying that is for follow-on PRs. ------------- PR: https://git.openjdk.org/jdk/pull/13054 From jpai at openjdk.org Sat Mar 18 13:17:04 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 18 Mar 2023 13:17:04 GMT Subject: RFR: 8304006: jlink should create the jimage file in the native endian for the target platform [v9] In-Reply-To: References: Message-ID: <5hOUPGZawUJeh7br8fz7u_sy7ABnOwzPpS12wKMzPJE=.8b9ec096-9fbe-436f-a7b9-ba866d26123f@github.com> > Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8206890? > > The `jlink` command allows a `--endian` option to specify the byte order in the generated image. Before this change, when such a image was being launched, the code would assume the byte order in the image to be the native order of the host where the image is being launched. That would result in failure to launch java, as noted in the linked issue. > > The commit in this PR, changes relevant places to not assume native order and instead determine the byte order by reading the magic bytes in the image file's header content. > > A new jtreg test has been added which reproduces the issue and verifies the fix. 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 20 additional commits since the last revision: - Mandy's suggestion - pass along target platform to the DefaultImageBuilder to prevent reparsing the value from the ModuleTarget - Mandy's suggestion to use Platform class for additional arch support. Plus, Jim's suggestion to use a runtime resource for endianness mapping - merge latest from master branch - don't hardcode the .jmod extension while determining java.base module location - Path.resolve(String) instead of Path.resolve(Path) - no need for security manager checks in jlink - only include known supported arch - Alan's suggestion - look into the ModuleTarget attribute in module-info.class only if this is a cross-platform image generation - missed ppc64 from the arch mapping - undo unintentional copyright year change - ... and 10 more: https://git.openjdk.org/jdk/compare/75ddac94...f4b71700 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11943/files - new: https://git.openjdk.org/jdk/pull/11943/files/da590e9d..f4b71700 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11943&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11943&range=07-08 Stats: 77621 lines in 772 files changed: 48489 ins; 20061 del; 9071 mod Patch: https://git.openjdk.org/jdk/pull/11943.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11943/head:pull/11943 PR: https://git.openjdk.org/jdk/pull/11943 From jpai at openjdk.org Sat Mar 18 13:31:22 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 18 Mar 2023 13:31:22 GMT Subject: RFR: 8304006: jlink should create the jimage file in the native endian for the target platform [v8] In-Reply-To: References: Message-ID: <3PosSfnNxBGNjlCAGVaSD9JqgOfrfQjWM5kv-VTgxj4=.49f65531-8400-43c2-9520-a896431ea3a3@github.com> On Tue, 14 Mar 2023 08:30:11 GMT, Alan Bateman wrote: >> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 953: >> >>> 951: // and supported for creating an image through jlink. Else returns null. >>> 952: private static ByteOrder getNativeEndianOfTargetPlatform(String targetPlatform) { >>> 953: int index = targetPlatform.indexOf("-"); // of the form - >> >> `Platform::parsePlatform` is the utility method to parse `ModuleTarget`. It can be updated to include additional architectures. > >> `Platform::parsePlatform` is the utility method to parse `ModuleTarget`. It can be updated to include additional architectures. > > Alternatively, don't parse it. If we go with Jim's suggestion of a resource file then it is just a simple mapping of the ModuleTarget value, e.g the entry for macox-x64 would be: > > macos-amd64.endianness = little Hello Mandy, Alan, Jim, I've updated this PR to take into account these suggestions. I went ahead with what Mandy suggested and enhanced the existing (internal) `jdk.tools.jlink.internal.Platform` `record`to additional parse these architectures. It was anyway doing it for a select few. In addition to that, I also moved the architecture to endianness mapping into this `Platform` class itself. I followed Jim's suggestion to move the mapping out of the code. The `Platform` code now reads this from a `endianness.properties` file which is an internal resource of the `jdk.jlink` module. However, I'm having second thoughts about this part. I'm guessing that when Jim suggested moving this to a resource, it was probably because the code resided within the `JLinkTask` class. Now that I've moved this to an existing `Platform` class which is solely meant for things like these, I feel that we could probably just hard code these architecture to endianness mapping within this class itself, instead of reading it from a properties file. I'm looking for some inputs on what you all think would be the best way to proceed. Alan, as for the `osname-arch=little/big` vs `arch=little/big` mapping style, I decided to use the `arch=little/big` and let the Platform class parse the architecture out of the string in the `ModuleTarget`. I did it for a couple of reasons: 1. The `Platform` class already has the necessary logic to do that, plus it has to do that anyway (for us to implement the suggestion that Mandy noted about using this in `DefaultImageBuilder`) 2. As far as I could see, the OS name shouldn't play any role in the endianness, so leaving that out felt easier to deal with since we wouldn't have to think of what OS name, arch combinations would be valid. If you or others feel that it's better to stick with the `osname-arch=little/big` approach, instead of this one, please do let me know and I'll go ahead and do that change. ------------- PR: https://git.openjdk.org/jdk/pull/11943 From jpai at openjdk.org Sat Mar 18 13:34:23 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 18 Mar 2023 13:34:23 GMT Subject: RFR: 8304006: jlink should create the jimage file in the native endian for the target platform [v8] In-Reply-To: References: Message-ID: On Mon, 13 Mar 2023 23:20:35 GMT, Mandy Chung wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> don't hardcode the .jmod extension while determining java.base module location > > src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 834: > >> 832: // find the target platform's arch and thus its endianness from the java.base >> 833: // module's ModuleTarget attribute >> 834: Optional javaBase = cf.findModule("java.base"); > > `ModuleTarget` is read by `DefaultImageReader::storeFiles` as well. Perhaps it should be refactored so that the target `Platform` can be passed to `DefaultImageBuilder`. I've updated the PR to pass along this already parsed target platform to the `DefaultImageBuilder`. This code is new to me and I think I made sure (by checking references and the package names) that I only updated the internal classes without impacting any user facing APIs. If however, this impacts any user facing API, please do let me know. ------------- PR: https://git.openjdk.org/jdk/pull/11943 From jpai at openjdk.org Sat Mar 18 13:37:25 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 18 Mar 2023 13:37:25 GMT Subject: RFR: 8304006: jlink should create the jimage file in the native endian for the target platform [v9] In-Reply-To: <5hOUPGZawUJeh7br8fz7u_sy7ABnOwzPpS12wKMzPJE=.8b9ec096-9fbe-436f-a7b9-ba866d26123f@github.com> References: <5hOUPGZawUJeh7br8fz7u_sy7ABnOwzPpS12wKMzPJE=.8b9ec096-9fbe-436f-a7b9-ba866d26123f@github.com> Message-ID: <-_aCDcQPk-DlsvoMarpuMu4Nw_4s5at9kwcpg78L5Cs=.33d058ae-a336-422a-ab74-4ce9e699a737@github.com> On Sat, 18 Mar 2023 13:17:04 GMT, Jaikiran Pai wrote: >> Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8206890? >> >> The `jlink` command allows a `--endian` option to specify the byte order in the generated image. Before this change, when such a image was being launched, the code would assume the byte order in the image to be the native order of the host where the image is being launched. That would result in failure to launch java, as noted in the linked issue. >> >> The commit in this PR, changes relevant places to not assume native order and instead determine the byte order by reading the magic bytes in the image file's header content. >> >> A new jtreg test has been added which reproduces the issue and verifies the fix. > > 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 20 additional commits since the last revision: > > - Mandy's suggestion - pass along target platform to the DefaultImageBuilder to prevent reparsing the value from the ModuleTarget > - Mandy's suggestion to use Platform class for additional arch support. Plus, Jim's suggestion to use a runtime resource for endianness mapping > - merge latest from master branch > - don't hardcode the .jmod extension while determining java.base module location > - Path.resolve(String) instead of Path.resolve(Path) > - no need for security manager checks in jlink > - only include known supported arch > - Alan's suggestion - look into the ModuleTarget attribute in module-info.class only if this is a cross-platform image generation > - missed ppc64 from the arch mapping > - undo unintentional copyright year change > - ... and 10 more: https://git.openjdk.org/jdk/compare/520eaa6f...f4b71700 Existing tests in `test/jdk/tools/jlink` and `test/jdk/tools/jimage` continue to pass with these changes and a manual test of building a cross platform image shows that it picks up the correct endianness of the target platform (and fails with an error if the target platform's endianness isn't known) ------------- PR: https://git.openjdk.org/jdk/pull/11943 From duke at openjdk.org Sat Mar 18 17:09:23 2023 From: duke at openjdk.org (jmehrens) Date: Sat, 18 Mar 2023 17:09:23 GMT Subject: RFR: 8304245: Speed up CharacterData.of by avoiding bit shifting in the latin1 fast-path test [v2] In-Reply-To: <4m6unzqJyeoeWDRGNSMXOZq9ysa1JfUldlHhrXz5xTY=.58f68d2c-4ab2-4357-aa83-3c88e7a8ba0f@github.com> References: <-mhNL4ascuO9KdhZ-L0jRng9dxvp78p_FWNrg6VUaKo=.1f6c5ec1-cde3-4acd-a2c4-c2fd0933c480@github.com> <48pbcrbZmBQO6J80QbsguXOnjkWpcvYAHoJeuRJkJxM=.8c5a9e01-2793-4161-9dab-dee7a1b95d52@github.com> <-G0bjp7QOP42BCRs1n2G6mxJSExj76GroacBjkQoWuo=.05e993a5-f012-4c6b-8c49-4c74d8e35b39@github.com> <1jnPSPh1W0Lme04llPDlejKeFmNOH2eL5fNmyUgN_Ns=.b4021466-157a-49ab-bd08-71c0ec9312dd@github.com> <4m6unzqJyeoeWDRGNSMXOZq9ysa1JfUldlHhrXz5xTY=.58f68d2c-4ab2-4357-aa83-3c88e7a8ba0f@github.com> Message-ID: On Wed, 15 Mar 2023 15:10:49 GMT, Eirik Bjorsnos wrote: >> We can do `Integer.compareUnsigned(ch, 0xFF) <= 0` > > We could, but benchmarks show no performance improvements over the current PR. I think the current code is perhaps slightly more readable. Does non-short-circuit logical AND operator perform similar to baseline? In this very specific case there is no risk of side effects due to method calls, no risk of null pointer exception because of primitives, and there is not an excessive amount of conditions. Therefore, I would think either `&` or `&&` are viable options. `if (ch >= 0 & ch <= 0xFF) {` I ask just for the sake of my own learning on this topic as it relates to performance as opposed to code readability preferences. ------------- PR: https://git.openjdk.org/jdk/pull/13040 From duke at openjdk.org Sat Mar 18 17:48:20 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Sat, 18 Mar 2023 17:48:20 GMT Subject: RFR: 8304245: Speed up CharacterData.of by avoiding bit shifting in the latin1 fast-path test [v2] In-Reply-To: References: <-mhNL4ascuO9KdhZ-L0jRng9dxvp78p_FWNrg6VUaKo=.1f6c5ec1-cde3-4acd-a2c4-c2fd0933c480@github.com> <48pbcrbZmBQO6J80QbsguXOnjkWpcvYAHoJeuRJkJxM=.8c5a9e01-2793-4161-9dab-dee7a1b95d52@github.com> <-G0bjp7QOP42BCRs1n2G6mxJSExj76GroacBjkQoWuo=.05e993a5-f012-4c6b-8c49-4c74d8e35b39@github.com> <1jnPSPh1W0Lme04llPDlejKeFmNOH2eL5fNmyUgN_Ns=.b4021466-157a-49ab-bd08-71c0ec9312dd@github.com> <4m6unzqJyeoeWDRGNSMXOZq9ysa1JfUldlHhrXz5xTY=.58f68d2c-4ab2-4357-aa83-3c88e7a8ba0f@github.com> Message-ID: On Sat, 18 Mar 2023 17:06:52 GMT, jmehrens wrote: >> We could, but benchmarks show no performance improvements over the current PR. I think the current code is perhaps slightly more readable. > > Does non-short-circuit logical AND operator perform similar to baseline? In this very specific case there is no risk of side effects due to method calls, no risk of null pointer exception because of primitives, and there is not an excessive amount of conditions. Therefore, I would think either `&` or `&&` are viable options. > > `if (ch >= 0 & ch <= 0xFF) {` > > I ask just for the sake of my own learning on this topic as it relates to performance as opposed to code readability preferences. Both choices of operators en up with identical generated code on my Intel Mac. For reference, I did a comparison between the generated code for the current code, and the one in this PR: Current generated code start like this: movl %eax, -0x14000(%rsp) pushq %rbp subq $0x20, %rsp cmpl $1, 0x20(%r15) jne 0x119cae072 movl %esi, %r11d shrl $8, %r11d testl %r11d, %r11d jne 0x119cae043 movabsq $0x70fe03c90, %rax ; {oop(a 'java/lang/CharacterDataLatin1'{0x000000070fe03c90})} ``` While the PR generated code starts like this: movl %eax, -0x14000(%rsp) pushq %rbp subq $0x20, %rsp cmpl $1, 0x20(%r15) jne 0x1171d41f2 nopw (%rax, %rax) cmpl $0x100, %esi jae 0x1171d41c5 movabsq $0x70fe03c90, %rax ; {oop(a 'java/lang/CharacterDataLatin1'{0x000000070fe03c90})} The rest of the code seems identical. ------------- PR: https://git.openjdk.org/jdk/pull/13040 From duke at openjdk.org Sat Mar 18 17:52:11 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Sat, 18 Mar 2023 17:52:11 GMT Subject: RFR: 8304443: bootcycle builds fail after JDK-8015831 Message-ID: The fix for JDK-8015831, which added the new `this-escape` lint warning, caused the build of the `bootcycle-images` make target to fail. This commit adds the additional `@SuppressWarnings("this-escape")` annotations needed to fix it. ------------- Commit messages: - Add @SuppressWarnings("this-escape") annotations needed by 'bootcycle' build. - Merge branch 'master' into ThisEscape - Relax warning to apply only if subclass could exist in another module/package. - Tweaks to man page. - Add YieldRef to Javadoc algorithm summary. - Document the this-escape lint option in the javac(1) man page. - Omit sealed classes when permitted subclasses are in the compilation unit. - Add assertion check for reuse of analyzer, which is unsupported. - Include assert detail expressions in the analysis. - Use more modern patterned instanceof instead of hasTag() + cast. - ... and 83 more: https://git.openjdk.org/jdk/compare/7503ecc0...28182104 Changes: https://git.openjdk.org/jdk/pull/13089/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13089&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304443 Stats: 74 lines in 63 files changed: 71 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/13089.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13089/head:pull/13089 PR: https://git.openjdk.org/jdk/pull/13089 From mchung at openjdk.org Sat Mar 18 19:14:09 2023 From: mchung at openjdk.org (Mandy Chung) Date: Sat, 18 Mar 2023 19:14:09 GMT Subject: RFR: JDK-8304163: Move jdk.internal.module.ModuleInfoWriter to the test library [v2] In-Reply-To: References: Message-ID: > `ModuleInfoWriter` is not used by the runtime. Move it to the test library as `jdk.test.lib.util.ModuleInfoWriter`. The tests are updated to use the test library instead. `ModuleInfoWriter` depends on `jdk.internal.module` types and the Classfile API. Hence `@modules java.base/jdk.internal.classfile` and other classfile subpackages are added. Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: move @library after @modules per the recommended ordering ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13085/files - new: https://git.openjdk.org/jdk/pull/13085/files/3eda19b5..6b7611ad Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13085&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13085&range=00-01 Stats: 30 lines in 14 files changed: 15 ins; 15 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13085.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13085/head:pull/13085 PR: https://git.openjdk.org/jdk/pull/13085 From mchung at openjdk.org Sat Mar 18 19:14:11 2023 From: mchung at openjdk.org (Mandy Chung) Date: Sat, 18 Mar 2023 19:14:11 GMT Subject: RFR: JDK-8304163: Move jdk.internal.module.ModuleInfoWriter to the test library In-Reply-To: References: Message-ID: On Fri, 17 Mar 2023 22:01:46 GMT, Mandy Chung wrote: > `ModuleInfoWriter` is not used by the runtime. Move it to the test library as `jdk.test.lib.util.ModuleInfoWriter`. The tests are updated to use the test library instead. `ModuleInfoWriter` depends on `jdk.internal.module` types and the Classfile API. Hence `@modules java.base/jdk.internal.classfile` and other classfile subpackages are added. Thanks for the pointer to the recommended ordering. Tests updated. ------------- PR: https://git.openjdk.org/jdk/pull/13085 From vromero at openjdk.org Sat Mar 18 23:20:21 2023 From: vromero at openjdk.org (Vicente Romero) Date: Sat, 18 Mar 2023 23:20:21 GMT Subject: RFR: 8304443: bootcycle builds fail after JDK-8015831 In-Reply-To: References: Message-ID: On Sat, 18 Mar 2023 17:46:00 GMT, Archie L. Cobbs wrote: > The fix for JDK-8015831, which added the new `this-escape` lint warning, caused the build of the `bootcycle-images` make target to fail. > > This commit adds the additional `@SuppressWarnings("this-escape")` annotations needed to fix it. change looks good, rerunning the tests to double check ------------- PR: https://git.openjdk.org/jdk/pull/13089 From vromero at openjdk.org Sun Mar 19 02:44:22 2023 From: vromero at openjdk.org (Vicente Romero) Date: Sun, 19 Mar 2023 02:44:22 GMT Subject: RFR: 8304443: bootcycle builds fail after JDK-8015831 In-Reply-To: References: Message-ID: On Sat, 18 Mar 2023 17:46:00 GMT, Archie L. Cobbs wrote: > The fix for JDK-8015831, which added the new `this-escape` lint warning, caused the build of the `bootcycle-images` make target to fail. > > This commit adds the additional `@SuppressWarnings("this-escape")` annotations needed to fix it. looks good, thanks! ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.org/jdk/pull/13089 From alanb at openjdk.org Sun Mar 19 07:05:19 2023 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 19 Mar 2023 07:05:19 GMT Subject: RFR: JDK-8304163: Move jdk.internal.module.ModuleInfoWriter to the test library [v2] In-Reply-To: References: Message-ID: On Sat, 18 Mar 2023 19:14:09 GMT, Mandy Chung wrote: >> `ModuleInfoWriter` is not used by the runtime. Move it to the test library as `jdk.test.lib.util.ModuleInfoWriter`. The tests are updated to use the test library instead. `ModuleInfoWriter` depends on `jdk.internal.module` types and the Classfile API. Hence `@modules java.base/jdk.internal.classfile` and other classfile subpackages are added. > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > move @library after @modules per the recommended ordering Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/13085 From alanb at openjdk.org Sun Mar 19 09:10:22 2023 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 19 Mar 2023 09:10:22 GMT Subject: RFR: 8304006: jlink should create the jimage file in the native endian for the target platform [v8] In-Reply-To: <3PosSfnNxBGNjlCAGVaSD9JqgOfrfQjWM5kv-VTgxj4=.49f65531-8400-43c2-9520-a896431ea3a3@github.com> References: <3PosSfnNxBGNjlCAGVaSD9JqgOfrfQjWM5kv-VTgxj4=.49f65531-8400-43c2-9520-a896431ea3a3@github.com> Message-ID: On Sat, 18 Mar 2023 13:28:52 GMT, Jaikiran Pai wrote: >>> `Platform::parsePlatform` is the utility method to parse `ModuleTarget`. It can be updated to include additional architectures. >> >> Alternatively, don't parse it. If we go with Jim's suggestion of a resource file then it is just a simple mapping of the ModuleTarget value, e.g the entry for macox-x64 would be: >> >> macos-amd64.endianness = little > > Hello Mandy, Alan, Jim, > > I've updated this PR to take into account these suggestions. I went ahead with what Mandy suggested and enhanced the existing (internal) `jdk.tools.jlink.internal.Platform` `record`to additional parse these architectures. It was anyway doing it for a select few. > > In addition to that, I also moved the architecture to endianness mapping into this `Platform` class itself. I followed Jim's suggestion to move the mapping out of the code. The `Platform` code now reads this from a `endianness.properties` file which is an internal resource of the `jdk.jlink` module. However, I'm having second thoughts about this part. I'm guessing that when Jim suggested moving this to a resource, it was probably because the code resided within the `JLinkTask` class. Now that I've moved this to an existing `Platform` class which is solely meant for things like these, I feel that we could probably just hard code these architecture to endianness mapping within this class itself, instead of reading it from a properties file. I'm looking for some inputs on what you all think would be the best way to proceed. > > Alan, as for the `osname-arch=little/big` vs `arch=little/big` mapping style, I decided to use the `arch=little/big` and let the Platform class parse the architecture out of the string in the `ModuleTarget`. I did it for a couple of reasons: > > 1. The `Platform` class already has the necessary logic to do that, plus it has to do that anyway (for us to implement the suggestion that Mandy noted about using this in `DefaultImageBuilder`) > > 2. As far as I could see, the OS name shouldn't play any role in the endianness, so leaving that out felt easier to deal with since we wouldn't have to think of what OS name, arch combinations would be valid. > > If you or others feel that it's better to stick with the `osname-arch=little/big` approach, instead of this one, please do let me know and I'll go ahead and do that change. > If you or others feel that it's better to stick with the osname-arch=little/big approach, instead of this one, please do let me know and I'll go ahead and do that change.that out felt easier to deal with since we wouldn't have to think of what OS name, arch combinations would be valid. My preference would be something like target.properties so we have one place with the properties for target platform when cross linking. ${ModuleTarget}.${property} could work as keys. At some point we will need to extend or replace the ModuleTarget as it too basic to describe the target platform, that's why I was hoping to avoid parsing it here. jlink cannot be reliably used to cross link to target a different JDK release. Reasons include changes to the run-time image, jimage changes, and plugins that are deeply tied to java.base or other modules. I mention this because JDK 11 was the last release to build solaris-sparcv9, so I think you can this and several others from the properties file. Probably just stick the the builds that are possible in the main line. ------------- PR: https://git.openjdk.org/jdk/pull/11943 From alanb at openjdk.org Sun Mar 19 09:12:21 2023 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 19 Mar 2023 09:12:21 GMT Subject: RFR: JDK-8303742: CompletableFuture.orTimeout leaks if the future completes exceptionally [v6] In-Reply-To: References: Message-ID: On Fri, 17 Mar 2023 09:52:51 GMT, Viktor Klang wrote: >> Addresses the situation where exceptional completion of `orTimeout`:ed CompletableFutures wouldn't cancel the timeout task which could lead to memory leaks if done frequently enough with long enough timeout durations. >> >> Fix discussed with @DougLea > > Viktor Klang has updated the pull request incrementally with one additional commit since the last revision: > > Reformatting the while-body to be more legible in diffs, and inlining the counter incrementation. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/13059 From duke at openjdk.org Sun Mar 19 09:55:10 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Sun, 19 Mar 2023 09:55:10 GMT Subject: RFR: 8205129: Remove java.lang.Compiler Message-ID: Please help review this PR which suggests we remove the class `java.lang.Compiler`. The class seems non-functional for a decade, and was terminally deprecated in Java 9. Time has come to let it go. ------------- Commit messages: - Remove the deprecated class java.lang.Compiler Changes: https://git.openjdk.org/jdk/pull/13092/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13092&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8205129 Stats: 105 lines in 1 file changed: 0 ins; 105 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13092.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13092/head:pull/13092 PR: https://git.openjdk.org/jdk/pull/13092 From duke at openjdk.org Sun Mar 19 09:57:09 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Sun, 19 Mar 2023 09:57:09 GMT Subject: RFR: 8303923: ZipOutStream::putEntry should include an apiNote to indicate that the STORED compression method should be used when writing directory entries Message-ID: ZipOutputStream currently writes directory entries using the DEFLATED compression method. This does not strictly comply with the APPNOTE.TXT specification and is also about 10x slower than using the STORED compression method. Because of these concerns, `ZipOutputStream.putNextEntry` should be updated with an `@apiNote` recommending the use of the STORED compression method for directory entries. Suggested CSR in the first comment. ------------- Commit messages: - For consistency with other Javadocs, use 'CRC-32' instead of 'crc' when referring to the checksum - Generalize the ZipEntry using '...' instead of new ZipEntry("dir/") - Add @apiNote describing that directory entries should use the STORED compression method and have size and crc set to 0. Changes: https://git.openjdk.org/jdk/pull/12899/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12899&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303923 Stats: 16 lines in 1 file changed: 16 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12899.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12899/head:pull/12899 PR: https://git.openjdk.org/jdk/pull/12899 From duke at openjdk.org Sun Mar 19 09:57:10 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Sun, 19 Mar 2023 09:57:10 GMT Subject: RFR: 8303923: ZipOutStream::putEntry should include an apiNote to indicate that the STORED compression method should be used when writing directory entries In-Reply-To: References: Message-ID: On Tue, 7 Mar 2023 07:46:25 GMT, Eirik Bjorsnos wrote: > ZipOutputStream currently writes directory entries using the DEFLATED compression method. This does not strictly comply with the APPNOTE.TXT specification and is also about 10x slower than using the STORED compression method. > > Because of these concerns, `ZipOutputStream.putNextEntry` should be updated with an `@apiNote` recommending > the use of the STORED compression method for directory entries. > > Suggested CSR in the first comment. Suggested CSR: ### Compatibility kind none ### Compatibility risk minimal ### Compatibility description This is a documentation-only change ### Summary Add an `@apiNote`to `ZipOutputStream.putNextEntry` recommending that directory entries should be added using the `STORED` compression method. ### Problem ZipOutputStream currently writes directory entries using the default DEFLATE method. This causes file data for a two-byte 'final empty' DEFLATE block to be written, followed by a 16-byte data descriptor. This is in violation of the APPNOTE.txt specification, which mandates that directory entries `MUST NOT` have file data: 4.3.8 File data Immediately following the local header for a file SHOULD be placed the compressed or stored data for the file. If the file is encrypted, the encryption header for the file SHOULD be placed after the local header and before the file data. The series of [local file header][encryption header] [file data][data descriptor] repeats for each file in the .ZIP archive. Zero-byte files, directories, and other file types that contain no content MUST NOT include file data. ``` Additionally, benchmarks show that the writing of these empty DEFLATED directory entries are ~10X slower compared to an empty STORED entry. While the `jar` command uses the STORED method for directory entries, the DEFLATE method still seems to be prevalent: An analysis of the 109 dependency jars of the Spring Petclinic project shows that 65 files had DEFLATE directories while 34 files has STORED directories. ### Solution Add an `@apiNote` to `ZipOutputStream.putNextEntry` recommending the use of the?STORED compression method for directory entries. The note should include a snippet which shows the recommended configuration of a directory `ZipEntry`. (As an alternative solution, `putNextEntry` could be updated to change the default compression method to STORED for directory entires. This was deemed as having a too high risk, since users may be depending of the ability to attach arbitrary data to directory entries.) ### Specification - Add the following `@apiNote` to `ZipOutputStream.putNextEntry` Index: src/java.base/share/classes/java/util/zip/ZipOutputStream.java IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8 =================================================================== diff --git a/src/java.base/share/classes/java/util/zip/ZipOutputStream.java b/src/java.base/share/classes/java/util/zip/ZipOutputStream.java --- a/src/java.base/share/classes/java/util/zip/ZipOutputStream.java (revision f2b03f9a2c0fca853211e41a1ddf46195dd56698) +++ b/src/java.base/share/classes/java/util/zip/ZipOutputStream.java (revision f57735cf134469b49cd19472680aee778c245771) @@ -191,6 +191,22 @@ *

* The current time will be used if the entry has no set modification time. * + * @apiNote When writing a directory entry, the STORED compression method + * should be used and the size and CRC-32 values should be set to 0: + * + * {@snippet lang="java" : + * ZipEntry e = ...; + * if (e.isDirectory()) { + * e.setMethod(ZipEntry.STORED); + * e.setSize(0); + * e.setCrc(0); + * } + * stream.putNextEntry(e); + * } + * + * This ensures strict compliance with the ZIP specification and + * allows optimal performance when processing directory entries. + * * @param e the ZIP entry to be written * @throws ZipException if a ZIP format error has occurred * @throws IOException if an I/O error has occurred ### Here's what the generated API note looks like: image Looking for reviewers for this CSR which adds an `@apiNote` recommending the use of the STORED compression method when writing directory entries in ZipOutputStream: https://bugs.openjdk.org/browse/JDK-8303925 The CSR was initially written by me, then edited by Lance. ------------- PR: https://git.openjdk.org/jdk/pull/12899 From duke at openjdk.org Sun Mar 19 10:02:17 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Sun, 19 Mar 2023 10:02:17 GMT Subject: RFR: 8205129: Remove java.lang.Compiler In-Reply-To: References: Message-ID: <4i8WgY38HfIPjy1xpW-vF3lcRCKifGRT1brkrrgPUxQ=.1656c321-d140-4482-bdef-470f83e0b4e6@github.com> On Sun, 19 Mar 2023 09:01:26 GMT, Eirik Bjorsnos wrote: > Please help review this PR which suggests we remove the class `java.lang.Compiler`. The class seems non-functional for a decade, and was terminally deprecated in Java 9. Time has come to let it go. The actual change in this PR seems trivial (simply removes a file), so I guess it is more useful to review the CSR and the release note: https://bugs.openjdk.org/browse/JDK-8304458 (CSR) https://bugs.openjdk.org/browse/JDK-8304459 (Release note) ------------- PR: https://git.openjdk.org/jdk/pull/13092 From qamai at openjdk.org Sun Mar 19 13:10:09 2023 From: qamai at openjdk.org (Quan Anh Mai) Date: Sun, 19 Mar 2023 13:10:09 GMT Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation Message-ID: Hi, This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, VectorShuffle is stored as a byte array, and would be expanded upon usage. This poses several drawbacks: 1. Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically. 2. Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations. 3. Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler. 4. Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones. Upon these changes, a `rearrange` can emit more efficient code: var species = IntVector.SPECIES_128; var v1 = IntVector.fromArray(species, SRC1, 0); var v2 = IntVector.fromArray(species, SRC2, 0); v1.rearrange(v2.toShuffle()).intoArray(DST, 0); Before: movabs $0x751589fa8,%r10 ; {oop([I{0x0000000751589fa8})} vmovdqu 0x10(%r10),%xmm2 movabs $0x7515a0d08,%r10 ; {oop([I{0x00000007515a0d08})} vmovdqu 0x10(%r10),%xmm1 movabs $0x75158afb8,%r10 ; {oop([I{0x000000075158afb8})} vmovdqu 0x10(%r10),%xmm0 vpand -0xddc12(%rip),%xmm0,%xmm0 # Stub::vector_int_to_byte_mask ; {external_word} vpackusdw %xmm0,%xmm0,%xmm0 vpackuswb %xmm0,%xmm0,%xmm0 vpmovsxbd %xmm0,%xmm3 vpcmpgtd %xmm3,%xmm1,%xmm3 vtestps %xmm3,%xmm3 jne 0x00007fc2acb4e0d8 vpmovzxbd %xmm0,%xmm0 vpermd %ymm2,%ymm0,%ymm0 movabs $0x751588f98,%r10 ; {oop([I{0x0000000751588f98})} vmovdqu %xmm0,0x10(%r10) After: movabs $0x751589c78,%r10 ; {oop([I{0x0000000751589c78})} vmovdqu 0x10(%r10),%xmm1 movabs $0x75158ac88,%r10 ; {oop([I{0x000000075158ac88})} vmovdqu 0x10(%r10),%xmm2 vpxor %xmm0,%xmm0,%xmm0 vpcmpgtd %xmm2,%xmm0,%xmm3 vtestps %xmm3,%xmm3 jne 0x00007fa818b27cb1 vpermd %ymm1,%ymm2,%ymm0 movabs $0x751588c68,%r10 ; {oop([I{0x0000000751588c68})} vmovdqu %xmm0,0x10(%r10) Please take a look and leave reviews. Thanks a lot. ------------- Commit messages: - fix internal types, clean up - optimise laneIsValid - Merge branch 'master' into shufflerefactor - small beautifications - other architecture - fix mismatched fp vector payload types - draft Changes: https://git.openjdk.org/jdk/pull/13093/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13093&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304450 Stats: 4440 lines in 62 files changed: 2567 ins; 651 del; 1222 mod Patch: https://git.openjdk.org/jdk/pull/13093.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13093/head:pull/13093 PR: https://git.openjdk.org/jdk/pull/13093 From lancea at openjdk.org Sun Mar 19 14:05:19 2023 From: lancea at openjdk.org (Lance Andersen) Date: Sun, 19 Mar 2023 14:05:19 GMT Subject: RFR: 8303923: ZipOutStream::putEntry should include an apiNote to indicate that the STORED compression method should be used when writing directory entries In-Reply-To: References: Message-ID: On Tue, 7 Mar 2023 07:46:25 GMT, Eirik Bjorsnos wrote: > ZipOutputStream currently writes directory entries using the DEFLATED compression method. This does not strictly comply with the APPNOTE.TXT specification and is also about 10x slower than using the STORED compression method. > > Because of these concerns, `ZipOutputStream.putNextEntry` should be updated with an `@apiNote` recommending > the use of the STORED compression method for directory entries. > > Suggested CSR in the first comment. Hi Eirik, Thank you for starting the review of your proposed clarification. A couple of minor comments. Also the copyright should be changed to 2023 with your next update. src/java.base/share/classes/java/util/zip/ZipOutputStream.java line 198: > 196: * > 197: * {@snippet lang="java" : > 198: * ZipEntry e = ...; Please make this an actual value as the snippet should be valid code src/java.base/share/classes/java/util/zip/ZipOutputStream.java line 208: > 206: * > 207: * This ensures strict compliance with the ZIP specification and > 208: * allows optimal performance when processing directory entries. I think we can remove at least the first part of the sentence regarding "strict compliance" as "file data" can be interpreted as the contents of the file as 4.1.3 of the App.Note allows for the default compression method to be DEFAULT. The intent of the apiNote is to remind developers that the use of the STORED compression method is preferred and may be more optimal ------------- PR: https://git.openjdk.org/jdk/pull/12899 From duke at openjdk.org Sun Mar 19 14:22:21 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Sun, 19 Mar 2023 14:22:21 GMT Subject: RFR: 8303923: ZipOutStream::putEntry should include an apiNote to indicate that the STORED compression method should be used when writing directory entries In-Reply-To: References: Message-ID: On Sun, 19 Mar 2023 13:50:40 GMT, Lance Andersen wrote: >> ZipOutputStream currently writes directory entries using the DEFLATED compression method. This does not strictly comply with the APPNOTE.TXT specification and is also about 10x slower than using the STORED compression method. >> >> Because of these concerns, `ZipOutputStream.putNextEntry` should be updated with an `@apiNote` recommending >> the use of the STORED compression method for directory entries. >> >> Suggested CSR in the first comment. > > src/java.base/share/classes/java/util/zip/ZipOutputStream.java line 198: > >> 196: * >> 197: * {@snippet lang="java" : >> 198: * ZipEntry e = ...; > > Please make this an actual value as the snippet should be valid code I initially used a directory as an example: `ZipEntry e = new ZipEntry("dir/")`, but then @AlanBateman suggested to make it more generic: https://mail.openjdk.org/pipermail/core-libs-dev/2023-March/101686.html > For the note then you might want to change it to "ZipEntry e = ..." because the reader see the trailing slash after dir so it is obviously a directory. I agree valid code would be preferrable. Not sure how to make it valid though, since the `isDirectory` part suggests the path is unknown. Could an undefined local variable work? ZipEntry e = new ZipEntry(name); Or perhaps with a comment: ZipEntry e = new ZipEntry(name); // name could be a file or directory ------------- PR: https://git.openjdk.org/jdk/pull/12899 From alanb at openjdk.org Sun Mar 19 14:41:19 2023 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 19 Mar 2023 14:41:19 GMT Subject: RFR: 8205129: Remove java.lang.Compiler In-Reply-To: References: Message-ID: On Sun, 19 Mar 2023 09:01:26 GMT, Eirik Bjorsnos wrote: > Please help review this PR which suggests we remove the class `java.lang.Compiler`. The class seems non-functional for a decade, and was terminally deprecated in Java 9. Time has come to let it go. For reference, here's the discussion from 2016 when it was proposed to deprecate j.l.Compiler, for removal. Tim Ellison from IBM engaged in that discussion as one of the replies asked about applications running on the J9 VM using this API. https://mail.openjdk.org/pipermail/core-libs-dev/2016-September/043365.html The discussion is also a reminder that -Djava.compiler=NONE is the equivalent of -Xint, I thought that system property was dropped a long time ago. ------------- PR: https://git.openjdk.org/jdk/pull/13092 From duke at openjdk.org Sun Mar 19 14:46:44 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Sun, 19 Mar 2023 14:46:44 GMT Subject: RFR: 8303923: ZipOutStream::putEntry should include an apiNote to indicate that the STORED compression method should be used when writing directory entries [v2] In-Reply-To: References: Message-ID: > ZipOutputStream currently writes directory entries using the DEFLATED compression method. This does not strictly comply with the APPNOTE.TXT specification and is also about 10x slower than using the STORED compression method. > > Because of these concerns, `ZipOutputStream.putNextEntry` should be updated with an `@apiNote` recommending > the use of the STORED compression method for directory entries. > > Suggested CSR in the first comment. Eirik Bjorsnos has updated the pull request incrementally with two additional commits since the last revision: - Make snippet syntactically valid - Update copyright year ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12899/files - new: https://git.openjdk.org/jdk/pull/12899/files/f57735cf..864a0887 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12899&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12899&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/12899.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12899/head:pull/12899 PR: https://git.openjdk.org/jdk/pull/12899 From duke at openjdk.org Sun Mar 19 14:46:44 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Sun, 19 Mar 2023 14:46:44 GMT Subject: RFR: 8303923: ZipOutStream::putEntry should include an apiNote to indicate that the STORED compression method should be used when writing directory entries [v2] In-Reply-To: References: Message-ID: On Sun, 19 Mar 2023 14:02:18 GMT, Lance Andersen wrote: > Also the copyright should be changed to 2023 with your next update. Imagine if jcheck could remind people of this, reviewers would be out of a job :-) > src/java.base/share/classes/java/util/zip/ZipOutputStream.java line 208: > >> 206: * >> 207: * This ensures strict compliance with the ZIP specification and >> 208: * allows optimal performance when processing directory entries. > > I think we can remove at least the first part of the sentence regarding "strict compliance" as "file data" can be interpreted as the contents of the file as 4.1.3 of the App.Note allows for the default compression method to be DEFAULT. The intent of the apiNote is to remind developers that the use of the STORED compression method is preferred and may be more optimal 4.3.8 File data Immediately following the local header for a file SHOULD be placed the compressed or stored data for the file. If the file is encrypted, the encryption header for the file SHOULD be placed after the local header and before the file data. The series of [local file header][encryption header] [file data][data descriptor] repeats for each file in the .ZIP archive. Zero-byte files, directories, and other file types that contain no content MUST NOT include file data. My interpretation of section 4.3.8 is that 'file data' in the last sentence of this section refers to what is defined in the first sentence: 'Immediately following the local header for a file SHOULD be placed the compressed or stored data for the file.' While I'm not sure I fully understand you interpretation, it seems you are saying that a DEFLATED entry with the two-byte 'empty final' DEFLATE blocks does not have file data? (Because it is just an encoding of 'no content')? In any case, I'm happy to remove this since as it stands it is a bit vague and as we've seen open for interpretation. ------------- PR: https://git.openjdk.org/jdk/pull/12899 From duke at openjdk.org Sun Mar 19 14:46:45 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Sun, 19 Mar 2023 14:46:45 GMT Subject: RFR: 8303923: ZipOutStream::putEntry should include an apiNote to indicate that the STORED compression method should be used when writing directory entries [v2] In-Reply-To: References: Message-ID: On Sun, 19 Mar 2023 14:19:10 GMT, Eirik Bjorsnos wrote: >> src/java.base/share/classes/java/util/zip/ZipOutputStream.java line 198: >> >>> 196: * >>> 197: * {@snippet lang="java" : >>> 198: * ZipEntry e = ...; >> >> Please make this an actual value as the snippet should be valid code > > I initially used a directory as an example: `ZipEntry e = new ZipEntry("dir/")`, but then @AlanBateman suggested to make it more generic: > > https://mail.openjdk.org/pipermail/core-libs-dev/2023-March/101686.html > >> For the note then you might want to change it to "ZipEntry e = ..." because the reader see the trailing slash after dir so it is obviously a directory. > > I agree valid code would be preferrable. Not sure how to make it valid though, since the `isDirectory` part suggests the path is unknown. Could an undefined local variable work? > > > ZipEntry e = new ZipEntry(name); > > > Or perhaps with a comment: > > > ZipEntry e = new ZipEntry(name); // name could be a file or directory I opted for `ZipEntry e = new ZipEntry(entryName)` for now. ------------- PR: https://git.openjdk.org/jdk/pull/12899 From duke at openjdk.org Sun Mar 19 14:50:41 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Sun, 19 Mar 2023 14:50:41 GMT Subject: RFR: 8303923: ZipOutStream::putEntry should include an apiNote to indicate that the STORED compression method should be used when writing directory entries [v3] In-Reply-To: References: Message-ID: > ZipOutputStream currently writes directory entries using the DEFLATED compression method. This does not strictly comply with the APPNOTE.TXT specification and is also about 10x slower than using the STORED compression method. > > Because of these concerns, `ZipOutputStream.putNextEntry` should be updated with an `@apiNote` recommending > the use of the STORED compression method for directory entries. > > Suggested CSR in the first comment. Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision: Remove speculation that using DEFLATED for directory entries is not in strict compliance with APPNOTE.txt ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12899/files - new: https://git.openjdk.org/jdk/pull/12899/files/864a0887..24d2afc2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12899&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12899&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/12899.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12899/head:pull/12899 PR: https://git.openjdk.org/jdk/pull/12899 From duke at openjdk.org Sun Mar 19 15:13:21 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Sun, 19 Mar 2023 15:13:21 GMT Subject: RFR: 8205129: Remove java.lang.Compiler In-Reply-To: References: Message-ID: On Sun, 19 Mar 2023 14:38:55 GMT, Alan Bateman wrote: > For reference, here's the discussion from 2016 when it was proposed to deprecate j.l.Compiler, for removal. Tim Ellison from IBM engaged in that discussion as one of the replies asked about applications running on the J9 VM using this API. So it seems in 2016 IBM in was ok with an eventual removal of this class ("these APIs can be removed without grief") However, I see that later in the thread Azul Systems raised concerns about a removal: https://mail.openjdk.org/pipermail/core-libs-dev/2016-September/043585.html https://mail.openjdk.org/pipermail/core-libs-dev/2016-September/043646.html So to summarize: java.lang.Compiler.command is a key API for functionality that we currently use, and that we leverage and need to remain in the common (non platform specific) name space. While we can live with deprecation as part of an API cleanup, this cleanup should result in a suitable replacement API, and we would want a non-platform-specific-namespace replacement to exist before the current API is actually removed at any future date. Would be good if someone from Azul Systems could give a 2023 assessment on removing this class? > The discussion is also a reminder that -Djava.compiler=NONE is the equivalent of -Xint, I thought that system property was dropped a long time ago. It exists in System.getProperties Javadocs at least: * {@systemProperty java.compiler} * Name of JIT compiler to use Was this just for reference or are you suggesting that this PR is blocked by the 'java.compiler' somehow? ------------- PR: https://git.openjdk.org/jdk/pull/13092 From duke at openjdk.org Sun Mar 19 15:23:19 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Sun, 19 Mar 2023 15:23:19 GMT Subject: RFR: 8205129: Remove java.lang.Compiler In-Reply-To: References: Message-ID: On Sun, 19 Mar 2023 15:08:58 GMT, Eirik Bjorsnos wrote: > The discussion is also a reminder that -Djava.compiler=NONE is the equivalent of -Xint, I thought that system property was dropped a long time ago. https://bugs.openjdk.org/browse/JDK-8041676 suggests to deprecate it, but from the last comment we still seem to be waiting for @dholmes-ora to get back from vacation on the 22nd :-) ------------- PR: https://git.openjdk.org/jdk/pull/13092 From lmesnik at openjdk.org Sun Mar 19 16:52:20 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Sun, 19 Mar 2023 16:52:20 GMT Subject: RFR: 8304303: implement VirtualThread class notifyJvmti methods as C2 intrinsics [v4] In-Reply-To: <-kZ3wf7zOt0zABMfgibzmuT5VHuROnTA92lkqbhitbE=.fd934229-b4a6-469a-9c4b-ac9f26efd80f@github.com> References: <-Pt3zLSu1Y2GYeM8XEivglUyDVXlAqMIA42-_zEnHlo=.7dd40f19-160a-4f11-8702-99c69a9b9923@github.com> <-kZ3wf7zOt0zABMfgibzmuT5VHuROnTA92lkqbhitbE=.fd934229-b4a6-469a-9c4b-ac9f26efd80f@github.com> Message-ID: On Fri, 17 Mar 2023 10:31:46 GMT, Serguei Spitsyn wrote: >> This is needed for future performance/scalability improvements in JVMTI support of virtual threads. >> The update includes the following: >> >> 1. Refactored the `VirtualThread` native methods: >> `notifyJvmtiMountBegin` and `notifyJvmtiMountEnd` => `notifyJvmtiMount` >> `notifyJvmtiUnmountBegin` and `notifyJvmtiUnmountEnd` => `notifyJvmtiUnmount` >> 2. Still useful implementation of old native methods is moved from `jvm.cpp` to `jvmtiThreadState.cpp`: >> `JVM_VirtualThreadMountStart` => `VTMS_mount_begin` >> `JVM_VirtualThreadMountEnd` => `VTMS_mount_end` >> `JVM_VirtualThreadUnmountStart` = > `VTMS_unmount_begin` >> `JVM_VirtualThreadUnmountEnd` => `VTMS_mount_end` >> 3. Intrinsified the `VirtualThread` native methods: `notifyJvmtiMount`, `notifyJvmtiUnmount`, `notifyJvmtiHideFrames`. >> 4. Removed the`VirtualThread` static boolean state variable `notifyJvmtiEvents` and its support in `javaClasses`. >> 5. Added static boolean state variable `_VTMS_notify_jvmti_events` to the jvmtiVTMSTransitionDisabler class as a replacement of the `VirtualThread` `notifyJvmtiEvents` variable. >> >> Implementing the same methods as C1 intrinsics can be needed in the future but is a low priority for now. >> >> Testing: >> - Ran mach5 tiers 1-6. No regressions were found. > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > minor tweaks in intrisics implementation I haven't reviewed C2 changes, all other changes look good to me. ------------- Marked as reviewed by lmesnik (Reviewer). PR: https://git.openjdk.org/jdk/pull/13054 From duke at openjdk.org Sun Mar 19 17:28:19 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Sun, 19 Mar 2023 17:28:19 GMT Subject: RFR: 8303923: ZipOutStream::putEntry should include an apiNote to indicate that the STORED compression method should be used when writing directory entries [v3] In-Reply-To: References: Message-ID: On Sun, 19 Mar 2023 14:38:46 GMT, Eirik Bjorsnos wrote: >> src/java.base/share/classes/java/util/zip/ZipOutputStream.java line 208: >> >>> 206: * >>> 207: * This ensures strict compliance with the ZIP specification and >>> 208: * allows optimal performance when processing directory entries. >> >> I think we can remove at least the first part of the sentence regarding "strict compliance" as "file data" can be interpreted as the contents of the file as 4.1.3 of the App.Note allows for the default compression method to be DEFAULT. The intent of the apiNote is to remind developers that the use of the STORED compression method is preferred and may be more optimal > > 4.3.8 File data > > Immediately following the local header for a file > SHOULD be placed the compressed or stored data for the file. > If the file is encrypted, the encryption header for the file > SHOULD be placed after the local header and before the file > data. The series of [local file header][encryption header] > [file data][data descriptor] repeats for each file in the > .ZIP archive. > > Zero-byte files, directories, and other file types that > contain no content MUST NOT include file data. > > > > My interpretation of section 4.3.8 is that 'file data' in the last sentence of this section refers to what is defined in the first sentence: 'Immediately following the local header for a file SHOULD be placed the compressed or stored data for the file.' > > While I'm not sure I fully understand you interpretation, it seems you are saying that a DEFLATED entry with the two-byte 'empty final' DEFLATE blocks does not have file data? (Because it is just an encoding of 'no content')? > > In any case, I'm happy to remove this since as it stands it is a bit vague and as we've seen open for interpretation. > I think we can remove at least the first part of the sentence regarding "strict compliance" as "file data" can be interpreted as the contents of the file as 4.1.3 of the App.Note allows for the default compression method to be DEFAULT. 4.1.3 Data compression MAY be used to reduce the size of files placed into a ZIP file, but is not required. This format supports the use of multiple data compression algorithms. When compression is used, one of the documented compression algorithms MUST be used. Implementors are advised to experiment with their data to determine which of the available algorithms provides the best compression for their needs. Compression method 8 (Deflate) is the method used by default by most ZIP compatible application programs. I think we read 4.1.3 slightly differently. I read it as saying that WHEN data compression is used, 8 (Deflate) is the method used by default by most ZIP compatible application programs. STORED entries are not using data compression, and as such do not have any 'default compression method'. 4.1.3 does not apply to them. ------------- PR: https://git.openjdk.org/jdk/pull/12899 From alanb at openjdk.org Sun Mar 19 19:02:18 2023 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 19 Mar 2023 19:02:18 GMT Subject: RFR: 8205129: Remove java.lang.Compiler In-Reply-To: References: Message-ID: On Sun, 19 Mar 2023 09:01:26 GMT, Eirik Bjorsnos wrote: > Please help review this PR which suggests we remove the class `java.lang.Compiler`. The class seems non-functional for a decade, and was terminally deprecated in Java 9. Time has come to let it go. A search of 3M classes in 130k artifacts found just 8 references to this class. 6 of the 8 are versions of the same thing seem to be an off-label usage in a class named net.openhft.chronicle.core.Jvm where it calls Compiler.enable() instead of Thread.onSpinWait on older JDK releases. I remember the Azul mails from 2016 on this topic but I don't think they provided sufficient insight why an application would using this barely documented API. Anything relying on these methods to do something is probably very tied to the VM implementation. -Djava.compiler=NONE pre-dates "full speed debugging" and I would think all traces can be removed now. Yes, there is still a reference to this system property in System.getProperties that could be looked at too. All of these things are low priority. The good thing about removing java.lang.Compiler is that is avoids new developers from stumbling on it. ------------- PR: https://git.openjdk.org/jdk/pull/13092 From qamai at openjdk.org Sun Mar 19 19:38:04 2023 From: qamai at openjdk.org (Quan Anh Mai) Date: Sun, 19 Mar 2023 19:38:04 GMT Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation [v2] In-Reply-To: References: Message-ID: > Hi, > > This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, VectorShuffle is stored as a byte array, and would be expanded upon usage. This poses several drawbacks: > > 1. Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically. > 2. Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations. > 3. Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler. > 4. Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones. > > Upon these changes, a `rearrange` can emit more efficient code: > > var species = IntVector.SPECIES_128; > var v1 = IntVector.fromArray(species, SRC1, 0); > var v2 = IntVector.fromArray(species, SRC2, 0); > v1.rearrange(v2.toShuffle()).intoArray(DST, 0); > > Before: > movabs $0x751589fa8,%r10 ; {oop([I{0x0000000751589fa8})} > vmovdqu 0x10(%r10),%xmm2 > movabs $0x7515a0d08,%r10 ; {oop([I{0x00000007515a0d08})} > vmovdqu 0x10(%r10),%xmm1 > movabs $0x75158afb8,%r10 ; {oop([I{0x000000075158afb8})} > vmovdqu 0x10(%r10),%xmm0 > vpand -0xddc12(%rip),%xmm0,%xmm0 # Stub::vector_int_to_byte_mask > ; {external_word} > vpackusdw %xmm0,%xmm0,%xmm0 > vpackuswb %xmm0,%xmm0,%xmm0 > vpmovsxbd %xmm0,%xmm3 > vpcmpgtd %xmm3,%xmm1,%xmm3 > vtestps %xmm3,%xmm3 > jne 0x00007fc2acb4e0d8 > vpmovzxbd %xmm0,%xmm0 > vpermd %ymm2,%ymm0,%ymm0 > movabs $0x751588f98,%r10 ; {oop([I{0x0000000751588f98})} > vmovdqu %xmm0,0x10(%r10) > > After: > movabs $0x751589c78,%r10 ; {oop([I{0x0000000751589c78})} > vmovdqu 0x10(%r10),%xmm1 > movabs $0x75158ac88,%r10 ; {oop([I{0x000000075158ac88})} > vmovdqu 0x10(%r10),%xmm2 > vpxor %xmm0,%xmm0,%xmm0 > vpcmpgtd %xmm2,%xmm0,%xmm3 > vtestps %xmm3,%xmm3 > jne 0x00007fa818b27cb1 > vpermd %ymm1,%ymm2,%ymm0 > movabs $0x751588c68,%r10 ; {oop([I{0x0000000751588c68})} > vmovdqu %xmm0,0x10(%r10) > > Please take a look and leave reviews. Thanks a lot. Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: fix Matcher::vector_needs_load_shuffle ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13093/files - new: https://git.openjdk.org/jdk/pull/13093/files/7acf928d..060554a9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13093&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13093&range=00-01 Stats: 9 lines in 1 file changed: 4 ins; 3 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13093.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13093/head:pull/13093 PR: https://git.openjdk.org/jdk/pull/13093 From lmesnik at openjdk.org Mon Mar 20 01:37:23 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 20 Mar 2023 01:37:23 GMT Subject: RFR: JDK-8304163: Move jdk.internal.module.ModuleInfoWriter to the test library [v2] In-Reply-To: References: Message-ID: On Sat, 18 Mar 2023 19:14:09 GMT, Mandy Chung wrote: >> `ModuleInfoWriter` is not used by the runtime. Move it to the test library as `jdk.test.lib.util.ModuleInfoWriter`. The tests are updated to use the test library instead. `ModuleInfoWriter` depends on `jdk.internal.module` types and the Classfile API. Hence `@modules java.base/jdk.internal.classfile` and other classfile subpackages are added. > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > move @library after @modules per the recommended ordering Changes requested by lmesnik (Reviewer). test/jdk/java/lang/ModuleTests/AnnotationsTest.java line 61: > 59: * java.base/jdk.internal.module > 60: * @library /test/lib > 61: * @build jdk.test.lib.util.ModuleInfoWriter You don't need to build library classes explicitly. I think @library /test/lib it enough. ------------- PR: https://git.openjdk.org/jdk/pull/13085 From dholmes at openjdk.org Mon Mar 20 02:04:19 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 20 Mar 2023 02:04:19 GMT Subject: RFR: 8205129: Remove java.lang.Compiler In-Reply-To: References: Message-ID: On Sun, 19 Mar 2023 15:20:33 GMT, Eirik Bjorsnos wrote: > > The discussion is also a reminder that -Djava.compiler=NONE is the equivalent of -Xint, I thought that system property was dropped a long time ago. > > https://bugs.openjdk.org/browse/JDK-8041676 suggests to deprecate it, but from the last comment we still seem to be waiting for @dholmes-ora to get back from vacation on the 22nd :-) I guess I never heard back from @stuart-marks . :( I think [JDK-8041676](https://bugs.openjdk.org/browse/JDK-8041676) needs to be resolved along side this issue. ------------- PR: https://git.openjdk.org/jdk/pull/13092 From jpai at openjdk.org Mon Mar 20 07:00:24 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 20 Mar 2023 07:00:24 GMT Subject: RFR: JDK-8304163: Move jdk.internal.module.ModuleInfoWriter to the test library [v2] In-Reply-To: References: Message-ID: On Mon, 20 Mar 2023 01:34:11 GMT, Leonid Mesnik wrote: >> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> move @library after @modules per the recommended ordering > > test/jdk/java/lang/ModuleTests/AnnotationsTest.java line 61: > >> 59: * java.base/jdk.internal.module >> 60: * @library /test/lib >> 61: * @build jdk.test.lib.util.ModuleInfoWriter > > You don't need to build library classes explicitly. I think @library /test/lib it enough. Hello @lmesnik, on the contrary, these build directives are recommended (and based on some of the issues we have encountered, are in fact necessary). The jtreg documentation has this to say https://openjdk.org/jtreg/tag-spec.html: > In general, classes in library directories are not automatically compiled as part of a compilation command explicitly naming the source files containing those classes. A test that relies upon library classes should contain appropriate @build directives to ensure that the classes will be compiled. It is strongly recommended that tests do not rely on the use of implicit compilation by the Java compiler. Such an approach is generally fragile, and may lead to incomplete recompilation when a test or library code has been modified. ------------- PR: https://git.openjdk.org/jdk/pull/13085 From sspitsyn at openjdk.org Mon Mar 20 07:18:24 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 20 Mar 2023 07:18:24 GMT Subject: RFR: 8304303: implement VirtualThread class notifyJvmti methods as C2 intrinsics [v4] In-Reply-To: <-OJbhkKU3EtSS8E31eEd62h3-x5Szpl_Hk0apm1a6aQ=.687c660f-bc13-41cd-bc63-c59ca60300f0@github.com> References: <-Pt3zLSu1Y2GYeM8XEivglUyDVXlAqMIA42-_zEnHlo=.7dd40f19-160a-4f11-8702-99c69a9b9923@github.com> <-kZ3wf7zOt0zABMfgibzmuT5VHuROnTA92lkqbhitbE=.fd934229-b4a6-469a-9c4b-ac9f26efd80f@github.com> <-OJbhkKU3EtSS8E31eEd62h3-x5Szpl_Hk0apm1a6aQ=.687c660f-bc13-41cd-bc63-c59ca60300f0@github.com> Message-ID: On Sat, 18 Mar 2023 11:24:47 GMT, Alan Bateman wrote: > The most important case is when there is no JVMTI env. If I read the changes correctly, the overhead for park/continue changes from one volatile-read (notifyJvmtiEvents) to two plain-writes (JavaThread::_is_in_VTMS_transition). > > If a JVMTI env has been created then there is no benefit for the moment as there is still a call into the runtime to interact with JvmtiVTMSTransitionDisabler. So I think you are saying that is for follow-on PRs. @AlanBateman Yes, your conclusion is correct. ------------- PR: https://git.openjdk.org/jdk/pull/13054 From sspitsyn at openjdk.org Mon Mar 20 07:18:27 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 20 Mar 2023 07:18:27 GMT Subject: RFR: 8304303: implement VirtualThread class notifyJvmti methods as C2 intrinsics [v4] In-Reply-To: <-kZ3wf7zOt0zABMfgibzmuT5VHuROnTA92lkqbhitbE=.fd934229-b4a6-469a-9c4b-ac9f26efd80f@github.com> References: <-Pt3zLSu1Y2GYeM8XEivglUyDVXlAqMIA42-_zEnHlo=.7dd40f19-160a-4f11-8702-99c69a9b9923@github.com> <-kZ3wf7zOt0zABMfgibzmuT5VHuROnTA92lkqbhitbE=.fd934229-b4a6-469a-9c4b-ac9f26efd80f@github.com> Message-ID: On Fri, 17 Mar 2023 10:31:46 GMT, Serguei Spitsyn wrote: >> This is needed for future performance/scalability improvements in JVMTI support of virtual threads. >> The update includes the following: >> >> 1. Refactored the `VirtualThread` native methods: >> `notifyJvmtiMountBegin` and `notifyJvmtiMountEnd` => `notifyJvmtiMount` >> `notifyJvmtiUnmountBegin` and `notifyJvmtiUnmountEnd` => `notifyJvmtiUnmount` >> 2. Still useful implementation of old native methods is moved from `jvm.cpp` to `jvmtiThreadState.cpp`: >> `JVM_VirtualThreadMountStart` => `VTMS_mount_begin` >> `JVM_VirtualThreadMountEnd` => `VTMS_mount_end` >> `JVM_VirtualThreadUnmountStart` = > `VTMS_unmount_begin` >> `JVM_VirtualThreadUnmountEnd` => `VTMS_mount_end` >> 3. Intrinsified the `VirtualThread` native methods: `notifyJvmtiMount`, `notifyJvmtiUnmount`, `notifyJvmtiHideFrames`. >> 4. Removed the`VirtualThread` static boolean state variable `notifyJvmtiEvents` and its support in `javaClasses`. >> 5. Added static boolean state variable `_VTMS_notify_jvmti_events` to the jvmtiVTMSTransitionDisabler class as a replacement of the `VirtualThread` `notifyJvmtiEvents` variable. >> >> Implementing the same methods as C1 intrinsics can be needed in the future but is a low priority for now. >> >> Testing: >> - Ran mach5 tiers 1-6. No regressions were found. > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > minor tweaks in intrisics implementation Thank you for review, Leonid! ------------- PR: https://git.openjdk.org/jdk/pull/13054 From asotona at openjdk.org Mon Mar 20 11:10:22 2023 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 20 Mar 2023 11:10:22 GMT Subject: RFR: 8304425: ClassHierarchyResolver from Reflection In-Reply-To: <08Hy6pEhV75yr_F4mCP-dkKOKMCSoFxWI2E7OnM4iyQ=.cfa14992-8e94-4d6d-bdf9-e6689549c83e@github.com> References: <08Hy6pEhV75yr_F4mCP-dkKOKMCSoFxWI2E7OnM4iyQ=.cfa14992-8e94-4d6d-bdf9-e6689549c83e@github.com> Message-ID: On Fri, 17 Mar 2023 18:18:48 GMT, Chen Liang wrote: > Add API to explore Class Hierarchy with a `ClassLoader` or a `Lookup` with proper privileges, with tests. > > This addition is useful in case classes at runtime are not loaded from the system class loader, such as Proxy. This is also useful to APIs that generate bytecode with a `Lookup` object, such as a custom single-abstract-method class implementations from a method handle. > > See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000249.html as well. > > Current questions, which I wish to discuss with @asotona: > 1. Should the resolver fail fast on `IllegalAccessException` from the lookup? This usually indicates the hierarchy resolver is set up improperly, and proceeding may simply yield verification errors in class loading that are hard to track. For bytecode-generating APIs, throwing access errors for the Lookup eagerly is also more preferable than later silent generation failure. > 2. Whether the default resolver should be reading from jrt alone, reflection alone, or jrt then reflection. I personally believe reflection alone is more reliable, for classes may redefined with instrumentation or jfr, which may not be reflected in the system resources. > 3. In addition, I don't think chaining system class loader reflection after system resource retrieval is really meaningful: is there any case where reflection always works while the system resource retrieval always fails? Marked as reviewed by asotona (Committer). ------------- PR: https://git.openjdk.org/jdk/pull/13082 From asotona at openjdk.org Mon Mar 20 11:24:21 2023 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 20 Mar 2023 11:24:21 GMT Subject: RFR: 8304502: Classfile API class hierarchy makes assumptions when class is not resolved Message-ID: Classfile API class hierarchy makes assumptions when class is not resolved and that may lead to silent generation of invalid stack maps. Only debug-level log information of case is actually provided. Proposed patch throws IllegalArgumentException when the class is not resolved instead. Thanks for review. Adam ------------- Commit messages: - 8304502: Classfile API class hierarchy makes assumptions when class is not resolved Changes: https://git.openjdk.org/jdk/pull/13099/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13099&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304502 Stats: 17 lines in 4 files changed: 4 ins; 8 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/13099.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13099/head:pull/13099 PR: https://git.openjdk.org/jdk/pull/13099 From asotona at openjdk.org Mon Mar 20 12:02:31 2023 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 20 Mar 2023 12:02:31 GMT Subject: RFR: 8294972: Convert jdk.jlink internal plugins to use the Classfile API [v13] In-Reply-To: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> Message-ID: > jdk.jlink internal plugins are heavily using ASM > > This patch converts ASM calls to Classfile API. > > Please review. > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: added default to thrown for unknown CP tag in IncludeLocalesPlugin ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12944/files - new: https://git.openjdk.org/jdk/pull/12944/files/4e5b9651..b021d852 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12944&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12944&range=11-12 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12944.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12944/head:pull/12944 PR: https://git.openjdk.org/jdk/pull/12944 From asotona at openjdk.org Mon Mar 20 12:02:36 2023 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 20 Mar 2023 12:02:36 GMT Subject: RFR: 8294972: Convert jdk.jlink internal plugins to use the Classfile API [v12] In-Reply-To: References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> <0XMnqSxriFou4zaFeHS3ECf43vk6skDCm9xnW6zrhoI=.572a6897-d370-4a5d-b8ff-72a0e479efbe@github.com> Message-ID: <6CqCphoapJp_DTHDrzP5OExR7zlf9lr35rH0umEwg3M=.56c00797-1b28-4acd-a6f1-cdcc6dd9b780@github.com> On Fri, 17 Mar 2023 17:30:41 GMT, Mandy Chung wrote: >> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 220 commits: >> >> - Merge branch 'master' into JDK-8294972-jlink-plugins >> - SystemModulesPlugin::genClassBytes rename >> - SystemModulesPlugin::getClassBytes rename >> - Revert "implementation of custom ResourceHelper in IncludeLocalesPlugin" >> - remaining cleanup in SystemModulesPlugin >> - implementation of custom ResourceHelper in IncludeLocalesPlugin >> - fixed SystemModulesPlugin >> - fixed StripJavaDebugAttribute to drop line numbers from code >> - long lines wrapped >> - StripJavaDebugAttributesPlugin transformation fixed >> - ... and 210 more: https://git.openjdk.org/jdk/compare/4486f1b7...4e5b9651 > > src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/IncludeLocalesPlugin.java line 309: > >> 307: TAG_INVOKEDYNAMIC -> offset += 5; >> 308: case TAG_LONG, >> 309: TAG_DOUBLE -> {offset += 9; cpSlot++;} //additional slot for double and long entries > > should this add the default case and throw to prepare for future change? yes, fixed, thanks. ------------- PR: https://git.openjdk.org/jdk/pull/12944 From jlahoda at openjdk.org Mon Mar 20 12:17:19 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 20 Mar 2023 12:17:19 GMT Subject: RFR: 8304498: JShell does not switch to raw mode when there is no /bin/test Message-ID: If JShell is run on a system that does not have `/bin/test` (which is, apparently, possible for some systems, which only have `/usr/bin/test`), it won't switch the terminal into the raw mode, and the input will not work properly. The proposed fix herein is to detect whether `test` existing in `/usr/bin/test`, and if yes, use that location. Use the existing `/bin/test` otherwise. ------------- Commit messages: - 8304498: JShell does not switch to raw mode when there is no /bin/test Changes: https://git.openjdk.org/jdk/pull/13100/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13100&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304498 Stats: 63 lines in 2 files changed: 62 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13100.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13100/head:pull/13100 PR: https://git.openjdk.org/jdk/pull/13100 From duke at openjdk.org Mon Mar 20 12:23:20 2023 From: duke at openjdk.org (Glavo) Date: Mon, 20 Mar 2023 12:23:20 GMT Subject: RFR: 8304425: ClassHierarchyResolver from Reflection In-Reply-To: <08Hy6pEhV75yr_F4mCP-dkKOKMCSoFxWI2E7OnM4iyQ=.cfa14992-8e94-4d6d-bdf9-e6689549c83e@github.com> References: <08Hy6pEhV75yr_F4mCP-dkKOKMCSoFxWI2E7OnM4iyQ=.cfa14992-8e94-4d6d-bdf9-e6689549c83e@github.com> Message-ID: <_J7PEehDL3nULpqMLpgkobRurX-sxOjFEM_bkXXYrRs=.094614fb-5221-47a8-8393-477a204720e4@github.com> On Fri, 17 Mar 2023 18:18:48 GMT, Chen Liang wrote: > Add API to explore Class Hierarchy with a `ClassLoader` or a `Lookup` with proper privileges, with tests. > > This addition is useful in case classes at runtime are not loaded from the system class loader, such as Proxy. This is also useful to APIs that generate bytecode with a `Lookup` object, such as a custom single-abstract-method class implementations from a method handle. > > See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000249.html as well. > > Current questions, which I wish to discuss with @asotona: > 1. Should the resolver fail fast on `IllegalAccessException` from the lookup? This usually indicates the hierarchy resolver is set up improperly, and proceeding may simply yield verification errors in class loading that are hard to track. For bytecode-generating APIs, throwing access errors for the Lookup eagerly is also more preferable than later silent generation failure. > 2. Whether the default resolver should be reading from jrt alone, reflection alone, or jrt then reflection. I personally believe reflection alone is more reliable, for classes may redefined with instrumentation or jfr, which may not be reflected in the system resources. > 3. In addition, I don't think chaining system class loader reflection after system resource retrieval is really meaningful: is there any case where reflection always works while the system resource retrieval always fails? Can you clean up a few redundant `public` access modifiers in `ClassHierarchyResolver.java`? They may bring some confusion. https://github.com/openjdk/jdk/blob/04dfe62d9c13bd234fa21d5d6211bff4038d31b4/src/java.base/share/classes/jdk/internal/classfile/ClassHierarchyResolver.java#L90 https://github.com/openjdk/jdk/blob/04dfe62d9c13bd234fa21d5d6211bff4038d31b4/src/java.base/share/classes/jdk/internal/classfile/ClassHierarchyResolver.java#L100 https://github.com/openjdk/jdk/blob/04dfe62d9c13bd234fa21d5d6211bff4038d31b4/src/java.base/share/classes/jdk/internal/classfile/ClassHierarchyResolver.java#L112 ------------- PR: https://git.openjdk.org/jdk/pull/13082 From duke at openjdk.org Mon Mar 20 13:20:30 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Mon, 20 Mar 2023 13:20:30 GMT Subject: RFR: 8205129: Remove java.lang.Compiler In-Reply-To: References: Message-ID: On Sun, 19 Mar 2023 09:01:26 GMT, Eirik Bjorsnos wrote: > Please help review this PR which suggests we remove the class `java.lang.Compiler`. The class seems non-functional for a decade, and was terminally deprecated in Java 9. Time has come to let it go. I noticed there are quite a few uses of `-Djava.compiler=none` in the demo netbeans project/build files. I have filed #13101 and #13098 to take care of those usages. ------------- PR: https://git.openjdk.org/jdk/pull/13092 From alanb at openjdk.org Mon Mar 20 13:29:21 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 20 Mar 2023 13:29:21 GMT Subject: RFR: 8304498: JShell does not switch to raw mode when there is no /bin/test In-Reply-To: References: Message-ID: <-WMZa6Pk0lidOnX1xJzmEkRu-GsoPzSS0fyya5dz4to=.8a4fd091-0019-4702-b787-e233af5368bb@github.com> On Mon, 20 Mar 2023 12:10:04 GMT, Jan Lahoda wrote: > If JShell is run on a system that does not have `/bin/test` (which is, apparently, possible for some systems, which only have `/usr/bin/test`), it won't switch the terminal into the raw mode, and the input will not work properly. > > The proposed fix herein is to detect whether `test` existing in `/usr/bin/test`, and if yes, use that location. Use the existing `/bin/test` otherwise. As a general point, we probably need to change jline to not create sub-processes. If we needs to introspect the environment then it will need to do it in the current VM. ------------- PR: https://git.openjdk.org/jdk/pull/13100 From jpai at openjdk.org Mon Mar 20 13:54:03 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 20 Mar 2023 13:54:03 GMT Subject: RFR: JDK-8303742: CompletableFuture.orTimeout leaks if the future completes exceptionally [v6] In-Reply-To: References: Message-ID: On Fri, 17 Mar 2023 09:52:51 GMT, Viktor Klang wrote: >> Addresses the situation where exceptional completion of `orTimeout`:ed CompletableFutures wouldn't cancel the timeout task which could lead to memory leaks if done frequently enough with long enough timeout durations. >> >> Fix discussed with @DougLea > > Viktor Klang has updated the pull request incrementally with one additional commit since the last revision: > > Reformatting the while-body to be more legible in diffs, and inlining the counter incrementation. Hello Viktor, I'll sponsor this shortly. It's my understanding that changes to these classes are also expected to be synced to the jsr166 repo that Doug maintains. From the description in this PR, I'm guessing that Doug will be doing this change in the jsr166 repo as well? ------------- PR: https://git.openjdk.org/jdk/pull/13059 From duke at openjdk.org Mon Mar 20 13:59:51 2023 From: duke at openjdk.org (Viktor Klang) Date: Mon, 20 Mar 2023 13:59:51 GMT Subject: RFR: JDK-8303742: CompletableFuture.orTimeout leaks if the future completes exceptionally [v6] In-Reply-To: References: Message-ID: On Fri, 17 Mar 2023 09:52:51 GMT, Viktor Klang wrote: >> Addresses the situation where exceptional completion of `orTimeout`:ed CompletableFutures wouldn't cancel the timeout task which could lead to memory leaks if done frequently enough with long enough timeout durations. >> >> Fix discussed with @DougLea > > Viktor Klang has updated the pull request incrementally with one additional commit since the last revision: > > Reformatting the while-body to be more legible in diffs, and inlining the counter incrementation. I just synced up with @DougLea?I'll let him decide how to handle it. :) ------------- PR: https://git.openjdk.org/jdk/pull/13059 From duke at openjdk.org Mon Mar 20 13:59:53 2023 From: duke at openjdk.org (Viktor Klang) Date: Mon, 20 Mar 2023 13:59:53 GMT Subject: Integrated: JDK-8303742: CompletableFuture.orTimeout leaks if the future completes exceptionally In-Reply-To: References: Message-ID: <0CL223Bl7IvuxPYfDrmtYm1VZMZ_sC4hQqvEst7KbDg=.c718b7a0-9c41-42ee-91f0-c9e5fbeec71c@github.com> On Thu, 16 Mar 2023 13:37:10 GMT, Viktor Klang wrote: > Addresses the situation where exceptional completion of `orTimeout`:ed CompletableFutures wouldn't cancel the timeout task which could lead to memory leaks if done frequently enough with long enough timeout durations. > > Fix discussed with @DougLea This pull request has now been integrated. Changeset: ded6a813 Author: Viktor Klang Committer: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/ded6a8131970ac2f7ae59716769e6f6bae3b809a Stats: 64 lines in 2 files changed: 63 ins; 0 del; 1 mod 8303742: CompletableFuture.orTimeout leaks if the future completes exceptionally Reviewed-by: jpai, alanb ------------- PR: https://git.openjdk.org/jdk/pull/13059 From asotona at openjdk.org Mon Mar 20 14:06:43 2023 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 20 Mar 2023 14:06:43 GMT Subject: RFR: 8304502: Classfile API class hierarchy makes assumptions when class is not resolved [v2] In-Reply-To: References: Message-ID: > Classfile API class hierarchy makes assumptions when class is not resolved and that may lead to silent generation of invalid stack maps. Only debug-level log information of case is actually provided. > > Proposed patch throws IllegalArgumentException when the class is not resolved instead. > > Thanks for review. > > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: Update src/java.base/share/classes/jdk/internal/classfile/impl/ClassHierarchyImpl.java Co-authored-by: liach <7806504+liach at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13099/files - new: https://git.openjdk.org/jdk/pull/13099/files/67349d44..8f166bdd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13099&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13099&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13099.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13099/head:pull/13099 PR: https://git.openjdk.org/jdk/pull/13099 From liach at openjdk.org Mon Mar 20 14:06:45 2023 From: liach at openjdk.org (Chen Liang) Date: Mon, 20 Mar 2023 14:06:45 GMT Subject: RFR: 8304502: Classfile API class hierarchy makes assumptions when class is not resolved [v2] In-Reply-To: References: Message-ID: On Mon, 20 Mar 2023 14:02:13 GMT, Adam Sotona wrote: >> Classfile API class hierarchy makes assumptions when class is not resolved and that may lead to silent generation of invalid stack maps. Only debug-level log information of case is actually provided. >> >> Proposed patch throws IllegalArgumentException when the class is not resolved instead. >> >> Thanks for review. >> >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > Update src/java.base/share/classes/jdk/internal/classfile/impl/ClassHierarchyImpl.java > > Co-authored-by: liach <7806504+liach at users.noreply.github.com> src/java.base/share/classes/jdk/internal/classfile/impl/ClassHierarchyImpl.java line 171: > 169: > 170: public StaticClassHierarchyResolver(Collection interfaceNames, Map classToSuperClass) { > 171: map = new HashMap<>(interfaceNames.size() + classToSuperClass.size() + 1); Should use HashMap.newHashMap instead Suggestion: map = HashMap.newHashMap(interfaceNames.size() + classToSuperClass.size() + 1); ------------- PR: https://git.openjdk.org/jdk/pull/13099 From jpai at openjdk.org Mon Mar 20 14:21:55 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 20 Mar 2023 14:21:55 GMT Subject: RFR: 8304006: jlink should create the jimage file in the native endian for the target platform [v10] In-Reply-To: References: Message-ID: <0dJDlxKHyQs6Dtq8pvAEmg-7Q4PA__XmtvPVDSxSQhE=.e6806026-7866-492e-a976-e0640fe9e11c@github.com> > Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8206890? > > The `jlink` command allows a `--endian` option to specify the byte order in the generated image. Before this change, when such a image was being launched, the code would assume the byte order in the image to be the native order of the host where the image is being launched. That would result in failure to launch java, as noted in the linked issue. > > The commit in this PR, changes relevant places to not assume native order and instead determine the byte order by reading the magic bytes in the image file's header content. > > A new jtreg test has been added which reproduces the issue and verifies the fix. Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: Alan's suggestions - don't parse arch out of osname-arch for determining endianness and reduce the number of supported/known target platforms for cross linking ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11943/files - new: https://git.openjdk.org/jdk/pull/11943/files/f4b71700..e31ef76c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11943&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11943&range=08-09 Stats: 85 lines in 4 files changed: 36 ins; 40 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/11943.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11943/head:pull/11943 PR: https://git.openjdk.org/jdk/pull/11943 From jpai at openjdk.org Mon Mar 20 14:21:56 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 20 Mar 2023 14:21:56 GMT Subject: RFR: 8304006: jlink should create the jimage file in the native endian for the target platform [v8] In-Reply-To: References: <3PosSfnNxBGNjlCAGVaSD9JqgOfrfQjWM5kv-VTgxj4=.49f65531-8400-43c2-9520-a896431ea3a3@github.com> Message-ID: <2AsvcEQttfH5zOM_eW5whTzsitJelAZvl5ShUSaB_cQ=.e416c714-0e10-43d3-95a3-4928e43914f6@github.com> On Sun, 19 Mar 2023 09:07:41 GMT, Alan Bateman wrote: >> Hello Mandy, Alan, Jim, >> >> I've updated this PR to take into account these suggestions. I went ahead with what Mandy suggested and enhanced the existing (internal) `jdk.tools.jlink.internal.Platform` `record`to additional parse these architectures. It was anyway doing it for a select few. >> >> In addition to that, I also moved the architecture to endianness mapping into this `Platform` class itself. I followed Jim's suggestion to move the mapping out of the code. The `Platform` code now reads this from a `endianness.properties` file which is an internal resource of the `jdk.jlink` module. However, I'm having second thoughts about this part. I'm guessing that when Jim suggested moving this to a resource, it was probably because the code resided within the `JLinkTask` class. Now that I've moved this to an existing `Platform` class which is solely meant for things like these, I feel that we could probably just hard code these architecture to endianness mapping within this class itself, instead of reading it from a properties file. I'm looking for some inputs on what you all think would be the best way to proceed. >> >> Alan, as for the `osname-arch=little/big` vs `arch=little/big` mapping style, I decided to use the `arch=little/big` and let the Platform class parse the architecture out of the string in the `ModuleTarget`. I did it for a couple of reasons: >> >> 1. The `Platform` class already has the necessary logic to do that, plus it has to do that anyway (for us to implement the suggestion that Mandy noted about using this in `DefaultImageBuilder`) >> >> 2. As far as I could see, the OS name shouldn't play any role in the endianness, so leaving that out felt easier to deal with since we wouldn't have to think of what OS name, arch combinations would be valid. >> >> If you or others feel that it's better to stick with the `osname-arch=little/big` approach, instead of this one, please do let me know and I'll go ahead and do that change. > >> If you or others feel that it's better to stick with the osname-arch=little/big approach, instead of this one, please do let me know and I'll go ahead and do that change.that out felt easier to deal with since we wouldn't have to think of what OS name, arch combinations would be valid. > > My preference would be something like target.properties so we have one place with the properties for target platform when cross linking. ${ModuleTarget}.${property} could work as keys. At some point we will need to extend or replace the ModuleTarget as it too basic to describe the target platform, that's why I was hoping to avoid parsing it here. > > jlink cannot be reliably used to cross link to target a different JDK release. Reasons include changes to the run-time image, jimage changes, and plugins that are deeply tied to java.base or other modules. I mention this because JDK 11 was the last release to build solaris-sparcv9, so I think you can this and several others from the properties file. Probably just stick the the builds that are possible in the main line. Thank you Alan for these additional inputs. I've now updated the PR to use a `target.properties` to map the `osname-arch` to a endianness. The implementation in `Platform` class will no longer use the arch substring to decide the endianness and instead will use the complete `osname-arch` for determining the endianness. Additionally, I have trimmed down the number of `osname-arch` mapping to what I think is the current supported ones in mainline. If this list is inaccurate (which is possible), then please do let me know and I'll investigate further. ------------- PR: https://git.openjdk.org/jdk/pull/11943 From duke at openjdk.org Mon Mar 20 14:37:28 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Mon, 20 Mar 2023 14:37:28 GMT Subject: Integrated: 8304443: bootcycle builds fail after JDK-8015831 In-Reply-To: References: Message-ID: On Sat, 18 Mar 2023 17:46:00 GMT, Archie L. Cobbs wrote: > The fix for JDK-8015831, which added the new `this-escape` lint warning, caused the build of the `bootcycle-images` make target to fail. > > This commit adds the additional `@SuppressWarnings("this-escape")` annotations needed to fix it. This pull request has now been integrated. Changeset: c396f1ed Author: Archie L. Cobbs Committer: Vicente Romero URL: https://git.openjdk.org/jdk/commit/c396f1ed8b91b799fdd6a9a849d7407e606227d5 Stats: 74 lines in 63 files changed: 71 ins; 0 del; 3 mod 8304443: bootcycle builds fail after JDK-8015831 Reviewed-by: vromero ------------- PR: https://git.openjdk.org/jdk/pull/13089 From liach at openjdk.org Mon Mar 20 15:11:17 2023 From: liach at openjdk.org (Chen Liang) Date: Mon, 20 Mar 2023 15:11:17 GMT Subject: RFR: 8304425: ClassHierarchyResolver from Reflection In-Reply-To: References: <08Hy6pEhV75yr_F4mCP-dkKOKMCSoFxWI2E7OnM4iyQ=.cfa14992-8e94-4d6d-bdf9-e6689549c83e@github.com> Message-ID: <9yqOOS55Csq_oCC4v4MfyeiYbpOh5LvwRE_bCcg1P9I=.31ce1796-8617-414a-b682-d08c6866a96b@github.com> On Mon, 20 Mar 2023 11:07:23 GMT, Adam Sotona wrote: >> Add API to explore Class Hierarchy with a `ClassLoader` or a `Lookup` with proper privileges, with tests. >> >> This addition is useful in case classes at runtime are not loaded from the system class loader, such as Proxy. This is also useful to APIs that generate bytecode with a `Lookup` object, such as a custom single-abstract-method class implementations from a method handle. >> >> See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000249.html as well. >> >> Current questions, which I wish to discuss with @asotona: >> 1. Should the resolver fail fast on `IllegalAccessException` from the lookup? This usually indicates the hierarchy resolver is set up improperly, and proceeding may simply yield verification errors in class loading that are hard to track. For bytecode-generating APIs, throwing access errors for the Lookup eagerly is also more preferable than later silent generation failure. >> 2. Whether the default resolver should be reading from jrt alone, reflection alone, or jrt then reflection. I personally believe reflection alone is more reliable, for classes may redefined with instrumentation or jfr, which may not be reflected in the system resources. >> 3. In addition, I don't think chaining system class loader reflection after system resource retrieval is really meaningful: is there any case where reflection always works while the system resource retrieval always fails? > > Marked as reviewed by asotona (Committer). @asotona So should I simply throw an `IllegalAccessError` when the Lookup encounters a `IllegalAccessException`, or should I return null? I favor throwing an `IllegalAccessError` as the lookup represents bytecode accessibility, and shall it fail to access, the generated bytecode will fail to access the specified superclass as well. ------------- PR: https://git.openjdk.org/jdk/pull/13082 From mchung at openjdk.org Mon Mar 20 15:11:35 2023 From: mchung at openjdk.org (Mandy Chung) Date: Mon, 20 Mar 2023 15:11:35 GMT Subject: RFR: 8294972: Convert jdk.jlink internal plugins to use the Classfile API [v13] In-Reply-To: References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> Message-ID: On Mon, 20 Mar 2023 12:02:31 GMT, Adam Sotona wrote: >> jdk.jlink internal plugins are heavily using ASM >> >> This patch converts ASM calls to Classfile API. >> >> Please review. >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > added default to thrown for unknown CP tag in IncludeLocalesPlugin Looks good. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.org/jdk/pull/12944 From asotona at openjdk.org Mon Mar 20 15:25:37 2023 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 20 Mar 2023 15:25:37 GMT Subject: RFR: 8304425: ClassHierarchyResolver from Reflection In-Reply-To: References: <08Hy6pEhV75yr_F4mCP-dkKOKMCSoFxWI2E7OnM4iyQ=.cfa14992-8e94-4d6d-bdf9-e6689549c83e@github.com> Message-ID: On Mon, 20 Mar 2023 11:07:23 GMT, Adam Sotona wrote: >> Add API to explore Class Hierarchy with a `ClassLoader` or a `Lookup` with proper privileges, with tests. >> >> This addition is useful in case classes at runtime are not loaded from the system class loader, such as Proxy. This is also useful to APIs that generate bytecode with a `Lookup` object, such as a custom single-abstract-method class implementations from a method handle. >> >> See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000249.html as well. >> >> Current questions, which I wish to discuss with @asotona: >> 1. Should the resolver fail fast on `IllegalAccessException` from the lookup? This usually indicates the hierarchy resolver is set up improperly, and proceeding may simply yield verification errors in class loading that are hard to track. For bytecode-generating APIs, throwing access errors for the Lookup eagerly is also more preferable than later silent generation failure. >> 2. Whether the default resolver should be reading from jrt alone, reflection alone, or jrt then reflection. I personally believe reflection alone is more reliable, for classes may redefined with instrumentation or jfr, which may not be reflected in the system resources. >> 3. In addition, I don't think chaining system class loader reflection after system resource retrieval is really meaningful: is there any case where reflection always works while the system resource retrieval always fails? > > Marked as reviewed by asotona (Committer). > @asotona So should I simply throw an `IllegalAccessError` when the Lookup encounters a `IllegalAccessException`, or should I return null? I favor throwing an `IllegalAccessError` as the lookup represents bytecode accessibility, and shall it fail to access, the generated bytecode will fail to access the specified superclass as well. Yes, I also prefer throwing `IllegalAccessError` to directly indicate what is wrong instead of later indirect exceptions. I think `IllegalAccessError` is not a case for fallback resolver, so it should not be masked. ------------- PR: https://git.openjdk.org/jdk/pull/13082 From alanb at openjdk.org Mon Mar 20 15:34:15 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 20 Mar 2023 15:34:15 GMT Subject: RFR: 8294972: Convert jdk.jlink internal plugins to use the Classfile API [v13] In-Reply-To: References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> Message-ID: On Mon, 20 Mar 2023 12:02:31 GMT, Adam Sotona wrote: >> jdk.jlink internal plugins are heavily using ASM >> >> This patch converts ASM calls to Classfile API. >> >> Please review. >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > added default to thrown for unknown CP tag in IncludeLocalesPlugin src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 523: > 521: private int nextLocalVar = 2; // index to next local variable > 522: > 523: // name of class to generate With the switch the ClassDesc then some of the comments might need to be adjusted. ------------- PR: https://git.openjdk.org/jdk/pull/12944 From alanb at openjdk.org Mon Mar 20 15:37:22 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 20 Mar 2023 15:37:22 GMT Subject: RFR: 8294972: Convert jdk.jlink internal plugins to use the Classfile API [v13] In-Reply-To: References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> Message-ID: On Mon, 20 Mar 2023 12:02:31 GMT, Adam Sotona wrote: >> jdk.jlink internal plugins are heavily using ASM >> >> This patch converts ASM calls to Classfile API. >> >> Please review. >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > added default to thrown for unknown CP tag in IncludeLocalesPlugin src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 581: > 579: clb.withFlags(ACC_FINAL + ACC_SUPER) > 580: .withInterfaceSymbols(List.of(CD_SYSTEM_MODULES)) > 581: .withVersion(52, 0); @mlchung Do you recall why this was generated as version 52? ------------- PR: https://git.openjdk.org/jdk/pull/12944 From asotona at openjdk.org Mon Mar 20 16:00:40 2023 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 20 Mar 2023 16:00:40 GMT Subject: RFR: 8294972: Convert jdk.jlink internal plugins to use the Classfile API [v14] In-Reply-To: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> Message-ID: <0efK-pRtx-xkeOMKMEZBRcwFOoNFphU3Nubw9shBVIc=.42e2cb69-7ad9-4f23-9d23-2a95f6738753@github.com> > jdk.jlink internal plugins are heavily using ASM > > This patch converts ASM calls to Classfile API. > > Please review. > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: fixed SystemModulesClassGenerator.moduleInfos comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12944/files - new: https://git.openjdk.org/jdk/pull/12944/files/b021d852..993ef398 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12944&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12944&range=12-13 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12944.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12944/head:pull/12944 PR: https://git.openjdk.org/jdk/pull/12944 From liach at openjdk.org Mon Mar 20 16:04:13 2023 From: liach at openjdk.org (Chen Liang) Date: Mon, 20 Mar 2023 16:04:13 GMT Subject: RFR: 8304425: ClassHierarchyResolver from Reflection In-Reply-To: <08Hy6pEhV75yr_F4mCP-dkKOKMCSoFxWI2E7OnM4iyQ=.cfa14992-8e94-4d6d-bdf9-e6689549c83e@github.com> References: <08Hy6pEhV75yr_F4mCP-dkKOKMCSoFxWI2E7OnM4iyQ=.cfa14992-8e94-4d6d-bdf9-e6689549c83e@github.com> Message-ID: <43RJsK7R1zeREEAnDUJB77opANogo12cDOKCIgCrTmE=.baa9c834-c5af-4072-8ddb-591851ff6754@github.com> On Fri, 17 Mar 2023 18:18:48 GMT, Chen Liang wrote: > Add API to explore Class Hierarchy with a `ClassLoader` or a `Lookup` with proper privileges, with tests. > > This addition is useful in case classes at runtime are not loaded from the system class loader, such as Proxy. This is also useful to APIs that generate bytecode with a `Lookup` object, such as a custom single-abstract-method class implementations from a method handle. > > See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000249.html as well. > > Current questions, which I wish to discuss with @asotona: > 1. Should the resolver fail fast on `IllegalAccessException` from the lookup? This usually indicates the hierarchy resolver is set up improperly, and proceeding may simply yield verification errors in class loading that are hard to track. For bytecode-generating APIs, throwing access errors for the Lookup eagerly is also more preferable than later silent generation failure. > 2. Whether the default resolver should be reading from jrt alone, reflection alone, or jrt then reflection. I personally believe reflection alone is more reliable, for classes may redefined with instrumentation or jfr, which may not be reflected in the system resources. > 3. In addition, I don't think chaining system class loader reflection after system resource retrieval is really meaningful: is there any case where reflection always works while the system resource retrieval always fails? After thinking, I chose `IllegalArgumentException` for an error is not indicative here (as this should not throw an `IncompatibleClassChangeError`, the superclass of `IllegalAccessError`). I will keep the delegation to system classloader for default resolver for now, though it appears this is subject to discussion on the mailing list. ------------- PR: https://git.openjdk.org/jdk/pull/13082 From liach at openjdk.org Mon Mar 20 16:18:27 2023 From: liach at openjdk.org (Chen Liang) Date: Mon, 20 Mar 2023 16:18:27 GMT Subject: RFR: 8304425: ClassHierarchyResolver from Reflection [v2] In-Reply-To: <08Hy6pEhV75yr_F4mCP-dkKOKMCSoFxWI2E7OnM4iyQ=.cfa14992-8e94-4d6d-bdf9-e6689549c83e@github.com> References: <08Hy6pEhV75yr_F4mCP-dkKOKMCSoFxWI2E7OnM4iyQ=.cfa14992-8e94-4d6d-bdf9-e6689549c83e@github.com> Message-ID: <6R3DUw7cdMjHIjmsO2zs7ftYvc4-DTOK3rHLd3Ph-pM=.65f53308-4e52-405d-9cf6-2bb9be9c8aaf@github.com> > Add API to explore Class Hierarchy with a `ClassLoader` or a `Lookup` with proper privileges, with tests. > > This addition is useful in case classes at runtime are not loaded from the system class loader, such as Proxy. This is also useful to APIs that generate bytecode with a `Lookup` object, such as a custom single-abstract-method class implementations from a method handle. > > See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000249.html as well. > > Current questions, which I wish to discuss with @asotona: > 1. Should the resolver fail fast on `IllegalAccessException` from the lookup? This usually indicates the hierarchy resolver is set up improperly, and proceeding may simply yield verification errors in class loading that are hard to track. For bytecode-generating APIs, throwing access errors for the Lookup eagerly is also more preferable than later silent generation failure. > 2. Whether the default resolver should be reading from jrt alone, reflection alone, or jrt then reflection. I personally believe reflection alone is more reliable, for classes may redefined with instrumentation or jfr, which may not be reflected in the system resources. > 3. In addition, I don't think chaining system class loader reflection after system resource retrieval is really meaningful: is there any case where reflection always works while the system resource retrieval always fails? Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Make lookup based resolver throw on illegal access eagerly ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13082/files - new: https://git.openjdk.org/jdk/pull/13082/files/04dfe62d..e74eb13d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13082&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13082&range=00-01 Stats: 19 lines in 3 files changed: 12 ins; 1 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/13082.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13082/head:pull/13082 PR: https://git.openjdk.org/jdk/pull/13082 From alanb at openjdk.org Mon Mar 20 17:08:12 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 20 Mar 2023 17:08:12 GMT Subject: RFR: 8294972: Convert jdk.jlink internal plugins to use the Classfile API [v14] In-Reply-To: <0efK-pRtx-xkeOMKMEZBRcwFOoNFphU3Nubw9shBVIc=.42e2cb69-7ad9-4f23-9d23-2a95f6738753@github.com> References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> <0efK-pRtx-xkeOMKMEZBRcwFOoNFphU3Nubw9shBVIc=.42e2cb69-7ad9-4f23-9d23-2a95f6738753@github.com> Message-ID: On Mon, 20 Mar 2023 16:00:40 GMT, Adam Sotona wrote: >> jdk.jlink internal plugins are heavily using ASM >> >> This patch converts ASM calls to Classfile API. >> >> Please review. >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > fixed SystemModulesClassGenerator.moduleInfos comment Good work ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/12944#pullrequestreview-1349040466 From mchung at openjdk.org Mon Mar 20 17:08:16 2023 From: mchung at openjdk.org (Mandy Chung) Date: Mon, 20 Mar 2023 17:08:16 GMT Subject: RFR: 8294972: Convert jdk.jlink internal plugins to use the Classfile API [v13] In-Reply-To: References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> Message-ID: On Mon, 20 Mar 2023 15:34:31 GMT, Alan Bateman wrote: >> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: >> >> added default to thrown for unknown CP tag in IncludeLocalesPlugin > > src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 581: > >> 579: clb.withFlags(ACC_FINAL + ACC_SUPER) >> 580: .withInterfaceSymbols(List.of(CD_SYSTEM_MODULES)) >> 581: .withVersion(52, 0); > > @mlchung Do you recall why this was generated as version 52? When this plugin was added in JDK 9, no API to get the current class file version. Later I added `jdk.internal.misc.VM::classFileVersion` and converted lambda proxies and lambda forms to use it. I have a patch to switch class file version to `ClassFileFormatVersion::latest` in this generated class and some others but want to wait until this PR is integrated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12944#discussion_r1142415605 From aturbanov at openjdk.org Mon Mar 20 17:11:14 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 20 Mar 2023 17:11:14 GMT Subject: RFR: 8304425: ClassHierarchyResolver from Reflection [v2] In-Reply-To: <6R3DUw7cdMjHIjmsO2zs7ftYvc4-DTOK3rHLd3Ph-pM=.65f53308-4e52-405d-9cf6-2bb9be9c8aaf@github.com> References: <08Hy6pEhV75yr_F4mCP-dkKOKMCSoFxWI2E7OnM4iyQ=.cfa14992-8e94-4d6d-bdf9-e6689549c83e@github.com> <6R3DUw7cdMjHIjmsO2zs7ftYvc4-DTOK3rHLd3Ph-pM=.65f53308-4e52-405d-9cf6-2bb9be9c8aaf@github.com> Message-ID: On Mon, 20 Mar 2023 16:18:27 GMT, Chen Liang wrote: >> Add API to explore Class Hierarchy with a `ClassLoader` or a `Lookup` with proper privileges, with tests. >> >> This addition is useful in case classes at runtime are not loaded from the system class loader, such as Proxy. This is also useful to APIs that generate bytecode with a `Lookup` object, such as a custom single-abstract-method class implementations from a method handle. >> >> See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000249.html as well. >> >> Current questions, which I wish to discuss with @asotona: >> 1. Should the resolver fail fast on `IllegalAccessException` from the lookup? This usually indicates the hierarchy resolver is set up improperly, and proceeding may simply yield verification errors in class loading that are hard to track. For bytecode-generating APIs, throwing access errors for the Lookup eagerly is also more preferable than later silent generation failure. >> 2. Whether the default resolver should be reading from jrt alone, reflection alone, or jrt then reflection. I personally believe reflection alone is more reliable, for classes may redefined with instrumentation or jfr, which may not be reflected in the system resources. >> 3. In addition, I don't think chaining system class loader reflection after system resource retrieval is really meaningful: is there any case where reflection always works while the system resource retrieval always fails? > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Make lookup based resolver throw on illegal access eagerly src/java.base/share/classes/jdk/internal/classfile/impl/ClassHierarchyImpl.java line 187: > 185: } > 186: > 187: public static abstract class ReflectionClassHierarchyResolver implements ClassHierarchyResolver { let's use blessed modifiers order: Suggestion: public abstract static class ReflectionClassHierarchyResolver implements ClassHierarchyResolver { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13082#discussion_r1142445278 From mchung at openjdk.org Mon Mar 20 17:12:56 2023 From: mchung at openjdk.org (Mandy Chung) Date: Mon, 20 Mar 2023 17:12:56 GMT Subject: RFR: JDK-8304163: Move jdk.internal.module.ModuleInfoWriter to the test library [v2] In-Reply-To: References: Message-ID: On Mon, 20 Mar 2023 06:57:32 GMT, Jaikiran Pai wrote: >> test/jdk/java/lang/ModuleTests/AnnotationsTest.java line 61: >> >>> 59: * java.base/jdk.internal.module >>> 60: * @library /test/lib >>> 61: * @build jdk.test.lib.util.ModuleInfoWriter >> >> You don't need to build library classes explicitly. I think @library /test/lib it enough. > > Hello @lmesnik, on the contrary, these build directives are recommended (and based on some of the issues we have encountered, are in fact necessary). The jtreg documentation has this to say https://openjdk.org/jtreg/tag-spec.html: > >> In general, classes in library directories are not automatically compiled as part of a compilation command explicitly naming the source files containing those classes. A test that relies upon library classes should contain appropriate @build directives to ensure that the classes will be compiled. It is strongly recommended that tests do not rely on the use of implicit compilation by the Java compiler. Such an approach is generally fragile, and may lead to incomplete recompilation when a test or library code has been modified. Explicit compilation is exactly the reason of adding `@build` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13085#discussion_r1142447529 From liach at openjdk.org Mon Mar 20 17:24:52 2023 From: liach at openjdk.org (Chen Liang) Date: Mon, 20 Mar 2023 17:24:52 GMT Subject: RFR: 8304425: ClassHierarchyResolver from Reflection [v3] In-Reply-To: <08Hy6pEhV75yr_F4mCP-dkKOKMCSoFxWI2E7OnM4iyQ=.cfa14992-8e94-4d6d-bdf9-e6689549c83e@github.com> References: <08Hy6pEhV75yr_F4mCP-dkKOKMCSoFxWI2E7OnM4iyQ=.cfa14992-8e94-4d6d-bdf9-e6689549c83e@github.com> Message-ID: <5aiDoSN1REXXWT236jFlZLZhmywCFxs5N1C12EJoCdE=.0985e085-f5d6-4181-ad0b-2a91e84943f1@github.com> > Add API to explore Class Hierarchy with a `ClassLoader` or a `Lookup` with proper privileges, with tests. > > This addition is useful in case classes at runtime are not loaded from the system class loader, such as Proxy. This is also useful to APIs that generate bytecode with a `Lookup` object, such as a custom single-abstract-method class implementations from a method handle. > > See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000249.html as well. > > Current questions, which I wish to discuss with @asotona: > 1. Should the resolver fail fast on `IllegalAccessException` from the lookup? This usually indicates the hierarchy resolver is set up improperly, and proceeding may simply yield verification errors in class loading that are hard to track. For bytecode-generating APIs, throwing access errors for the Lookup eagerly is also more preferable than later silent generation failure. > 2. Whether the default resolver should be reading from jrt alone, reflection alone, or jrt then reflection. I personally believe reflection alone is more reliable, for classes may redefined with instrumentation or jfr, which may not be reflected in the system resources. > 3. In addition, I don't think chaining system class loader reflection after system resource retrieval is really meaningful: is there any case where reflection always works while the system resource retrieval always fails? Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Update src/java.base/share/classes/jdk/internal/classfile/impl/ClassHierarchyImpl.java Co-authored-by: Andrey Turbanov ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13082/files - new: https://git.openjdk.org/jdk/pull/13082/files/e74eb13d..5ab4056f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13082&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13082&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13082.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13082/head:pull/13082 PR: https://git.openjdk.org/jdk/pull/13082 From mchung at openjdk.org Mon Mar 20 17:33:33 2023 From: mchung at openjdk.org (Mandy Chung) Date: Mon, 20 Mar 2023 17:33:33 GMT Subject: Integrated: JDK-8304163: Move jdk.internal.module.ModuleInfoWriter to the test library In-Reply-To: References: Message-ID: On Fri, 17 Mar 2023 22:01:46 GMT, Mandy Chung wrote: > `ModuleInfoWriter` is not used by the runtime. Move it to the test library as `jdk.test.lib.util.ModuleInfoWriter`. The tests are updated to use the test library instead. `ModuleInfoWriter` depends on `jdk.internal.module` types and the Classfile API. Hence `@modules java.base/jdk.internal.classfile` and other classfile subpackages are added. This pull request has now been integrated. Changeset: 622f2394 Author: Mandy Chung URL: https://git.openjdk.org/jdk/commit/622f239448c2a96a74202621ee84c181d79fbde4 Stats: 154 lines in 17 files changed: 91 ins; 19 del; 44 mod 8304163: Move jdk.internal.module.ModuleInfoWriter to the test library Reviewed-by: jpai, alanb ------------- PR: https://git.openjdk.org/jdk/pull/13085 From smarks at openjdk.org Mon Mar 20 17:38:39 2023 From: smarks at openjdk.org (Stuart Marks) Date: Mon, 20 Mar 2023 17:38:39 GMT Subject: RFR: 8205129: Remove java.lang.Compiler In-Reply-To: References: Message-ID: On Mon, 20 Mar 2023 02:01:38 GMT, David Holmes wrote: >>> The discussion is also a reminder that -Djava.compiler=NONE is the equivalent of -Xint, I thought that system property was dropped a long time ago. >> >> https://bugs.openjdk.org/browse/JDK-8041676 suggests to deprecate it, but from the last comment we still seem to be waiting for @dholmes-ora to get back from vacation on the 22nd :-) > >> > The discussion is also a reminder that -Djava.compiler=NONE is the equivalent of -Xint, I thought that system property was dropped a long time ago. >> >> https://bugs.openjdk.org/browse/JDK-8041676 suggests to deprecate it, but from the last comment we still seem to be waiting for @dholmes-ora to get back from vacation on the 22nd :-) > > I guess I never heard back from @stuart-marks . :( I think [JDK-8041676](https://bugs.openjdk.org/browse/JDK-8041676) needs to be resolved along side this issue. I don't know how much interdependency there is between the `java.compiler` system property and the `java.lang.Compiler` class. On the library side I think they're independent. But it sounds like @dholmes-ora thinks they should be resolved at the same time, so maybe there some things going on between them inside the JVM. The `java.compiler` property still seems to have some actual effect (see src/hotspot/share/runtime/arguments.cpp) so it shouldn't be removed immediately. Instead, it needs to be deprecated and its use should cause a warning to be issued. A comment in that file also mentions `-Xdebug`. The Hotspot help message for that says -Xdebug does nothing. Provided for backward compatibility. which doesn't appear to be true, as `-Xdebug` seems to have an effect on the interpretation of the `java.compiler` property! Ugh. Well, this appears to be the only effect of `-Xdebug`, so maybe the eventual removal of the `java.compiler` property will make the help message become true. Anyway it sounds to me like the next step is to deprecate the `java.compiler` property and to have setting it cause a warning to be issued. If @dholmes-ora thinks that removal of `java.lang.Compiler` should wait until after that, I'm ok with it. P.S. I note that I am finally getting back to @dholmes-ora on this issue, and it is in fact after he has returned from vacation on the 22nd. :-) ------------- PR Comment: https://git.openjdk.org/jdk/pull/13092#issuecomment-1476662136 From dcubed at openjdk.org Mon Mar 20 17:55:59 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Mon, 20 Mar 2023 17:55:59 GMT Subject: RFR: JDK-8304163: Move jdk.internal.module.ModuleInfoWriter to the test library [v2] In-Reply-To: References: Message-ID: On Sat, 18 Mar 2023 19:14:09 GMT, Mandy Chung wrote: >> `ModuleInfoWriter` is not used by the runtime. Move it to the test library as `jdk.test.lib.util.ModuleInfoWriter`. The tests are updated to use the test library instead. `ModuleInfoWriter` depends on `jdk.internal.module` types and the Classfile API. Hence `@modules java.base/jdk.internal.classfile` and other classfile subpackages are added. > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > move @library after @modules per the recommended ordering Sigh... And again we have the situation where some folks are adding `@build` directives and other folks are removing `@build` directives. Another recent PR removed library build directives: https://github.com/openjdk/jdk/pull/13030 and that made the related tests stop failing with NoClassDefFoundErrors. This mess is related to: [CODETOOLS-7902847](https://bugs.openjdk.org/browse/CODETOOLS-7902847) Class directory of a test case should not be used to compile a library and these problems show up when doing parallel execution of tests where more than one test uses the "offending" library. We really, really need @jonathan-gibbons to chime in on review threads like these. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13085#issuecomment-1476684779 From pminborg at openjdk.org Mon Mar 20 18:02:00 2023 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 20 Mar 2023 18:02:00 GMT Subject: RFR: 8301552: Use AtomicReferenceArray for caching instead of CHM in ZoneOffset [v8] In-Reply-To: References: Message-ID: On Thu, 9 Feb 2023 13:46:14 GMT, Per Minborg wrote: >> `ZoneOffset` instances are cached by the `ZoneOffset` class itself for values in the range [-18h, 18h] for each second that is on an even quarter of an hour (i.e. at most 2*18*4+1 = 145 values). >> >> Instead of using a `ConcurrentHashMap` for caching instanced, we could instead use an `AtomicReferenceArray` with direct slot value access for said even seconds. This will improve performance and reduce the number of object even though the backing array will go from an initial 32 in the CHM to an initial/final 145 in the ARA. The CHM will contain much more objects and array slots for typical numbers of entries in the cache and will compute hash/bucket/collision on the hot code path for each cache access. > > Per Minborg has updated the pull request incrementally with three additional commits since the last revision: > > - Remove unused setup method > - Rename method in test > - Add copyright header Keep alive. ------------- PR Comment: https://git.openjdk.org/jdk/pull/12346#issuecomment-1476693257 From pminborg at openjdk.org Mon Mar 20 18:12:39 2023 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 20 Mar 2023 18:12:39 GMT Subject: RFR: 8304265: Implementation of Foreign Function and Memory API (Third Preview) Message-ID: API changes for the FFM API (third preview) Specdiff: https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html Javadoc: https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html ------------- Commit messages: - Update after first round of comments - Remove extra line - Remove Panama-specific content - Generate delta Changes: https://git.openjdk.org/jdk/pull/13079/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304265 Stats: 13601 lines in 269 files changed: 5644 ins; 5999 del; 1958 mod Patch: https://git.openjdk.org/jdk/pull/13079.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13079/head:pull/13079 PR: https://git.openjdk.org/jdk/pull/13079 From duke at openjdk.org Mon Mar 20 18:12:45 2023 From: duke at openjdk.org (ExE Boss) Date: Mon, 20 Mar 2023 18:12:45 GMT Subject: RFR: 8304265: Implementation of Foreign Function and Memory API (Third Preview) In-Reply-To: References: Message-ID: On Fri, 17 Mar 2023 15:42:56 GMT, Per Minborg wrote: > API changes for the FFM API (third preview) > > Specdiff: > https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html > > Javadoc: > https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html src/java.base/share/classes/java/lang/foreign/AddressLayout.java line 59: > 57: */ > 58: @PreviewFeature(feature = PreviewFeature.Feature.FOREIGN) > 59: sealed public interface AddressLayout extends ValueLayout permits ValueLayouts.OfAddressImpl { This should?match other sealed?interfaces: Suggestion: public sealed interface AddressLayout extends ValueLayout permits ValueLayouts.OfAddressImpl { src/java.base/share/classes/java/lang/foreign/Linker.java line 578: > 576: * Execution state is captured by a downcall method handle on invocation, by writing it > 577: * to a native segment provided by the user to the downcall method handle. > 578: * For this purpose, a downcall method handle linked with the this Suggestion: * For this purpose, a downcall method handle linked with this ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1140677384 PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1140679387 From mcimadamore at openjdk.org Mon Mar 20 18:12:41 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 20 Mar 2023 18:12:41 GMT Subject: RFR: 8304265: Implementation of Foreign Function and Memory API (Third Preview) In-Reply-To: References: Message-ID: On Fri, 17 Mar 2023 15:42:56 GMT, Per Minborg wrote: > API changes for the FFM API (third preview) > > Specdiff: > https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html > > Javadoc: > https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html Here are the main API changes introduced in this round: * `SegmentScope` has been simplified into a pure lifetime abstraction and moved into a nested class `MemorySegment.Scope`. All segments have a scope (e.g. the segment lifetime), which is usually the scope of some `Arena`. All the factory methods in `SegmentScope` to create non-closeable lifetimes have been moved to `Arena` (e.g. `Arena.ofAuto` and `Arena.global`). This leads to a simplified API, which still allows to build custom arenas via simple delegation, but, at the same time, allows clients to use arenas with minimal indirections (e.g. `arena.scope()` is no longer needed in many places). Some factory names in `Arena` were also updated (e.g. from `openConfined` to `ofConfined`). * `ValueLayout::OfAddress` has been moved to a toplevel class `AddressLayout`. Also, the method to obtain an address layout of unbounded size (`OfAddress::asUnbounded`) has been changed, so that it now takes the layout of the target region of memory pointed to by the address (`AddressLayout::withTargetLayout`). * A new *layout path* is provided to dereference an address layout. This allows memory segment var handle to deal with complex dereference expressions like `*(a[10].x).y`. * A new linker implementation, namely the *fallback linker* has been added. This linker is based on `libffi` and provides a very easy way to add support for `Linker` API, even in platforms that have limited functionalities (such as [zero](https://openjdk.org/projects/zero/)). * The `VaList` interface has been dropped. Unfortunately, the behavior of `va_list` is hopelessly platform specific, and we could also never make full use of it in the `jextract` tool, given that parsing support `va_list` is very limited in `libclang`. * The API for unsafely attaching spatial/temporal bounds to an unsafe memory segment has been improved and streamlined. The `MemorySegment::ofAddress` method is now a single, unrestricted method which turns a long address into a native memory segment whose base address is the provided address. The returned segment has a scope that is always alive, and has zero-length. To resize, or add new temporal bounds to an existing segments, clients can use the new `MemorySegment::reinterpret` methods. The logic for attaching a cleanup action to a memory segment has also been updated: now the cleanup action will take as input a shallow copy of the memory segment, in a scope that is always alive, so that clients can pass that copy to other functions in order to perform custom cleanup. * We have made some changes and simplfications to the way in which runtime values such as `errno` are preserved, The `CapturedCallState` interface has been removed. Instead, there is a way to obtain a group layout of all the values that can be saved, given the platform in which the linker runs. Clients can query the layout, e.g. obtaining names for the values to be saved, and then create a linker option which lists all the name of the values to be saved. * We have added support for *trivial* (or *leaf*) calls - that is native calls whose execution completes very quickly. This option might be useful when calling functions whose total execution time is comparable to that of the overhead of the change of the thread state from Java to native (in JNI, such calls are handled using *critical JNI*). ------------- PR Comment: https://git.openjdk.org/jdk/pull/13079#issuecomment-1476648707 From liach at openjdk.org Mon Mar 20 18:21:10 2023 From: liach at openjdk.org (Chen Liang) Date: Mon, 20 Mar 2023 18:21:10 GMT Subject: RFR: 8301552: Use AtomicReferenceArray for caching instead of CHM in ZoneOffset [v8] In-Reply-To: References: Message-ID: On Thu, 9 Feb 2023 13:46:14 GMT, Per Minborg wrote: >> `ZoneOffset` instances are cached by the `ZoneOffset` class itself for values in the range [-18h, 18h] for each second that is on an even quarter of an hour (i.e. at most 2*18*4+1 = 145 values). >> >> Instead of using a `ConcurrentHashMap` for caching instanced, we could instead use an `AtomicReferenceArray` with direct slot value access for said even seconds. This will improve performance and reduce the number of object even though the backing array will go from an initial 32 in the CHM to an initial/final 145 in the ARA. The CHM will contain much more objects and array slots for typical numbers of entries in the cache and will compute hash/bucket/collision on the hot code path for each cache access. > > Per Minborg has updated the pull request incrementally with three additional commits since the last revision: > > - Remove unused setup method > - Rename method in test > - Add copyright header src/java.base/share/classes/java/time/ZoneOffset.java line 430: > 428: public static ZoneOffset ofTotalSeconds(int totalSeconds) { > 429: final class Holder { > 430: private static final IntFunction ZONE_OFFSET_MAPPER = new ZoneOffsetMapper(); Can't the ZoneOffsetMapper itself serve as a holder class? so we move this singleton into ZoneOffsetMapper itself. test/jdk/jdk/internal/util/LazyReferenceArray/BasicLazyReferenceArrayTest.java line 107: > 105: > 106: private static IntFunction intIdentity() { > 107: return i -> i; Can't this be `Integer::valueOf`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12346#discussion_r1142516460 PR Review Comment: https://git.openjdk.org/jdk/pull/12346#discussion_r1142520869 From mchung at openjdk.org Mon Mar 20 18:50:18 2023 From: mchung at openjdk.org (Mandy Chung) Date: Mon, 20 Mar 2023 18:50:18 GMT Subject: RFR: 8294972: Convert jdk.jlink internal plugins to use the Classfile API [v13] In-Reply-To: References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> Message-ID: <5ekiKI8izGG5Li73e56zp1sf6rGkLlHVSoCSIY40Foc=.99fa9abe-672d-4a3f-b5ff-ab43980242f7@github.com> On Mon, 20 Mar 2023 16:44:25 GMT, Mandy Chung wrote: >> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 581: >> >>> 579: clb.withFlags(ACC_FINAL + ACC_SUPER) >>> 580: .withInterfaceSymbols(List.of(CD_SYSTEM_MODULES)) >>> 581: .withVersion(52, 0); >> >> @mlchung Do you recall why this was generated as version 52? > > When this plugin was added in JDK 9, no API to get the current class file version. Later I added `jdk.internal.misc.VM::classFileVersion` and converted lambda proxies and lambda forms to use it. > > I have a patch to switch class file version to `ClassFileFormatVersion::latest` in this generated class and some others but want to wait until this PR is integrated. I posted https://github.com/openjdk/jdk/pull/13106 regarding the class file version. Having a second thought, no need to wait until this PR is integrated. It should be easily merged. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12944#discussion_r1142551119 From mchung at openjdk.org Mon Mar 20 18:52:05 2023 From: mchung at openjdk.org (Mandy Chung) Date: Mon, 20 Mar 2023 18:52:05 GMT Subject: RFR: JDK-8304542: Convert use of internal VM::classFileVersion to ClassFileFormatVersion Message-ID: <8DEcPyyKgl_ZdtGKBw7knC4D_bjzsW4NgGcAxtzv2Dk=.73dc3efd-eff2-43a6-8853-d70e66a7d9b9@github.com> Replace calls to `jdk.internal.vm.VM::classFileVersion` with `java.lang.reflect.ClassFileFormatVersion.latest().major()`. This also fixes jlink SystemModulesPlugin plugin to use CFFV API instead of hardcoding the class file version. ------------- Commit messages: - JDK-8304542: Convert use of internal VM::classFileVersion to ClassFileFormatVersion - Merge branch 'master' of https://github.com/openjdk/jdk into cff-version - Merge branch 'master' of https://github.com/openjdk/jdk into AddClassLoader_Proxy - Added JavaLangAccess::getLoaderNameID(ClassLoader loader) - Avoid long line of code - Add comments - Fix Indentation - Use classloaderName if not Null otherwise Objects.toIdentityString(ld) - Added specific ClassLoader object to Proxy IllegalArgumentException Changes: https://git.openjdk.org/jdk/pull/13106/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13106&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304542 Stats: 22 lines in 5 files changed: 5 ins; 12 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/13106.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13106/head:pull/13106 PR: https://git.openjdk.org/jdk/pull/13106 From erikj at openjdk.org Mon Mar 20 19:32:31 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 20 Mar 2023 19:32:31 GMT Subject: RFR: 8304265: Implementation of Foreign Function and Memory API (Third Preview) In-Reply-To: References: Message-ID: On Fri, 17 Mar 2023 15:42:56 GMT, Per Minborg wrote: > API changes for the FFM API (third preview) > > Specdiff: > https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html > > Javadoc: > https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html Build changes look ok. ------------- Marked as reviewed by erikj (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13079#pullrequestreview-1349265135 From alanb at openjdk.org Mon Mar 20 19:41:52 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 20 Mar 2023 19:41:52 GMT Subject: RFR: JDK-8304542: Convert use of internal VM::classFileVersion to ClassFileFormatVersion In-Reply-To: <8DEcPyyKgl_ZdtGKBw7knC4D_bjzsW4NgGcAxtzv2Dk=.73dc3efd-eff2-43a6-8853-d70e66a7d9b9@github.com> References: <8DEcPyyKgl_ZdtGKBw7knC4D_bjzsW4NgGcAxtzv2Dk=.73dc3efd-eff2-43a6-8853-d70e66a7d9b9@github.com> Message-ID: On Mon, 20 Mar 2023 18:44:24 GMT, Mandy Chung wrote: > Replace calls to `jdk.internal.vm.VM::classFileVersion` with `java.lang.reflect.ClassFileFormatVersion.latest().major()`. This also fixes jlink SystemModulesPlugin plugin to use CFFV API instead of hardcoding the class file version. Looks good, I assume you'll bump the copyright header before integrating as this is the first change to a few of these files. I agree it should be easy to merge with Adam's update . ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13106#pullrequestreview-1349278021 From alanb at openjdk.org Mon Mar 20 19:56:57 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 20 Mar 2023 19:56:57 GMT Subject: RFR: 8294972: Convert jdk.jlink internal plugins to use the Classfile API [v14] In-Reply-To: <0efK-pRtx-xkeOMKMEZBRcwFOoNFphU3Nubw9shBVIc=.42e2cb69-7ad9-4f23-9d23-2a95f6738753@github.com> References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com> <0efK-pRtx-xkeOMKMEZBRcwFOoNFphU3Nubw9shBVIc=.42e2cb69-7ad9-4f23-9d23-2a95f6738753@github.com> Message-ID: On Mon, 20 Mar 2023 16:00:40 GMT, Adam Sotona wrote: >> jdk.jlink internal plugins are heavily using ASM >> >> This patch converts ASM calls to Classfile API. >> >> Please review. >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > fixed SystemModulesClassGenerator.moduleInfos comment src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 1021: > 1019: MethodTypeDesc.of(CD_void, CD_String)) > 1020: .astore(BUILDER_VAR) > 1021: .aload(BUILDER_VAR); The methods to generate the MD all load the Builder onto the operand stack so the aload at L1021 is catching my attention, is that needed? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12944#discussion_r1142612188 From sspitsyn at openjdk.org Mon Mar 20 19:58:51 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 20 Mar 2023 19:58:51 GMT Subject: Integrated: 8304303: implement VirtualThread class notifyJvmti methods as C2 intrinsics In-Reply-To: <-Pt3zLSu1Y2GYeM8XEivglUyDVXlAqMIA42-_zEnHlo=.7dd40f19-160a-4f11-8702-99c69a9b9923@github.com> References: <-Pt3zLSu1Y2GYeM8XEivglUyDVXlAqMIA42-_zEnHlo=.7dd40f19-160a-4f11-8702-99c69a9b9923@github.com> Message-ID: <2QSQ5C7cdI-KgoFNa3aLqdYQQbLMY7P3qrKvVMsN86I=.503493f9-d9d0-4bff-b8a0-f95f82d412bb@github.com> On Thu, 16 Mar 2023 05:03:51 GMT, Serguei Spitsyn wrote: > This is needed for future performance/scalability improvements in JVMTI support of virtual threads. > The update includes the following: > > 1. Refactored the `VirtualThread` native methods: > `notifyJvmtiMountBegin` and `notifyJvmtiMountEnd` => `notifyJvmtiMount` > `notifyJvmtiUnmountBegin` and `notifyJvmtiUnmountEnd` => `notifyJvmtiUnmount` > 2. Still useful implementation of old native methods is moved from `jvm.cpp` to `jvmtiThreadState.cpp`: > `JVM_VirtualThreadMountStart` => `VTMS_mount_begin` > `JVM_VirtualThreadMountEnd` => `VTMS_mount_end` > `JVM_VirtualThreadUnmountStart` = > `VTMS_unmount_begin` > `JVM_VirtualThreadUnmountEnd` => `VTMS_mount_end` > 3. Intrinsified the `VirtualThread` native methods: `notifyJvmtiMount`, `notifyJvmtiUnmount`, `notifyJvmtiHideFrames`. > 4. Removed the`VirtualThread` static boolean state variable `notifyJvmtiEvents` and its support in `javaClasses`. > 5. Added static boolean state variable `_VTMS_notify_jvmti_events` to the jvmtiVTMSTransitionDisabler class as a replacement of the `VirtualThread` `notifyJvmtiEvents` variable. > > Implementing the same methods as C1 intrinsics can be needed in the future but is a low priority for now. > > Testing: > - Ran mach5 tiers 1-6. No regressions were found. This pull request has now been integrated. Changeset: bc0ed730 Author: Serguei Spitsyn URL: https://git.openjdk.org/jdk/commit/bc0ed730f2c9dad55d0046b4fe8c9cd623b6dbf8 Stats: 449 lines in 20 files changed: 276 ins; 125 del; 48 mod 8304303: implement VirtualThread class notifyJvmti methods as C2 intrinsics Reviewed-by: vlivanov, lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/13054 From mchung at openjdk.org Mon Mar 20 20:19:20 2023 From: mchung at openjdk.org (Mandy Chung) Date: Mon, 20 Mar 2023 20:19:20 GMT Subject: RFR: JDK-8304542: Convert use of internal VM::classFileVersion to ClassFileFormatVersion [v2] In-Reply-To: <8DEcPyyKgl_ZdtGKBw7knC4D_bjzsW4NgGcAxtzv2Dk=.73dc3efd-eff2-43a6-8853-d70e66a7d9b9@github.com> References: <8DEcPyyKgl_ZdtGKBw7knC4D_bjzsW4NgGcAxtzv2Dk=.73dc3efd-eff2-43a6-8853-d70e66a7d9b9@github.com> Message-ID: > Replace calls to `jdk.internal.vm.VM::classFileVersion` with `java.lang.reflect.ClassFileFormatVersion.latest().major()`. This also fixes jlink SystemModulesPlugin plugin to use CFFV API instead of hardcoding the class file version. Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: update copyright header ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13106/files - new: https://git.openjdk.org/jdk/pull/13106/files/4a6de284..027a82f8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13106&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13106&range=00-01 Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/13106.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13106/head:pull/13106 PR: https://git.openjdk.org/jdk/pull/13106 From naoto at openjdk.org Mon Mar 20 20:23:54 2023 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 20 Mar 2023 20:23:54 GMT Subject: Integrated: 8303018: Unicode Emoji Properties In-Reply-To: References: Message-ID: <1QVsE5ZlGTvk2JJt5nw7pj_hb2gAJXbSZu1y4kUyMOQ=.888c5fee-b445-4b93-8027-c135818a1377@github.com> On Mon, 13 Mar 2023 21:16:24 GMT, Naoto Sato wrote: > Proposing accessor methods to Emoji properties defined in [Unicode Technical Standard #51](https://unicode.org/reports/tr51/) in `java.lang.Character` class. This is per a request from the client group, as well as refining the currently existing ad-hoc emoji implementation in regex. A CSR has also been drafted, and I would appreciate reviews for it too. This pull request has now been integrated. Changeset: f593a6b5 Author: Naoto Sato URL: https://git.openjdk.org/jdk/commit/f593a6b52ee7161f7d63bfaf04062551c1281e61 Stats: 897 lines in 19 files changed: 619 ins; 254 del; 24 mod 8303018: Unicode Emoji Properties Reviewed-by: prr, erikj, rriggs ------------- PR: https://git.openjdk.org/jdk/pull/13006 From jlaskey at openjdk.org Mon Mar 20 20:31:46 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 20 Mar 2023 20:31:46 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v46] In-Reply-To: References: Message-ID: > Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). Jim Laskey has updated the pull request incrementally with two additional commits since the last revision: - Tidy javadoc - Rename StringTemplate classes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10889/files - new: https://git.openjdk.org/jdk/pull/10889/files/d6947fd4..9ba6400d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=45 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=44-45 Stats: 2086 lines in 54 files changed: 874 ins; 1075 del; 137 mod Patch: https://git.openjdk.org/jdk/pull/10889.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/10889/head:pull/10889 PR: https://git.openjdk.org/jdk/pull/10889 From mchung at openjdk.org Mon Mar 20 23:27:52 2023 From: mchung at openjdk.org (Mandy Chung) Date: Mon, 20 Mar 2023 23:27:52 GMT Subject: Integrated: JDK-8304542: Convert use of internal VM::classFileVersion to ClassFileFormatVersion In-Reply-To: <8DEcPyyKgl_ZdtGKBw7knC4D_bjzsW4NgGcAxtzv2Dk=.73dc3efd-eff2-43a6-8853-d70e66a7d9b9@github.com> References: <8DEcPyyKgl_ZdtGKBw7knC4D_bjzsW4NgGcAxtzv2Dk=.73dc3efd-eff2-43a6-8853-d70e66a7d9b9@github.com> Message-ID: On Mon, 20 Mar 2023 18:44:24 GMT, Mandy Chung wrote: > Replace calls to `jdk.internal.vm.VM::classFileVersion` with `java.lang.reflect.ClassFileFormatVersion.latest().major()`. This also fixes jlink SystemModulesPlugin plugin to use CFFV API instead of hardcoding the class file version. This pull request has now been integrated. Changeset: bbca7c3e Author: Mandy Chung URL: https://git.openjdk.org/jdk/commit/bbca7c3ede338a04d140abfe3e19cb27c628a0f5 Stats: 26 lines in 5 files changed: 5 ins; 12 del; 9 mod 8304542: Convert use of internal VM::classFileVersion to ClassFileFormatVersion Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/13106 From bhuang at openjdk.org Mon Mar 20 23:29:25 2023 From: bhuang at openjdk.org (Bill Huang) Date: Mon, 20 Mar 2023 23:29:25 GMT Subject: RFR: JDK-8295859 Update Manual Test Groups [v2] In-Reply-To: References: Message-ID: <3KeJLP761daIyT87slqdEryg-DaoCH8FcjwzxaVfxIY=.ada66a7b-8cd6-4a8e-bbc2-a185ea5fc7c5@github.com> > The purpose of this task is to add the difference between -manual jdk_core and jdk_core_manual to the jdk_core_manual test goal. Furthermore, in order to streamline the manual test execution process, a new test group called jdk_core_manual_human has been created for manual tests that demand extra preparation or test input. Bill Huang has updated the pull request incrementally with one additional commit since the last revision: Implemented review comments. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12840/files - new: https://git.openjdk.org/jdk/pull/12840/files/361985ba..32496d97 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12840&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12840&range=00-01 Stats: 7 lines in 1 file changed: 0 ins; 6 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12840.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/12840/head:pull/12840 PR: https://git.openjdk.org/jdk/pull/12840 From psandoz at openjdk.org Mon Mar 20 23:33:41 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Mon, 20 Mar 2023 23:33:41 GMT Subject: RFR: 8304265: Implementation of Foreign Function and Memory API (Third Preview) In-Reply-To: References: Message-ID: On Fri, 17 Mar 2023 15:42:56 GMT, Per Minborg wrote: > API changes for the FFM API (third preview) > > Specdiff: > https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html > > Javadoc: > https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html src/java.base/share/classes/java/lang/foreign/AddressLayout.java line 93: > 91: * @apiNote > 92: * This method can also be used to create an address layout which, when used, creates native memory > 93: * segments with maximal size (e.g. {@linkplain Long#MAX_VALUE}. This can be done by using a target sequence Suggestion: * segments with maximal size (e.g. {@linkplain Long#MAX_VALUE}). This can be done by using a target sequence ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1142769618 From smarks at openjdk.org Mon Mar 20 23:44:47 2023 From: smarks at openjdk.org (Stuart Marks) Date: Mon, 20 Mar 2023 23:44:47 GMT Subject: RFR: 8266571: Sequenced Collections Message-ID: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com> PR for Sequenced Collections implementation. ------------- Commit messages: - Specification cleanups. - Update spec of CopyOnWriteArrayList::reversed. - Move AbstractViewCollection to AbstractMap.ViewCollection to avoid exposing it publicly. - Merge branch 'master' into JDK-8266571-SequencedCollections - Merge branch 'master' into JDK-8266571-SequencedCollections - Fix indentation. - Merge branch 'master' into JDK-8266571-SequencedCollections - Add thread-safe reversed view of CopyOnWriteArrayList - Add CopyOnWriteArrayList to the tests. - Add ListIterator and subList ListIterator modification tests. - ... and 64 more: https://git.openjdk.org/jdk/compare/21169285...31f7d102 Changes: https://git.openjdk.org/jdk/pull/7387/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=7387&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8266571 Stats: 6524 lines in 34 files changed: 6410 ins; 9 del; 105 mod Patch: https://git.openjdk.org/jdk/pull/7387.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/7387/head:pull/7387 PR: https://git.openjdk.org/jdk/pull/7387 From emcmanus at openjdk.org Mon Mar 20 23:44:49 2023 From: emcmanus at openjdk.org (Eamonn McManus) Date: Mon, 20 Mar 2023 23:44:49 GMT Subject: RFR: 8266571: Sequenced Collections In-Reply-To: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com> References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com> Message-ID: On Tue, 8 Feb 2022 17:23:38 GMT, Stuart Marks wrote: > PR for Sequenced Collections implementation. Yes, I think this `LinkedHashMap.keySet()` change is binary compatible but source incompatible. Surely binary incompatibility would have been enough to rule it out immediately. For the source compatibility question, I found at least these four examples that it would break, using [this SourceGraph query](https://sourcegraph.com/search?q=context:global+extends+LinkedHashMap+AND+keySet%28%29+%7B&patternType=literal): * [`ConcurrentModificationThrowingMap`](https://sourcegraph.com/github.com/spring-projects/spring-boot/-/blob/spring-boot-project/spring-boot/src/test/java/org/springframework/boot/context/properties/source/SpringIterableConfigurationPropertySourceTests.java?L288:17&subtree=true) (in a test) * [`GroupedMap`](https://sourcegraph.com/github.com/dromara/hutool/-/blob/hutool-setting/src/main/java/cn/hutool/setting/GroupedMap.java?L230) * [`BoundedConcurrentHashMap`](https://sourcegraph.com/github.com/debezium/debezium/-/blob/debezium-core/src/main/java/io/debezium/util/BoundedConcurrentHashMap.java?L2100:19-2100:25) * [`NutMap`](https://sourcegraph.com/github.com/nutzam/nutz/-/blob/src/org/nutz/lang/util/NutMap.java?L354:24-354:30) So while probably not very widespread, there are certainly examples that this will break. (I didn't find any examples in Google's internal source base.) Perhaps instead `LinkedHashMap` should acquire a new method `SequencedSet sequencedKeySet()`. Or perhaps `SequencedMap` should acquire that method. I'm sure you've noticed the parallel with `NavigableMap.navigableKeySet()`. Unlike `NavigableMap`, it would also be straightforward to understand `SequencedSet> sequencedEntrySet()`. src/java.base/share/classes/java/util/LinkedHashMap.java line 604: > 602: * @return a set view of the keys contained in this map > 603: */ > 604: public SequencedSet keySet() { Changing the return type means that subclasses of `LinkedHashMap` that override `keySet()` will no longer compile, unless they also change the return type. ------------- PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1098605810 PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r848817204 From smarks at openjdk.org Mon Mar 20 23:44:50 2023 From: smarks at openjdk.org (Stuart Marks) Date: Mon, 20 Mar 2023 23:44:50 GMT Subject: RFR: 8266571: Sequenced Collections In-Reply-To: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com> References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com> Message-ID: On Tue, 8 Feb 2022 17:23:38 GMT, Stuart Marks wrote: > PR for Sequenced Collections implementation. I'm not convinced it's binary compatible. :-) Perhaps this particular case is, but there are a bunch of other cases (additional subclasses, etc.) that need to be considered. Thanks for the SourceGraph query. I'll take a look at those. The fallback position is to do something like NavigableMap and provide the SequencedX-returning methods with different names, avoiding covariant overrides. I was discussing this with KevinB not long ago and he said this would make him sad. It would make me sad too. :-) But it might be a forced move; I'm not convinced it's possible to add covariant overrides into a hierarchy as widely used and subclassed as the collections framework without introducing unacceptable incompatibilities. Still working on compatibility analysis. See compatibility report attached to the CSR [JDK-8266572](https://bugs.openjdk.org/browse/JDK-8266572). Summary of recent design changes: 1. Covariant override restored for `Deque::reversed`. It turns out that `LinkedList` (and other classes that inherit conflicting default methods because they implement both `List` and `Deque`) can resolve this conflict by providing a covariant override that returns a subtype of `List` and `Deque`. 2. Added `SequencedMap` interface retrofitted above `LinkedHashMap` and `SortedMap`. 3. Removed covariant override proposal for `Map` view methods `keySet`, `values`, and `entrySet`. These methods will remain as-is. New methods `sequencedKeySet`, `sequencedValues`, and `sequencedEntrySet` are introduced that return the sequenced types. > I might take another swing at this and see if there's a way to get throwing [methods] into SequencedMap. The problem is that `firstKey` throws if empty but `firstEntry` returns `null` if empty. So to make things consistently throwing, we'd need to add `getFirst`/`LastEntry` and `removeFirst`/`LastEntry` to `SequencedMap` (and probably get rid of some of the other methods). This would make `SequencedMap` and probably `LinkedHashMap` fairly nice, but it would clutter up `NavigableMap`. After some more consultation and thinking, I've decided not to do this. We can't make things fully consistent; we can only choose where to put the inconsistency. Currently, `List` has throwing-style methods. For example, to remove the first element, you need to do `list.remove(0)`. Of course this throws if the list is empty, so code must check first. It thus makes sense to have `removeFirst` be a throwing method. (`NavigableSet` uses a mixture of throwing and null-returning, but `List` is used an order of magnitude more frequently so we'll follow `List`.) By contrast, `Map` doesn't have any throwing-style methods. Methods like `get` and `remove` return `null` if the requested key isn't present (which is the case if the map is empty). All of the navigation methods on `NavigableMap` also return `null` if the map is empty or if the element isn't present. Thus, adding throwing methods will do a fair amount of damage to `NavigableMap`. The real outliers are `firstKey` and `lastKey`, which throw if the map is empty. They're defined on `SortedMap`. These don't actually add much, but they do add some confusion and inconsistency, so I think it would actually be helpful to remove them from `SequencedMap`. Specdiff posted: https://cr.openjdk.org/~smarks/collections/specdiff-sequenced-20230316/overview-summary.html ------------- PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1099824260 PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1162132964 PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1253162447 PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1253163561 PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1307810991 PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1474442816 From liach at openjdk.org Mon Mar 20 23:44:54 2023 From: liach at openjdk.org (Chen Liang) Date: Mon, 20 Mar 2023 23:44:54 GMT Subject: RFR: 8266571: Sequenced Collections In-Reply-To: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com> References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com> Message-ID: On Tue, 8 Feb 2022 17:23:38 GMT, Stuart Marks wrote: > PR for Sequenced Collections implementation. Since we added reversal to deque, can we add notes to a few Collections APIs like `Collections::asLifoQueue` about this newer alternative? Also on using `reverse` on the list view than actually reversing a whole list. In addition, the new methods should have `@since 20` tags, such as on `LinkedList::reversed`, `SortedSet::addFirst`. Other similar methods are version-tagged, like `Collection::spliterator` or `Method::getParameterCount`. Is there a particular reason we define poll (null on empty) in SequencedMap but remove (NSEE on empty) in SequencedCollection? I understand that SequencedCollection doesn't want to be null-ambiguous, and map entries are non-null so poll there is not ambiguous. But I still think using remove for both look more consistent. Just curious, will sequenced collections be delivered directly or will it incubate/preview first? src/java.base/share/classes/java/util/Collections.java line 1211: > 1209: * @param s the set for which an unmodifiable view is to be returned. > 1210: * @return an unmodifiable view of the specified set. > 1211: * @since 20 Extraneous and wrong Suggestion: src/java.base/share/classes/java/util/Collections.java line 1248: > 1246: * @param s the set for which an unmodifiable view is to be returned. > 1247: * @return an unmodifiable view of the specified sequenced set. > 1248: */ Suggestion: * @since 20 */ The last one was misplaced. src/java.base/share/classes/java/util/Collections.java line 5980: > 5978: * an eviction policy, which is not possible with a {@code LinkedHashSet}. > 5979: * > 5980: * 

{@code

Can we upgrade this to a snippet?

src/java.base/share/classes/java/util/SortedSet.java line 303:

> 301:      * @since 20
> 302:      */
> 303:     default E removeFirst() {

Should removeFirst/removeLast be overridden in NavigableSet with a new default implementation like:

    if (this.isEmpty()) {
        throw new NoSuchElementException();
    }
    return this.pollFirst();

which is probably slightly more efficient?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1253174627
PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1302239328
PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1475519496
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1012461962
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1012462289
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1139631921
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1013372259

From smarks at openjdk.org  Mon Mar 20 23:44:54 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 20 Mar 2023 23:44:54 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
Message-ID: <_buWu3J8JtJ9JaIzoHAhQXkkmK7GZAFYfOTAo_EoO08=.23d0f03c-af2d-4655-a433-4574d9277c05@github.com>

On Wed, 21 Sep 2022 04:01:13 GMT, Chen Liang  wrote:

>> PR for Sequenced Collections implementation.
>
> Since we added reversal to deque, can we add notes to a few Collections APIs like `Collections::asLifoQueue` about this newer alternative? Also on using `reverse` on the list view than actually reversing a whole list.
> 
> In addition, the new methods should have `@since 20` tags, such as on `LinkedList::reversed`, `SortedSet::addFirst`. Other similar methods are version-tagged, like `Collection::spliterator` or `Method::getParameterCount`.

@liach 

> Since we added reversal to deque, can we add notes to a few Collections APIs like `Collections::asLifoQueue` about this newer alternative? Also on using `reverse` on the list view than actually reversing a whole list.
> 
> In addition, the new methods should have `@since 20` tags, such as on `LinkedList::reversed`, `SortedSet::addFirst`. Other similar methods are version-tagged, like `Collection::spliterator` or `Method::getParameterCount`.

Good points. I've added a API notes to asLifeQueue and reverse, and I've added a bunch of @since tags. Let me know if you find other places that need them.

> Is there a particular reason we define poll (null on empty) in SequencedMap but remove (NSEE on empty) in SequencedCollection?
> 
> I understand that SequencedCollection doesn't want to be null-ambiguous, and map entries are non-null so poll there is not ambiguous. But I still think using remove for both look more consistent.

@liach 

> Is there a particular reason we define poll (null on empty) in SequencedMap but remove (NSEE on empty) in SequencedCollection?
> 
> I understand that SequencedCollection doesn't want to be null-ambiguous, and map entries are non-null so poll there is not ambiguous. But I still think using remove for both look more consistent.

Yes, this is definitely an asymmetry. I did it this way to avoid proliferation of new methods, so I just promoted existing ones from NavigableMap into SequencedMap. But I might take another swing at this and see if there's a way to get throwing versions into SequencedMap. The problem is that `firstKey` throws if empty but `firstEntry` returns null if empty. So to make things consistently throwing, we'd need to add `getFirst/LastEntry` and `removeFirst/LastEntry` to SequencedMap (and probably get rid of some of the other methods). This would make SequencedMap and probably LinkedHashMap fairly nice, but it would clutter up NavigableMap.

> Just curious, will sequenced collections be delivered directly or will it incubate/preview first?

No plans to preview. (If it were for preview, the JEP would state that prominently.)

> src/java.base/share/classes/java/util/Collections.java line 1248:
> 
>> 1246:      * @param  s the set for which an unmodifiable view is to be returned.
>> 1247:      * @return an unmodifiable view of the specified sequenced set.
>> 1248:      */
> 
> Suggestion:
> 
>      * @since 20
>      */
> 
> The last one was misplaced.

Oops, good catch. Will fix.

> src/java.base/share/classes/java/util/Collections.java line 5980:
> 
>> 5978:      * an eviction policy, which is not possible with a {@code LinkedHashSet}.
>> 5979:      *
>> 5980:      * 
{@code
> 
> Can we upgrade this to a snippet?

At some point yes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1301524326
PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1304414879
PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1476757813
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1014575871
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1140749658

From duke at openjdk.org  Mon Mar 20 23:44:54 2023
From: duke at openjdk.org (ExE Boss)
Date: Mon, 20 Mar 2023 23:44:54 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: <_buWu3J8JtJ9JaIzoHAhQXkkmK7GZAFYfOTAo_EoO08=.23d0f03c-af2d-4655-a433-4574d9277c05@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
 <_buWu3J8JtJ9JaIzoHAhQXkkmK7GZAFYfOTAo_EoO08=.23d0f03c-af2d-4655-a433-4574d9277c05@github.com>
Message-ID: <5ycXBFbEmUgNzCNXu4EO8Cu4HuPAFafv87Tjh4E8T38=.83f346af-3604-42d4-a7a8-1f9622e06faa@github.com>

On Sat, 5 Nov 2022 05:44:42 GMT, Stuart Marks  wrote:

>> Is there a particular reason we define poll (null on empty) in SequencedMap but remove (NSEE on empty) in SequencedCollection?
>> 
>> I understand that SequencedCollection doesn't want to be null-ambiguous, and map entries are non-null so poll there is not ambiguous. But I still think using remove for both look more consistent.
>
> @liach 
> 
>> Is there a particular reason we define poll (null on empty) in SequencedMap but remove (NSEE on empty) in SequencedCollection?
>> 
>> I understand that SequencedCollection doesn't want to be null-ambiguous, and map entries are non-null so poll there is not ambiguous. But I still think using remove for both look more consistent.
> 
> Yes, this is definitely an asymmetry. I did it this way to avoid proliferation of new methods, so I just promoted existing ones from NavigableMap into SequencedMap. But I might take another swing at this and see if there's a way to get throwing versions into SequencedMap. The problem is that `firstKey` throws if empty but `firstEntry` returns null if empty. So to make things consistently throwing, we'd need to add `getFirst/LastEntry` and `removeFirst/LastEntry` to SequencedMap (and probably get rid of some of the other methods). This would make SequencedMap and probably LinkedHashMap fairly nice, but it would clutter up NavigableMap.

@stuart-marks
> The problem is that `firstKey` throws if empty but `firstEntry` returns null if empty.

That?s?because there?s?no?way for?`firstKey` to?distinguish `null` as?meaning an?`Entry` where?`getKey()` returns?`null`, and?`null` meaning?no?mapping.

Whereas?with `firstEntry`, `null`?can?only be?returned when?the?map is?empty, because?a?`null`?key mapped?to?some?value would?return `Entry[key=null,?value=?]`.

--------------------------------------------------------------------------------

Another?way to?think about?it is?that the?default?implementation of?`firstKey()`?does:

default K firstKey() {
	return this.firstEntry().getKey();
}

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1304500566

From smarks at openjdk.org  Mon Mar 20 23:44:55 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 20 Mar 2023 23:44:55 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: <5ycXBFbEmUgNzCNXu4EO8Cu4HuPAFafv87Tjh4E8T38=.83f346af-3604-42d4-a7a8-1f9622e06faa@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
 <_buWu3J8JtJ9JaIzoHAhQXkkmK7GZAFYfOTAo_EoO08=.23d0f03c-af2d-4655-a433-4574d9277c05@github.com>
 <5ycXBFbEmUgNzCNXu4EO8Cu4HuPAFafv87Tjh4E8T38=.83f346af-3604-42d4-a7a8-1f9622e06faa@github.com>
Message-ID: <5kO1_VDAVk46brVemeITov9k-T9RUjWZCkYQ2KLQ0Es=.0cfd78d2-8785-42e2-9b4a-cd71efb5d0a7@github.com>

On Sat, 5 Nov 2022 11:17:04 GMT, ExE Boss  wrote:

>> @liach 
>> 
>>> Is there a particular reason we define poll (null on empty) in SequencedMap but remove (NSEE on empty) in SequencedCollection?
>>> 
>>> I understand that SequencedCollection doesn't want to be null-ambiguous, and map entries are non-null so poll there is not ambiguous. But I still think using remove for both look more consistent.
>> 
>> Yes, this is definitely an asymmetry. I did it this way to avoid proliferation of new methods, so I just promoted existing ones from NavigableMap into SequencedMap. But I might take another swing at this and see if there's a way to get throwing versions into SequencedMap. The problem is that `firstKey` throws if empty but `firstEntry` returns null if empty. So to make things consistently throwing, we'd need to add `getFirst/LastEntry` and `removeFirst/LastEntry` to SequencedMap (and probably get rid of some of the other methods). This would make SequencedMap and probably LinkedHashMap fairly nice, but it would clutter up NavigableMap.
>
> @stuart-marks
>> The problem is that `firstKey` throws if empty but `firstEntry` returns null if empty.
> 
> That?s?because there?s?no?way for?`firstKey` to?distinguish `null` as?meaning an?`Entry` where?`getKey()` returns?`null`, and?`null` meaning?no?mapping.
> 
> Whereas?with `firstEntry`, `null`?can?only be?returned when?the?map is?empty, because?a?`null`?key mapped?to?some?value would?return `Entry[key=null,?value=?]`.
> 
> --------------------------------------------------------------------------------
> 
> Another?way to?think about?it is?that the?default?implementation of?`firstKey()`?does:
> 
> default K firstKey() {
> 	return this.firstEntry().getKey();
> }

@ExE-Boss Yes, I'm aware of the problem if `firstKey` were to return null. (Didn't prevent `Map::get` from being added though.) The problem I was referring to was one of consistency. We have an uncomfortable mixture of throwing things and null-returning things. The challenge is to come up with a reasonable set of things that makes internal sense and that also fits with what's there already. This might not be possible. Thus, some tradeoffs are necessary.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1304678458

From sadayapalam at openjdk.org  Mon Mar 20 23:44:56 2023
From: sadayapalam at openjdk.org (Srikanth Adayapalam)
Date: Mon, 20 Mar 2023 23:44:56 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
Message-ID: 

On Tue, 8 Feb 2022 17:23:38 GMT, Stuart Marks  wrote:

> PR for Sequenced Collections implementation.

Please include the following fix for the langtools test "failures": 


diff --git a/test/langtools/tools/javac/api/TestJavacTaskScanner.java b/test/langtools/tools/javac/api/TestJavacTaskScanner.java
index e8110396dac..8d53c3b9d6f 100644
--- a/test/langtools/tools/javac/api/TestJavacTaskScanner.java
+++ b/test/langtools/tools/javac/api/TestJavacTaskScanner.java
@@ -102,7 +102,7 @@ public class TestJavacTaskScanner extends ToolTester {
         System.out.println("#allMembers: " + numAllMembers);
 
         check(numTokens, "#Tokens", 1054);
- check(numParseTypeElements, "#parseTypeElements", 158);
+ check(numParseTypeElements, "#parseTypeElements", 170);
         check(numAllMembers, "#allMembers", 52);
     }
 diff --git a/test/langtools/tools/javac/processing/model/type/BoundsTest.java b/test/langtools/tools/javac/processing/model/type/BoundsTest.java
index b7e9121a956..c47b7a7de92 100644
--- a/test/langtools/tools/javac/processing/model/type/BoundsTest.java
+++ b/test/langtools/tools/javac/processing/model/type/BoundsTest.java
@@ -70,7 +70,7 @@ public class BoundsTest {
     };
     private static final String[] Single_supers = {
         "java.lang.Object",
- "java.util.Collection"
+ "java.util.SequencedCollection"
     };

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1306689463

From smarks at openjdk.org  Mon Mar 20 23:44:56 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 20 Mar 2023 23:44:56 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
Message-ID: 

On Tue, 8 Nov 2022 06:15:48 GMT, Srikanth Adayapalam  wrote:

>> PR for Sequenced Collections implementation.
>
> Please include the following fix for the langtools test "failures": 
> 
> 
> diff --git a/test/langtools/tools/javac/api/TestJavacTaskScanner.java b/test/langtools/tools/javac/api/TestJavacTaskScanner.java
> index e8110396dac..8d53c3b9d6f 100644
> --- a/test/langtools/tools/javac/api/TestJavacTaskScanner.java
> +++ b/test/langtools/tools/javac/api/TestJavacTaskScanner.java
> @@ -102,7 +102,7 @@ public class TestJavacTaskScanner extends ToolTester {
>          System.out.println("#allMembers: " + numAllMembers);
>  
>          check(numTokens, "#Tokens", 1054);
> - check(numParseTypeElements, "#parseTypeElements", 158);
> + check(numParseTypeElements, "#parseTypeElements", 170);
>          check(numAllMembers, "#allMembers", 52);
>      }
>  diff --git a/test/langtools/tools/javac/processing/model/type/BoundsTest.java b/test/langtools/tools/javac/processing/model/type/BoundsTest.java
> index b7e9121a956..c47b7a7de92 100644
> --- a/test/langtools/tools/javac/processing/model/type/BoundsTest.java
> +++ b/test/langtools/tools/javac/processing/model/type/BoundsTest.java
> @@ -70,7 +70,7 @@ public class BoundsTest {
>      };
>      private static final String[] Single_supers = {
>          "java.lang.Object",
> - "java.util.Collection"
> + "java.util.SequencedCollection"
>      };

@sadayapalam

> Please include the following fix for the langtools test "failures":

OK, applying these patches lets the tests pass. I can include them in this PR.

The patch in TestJavacTaskScanner.java adjusts the expected number of elements from 158 to 170, but I note that the error message in the test failure is

    java.lang.Error: #parseTypeElements higher than expected; expected 158; found: 180

The test still passes with the expected value of 170, as the criterion seems to be that the actual number be within 10% of the expected number. Since the actual number is 180, though, would it be better to use 180?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1307795998

From duke at openjdk.org  Mon Mar 20 23:45:00 2023
From: duke at openjdk.org (ExE Boss)
Date: Mon, 20 Mar 2023 23:45:00 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
Message-ID: 

On Tue, 8 Feb 2022 17:23:38 GMT, Stuart Marks  wrote:

> PR for Sequenced Collections implementation.

Note?that `SortedMap::firstKey` and?`SortedMap::lastKey` can?now both?have a?default?implementation that?delegates to?`SequencedMap::firstEntry` and?`SequencedMap::lastEntry` respectively.

src/java.base/share/classes/java/util/SequencedMap.java line 343:

> 341:         return new SeqEntrySet();
> 342:     }
> 343: }

Missing trailing newline:
Suggestion:

}

src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java line 554:

> 552:     public E removeLast() {
> 553:         synchronized (lock) {
> 554:            int size = getArray().length;

Wrong?indentation:
Suggestion:

            int size = getArray().length;

(this?would be?avoided if?the?JDK was?using the?more accessible?tabs[^1])

[^1]: prettier/prettier#7475

src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java line 1734:

> 1732:                     it = base.listIterator(base.size());
> 1733:                 }
> 1734:             }

Storing?the?`size` in?a?field allows?`Reversed::stream().estimateSize()` to?match `Reversed::size()`:
Suggestion:

            final ListIterator it;
            final int size;

            DescendingIterator() {
                synchronized (lock) {
                    size = base.size();
                    it = base.listIterator(size);
                }
            }

src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java line 1803:

> 1801:         public Spliterator spliterator() {
> 1802:             // TODO can probably improve this
> 1803:             return Spliterators.spliteratorUnknownSize(new DescendingIterator(), 0);

Suggestion:

            var it = new DescendingIterator();
            return Spliterators.spliterator(
                    it, it.size,
                    Spliterator.IMMUTABLE | Spliterator.ORDERED);

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1308200115
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1139871748
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1103614429
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1103615024
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1103615337

From sadayapalam at openjdk.org  Mon Mar 20 23:45:01 2023
From: sadayapalam at openjdk.org (Srikanth Adayapalam)
Date: Mon, 20 Mar 2023 23:45:01 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
 
Message-ID: 

On Tue, 8 Nov 2022 20:36:40 GMT, Stuart Marks  wrote:

> @sadayapalam
> 
> > Please include the following fix for the langtools test "failures":
> 
> OK, applying these patches lets the tests pass. I can include them in this PR.
> 
> The patch in TestJavacTaskScanner.java adjusts the expected number of elements from 158 to 170, but I note that the error message in the test failure is
> 
> ```
> java.lang.Error: #parseTypeElements higher than expected; expected 158; found: 180
> ```
> 
> The test still passes with the expected value of 170, as the criterion seems to be that the actual number be within 10% of the expected number. Since the actual number is 180, though, would it be better to use 180?

Perhaps. The fudge factor seems to be implemented to prepare for a potential move downwards as well as upwards.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1308300571

From psandoz at openjdk.org  Mon Mar 20 23:45:03 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 20 Mar 2023 23:45:03 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
Message-ID: 

On Tue, 8 Feb 2022 17:23:38 GMT, Stuart Marks  wrote:

> PR for Sequenced Collections implementation.

src/java.base/share/classes/java/util/Collections.java line 376:

> 374:      * reversed-ordered view of a list without mutating it, use the
> 375:      * {@link List#reversed List::reversed} method.
> 376:      *

Also add `@see ` reference

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1140817943

From duke at openjdk.org  Mon Mar 20 23:45:04 2023
From: duke at openjdk.org (Viktor Klang)
Date: Mon, 20 Mar 2023 23:45:04 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
Message-ID: 

On Tue, 8 Feb 2022 17:23:38 GMT, Stuart Marks  wrote:

> PR for Sequenced Collections implementation.

src/java.base/share/classes/java/util/LinkedHashMap.java line 384:

> 382:             return this.put(k, v);
> 383:         } finally {
> 384:             putMode = PUT_NORM;

@stuart-marks Would it be an alternative to have an  `internalPut(mode, k, v)` so there is no need to have an internal variable which needs to be read/written multiple time per operation? ?

src/java.base/share/classes/java/util/SequencedCollection.java line 93:

> 91:      * underlying collection. Changes to the underlying collection might or might not be visible
> 92:      * in this reversed view, depending upon the implementation.
> 93:      *

@stuart-marks Perhaps an opportunity to spec it so that x == x.reversed().reversed() (i.e. unwrap on double-reverse)?

src/java.base/share/classes/java/util/SequencedCollection.java line 155:

> 153:      */
> 154:     default E getLast() {
> 155:         return this.reversed().iterator().next();

@stuart-marks Are these default implementation expected to be used (actually) in the JDK? From a performance PoV, it might make sense to not have default implementations unless strictly needed, and instead keep the code in the JavaDoc as a guideline for "worst-case" performance profile. ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r987925904
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r986962055
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r987216743

From smarks at openjdk.org  Mon Mar 20 23:45:05 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 20 Mar 2023 23:45:05 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
Message-ID: 

On Wed, 5 Oct 2022 13:30:08 GMT, Viktor Klang  wrote:

>> PR for Sequenced Collections implementation.
>
> src/java.base/share/classes/java/util/LinkedHashMap.java line 384:
> 
>> 382:             return this.put(k, v);
>> 383:         } finally {
>> 384:             putMode = PUT_NORM;
> 
> @stuart-marks Would it be an alternative to have an  `internalPut(mode, k, v)` so there is no need to have an internal variable which needs to be read/written multiple time per operation? ?

Yeah, the coupling here is rather distasteful. (Otherwise known as a quick and dirty hack.) Unfortunately the coupling between HashMap and LinkedHashMap is pretty special-purposed for exactly the intended usage modes (insertion-order and access-order). It could be improved, but it would probably require some refactoring in HashMap, which I didn't want to do right now, in order to keep the sequenced stuff separate.

> src/java.base/share/classes/java/util/SequencedCollection.java line 155:
> 
>> 153:      */
>> 154:     default E getLast() {
>> 155:         return this.reversed().iterator().next();
> 
> @stuart-marks Are these default implementation expected to be used (actually) in the JDK? From a performance PoV, it might make sense to not have default implementations unless strictly needed, and instead keep the code in the JavaDoc as a guideline for "worst-case" performance profile. ?

Good question. They might not actually be used in the JDK... but it isn't obvious! In fact some of these methods are used in the `sequencedValues()` view of `SequencedMap`. They could be used if there is a `SortedMap` implementation that doesn't implement `NavigableMap`. I don't think there are any of these in the JDK, but there are "in the wild." Yes, there are potentially performance issues with these, but I think it's valuable to have a complete set of default implementations available.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1012436476
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1012418175

From duke at openjdk.org  Mon Mar 20 23:45:05 2023
From: duke at openjdk.org (ExE Boss)
Date: Mon, 20 Mar 2023 23:45:05 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
 
Message-ID: <0qfhujWfzjkE__6vE_jZMl9RAWx8Or_SSlxTzapfFbY=.661bbf82-17fb-4080-989a-eca9f0f43765@github.com>

On Thu, 3 Nov 2022 01:56:05 GMT, Stuart Marks  wrote:

>> src/java.base/share/classes/java/util/LinkedHashMap.java line 384:
>> 
>>> 382:             return this.put(k, v);
>>> 383:         } finally {
>>> 384:             putMode = PUT_NORM;
>> 
>> @stuart-marks Would it be an alternative to have an  `internalPut(mode, k, v)` so there is no need to have an internal variable which needs to be read/written multiple time per operation? ?
>
> Yeah, the coupling here is rather distasteful. (Otherwise known as a quick and dirty hack.) Unfortunately the coupling between HashMap and LinkedHashMap is pretty special-purposed for exactly the intended usage modes (insertion-order and access-order). It could be improved, but it would probably require some refactoring in HashMap, which I didn't want to do right now, in order to keep the sequenced stuff separate.

Another?issue are?custom `LinkedHashMap`?subclasses which?override?`put(?)` to?do?input?validation, which?would get?bypassed by?`internalPut(?)`. A?better?solution to?a?private?field would?be?to?use [JEP?429: Scoped?values].

--------------------------------------------------------------------------------

That?said, using?`internalPut(?)` for?the?case where?`getClass() ==?LinkedHashMap.class` would?probably?be?fine.

[JEP?429: Scoped?values]: https://openjdk.org/jeps/429

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1012574601

From smarks at openjdk.org  Mon Mar 20 23:45:06 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 20 Mar 2023 23:45:06 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: <0qfhujWfzjkE__6vE_jZMl9RAWx8Or_SSlxTzapfFbY=.661bbf82-17fb-4080-989a-eca9f0f43765@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
 
 <0qfhujWfzjkE__6vE_jZMl9RAWx8Or_SSlxTzapfFbY=.661bbf82-17fb-4080-989a-eca9f0f43765@github.com>
Message-ID: <3z3hE-o5561CBnP96pc-NvOUIBo29NhCFb9AnFynU6Y=.6923d115-34f4-494b-989d-7d9d40ab1424@github.com>

On Thu, 3 Nov 2022 07:41:05 GMT, ExE Boss  wrote:

>> Yeah, the coupling here is rather distasteful. (Otherwise known as a quick and dirty hack.) Unfortunately the coupling between HashMap and LinkedHashMap is pretty special-purposed for exactly the intended usage modes (insertion-order and access-order). It could be improved, but it would probably require some refactoring in HashMap, which I didn't want to do right now, in order to keep the sequenced stuff separate.
>
> Another?issue are?custom `LinkedHashMap`?subclasses which?override?`put(?)` to?do?input?validation, which?would get?bypassed by?`internalPut(?)`. A?better?solution to?a?private?field would?be?to?use [JEP?429: Scoped?values].
> 
> --------------------------------------------------------------------------------
> 
> That?said, using?`internalPut(?)` for?the?case where?`getClass() ==?LinkedHashMap.class` would?probably?be?fine.
> 
> [JEP?429: Scoped?values]: https://openjdk.org/jeps/429

Input validation can't really be done in `put()`, since there are a bunch of other paths such as `computeIfAbsent()` that will insert entries without calling `put()`.

I think some judicious refactoring in HashMap to provide better support to LinkedHashMap is called for here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1014576382

From smarks at openjdk.org  Mon Mar 20 23:45:07 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 20 Mar 2023 23:45:07 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
Message-ID: 

On Tue, 12 Apr 2022 19:55:13 GMT, Eamonn McManus  wrote:

>> PR for Sequenced Collections implementation.
>
> src/java.base/share/classes/java/util/LinkedHashMap.java line 604:
> 
>> 602:      * @return a set view of the keys contained in this map
>> 603:      */
>> 604:     public SequencedSet keySet() {
> 
> Changing the return type means that subclasses of `LinkedHashMap` that override `keySet()` will no longer compile, unless they also change the return type.

Yes. Previously compiled binaries will also throw `NoSuchMethodError` if they call `super.keySet()`. Clearly these are incompatibilities; the question is whether they are severe enough to warrant pursuing a different approach. If you have any thoughts about how to assess the severity of this change, please let me know.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r848945910

From duke at openjdk.org  Mon Mar 20 23:45:07 2023
From: duke at openjdk.org (ExE Boss)
Date: Mon, 20 Mar 2023 23:45:07 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
 
Message-ID: <5dL_Rh5ZEG4s04eQrNZorhh2sz0K2W7SL4AxUbWmbVs=.8efd267e-bb8f-4361-aa95-1151f795fcc2@github.com>

On Tue, 12 Apr 2022 23:25:14 GMT, Stuart Marks  wrote:

>> src/java.base/share/classes/java/util/LinkedHashMap.java line 604:
>> 
>>> 602:      * @return a set view of the keys contained in this map
>>> 603:      */
>>> 604:     public SequencedSet keySet() {
>> 
>> Changing the return type means that subclasses of `LinkedHashMap` that override `keySet()` will no longer compile, unless they also change the return type.
>
> Yes. Previously compiled binaries will also throw `NoSuchMethodError` if they call `super.keySet()`. Clearly these are incompatibilities; the question is whether they are severe enough to warrant pursuing a different approach. If you have any thoughts about how to assess the severity of this change, please let me know.

Won?t?`super.keySet()` resolve to?a?bridge?method in?that?case?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r849394986

From smarks at openjdk.org  Mon Mar 20 23:45:07 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 20 Mar 2023 23:45:07 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: <5dL_Rh5ZEG4s04eQrNZorhh2sz0K2W7SL4AxUbWmbVs=.8efd267e-bb8f-4361-aa95-1151f795fcc2@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
 
 <5dL_Rh5ZEG4s04eQrNZorhh2sz0K2W7SL4AxUbWmbVs=.8efd267e-bb8f-4361-aa95-1151f795fcc2@github.com>
Message-ID: <0BBjJX4m4R4hvGBgXI9MJYOOKRRTiH9veEigIsB4LAU=.52e87be1-9a16-494d-90d6-95559721bce5@github.com>

On Wed, 13 Apr 2022 11:53:52 GMT, ExE Boss  wrote:

>> Yes. Previously compiled binaries will also throw `NoSuchMethodError` if they call `super.keySet()`. Clearly these are incompatibilities; the question is whether they are severe enough to warrant pursuing a different approach. If you have any thoughts about how to assess the severity of this change, please let me know.
>
> Won?t?`super.keySet()` resolve to?a?bridge?method in?that?case?

Oh yes, in this case it might resolve to a bridge method, and it might actually work. In this case. However, the compatibility matrix for covariant overrides and bridge methods is quite complex; see

https://mail.openjdk.java.net/pipermail/core-libs-dev/2012-February/009119.html

for why we decided not to add covariant `clone` overrides. Similar issues might arise here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r849809038

From smarks at openjdk.org  Mon Mar 20 23:45:07 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 20 Mar 2023 23:45:07 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: <0BBjJX4m4R4hvGBgXI9MJYOOKRRTiH9veEigIsB4LAU=.52e87be1-9a16-494d-90d6-95559721bce5@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
 
 <5dL_Rh5ZEG4s04eQrNZorhh2sz0K2W7SL4AxUbWmbVs=.8efd267e-bb8f-4361-aa95-1151f795fcc2@github.com>
 <0BBjJX4m4R4hvGBgXI9MJYOOKRRTiH9veEigIsB4LAU=.52e87be1-9a16-494d-90d6-95559721bce5@github.com>
Message-ID: 

On Wed, 13 Apr 2022 19:08:58 GMT, Stuart Marks  wrote:

>> Won?t?`super.keySet()` resolve to?a?bridge?method in?that?case?
>
> Oh yes, in this case it might resolve to a bridge method, and it might actually work. In this case. However, the compatibility matrix for covariant overrides and bridge methods is quite complex; see
> 
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2012-February/009119.html
> 
> for why we decided not to add covariant `clone` overrides. Similar issues might arise here.

For what it's worth, I've done a detailed compatibility analysis of the cases here, and I've decided that adding covariant overrides for keySet/values/entrySet is too dangerous. See the full analysis in the documents attached to the CSR request:

https://bugs.openjdk.org/browse/JDK-8266572

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1012392883

From duke at openjdk.org  Mon Mar 20 23:45:08 2023
From: duke at openjdk.org (Grzegorz Piwowarek)
Date: Mon, 20 Mar 2023 23:45:08 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
Message-ID: <8d7p_kGQQJWXOAkBjVpLuSPBRbY9R7Gs_xpku798Aw8=.44b4465c-cb91-4395-91ab-486fc8022f13@github.com>

On Tue, 8 Feb 2022 17:23:38 GMT, Stuart Marks  wrote:

> PR for Sequenced Collections implementation.

src/java.base/share/classes/java/util/SequencedCollection.java line 84:

> 82:      * the iterator() method, calls next() on it and returns the result.
> 83:      */
> 84:     default E getFirst() {

Too bad there's no `Optional` here, but I assume that's because you don't want to mix two approaches within a class hierarchy?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r956666157

From smarks at openjdk.org  Mon Mar 20 23:45:08 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 20 Mar 2023 23:45:08 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: <8d7p_kGQQJWXOAkBjVpLuSPBRbY9R7Gs_xpku798Aw8=.44b4465c-cb91-4395-91ab-486fc8022f13@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <8d7p_kGQQJWXOAkBjVpLuSPBRbY9R7Gs_xpku798Aw8=.44b4465c-cb91-4395-91ab-486fc8022f13@github.com>
Message-ID: 

On Sun, 28 Aug 2022 05:45:54 GMT, Grzegorz Piwowarek  wrote:

>> PR for Sequenced Collections implementation.
>
> src/java.base/share/classes/java/util/SequencedCollection.java line 84:
> 
>> 82:      * the iterator() method, calls next() on it and returns the result.
>> 83:      */
>> 84:     default E getFirst() {
> 
> Too bad there's no `Optional` here, but I assume that's because you don't want to mix two approaches within a class hierarchy?

I wanted to make `getFirst` et. al. be identical to the methods already in `Deque`, to avoid proliferation of methods.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r957518311

From duke at openjdk.org  Mon Mar 20 23:45:08 2023
From: duke at openjdk.org (Viktor Klang)
Date: Mon, 20 Mar 2023 23:45:08 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
Message-ID: <9_34ZKelWdc1dC_aPGVB9zo4caFdMa2xPmnjlzd94CY=.491ae57b-b117-4372-a71f-4669e2fd3545@github.com>

On Tue, 4 Oct 2022 14:43:44 GMT, Viktor Klang  wrote:

>> PR for Sequenced Collections implementation.
>
> src/java.base/share/classes/java/util/SequencedCollection.java line 93:
> 
>> 91:      * underlying collection. Changes to the underlying collection might or might not be visible
>> 92:      * in this reversed view, depending upon the implementation.
>> 93:      *
> 
> @stuart-marks Perhaps an opportunity to spec it so that x == x.reversed().reversed() (i.e. unwrap on double-reverse)?

@stuart-marks What are examples of cases where it wouldn't be reasonable: https://github.com/openjdk/jdk/pull/7387/files#diff-2b261a88d9ed30893d24186a36ef500d284d82e8f345591fc6c44ed5ae15da4fR161 ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r988048079

From smarks at openjdk.org  Mon Mar 20 23:45:08 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 20 Mar 2023 23:45:08 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: <9_34ZKelWdc1dC_aPGVB9zo4caFdMa2xPmnjlzd94CY=.491ae57b-b117-4372-a71f-4669e2fd3545@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
 <9_34ZKelWdc1dC_aPGVB9zo4caFdMa2xPmnjlzd94CY=.491ae57b-b117-4372-a71f-4669e2fd3545@github.com>
Message-ID: 

On Wed, 5 Oct 2022 15:15:05 GMT, Viktor Klang  wrote:

>> src/java.base/share/classes/java/util/SequencedCollection.java line 93:
>> 
>>> 91:      * underlying collection. Changes to the underlying collection might or might not be visible
>>> 92:      * in this reversed view, depending upon the implementation.
>>> 93:      *
>> 
>> @stuart-marks Perhaps an opportunity to spec it so that x == x.reversed().reversed() (i.e. unwrap on double-reverse)?
>
> @stuart-marks What are examples of cases where it wouldn't be reasonable: https://github.com/openjdk/jdk/pull/7387/files#diff-2b261a88d9ed30893d24186a36ef500d284d82e8f345591fc6c44ed5ae15da4fR161 ?

I had to uncomment that line to figure out what broke. :-) Turns out `TreeSet.reversed().reversed()` doesn't return the original TreeSet. This is because `descendingSet().descendingSet()` doesn't unwrap, and neither does TreeMap's `descendingMap().descendingMap()`. I don't know what this wasn't done in the first place. Nonetheless, since unwrapping isn't done in the underlying implementation, it doesn't seem reasonable for the specification to require it be done. Furthermore this enables `reversed()` to be implemented as a default method that simply delegates to the respective `descending*()` method.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1012410605

From smarks at openjdk.org  Mon Mar 20 23:45:08 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 20 Mar 2023 23:45:08 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
Message-ID: 

On Fri, 17 Mar 2023 07:30:12 GMT, ExE Boss  wrote:

>> PR for Sequenced Collections implementation.
>
> src/java.base/share/classes/java/util/SequencedMap.java line 343:
> 
>> 341:         return new SeqEntrySet();
>> 342:     }
>> 343: }
> 
> Missing trailing newline:
> Suggestion:
> 
> }

will fix

> src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java line 554:
> 
>> 552:     public E removeLast() {
>> 553:         synchronized (lock) {
>> 554:            int size = getArray().length;
> 
> Wrong?indentation:
> Suggestion:
> 
>             int size = getArray().length;
> 
> (this?would be?avoided if?the?JDK was?using the?more accessible?tabs[^1])
> 
> [^1]: prettier/prettier#7475

Thanks, will fix.

> src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java line 1803:
> 
>> 1801:         public Spliterator spliterator() {
>> 1802:             // TODO can probably improve this
>> 1803:             return Spliterators.spliteratorUnknownSize(new DescendingIterator(), 0);
> 
> Suggestion:
> 
>             var it = new DescendingIterator();
>             return Spliterators.spliterator(
>                     it, it.size,
>                     Spliterator.IMMUTABLE | Spliterator.ORDERED);

Thanks, but I have some pending work to redo most if not all of the spliterators.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1140749575
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1104931273
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1104931560

From smarks at openjdk.org  Mon Mar 20 23:47:38 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 20 Mar 2023 23:47:38 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
Message-ID: <8TgBVKlRLLYybAvEbt7Pz3Ucs_-jPNo8HckE3am8i5I=.84e4c3e0-7060-4d26-bd5e-945e6a60f707@github.com>

On Tue, 8 Feb 2022 17:23:38 GMT, Stuart Marks  wrote:

> PR for Sequenced Collections implementation.

[JEP 431](https://openjdk.org/jeps/431) is now Targeted to JDK 21. Hooray! It thus seems as good a time as any to mark this PR as ready for review. Currently I'm focusing on getting the specification finished so I can then update and finalize the [CSR](https://bugs.openjdk.org/browse/JDK-8266572) which is the last remaining hurdle before integration. I'd thus appreciate comments that focus on the specifications. See a recent specdiff:

https://cr.openjdk.org/~smarks/collections/specdiff-sequenced-20230316/overview-summary.html

or you can comment on the doc comments in the code changes themselves.

Of course if there implementation or other comments, feel free to post them, though I may postpone them until after the CSR is completed and possibly even after the initial integration. If I do the latter I'll track changes as separate bug reports (and thus separate PRs).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1477093137

From psandoz at openjdk.org  Tue Mar 21 00:38:49 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 21 Mar 2023 00:38:49 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview)
In-Reply-To: 
References: 
Message-ID: 

On Fri, 17 Mar 2023 15:42:56 GMT, Per Minborg  wrote:

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

src/java.base/share/classes/java/lang/foreign/Linker.java line 479:

> 477:      *     Otherwise, the invocation throws {@link WrongThreadException}; and
> 478:      *     
  • {@code A} is kept alive during the invocation. For instance, if {@code A} has been obtained using a
> 479:      *     {@linkplain Arena#ofConfined() confined arena}, any attempt to {@linkplain Arena#close() close}

Is that correct? Do you mean a shared arena?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1142798464

From liach at openjdk.org  Tue Mar 21 00:56:53 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 21 Mar 2023 00:56:53 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
Message-ID: 

On Tue, 8 Feb 2022 17:23:38 GMT, Stuart Marks  wrote:

> PR for Sequenced Collections implementation.

Just curious, does sequenced collection specify if add simulates addLast if addition supports custom ordering? I wish to have efficient reversible batch addition operations available, like ordered versions of addAll.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1477097626

From psandoz at openjdk.org  Tue Mar 21 00:57:17 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 21 Mar 2023 00:57:17 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview)
In-Reply-To: 
References: 
Message-ID: 

On Fri, 17 Mar 2023 15:42:56 GMT, Per Minborg  wrote:

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

src/java.base/share/classes/java/lang/foreign/Linker.java line 609:

> 607:          * @see #captureStateLayout()
> 608:          */
> 609:         static Option captureCallState(String... capturedState) {

What if a name is not recognized? Throw IAE?

src/java.base/share/classes/java/lang/foreign/Linker.java line 621:

> 619:          *          to a downcall handle linked with {@link #captureCallState(String...)}}
> 620:          *
> 621:          * @see #captureCallState(String...)

How does a caller know what the structure may contain? Should we document the platform specific structures?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1142804110
PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1142804836

From psandoz at openjdk.org  Tue Mar 21 01:17:42 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 21 Mar 2023 01:17:42 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview)
In-Reply-To: 
References: 
Message-ID: 

On Fri, 17 Mar 2023 15:42:56 GMT, Per Minborg  wrote:

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 56:

> 54:  *     
  • It can be passed to an existing {@linkplain Linker#downcallHandle(FunctionDescriptor, Linker.Option...) downcall method handle}, as an argument to the underlying foreign function.
    • 
> 55:  *     
  • It can be {@linkplain MemorySegment#set(AddressLayout, long, MemorySegment) stored} inside another memory segment.
    • 
> 56:  *     
  • It can be used to access the region of memory backing a global variable (this might require

Suggestion:

 *     
  • It can be used to access the region of memory backing a global variable (this requires

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1142812300

From dholmes at openjdk.org  Tue Mar 21 01:49:41 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 21 Mar 2023 01:49:41 GMT
Subject: RFR: 8205129: Remove java.lang.Compiler
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: <0OTGAOe3OSKKre_ybkPWQs2RlvgvXfAk-Gl74rKSIxg=.b1226eec-cffb-43ad-8bf8-aefb4fff1c7e@github.com>

On Mon, 20 Mar 2023 17:35:58 GMT, Stuart Marks  wrote:

> I don't know how much interdependency there is between the java.compiler system property and the java.lang.Compiler class. 
> On the library side I think they're independent.

That may be true today but originally they were very much inter-dependent:

/**
 * The Compiler class is provided to support
 * Java-to-native-code compilers and related services. By design, the
 * Compiler class does nothing; it serves as a
 * placeholder for a JIT compiler implementation.
 * 
    
 * When the Java Virtual Machine first starts, it determines if the
 * system property java.compiler exists. (System
 * properties are accessible through getProperty  and ,
 * a method defined by the System class.) If so, it is
 * assumed to be the name of a library (with a platform-dependent
 * exact location and type); the loadLibrary method in
 * class System is called to load that library. If this
 * loading succeeds, the function named
 * java_lang_Compiler_start() in that library is called.
 * 
    
 * If no compiler is available, these methods do nothing.

The only part of that we have left today is that `-Djava.compiler=NONE` is an alias for `-Xint` mode.

JDK 9 effectively severed the class from the property by removing the above wording, so in that sense the two issues can be addressed separately. We should have handled the property deprecation back in JDK 9 too (not that there is an actual definition/process of deprecating system properties).

P.S I will try not to take any vacation until after this is resolved. :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13092#issuecomment-1477170195

From dholmes at openjdk.org  Tue Mar 21 02:42:41 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 21 Mar 2023 02:42:41 GMT
Subject: RFR: 8205129: Remove java.lang.Compiler
In-Reply-To: <0OTGAOe3OSKKre_ybkPWQs2RlvgvXfAk-Gl74rKSIxg=.b1226eec-cffb-43ad-8bf8-aefb4fff1c7e@github.com>
References: 
 
 
 
 
 
 <0OTGAOe3OSKKre_ybkPWQs2RlvgvXfAk-Gl74rKSIxg=.b1226eec-cffb-43ad-8bf8-aefb4fff1c7e@github.com>
Message-ID: 

On Tue, 21 Mar 2023 01:46:46 GMT, David Holmes  wrote:

>The only part of that we have left today is that -Djava.compiler=NONE is an alias for -Xint mode.

Edit: ... unless `-Xdebug` is specified in which case it is ignored.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13092#issuecomment-1477202418

From smarks at openjdk.org  Tue Mar 21 03:36:57 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 21 Mar 2023 03:36:57 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
Message-ID: 

On Tue, 8 Feb 2022 17:23:38 GMT, Stuart Marks  wrote:

> PR for Sequenced Collections implementation.

(Heh, it looks like a whole bunch of old PR comments from when it was in draft state just got replayed to the mailing lists.)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1477235039

From smarks at openjdk.org  Tue Mar 21 03:46:58 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 21 Mar 2023 03:46:58 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
Message-ID: 

On Mon, 20 Mar 2023 23:52:11 GMT, Chen Liang  wrote:

>> PR for Sequenced Collections implementation.
>
> Just curious, does sequenced collection specify if add simulates addLast if addition supports custom ordering? I wish to have efficient reversible batch addition operations available, like ordered versions of addAll.

@liach 

> Just curious, does sequenced collection specify if add simulates addLast if addition supports custom ordering? I wish to have efficient reversible batch addition operations available, like ordered versions of addAll.

Well the specs say what they say. For List, Deque, and LinkedHashSet, the add(E) method adds at the end. The addAll(Collection) method is specified to honor the iteration order (really, encounter order) of the argument, and they all add at the end. (But Deque.addAll is specified in terms of addLast.) If some other existing collection defines add(E) to insert at some custom location, then addAll(Collection) will need to specify what it does. Converting that collection to be sequenced doesn't necessarily change that.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1477240323

From darcy at openjdk.org  Tue Mar 21 06:19:47 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 21 Mar 2023 06:19:47 GMT
Subject: RFR: JDK-8304028: Port fdlibm IEEEremainder to Java
Message-ID: 

Last but not least, a port of fdlibm IEEEremainder from C to Java. I plan to write some more implementation-specific tests around decision points in the FDLIBM algorithm, but I wanted to get the bulk of the changes out for review first.

Note that since IEEEremainder was the last native method in StrictMath.java, the StrictMath.c file needed to be deleted (or modified) since StrictMath.h was no longer generated as part of the build. (StrictMath.c was one of the file deleted as part of JDK-8302801).

For testing, Mach 5 tier 1 through 3 were successful (other than an unrelated test failure that was problem listed) and the exhaustive test was locally run and passed with "16, 16" to increase the testing density.

-------------

Commit messages:
 - JDK-8304028: Port fdlibm IEEEremainder to Java

Changes: https://git.openjdk.org/jdk/pull/13113/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13113&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304028
  Stats: 704 lines in 6 files changed: 575 ins; 127 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13113.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13113/head:pull/13113

PR: https://git.openjdk.org/jdk/pull/13113

From darcy at openjdk.org  Tue Mar 21 06:19:48 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 21 Mar 2023 06:19:48 GMT
Subject: RFR: JDK-8304028: Port fdlibm IEEEremainder to Java
In-Reply-To: 
References: 
Message-ID: <3mrbZjCtzviHP1QjWB3dj5wvY6Hb_F0MkTmYQ-eHhts=.14977fba-69de-41c3-b6ef-379b86f52cef@github.com>

On Tue, 21 Mar 2023 06:11:57 GMT, Joe Darcy  wrote:

> Last but not least, a port of fdlibm IEEEremainder from C to Java. I plan to write some more implementation-specific tests around decision points in the FDLIBM algorithm, but I wanted to get the bulk of the changes out for review first.
> 
> Note that since IEEEremainder was the last native method in StrictMath.java, the StrictMath.c file needed to be deleted (or modified) since StrictMath.h was no longer generated as part of the build. (StrictMath.c was one of the file deleted as part of JDK-8302801).
> 
> For testing, Mach 5 tier 1 through 3 were successful (other than an unrelated test failure that was problem listed) and the exhaustive test was locally run and passed with "16, 16" to increase the testing density.

Diffs to aid review:


$ diff -w Remainder.c Remainder.translit.java 
1,25c1,6
< /* __ieee754_remainder(x,p)
<  * Return :
<  *      returns  x REM p  =  x - [x/p]*p as if in infinite
<  *      precise arithmetic, where [x/p] is the (infinite bit)
<  *      integer nearest x/p (in half way case choose the even one).
<  * Method :
<  *      Based on fmod() return x-[x/p]chopped*p exactlp.
<  */
< 
< #include "fdlibm.h"
< 
< #ifdef __STDC__
< static const double zero = 0.0;
< #else
< static double zero = 0.0;
< #endif
< 
< 
< #ifdef __STDC__
<         double __ieee754_remainder(double x, double p)
< #else
<         double __ieee754_remainder(x,p)
<         double x,p;
< #endif
< {
---
>     private static final class IEEEremainder {
>         private static final double zero = 0.0;
>         private static double one = 1.0;
>         private static double[] Zero = {0.0, -0.0,};
> 
>         static double compute(double x, double p) {
27c8
<         unsigned sx,lx,lp;
---
>             /*unsigned*/ int sx,lx,lp;
48,49c29,30
<         x  = fabs(x);
<         p  = fabs(p);
---
>             x  = Math.abs(x);
>             p  = Math.abs(p);
62c43,44
<         __HI(x) ^= sx;
---
>             // __HI(x) ^= sx;
>             x = __HI(x, __HI(x)^sx);
65,85c47,48
< /*
<  * __ieee754_fmod(x,y)
<  * Return x mod y in exact arithmetic
<  * Method: shift and subtract
<  */
< 
< #include "fdlibm.h"
< 
< #ifdef __STDC__
< static const double one = 1.0, Zero[] = {0.0, -0.0,};
< #else
< static double one = 1.0, Zero[] = {0.0, -0.0,};
< #endif
< 
< #ifdef __STDC__
<         double __ieee754_fmod(double x, double y)
< #else
<         double __ieee754_fmod(x,y)
<         double x,y ;
< #endif
< {
---
> 
>         private static double __ieee754_fmod(double x, double y) {
87c50
<         unsigned lx,ly,lz;
---
>             /*unsigned*/ int lx,ly,lz;
102c65,66
<             if((hx                 // if((hx                 if((hx>31];  /* |x|=|y| return x*0*/
---
>                     return Zero[/*(unsigned)*/sx>>>31];  /* |x|=|y| return x*0*/ // unsigned shift
131c95
<                 hx = (hx<>(32-n));
---
>                     hx = (hx<>> (32-n)); // unsigned shift
143c107
<                 hy = (hy<>(32-n));
---
>                     hy = (hy<>> (32-n)); // unsigned shift
153,155c117,121
<         while(n--) {
<             hz=hx-hy;lz=lx-ly; if(lx>31); lx = lx+lx;}
---
>             while(n-- != 0) {
>                 hz=hx-hy;lz=lx-ly;
>                 // if(lx                 if(Integer.compareUnsigned(lx, ly) < 0) hz -= 1;
>                 if(hz<0){hx = hx+hx+(lx >>> 31); lx = lx+lx;} // unsigned shift
158,159c124,126
<                     return Zero[(unsigned)sx>>31];
<                 hx = hz+hz+(lz>>31); lx = lz+lz;
---
>                         return Zero[/*(unsigned)*/sx>>>31]; // unsigned shift
>                     hx = hz+hz+(lz >>> 31); // unsigned shift
>                     lx = lz+lz;
162c129,131
<         hz=hx-hy;lz=lx-ly; if(lx             hz=hx-hy;lz=lx-ly;
>             // if(lx             if(Integer.compareUnsigned(lx, ly) < 0) hz -= 1;
167c136
<             return Zero[(unsigned)sx>>31];
---
>                 return Zero[/*(unsigned)*/sx >>> 31]; // unsigned shift
169c138
<             hx = hx+hx+(lx>>31); lx = lx+lx;
---
>                 hx = hx+hx+(lx >>> 31); lx = lx+lx; // unsigned shift
174,175c143,146
<             __HI(x) = hx|sx;
<             __LO(x) = lx;
---
>                 // __HI(x) = hx|sx;
>                 x = __HI(x, hx|sx);
>                 // __LO(x) = lx;
>                 x = __LO(x, lx);
179c150
<                 lx = (lx>>n)|((unsigned)hx<<(32-n));
---
>                     lx = (lx >>> n)|(/*(unsigned)*/hx<<(32-n)); // unsigned shift
182c153,154
<                 lx = (hx<<(32-n))|(lx>>n); hx = sx;
---
>                     lx = (hx<<(32-n))|(lx >>> n); // unsigned shift
>                     hx = sx;
186,187c158,161
<             __HI(x) = hx|sx;
<             __LO(x) = lx;
---
>                 // __HI(x) = hx|sx;
>                 x = __HI(x, hx|sx);
>                 // __LO(x) = lx;
>                 x = __LO(x, lx);
191a166
>     }



$ diff -w Remainder.translit.java  Remainder.fdlibm.java 
1,4c1,2
<     private static final class IEEEremainder {
<         private static final double zero = 0.0;
<         private static double one = 1.0;
<         private static double[] Zero = {0.0, -0.0,};
---
>     static final class IEEEremainder {
>         private IEEEremainder() {throw new UnsupportedOperationException();}
11,24c9,15
<             hx = __HI(x);           /* high word of x */
<             lx = __LO(x);           /* low  word of x */
<             hp = __HI(p);           /* high word of p */
<             lp = __LO(p);           /* low  word of p */
<             sx = hx&0x80000000;
<             hp &= 0x7fffffff;
<             hx &= 0x7fffffff;
< 
<             /* purge off exception values */
<             if((hp|lp)==0) return (x*p)/(x*p);      /* p = 0 */
<             if((hx>=0x7ff00000)||                   /* x not finite */
<                ((hp>=0x7ff00000)&&                   /* p is NaN */
<                 (((hp-0x7ff00000)|lp)!=0)))
<                 return (x*p)/(x*p);
---
>             hx = __HI(x);           // high word of x
>             lx = __LO(x);           // low  word of x
>             hp = __HI(p);           // high word of p
>             lp = __LO(p);           // low  word of p
>             sx = hx & 0x8000_0000;
>             hp &= 0x7fff_ffff;
>             hx &= 0x7fff_ffff;
25a17,24
>             // purge off exception values
>             if ((hp | lp) == 0) {// p = 0
>                 return (x*p)/(x*p);
>             }
>             if ((hx >= 0x7ff0_0000) ||                   // not finite
>                 ((hp >= 0x7ff0_0000) &&                   // p is NaN
>                  (((hp - 0x7ff0_0000) | lp) != 0)))
>                 return (x*p)/(x*p);
27,28c26,31
<             if (hp<=0x7fdfffff) x = __ieee754_fmod(x,p+p);  /* now x < 2p */
<             if (((hx-hp)|(lx-lp))==0) return zero*x;
---
>             if (hp <= 0x7fdf_ffff) {  // now x < 2p
>                 x = __ieee754_fmod(x, p + p);
>             }
>             if (((hx - hp) | (lx - lp)) == 0) {
>                 return 0.0*x;
>             }
31c34
<             if (hp<0x00200000) {
---
>             if (hp < 0x0020_0000) {
34c37,39
<                     if(x+x>=p) x -= p;
---
>                     if (x + x >= p) {
>                         x -= p;
>                     }
40c45,47
<                     if(x>=p_half) x -= p;
---
>                     if (x >= p_half) {
>                         x -= p;
>                     }
43d49
<             // __HI(x) ^= sx;
49c55
<             int n,hx,hy,hz,ix,iy,sx,i;
---
>             int n, hx, hy, hz, ix, iy, sx;
52,62c58,68
<             hx = __HI(x);           /* high word of x */
<             lx = __LO(x);           /* low  word of x */
<             hy = __HI(y);           /* high word of y */
<             ly = __LO(y);           /* low  word of y */
<             sx = hx&0x80000000;             /* sign of x */
<             hx ^=sx;                /* |x| */
<             hy &= 0x7fffffff;       /* |y| */
< 
<             /* purge off exception values */
<             if((hy|ly)==0||(hx>=0x7ff00000)||       /* y=0,or x not finite */
<                ((hy|((ly|-ly)>>31))>0x7ff00000))     /* or y is NaN */
---
>             hx = __HI(x);           // high word of x
>             lx = __LO(x);           // low  word of x
>             hy = __HI(y);           // high word of y
>             ly = __LO(y);           // low  word of y
>             sx = hx & 0x8000_0000;  // sign of x
>             hx ^= sx;               // |x|
>             hy &= 0x7fff_ffff;      // |y|
> 
>             // purge off exception values
>             if((hy | ly) == 0 || (hx >= 0x7ff0_0000)||       // y = 0, or x not finite
>                ((hy | ((ly | -ly) >> 31)) > 0x7ff0_0000))    // or y is NaN
65,68c71,72
<                 // if((hx>>31];  /* |x|=|y| return x*0*/ // unsigned shift
---
>                 if ((hx < hy) || (Integer.compareUnsigned(lx, ly) < 0)) { // |x| < |y| return x
>                     return x;
70,76c74,75
< 
<             /* determine ix = ilogb(x) */
<             if(hx<0x00100000) {     /* subnormal x */
<                 if(hx==0) {
<                     for (ix = -1043, i=lx; i>0; i<<=1) ix -=1;
<                 } else {
<                     for (ix = -1022,i=(hx<<11); i>0; i<<=1) ix -=1;
---
>                 if (lx == ly) {
>                     return signedZero(sx);  // |x| = |y| return x*0
78,85d76
<             } else ix = (hx>>20)-1023;
< 
<             /* determine iy = ilogb(y) */
<             if(hy<0x00100000) {     /* subnormal y */
<                 if(hy==0) {
<                     for (iy = -1043, i=ly; i>0; i<<=1) iy -=1;
<                 } else {
<                     for (iy = -1022,i=(hy<<11); i>0; i<<=1) iy -=1;
87d77
<             } else iy = (hy>>20)-1023;
89c79,82
<             /* set up {hx,lx}, {hy,ly} and align y to x */
---
>             ix = ilogb(hx, lx);
>             iy = ilogb(hy, ly);
> 
>             // set up {hx, lx}, {hy, ly} and align y to x
91,92c84,85
<                 hx = 0x00100000|(0x000fffff&hx);
<             else {          /* subnormal x, shift x to normal */
---
>                 hx = 0x0010_0000 | (0x000f_ffff & hx);
>             else {          // subnormal x, shift x to normal
103,104c96,97
<                 hy = 0x00100000|(0x000fffff&hy);
<             else {          /* subnormal y, shift y to normal */
---
>                 hy = 0x0010_0000 | (0x000f_ffff & hy);
>             else {          // subnormal y, shift y to normal
115c108
<             /* fix point fmod */
---
>             // fix point fmod
118,124c111,122
<                 hz=hx-hy;lz=lx-ly;
<                 // if(lx>> 31); lx = lx+lx;} // unsigned shift
<                 else {
<                     if((hz|lz)==0)          /* return sign(x)*0 */
<                         return Zero[/*(unsigned)*/sx>>>31]; // unsigned shift
---
>                 hz = hx - hy;
>                 lz = lx - ly;
>                 if (Integer.compareUnsigned(lx, ly) < 0) {
>                     hz -= 1;
>                 }
>                 if (hz < 0){
>                     hx = hx + hx +(lx >>> 31); // unsigned shift
>                     lx = lx + lx;
>                 } else {
>                     if ((hz | lz) == 0) {        // return sign(x)*0
>                         return signedZero(sx);
>                     }
129,138c127,143
<             hz=hx-hy;lz=lx-ly;
<             // if(lx=0) {hx=hz;lx=lz;}
< 
<             /* convert back to floating value and restore the sign */
<             if((hx|lx)==0)                  /* return sign(x)*0 */
<                 return Zero[/*(unsigned)*/sx >>> 31]; // unsigned shift
<             while(hx<0x00100000) {          /* normalize x */
<                 hx = hx+hx+(lx >>> 31); lx = lx+lx; // unsigned shift
---
>             hz = hx - hy;
>             lz = lx - ly;
>             if (Integer.compareUnsigned(lx, ly) < 0) {
>                 hz -= 1;
>             }
>             if (hz >= 0) {
>                 hx = hz;
>                 lx = lz;
>             }
> 
>             // convert back to floating value and restore the sign
>             if ((hx | lx) == 0) {                  // return sign(x)*0
>                 return signedZero(sx);
>             }
>             while (hx < 0x0010_0000) {          // normalize x
>                 hx = hx + hx + (lx >>> 31); // unsigned shift
>                 lx = lx + lx;
141,147c146,149
<             if(iy>= -1022) {        /* normalize output */
<                 hx = ((hx-0x00100000)|((iy+1023)<<20));
<                 // __HI(x) = hx|sx;
<                 x = __HI(x, hx|sx);
<                 // __LO(x) = lx;
<                 x = __LO(x, lx);
<             } else {                /* subnormal output */
---
>             if( iy >= -1022) {        // normalize output
>                 hx = ((hx - 0x0010_0000) | ((iy + 1023) << 20));
>                 x = __HI_LO(hx | sx, lx);
>             } else {                // subnormal output
156c158,184
<                     lx = hx>>(n-32); hx = sx;
---
>                     lx = hx >>(n - 32);
>                     hx = sx;
>                 }
>                 x = __HI_LO(hx | sx, lx);
>                 x *= 1.0;           // create necessary signal
>             }
>             return x;               // exact output
>         }
> 
>         /*
>          * Return a double zero with the same sign as the int argument.
>          */
>         private static double signedZero(int sign) {
>             return +0.0 * ( (double)sign);
>         }
> 
>         private static int ilogb(int hz, int lz) {
>             int iz, i;
>             if (hz < 0x0010_0000) {     // subnormal z
>                 if (hz == 0) {
>                     for (iz = -1043, i = lz; i > 0; i <<= 1) {
>                         iz -= 1;
>                     }
>                 } else {
>                     for (iz = -1022, i = (hz << 11); i > 0; i <<= 1) {
>                         iz -= 1;
>                     }
158,162c186,187
<                 // __HI(x) = hx|sx;
<                 x = __HI(x, hx|sx);
<                 // __LO(x) = lx;
<                 x = __LO(x, lx);
<                 x *= one;           /* create necessary signal */
---
>             } else {
>                 iz = (hz >> 20) - 1023;
164c189
<             return x;               /* exact output */
---
>             return iz;

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13113#issuecomment-1477333025

From pminborg at openjdk.org  Tue Mar 21 07:32:48 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 21 Mar 2023 07:32:48 GMT
Subject: RFR: 8301552: Use AtomicReferenceArray for caching instead of CHM
 in ZoneOffset [v8]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 20 Mar 2023 18:12:01 GMT, Chen Liang  wrote:

>> Per Minborg has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Remove unused setup method
>>  - Rename method in test
>>  - Add copyright header
>
> src/java.base/share/classes/java/time/ZoneOffset.java line 430:
> 
>> 428:     public static ZoneOffset ofTotalSeconds(int totalSeconds) {
>> 429:         final class Holder {
>> 430:             private static final IntFunction ZONE_OFFSET_MAPPER = new ZoneOffsetMapper();
> 
> Can't the ZoneOffsetMapper itself serve as a holder class? so we move this singleton into ZoneOffsetMapper itself.

It is possible but this keeps the mapper more local and only accessible where it is supposed to be used. For testing purposed, it might be better to have the class as you propose.

> test/jdk/jdk/internal/util/LazyReferenceArray/BasicLazyReferenceArrayTest.java line 107:
> 
>> 105: 
>> 106:     private static IntFunction intIdentity() {
>> 107:         return i -> i;
> 
> Can't this be `Integer::valueOf`?

It can. I think either works fine. Maybe a bit nicer with a method reference as you propose.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12346#discussion_r1142972042
PR Review Comment: https://git.openjdk.org/jdk/pull/12346#discussion_r1142973744

From pminborg at openjdk.org  Tue Mar 21 07:32:49 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 21 Mar 2023 07:32:49 GMT
Subject: RFR: 8301552: Use AtomicReferenceArray for caching instead of CHM
 in ZoneOffset [v8]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Tue, 21 Mar 2023 07:27:59 GMT, Per Minborg  wrote:

>> test/jdk/jdk/internal/util/LazyReferenceArray/BasicLazyReferenceArrayTest.java line 107:
>> 
>>> 105: 
>>> 106:     private static IntFunction intIdentity() {
>>> 107:         return i -> i;
>> 
>> Can't this be `Integer::valueOf`?
>
> It can. I think either works fine. Maybe a bit nicer with a method reference as you propose.

Perhaps you mean the method could be *replaced* with `Integer::valueOf"? Good suggestion.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12346#discussion_r1142974996

From pminborg at openjdk.org  Tue Mar 21 07:50:22 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 21 Mar 2023 07:50:22 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v2]
In-Reply-To: 
References: 
Message-ID: 

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

Per Minborg has updated the pull request incrementally with two additional commits since the last revision:

 - Update src/java.base/share/classes/java/lang/foreign/SymbolLookup.java
   
   Co-authored-by: Paul Sandoz 
 - Update src/java.base/share/classes/java/lang/foreign/AddressLayout.java
   
   Co-authored-by: Paul Sandoz 

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13079/files
  - new: https://git.openjdk.org/jdk/pull/13079/files/bb2f4438..7a78948a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13079.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13079/head:pull/13079

PR: https://git.openjdk.org/jdk/pull/13079

From pminborg at openjdk.org  Tue Mar 21 08:04:25 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 21 Mar 2023 08:04:25 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v3]
In-Reply-To: 
References: 
Message-ID: 

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Remove MemoryInspection classes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13079/files
  - new: https://git.openjdk.org/jdk/pull/13079/files/7a78948a..a71518c4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=01-02

  Stats: 684 lines in 3 files changed: 0 ins; 684 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13079.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13079/head:pull/13079

PR: https://git.openjdk.org/jdk/pull/13079

From duke at openjdk.org  Tue Mar 21 08:18:41 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 21 Mar 2023 08:18:41 GMT
Subject: RFR: 8205129: Remove java.lang.Compiler
In-Reply-To: 
References: 
Message-ID: 

On Sun, 19 Mar 2023 09:01:26 GMT, Eirik Bjorsnos  wrote:

> Please help review this PR which suggests we remove the class `java.lang.Compiler`. The class seems non-functional for a decade, and was terminally deprecated in Java 9. Time has come to let it go.

The CSR for the removal of `java.lang.Compiler` is now looking for non-vacationing reviewers:

https://bugs.openjdk.org/browse/JDK-8304458

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13092#issuecomment-1477425915

From pminborg at openjdk.org  Tue Mar 21 08:33:26 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 21 Mar 2023 08:33:26 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v4]
In-Reply-To: 
References: 
Message-ID: <_HwSyb1bsHNIJpGKdznMZR_HfWIU9VeAl1etn4miKGQ=.8397676f-1e24-4a2e-bcfa-ed44fb8a515b@github.com>

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Improve Linker javadocs

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13079/files
  - new: https://git.openjdk.org/jdk/pull/13079/files/a71518c4..4626a54e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=02-03

  Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13079.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13079/head:pull/13079

PR: https://git.openjdk.org/jdk/pull/13079

From pminborg at openjdk.org  Tue Mar 21 08:33:29 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 21 Mar 2023 08:33:29 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 21 Mar 2023 00:52:01 GMT, Paul Sandoz  wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve Linker javadocs
>
> src/java.base/share/classes/java/lang/foreign/Linker.java line 609:
> 
>> 607:          * @see #captureStateLayout()
>> 608:          */
>> 609:         static Option captureCallState(String... capturedState) {
> 
> What if a name is not recognized? Throw IAE?

Added

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1143024389

From rgiulietti at openjdk.org  Tue Mar 21 08:46:52 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 21 Mar 2023 08:46:52 GMT
Subject: Integrated: 8303648: Add String.indexOf(String str, int beginIndex,
 int endIndex)
In-Reply-To: 
References: 
Message-ID: 

On Tue, 7 Mar 2023 14:44:32 GMT, Raffaello Giulietti  wrote:

> As a followup of [JDK-8302590](https://bugs.openjdk.org/browse/JDK-8302590), this issue covers the analogous case for a search of a string rather than a character.

This pull request has now been integrated.

Changeset: 4bf1fbb0
Author:    Raffaello Giulietti 
URL:       https://git.openjdk.org/jdk/commit/4bf1fbb06d63b4c52bfd3922beb2adf069e25b09
Stats:     252 lines in 2 files changed: 237 ins; 5 del; 10 mod

8303648: Add String.indexOf(String str, int beginIndex, int endIndex)

Reviewed-by: rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/12903

From pminborg at openjdk.org  Tue Mar 21 09:02:29 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 21 Mar 2023 09:02:29 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v5]
In-Reply-To: 
References: 
Message-ID: 

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Add example for Option::captureStateLayout

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13079/files
  - new: https://git.openjdk.org/jdk/pull/13079/files/4626a54e..21ef0607

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=03-04

  Stats: 12 lines in 1 file changed: 12 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13079.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13079/head:pull/13079

PR: https://git.openjdk.org/jdk/pull/13079

From pminborg at openjdk.org  Tue Mar 21 09:02:33 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 21 Mar 2023 09:02:33 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 21 Mar 2023 00:54:10 GMT, Paul Sandoz  wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add example for Option::captureStateLayout
>
> src/java.base/share/classes/java/lang/foreign/Linker.java line 621:
> 
>> 619:          *          to a downcall handle linked with {@link #captureCallState(String...)}}
>> 620:          *
>> 621:          * @see #captureCallState(String...)
> 
> How does a caller know what the structure may contain? Should we document the platform specific structures?

I've added an example of how to print the platform-dependent structure. Should we document anyhow?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1143055969

From asotona at openjdk.org  Tue Mar 21 09:03:59 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 21 Mar 2023 09:03:59 GMT
Subject: RFR: 8294972: Convert jdk.jlink internal plugins to use the
 Classfile API [v15]
In-Reply-To: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com>
References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com>
Message-ID: 

> jdk.jlink internal plugins are heavily using ASM
> 
> This patch converts ASM calls to Classfile API.
> 
> Please review.
> Thanks,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 223 commits:

 - Merge branch 'master' into JDK-8294972-jlink-plugins
   
   # Conflicts:
   #	src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java
 - fixed SystemModulesClassGenerator.moduleInfos comment
 - added default to thrown for unknown CP tag in IncludeLocalesPlugin
 - Merge branch 'master' into JDK-8294972-jlink-plugins
 - SystemModulesPlugin::genClassBytes rename
 - SystemModulesPlugin::getClassBytes rename
 - Revert "implementation of custom ResourceHelper in IncludeLocalesPlugin"
 - remaining cleanup in SystemModulesPlugin
 - implementation of custom ResourceHelper in IncludeLocalesPlugin
 - fixed SystemModulesPlugin
 - ... and 213 more: https://git.openjdk.org/jdk/compare/c4df9b5f...71ed9a43

-------------

Changes: https://git.openjdk.org/jdk/pull/12944/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12944&range=14
  Stats: 1035 lines in 6 files changed: 217 ins; 278 del; 540 mod
  Patch: https://git.openjdk.org/jdk/pull/12944.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12944/head:pull/12944

PR: https://git.openjdk.org/jdk/pull/12944

From asotona at openjdk.org  Tue Mar 21 09:13:24 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 21 Mar 2023 09:13:24 GMT
Subject: RFR: 8294972: Convert jdk.jlink internal plugins to use the
 Classfile API [v14]
In-Reply-To: 
References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com>
 <0efK-pRtx-xkeOMKMEZBRcwFOoNFphU3Nubw9shBVIc=.42e2cb69-7ad9-4f23-9d23-2a95f6738753@github.com>
 
Message-ID: <9ZeKCgzF1skBwSKW1SXFTwyR44JYO22QJbboqdq0lOY=.b56a76ac-2c58-489b-afc9-9a1fca1238cf@github.com>

On Mon, 20 Mar 2023 19:53:29 GMT, Alan Bateman  wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed SystemModulesClassGenerator.moduleInfos comment
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 1021:
> 
>> 1019:                                   MethodTypeDesc.of(CD_void, CD_String))
>> 1020:                    .astore(BUILDER_VAR)
>> 1021:                    .aload(BUILDER_VAR);
> 
> The methods to generate the MD all load the Builder onto the operand stack so the aload at L1021 is catching my attention, is that needed?

It seems to be redundant as the following code does not expect it on stack and loads it again as needed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12944#discussion_r1143070062

From jpai at openjdk.org  Tue Mar 21 09:49:45 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 21 Mar 2023 09:49:45 GMT
Subject: RFR: 8304502: Classfile API class hierarchy makes assumptions when
 class is not resolved [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 20 Mar 2023 14:06:43 GMT, Adam Sotona  wrote:

>> Classfile API class hierarchy makes assumptions when class is not resolved and that may lead to silent generation of invalid stack maps. Only debug-level log information of case is actually provided.
>> 
>> Proposed patch throws IllegalArgumentException when the class is not resolved instead.
>> 
>> Thanks for review.
>> 
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/jdk/internal/classfile/impl/ClassHierarchyImpl.java
>   
>   Co-authored-by: liach <7806504+liach at users.noreply.github.com>

Looks OK to me. Just a minor comment, which I've added inline.

src/java.base/share/classes/jdk/internal/classfile/impl/ClassHierarchyImpl.java line 172:

> 170:         public StaticClassHierarchyResolver(Collection interfaceNames, Map classToSuperClass) {
> 171:             map = HashMap.newHashMap(interfaceNames.size() + classToSuperClass.size() + 1);
> 172:             map.put(ConstantDescs.CD_Object, new ClassHierarchyInfo(ConstantDescs.CD_Object, false, null));

Hello Adam, for this `Object` class representation, perhaps you could just have a `static final` field which is instantiated to this value and reused instead of creating a new instance each time?

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13099#pullrequestreview-1350037496
PR Review Comment: https://git.openjdk.org/jdk/pull/13099#discussion_r1143113268

From mcimadamore at openjdk.org  Tue Mar 21 09:52:54 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 21 Mar 2023 09:52:54 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 21 Mar 2023 00:35:40 GMT, Paul Sandoz  wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add example for Option::captureStateLayout
>
> src/java.base/share/classes/java/lang/foreign/Linker.java line 479:
> 
>> 477:      *     Otherwise, the invocation throws {@link WrongThreadException}; and
    • 
>> 478:      *     
  • {@code A} is kept alive during the invocation. For instance, if {@code A} has been obtained using a
>> 479:      *     {@linkplain Arena#ofConfined() confined arena}, any attempt to {@linkplain Arena#close() close}
> 
> Is that correct? Do you mean a shared arena?

The text is correct (you can still close a confined arena from inside an upcall), but I agree that perhaps using a shared arena might be a bit more intuitive.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1143118512

From mcimadamore at openjdk.org  Tue Mar 21 09:56:53 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 21 Mar 2023 09:56:53 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v5]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 21 Mar 2023 08:57:42 GMT, Per Minborg  wrote:

>> src/java.base/share/classes/java/lang/foreign/Linker.java line 621:
>> 
>>> 619:          *          to a downcall handle linked with {@link #captureCallState(String...)}}
>>> 620:          *
>>> 621:          * @see #captureCallState(String...)
>> 
>> How does a caller know what the structure may contain? Should we document the platform specific structures?
>
> I've added an example of how to print the platform-dependent structure. Should we document anyhow?

I'm not sure about this. Honestly, the example probably doesn't help much if somebody didn't get the idea of what the layout might be. I think it might be better to say something like, `on Windows/x64 the returned layout might be as follows...` and then you write the code to create the layout instance corresponding to the returned layout. But we have to be careful to make the text non-normative (as the set of values might change).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1143125997

From mcimadamore at openjdk.org  Tue Mar 21 10:01:53 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 21 Mar 2023 10:01:53 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 21 Mar 2023 09:02:29 GMT, Per Minborg  wrote:

>> API changes for the FFM API (third preview)
>> 
>> Specdiff:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
>> 
>> Javadoc:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add example for Option::captureStateLayout

src/java.base/share/classes/java/lang/foreign/Linker.java line 480:

> 478:      *     Otherwise, the invocation throws {@link WrongThreadException}; and
    • 
> 479:      *     
  • {@code A} is kept alive during the invocation. For instance, if {@code A} has been obtained using a
> 480:      *     {@linkplain Arena#ofShared()} confined arena}, any attempt to {@linkplain Arena#close() close}

the description of the link still says "confined"

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1143131392

From asotona at openjdk.org  Tue Mar 21 10:26:39 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 21 Mar 2023 10:26:39 GMT
Subject: RFR: 8294972: Convert jdk.jlink internal plugins to use the
 Classfile API [v16]
In-Reply-To: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com>
References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com>
Message-ID: <4LTxYkVwdLtBqXcMDd5bnEi33_ysuDGiHbAeu2AII48=.abca977f-69f8-4c7e-9bc8-6d2b660dfe8b@github.com>

> jdk.jlink internal plugins are heavily using ASM
> 
> This patch converts ASM calls to Classfile API.
> 
> Please review.
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  removed obsolete instruction from SystemModulesPlugin

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12944/files
  - new: https://git.openjdk.org/jdk/pull/12944/files/71ed9a43..3c12e88c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12944&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12944&range=14-15

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12944.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12944/head:pull/12944

PR: https://git.openjdk.org/jdk/pull/12944

From mchhipa at openjdk.org  Tue Mar 21 10:40:41 2023
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Tue, 21 Mar 2023 10:40:41 GMT
Subject: RFR: JDK-8295859 Update Manual Test Groups [v2]
In-Reply-To: <3KeJLP761daIyT87slqdEryg-DaoCH8FcjwzxaVfxIY=.ada66a7b-8cd6-4a8e-bbc2-a185ea5fc7c5@github.com>
References: 
 <3KeJLP761daIyT87slqdEryg-DaoCH8FcjwzxaVfxIY=.ada66a7b-8cd6-4a8e-bbc2-a185ea5fc7c5@github.com>
Message-ID: 

On Mon, 20 Mar 2023 23:29:25 GMT, Bill Huang  wrote:

>> The purpose of this task is to add the difference between -manual jdk_core and jdk_core_manual to the jdk_core_manual test goal. Furthermore, in order to streamline the manual test execution process, a new test group called jdk_core_manual_human has been created for manual tests that demand extra preparation or test input.
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented review comments.

LGTM

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12840#issuecomment-1477607865

From asotona at openjdk.org  Tue Mar 21 10:44:20 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 21 Mar 2023 10:44:20 GMT
Subject: RFR: 8304502: Classfile API class hierarchy makes assumptions when
 class is not resolved [v3]
In-Reply-To: 
References: 
Message-ID: 

> Classfile API class hierarchy makes assumptions when class is not resolved and that may lead to silent generation of invalid stack maps. Only debug-level log information of case is actually provided.
> 
> Proposed patch throws IllegalArgumentException when the class is not resolved instead.
> 
> Thanks for review.
> 
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  avoid repeated ClassHierarchyInfo of CD_Object instantiation in StaticClassHierarchyResolver

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13099/files
  - new: https://git.openjdk.org/jdk/pull/13099/files/8f166bdd..39f46722

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13099&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13099&range=01-02

  Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13099.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13099/head:pull/13099

PR: https://git.openjdk.org/jdk/pull/13099

From jpai at openjdk.org  Tue Mar 21 10:44:20 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 21 Mar 2023 10:44:20 GMT
Subject: RFR: 8304502: Classfile API class hierarchy makes assumptions when
 class is not resolved [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 21 Mar 2023 10:40:35 GMT, Adam Sotona  wrote:

>> Classfile API class hierarchy makes assumptions when class is not resolved and that may lead to silent generation of invalid stack maps. Only debug-level log information of case is actually provided.
>> 
>> Proposed patch throws IllegalArgumentException when the class is not resolved instead.
>> 
>> Thanks for review.
>> 
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   avoid repeated ClassHierarchyInfo of CD_Object instantiation in StaticClassHierarchyResolver

Marked as reviewed by jpai (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13099#pullrequestreview-1350139685

From asotona at openjdk.org  Tue Mar 21 10:44:20 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 21 Mar 2023 10:44:20 GMT
Subject: RFR: 8304502: Classfile API class hierarchy makes assumptions when
 class is not resolved [v2]
In-Reply-To: 
References: 
 
 
Message-ID: <6jvzbq3XSs-gj8UEXu8iIGmpCF9p5RVDrp9SEK7jN-Y=.bfa0d056-2717-451a-b33a-ab050914d360@github.com>

On Tue, 21 Mar 2023 09:45:56 GMT, Jaikiran Pai  wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/java.base/share/classes/jdk/internal/classfile/impl/ClassHierarchyImpl.java
>>   
>>   Co-authored-by: liach <7806504+liach at users.noreply.github.com>
>
> src/java.base/share/classes/jdk/internal/classfile/impl/ClassHierarchyImpl.java line 172:
> 
>> 170:         public StaticClassHierarchyResolver(Collection interfaceNames, Map classToSuperClass) {
>> 171:             map = HashMap.newHashMap(interfaceNames.size() + classToSuperClass.size() + 1);
>> 172:             map.put(ConstantDescs.CD_Object, new ClassHierarchyInfo(ConstantDescs.CD_Object, false, null));
> 
> Hello Adam, for this `Object` class representation, perhaps you could just have a `static final` field which is instantiated to this value and reused instead of creating a new instance each time?

fixed, thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13099#discussion_r1143179081

From duke at openjdk.org  Tue Mar 21 10:50:31 2023
From: duke at openjdk.org (Viktor Klang)
Date: Tue, 21 Mar 2023 10:50:31 GMT
Subject: RFR: JDK-8303742: CompletableFuture.orTimeout leaks if the future
 completes exceptionally
Message-ID: 

Improves the stability of the memory leak test for CompletableFuture timeout cancellation by both reducing the count by 50% (which should still be above threshold to trigger given the ample margin set initially) as well as extending the default timeout of the test run.

-------------

Commit messages:
 - Hardening the memory leak test for CompletableFuture timeout cancellation

Changes: https://git.openjdk.org/jdk/pull/13116/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13116&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303742
  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/13116.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13116/head:pull/13116

PR: https://git.openjdk.org/jdk/pull/13116

From jpai at openjdk.org  Tue Mar 21 11:05:42 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 21 Mar 2023 11:05:42 GMT
Subject: RFR: JDK-8303742: CompletableFuture.orTimeout leaks if the future
 completes exceptionally
In-Reply-To: 
References: 
Message-ID: 

On Tue, 21 Mar 2023 10:42:55 GMT, Viktor Klang  wrote:

> Improves the stability of the memory leak test for CompletableFuture timeout cancellation by both reducing the count by 50% (which should still be above threshold to trigger given the ample margin set initially) as well as extending the default timeout of the test run.

The PR seems to be using an incorrect JBS issue id/summary. This PR should be linked with the new https://bugs.openjdk.org/browse/JDK-8304557 issue.

test/jdk/java/util/concurrent/CompletableFuture/CompletableFutureOrTimeoutExceptionallyTest.java line 28:

> 26:  * @bug 8303742
> 27:  * @summary CompletableFuture.orTimeout can leak memory if completed exceptionally
> 28:  * @run junit/othervm/timeout=1000 -Xmx128m CompletableFutureOrTimeoutExceptionallyTest

Hello Viktor, a timeout of 1000 seconds is 16 minutes. This timeout value is then multiplied by the timeout factor (which is a jtreg option) to decide the final timeout. The CI on which this was reported use a timeout factor of 4. So this would translate to a timeout of 64 minutes, which I think is extremely high (although it's just the upper bound). 

Perhaps you could increase this timeout to maybe 5 minutes (300 seconds) and run some tests on our CI to see if that is sufficient?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13116#issuecomment-1477639233
PR Review Comment: https://git.openjdk.org/jdk/pull/13116#discussion_r1143207328

From aturbanov at openjdk.org  Tue Mar 21 11:33:44 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 21 Mar 2023 11:33:44 GMT
Subject: RFR: JDK-8304028: Port fdlibm IEEEremainder to Java
In-Reply-To: 
References: 
Message-ID: 

On Tue, 21 Mar 2023 06:11:57 GMT, Joe Darcy  wrote:

> Last but not least, a port of fdlibm IEEEremainder from C to Java. I plan to write some more implementation-specific tests around decision points in the FDLIBM algorithm, but I wanted to get the bulk of the changes out for review first.
> 
> Note that since IEEEremainder was the last native method in StrictMath.java, the StrictMath.c file needed to be deleted (or modified) since StrictMath.h was no longer generated as part of the build. (StrictMath.c was one of the file deleted as part of JDK-8302801).
> 
> For testing, Mach 5 tier 1 through 3 were successful (other than an unrelated test failure that was problem listed) and the exhaustive test was locally run and passed with "16, 16" to increase the testing density.

src/java.base/share/classes/java/lang/FdLibm.java line 3337:

> 3335:             }
> 3336:             x  = Math.abs(x);
> 3337:             p  = Math.abs(p);

Suggestion:

            x = Math.abs(x);
            p = Math.abs(p);

src/java.base/share/classes/java/lang/FdLibm.java line 3371:

> 3369: 
> 3370:             // purge off exception values
> 3371:             if((hy | ly) == 0 || (hx >= 0x7ff0_0000)||       // y = 0, or x not finite

Suggestion:

            if ((hy | ly) == 0 || (hx >= 0x7ff0_0000)||       // y = 0, or x not finite

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13113#discussion_r1143236600
PR Review Comment: https://git.openjdk.org/jdk/pull/13113#discussion_r1143236820

From alanb at openjdk.org  Tue Mar 21 11:34:58 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 21 Mar 2023 11:34:58 GMT
Subject: RFR: 8294972: Convert jdk.jlink internal plugins to use the
 Classfile API [v14]
In-Reply-To: <9ZeKCgzF1skBwSKW1SXFTwyR44JYO22QJbboqdq0lOY=.b56a76ac-2c58-489b-afc9-9a1fca1238cf@github.com>
References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com>
 <0efK-pRtx-xkeOMKMEZBRcwFOoNFphU3Nubw9shBVIc=.42e2cb69-7ad9-4f23-9d23-2a95f6738753@github.com>
 
 <9ZeKCgzF1skBwSKW1SXFTwyR44JYO22QJbboqdq0lOY=.b56a76ac-2c58-489b-afc9-9a1fca1238cf@github.com>
Message-ID: 

On Tue, 21 Mar 2023 09:10:05 GMT, Adam Sotona  wrote:

>> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 1021:
>> 
>>> 1019:                                   MethodTypeDesc.of(CD_void, CD_String))
>>> 1020:                    .astore(BUILDER_VAR)
>>> 1021:                    .aload(BUILDER_VAR);
>> 
>> The methods to generate the MD all load the Builder onto the operand stack so the aload at L1021 is catching my attention, is that needed?
>
> It seems to be redundant as the following code does not expect it on stack and loads it again as needed.

Yes, I think so. If `java -XX:+UnlockDiagnosticVMOptions -XX:+BytecodeVerificationLocal -version` doesn't fail and you've run all the tests then it should be okay to drop it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12944#discussion_r1143238336

From aturbanov at openjdk.org  Tue Mar 21 11:45:42 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 21 Mar 2023 11:45:42 GMT
Subject: RFR: JDK-8304028: Port fdlibm IEEEremainder to Java
In-Reply-To: 
References: 
Message-ID: <7VGzUfoa0EXGiS-v5YXLlbogZTAGZT0Ji9fj-k-HWy0=.c747c65f-88c9-47e3-8954-e7624dd22d09@github.com>

On Tue, 21 Mar 2023 06:11:57 GMT, Joe Darcy  wrote:

> Last but not least, a port of fdlibm IEEEremainder from C to Java. I plan to write some more implementation-specific tests around decision points in the FDLIBM algorithm, but I wanted to get the bulk of the changes out for review first.
> 
> Note that since IEEEremainder was the last native method in StrictMath.java, the StrictMath.c file needed to be deleted (or modified) since StrictMath.h was no longer generated as part of the build. (StrictMath.c was one of the file deleted as part of JDK-8302801).
> 
> For testing, Mach 5 tier 1 through 3 were successful (other than an unrelated test failure that was problem listed) and the exhaustive test was locally run and passed with "16, 16" to increase the testing density.

src/java.base/share/classes/java/lang/FdLibm.java line 3399:

> 3397:                 }
> 3398:             }
> 3399:             if(iy >= -1022)

Suggestion:

            if (iy >= -1022)

src/java.base/share/classes/java/lang/FdLibm.java line 3414:

> 3412:             // fix point fmod
> 3413:             n = ix - iy;
> 3414:             while(n-- != 0) {

Suggestion:

            while (n-- != 0) {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13113#discussion_r1143247870
PR Review Comment: https://git.openjdk.org/jdk/pull/13113#discussion_r1143249143

From asotona at openjdk.org  Tue Mar 21 11:58:06 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 21 Mar 2023 11:58:06 GMT
Subject: RFR: 8294972: Convert jdk.jlink internal plugins to use the
 Classfile API [v14]
In-Reply-To: 
References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com>
 <0efK-pRtx-xkeOMKMEZBRcwFOoNFphU3Nubw9shBVIc=.42e2cb69-7ad9-4f23-9d23-2a95f6738753@github.com>
 
 <9ZeKCgzF1skBwSKW1SXFTwyR44JYO22QJbboqdq0lOY=.b56a76ac-2c58-489b-afc9-9a1fca1238cf@github.com>
 
Message-ID: 

On Tue, 21 Mar 2023 11:31:54 GMT, Alan Bateman  wrote:

>> It seems to be redundant as the following code does not expect it on stack and loads it again as needed.
>
> Yes, I think so. If `java -XX:+UnlockDiagnosticVMOptions -XX:+BytecodeVerificationLocal -version` doesn't fail and you've run all the tests then it should be okay to drop it.

I can confirm `java -XX:+UnlockDiagnosticVMOptions -XX:+BytecodeVerificationLocal -version` successful execution and passing all  jdk/tools/jlink tests. Now waiting for all tier1 tests results.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12944#discussion_r1143261554

From alanb at openjdk.org  Tue Mar 21 11:59:48 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 21 Mar 2023 11:59:48 GMT
Subject: RFR: JDK-8303742: CompletableFuture.orTimeout leaks if the future
 completes exceptionally
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 21 Mar 2023 11:02:00 GMT, Jaikiran Pai  wrote:

>> Improves the stability of the memory leak test for CompletableFuture timeout cancellation by both reducing the count by 50% (which should still be above threshold to trigger given the ample margin set initially) as well as extending the default timeout of the test run.
>
> test/jdk/java/util/concurrent/CompletableFuture/CompletableFutureOrTimeoutExceptionallyTest.java line 28:
> 
>> 26:  * @bug 8303742
>> 27:  * @summary CompletableFuture.orTimeout can leak memory if completed exceptionally
>> 28:  * @run junit/othervm/timeout=1000 -Xmx128m CompletableFutureOrTimeoutExceptionallyTest
> 
> Hello Viktor, a timeout of 1000 seconds is 16 minutes. This timeout value is then multiplied by the timeout factor (which is a jtreg option) to decide the final timeout. The CI on which this was reported use a timeout factor of 4. So this would translate to a timeout of 64 minutes, which I think is extremely high (although it's just the upper bound). 
> 
> Perhaps you could increase this timeout to maybe 5 minutes (300 seconds) and run some tests on our CI to see if that is sufficient?

If there isn't any value running this test with a debug build then you could have it skip (`@requires vm.debug == true`) to save resources.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13116#discussion_r1143263858

From pminborg at openjdk.org  Tue Mar 21 12:02:44 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 21 Mar 2023 12:02:44 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v5]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Tue, 21 Mar 2023 09:54:16 GMT, Maurizio Cimadamore  wrote:

>> I've added an example of how to print the platform-dependent structure. Should we document anyhow?
>
> I'm not sure about this. Honestly, the example probably doesn't help much if somebody didn't get the idea of what the layout might be. I think it might be better to say something like, `on Windows/x64 the returned layout might be as follows...` and then you write the code to create the layout instance corresponding to the returned layout. But we have to be careful to make the text non-normative (as the set of values might change).

What about adding something like this?


Here is a list of valid names for some platforms:
    Linux:
        "errno"
    macOS:
        "errno"
    Windows:
        "GetLastError", "WSAGetLastError" and "errno"

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1143265595

From mcimadamore at openjdk.org  Tue Mar 21 12:08:45 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 21 Mar 2023 12:08:45 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v5]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: <5VeF6VvOJ94JGz-slAqtwU-mtnhdV4qSk2KsbqVy-x4=.47d9a1f7-b86b-4d07-8ab1-f9abbaf3e5ed@github.com>

On Tue, 21 Mar 2023 11:58:28 GMT, Per Minborg  wrote:

>> I'm not sure about this. Honestly, the example probably doesn't help much if somebody didn't get the idea of what the layout might be. I think it might be better to say something like, `on Windows/x64 the returned layout might be as follows...` and then you write the code to create the layout instance corresponding to the returned layout. But we have to be careful to make the text non-normative (as the set of values might change).
>
> What about adding something like this?
> 
> 
> Here is a list of valid names for some platforms:
>     Linux:
>         "errno"
>     macOS:
>         "errno"
>     Windows:
>         "GetLastError", "WSAGetLastError" and "errno"

I'd prefer something more informal: "Examples of valid names are "errno" on Linux/x64, or "GetLastError" on Windows/x64". And maybe add that "The precise set of platform-dependent supported names can be queried using the returned group layout".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1143272764

From mcimadamore at openjdk.org  Tue Mar 21 12:17:43 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 21 Mar 2023 12:17:43 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 21 Mar 2023 00:54:10 GMT, Paul Sandoz  wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add example for Option::captureStateLayout
>
> src/java.base/share/classes/java/lang/foreign/Linker.java line 621:
> 
>> 619:          *          to a downcall handle linked with {@link #captureCallState(String...)}}
>> 620:          *
>> 621:          * @see #captureCallState(String...)
> 
> How does a caller know what the structure may contain? Should we document the platform specific structures?

Back to @PaulSandoz  question - "how does the caller know what the structure contains?". The caller typically doesn't care too much about what the returned struct is. But it might care about which "values" can be captured. That said, the set of such interesting values, is not too surprising. As demonstrated in the example in the `Linker.capturedCallState` method, once the client knows the name (and "errno" is likely to be 90% case), everything else follows from there - as the layout can be used to obtain var handles for the required values.

But, perhaps, now that I write this, I realize that what @PaulSandoz might _really_ be asking is: how do I know that e.g. the returned struct will not contain e.g. nested structs, sequences, or other non-sense. So we might specify (in a normative way) that the returned layout is a struct layout, whose member layouts are one or more value layouts (possibly with some added padding layouts). The names of the value layouts reflect the names of the values that can be captured.

And _then_ we show an example of the layout we return for Windows/x64 (as that's more interesting).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1143281164

From liach at openjdk.org  Tue Mar 21 12:28:22 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 21 Mar 2023 12:28:22 GMT
Subject: RFR: 8288730: Add type parameter to Lookup::accessClass and
 Lookup::ensureInitialized [v2]
In-Reply-To: 
References: 
Message-ID: 

> Parameterizes `Lookup::accessClass` and `Lookup::ensureInitialized`. Updated an applicable use-site within JDK to benefit from this patch.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Update return spec to indicate the same targetClass object is returned

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12984/files
  - new: https://git.openjdk.org/jdk/pull/12984/files/e4dc34cb..3b7d8055

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12984&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12984&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12984.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12984/head:pull/12984

PR: https://git.openjdk.org/jdk/pull/12984

From liach at openjdk.org  Tue Mar 21 12:28:25 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 21 Mar 2023 12:28:25 GMT
Subject: RFR: 8288730: Add type parameter to Lookup::accessClass and
 Lookup::ensureInitialized
In-Reply-To: 
References: 
Message-ID: 

On Sat, 11 Mar 2023 03:28:16 GMT, Chen Liang  wrote:

> Parameterizes `Lookup::accessClass` and `Lookup::ensureInitialized`. Updated an applicable use-site within JDK to benefit from this patch.

Based on the feedback in the CSR, updated the return spec for `accessClass` to indicate the input `targetClass` is returned, in line with the specification for `ensureInitialized`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12984#issuecomment-1477748354

From liach at openjdk.org  Tue Mar 21 12:42:06 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 21 Mar 2023 12:42:06 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
Message-ID: 

On Tue, 8 Feb 2022 17:23:38 GMT, Stuart Marks  wrote:

> PR for Sequenced Collections implementation.

I am interested in the optimization potential of `arraylist.reversed().addAll()` and similar batch operations. Though reverse list/deque views are a good start, I still wish to see customized implementations for `reversed` to perform `addAll` `removeIf` efficiently.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1477768549

From pminborg at openjdk.org  Tue Mar 21 13:39:05 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 21 Mar 2023 13:39:05 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 21 Mar 2023 09:02:29 GMT, Per Minborg  wrote:

>> API changes for the FFM API (third preview)
>> 
>> Specdiff:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
>> 
>> Javadoc:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add example for Option::captureStateLayout

A review of all the copyright years shall be made in this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13079#issuecomment-1477849414

From liach at openjdk.org  Tue Mar 21 13:57:24 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 21 Mar 2023 13:57:24 GMT
Subject: RFR: 8301552: Use AtomicReferenceArray for caching instead of CHM
 in ZoneOffset [v8]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Tue, 21 Mar 2023 07:25:38 GMT, Per Minborg  wrote:

>> src/java.base/share/classes/java/time/ZoneOffset.java line 430:
>> 
>>> 428:     public static ZoneOffset ofTotalSeconds(int totalSeconds) {
>>> 429:         final class Holder {
>>> 430:             private static final IntFunction ZONE_OFFSET_MAPPER = new ZoneOffsetMapper();
>> 
>> Can't the ZoneOffsetMapper itself serve as a holder class? so we move this singleton into ZoneOffsetMapper itself.
>
> It is possible but this keeps the mapper more local and only accessible where it is supposed to be used. For testing purposed, it might be better to have the class as you propose.

If we want it local, I suppose we can convert the whole `ZoneOffsetMapper` local with this singleton in `ofTotalSeconds` static method as well.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12346#discussion_r1143415419

From liach at openjdk.org  Tue Mar 21 13:57:26 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 21 Mar 2023 13:57:26 GMT
Subject: RFR: 8301552: Use AtomicReferenceArray for caching instead of CHM
 in ZoneOffset [v8]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Tue, 21 Mar 2023 07:29:49 GMT, Per Minborg  wrote:

>> It can. I think either works fine. Maybe a bit nicer with a method reference as you propose.
>
> Perhaps you mean the method could be *replaced* with `Integer::valueOf"? Good suggestion.

Yes, `Integer::valueOf` is a better replacement of individual `intIdentity` calls. Thought you may want this method so only one lambda callsite would be generated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12346#discussion_r1143417225

From liangchenblue at gmail.com  Tue Mar 21 14:01:11 2023
From: liangchenblue at gmail.com (-)
Date: Tue, 21 Mar 2023 09:01:11 -0500
Subject: RFR: 8302818: Optimize wrapper sets and immutable sets of Enums
 [v5]
In-Reply-To: 
References: 
 
Message-ID: 

Hello Stuart Marks, would you be able to take a look at this patch,
improving performance of enum-only immutable collections, as you are
the primary engineer in this area?


On Mon, Feb 20, 2023 at 9:40?PM Tingjun Yuan  wrote:
>
> > Currently, the two subclasses of `java.util.EnumSet` optimize bulk operations when the argument is also a `EnumSet`, but there is no such optimization for wrapper sets (returned by `Collections.unmodifiableSet`, `Collections.synchronizedSet`, etc.) and immutable sets (returned by `Set.of` methods) of `Enum`s.
> >
> > This PR introduces optimization classes for these situations.  No public APIs are changed.
>
> Tingjun Yuan has updated the pull request incrementally with one additional commit since the last revision:
>
>   Set.copyOf: need defensive copy
>
> -------------
>
> Changes:
>   - all: https://git.openjdk.org/jdk/pull/12498/files
>   - new: https://git.openjdk.org/jdk/pull/12498/files/b9699bfe..0e0b2bf1
>
> Webrevs:
>  - full: https://webrevs.openjdk.org/?repo=jdk&pr=12498&range=04
>  - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12498&range=03-04
>
>   Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
>   Patch: https://git.openjdk.org/jdk/pull/12498.diff
>   Fetch: git fetch https://git.openjdk.org/jdk pull/12498/head:pull/12498
>
> PR: https://git.openjdk.org/jdk/pull/12498

From mcimadamore at openjdk.org  Tue Mar 21 14:55:32 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 21 Mar 2023 14:55:32 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 20 Mar 2023 20:31:46 GMT, Jim Laskey  wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Tidy javadoc
>  - Rename StringTemplate classes

I like the new naming scheme!

src/java.base/share/classes/java/lang/StringTemplate.java line 28:

> 26: package java.lang;
> 27: 
> 28: import java.lang.Object;

You might want to do another pass to check for unused imports

src/java.base/share/classes/java/lang/StringTemplate.java line 44:

> 42:  * {@link StringTemplate} is the run-time representation of a string template or
> 43:  * text block template in a template expression.
> 44:  *

Extra newline?

src/java.base/share/classes/java/lang/StringTemplate.java line 56:

> 54:  * {@link StringTemplate} is primarily used in conjunction with a template processor
> 55:  * to produce a string or other meaningful value. Evaluation of a template expression
> 56:  * first produces an instance of {@link StringTemplate}, representing the template

The "template of the template expression" - is this nomenclature official (e.g. backed by any text in the JLS?). I must admit I find it a tad jarring.

src/java.base/share/classes/java/lang/StringTemplate.java line 69:

> 67:  * List values = st.values();
> 68:  * }
> 69:  * The value of {@code fragments} will be equivalent to {@code List.of("", " + ", " = ", "")},

This is a bit hard to parse, due to the use of `the value of` (which then becomes problematic in the next para, as we are talking about `values`). Either change the name of the variable `values` in the snippet, or use some other locution, like "the list {@code fragments} is equivalent to ..." etc.

src/java.base/share/classes/java/lang/StringTemplate.java line 324:

> 322:      * assert Objects.equals(sc, "abcxyz");
> 323:      * }
> 324:      * the last character {@code "c"} from the first string is juxtaposed with the first

I was playing with this example in jshell:

jshell> var st1 = RAW."{1}"
st1 ==> StringTemplate{ fragments = [ "", "" ], values = [1] }

jshell> var st2 = RAW."{2}"
st2 ==> StringTemplate{ fragments = [ "", "" ], values = [2] }

jshell> StringTemplate.combine(st1, st2);
$7 ==> StringTemplate{ fragments = [ "", "", "" ], values = [1, 2] }


The result is obviously well-formed - but I'm not sure I can derive what the method does just by reading the javadoc. The javadoc says:

Fragment lists from the StringTemplates are combined end to end with the last fragment from each StringTemplate concatenated with the first fragment of the next

I think I see what you want to say - (e.g. the end fragment of string template `N` is concatenated with the starting fragment of string template `N + 1`).

src/java.base/share/classes/java/lang/StringTemplate.java line 431:

> 429:      * Java compilation unit.
    The result of interpolation is not interned.
> 430:      */
> 431:     static final StringProcessor STR = StringTemplate::interpolate;

`static final` is redundant here (we are in an interface)

src/java.base/share/classes/java/lang/StringTemplate.java line 454:

> 452:      * This interface describes the methods provided by a generalized string template processor. The
> 453:      * primary method {@link Processor#process(StringTemplate)} is used to validate
> 454:      * and compose a result using a {@link StringTemplate StringTemplate's} fragments and values lists.

nit: `{@link StringTemplate StringTemplate's}` will probably not render as you'd expect (as it will all be preformat, including the `'s`).

src/java.base/share/classes/java/lang/runtime/ReferenceKey.java line 47:

> 45:  */
> 46: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
> 47: interface ReferenceKey {

This (and other) class are package-private. Do we still need @PreviewFeature for stuff like this, since it's not meant to be used publicly?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 226:

> 224:                         List.nil(), expressions);
> 225:                 valuesArray.type = new ArrayType(syms.objectType, syms.arrayClass);
> 226:                 return bsmCall(names.process, names.newLargeStringTemplate, syms.stringTemplateType,

nit: the indy name is irrelevant here - that said, `process` is a tad confusing, since it's also the name of a StringTemplate method.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 252:

> 250:                 staticArgsTypes = staticArgsTypes.append(syms.stringType);
> 251:             }
> 252:             return bsmCall(names.process, names.processStringTemplate, tree.type,

What happens if we have too many fragments here? (e.g. > 200). That case seems handled in the RAW case.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 281:

> 279:             make.at(tree.pos);
> 280: 
> 281:             if (processor == null || isNamedProcessor(names.RAW)) {

is `processor == null` still a thing?

-------------

PR Review: https://git.openjdk.org/jdk/pull/10889#pullrequestreview-1350457321
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1143370713
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1143371242
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1143373826
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1143379210
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1143441733
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1143444292
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1143448931
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1143484050
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1143501675
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1143507003
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1143487363

From mcimadamore at openjdk.org  Tue Mar 21 14:55:33 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 21 Mar 2023 14:55:33 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 21 Mar 2023 13:31:37 GMT, Maurizio Cimadamore  wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Tidy javadoc
>>  - Rename StringTemplate classes
>
> src/java.base/share/classes/java/lang/StringTemplate.java line 69:
> 
>> 67:  * List values = st.values();
>> 68:  * }
>> 69:  * The value of {@code fragments} will be equivalent to {@code List.of("", " + ", " = ", "")},
> 
> This is a bit hard to parse, due to the use of `the value of` (which then becomes problematic in the next para, as we are talking about `values`). Either change the name of the variable `values` in the snippet, or use some other locution, like "the list {@code fragments} is equivalent to ..." etc.

The above comment also applies to the javadoc of the `fragments` and `values` methods, which use a similar way to describe their results.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1143387999

From duke at openjdk.org  Tue Mar 21 14:58:41 2023
From: duke at openjdk.org (Viktor Klang)
Date: Tue, 21 Mar 2023 14:58:41 GMT
Subject: RFR: JDK-8303742: CompletableFuture.orTimeout leaks if the future
 completes exceptionally
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 21 Mar 2023 11:02:00 GMT, Jaikiran Pai  wrote:

>> Improves the stability of the memory leak test for CompletableFuture timeout cancellation by both reducing the count by 50% (which should still be above threshold to trigger given the ample margin set initially) as well as extending the default timeout of the test run.
>
> test/jdk/java/util/concurrent/CompletableFuture/CompletableFutureOrTimeoutExceptionallyTest.java line 28:
> 
>> 26:  * @bug 8303742
>> 27:  * @summary CompletableFuture.orTimeout can leak memory if completed exceptionally
>> 28:  * @run junit/othervm/timeout=1000 -Xmx128m CompletableFutureOrTimeoutExceptionallyTest
> 
> Hello Viktor, a timeout of 1000 seconds is 16 minutes. This timeout value is then multiplied by the timeout factor (which is a jtreg option) to decide the final timeout. The CI on which this was reported use a timeout factor of 4. So this would translate to a timeout of 64 minutes, which I think is extremely high (although it's just the upper bound). 
> 
> Perhaps you could increase this timeout to maybe 5 minutes (300 seconds) and run some tests on our CI to see if that is sufficient?

@jaikiran Having a long timeout doesn't seem like a problem given that it just needs enough time to run through the iterations (i.e. that's the max duration of the test before giving up).

@AlanBateman That's a great observation?do you see anything about this which would impact whether it makes sense to run on top of a debug-build (I don't see any). If it doesn't need to run on a debug build then I'll add the requirement you suggested. Let me know.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13116#discussion_r1143522447

From liach at openjdk.org  Tue Mar 21 14:58:55 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 21 Mar 2023 14:58:55 GMT
Subject: Integrated: 8304180: Constant Descriptors for MethodHandles::classData
 and classDataAt
In-Reply-To: 
References: 
Message-ID: 

On Wed, 15 Mar 2023 02:18:37 GMT, Chen Liang  wrote:

> Add Constant Descriptors for DirectMethodHandleDesc of MethodHandles::classData and classDataAt in ConstantDescs. This facilitates easier access of class data via condy in Classfile API-generated bytecode. Most other constant bootstrap methods provided in the JDK, notably from `ConstantBootstraps`, already have constant descriptors in ConstantDescs.
> 
> Context: https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000235.html

This pull request has now been integrated.

Changeset: d788a1bb
Author:    Chen Liang 
Committer: Jorn Vernee 
URL:       https://git.openjdk.org/jdk/commit/d788a1bb808da73ef17aee0b773b7e3ea682426f
Stats:     16 lines in 1 file changed: 16 ins; 0 del; 0 mod

8304180: Constant Descriptors for MethodHandles::classData and classDataAt

Reviewed-by: jvernee, mchung

-------------

PR: https://git.openjdk.org/jdk/pull/13033

From duke at openjdk.org  Tue Mar 21 15:11:42 2023
From: duke at openjdk.org (Viktor Klang)
Date: Tue, 21 Mar 2023 15:11:42 GMT
Subject: RFR: JDK-8303742: CompletableFuture.orTimeout leaks if the future
 completes exceptionally
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 21 Mar 2023 11:56:57 GMT, Alan Bateman  wrote:

>> test/jdk/java/util/concurrent/CompletableFuture/CompletableFutureOrTimeoutExceptionallyTest.java line 28:
>> 
>>> 26:  * @bug 8303742
>>> 27:  * @summary CompletableFuture.orTimeout can leak memory if completed exceptionally
>>> 28:  * @run junit/othervm/timeout=1000 -Xmx128m CompletableFutureOrTimeoutExceptionallyTest
>> 
>> Hello Viktor, a timeout of 1000 seconds is 16 minutes. This timeout value is then multiplied by the timeout factor (which is a jtreg option) to decide the final timeout. The CI on which this was reported use a timeout factor of 4. So this would translate to a timeout of 64 minutes, which I think is extremely high (although it's just the upper bound). 
>> 
>> Perhaps you could increase this timeout to maybe 5 minutes (300 seconds) and run some tests on our CI to see if that is sufficient?
>
> If there isn't any value running this test with a debug build then you could have it skip (`@requires vm.debug == true`) to save resources.

@AlanBateman Wouldn't that be `@requires vm.debug == false` ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13116#discussion_r1143541565

From redestad at openjdk.org  Tue Mar 21 15:26:22 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 21 Mar 2023 15:26:22 GMT
Subject: RFR: 8302818: Optimize wrapper sets and immutable sets of Enums
 [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 21 Feb 2023 03:39:46 GMT, Tingjun Yuan  wrote:

>> Currently, the two subclasses of `java.util.EnumSet` optimize bulk operations when the argument is also a `EnumSet`, but there is no such optimization for wrapper sets (returned by `Collections.unmodifiableSet`, `Collections.synchronizedSet`, etc.) and immutable sets (returned by `Set.of` methods) of `Enum`s.
>> 
>> This PR introduces optimization classes for these situations.  No public APIs are changed.
>
> Tingjun Yuan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Set.copyOf: need defensive copy

I'm wary of the impact of adding new wrapper classes. It may make the factory methods slightly slower due additional checks, but also risks increasing the number of classes at various call-sites which might upset call site inlining. 

An alternative design which would avoid adding more classes could be to add package-private accessors to the existing `Unmodifiable/Synchronized` wrapper classes so that `EnumSet/-Map` can retrieve the underlying set of an unmodifiable or synchronized `Set` or `Map` and then use it directly for these bulk operations. Then you'd contain the additional overhead to `EnumSet/-Map`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12498#issuecomment-1478035549

From pminborg at openjdk.org  Tue Mar 21 15:58:25 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 21 Mar 2023 15:58:25 GMT
Subject: RFR: 8300979: Lazily initialize (byte,
 char)arr in java.io.DataInputStream
Message-ID: 

This PR proposed to lazily initialize the scratch arrays only if/when needed.

-------------

Commit messages:
 - Remove redundant initilizers
 - Lazily initialize (byte, char)arr in java.io.DataInputStream

Changes: https://git.openjdk.org/jdk/pull/13121/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13121&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300979
  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/13121.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13121/head:pull/13121

PR: https://git.openjdk.org/jdk/pull/13121

From duke at openjdk.org  Tue Mar 21 16:11:43 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 21 Mar 2023 16:11:43 GMT
Subject: RFR: 8300979: Lazily initialize (byte,
 char)arr in java.io.DataInputStream
In-Reply-To: 
References: 
Message-ID: 

On Tue, 21 Mar 2023 15:41:13 GMT, Per Minborg  wrote:

> This PR proposed to lazily initialize the scratch arrays only if/when needed.

Looks good. Many DataInputStreams probably never read UTF. (Not a reviewer)

src/java.base/share/classes/java/io/DataInputStream.java line 576:

> 574:         char[] chararr = null;
> 575:         if (in instanceof DataInputStream dis) {
> 576:             if (dis.bytearr == null || dis.bytearr.length < utflen){

Add a space between ')' and '{'?

Suggestion:

            if (dis.bytearr == null || dis.bytearr.length < utflen) {

-------------

Marked as reviewed by eirbjo at github.com (no known OpenJDK username).

PR Review: https://git.openjdk.org/jdk/pull/13121#pullrequestreview-1350859010
PR Review Comment: https://git.openjdk.org/jdk/pull/13121#discussion_r1143638420

From psandoz at openjdk.org  Tue Mar 21 16:16:33 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 21 Mar 2023 16:16:33 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v2]
In-Reply-To: 
References: 
 
Message-ID: <34zcCpLdmLg_1qtY5maOBw5ozxupQlkKPOf3Kzljybc=.d995b7c1-6ad0-4af4-9bc3-bf6cda45d274@github.com>

On Sun, 19 Mar 2023 19:38:04 GMT, Quan Anh Mai  wrote:

>> Hi,
>> 
>> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, VectorShuffle is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
>> 
>> 1. Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
>> 2. Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
>> 3. Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
>> 4. Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
>> 
>> Upon these changes, a `rearrange` can emit more efficient code:
>> 
>>     var species = IntVector.SPECIES_128;
>>     var v1 = IntVector.fromArray(species, SRC1, 0);
>>     var v2 = IntVector.fromArray(species, SRC2, 0);
>>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
>> 
>>     Before:
>>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>>     vmovdqu 0x10(%r10),%xmm0
>>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byte_mask
>>                                                             ;   {external_word}
>>     vpackusdw %xmm0,%xmm0,%xmm0
>>     vpackuswb %xmm0,%xmm0,%xmm0
>>     vpmovsxbd %xmm0,%xmm3
>>     vpcmpgtd %xmm3,%xmm1,%xmm3
>>     vtestps %xmm3,%xmm3
>>     jne    0x00007fc2acb4e0d8
>>     vpmovzxbd %xmm0,%xmm0
>>     vpermd %ymm2,%ymm0,%ymm0
>>     movabs $0x751588f98,%r10            ;   {oop([I{0x0000000751588f98})}
>>     vmovdqu %xmm0,0x10(%r10)
>> 
>>     After:
>>     movabs $0x751589c78,%r10            ;   {oop([I{0x0000000751589c78})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158ac88,%r10            ;   {oop([I{0x000000075158ac88})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     vpxor  %xmm0,%xmm0,%xmm0
>>     vpcmpgtd %xmm2,%xmm0,%xmm3
>>     vtestps %xmm3,%xmm3
>>     jne    0x00007fa818b27cb1
>>     vpermd %ymm1,%ymm2,%ymm0
>>     movabs $0x751588c68,%r10            ;   {oop([I{0x0000000751588c68})}
>>     vmovdqu %xmm0,0x10(%r10)
>>     
>> Please take a look and leave reviews. Thanks a lot.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix Matcher::vector_needs_load_shuffle

That looks like a very good simplification and performance enhancement, and removing a limitation, the byte[] representation. This should likely also help with Valhalla integration.

IIUC it has the same upper bound limitation for vector lengths greater than the maximum index size that can be represented as a lane element (although in practice there may not be any hardware where this can occur). Which is fine, i am not suggesting we try and fix this.

Perhaps it may be possible to move some methods on the concrete implementations to the abstract implementations as helper methods or template methods, thereby reducing the amount of generated code? It seems so in some cases, but i did not look very closely. It may require the introduction of an an element type specific abstract shuffle, and if that's the case it may not be worth it.

--

Relatedly, i would be interested in your opinion on the following. One annoyance in the API which propagates down into the implementation is `VectorShuffle` and `VectorMask` have `E` that is the lane element type. But, in theory they should not need E, and any shuffle or mask with the same lanes as the vector being operated on should be compatible, and it's an implementation detail of the shuffle/mask how its state represented as a hardware register. However, i don't have a good sense of the implications this has to the current HotSpot implementation and whether it is feasible.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13093#pullrequestreview-1349108003

From qamai at openjdk.org  Tue Mar 21 16:16:31 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 21 Mar 2023 16:16:31 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v3]
In-Reply-To: 
References: 
Message-ID: <4Op0Z8whnyDXDC6zGyMbx4ugcZp5TEoAqW_myB5flxM=.1c7b59ba-efb2-4f68-90d7-2d6e33e39572@github.com>

> Hi,
> 
> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, VectorShuffle is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
> 
> 1. Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
> 2. Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
> 3. Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
> 4. Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
> 
> Upon these changes, a `rearrange` can emit more efficient code:
> 
>     var species = IntVector.SPECIES_128;
>     var v1 = IntVector.fromArray(species, SRC1, 0);
>     var v2 = IntVector.fromArray(species, SRC2, 0);
>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
> 
>     Before:
>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>     vmovdqu 0x10(%r10),%xmm2
>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>     vmovdqu 0x10(%r10),%xmm1
>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>     vmovdqu 0x10(%r10),%xmm0
>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byte_mask
>                                                             ;   {external_word}
>     vpackusdw %xmm0,%xmm0,%xmm0
>     vpackuswb %xmm0,%xmm0,%xmm0
>     vpmovsxbd %xmm0,%xmm3
>     vpcmpgtd %xmm3,%xmm1,%xmm3
>     vtestps %xmm3,%xmm3
>     jne    0x00007fc2acb4e0d8
>     vpmovzxbd %xmm0,%xmm0
>     vpermd %ymm2,%ymm0,%ymm0
>     movabs $0x751588f98,%r10            ;   {oop([I{0x0000000751588f98})}
>     vmovdqu %xmm0,0x10(%r10)
> 
>     After:
>     movabs $0x751589c78,%r10            ;   {oop([I{0x0000000751589c78})}
>     vmovdqu 0x10(%r10),%xmm1
>     movabs $0x75158ac88,%r10            ;   {oop([I{0x000000075158ac88})}
>     vmovdqu 0x10(%r10),%xmm2
>     vpxor  %xmm0,%xmm0,%xmm0
>     vpcmpgtd %xmm2,%xmm0,%xmm3
>     vtestps %xmm3,%xmm3
>     jne    0x00007fa818b27cb1
>     vpermd %ymm1,%ymm2,%ymm0
>     movabs $0x751588c68,%r10            ;   {oop([I{0x0000000751588c68})}
>     vmovdqu %xmm0,0x10(%r10)
>     
> Please take a look and leave reviews. Thanks a lot.

Quan Anh Mai has updated the pull request incrementally with two additional commits since the last revision:

 - missing casts
 - clean up

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13093/files
  - new: https://git.openjdk.org/jdk/pull/13093/files/060554a9..4caa9d10

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13093&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13093&range=01-02

  Stats: 1396 lines in 36 files changed: 44 ins; 1339 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/13093.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13093/head:pull/13093

PR: https://git.openjdk.org/jdk/pull/13093

From qamai at openjdk.org  Tue Mar 21 16:16:34 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 21 Mar 2023 16:16:34 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 19 Mar 2023 19:38:04 GMT, Quan Anh Mai  wrote:

>> Hi,
>> 
>> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, VectorShuffle is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
>> 
>> 1. Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
>> 2. Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
>> 3. Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
>> 4. Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
>> 
>> Upon these changes, a `rearrange` can emit more efficient code:
>> 
>>     var species = IntVector.SPECIES_128;
>>     var v1 = IntVector.fromArray(species, SRC1, 0);
>>     var v2 = IntVector.fromArray(species, SRC2, 0);
>>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
>> 
>>     Before:
>>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>>     vmovdqu 0x10(%r10),%xmm0
>>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byte_mask
>>                                                             ;   {external_word}
>>     vpackusdw %xmm0,%xmm0,%xmm0
>>     vpackuswb %xmm0,%xmm0,%xmm0
>>     vpmovsxbd %xmm0,%xmm3
>>     vpcmpgtd %xmm3,%xmm1,%xmm3
>>     vtestps %xmm3,%xmm3
>>     jne    0x00007fc2acb4e0d8
>>     vpmovzxbd %xmm0,%xmm0
>>     vpermd %ymm2,%ymm0,%ymm0
>>     movabs $0x751588f98,%r10            ;   {oop([I{0x0000000751588f98})}
>>     vmovdqu %xmm0,0x10(%r10)
>> 
>>     After:
>>     movabs $0x751589c78,%r10            ;   {oop([I{0x0000000751589c78})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158ac88,%r10            ;   {oop([I{0x000000075158ac88})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     vpxor  %xmm0,%xmm0,%xmm0
>>     vpcmpgtd %xmm2,%xmm0,%xmm3
>>     vtestps %xmm3,%xmm3
>>     jne    0x00007fa818b27cb1
>>     vpermd %ymm1,%ymm2,%ymm0
>>     movabs $0x751588c68,%r10            ;   {oop([I{0x0000000751588c68})}
>>     vmovdqu %xmm0,0x10(%r10)
>>     
>> Please take a look and leave reviews. Thanks a lot.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix Matcher::vector_needs_load_shuffle

Yes I will try to polish the patch more after finding the cause of the failure in x86_32. The failure is strange, though, it does not occur on x86_64 for some reasons.

> One annoyance in the API which propagates down into the implementation is `VectorShuffle` and `VectorMask` have `E` that is the lane element type.

Yes I agree, a shuffle merely contains the lane indices while a mask is an array of boolean, it would be a good cleanup to remove `E` from the interface.

> However, i don't have a good sense of the implications this has to the current HotSpot implementation and whether it is feasible.

Note that generics are erased, so from the VM point of view, a `VectorMask` and a `VectorMask` is indifferent. As a result, removing the type parameter should not have any impact on the VM. Some details may have to change though, as element types are removed, a mask or shuffle would only be validated in accordance to its length, and we need to insert a cast at use sites. The cast will be removed if it is actually the same species so there is little concern regarding the machine code emitted.

Thanks a lot.

I have moved most of the methods to `AbstractVector` and `AbstractShuffle`, I have to resort to raw types, though, since there seems to be no way to do the same with wild cards, and the generics mechanism is not powerful enough for things like `Vector`. The remaining failure seems to be related to [JDK-8304676](https://bugs.openjdk.org/projects/JDK/issues/JDK-8304676), so I think this patch is ready for review now.

> The mask implementation is specialized by the species of vectors it operates on, but does it have to be

Apart from the mask implementation, shuffle implementation definitely has to take into consideration the element type. However, this information does not have to be visible to the API, similar to how we currently handle the vector length, we can have `class AbstractMask implements VectorMask`. As a result, the cast method would be useless and can be removed in the API, but our implementation details would still use it, for example

    Vector blend(Vector v, VectorMask w) {
        AbstractMask aw = (AbstractMask) w;
        AbstractMask tw = aw.cast(vspecies());
        return VectorSupport.blend(...);
    }

    Vector rearrange(VectorShuffle s) {
        AbstractShuffle as = (AbstractShuffle) s;
        AbstractShuffle ts = s.cast(vspecies());
        return VectorSupport.rearrangeOp(...);
    }

What do you think?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13093#issuecomment-1477581887
PR Comment: https://git.openjdk.org/jdk/pull/13093#issuecomment-1478140557

From psandoz at openjdk.org  Tue Mar 21 16:17:07 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 21 Mar 2023 16:17:07 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 21 Mar 2023 16:11:50 GMT, Quan Anh Mai  wrote:

> I have moved most of the methods to `AbstractVector` and `AbstractShuffle`, I have to resort to raw types, though, since there seems to be no way to do the same with wild cards, and the generics mechanism is not powerful enough for things like `Vector`. The remaining failure seems to be related to [JDK-8304676](https://bugs.openjdk.org/projects/JDK/issues/JDK-8304676), so I think this patch is ready for review now.

The Java changes look good to me. I need to have another look, but will not be able to do so until next week.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13093#issuecomment-1478148846

From psandoz at openjdk.org  Tue Mar 21 16:16:35 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 21 Mar 2023 16:16:35 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v2]
In-Reply-To: 
References: 
 
 
Message-ID: <5WEC6Qqt9dnLkrD7AlIXjAImDgYtcUgvQlR3acn1oi0=.96d3caf3-a2b9-4491-b2ba-a9d04f658772@github.com>

On Tue, 21 Mar 2023 10:18:19 GMT, Quan Anh Mai  wrote:

> Note that generics are erased, so from the VM point of view, a `VectorMask` and a `VectorMask` is indifferent.

Yes, that's the easy bit :-) The mask implementation is specialized by the species of vectors it operates on, but does it have to be and can we make it independent of the species and bind to the lane count? 

Then the user does not need to explicitly cast from and to species that have the same lane count, which means we can remove the VectorMask::cast method (since it already throws if the lane counts are not equal).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13093#issuecomment-1478069401

From liach at openjdk.org  Tue Mar 21 16:19:38 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 21 Mar 2023 16:19:38 GMT
Subject: Integrated: 8304139: Add  and  method constants to
 ConstantDescs
In-Reply-To: 
References: 
Message-ID: <471jjh_f3DxA_oVplr1hg0PBZEQ3vzJ5HOLievQ_DT0=.977083f7-8260-47db-b912-5ef807682fb8@github.com>

On Tue, 14 Mar 2023 14:30:32 GMT, Chen Liang  wrote:

> Add String constants INIT_NAME, CLASS_INIT_NAME, MTD_void for the names and method type of instance and class initializers, as they are frequently used in the Classfile API. In addition, they appear frequently in the JDK itself as well.
> 
> Update occurrences of  and  in core libraries API specification to refer to these constants. The occurrences in code elsewhere will be converted separately for there are too many.
> 
> See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000233.html

This pull request has now been integrated.

Changeset: 019fcd81
Author:    Chen Liang 
Committer: Mandy Chung 
URL:       https://git.openjdk.org/jdk/commit/019fcd819c4f24e6c9de9d4f9fc64b8db6bc6cfa
Stats:     56 lines in 7 files changed: 35 ins; 0 del; 21 mod

8304139: Add  and  method constants to ConstantDescs

Reviewed-by: mchung

-------------

PR: https://git.openjdk.org/jdk/pull/13020

From bpb at openjdk.org  Tue Mar 21 16:20:28 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 21 Mar 2023 16:20:28 GMT
Subject: RFR: 8300979: Lazily initialize (byte,
 char)arr in java.io.DataInputStream
In-Reply-To: 
References: 
Message-ID: 

On Tue, 21 Mar 2023 15:41:13 GMT, Per Minborg  wrote:

> This PR proposed to lazily initialize the scratch arrays only if/when needed.

src/java.base/share/classes/java/io/DataInputStream.java line 64:

> 62:      * working arrays initialized on demand by readUTF
> 63:      */
> 64:     private byte[] bytearr;

Could the `bytearr` and `chararr` instance variables be removed altogether?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13121#discussion_r1143664354

From mchung at openjdk.org  Tue Mar 21 16:25:15 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 21 Mar 2023 16:25:15 GMT
Subject: RFR: 8288730: Add type parameter to Lookup::accessClass and
 Lookup::ensureInitialized [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 21 Mar 2023 12:28:22 GMT, Chen Liang  wrote:

>> Parameterizes `Lookup::accessClass` and `Lookup::ensureInitialized`. Updated an applicable use-site within JDK to benefit from this patch.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update return spec to indicate the same targetClass object is returned

The spec adjustment looks good, make it explicit that the method returns the argument passed to the method.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12984#issuecomment-1478163654

From psandoz at openjdk.org  Tue Mar 21 16:32:44 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 21 Mar 2023 16:32:44 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 21 Mar 2023 16:11:50 GMT, Quan Anh Mai  wrote:

> Apart from the mask implementation, shuffle implementation definitely has to take into consideration the element type.

Yes, the way you have implemented shuffle is tightly connected, that looks ok.

I am wondering if we can make the mask implementation more loosely coupled and modified such that it does not have to take into consideration the element type (or species) of the vector it operates on, and instead compatibility is based solely on the lane count.

Ideally it would be good to change the `VectorMask::check` method to just compare the lanes counts and not require a cast in the implementation, which i presume requires some deeper changes in C2?

What you propose seems a possible a interim step towards a more preferable API, if the performance is good.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13093#issuecomment-1478175761

From prappo at openjdk.org  Tue Mar 21 16:58:32 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 21 Mar 2023 16:58:32 GMT
Subject: RFR: 8302818: Optimize wrapper sets and immutable sets of Enums
 [v5]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 21 Mar 2023 15:23:53 GMT, Claes Redestad  wrote:

> An alternative design which would avoid adding more classes could be to add package-private accessors to the existing `Unmodifiable/Synchronized` wrapper classes so that `EnumSet/-Map` can retrieve the underlying set of an unmodifiable or synchronized `Set` or `Map` and then use it directly for these bulk operations. Then you'd contain the additional overhead to `EnumSet/-Map`.

Another alternative, in cases where `arg.getClass() == X.class` can be safely substituted with `requireNonNull(arg) instanceof X`, is a marker interface.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12498#issuecomment-1478253385

From duke at openjdk.org  Tue Mar 21 17:30:40 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 21 Mar 2023 17:30:40 GMT
Subject: RFR: 8300979: Lazily initialize (byte,
 char)arr in java.io.DataInputStream
In-Reply-To: 
References: 
Message-ID: 

On Tue, 21 Mar 2023 15:41:13 GMT, Per Minborg  wrote:

> This PR proposed to lazily initialize the scratch arrays only if/when needed.

Looks like `DataInputStream.readUTF` could benefit from using `JavaLangAccess.countPositives` and return early for the common case that all bytes are ASCII. Food for another PR?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13121#issuecomment-1478310588

From martin at openjdk.org  Tue Mar 21 17:51:26 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Tue, 21 Mar 2023 17:51:26 GMT
Subject: RFR: 8297605: DelayQueue javadoc is confusing [v2]
In-Reply-To: 
References: 
Message-ID: 

> Inviting @DougLea and @viktorklang-ora to review.
> 
> As usual, I couldn't resist more fiddling.  
> - Added missing tests for take, remove(), remove(Object).
> - Improved DelayQueueTest's testing infrastructure
> - added more test assertions
> - linkified new javadoc definitions

Martin Buchholz has updated the pull request incrementally with one additional commit since the last revision:

  fix punctuation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12838/files
  - new: https://git.openjdk.org/jdk/pull/12838/files/fb14b2f3..4d02235a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12838&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12838&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12838.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12838/head:pull/12838

PR: https://git.openjdk.org/jdk/pull/12838

From qamai at openjdk.org  Tue Mar 21 18:15:44 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 21 Mar 2023 18:15:44 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Tue, 21 Mar 2023 16:29:44 GMT, Paul Sandoz  wrote:

>> I have moved most of the methods to `AbstractVector` and `AbstractShuffle`, I have to resort to raw types, though, since there seems to be no way to do the same with wild cards, and the generics mechanism is not powerful enough for things like `Vector`. The remaining failure seems to be related to [JDK-8304676](https://bugs.openjdk.org/projects/JDK/issues/JDK-8304676), so I think this patch is ready for review now.
>> 
>>> The mask implementation is specialized by the species of vectors it operates on, but does it have to be
>> 
>> Apart from the mask implementation, shuffle implementation definitely has to take into consideration the element type. However, this information does not have to be visible to the API, similar to how we currently handle the vector length, we can have `class AbstractMask implements VectorMask`. As a result, the cast method would be useless and can be removed in the API, but our implementation details would still use it, for example
>> 
>>     Vector blend(Vector v, VectorMask w) {
>>         AbstractMask aw = (AbstractMask) w;
>>         AbstractMask tw = aw.cast(vspecies());
>>         return VectorSupport.blend(...);
>>     }
>> 
>>     Vector rearrange(VectorShuffle s) {
>>         AbstractShuffle as = (AbstractShuffle) s;
>>         AbstractShuffle ts = s.cast(vspecies());
>>         return VectorSupport.rearrangeOp(...);
>>     }
>> 
>> What do you think?
>
>> Apart from the mask implementation, shuffle implementation definitely has to take into consideration the element type.
> 
> Yes, the way you have implemented shuffle is tightly connected, that looks ok.
> 
> I am wondering if we can make the mask implementation more loosely coupled and modified such that it does not have to take into consideration the element type (or species) of the vector it operates on, and instead compatibility is based solely on the lane count.
> 
> Ideally it would be good to change the `VectorMask::check` method to just compare the lanes counts and not require a cast in the implementation, which i presume requires some deeper changes in C2?
> 
> What you propose seems a possible a interim step towards a more preferable API, if the performance is good.

@PaulSandoz As some hardware does differentiate masks based on element type, at some point we have to differentiate between them. From a design point of view, they are both implementation details so there might be no consideration regarding the API. On the other hand, having more in the Java side seems to be more desirable, as it does illustrate the operations more intuitively compared to the graph management in C2. Another important point I can think of is that having a constant shape for a Java class would help us in implementing the vector calling convention, as we can rely on the class information instead of some side channels. As a result, I think I do prefer the current class hierarchy.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13093#issuecomment-1478374992

From lancea at openjdk.org  Tue Mar 21 18:24:45 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 21 Mar 2023 18:24:45 GMT
Subject: RFR: 8303923: ZipOutStream::putEntry should include an apiNote to
 indicate that the STORED compression method should be used when
 writing directory entries [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 19 Mar 2023 14:50:41 GMT, Eirik Bjorsnos  wrote:

>> ZipOutputStream currently writes directory entries using the DEFLATED compression method. This does not strictly comply with the APPNOTE.TXT specification and is also about 10x slower than using the STORED compression method.
>> 
>> Because of these concerns, `ZipOutputStream.putNextEntry` should be updated with an `@apiNote` recommending
>> the use of the STORED compression method for directory entries.
>> 
>> Suggested CSR in the first comment.
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove speculation that using DEFLATED for directory entries is not in strict compliance with APPNOTE.txt

Thank you for making the changes.  I think this looks better.

I go back and forth as to whether to include the sentence regarding performance but I think it is OK.  Let's see if anyone else has thoughts prior to finalizing the CSR with this change

-------------

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/12899#pullrequestreview-1351148686

From duke at openjdk.org  Tue Mar 21 18:34:40 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 21 Mar 2023 18:34:40 GMT
Subject: RFR: 8303923: ZipOutStream::putEntry should include an apiNote to
 indicate that the STORED compression method should be used when
 writing directory entries [v3]
In-Reply-To: 
References: 
 
 
Message-ID: <8Uuba93pEif8LulFqJiH_4E79Vbhn4NnRPS19ukdJgI=.3377463d-cb7c-4c39-9bb3-891b4765d9ef@github.com>

On Tue, 21 Mar 2023 18:21:31 GMT, Lance Andersen  wrote:

> Thank you for making the changes. I think this looks better.
> 
> I go back and forth as to whether to include the sentence regarding performance but I think it is OK. Let's see if anyone else has thoughts prior to finalizing the CSR with this change

I understand one can look at this differently.

For me, winning friends and influencing people has always seemed easier when I provide an answer for 'What's in it for me?'. Here, I wanted to flip the reader's state of mind from 'hmm!?' to 'hah!'.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12899#issuecomment-1478398916

From mchung at openjdk.org  Tue Mar 21 19:10:55 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 21 Mar 2023 19:10:55 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v10]
In-Reply-To: <0dJDlxKHyQs6Dtq8pvAEmg-7Q4PA__XmtvPVDSxSQhE=.e6806026-7866-492e-a976-e0640fe9e11c@github.com>
References: 
 <0dJDlxKHyQs6Dtq8pvAEmg-7Q4PA__XmtvPVDSxSQhE=.e6806026-7866-492e-a976-e0640fe9e11c@github.com>
Message-ID: 

On Mon, 20 Mar 2023 14:21:55 GMT, Jaikiran Pai  wrote:

>> Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8206890?
>> 
>> The `jlink` command allows a `--endian` option to specify the byte order in the generated image. Before this change, when such a image was being launched, the code would assume the byte order in the image to be the native order of the host where the image is being launched. That would result in failure to launch java, as noted in the linked issue.
>> 
>> The commit in this PR, changes relevant places to not assume native order and instead determine the byte order by reading the magic bytes in the image file's header content.
>> 
>> A new jtreg test has been added which reproduces the issue and verifies the fix.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Alan's suggestions - don't parse arch out of osname-arch for determining endianness and reduce the number of supported/known target platforms for cross linking

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 548:

> 546:                                                      Path retainModulesPath,
> 547:                                                      boolean ignoreSigning,
> 548:                                                      boolean bindService,

formatting nit: align the parameters with the first one.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 822:

> 820:                     PrintWriter log) throws IOException {
> 821:             if (order != null) {
> 822:                 this.targetPlatform = Platform.runtime();

The target platform should always be fetched from `java.base` (as it was implemented in `DefaultImageBuilder`) or use the current runtime if `java.base` is from the module path of the current runtime.

If `--endian ` is specified, jlink can check if the target platform's endianness matches the specified value and emit an error if mismatch unless `Platform::getNativeByteOrder` is null.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 856:

> 854:                         // unsupported target platform
> 855:                         throw new IOException(
> 856:                                 taskHelper.getMessage("err.unsupported.target.platform",

IIUC, the current jlink implementation does not fail if the target platform is unknown as long as `--endian` option is specified.   So I think `--endian` may be useful to keep (rather than taking it out).   This error key should be `err.unknown.target.endianness` and the message can suggest to use `--endian` option to specify.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Platform.java line 192:

> 190:             case "s390x"           -> Architecture.s390x;
> 191:             case "sparc"           -> Architecture.SPARC;
> 192:             case "sparcv9"         -> Architecture.SPARCv9;

This list should be trimmed to the ones supported in the mainline as in `target.properties`.

src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties line 151:

> 149: err.signing=signed modular JAR {0} is currently not supported,\
> 150: \ use --ignore-signing-information to suppress error
> 151: err.cannot.determine.target.platform=cannot determine target platform for image generation

Suggestion:

err.cannot.determine.target.platform=cannot determine target platform from {0}


`{0}` can be the path to `java.base.jmod`  (i.e. `ModuleReference::location`)

src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties line 152:

> 150: \ use --ignore-signing-information to suppress error
> 151: err.cannot.determine.target.platform=cannot determine target platform for image generation
> 152: err.unsupported.target.platform=image generation for target platform {0} is not supported

Suggestion:

err.unsupported.target.endianness=Unknown native byte order for target platform {0}`


`{0}` is `targetPlatformVal`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/11943#discussion_r1143813371
PR Review Comment: https://git.openjdk.org/jdk/pull/11943#discussion_r1143823833
PR Review Comment: https://git.openjdk.org/jdk/pull/11943#discussion_r1143872844
PR Review Comment: https://git.openjdk.org/jdk/pull/11943#discussion_r1143847888
PR Review Comment: https://git.openjdk.org/jdk/pull/11943#discussion_r1143875777
PR Review Comment: https://git.openjdk.org/jdk/pull/11943#discussion_r1143877925

From mchung at openjdk.org  Tue Mar 21 19:10:56 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 21 Mar 2023 19:10:56 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v10]
In-Reply-To: 
References: 
 <0dJDlxKHyQs6Dtq8pvAEmg-7Q4PA__XmtvPVDSxSQhE=.e6806026-7866-492e-a976-e0640fe9e11c@github.com>
 
Message-ID: <_nMLxyEyUfuWj7Xf_DV4ArtRMB74hSTQXXuKbLkK7F8=.abfc97fc-41d4-45b4-9bab-3b3d98354d59@github.com>

On Tue, 21 Mar 2023 18:38:06 GMT, Mandy Chung  wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Alan's suggestions - don't parse arch out of osname-arch for determining endianness and reduce the number of supported/known target platforms for cross linking
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Platform.java line 192:
> 
>> 190:             case "s390x"           -> Architecture.s390x;
>> 191:             case "sparc"           -> Architecture.SPARC;
>> 192:             case "sparcv9"         -> Architecture.SPARCv9;
> 
> This list should be trimmed to the ones supported in the mainline as in `target.properties`.

Also `is64Bit` will need update for other 64-bit platforms.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/11943#discussion_r1143865820

From liach at openjdk.org  Tue Mar 21 20:21:23 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 21 Mar 2023 20:21:23 GMT
Subject: RFR: 8303930: Fix ConstantUtils.skipOverFieldSignature void case
 return value [v3]
In-Reply-To: 
References: 
Message-ID: 

> This typo doesn't allow creation of malformed ClassDesc or MethodTypeDesc, but it produces an erroneous exception on certain inputs. Running `java.lang.constant.MethodTypeDesc.ofDescriptor("(IIIII[[[V)I")` in Jshell 19.0.2 throws StringIndexOutOfBoundsException, and throws IllegalArgumentException in the Jshell for this patch.

Chen Liang 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' of https://git.openjdk.java.net/jdk into 8303930
 - Add test for skipOverFieldSignature bug
 - Merge branch 'master' of https://git.openjdk.java.net/jdk into 8303930
 - Copyright year
 - 8303930: Fix ConstantUtils.skipOverFieldSignature void case return value

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12964/files
  - new: https://git.openjdk.org/jdk/pull/12964/files/d7b38bcf..f53269ca

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12964&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12964&range=01-02

  Stats: 82754 lines in 1011 files changed: 50645 ins; 22368 del; 9741 mod
  Patch: https://git.openjdk.org/jdk/pull/12964.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12964/head:pull/12964

PR: https://git.openjdk.org/jdk/pull/12964

From stsypanov at openjdk.org  Tue Mar 21 20:38:40 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Tue, 21 Mar 2023 20:38:40 GMT
Subject: RFR: 8300979: Lazily initialize (byte,
 char)arr in java.io.DataInputStream
In-Reply-To: 
References: 
Message-ID: <3_lOBNzij1Go_ub0Rv1BzwlKbYixthhzIahk2f0s5FE=.0398c4e6-ef51-4458-930f-0a3e301f61ba@github.com>

On Tue, 21 Mar 2023 15:41:13 GMT, Per Minborg  wrote:

> This PR proposed to lazily initialize the scratch arrays only if/when needed.

Nice idea. Just wonder could we do the same for `BufferedInputStream`?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13121#issuecomment-1478546070

From igraves at openjdk.org  Tue Mar 21 20:46:44 2023
From: igraves at openjdk.org (Ian Graves)
Date: Tue, 21 Mar 2023 20:46:44 GMT
Subject: RFR: 8304691: Remove jlink --post-process-path option
Message-ID: 

Removing the hidden `jlink --post-process-path` option.

-------------

Commit messages:
 - Removing Post Processing functionality

Changes: https://git.openjdk.org/jdk/pull/13126/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13126&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304691
  Stats: 193 lines in 8 files changed: 0 ins; 193 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13126.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13126/head:pull/13126

PR: https://git.openjdk.org/jdk/pull/13126

From mchung at openjdk.org  Tue Mar 21 21:24:44 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 21 Mar 2023 21:24:44 GMT
Subject: RFR: 8304691: Remove jlink --post-process-path option
In-Reply-To: 
References: 
Message-ID: 

On Tue, 21 Mar 2023 20:39:38 GMT, Ian Graves  wrote:

> Removing the hidden `jlink --post-process-path` option.

I expect `JlinkTask::postProcessImage` and `Jlink::postProcess` to be removed.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13126#pullrequestreview-1351401366

From mchung at openjdk.org  Tue Mar 21 21:32:42 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 21 Mar 2023 21:32:42 GMT
Subject: RFR: 8304691: Remove jlink --post-process-path option
In-Reply-To: 
References: 
Message-ID: <-eAVB8eOgJL495gEtag4Ei4eBY4td8pDeFLjI45FZLM=.f41170e7-4f74-4253-b3c8-470038d5c537@github.com>

On Tue, 21 Mar 2023 20:39:38 GMT, Ian Graves  wrote:

> Removing the hidden `jlink --post-process-path` option.

The localized resource bundles for other languages are updated together in bulk toward the end of the release.   `plugins_xx.properties` can be kept unchanged and let them updated by the L10N team in bulk.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13126#issuecomment-1478607924

From liach at openjdk.org  Tue Mar 21 21:39:48 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 21 Mar 2023 21:39:48 GMT
Subject: RFR: 8294977: Convert test/jdk/java tests from ASM library to
 Classfile API [v7]
In-Reply-To: 
References: 
Message-ID: <3PN6riy9fxQHRz1646Xi5fo-V7pTeF_r4Ojgt3yMRtg=.eb0d3145-3d0c-4c3e-b158-d836f7460110@github.com>

> Summaries:
> 1. A few recommendations about updating the constant API is made at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000233.html and I may update this patch shall the API changes be integrated before
> 2. One ASM library-specific test, `LambdaAsm` is removed. Others have their code generation infrastructure upgraded from ASM to Classfile API.
> 3. Most tests are included in tier1, but some are not:
> In `:jdk_io`: (tier2, part 2)
> 
> test/jdk/java/io/Serializable/records/SerialPersistentFieldsTest.java
> test/jdk/java/io/Serializable/records/ProhibitedMethods.java
> test/jdk/java/io/Serializable/records/BadCanonicalCtrTest.java
> 
> In `:jdk_instrument`: (tier 3)
> 
> test/jdk/java/lang/instrument/RetransformAgent.java
> test/jdk/java/lang/instrument/NativeMethodPrefixAgent.java
> test/jdk/java/lang/instrument/asmlib/Instrumentor.java
> 
> 
> @asotona Would you mind reviewing?

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:

 - Switch to ConstantDescs for   and void constants
 - Merge AnnotationsTest, remove ModuleTargetAttribute call
 - Merge branch 'invoke-test-classfile' of https://github.com/liachmodded/jdk into invoke-test-classfile
 - Update test/jdk/java/lang/invoke/8022701/MHIllegalAccess.java
   
   Co-authored-by: Andrey Turbanov 
 - Merge branch 'master' into invoke-test-classfile
 - Fix LambdaStackTrace after running
 - formatting
 - Fix failed LambdaStackTrace test, use more convenient APIs
 - Merge branch 'master' of https://git.openjdk.java.net/jdk into invoke-test-classfile
 - Shorten lines, move from mask() to ACC_ constants, other misc improvements
 - ... and 1 more: https://git.openjdk.org/jdk/compare/0deb6489...7dc785b3

-------------

Changes: https://git.openjdk.org/jdk/pull/13009/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13009&range=06
  Stats: 1946 lines in 31 files changed: 302 ins; 889 del; 755 mod
  Patch: https://git.openjdk.org/jdk/pull/13009.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13009/head:pull/13009

PR: https://git.openjdk.org/jdk/pull/13009

From duke at openjdk.org  Tue Mar 21 22:15:45 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Tue, 21 Mar 2023 22:15:45 GMT
Subject: RFR: 8302818: Optimize wrapper sets and immutable sets of Enums
 [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 21 Feb 2023 03:39:46 GMT, Tingjun Yuan  wrote:

>> Currently, the two subclasses of `java.util.EnumSet` optimize bulk operations when the argument is also a `EnumSet`, but there is no such optimization for wrapper sets (returned by `Collections.unmodifiableSet`, `Collections.synchronizedSet`, etc.) and immutable sets (returned by `Set.of` methods) of `Enum`s.
>> 
>> This PR introduces optimization classes for these situations.  No public APIs are changed.
>
> Tingjun Yuan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Set.copyOf: need defensive copy

Thanks again for reviewing. Correct me if I'm wrong.

@cl4es I need to add these new wrapper classes `{Unmodifiable,Synchronized}{Regular,Jumbo}EnumSet` to implement interfaces `{Regular,Jumbo}EnumSetCompatible`, just like `*RandomAccessList` which appear to implement `RandomAccess`. I don't think removing these wrapper classes and introducing accessors is a good idea, because I will have to check for the wrapper classes in bulk operation methods, which are used more frequently.

@pavelrappo `{Unmodifiable,Sychronized}Set` also have subclasses implementing `SortedSet` and `NavigableSet`, I'm not sure whether `instanceof` is safe for these subclasses.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12498#issuecomment-1478658361

From liach at openjdk.org  Tue Mar 21 22:44:46 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 21 Mar 2023 22:44:46 GMT
Subject: RFR: 8302818: Optimize wrapper sets and immutable sets of Enums
 [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 21 Feb 2023 03:39:46 GMT, Tingjun Yuan  wrote:

>> Currently, the two subclasses of `java.util.EnumSet` optimize bulk operations when the argument is also a `EnumSet`, but there is no such optimization for wrapper sets (returned by `Collections.unmodifiableSet`, `Collections.synchronizedSet`, etc.) and immutable sets (returned by `Set.of` methods) of `Enum`s.
>> 
>> This PR introduces optimization classes for these situations.  No public APIs are changed.
>
> Tingjun Yuan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Set.copyOf: need defensive copy

The `RandomAccess` `SortedSet` `NaviagableSet` implementations are public to users while `RegularEnumSetCompatible` and `JumboEnumSetCompatible` aren't. So I guess we can implement another interface for these wrappers to retrieve their backing instances, like:

interface WrapperCollection {
  Collection getBacking();
}

and thus:

interface RegularEnumSetCompatible {
  static RegularEnumSetCompatible tryConvert(Collection coll) {
    if (coll instanceof RegularEnumSetCompatible compat) return compat;
    if (coll instanceof WrapperCollection wrap) return tryConvert(wrap.getBacking());
    return null;
  }
}


Adding extra `getClass() == UnmodifiableRegularEnumSet.class` indeed will affect most users, which rarely are enum set compatibles.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12498#issuecomment-1478689026

From liach at openjdk.org  Tue Mar 21 22:57:44 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 21 Mar 2023 22:57:44 GMT
Subject: RFR: 8302818: Optimize wrapper sets and immutable sets of Enums
 [v5]
In-Reply-To: 
References: 
 
Message-ID: <970ndqcHjf9B4WDg8AKzq0ly4hCeMpDLowMZF_mfMOQ=.2db1bd6b-965a-4ade-bbf5-a851be4c1184@github.com>

On Tue, 21 Feb 2023 03:39:46 GMT, Tingjun Yuan  wrote:

>> Currently, the two subclasses of `java.util.EnumSet` optimize bulk operations when the argument is also a `EnumSet`, but there is no such optimization for wrapper sets (returned by `Collections.unmodifiableSet`, `Collections.synchronizedSet`, etc.) and immutable sets (returned by `Set.of` methods) of `Enum`s.
>> 
>> This PR introduces optimization classes for these situations.  No public APIs are changed.
>
> Tingjun Yuan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Set.copyOf: need defensive copy

Also, in JEP 441, there is pattern matching support for different enums implementing one interface in one switch, see the enum constants section there. I wonder how useful this is, and how often do we have interfaces with more than one enum implementations (e.g. StandardOptions/ExtendedOptions)

src/java.base/share/classes/java/util/ImmutableCollections.java line 1110:

> 1108:         static final JavaLangAccess JLA = SharedSecrets.getJavaLangAccess();
> 1109: 
> 1110:         @Stable

Useless

src/java.base/share/classes/java/util/ImmutableCollections.java line 1174:

> 1172:     static final class ImmutableRegularEnumSet> extends AbstractImmutableEnumSet
> 1173:             implements RegularEnumSetCompatible, Serializable {
> 1174:         @Stable

Useless

src/java.base/share/classes/java/util/ImmutableCollections.java line 1267:

> 1265:         final long[] elements;
> 1266: 
> 1267:         @Stable

Useless

-------------

PR Review: https://git.openjdk.org/jdk/pull/12498#pullrequestreview-1351490416
PR Review Comment: https://git.openjdk.org/jdk/pull/12498#discussion_r1144062917
PR Review Comment: https://git.openjdk.org/jdk/pull/12498#discussion_r1144064197
PR Review Comment: https://git.openjdk.org/jdk/pull/12498#discussion_r1144062709

From redestad at openjdk.org  Tue Mar 21 23:44:44 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 21 Mar 2023 23:44:44 GMT
Subject: RFR: 8302818: Optimize wrapper sets and immutable sets of Enums
 [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 21 Feb 2023 03:39:46 GMT, Tingjun Yuan  wrote:

>> Currently, the two subclasses of `java.util.EnumSet` optimize bulk operations when the argument is also a `EnumSet`, but there is no such optimization for wrapper sets (returned by `Collections.unmodifiableSet`, `Collections.synchronizedSet`, etc.) and immutable sets (returned by `Set.of` methods) of `Enum`s.
>> 
>> This PR introduces optimization classes for these situations.  No public APIs are changed.
>
> Tingjun Yuan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Set.copyOf: need defensive copy

If this level of complexity is indeed needed to get whatever improvement you're after then I don't see how this can be worth its weight. Microbenchmarking might help support your case here, but assessing the potential performance costs from gradually increasing the number of classes floating around at various call sites in arbitrary applications is hard. Thus it is something we need to be very careful not to do without solid evidence.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12498#issuecomment-1478731354

From duke at openjdk.org  Wed Mar 22 01:17:43 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Wed, 22 Mar 2023 01:17:43 GMT
Subject: RFR: 8302818: Optimize wrapper sets and immutable sets of Enums
 [v6]
In-Reply-To: 
References: 
Message-ID: 

> Currently, the two subclasses of `java.util.EnumSet` optimize bulk operations when the argument is also a `EnumSet`, but there is no such optimization for wrapper sets (returned by `Collections.unmodifiableSet`, `Collections.synchronizedSet`, etc.) and immutable sets (returned by `Set.of` methods) of `Enum`s.
> 
> This PR introduces optimization classes for these situations.  No public APIs are changed.

Tingjun Yuan has updated the pull request incrementally with one additional commit since the last revision:

  Delete compatible interfaces and introduce some methods
  
  I have deleted `{Regular,Jumbo}EnumSetCompatible` interfaces and introduced some package-private methods in `AbstractCollection`. This avoids rarely-used checks from static factories in `Collections` and does not reduce much performance compared against the previous implementation.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12498/files
  - new: https://git.openjdk.org/jdk/pull/12498/files/0e0b2bf1..c02ca488

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12498&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12498&range=04-05

  Stats: 392 lines in 9 files changed: 65 ins; 218 del; 109 mod
  Patch: https://git.openjdk.org/jdk/pull/12498.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12498/head:pull/12498

PR: https://git.openjdk.org/jdk/pull/12498

From duke at openjdk.org  Wed Mar 22 01:22:37 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Wed, 22 Mar 2023 01:22:37 GMT
Subject: RFR: 8302818: Optimize wrapper sets and immutable sets of Enums
 [v7]
In-Reply-To: 
References: 
Message-ID: <7PjQsQ74GnJ05eVyrXrSzVfPt7ZOfWX3sVrpCNnhkZ8=.b659ed58-ca28-48f2-9875-ee1349a63cb2@github.com>

> Currently, the two subclasses of `java.util.EnumSet` optimize bulk operations when the argument is also a `EnumSet`, but there is no such optimization for wrapper sets (returned by `Collections.unmodifiableSet`, `Collections.synchronizedSet`, etc.) and immutable sets (returned by `Set.of` methods) of `Enum`s.
> 
> This PR introduces optimization classes for these situations.  No public APIs are changed.

Tingjun Yuan has updated the pull request incrementally with one additional commit since the last revision:

  Fix a whitespace error

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12498/files
  - new: https://git.openjdk.org/jdk/pull/12498/files/c02ca488..4a7299b3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12498&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12498&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12498.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12498/head:pull/12498

PR: https://git.openjdk.org/jdk/pull/12498

From duke at openjdk.org  Wed Mar 22 01:22:39 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Wed, 22 Mar 2023 01:22:39 GMT
Subject: RFR: 8302818: Optimize wrapper sets and immutable sets of Enums
 [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 21 Feb 2023 03:39:46 GMT, Tingjun Yuan  wrote:

>> Currently, the two subclasses of `java.util.EnumSet` optimize bulk operations when the argument is also a `EnumSet`, but there is no such optimization for wrapper sets (returned by `Collections.unmodifiableSet`, `Collections.synchronizedSet`, etc.) and immutable sets (returned by `Set.of` methods) of `Enum`s.
>> 
>> This PR introduces optimization classes for these situations.  No public APIs are changed.
>
> Tingjun Yuan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Set.copyOf: need defensive copy

I have deleted `{Regular,Jumbo}EnumSetCompatible` interfaces and introduced some package-private methods in `AbstractCollection`. This avoids rarely-used checks from static factories in `Collections` and does not reduce much performance compared against the previous implementation.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12498#issuecomment-1478790594

From duke at openjdk.org  Wed Mar 22 04:00:08 2023
From: duke at openjdk.org (ExE Boss)
Date: Wed, 22 Mar 2023 04:00:08 GMT
Subject: RFR: 8294972: Convert jdk.jlink internal plugins to use the
 Classfile API [v12]
In-Reply-To: <0XMnqSxriFou4zaFeHS3ECf43vk6skDCm9xnW6zrhoI=.572a6897-d370-4a5d-b8ff-72a0e479efbe@github.com>
References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com>
 <0XMnqSxriFou4zaFeHS3ECf43vk6skDCm9xnW6zrhoI=.572a6897-d370-4a5d-b8ff-72a0e479efbe@github.com>
Message-ID: 

On Fri, 17 Mar 2023 17:01:43 GMT, Adam Sotona  wrote:

>> jdk.jlink internal plugins are heavily using ASM
>> 
>> This patch converts ASM calls to Classfile API.
>> 
>> Please review.
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 220 commits:
> 
>  - Merge branch 'master' into JDK-8294972-jlink-plugins
>  - SystemModulesPlugin::genClassBytes rename
>  - SystemModulesPlugin::getClassBytes rename
>  - Revert "implementation of custom ResourceHelper in IncludeLocalesPlugin"
>  - remaining cleanup in SystemModulesPlugin
>  - implementation of custom ResourceHelper in IncludeLocalesPlugin
>  - fixed SystemModulesPlugin
>  - fixed StripJavaDebugAttribute to drop line numbers from code
>  - long lines wrapped
>  - StripJavaDebugAttributesPlugin transformation fixed
>  - ... and 210 more: https://git.openjdk.org/jdk/compare/4486f1b7...4e5b9651

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 112:

> 110:     private static final String DEFAULT_SYSTEM_MODULES_CLASSNAME =
> 111:             SYSTEM_MODULES_CLASS_PREFIX + "default";
> 112:     private static final ClassDesc CD_SYSTEM_MODULES =

Suggestion:

    private static final ClassDesc CD_ALL_SYSTEM_MODULES =
            ClassDesc.ofInternalName(ALL_SYSTEM_MODULES_CLASSNAME);
    private static final ClassDesc CD_SYSTEM_MODULES =

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 272:

> 270: 
> 271:         // generate SystemModulesMap
> 272:         rn = genSystemModulesMapClass(ClassDesc.ofInternalName(ALL_SYSTEM_MODULES_CLASSNAME),

`ClassDesc.ofInternalName(ALL_SYSTEM_MODULES_CLASSNAME)` should?probably be?made into?a?constant.

Suggestion:

        rn = genSystemModulesMapClass(CD_ALL_SYSTEM_MODULES,

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12944#discussion_r1141018698
PR Review Comment: https://git.openjdk.org/jdk/pull/12944#discussion_r1141018455

From duke at openjdk.org  Wed Mar 22 04:00:03 2023
From: duke at openjdk.org (ExE Boss)
Date: Wed, 22 Mar 2023 04:00:03 GMT
Subject: RFR: 8294972: Convert jdk.jlink internal plugins to use the
 Classfile API [v12]
In-Reply-To: 
References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com>
 <0XMnqSxriFou4zaFeHS3ECf43vk6skDCm9xnW6zrhoI=.572a6897-d370-4a5d-b8ff-72a0e479efbe@github.com>
 
Message-ID: 

On Fri, 17 Mar 2023 17:30:41 GMT, Mandy Chung  wrote:

>> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 220 commits:
>> 
>>  - Merge branch 'master' into JDK-8294972-jlink-plugins
>>  - SystemModulesPlugin::genClassBytes rename
>>  - SystemModulesPlugin::getClassBytes rename
>>  - Revert "implementation of custom ResourceHelper in IncludeLocalesPlugin"
>>  - remaining cleanup in SystemModulesPlugin
>>  - implementation of custom ResourceHelper in IncludeLocalesPlugin
>>  - fixed SystemModulesPlugin
>>  - fixed StripJavaDebugAttribute to drop line numbers from code
>>  - long lines wrapped
>>  - StripJavaDebugAttributesPlugin transformation fixed
>>  - ... and 210 more: https://git.openjdk.org/jdk/compare/4486f1b7...4e5b9651
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/IncludeLocalesPlugin.java line 309:
> 
>> 307:                      TAG_INVOKEDYNAMIC -> offset += 5;
>> 308:                 case TAG_LONG,
>> 309:                      TAG_DOUBLE -> {offset += 9; cpSlot++;} //additional slot for double and long entries
> 
> should this add the default case and throw to prepare for future change?

That?s definitely better?than breaking?silently.
Suggestion:

                     TAG_DOUBLE -> {offset += 9; cpSlot++;} //additional slot for double and long entries
                default -> throw new IllegalArgumentException("Unknown constant pool entry: 0x" + Integer.toHexString(Byte.toUnsignedInt(bytes[offset])).toUpperCase(Locale.ROOT));

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12944#discussion_r1141017881

From liach at openjdk.org  Wed Mar 22 05:58:41 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 22 Mar 2023 05:58:41 GMT
Subject: RFR: 8304031: Classfile API cannot encode Primitive Class as Condy
In-Reply-To: <6SEB6ZAh2b0ayMCo5EfvOW-adtsAysbf1Zk6qBbh2SI=.96417080-f2a8-424d-9a26-0ed68f6b33ac@github.com>
References: <6SEB6ZAh2b0ayMCo5EfvOW-adtsAysbf1Zk6qBbh2SI=.96417080-f2a8-424d-9a26-0ed68f6b33ac@github.com>
Message-ID: <5euGsoVyC7bvcxbGjjXUXpHPJBP9grnJnUd3unRPBcw=.206d13f9-a4c8-45b6-822b-d36dbab87d57@github.com>

On Mon, 13 Mar 2023 08:13:44 GMT, Chen Liang  wrote:

> Without this patch, the Classfile API tries to encode PrimitiveClassDesc as CONSTANT_Class_info and error in `toInternalName`.

Seems this bug exists in `ConstantPoolBuilder::constantValueEntry` as well.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12996#issuecomment-1478962553

From asotona at openjdk.org  Wed Mar 22 06:17:04 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 22 Mar 2023 06:17:04 GMT
Subject: Integrated: 8304502: Classfile API class hierarchy makes assumptions
 when class is not resolved
In-Reply-To: 
References: 
Message-ID: 

On Mon, 20 Mar 2023 11:15:52 GMT, Adam Sotona  wrote:

> Classfile API class hierarchy makes assumptions when class is not resolved and that may lead to silent generation of invalid stack maps. Only debug-level log information of case is actually provided.
> 
> Proposed patch throws IllegalArgumentException when the class is not resolved instead.
> 
> Thanks for review.
> 
> Adam

This pull request has now been integrated.

Changeset: 0156909a
Author:    Adam Sotona 
URL:       https://git.openjdk.org/jdk/commit/0156909ab38072869e2eb9f5049042b9199d14a0
Stats:     21 lines in 4 files changed: 8 ins; 8 del; 5 mod

8304502: Classfile API class hierarchy makes assumptions when class is not resolved

Reviewed-by: jpai

-------------

PR: https://git.openjdk.org/jdk/pull/13099

From asotona at openjdk.org  Wed Mar 22 06:17:15 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 22 Mar 2023 06:17:15 GMT
Subject: RFR: 8294972: Convert jdk.jlink internal plugins to use the
 Classfile API [v17]
In-Reply-To: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com>
References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com>
Message-ID: 

> jdk.jlink internal plugins are heavily using ASM
> 
> This patch converts ASM calls to Classfile API.
> 
> Please review.
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  Apply suggestions from code review
  
  Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12944/files
  - new: https://git.openjdk.org/jdk/pull/12944/files/3c12e88c..c1d5a77a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12944&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12944&range=15-16

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12944.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12944/head:pull/12944

PR: https://git.openjdk.org/jdk/pull/12944

From jpai at openjdk.org  Wed Mar 22 06:24:43 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 22 Mar 2023 06:24:43 GMT
Subject: RFR: JDK-8303742: CompletableFuture.orTimeout leaks if the future
 completes exceptionally
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Tue, 21 Mar 2023 15:08:33 GMT, Viktor Klang  wrote:

>> If there isn't any value running this test with a debug build then you could have it skip (`@requires vm.debug == false`) to save resources.
>> (fixed typo in original message)
>
> @AlanBateman Wouldn't that be `@requires vm.debug == false` ?

Hello Viktor,

> @jaikiran Having a long timeout doesn't seem like a problem given that it just needs enough time to run through the iterations (i.e. that's the max duration of the test before giving up).

Having a extremely long timeout of T1 secods for a test which one can (reasonably) expect to finish in (T1 - X) seconds can mean that when/if it genuinely times out, then it holds on to the limited shared resources (like the host machine) for those X seconds longer instead of potentially letting other tests run during that period. So I think it's always better to have a reasonable timeout instead of an extremely large one - a value past which you know that if the test is still running then it's surely be a sign that it should no longer continue to run.
Typically the timeout for such tests is decided by running the test against the hosts/environment where it failed and gathering data to see how long it usually takes to finish successfully on those and then adding some extra seconds to it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13116#discussion_r1144281676

From asotona at openjdk.org  Wed Mar 22 06:27:53 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 22 Mar 2023 06:27:53 GMT
Subject: RFR: 8294972: Convert jdk.jlink internal plugins to use the
 Classfile API [v14]
In-Reply-To: 
References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com>
 <0efK-pRtx-xkeOMKMEZBRcwFOoNFphU3Nubw9shBVIc=.42e2cb69-7ad9-4f23-9d23-2a95f6738753@github.com>
 
 <9ZeKCgzF1skBwSKW1SXFTwyR44JYO22QJbboqdq0lOY=.b56a76ac-2c58-489b-afc9-9a1fca1238cf@github.com>
 
 
Message-ID: 

On Tue, 21 Mar 2023 11:54:38 GMT, Adam Sotona  wrote:

>> Yes, I think so. If `java -XX:+UnlockDiagnosticVMOptions -XX:+BytecodeVerificationLocal -version` doesn't fail and you've run all the tests then it should be okay to drop it.
>
> I can confirm `java -XX:+UnlockDiagnosticVMOptions -XX:+BytecodeVerificationLocal -version` successful execution and passing all  jdk/tools/jlink tests. Now waiting for all tier1 tests results.

all tier1, 2, and 3 tests passed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12944#discussion_r1144284079

From asotona at openjdk.org  Wed Mar 22 06:43:24 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 22 Mar 2023 06:43:24 GMT
Subject: RFR: 8294972: Convert jdk.jlink internal plugins to use the
 Classfile API [v18]
In-Reply-To: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com>
References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com>
Message-ID: <8L5dnigEfTyVAKT5OmmgoSP1TVjC6okAOZpn1lwMoTc=.560f160d-2da5-44ac-8c87-a3180b96a9a2@github.com>

> jdk.jlink internal plugins are heavily using ASM
> 
> This patch converts ASM calls to Classfile API.
> 
> Please review.
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  improved exception message as suggested

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12944/files
  - new: https://git.openjdk.org/jdk/pull/12944/files/c1d5a77a..2af22a27

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12944&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12944&range=16-17

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12944.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12944/head:pull/12944

PR: https://git.openjdk.org/jdk/pull/12944

From asotona at openjdk.org  Wed Mar 22 07:04:58 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 22 Mar 2023 07:04:58 GMT
Subject: RFR: 8294972: Convert jdk.jlink internal plugins to use the
 Classfile API [v12]
In-Reply-To: 
References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com>
 <0XMnqSxriFou4zaFeHS3ECf43vk6skDCm9xnW6zrhoI=.572a6897-d370-4a5d-b8ff-72a0e479efbe@github.com>
 
 
Message-ID: 

On Sat, 18 Mar 2023 13:15:01 GMT, ExE Boss  wrote:

>> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/IncludeLocalesPlugin.java line 309:
>> 
>>> 307:                      TAG_INVOKEDYNAMIC -> offset += 5;
>>> 308:                 case TAG_LONG,
>>> 309:                      TAG_DOUBLE -> {offset += 9; cpSlot++;} //additional slot for double and long entries
>> 
>> should this add the default case and throw to prepare for future change?
>
> That?s definitely better?than breaking?silently.
> Suggestion:
> 
>                      TAG_DOUBLE -> {offset += 9; cpSlot++;} //additional slot for double and long entries
>                 default -> throw new IllegalArgumentException("Unknown constant pool entry: 0x" + Integer.toHexString(Byte.toUnsignedInt(bytes[offset])).toUpperCase(Locale.ROOT));

@ExE-Boss I've applied your proposed exception message construction, thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12944#discussion_r1144312955

From xgong at openjdk.org  Wed Mar 22 08:08:46 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 22 Mar 2023 08:08:46 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v3]
In-Reply-To: <4Op0Z8whnyDXDC6zGyMbx4ugcZp5TEoAqW_myB5flxM=.1c7b59ba-efb2-4f68-90d7-2d6e33e39572@github.com>
References: 
 <4Op0Z8whnyDXDC6zGyMbx4ugcZp5TEoAqW_myB5flxM=.1c7b59ba-efb2-4f68-90d7-2d6e33e39572@github.com>
Message-ID: 

On Tue, 21 Mar 2023 16:16:31 GMT, Quan Anh Mai  wrote:

>> Hi,
>> 
>> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, VectorShuffle is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
>> 
>> 1. Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
>> 2. Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
>> 3. Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
>> 4. Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
>> 
>> Upon these changes, a `rearrange` can emit more efficient code:
>> 
>>     var species = IntVector.SPECIES_128;
>>     var v1 = IntVector.fromArray(species, SRC1, 0);
>>     var v2 = IntVector.fromArray(species, SRC2, 0);
>>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
>> 
>>     Before:
>>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>>     vmovdqu 0x10(%r10),%xmm0
>>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byte_mask
>>                                                             ;   {external_word}
>>     vpackusdw %xmm0,%xmm0,%xmm0
>>     vpackuswb %xmm0,%xmm0,%xmm0
>>     vpmovsxbd %xmm0,%xmm3
>>     vpcmpgtd %xmm3,%xmm1,%xmm3
>>     vtestps %xmm3,%xmm3
>>     jne    0x00007fc2acb4e0d8
>>     vpmovzxbd %xmm0,%xmm0
>>     vpermd %ymm2,%ymm0,%ymm0
>>     movabs $0x751588f98,%r10            ;   {oop([I{0x0000000751588f98})}
>>     vmovdqu %xmm0,0x10(%r10)
>> 
>>     After:
>>     movabs $0x751589c78,%r10            ;   {oop([I{0x0000000751589c78})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158ac88,%r10            ;   {oop([I{0x000000075158ac88})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     vpxor  %xmm0,%xmm0,%xmm0
>>     vpcmpgtd %xmm2,%xmm0,%xmm3
>>     vtestps %xmm3,%xmm3
>>     jne    0x00007fa818b27cb1
>>     vpermd %ymm1,%ymm2,%ymm0
>>     movabs $0x751588c68,%r10            ;   {oop([I{0x0000000751588c68})}
>>     vmovdqu %xmm0,0x10(%r10)
>>     
>> Please take a look and leave reviews. Thanks a lot.
>
> Quan Anh Mai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - missing casts
>  - clean up

src/hotspot/cpu/aarch64/aarch64_vector.ad line 6082:

> 6080: //   to implement rearrange.
> 6081: 
> 6082: // Maybe move the shuffle preparation to VectorLoadShuffle

Agree that moving the shuffle computation code to `VectorLoadShuffle`. Thanks!

src/hotspot/share/opto/vectorIntrinsics.cpp line 2059:

> 2057:   if (need_load_shuffle) {
> 2058:     shuffle = gvn().transform(new VectorLoadShuffleNode(shuffle, vt));
> 2059:   }

How about generating `VectorLoadShuffleNode` for all platforms that support Vector API, and remove the helper method `vector_needs_load_shuffle()` ? For those platforms that do not need this shuffle preparation, we can emit nothing  in codegen.

src/hotspot/share/opto/vectorIntrinsics.cpp line 2426:

> 2424:   if (is_vector_shuffle(vbox_klass_from)) {
> 2425:     return false; // vector shuffles aren't supported
> 2426:   }

Is it better to change this as an "assertion" or print the log details?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1144366812
PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1144360349
PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1144363416

From xgong at openjdk.org  Wed Mar 22 08:11:43 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 22 Mar 2023 08:11:43 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v3]
In-Reply-To: <4Op0Z8whnyDXDC6zGyMbx4ugcZp5TEoAqW_myB5flxM=.1c7b59ba-efb2-4f68-90d7-2d6e33e39572@github.com>
References: 
 <4Op0Z8whnyDXDC6zGyMbx4ugcZp5TEoAqW_myB5flxM=.1c7b59ba-efb2-4f68-90d7-2d6e33e39572@github.com>
Message-ID: 

On Tue, 21 Mar 2023 16:16:31 GMT, Quan Anh Mai  wrote:

>> Hi,
>> 
>> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, VectorShuffle is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
>> 
>> 1. Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
>> 2. Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
>> 3. Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
>> 4. Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
>> 
>> Upon these changes, a `rearrange` can emit more efficient code:
>> 
>>     var species = IntVector.SPECIES_128;
>>     var v1 = IntVector.fromArray(species, SRC1, 0);
>>     var v2 = IntVector.fromArray(species, SRC2, 0);
>>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
>> 
>>     Before:
>>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>>     vmovdqu 0x10(%r10),%xmm0
>>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byte_mask
>>                                                             ;   {external_word}
>>     vpackusdw %xmm0,%xmm0,%xmm0
>>     vpackuswb %xmm0,%xmm0,%xmm0
>>     vpmovsxbd %xmm0,%xmm3
>>     vpcmpgtd %xmm3,%xmm1,%xmm3
>>     vtestps %xmm3,%xmm3
>>     jne    0x00007fc2acb4e0d8
>>     vpmovzxbd %xmm0,%xmm0
>>     vpermd %ymm2,%ymm0,%ymm0
>>     movabs $0x751588f98,%r10            ;   {oop([I{0x0000000751588f98})}
>>     vmovdqu %xmm0,0x10(%r10)
>> 
>>     After:
>>     movabs $0x751589c78,%r10            ;   {oop([I{0x0000000751589c78})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158ac88,%r10            ;   {oop([I{0x000000075158ac88})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     vpxor  %xmm0,%xmm0,%xmm0
>>     vpcmpgtd %xmm2,%xmm0,%xmm3
>>     vtestps %xmm3,%xmm3
>>     jne    0x00007fa818b27cb1
>>     vpermd %ymm1,%ymm2,%ymm0
>>     movabs $0x751588c68,%r10            ;   {oop([I{0x0000000751588c68})}
>>     vmovdqu %xmm0,0x10(%r10)
>>     
>> Please take a look and leave reviews. Thanks a lot.
>
> Quan Anh Mai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - missing casts
>  - clean up

Please also update the copyright to 2023 for some touched files like `vectorSupport.hpp` and other java files like `AbstractShuffle.java`, `AbstractVector.java`, `VectorShape.java`, and `VectorShuffle.java`. Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13093#issuecomment-1479076010

From fjiang at openjdk.org  Wed Mar 22 08:18:42 2023
From: fjiang at openjdk.org (Feilong Jiang)
Date: Wed, 22 Mar 2023 08:18:42 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v5]
In-Reply-To: 
References: 
 
 
Message-ID: <2VN0jPv3cwJuzneVkIBwHReDI-2zj0qBknbc_AeFy1k=.d306ef5f-c104-496b-b6fd-f404ffc33d39@github.com>

On Tue, 21 Mar 2023 13:35:25 GMT, Per Minborg  wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add example for Option::captureStateLayout
>
> A review of all the copyright years shall be made in this PR.

Hi @minborg, looks like some changes were missed on riscv port. I've added these changes and submitted tests on linux-riscv. `jdk_foreign` still passed with release & fatdebug build.
Could you please add these extra changes for riscv? Thanks.
 Here is the patch: [foreign_riscv_port_patch.txt](https://github.com/openjdk/jdk/files/11037700/foreign_riscv_port_patch.txt)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13079#issuecomment-1479083052

From xgong at openjdk.org  Wed Mar 22 08:33:47 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 22 Mar 2023 08:33:47 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v3]
In-Reply-To: <4Op0Z8whnyDXDC6zGyMbx4ugcZp5TEoAqW_myB5flxM=.1c7b59ba-efb2-4f68-90d7-2d6e33e39572@github.com>
References: 
 <4Op0Z8whnyDXDC6zGyMbx4ugcZp5TEoAqW_myB5flxM=.1c7b59ba-efb2-4f68-90d7-2d6e33e39572@github.com>
Message-ID: 

On Tue, 21 Mar 2023 16:16:31 GMT, Quan Anh Mai  wrote:

>> Hi,
>> 
>> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, VectorShuffle is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
>> 
>> 1. Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
>> 2. Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
>> 3. Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
>> 4. Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
>> 
>> Upon these changes, a `rearrange` can emit more efficient code:
>> 
>>     var species = IntVector.SPECIES_128;
>>     var v1 = IntVector.fromArray(species, SRC1, 0);
>>     var v2 = IntVector.fromArray(species, SRC2, 0);
>>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
>> 
>>     Before:
>>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>>     vmovdqu 0x10(%r10),%xmm0
>>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byte_mask
>>                                                             ;   {external_word}
>>     vpackusdw %xmm0,%xmm0,%xmm0
>>     vpackuswb %xmm0,%xmm0,%xmm0
>>     vpmovsxbd %xmm0,%xmm3
>>     vpcmpgtd %xmm3,%xmm1,%xmm3
>>     vtestps %xmm3,%xmm3
>>     jne    0x00007fc2acb4e0d8
>>     vpmovzxbd %xmm0,%xmm0
>>     vpermd %ymm2,%ymm0,%ymm0
>>     movabs $0x751588f98,%r10            ;   {oop([I{0x0000000751588f98})}
>>     vmovdqu %xmm0,0x10(%r10)
>> 
>>     After:
>>     movabs $0x751589c78,%r10            ;   {oop([I{0x0000000751589c78})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158ac88,%r10            ;   {oop([I{0x000000075158ac88})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     vpxor  %xmm0,%xmm0,%xmm0
>>     vpcmpgtd %xmm2,%xmm0,%xmm3
>>     vtestps %xmm3,%xmm3
>>     jne    0x00007fa818b27cb1
>>     vpermd %ymm1,%ymm2,%ymm0
>>     movabs $0x751588c68,%r10            ;   {oop([I{0x0000000751588c68})}
>>     vmovdqu %xmm0,0x10(%r10)
>>     
>> Please take a look and leave reviews. Thanks a lot.
>
> Quan Anh Mai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - missing casts
>  - clean up

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractShuffle.java line 118:

> 116:         return (VectorShuffle) v.rearrange(shuffle.cast(vspecies().asIntegral()))
> 117:                 .toShuffle()
> 118:                 .cast(vspecies());

Style issue. Suggest to change to:

return (VectorShuffle) v.rearrange(shuffle.cast(vspecies().asIntegral()))
                           .toShuffle()
                           .cast(vspecies());

I also noticed that the similar shuffle cast code is used more frequently. Could we wrap such code `toShuffle().cast(vspecies())` to a separate method?

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractShuffle.java line 130:

> 128:         } else {
> 129:             v = v.blend(v.lanewise(VectorOperators.ADD, length()),
> 130:                     v.compare(VectorOperators.LT, 0));

Style issue. Suggest to change to:

v = v.blend(v.lanewise(VectorOperators.ADD, length()),
            v.compare(VectorOperators.LT, 0));

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractVector.java line 198:

> 196:         if ((length() & (length() - 1)) != 0) {
> 197:             return wrap ? shuffleFromOp(i -> (VectorIntrinsics.wrapToRange(i * step + start, length())))
> 198:                     : shuffleFromOp(i -> i * step + start);

Code style issue. Suggest to:

return wrap ? shuffleFromOp(i -> (VectorIntrinsics.wrapToRange(i * step + start, length())))
            : shuffleFromOp(i -> i * step + start);

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractVector.java line 204:

> 202:         Vector iota = species.iota();
> 203:         iota = iota.lanewise(VectorOperators.MUL, step)
> 204:                 .lanewise(VectorOperators.ADD, start);

Style issue. Same as above.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1144384585
PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1144389023
PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1144390218
PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1144390692

From aturbanov at openjdk.org  Wed Mar 22 09:09:41 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 22 Mar 2023 09:09:41 GMT
Subject: RFR: JDK-8304028: Port fdlibm IEEEremainder to Java
In-Reply-To: 
References: 
Message-ID: 

On Tue, 21 Mar 2023 06:11:57 GMT, Joe Darcy  wrote:

> Last but not least, a port of fdlibm IEEEremainder from C to Java. I plan to write some more implementation-specific tests around decision points in the FDLIBM algorithm, but I wanted to get the bulk of the changes out for review first.
> 
> Note that since IEEEremainder was the last native method in StrictMath.java, the StrictMath.c file needed to be deleted (or modified) since StrictMath.h was no longer generated as part of the build. (StrictMath.c was one of the file deleted as part of JDK-8302801).
> 
> For testing, Mach 5 tier 1 through 3 were successful (other than an unrelated test failure that was problem listed) and the exhaustive test was locally run and passed with "16, 16" to increase the testing density.

Changes requested by aturbanov (Committer).

src/java.base/share/classes/java/lang/FdLibm.java line 3450:

> 3448:                 iy -= 1;
> 3449:             }
> 3450:             if( iy >= -1022) {        // normalize output

Suggestion:

            if (iy >= -1022) {        // normalize output

-------------

PR Review: https://git.openjdk.org/jdk/pull/13113#pullrequestreview-1350245857
PR Review Comment: https://git.openjdk.org/jdk/pull/13113#discussion_r1143249561

From aturbanov at openjdk.org  Wed Mar 22 09:18:50 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 22 Mar 2023 09:18:50 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 21 Mar 2023 09:02:29 GMT, Per Minborg  wrote:

>> API changes for the FFM API (third preview)
>> 
>> Specdiff:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
>> 
>> Javadoc:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add example for Option::captureStateLayout

src/java.base/share/classes/java/lang/foreign/Arena.java line 224:

> 222:     static Arena global() {
> 223:         class Holder {
> 224:             final static Arena GLOBAL = MemorySessionImpl.GLOBAL.asArena();

Nit: use blessed modifiers order
Suggestion:

            static final Arena GLOBAL = MemorySessionImpl.GLOBAL.asArena();

src/java.base/share/classes/jdk/internal/foreign/abi/aarch64/windows/WindowsAArch64Linker.java line 58:

> 56:     @Override
> 57:     protected UpcallStubFactory arrangeUpcall(MethodType targetType, FunctionDescriptor function, LinkerOptions options) {
> 58:         return  CallArranger.WINDOWS.arrangeUpcall(targetType, function, options);

Suggestion:

        return CallArranger.WINDOWS.arrangeUpcall(targetType, function, options);

src/java.base/share/classes/jdk/internal/foreign/abi/fallback/LibFallback.java line 159:

> 157:      */
> 158:     static void getStructOffsets(MemorySegment structType, MemorySegment offsetsOut, FFIABI abi)
> 159:             throws IllegalStateException  {

Suggestion:

            throws IllegalStateException {

test/jdk/java/foreign/trivial/TestTrivial.java line 74:

> 72:         VarHandle vhX = bigLayout.varHandle(MemoryLayout.PathElement.groupElement("x"));
> 73:         VarHandle vhY = bigLayout.varHandle(MemoryLayout.PathElement.groupElement("y"));
> 74:         try (Arena arena  = Arena.ofConfined()) {

nit:
Suggestion:

        try (Arena arena = Arena.ofConfined()) {

test/jdk/java/foreign/trivial/TestTrivial.java line 89:

> 87:         StructLayout capturedStateLayout = Linker.Option.captureStateLayout();
> 88:         VarHandle errnoHandle = capturedStateLayout.varHandle(MemoryLayout.PathElement.groupElement("errno"));
> 89:         try (Arena arena  = Arena.ofConfined()) {

nit
Suggestion:

        try (Arena arena = Arena.ofConfined()) {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1144450371
PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1144453152
PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1144452221
PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1144451413
PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1144451634

From pminborg at openjdk.org  Wed Mar 22 10:00:15 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 22 Mar 2023 10:00:15 GMT
Subject: RFR: 8300979: Lazily initialize (byte,
 char)arr in java.io.DataInputStream [v2]
In-Reply-To: 
References: 
Message-ID: 

> This PR proposed to lazily initialize the scratch arrays only if/when needed.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/io/DataInputStream.java
  
  Co-authored-by: Eirik Bjorsnos 

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13121/files
  - new: https://git.openjdk.org/jdk/pull/13121/files/9d99127b..d689e36b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13121&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13121&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13121.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13121/head:pull/13121

PR: https://git.openjdk.org/jdk/pull/13121

From asotona at openjdk.org  Wed Mar 22 10:07:43 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 22 Mar 2023 10:07:43 GMT
Subject: RFR: 8304148: Remapping a class with Invokedynamic constant loses
 static bootstrap arguments
In-Reply-To: 
References: 
Message-ID: <89VXRwTFOn-N0ZTAM-PTNwrUlpfjymURzQZEjvHoTV0=.f50ff389-3425-45af-8d5d-f125cd34dfe6@github.com>

On Tue, 14 Mar 2023 14:51:34 GMT, Thiago Henrique H?pner  wrote:

> 8304148: Remapping a class with Invokedynamic constant loses static bootstrap arguments

Thanks for discovering the bug. 
Proposed fix looks good to me, however it would be good to cover it with a test.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13021#issuecomment-1479257811

From pminborg at openjdk.org  Wed Mar 22 10:12:26 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 22 Mar 2023 10:12:26 GMT
Subject: RFR: 8300979: Lazily initialize (byte,
 char)arr in java.io.DataInputStream [v3]
In-Reply-To: 
References: 
Message-ID: <5tQ84BWMKaCnFalikXWrEtW9X21bB-ElGw-k5B-KZTQ=.703816ac-c0b1-4e08-be7d-74f6942010a6@github.com>

> This PR proposed to lazily initialize the scratch arrays only if/when needed.

Per Minborg 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 'dis-lazy' of https://github.com/minborg/jdk into dis-lazy
 - Update src/java.base/share/classes/java/io/DataInputStream.java
   
   Co-authored-by: Eirik Bjorsnos 
 - Merge branch 'master' into dis-lazy
 - Remove redundant initilizers
 - Lazily initialize (byte, char)arr in java.io.DataInputStream

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13121/files
  - new: https://git.openjdk.org/jdk/pull/13121/files/d689e36b..efece452

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13121&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13121&range=01-02

  Stats: 103 lines in 16 files changed: 59 ins; 10 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/13121.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13121/head:pull/13121

PR: https://git.openjdk.org/jdk/pull/13121

From pminborg at openjdk.org  Wed Mar 22 10:12:29 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 22 Mar 2023 10:12:29 GMT
Subject: RFR: 8300979: Lazily initialize (byte,
 char)arr in java.io.DataInputStream [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 21 Mar 2023 16:17:35 GMT, Brian Burkhalter  wrote:

>> Per Minborg 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 'dis-lazy' of https://github.com/minborg/jdk into dis-lazy
>>  - Update src/java.base/share/classes/java/io/DataInputStream.java
>>    
>>    Co-authored-by: Eirik Bjorsnos 
>>  - Merge branch 'master' into dis-lazy
>>  - Remove redundant initilizers
>>  - Lazily initialize (byte, char)arr in java.io.DataInputStream
>
> src/java.base/share/classes/java/io/DataInputStream.java line 64:
> 
>> 62:      * working arrays initialized on demand by readUTF
>> 63:      */
>> 64:     private byte[] bytearr;
> 
> Could the `bytearr` and `chararr` instance variables be removed altogether?

They could but I think that would be under a separate PR. Feel free to raise an issue.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13121#discussion_r1144532801

From pminborg at openjdk.org  Wed Mar 22 10:17:43 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 22 Mar 2023 10:17:43 GMT
Subject: RFR: 8300979: Lazily initialize (byte,
 char)arr in java.io.DataInputStream
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 21 Mar 2023 17:27:42 GMT, Eirik Bjorsnos  wrote:

> Looks like `DataInputStream.readUTF` could benefit from using `JavaLangAccess.countPositives` and return early for the common case that all bytes are ASCII. Food for another PR?

Yep. Please raise an issue with the ideas around this if deemed beneficial.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13121#issuecomment-1479275639

From pminborg at openjdk.org  Wed Mar 22 10:20:45 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 22 Mar 2023 10:20:45 GMT
Subject: RFR: 8300979: Lazily initialize (byte,
 char)arr in java.io.DataInputStream
In-Reply-To: <3_lOBNzij1Go_ub0Rv1BzwlKbYixthhzIahk2f0s5FE=.0398c4e6-ef51-4458-930f-0a3e301f61ba@github.com>
References: 
 <3_lOBNzij1Go_ub0Rv1BzwlKbYixthhzIahk2f0s5FE=.0398c4e6-ef51-4458-930f-0a3e301f61ba@github.com>
Message-ID: 

On Tue, 21 Mar 2023 20:35:36 GMT, Sergey Tsypanov  wrote:

> Nice idea. Just wonder could we do the same for `BufferedInputStream`?

I think it is doable but would require some more work as nullity is used as a "closed flag". Please raise a separate issue about this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13121#issuecomment-1479279043

From asotona at openjdk.org  Wed Mar 22 11:11:43 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 22 Mar 2023 11:11:43 GMT
Subject: RFR: 8304148: Remapping a class with Invokedynamic constant loses
 static bootstrap arguments
In-Reply-To: 
References: 
Message-ID: 

On Tue, 14 Mar 2023 14:51:34 GMT, Thiago Henrique H?pner  wrote:

> 8304148: Remapping a class with Invokedynamic constant loses static bootstrap arguments

Suggested patch to test the args lost:

diff --git a/test/jdk/jdk/classfile/AdvancedTransformationsTest.java b/test/jdk/jdk/classfile/AdvancedTransformationsTest.java
index 931b0825a7f..92354fe4bdf 100644
--- a/test/jdk/jdk/classfile/AdvancedTransformationsTest.java
+++ b/test/jdk/jdk/classfile/AdvancedTransformationsTest.java
@@ -211,6 +211,7 @@ class AdvancedTransformationsTest {
                 "INVOKESTATIC, owner: AdvancedTransformationsTest$Bar, method name: fooMethod, method type: (LAdvancedTransformationsTest$Bar;)LAdvancedTransformationsTest$Bar",
                 "method type: ()LAdvancedTransformationsTest$Bar;",
                 "GETFIELD, owner: AdvancedTransformationsTest$Rec, field name: foo, field type: LAdvancedTransformationsTest$Bar;");
+        assertFalse(out.contains("bootstrap method arguments indexes: []"), "bootstrap arguments lost");
     }
 
     private static void assertContains(String actual, String... expected) {

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13021#issuecomment-1479365706

From duke at openjdk.org  Wed Mar 22 11:24:40 2023
From: duke at openjdk.org (Viktor Klang)
Date: Wed, 22 Mar 2023 11:24:40 GMT
Subject: RFR: JDK-8304557:
 java/util/concurrent/CompletableFuture/CompletableFutureOrTimeoutExceptionallyTest.java
 times out
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 21 Mar 2023 11:02:52 GMT, Jaikiran Pai  wrote:

>> Improves the stability of the memory leak test for CompletableFuture timeout cancellation by both reducing the count by 50% (which should still be above threshold to trigger given the ample margin set initially) as well as extending the default timeout of the test run.
>
> The PR seems to be using an incorrect JBS issue id/summary. This PR should be linked with the new https://bugs.openjdk.org/browse/JDK-8304557 issue.

@jaikiran Yes, good catch, have updated the title.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13116#issuecomment-1479384471

From duke at openjdk.org  Wed Mar 22 11:24:42 2023
From: duke at openjdk.org (Viktor Klang)
Date: Wed, 22 Mar 2023 11:24:42 GMT
Subject: RFR: JDK-8304557:
 java/util/concurrent/CompletableFuture/CompletableFutureOrTimeoutExceptionallyTest.java
 times out
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Wed, 22 Mar 2023 06:20:55 GMT, Jaikiran Pai  wrote:

>> @AlanBateman Wouldn't that be `@requires vm.debug == false` ?
>
> Hello Viktor,
> 
>> @jaikiran Having a long timeout doesn't seem like a problem given that it just needs enough time to run through the iterations (i.e. that's the max duration of the test before giving up).
> 
> Having a extremely long timeout of T1 secods for a test which one can (reasonably) expect to finish in (T1 - X) seconds can mean that when/if it genuinely times out, then it holds on to the limited shared resources (like the host machine) for those X seconds longer instead of potentially letting other tests run during that period. So I think it's always better to have a reasonable timeout instead of an extremely large one - a value past which you know that if the test is still running then it's surely be a sign that it should no longer continue to run.
> Typically the timeout for such tests is decided by running the test against the hosts/environment where it failed and gathering data to see how long it usually takes to finish successfully on those and then adding some extra seconds to it.

@jaikiran The downside is that it is hard to judge how long it will take for machine X to execute Y instructions. :/

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13116#discussion_r1144646434

From mcimadamore at openjdk.org  Wed Mar 22 11:57:46 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 22 Mar 2023 11:57:46 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 21 Mar 2023 09:02:29 GMT, Per Minborg  wrote:

>> API changes for the FFM API (third preview)
>> 
>> Specdiff:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
>> 
>> Javadoc:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add example for Option::captureStateLayout

src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 694:

> 692:      * @param bitSize the padding size in bits.
> 693:      * @return the new selector layout.
> 694:      * @throws IllegalArgumentException if {@code bitSize < 0} or {@code bitSize % 8 != 0}

I'm not sure if this change in the `@throws` was deliberate - e.g. the new API seems to allow creation of padding layouts of zero size (which I did not realize). This can hide issues for code generators (e.g. I stumbled upon this when working on jextract, which was silently emitting zero-length paddings in some struct layouts). Perhaps better to revert to old semantics?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1144680066

From duke at openjdk.org  Wed Mar 22 11:59:30 2023
From: duke at openjdk.org (Thiago Henrique =?UTF-8?B?SMO8cG5lcg==?=)
Date: Wed, 22 Mar 2023 11:59:30 GMT
Subject: RFR: 8304148: Remapping a class with Invokedynamic constant loses
 static bootstrap arguments [v2]
In-Reply-To: 
References: 
Message-ID: 

> 8304148: Remapping a class with Invokedynamic constant loses static bootstrap arguments

Thiago Henrique H?pner has updated the pull request incrementally with one additional commit since the last revision:

  Add test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13021/files
  - new: https://git.openjdk.org/jdk/pull/13021/files/ff10a5d8..d6a4fc5d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13021&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13021&range=00-01

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13021.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13021/head:pull/13021

PR: https://git.openjdk.org/jdk/pull/13021

From asotona at openjdk.org  Wed Mar 22 12:07:42 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 22 Mar 2023 12:07:42 GMT
Subject: RFR: 8304148: Remapping a class with Invokedynamic constant loses
 static bootstrap arguments [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 22 Mar 2023 11:59:30 GMT, Thiago Henrique H?pner  wrote:

>> 8304148: Remapping a class with Invokedynamic constant loses static bootstrap arguments
>
> Thiago Henrique H?pner has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test

Marked as reviewed by asotona (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13021#pullrequestreview-1352418011

From pminborg at openjdk.org  Wed Mar 22 12:10:46 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 22 Mar 2023 12:10:46 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v5]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 22 Mar 2023 11:55:09 GMT, Maurizio Cimadamore  wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add example for Option::captureStateLayout
>
> src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 694:
> 
>> 692:      * @param bitSize the padding size in bits.
>> 693:      * @return the new selector layout.
>> 694:      * @throws IllegalArgumentException if {@code bitSize < 0} or {@code bitSize % 8 != 0}
> 
> I'm not sure if this change in the `@throws` was deliberate - e.g. the new API seems to allow creation of padding layouts of zero size (which I did not realize). This can hide issues for code generators (e.g. I stumbled upon this when working on jextract, which was silently emitting zero-length paddings in some struct layouts). Perhaps better to revert to old semantics?

Agreed. Having zero-length padding does not make much sense.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1144707890

From asotona at openjdk.org  Wed Mar 22 12:16:10 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 22 Mar 2023 12:16:10 GMT
Subject: Integrated: 8294972: Convert jdk.jlink internal plugins to use the
 Classfile API
In-Reply-To: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com>
References: <3McJcGKifCoMVYxkKNhk1VZrcAnrKMz4zgvxU_7LrCA=.5a9bff48-c900-422b-a590-b7f7fee13e8c@github.com>
Message-ID: 

On Thu, 9 Mar 2023 11:35:32 GMT, Adam Sotona  wrote:

> jdk.jlink internal plugins are heavily using ASM
> 
> This patch converts ASM calls to Classfile API.
> 
> Please review.
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: 358c61b5
Author:    Adam Sotona 
URL:       https://git.openjdk.org/jdk/commit/358c61b58d0f1ff54caf732e361de5f7ab068d10
Stats:     1037 lines in 6 files changed: 219 ins; 278 del; 540 mod

8294972: Convert jdk.jlink internal plugins to use the Classfile API

Reviewed-by: mchung, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/12944

From pminborg at openjdk.org  Wed Mar 22 12:28:14 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 22 Mar 2023 12:28:14 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v6]
In-Reply-To: 
References: 
Message-ID: 

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

Per Minborg has updated the pull request incrementally with two additional commits since the last revision:

 - Fix formating and modifier order
 - Fix typo -> shared arena

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13079/files
  - new: https://git.openjdk.org/jdk/pull/13079/files/21ef0607..192050d6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=04-05

  Stats: 6 lines in 5 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/13079.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13079/head:pull/13079

PR: https://git.openjdk.org/jdk/pull/13079

From qamai at openjdk.org  Wed Mar 22 12:46:33 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 22 Mar 2023 12:46:33 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v4]
In-Reply-To: 
References: 
Message-ID: 

> Hi,
> 
> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, VectorShuffle is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
> 
> 1. Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
> 2. Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
> 3. Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
> 4. Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
> 
> Upon these changes, a `rearrange` can emit more efficient code:
> 
>     var species = IntVector.SPECIES_128;
>     var v1 = IntVector.fromArray(species, SRC1, 0);
>     var v2 = IntVector.fromArray(species, SRC2, 0);
>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
> 
>     Before:
>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>     vmovdqu 0x10(%r10),%xmm2
>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>     vmovdqu 0x10(%r10),%xmm1
>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>     vmovdqu 0x10(%r10),%xmm0
>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byte_mask
>                                                             ;   {external_word}
>     vpackusdw %xmm0,%xmm0,%xmm0
>     vpackuswb %xmm0,%xmm0,%xmm0
>     vpmovsxbd %xmm0,%xmm3
>     vpcmpgtd %xmm3,%xmm1,%xmm3
>     vtestps %xmm3,%xmm3
>     jne    0x00007fc2acb4e0d8
>     vpmovzxbd %xmm0,%xmm0
>     vpermd %ymm2,%ymm0,%ymm0
>     movabs $0x751588f98,%r10            ;   {oop([I{0x0000000751588f98})}
>     vmovdqu %xmm0,0x10(%r10)
> 
>     After:
>     movabs $0x751589c78,%r10            ;   {oop([I{0x0000000751589c78})}
>     vmovdqu 0x10(%r10),%xmm1
>     movabs $0x75158ac88,%r10            ;   {oop([I{0x000000075158ac88})}
>     vmovdqu 0x10(%r10),%xmm2
>     vpxor  %xmm0,%xmm0,%xmm0
>     vpcmpgtd %xmm2,%xmm0,%xmm3
>     vtestps %xmm3,%xmm3
>     jne    0x00007fa818b27cb1
>     vpermd %ymm1,%ymm2,%ymm0
>     movabs $0x751588c68,%r10            ;   {oop([I{0x0000000751588c68})}
>     vmovdqu %xmm0,0x10(%r10)
>     
> Please take a look and leave reviews. Thanks a lot.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  reviews

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13093/files
  - new: https://git.openjdk.org/jdk/pull/13093/files/4caa9d10..e0b9ee88

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13093&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13093&range=02-03

  Stats: 17 lines in 5 files changed: 0 ins; 0 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/13093.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13093/head:pull/13093

PR: https://git.openjdk.org/jdk/pull/13093

From qamai at openjdk.org  Wed Mar 22 12:46:36 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 22 Mar 2023 12:46:36 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v3]
In-Reply-To: 
References: 
 <4Op0Z8whnyDXDC6zGyMbx4ugcZp5TEoAqW_myB5flxM=.1c7b59ba-efb2-4f68-90d7-2d6e33e39572@github.com>
 
Message-ID: 

On Wed, 22 Mar 2023 08:09:03 GMT, Xiaohong Gong  wrote:

>> Quan Anh Mai has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - missing casts
>>  - clean up
>
> Please also update the copyright to 2023 for some touched files like `vectorSupport.hpp` and other java files like `AbstractShuffle.java`, `AbstractVector.java`, `VectorShape.java`, and `VectorShuffle.java`. Thanks!

@XiaohongGong Thanks, I have updated the copyright year and the code styles as you suggested

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13093#issuecomment-1479500096

From qamai at openjdk.org  Wed Mar 22 12:46:39 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 22 Mar 2023 12:46:39 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v4]
In-Reply-To: 
References: 
 <4Op0Z8whnyDXDC6zGyMbx4ugcZp5TEoAqW_myB5flxM=.1c7b59ba-efb2-4f68-90d7-2d6e33e39572@github.com>
 
Message-ID: 

On Wed, 22 Mar 2023 07:59:40 GMT, Xiaohong Gong  wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reviews
>
> src/hotspot/share/opto/vectorIntrinsics.cpp line 2059:
> 
>> 2057:   if (need_load_shuffle) {
>> 2058:     shuffle = gvn().transform(new VectorLoadShuffleNode(shuffle, vt));
>> 2059:   }
> 
> How about generating `VectorLoadShuffleNode` for all platforms that support Vector API, and remove the helper method `vector_needs_load_shuffle()` ? For those platforms that do not need this shuffle preparation, we can emit nothing  in codegen.

I think not emitting `VectorLoadShuffleNode` is more common so it is better to emit them only when needed, as it will simplify the graph and may allow better inspections of the indices in the future. Additionally, a do-nothing node does not alias with its input and therefore kills the input, which leads to an additional spill if they both need to live.

> src/hotspot/share/opto/vectorIntrinsics.cpp line 2426:
> 
>> 2424:   if (is_vector_shuffle(vbox_klass_from)) {
>> 2425:     return false; // vector shuffles aren't supported
>> 2426:   }
> 
> Is it better to change this as an "assertion" or print the log details?

The change indifferentiates a vector shuffle from a normal vector in C2, so this should be removed, as vector shuffles are converted to/from normal vector using this routine

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1144748489
PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1144744663

From prappo at openjdk.org  Wed Mar 22 13:05:40 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 22 Mar 2023 13:05:40 GMT
Subject: RFR: JDK-8304557:
 java/util/concurrent/CompletableFuture/CompletableFutureOrTimeoutExceptionallyTest.java
 times out
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: 

On Wed, 22 Mar 2023 11:21:14 GMT, Viktor Klang  wrote:

>> Hello Viktor,
>> 
>>> @jaikiran Having a long timeout doesn't seem like a problem given that it just needs enough time to run through the iterations (i.e. that's the max duration of the test before giving up).
>> 
>> Having a extremely long timeout of T1 secods for a test which one can (reasonably) expect to finish in (T1 - X) seconds can mean that when/if it genuinely times out, then it holds on to the limited shared resources (like the host machine) for those X seconds longer instead of potentially letting other tests run during that period. So I think it's always better to have a reasonable timeout instead of an extremely large one - a value past which you know that if the test is still running then it's surely be a sign that it should no longer continue to run.
>> Typically the timeout for such tests is decided by running the test against the hosts/environment where it failed and gathering data to see how long it usually takes to finish successfully on those and then adding some extra seconds to it.
>
> @jaikiran The downside is that it is hard to judge how long it will take for machine X to execute Y instructions. :/

1. Is there a way to mark this test as skipped if the timeout elapses? I suggest we don't mark it as skipped based on the build or any other configuration, but actaully run it and see if it fails or succeeds. The rationale is this: if the test is still running when the time is out, it means that the test is inconclusive.
2. Can we reduce memory configuration to conserve system resources? Say, set `-Xmx` to 96 or even 64 megabytes. Or is so little / unusual that we'll risk getting other issues on modern JVMs?
3. I don't see why we need to reduce the number of iterations. What we should do instead is compute it, otherwise that number, whatever it is, looks magic. There needs to be some rationale behing that number, even if that rationale is not accurate. Say, we can reasonably assume that overhead for one `CompletableFuture` is at least one byte. So, to fill up `N` megabyte(s) of heap we would need `N * 1_048_576` iterations.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13116#discussion_r1144777727

From pminborg at openjdk.org  Wed Mar 22 13:40:35 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 22 Mar 2023 13:40:35 GMT
Subject: RFR: 8300977: Retire java.io.ExpiringCache
Message-ID: 

This PR proposed to retire the class 'java.io.ExpiringCache'. The use of the class has been off by default since Java 16 but could be explicitly turned on by means of two System properties.

-------------

Commit messages:
 - Remove warnings
 - Update copyright years
 - Retire ExpiringCache

Changes: https://git.openjdk.org/jdk/pull/12167/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12167&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300977
  Stats: 446 lines in 6 files changed: 7 ins; 413 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/12167.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12167/head:pull/12167

PR: https://git.openjdk.org/jdk/pull/12167

From pminborg at openjdk.org  Wed Mar 22 13:40:36 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 22 Mar 2023 13:40:36 GMT
Subject: RFR: 8300977: Retire java.io.ExpiringCache
In-Reply-To: 
References: 
Message-ID: 

On Tue, 24 Jan 2023 14:02:26 GMT, Per Minborg  wrote:

> This PR proposed to retire the class 'java.io.ExpiringCache'. The use of the class has been off by default since Java 16 but could be explicitly turned on by means of two System properties.

src/java.base/share/classes/java/io/FileSystem.java line 253:

> 251: 
> 252:     static {
> 253:         infoPropIsIgnored("sun.io.useCanonCaches");

I am not sure we should warn. If we should, there might be a better way to do it?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12167#discussion_r1085371871

From pminborg at openjdk.org  Wed Mar 22 13:58:35 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 22 Mar 2023 13:58:35 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v7]
In-Reply-To: 
References: 
Message-ID: 

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Disalow padding layouts of size zero

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13079/files
  - new: https://git.openjdk.org/jdk/pull/13079/files/192050d6..45febe9d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=05-06

  Stats: 10 lines in 2 files changed: 3 ins; 5 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13079.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13079/head:pull/13079

PR: https://git.openjdk.org/jdk/pull/13079

From pminborg at openjdk.org  Wed Mar 22 14:09:07 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 22 Mar 2023 14:09:07 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v8]
In-Reply-To: 
References: 
Message-ID: <4JIhKmX2VnDfArfFl-1YJfoUzGGBVA5Uvd3mdpatW-s=.5d86f29e-5475-4a4a-91df-d6418356e204@github.com>

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Improve javadocs for Linker::captureStateLayout

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13079/files
  - new: https://git.openjdk.org/jdk/pull/13079/files/45febe9d..6df28a78

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=06-07

  Stats: 11 lines in 1 file changed: 0 ins; 1 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/13079.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13079/head:pull/13079

PR: https://git.openjdk.org/jdk/pull/13079

From pminborg at openjdk.org  Wed Mar 22 14:09:56 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 22 Mar 2023 14:09:56 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v8]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 21 Mar 2023 12:12:15 GMT, Maurizio Cimadamore  wrote:

>> src/java.base/share/classes/java/lang/foreign/Linker.java line 621:
>> 
>>> 619:          *          to a downcall handle linked with {@link #captureCallState(String...)}}
>>> 620:          *
>>> 621:          * @see #captureCallState(String...)
>> 
>> How does a caller know what the structure may contain? Should we document the platform specific structures?
>
> Back to @PaulSandoz  question - "how does the caller know what the structure contains?". The caller typically doesn't care too much about what the returned struct is. But it might care about which "values" can be captured. That said, the set of such interesting values, is not too surprising. As demonstrated in the example in the `Linker.capturedCallState` method, once the client knows the name (and "errno" is likely to be 90% case), everything else follows from there - as the layout can be used to obtain var handles for the required values.
> 
> But, perhaps, now that I write this, I realize that what @PaulSandoz might _really_ be asking is: how do I know that e.g. the returned struct will not contain e.g. nested structs, sequences, or other non-sense. So we might specify (in a normative way) that the returned layout is a struct layout, whose member layouts are one or more value layouts (possibly with some added padding layouts). The names of the value layouts reflect the names of the values that can be captured.
> 
> And _then_ we show an example of the layout we return for Windows/x64 (as that's more interesting).

I've updated the specs as per how I interpret the comments above. Let me know your thoughts on this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1144872865

From jwaters at openjdk.org  Wed Mar 22 14:19:48 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 22 Mar 2023 14:19:48 GMT
Subject: RFR: 8304717: Declaration aliasing between boolean and jboolean is
 wrong
Message-ID: <9Xij1FEbLnMYTPIZOOhGyaKnlplxP6Wp3ODS2bKP7u0=.146017ce-32ee-40f3-8496-49c014f7decb@github.com>

A couple of spots wrongly refer to boolean and jboolean as the same thing. While this does still compile thanks to a happy accident and implicit conversions, they are not the same at all, and should be fixed before a future compiler error happens if their declarations are touched

-------------

Commit messages:
 - awt_PrintJob.cpp
 - jboolean

Changes: https://git.openjdk.org/jdk/pull/13139/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13139&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304717
  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13139.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13139/head:pull/13139

PR: https://git.openjdk.org/jdk/pull/13139

From mcimadamore at openjdk.org  Wed Mar 22 14:38:30 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 22 Mar 2023 14:38:30 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v8]
In-Reply-To: <4JIhKmX2VnDfArfFl-1YJfoUzGGBVA5Uvd3mdpatW-s=.5d86f29e-5475-4a4a-91df-d6418356e204@github.com>
References: 
 <4JIhKmX2VnDfArfFl-1YJfoUzGGBVA5Uvd3mdpatW-s=.5d86f29e-5475-4a4a-91df-d6418356e204@github.com>
Message-ID: 

On Wed, 22 Mar 2023 14:09:07 GMT, Per Minborg  wrote:

>> API changes for the FFM API (third preview)
>> 
>> Specdiff:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
>> 
>> Javadoc:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve javadocs for Linker::captureStateLayout

src/java.base/share/classes/java/lang/foreign/Linker.java line 628:

> 626:          * and possibly {@linkplain PaddingLayout padding layouts}.
> 627:          * As an example, on Windows, the returned layout might contain three value layouts named:
> 628:          * 
      

Almost there - instead of listing the names, just put a code snippet with the struct layout! That will make it crystal clear.

src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 697:

> 695:      */
> 696:     static PaddingLayout paddingLayout(long bitSize) {
> 697:         if (bitSize <= 0) {

While this does the right thing, I wonder if we can do better, as it seems we're checking size twice - perhaps we need to customize the `requireBitSizeValid` function?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1144915578
PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1144917200

From duke at openjdk.org  Wed Mar 22 14:40:05 2023
From: duke at openjdk.org (ExE Boss)
Date: Wed, 22 Mar 2023 14:40:05 GMT
Subject: RFR: 8302818: Optimize wrapper sets and immutable sets of Enums
 [v7]
In-Reply-To: <7PjQsQ74GnJ05eVyrXrSzVfPt7ZOfWX3sVrpCNnhkZ8=.b659ed58-ca28-48f2-9875-ee1349a63cb2@github.com>
References: 
 <7PjQsQ74GnJ05eVyrXrSzVfPt7ZOfWX3sVrpCNnhkZ8=.b659ed58-ca28-48f2-9875-ee1349a63cb2@github.com>
Message-ID: 

On Wed, 22 Mar 2023 01:22:37 GMT, Tingjun Yuan  wrote:

>> Currently, the two subclasses of `java.util.EnumSet` optimize bulk operations when the argument is also a `EnumSet`, but there is no such optimization for wrapper sets (returned by `Collections.unmodifiableSet`, `Collections.synchronizedSet`, etc.) and immutable sets (returned by `Set.of` methods) of `Enum`s.
>> 
>> This PR introduces optimization classes for these situations.  No public APIs are changed.
>
> Tingjun Yuan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix a whitespace error

The?`Immutable*ESIterator.lastReturned*`?fields can?be?made into?locals of?`Immutable*ESIterator::next()`, as?the?only?reason those?fields?exist in?`RegularEnumSet.EnumSetIterator` and?`JumboEnumSet.EnumSetIterator` is?to?support `Iterator::remove()`, which?is?not a?valid?operation on?immutable enum?sets:

src/java.base/share/classes/java/util/ImmutableCollections.java line 1199:

> 1197:         private final class ImmutableRESIterator implements Iterator {
> 1198:             long unseen = elements;
> 1199:             long lastReturned = 0;

Suggestion:

src/java.base/share/classes/java/util/ImmutableCollections.java line 1212:

> 1210:                 if (unseen == 0)
> 1211:                     throw new NoSuchElementException();
> 1212:                 lastReturned = unseen & -unseen;

Suggestion:

                long lastReturned = unseen & -unseen;

src/java.base/share/classes/java/util/ImmutableCollections.java line 1299:

> 1297:             int unseenIndex = 0;
> 1298:             long lastReturned = 0;
> 1299:             int lastReturnedIndex = 0;

Suggestion:

src/java.base/share/classes/java/util/ImmutableCollections.java line 1315:

> 1313:                     throw new NoSuchElementException();
> 1314:                 lastReturned = unseen & -unseen;
> 1315:                 lastReturnedIndex = unseenIndex;

Suggestion:

                long lastReturned = unseen & -unseen;
                int lastReturnedIndex = unseenIndex;

-------------

PR Review: https://git.openjdk.org/jdk/pull/12498#pullrequestreview-1352706671
PR Review Comment: https://git.openjdk.org/jdk/pull/12498#discussion_r1144897096
PR Review Comment: https://git.openjdk.org/jdk/pull/12498#discussion_r1144897486
PR Review Comment: https://git.openjdk.org/jdk/pull/12498#discussion_r1144907088
PR Review Comment: https://git.openjdk.org/jdk/pull/12498#discussion_r1144909930

From coffeys at openjdk.org  Wed Mar 22 14:42:33 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 22 Mar 2023 14:42:33 GMT
Subject: RFR: 8304498: JShell does not switch to raw mode when there is no
 /bin/test
In-Reply-To: 
References: 
Message-ID: 

On Mon, 20 Mar 2023 12:10:04 GMT, Jan Lahoda  wrote:

> If JShell is run on a system that does not have `/bin/test` (which is, apparently, possible for some systems, which only have `/usr/bin/test`), it won't switch the terminal into the raw mode, and the input will not work properly.
> 
> The proposed fix herein is to detect whether `test` existing in `/usr/bin/test`, and if yes, use that location. Use the existing `/bin/test` otherwise.

src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/OSUtils.java line 108:

> 106:     private static boolean isTestCommandValid(String command) {
> 107:         try {
> 108:             Process p = new ProcessBuilder(command, "-z", "").inheritIO().start();

is there a reason why you chose to spin up a process here ? Would a test for an executable file be sufficient ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13100#discussion_r1144922827

From jlaskey at openjdk.org  Wed Mar 22 14:43:43 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 22 Mar 2023 14:43:43 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 21 Mar 2023 13:25:58 GMT, Maurizio Cimadamore  wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Tidy javadoc
>>  - Rename StringTemplate classes
>
> src/java.base/share/classes/java/lang/StringTemplate.java line 28:
> 
>> 26: package java.lang;
>> 27: 
>> 28: import java.lang.Object;
> 
> You might want to do another pass to check for unused imports

Changing

> src/java.base/share/classes/java/lang/StringTemplate.java line 44:
> 
>> 42:  * {@link StringTemplate} is the run-time representation of a string template or
>> 43:  * text block template in a template expression.
>> 44:  *
> 
> Extra newline?

Changing

> src/java.base/share/classes/java/lang/StringTemplate.java line 56:
> 
>> 54:  * {@link StringTemplate} is primarily used in conjunction with a template processor
>> 55:  * to produce a string or other meaningful value. Evaluation of a template expression
>> 56:  * first produces an instance of {@link StringTemplate}, representing the template
> 
> The "template of the template expression" - is this nomenclature official (e.g. backed by any text in the JLS?). I must admit I find it a tad jarring.

"representing the right hand side of the template expression"

> src/java.base/share/classes/java/lang/StringTemplate.java line 324:
> 
>> 322:      * assert Objects.equals(sc, "abcxyz");
>> 323:      * }
>> 324:      * the last character {@code "c"} from the first string is juxtaposed with the first
> 
> I was playing with this example in jshell:
> 
> jshell> var st1 = RAW."{1}"
> st1 ==> StringTemplate{ fragments = [ "", "" ], values = [1] }
> 
> jshell> var st2 = RAW."{2}"
> st2 ==> StringTemplate{ fragments = [ "", "" ], values = [2] }
> 
> jshell> StringTemplate.combine(st1, st2);
> $7 ==> StringTemplate{ fragments = [ "", "", "" ], values = [1, 2] }
> 
> 
> The result is obviously well-formed - but I'm not sure I can derive what the method does just by reading the javadoc. The javadoc says:
> 
> Fragment lists from the StringTemplates are combined end to end with the last fragment from each StringTemplate concatenated with the first fragment of the next
> 
> I think I see what you want to say - (e.g. the end fragment of string template `N` is concatenated with the starting fragment of string template `N + 1`).

okay

> src/java.base/share/classes/java/lang/StringTemplate.java line 431:
> 
>> 429:      * Java compilation unit.
      The result of interpolation is not interned.
>> 430:      */
>> 431:     static final StringProcessor STR = StringTemplate::interpolate;
> 
> `static final` is redundant here (we are in an interface)

Did not know that.

> src/java.base/share/classes/java/lang/StringTemplate.java line 454:
> 
>> 452:      * This interface describes the methods provided by a generalized string template processor. The
>> 453:      * primary method {@link Processor#process(StringTemplate)} is used to validate
>> 454:      * and compose a result using a {@link StringTemplate StringTemplate's} fragments and values lists.
> 
> nit: `{@link StringTemplate StringTemplate's}` will probably not render as you'd expect (as it will all be preformat, including the `'s`).

works for me

> src/java.base/share/classes/java/lang/runtime/ReferenceKey.java line 47:
> 
>> 45:  */
>> 46: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
>> 47: interface ReferenceKey {
> 
> This (and other) class are package-private. Do we still need @PreviewFeature for stuff like this, since it's not meant to be used publicly?

Informative incase some one wants to use elsewhere in the JDK. My plan is to move this class to java.util at some point.

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 226:
> 
>> 224:                         List.nil(), expressions);
>> 225:                 valuesArray.type = new ArrayType(syms.objectType, syms.arrayClass);
>> 226:                 return bsmCall(names.process, names.newLargeStringTemplate, syms.stringTemplateType,
> 
> nit: the indy name is irrelevant here - that said, `process` is a tad confusing, since it's also the name of a StringTemplate method.

Tracks well in javah

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 252:
> 
>> 250:                 staticArgsTypes = staticArgsTypes.append(syms.stringType);
>> 251:             }
>> 252:             return bsmCall(names.process, names.processStringTemplate, tree.type,
> 
> What happens if we have too many fragments here? (e.g. > 200). That case seems handled in the RAW case.

Criteria in isLinkageProcessor() prevents this from being called.


        boolean isLinkageProcessor() {
            return processor != null &&
                   !useValuesList &&  <=====
                   types.isSubtype(processor.type, syms.linkageType) &&
                   processor.type.isFinal() &&
                   TreeInfo.symbol(processor) instanceof VarSymbol varSymbol &&
                   varSymbol.isStatic() &&
                   varSymbol.isFinal();
        }

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 281:
> 
>> 279:             make.at(tree.pos);
>> 280: 
>> 281:             if (processor == null || isNamedProcessor(names.RAW)) {
> 
> is `processor == null` still a thing?

I deliberately left this to track free standing templates. Will be phased out in next preview/final.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1144898843
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1144899315
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1144902350
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1144907969
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1144911867
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1144916768
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1144915315
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1144920121
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1144924240
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1144918724

From jlaskey at openjdk.org  Wed Mar 22 14:43:44 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 22 Mar 2023 14:43:44 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Tue, 21 Mar 2023 13:37:02 GMT, Maurizio Cimadamore  wrote:

>> src/java.base/share/classes/java/lang/StringTemplate.java line 69:
>> 
>>> 67:  * List values = st.values();
>>> 68:  * }
>>> 69:  * The value of {@code fragments} will be equivalent to {@code List.of("", " + ", " = ", "")},
>> 
>> This is a bit hard to parse, due to the use of `the value of` (which then becomes problematic in the next para, as we are talking about `values`). Either change the name of the variable `values` in the snippet, or use some other locution, like "the list {@code fragments} is equivalent to ..." etc.
>
> The above comment also applies to the javadoc of the `fragments` and `values` methods, which use a similar way to describe their results.

* {@code fragments} will be equivalent to {@code List.of("", " + ", " = ", "")},
 * which includes the empty first and last fragments. {@code values} will be the
 * equivalent of {@code List.of(10, 20, 30)}.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1144904923

From liach at openjdk.org  Wed Mar 22 15:35:51 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 22 Mar 2023 15:35:51 GMT
Subject: RFR: 8302818: Optimize wrapper sets and immutable sets of Enums
 [v7]
In-Reply-To: 
References: 
 <7PjQsQ74GnJ05eVyrXrSzVfPt7ZOfWX3sVrpCNnhkZ8=.b659ed58-ca28-48f2-9875-ee1349a63cb2@github.com>
 
Message-ID: 

On Wed, 22 Mar 2023 14:23:45 GMT, ExE Boss  wrote:

>> Tingjun Yuan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix a whitespace error
>
> src/java.base/share/classes/java/util/ImmutableCollections.java line 1212:
> 
>> 1210:                 if (unseen == 0)
>> 1211:                     throw new NoSuchElementException();
>> 1212:                 lastReturned = unseen & -unseen;
> 
> Suggestion:
> 
>                 long lastReturned = unseen & -unseen;

Suggestion:

                long lastReturned = Long.lowestOneBit(unseen);

More descriptive. Same for below.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12498#discussion_r1145005398

From pminborg at openjdk.org  Wed Mar 22 16:18:47 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 22 Mar 2023 16:18:47 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v8]
In-Reply-To: 
References: 
 <4JIhKmX2VnDfArfFl-1YJfoUzGGBVA5Uvd3mdpatW-s=.5d86f29e-5475-4a4a-91df-d6418356e204@github.com>
 
Message-ID: 

On Wed, 22 Mar 2023 14:35:42 GMT, Maurizio Cimadamore  wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve javadocs for Linker::captureStateLayout
>
> src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 697:
> 
>> 695:      */
>> 696:     static PaddingLayout paddingLayout(long bitSize) {
>> 697:         if (bitSize <= 0) {
> 
> While this does the right thing, I wonder if we can do better, as it seems we're checking size twice - perhaps we need to customize the `requireBitSizeValid` function?

I tried that but it turned out it can be zero in other contexts. Maybe we should add back the good 'ole "allowZero" flag?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1145052056

From duke at openjdk.org  Wed Mar 22 16:20:03 2023
From: duke at openjdk.org (Viktor Klang)
Date: Wed, 22 Mar 2023 16:20:03 GMT
Subject: RFR: JDK-8304557:
 java/util/concurrent/CompletableFuture/CompletableFutureOrTimeoutExceptionallyTest.java
 times out
In-Reply-To: 
References: 
 
 
 
 
 
 
Message-ID: 

On Wed, 22 Mar 2023 13:02:46 GMT, Pavel Rappo  wrote:

>> @jaikiran The downside is that it is hard to judge how long it will take for machine X to execute Y instructions. :/
>
> 1. Is there a way to mark this test as skipped if the timeout elapses? I suggest we don't mark it as skipped based on the build or any other configuration, but actaully run it and see if it fails or succeeds. The rationale is this: if the test is still running when the time is out, it means that the test is inconclusive.
> 2. Can we reduce memory configuration to conserve system resources? Say, set `-Xmx` to 96 or even 64 megabytes. Or is so little / unusual that we'll risk getting other issues on modern JVMs?
> 3. I don't see why we need to reduce the number of iterations. What we should do instead is compute it, otherwise that number, whatever it is, looks magic. There needs to be some rationale behing that number, even if that rationale is not accurate. Say, we can reasonably assume that overhead for one `CompletableFuture` is at least one byte. So, to fill up `N` megabyte(s) of heap we would need `N * 1_048_576` iterations.

1. I don't know.
2. It's hard to come up with a one-size-fits-all-heap-size given that differences in pointersizes, object alignment, etc can skew the need.
3. I initially set the threshold (iteration number) at about 4x what I needed locally to make it fail, just to have margin in case memory-usage-per-object would vary with the different setups being tested. 


The other alternative I see would be to reach into the implementation of CompletableFuture's `Delayer`'s `ScheduledThreadPoolExecutor delayer` and make sure that it's `getQueue()` eventually goes empty.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13116#discussion_r1145069912

From smarks at openjdk.org  Wed Mar 22 16:20:04 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 22 Mar 2023 16:20:04 GMT
Subject: RFR: 8302818: Optimize wrapper sets and immutable sets of Enums
 [v7]
In-Reply-To: <7PjQsQ74GnJ05eVyrXrSzVfPt7ZOfWX3sVrpCNnhkZ8=.b659ed58-ca28-48f2-9875-ee1349a63cb2@github.com>
References: 
 <7PjQsQ74GnJ05eVyrXrSzVfPt7ZOfWX3sVrpCNnhkZ8=.b659ed58-ca28-48f2-9875-ee1349a63cb2@github.com>
Message-ID: 

On Wed, 22 Mar 2023 01:22:37 GMT, Tingjun Yuan  wrote:

>> Currently, the two subclasses of `java.util.EnumSet` optimize bulk operations when the argument is also a `EnumSet`, but there is no such optimization for wrapper sets (returned by `Collections.unmodifiableSet`, `Collections.synchronizedSet`, etc.) and immutable sets (returned by `Set.of` methods) of `Enum`s.
>> 
>> This PR introduces optimization classes for these situations.  No public APIs are changed.
>
> Tingjun Yuan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix a whitespace error

I agree with Claes here in my skepticism of the usefulness of this sort of change. It seems like it's adding lots of complexity. In addition, it also seems like there's a lot of churn in the design. I'd suggest returning this PR to draft status until it can be determined that there's a clear, net improvement.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12498#issuecomment-1479872159

From liach at openjdk.org  Wed Mar 22 16:23:19 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 22 Mar 2023 16:23:19 GMT
Subject: Integrated: 8288730: Add type parameter to Lookup::accessClass and
 Lookup::ensureInitialized
In-Reply-To: 
References: 
Message-ID: 

On Sat, 11 Mar 2023 03:28:16 GMT, Chen Liang  wrote:

> Parameterizes `Lookup::accessClass` and `Lookup::ensureInitialized`. Updated an applicable use-site within JDK to benefit from this patch.

This pull request has now been integrated.

Changeset: a2d8f634
Author:    Chen Liang 
Committer: Mandy Chung 
URL:       https://git.openjdk.org/jdk/commit/a2d8f634de69d11d7beec5e853f710719497bfe3
Stats:     7 lines in 2 files changed: 2 ins; 1 del; 4 mod

8288730: Add type parameter to Lookup::accessClass and Lookup::ensureInitialized

Reviewed-by: mchung

-------------

PR: https://git.openjdk.org/jdk/pull/12984

From igraves at openjdk.org  Wed Mar 22 16:25:51 2023
From: igraves at openjdk.org (Ian Graves)
Date: Wed, 22 Mar 2023 16:25:51 GMT
Subject: RFR: 8304691: Remove jlink --post-process-path option [v2]
In-Reply-To: 
References: 
Message-ID: 

> Removing the hidden `jlink --post-process-path` option.

Ian Graves has updated the pull request incrementally with one additional commit since the last revision:

  Updates per feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13126/files
  - new: https://git.openjdk.org/jdk/pull/13126/files/06f28f1f..df0fde69

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13126&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13126&range=00-01

  Stats: 35 lines in 5 files changed: 6 ins; 29 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13126.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13126/head:pull/13126

PR: https://git.openjdk.org/jdk/pull/13126

From duke at openjdk.org  Wed Mar 22 16:31:16 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Wed, 22 Mar 2023 16:31:16 GMT
Subject: RFR: 8302818: Optimize wrapper sets and immutable sets of Enums
 [v5]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 21 Mar 2023 23:41:44 GMT, Claes Redestad  wrote:

>> Tingjun Yuan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Set.copyOf: need defensive copy
>
> If this level of complexity is indeed needed to get whatever improvement you're after then I don't see how this can be worth its weight. Microbenchmarking might help support your case here, but assessing the potential performance costs from gradually increasing the number of classes floating around at various call sites in arbitrary applications is hard. Thus it is something we need to be very careful not to do without solid evidence.

@cl4es @stuart-marks Thanks for reviewing and commenting. I'm converting this PR to draft until I finish evaluating whether these changes are necessary or not.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12498#issuecomment-1479891838

From prappo at openjdk.org  Wed Mar 22 16:32:09 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 22 Mar 2023 16:32:09 GMT
Subject: RFR: JDK-8304557:
 java/util/concurrent/CompletableFuture/CompletableFutureOrTimeoutExceptionallyTest.java
 times out
In-Reply-To: 
References: 
 
 
 
 
 
 
 
Message-ID: <4o5glI2Dk1A98RhVEwr4gGXiDUW_8gTvNZDXgtYBRc4=.1da4f942-c488-4175-977d-4b5eb23eed34@github.com>

On Wed, 22 Mar 2023 16:06:51 GMT, Viktor Klang  wrote:

> The other alternative I see would be to reach into the implementation of CompletableFuture's `Delayer`'s `ScheduledThreadPoolExecutor delayer` and make sure that it's `getQueue()` eventually goes empty.

>From what I've seen, JDK prefers blackbox tests to whitebox tests. Even though the latter might conserve resources better and are easier to implement, they are problematic in the long run: they become an obstacle if the system under tests is modified.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13116#discussion_r1145108257

From igraves at openjdk.org  Wed Mar 22 16:34:03 2023
From: igraves at openjdk.org (Ian Graves)
Date: Wed, 22 Mar 2023 16:34:03 GMT
Subject: RFR: 8304691: Remove jlink --post-process-path option [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 22 Mar 2023 16:25:51 GMT, Ian Graves  wrote:

>> Removing the hidden `jlink --post-process-path` option.
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates per feedback

Thanks! Updates per the feedback

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13126#issuecomment-1479895622

From alanb at openjdk.org  Wed Mar 22 16:45:42 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 22 Mar 2023 16:45:42 GMT
Subject: RFR: 8300979: Lazily initialize (byte,
 char)arr in java.io.DataInputStream [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 22 Mar 2023 10:07:57 GMT, Per Minborg  wrote:

>> src/java.base/share/classes/java/io/DataInputStream.java line 64:
>> 
>>> 62:      * working arrays initialized on demand by readUTF
>>> 63:      */
>>> 64:     private byte[] bytearr;
>> 
>> Could the `bytearr` and `chararr` instance variables be removed altogether?
>
> They could but I think that would be under a separate PR. Feel free to raise an issue.

Probably needs an analysis of usages to see if the caching helps or hurts performance. @kuksenko may have opinions on this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13121#discussion_r1145126021

From duke at openjdk.org  Wed Mar 22 16:51:53 2023
From: duke at openjdk.org (Viktor Klang)
Date: Wed, 22 Mar 2023 16:51:53 GMT
Subject: RFR: JDK-8304557:
 java/util/concurrent/CompletableFuture/CompletableFutureOrTimeoutExceptionallyTest.java
 times out
In-Reply-To: <4o5glI2Dk1A98RhVEwr4gGXiDUW_8gTvNZDXgtYBRc4=.1da4f942-c488-4175-977d-4b5eb23eed34@github.com>
References: 
 
 
 
 
 
 
 
 <4o5glI2Dk1A98RhVEwr4gGXiDUW_8gTvNZDXgtYBRc4=.1da4f942-c488-4175-977d-4b5eb23eed34@github.com>
Message-ID: 

On Wed, 22 Mar 2023 16:29:21 GMT, Pavel Rappo  wrote:

>> 1. I don't know.
>> 2. It's hard to come up with a one-size-fits-all-heap-size given that differences in pointersizes, object alignment, etc can skew the need.
>> 3. I initially set the threshold (iteration number) at about 4x what I needed locally to make it fail, just to have margin in case memory-usage-per-object would vary with the different setups being tested. 
>> 
>> 
>> The other alternative I see would be to reach into the implementation of CompletableFuture's `Delayer`'s `ScheduledThreadPoolExecutor delayer` and make sure that it's `getQueue()` eventually goes empty.
>
>> The other alternative I see would be to reach into the implementation of CompletableFuture's `Delayer`'s `ScheduledThreadPoolExecutor delayer` and make sure that it's `getQueue()` eventually goes empty.
> 
> From what I've seen, JDK prefers blackbox tests to whitebox tests. Even though the latter might conserve resources better and are easier to implement, they are problematic in the long run: they become an obstacle if the system under tests is modified.

@pavelrappo I agree with that. I have the same experience. With that said, I have implemented a whitebox test which reaches in an monitors the task queue of the Delayer. @AlanBateman & @jaikiran any preference here?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13116#discussion_r1145134477

From mcimadamore at openjdk.org  Wed Mar 22 16:53:45 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 22 Mar 2023 16:53:45 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v8]
In-Reply-To: 
References: 
 <4JIhKmX2VnDfArfFl-1YJfoUzGGBVA5Uvd3mdpatW-s=.5d86f29e-5475-4a4a-91df-d6418356e204@github.com>
 
 
Message-ID: <7ShkwGh4K35ZoSJ13mwrlp-VDg0NCIDeiNGoV8lYwJE=.39fe2eaf-d253-4853-9438-bd9de7a1864b@github.com>

On Wed, 22 Mar 2023 15:57:16 GMT, Per Minborg  wrote:

>> src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 697:
>> 
>>> 695:      */
>>> 696:     static PaddingLayout paddingLayout(long bitSize) {
>>> 697:         if (bitSize <= 0) {
>> 
>> While this does the right thing, I wonder if we can do better, as it seems we're checking size twice - perhaps we need to customize the `requireBitSizeValid` function?
>
> I tried that but it turned out it can be zero in other contexts. Maybe we should add back the good 'ole "allowZero" flag?

yeah , a boolean seems good enough

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1145136161

From liach at openjdk.org  Wed Mar 22 17:10:56 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 22 Mar 2023 17:10:56 GMT
Subject: RFR: 8304031: Classfile API cannot encode Primitive Class as Condy
 [v2]
In-Reply-To: <6SEB6ZAh2b0ayMCo5EfvOW-adtsAysbf1Zk6qBbh2SI=.96417080-f2a8-424d-9a26-0ed68f6b33ac@github.com>
References: <6SEB6ZAh2b0ayMCo5EfvOW-adtsAysbf1Zk6qBbh2SI=.96417080-f2a8-424d-9a26-0ed68f6b33ac@github.com>
Message-ID: <3B4EgW8oZh2pCb9IAFrWik1U4okg17wrSATx7QqXTN0=.211d411f-4c99-4305-8f55-b65d45c52a11@github.com>

> Without this patch, the Classfile API tries to encode PrimitiveClassDesc as CONSTANT_Class_info and error in `toInternalName`.

Chen Liang 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:

 - Prevent primitive class misuse in a few other sites
 - Merge branch 'master' of https://git.openjdk.java.net/jdk into 8304031
 - 8304031: Classfile API cannot encode Primitive Class as Condy

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12996/files
  - new: https://git.openjdk.org/jdk/pull/12996/files/8f4e1642..df3ed0c0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12996&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12996&range=00-01

  Stats: 83033 lines in 1033 files changed: 50857 ins; 21488 del; 10688 mod
  Patch: https://git.openjdk.org/jdk/pull/12996.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12996/head:pull/12996

PR: https://git.openjdk.org/jdk/pull/12996

From asotona at openjdk.org  Wed Mar 22 17:12:01 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 22 Mar 2023 17:12:01 GMT
Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator
 to use the Classfile API to generate proxy classes [v9]
In-Reply-To: 
References: 
Message-ID: 

> java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes and this patch converts it to use Classfile API.
> 
> Please review.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:

 - ClassEntry caching ClassDesc to improve performance
 - MethodTypeDesc performance improvements

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10991/files
  - new: https://git.openjdk.org/jdk/pull/10991/files/2b23276a..ea974be7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10991&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10991&range=07-08

  Stats: 29 lines in 4 files changed: 19 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/10991.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10991/head:pull/10991

PR: https://git.openjdk.org/jdk/pull/10991

From asotona at openjdk.org  Wed Mar 22 17:12:05 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 22 Mar 2023 17:12:05 GMT
Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator
 to use the Classfile API to generate proxy classes [v5]
In-Reply-To: 
References: 
 
 
Message-ID: <8V_qxsvutc96An1X9sNMwgxa9iMIKMh6-1JN8QcCjSU=.e57bf594-3f71-4da6-973e-b258c1411e85@github.com>

On Thu, 9 Mar 2023 17:53:05 GMT, Mandy Chung  wrote:

>> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 195 commits:
>> 
>>  - Merge branch 'master' into JDK-8294961-proxy
>>  - Merge branch 'JDK-8294982' into JDK-8294961
>>  - removed obsolete javadoc from implementation classes
>>  - minor fix in CodeBuilder and added test cases to LDCTest
>>  - EntryMap::nextPowerOfTwo delegates to Long:numberOfLeadingZeros
>>  - fixed CodeBuilder:constantInstruction for -0.0d and -0.0f values and added test
>>  - Merge branch 'master' into JDK-8294982
>>  - fixed new lines at end of file
>>  - package jdk.internal.classfile.jdktypes moved to jdk.internal.classfile.java.lang.constant
>>  - fixed CodeRelabeler javadoc
>>  - ... and 185 more: https://git.openjdk.org/jdk/compare/cdcf5c1e...48ac16f8
>
> This change looks good.  Have you compared the performance in generating dynamic proxies before and after?   
> 
> `test/micro/org/openjdk/bench/java/lang/reflect/Proxy/ProxyPerf.java` compares `ProxyGenerator` with `ProxyGenerator_v49` which was the old implementation before converting to ASM.    You may consider leveraging this benchmark.

Thanks @mlchung I've run part of  `test/micro/org/openjdk/bench/java/lang/reflect/Proxy/ProxyPerf.java` to compare performance with existing implementation and unfortunately I've discovered significant regressions.

The most significant regressions are caused by repeated conversions between `String` and `ClassDesc` or `MethodTypeDesc`. Repetitiveness of the conversions can be fixed, speed of the conversions can be improved, however there will be still remaining overhead, mainly in embedded validation. 

Another clearly visible CPU consumer is class hierarchy resolution, where correct caching scope and caching methods play important roles.  

In the following patches I'll focus on cutting the performance regression down as much as possible.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10991#issuecomment-1479943761

From asotona at openjdk.org  Wed Mar 22 17:37:07 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 22 Mar 2023 17:37:07 GMT
Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator
 to use the Classfile API to generate proxy classes [v10]
In-Reply-To: 
References: 
Message-ID: 

> java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes and this patch converts it to use Classfile API.
> 
> Please review.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 201 commits:

 - Merge branch 'master' into JDK-8294961
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java
 - ClassEntry caching ClassDesc to improve performance
 - MethodTypeDesc performance improvements
 - improved method descriptor construction
 - Apply suggestions from code review
   
   Co-authored-by: liach <7806504+liach at users.noreply.github.com>
 - Merge branch 'master' into JDK-8294961-proxy
 - Merge branch 'master' into JDK-8294961-proxy
 - Merge branch 'JDK-8294982' into JDK-8294961
 - removed obsolete javadoc from implementation classes
 - minor fix in CodeBuilder and added test cases to LDCTest
 - ... and 191 more: https://git.openjdk.org/jdk/compare/a2d8f634...2787185c

-------------

Changes: https://git.openjdk.org/jdk/pull/10991/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10991&range=09
  Stats: 489 lines in 6 files changed: 63 ins; 193 del; 233 mod
  Patch: https://git.openjdk.org/jdk/pull/10991.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10991/head:pull/10991

PR: https://git.openjdk.org/jdk/pull/10991

From duke at openjdk.org  Wed Mar 22 18:23:48 2023
From: duke at openjdk.org (Chris Hennick)
Date: Wed, 22 Mar 2023 18:23:48 GMT
Subject: RFR: 8284493: Improve computeNextExponential tail performance and
 accuracy [v16]
In-Reply-To: 
References: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
 
Message-ID: 

On Tue, 4 Oct 2022 17:36:56 GMT, Chris Hennick  wrote:

>> This PR improves both the worst-case performance of `nextExponential` and `nextGaussian` and the distribution of output at the tails. It fixes the following imperfections:
>> 
>> * Repeatedly adding DoubleZigguratTables.exponentialX0 to extra causes a rounding error to accumulate at the tail of the distribution (probably starting around `2*exponentialX0 == 0x1.e46eff20739afp3 ~ 15.1`); this PR fixes that by tracking the multiple of exponentialX0 as a long. (This distortion is worst when `x > 0x1.0p56` since in that case, a rounding error means `extra + x == extra`.
>> * Reduces several equations using `Math.fma`. (This will almost certainly improve performance, and may or may not improve output distribution.)
>> * Uses the newly-extracted `computeWinsorizedNextExponential` function to prevent `nextGaussian` from going into the `nextExponential` tail twice.
>
> Chris Hennick has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add parameter to enable/disable fixed PRNG seed

Keep open.

@JimLaskey @jddarcy May I please have at least a timeline on when to expect a review?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/8131#issuecomment-1480053601

From jlahoda at openjdk.org  Wed Mar 22 18:38:08 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 22 Mar 2023 18:38:08 GMT
Subject: RFR: 8304498: JShell does not switch to raw mode when there is no
 /bin/test [v2]
In-Reply-To: 
References: 
Message-ID: <3zqgbZ1T9WHdEQxojLFpW1eJ0_iqxRnmkyGgu2YiMXw=.cb6b356a-fb3c-484c-aca3-3f09304e30c8@github.com>

> If JShell is run on a system that does not have `/bin/test` (which is, apparently, possible for some systems, which only have `/usr/bin/test`), it won't switch the terminal into the raw mode, and the input will not work properly.
> 
> The proposed fix herein is to detect whether `test` existing in `/usr/bin/test`, and if yes, use that location. Use the existing `/bin/test` otherwise.

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Checking the executable flags instead of running the program, as suggested.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13100/files
  - new: https://git.openjdk.org/jdk/pull/13100/files/159ef1a0..f7631210

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13100&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13100&range=00-01

  Stats: 9 lines in 1 file changed: 2 ins; 6 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13100.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13100/head:pull/13100

PR: https://git.openjdk.org/jdk/pull/13100

From jvernee at openjdk.org  Wed Mar 22 18:47:59 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 22 Mar 2023 18:47:59 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 21 Mar 2023 09:02:29 GMT, Per Minborg  wrote:

>> API changes for the FFM API (third preview)
>> 
>> Specdiff:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
>> 
>> Javadoc:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add example for Option::captureStateLayout

src/java.base/share/classes/java/lang/foreign/Arena.java line 59:

> 57:  * which features a bounded lifetime that is managed, automatically, by the garbage collector. As such, the regions
> 58:  * of memory backing memory segments allocated with the automatic arena are deallocated at some unspecified time
> 59:  * after the automatic allocator (and all the segments allocated by it) become

Suggestion:

 * after the automatic arena (and all the segments allocated by it) become

src/java.base/share/classes/java/lang/foreign/Arena.java line 89:

> 87:  * Memory segments allocated with a {@linkplain #ofConfined() confined arena} can only be accessed (and closed) by the
> 88:  * thread that created the arena. If access to a memory segment from multiple threads is required, clients can allocate
> 89:  * segment in a {@linkplain #ofShared() shared arena} instead.

Suggestion:

 * segments in a {@linkplain #ofShared() shared arena} instead.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1143734059
PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1143738342

From jvernee at openjdk.org  Wed Mar 22 18:48:07 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 22 Mar 2023 18:48:07 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v8]
In-Reply-To: <4JIhKmX2VnDfArfFl-1YJfoUzGGBVA5Uvd3mdpatW-s=.5d86f29e-5475-4a4a-91df-d6418356e204@github.com>
References: 
 <4JIhKmX2VnDfArfFl-1YJfoUzGGBVA5Uvd3mdpatW-s=.5d86f29e-5475-4a4a-91df-d6418356e204@github.com>
Message-ID: 

On Wed, 22 Mar 2023 14:09:07 GMT, Per Minborg  wrote:

>> API changes for the FFM API (third preview)
>> 
>> Specdiff:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
>> 
>> Javadoc:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve javadocs for Linker::captureStateLayout

src/java.base/share/classes/java/lang/foreign/Linker.java line 492:

> 490:      * Finally, the returned method handle will throw an {@link IllegalArgumentException} if the {@link MemorySegment}
> 491:      * parameter passed to it is associated with the {@link MemorySegment#NULL} address, or a {@link NullPointerException}
> 492:      * if that parameter is {@code null}.

I think this isn't quite correct, as it only applies to the target address parameter. Also, we don't have to mention the NPE, as that's already mentioned in the package doc
Suggestion:

     * Finally, the returned method handle will throw an {@link IllegalArgumentException} if the {@link MemorySegment}
     * representing the target address of the foreign function is the {@link MemorySegment#NULL} address.

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 2315:

> 2313:          * @return {@code true}, if the provided object is also a scope, which models the same lifetime as that
> 2314:          * modelled by this scope.
> 2315:          */

A `@return` tag could be used here
Suggestion:

        /**
         * {@return {@code true}, if the provided object is also a scope, which models the same lifetime as that
         * modelled by this scope.} In that case, it is always the case that
         * {@code this.isAlive() == ((Scope)that).isAlive()}.
         * @param that the object to be tested.
         */

src/java.base/share/classes/jdk/internal/foreign/abi/fallback/FFIType.java line 116:

> 114:             }
> 115:             assert grpl instanceof UnionLayout;
> 116:             throw new IllegalArgumentException("Fallback linker does not support by-value unions: " + grpl);

For posterity, I suggest adding a comment here with the the bug number.
Suggestion:

            // JDK-8301800
            throw new IllegalArgumentException("Fallback linker does not support by-value unions: " + grpl);

src/java.base/share/native/libfallbackLinker/fallbackLinker.c line 82:

> 80:     value_ptr++;
> 81:   }
> 82: #endif

This looks incorrect. Look at the changes to `downcallLinker.cpp`, the `value_ptr++` should be moved outside of the if statements. (it only matters on Windows though, which we can't test at the moment for the fallback linker, but let's keep the 2 impls in sync for now)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1145188849
PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1145221286
PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1145245662
PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1145258121

From liach at openjdk.org  Wed Mar 22 18:50:49 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 22 Mar 2023 18:50:49 GMT
Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator
 to use the Classfile API to generate proxy classes [v10]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 22 Mar 2023 17:37:07 GMT, Adam Sotona  wrote:

>> java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes and this patch converts it to use Classfile API.
>> 
>> Please review.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 201 commits:
> 
>  - Merge branch 'master' into JDK-8294961
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java
>  - ClassEntry caching ClassDesc to improve performance
>  - MethodTypeDesc performance improvements
>  - improved method descriptor construction
>  - Apply suggestions from code review
>    
>    Co-authored-by: liach <7806504+liach at users.noreply.github.com>
>  - Merge branch 'master' into JDK-8294961-proxy
>  - Merge branch 'master' into JDK-8294961-proxy
>  - Merge branch 'JDK-8294982' into JDK-8294961
>  - removed obsolete javadoc from implementation classes
>  - minor fix in CodeBuilder and added test cases to LDCTest
>  - ... and 191 more: https://git.openjdk.org/jdk/compare/a2d8f634...2787185c

src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 77:

> 75:     private static final MethodTypeDesc
> 76:             MTD_boolean = MethodTypeDesc.of(CD_boolean),
> 77:             MTD_void = MethodTypeDesc.of(CD_void),

Suggestion:


Already in `ConstantDescs`

src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 91:

> 89: 
> 90:     private static final String NAME_CTOR = "";
> 91:     private static final String NAME_CLINIT = "";

Can be replaced with `ConstantDescs.INIT_NAME` and `CLASS_INIT_NAME`

src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 727:

> 725:         private void codeWrapArgument(CodeBuilder cob, Class type, int slot) {
> 726:             if (type.isPrimitive()) {
> 727:                 cob.loadInstruction(TypeKind.fromDescriptor(type.descriptorString()).asLoadable(), slot);

Suggestion:

                cob.loadInstruction(TypeKind.from(type).asLoadable(), slot);

src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 746:

> 744:                 cob.typeCheckInstruction(Opcode.CHECKCAST, prim.wrapperClass)
> 745:                    .invokevirtual(prim.wrapperClass, prim.unwrapMethodName, prim.unwrapMethodType)
> 746:                    .returnInstruction(TypeKind.fromDescriptor(type.descriptorString()).asLoadable());

Suggestion:

                   .returnInstruction(TypeKind.from(type).asLoadable());

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10991#discussion_r1145201367
PR Review Comment: https://git.openjdk.org/jdk/pull/10991#discussion_r1145201895
PR Review Comment: https://git.openjdk.org/jdk/pull/10991#discussion_r1145206384
PR Review Comment: https://git.openjdk.org/jdk/pull/10991#discussion_r1145264294

From mchung at openjdk.org  Wed Mar 22 18:56:08 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 22 Mar 2023 18:56:08 GMT
Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator
 to use the Classfile API to generate proxy classes [v10]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 22 Mar 2023 17:37:07 GMT, Adam Sotona  wrote:

>> java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes and this patch converts it to use Classfile API.
>> 
>> Please review.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 201 commits:
> 
>  - Merge branch 'master' into JDK-8294961
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java
>  - ClassEntry caching ClassDesc to improve performance
>  - MethodTypeDesc performance improvements
>  - improved method descriptor construction
>  - Apply suggestions from code review
>    
>    Co-authored-by: liach <7806504+liach at users.noreply.github.com>
>  - Merge branch 'master' into JDK-8294961-proxy
>  - Merge branch 'master' into JDK-8294961-proxy
>  - Merge branch 'JDK-8294982' into JDK-8294961
>  - removed obsolete javadoc from implementation classes
>  - minor fix in CodeBuilder and added test cases to LDCTest
>  - ... and 191 more: https://git.openjdk.org/jdk/compare/a2d8f634...2787185c

Mapping from a Class -> String -> TypeKind can be short-circuit.    The implementation of `TypeKind::from(Class)` can be updated for that.   The Classfile API can be considered to take a live `Class` object or `MethodType` object to avoid the conversion when appropriate.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10991#issuecomment-1480095735

From liach at openjdk.org  Wed Mar 22 18:56:09 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 22 Mar 2023 18:56:09 GMT
Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator
 to use the Classfile API to generate proxy classes [v10]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 22 Mar 2023 17:37:07 GMT, Adam Sotona  wrote:

>> java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes and this patch converts it to use Classfile API.
>> 
>> Please review.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 201 commits:
> 
>  - Merge branch 'master' into JDK-8294961
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java
>  - ClassEntry caching ClassDesc to improve performance
>  - MethodTypeDesc performance improvements
>  - improved method descriptor construction
>  - Apply suggestions from code review
>    
>    Co-authored-by: liach <7806504+liach at users.noreply.github.com>
>  - Merge branch 'master' into JDK-8294961-proxy
>  - Merge branch 'master' into JDK-8294961-proxy
>  - Merge branch 'JDK-8294982' into JDK-8294961
>  - removed obsolete javadoc from implementation classes
>  - minor fix in CodeBuilder and added test cases to LDCTest
>  - ... and 191 more: https://git.openjdk.org/jdk/compare/a2d8f634...2787185c

True, a few invoke/field instructions can take a `TypeDescriptor.OfField` `TypeDescriptor.OfMethod` instead of a `ClassDesc` or `MethodTypeDesc`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10991#issuecomment-1480098492

From mcimadamore at openjdk.org  Wed Mar 22 19:05:49 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 22 Mar 2023 19:05:49 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v8]
In-Reply-To: 
References: 
 <4JIhKmX2VnDfArfFl-1YJfoUzGGBVA5Uvd3mdpatW-s=.5d86f29e-5475-4a4a-91df-d6418356e204@github.com>
 
Message-ID: <69SHPBocr-b_789_vAvfpV67J_7ZrNal8SSnAFxugyw=.a971481e-9707-4022-88bd-b80906996cc7@github.com>

On Wed, 22 Mar 2023 17:34:36 GMT, Jorn Vernee  wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve javadocs for Linker::captureStateLayout
>
> src/java.base/share/classes/java/lang/foreign/Linker.java line 492:
> 
>> 490:      * Finally, the returned method handle will throw an {@link IllegalArgumentException} if the {@link MemorySegment}
>> 491:      * parameter passed to it is associated with the {@link MemorySegment#NULL} address, or a {@link NullPointerException}
>> 492:      * if that parameter is {@code null}.
> 
> I think this isn't quite correct, as it only applies to the target address parameter. Also, we don't have to mention the NPE, as that's already mentioned in the package doc
> Suggestion:
> 
>      * Finally, the returned method handle will throw an {@link IllegalArgumentException} if the {@link MemorySegment}
>      * representing the target address of the foreign function is the {@link MemorySegment#NULL} address.

Note: this text was just copied/adapted from toplevel javadoc and moved here. I think we have to say something about `null` as the text refers to `null` being passed as parameter to the returned MH, which is NOT covered by the package javadoc.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1145281749

From mcimadamore at openjdk.org  Wed Mar 22 19:09:27 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 22 Mar 2023 19:09:27 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v8]
In-Reply-To: 
References: 
 <4JIhKmX2VnDfArfFl-1YJfoUzGGBVA5Uvd3mdpatW-s=.5d86f29e-5475-4a4a-91df-d6418356e204@github.com>
 
Message-ID: 

On Wed, 22 Mar 2023 18:04:15 GMT, Jorn Vernee  wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve javadocs for Linker::captureStateLayout
>
> src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 2315:
> 
>> 2313:          * @return {@code true}, if the provided object is also a scope, which models the same lifetime as that
>> 2314:          * modelled by this scope.
>> 2315:          */
> 
> A `@return` tag could be used here
> Suggestion:
> 
>         /**
>          * {@return {@code true}, if the provided object is also a scope, which models the same lifetime as that
>          * modelled by this scope.} In that case, it is always the case that
>          * {@code this.isAlive() == ((Scope)that).isAlive()}.
>          * @param that the object to be tested.
>          */

Oh - I didn't know you could use return tag plus other text...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1145284853

From alanb at openjdk.org  Wed Mar 22 19:25:49 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 22 Mar 2023 19:25:49 GMT
Subject: RFR: 8300979: Lazily initialize (byte,
 char)arr in java.io.DataInputStream [v3]
In-Reply-To: <5tQ84BWMKaCnFalikXWrEtW9X21bB-ElGw-k5B-KZTQ=.703816ac-c0b1-4e08-be7d-74f6942010a6@github.com>
References: 
 <5tQ84BWMKaCnFalikXWrEtW9X21bB-ElGw-k5B-KZTQ=.703816ac-c0b1-4e08-be7d-74f6942010a6@github.com>
Message-ID: 

On Wed, 22 Mar 2023 10:12:26 GMT, Per Minborg  wrote:

>> This PR proposed to lazily initialize the scratch arrays only if/when needed.
>
> Per Minborg 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 'dis-lazy' of https://github.com/minborg/jdk into dis-lazy
>  - Update src/java.base/share/classes/java/io/DataInputStream.java
>    
>    Co-authored-by: Eirik Bjorsnos 
>  - Merge branch 'master' into dis-lazy
>  - Remove redundant initilizers
>  - Lazily initialize (byte, char)arr in java.io.DataInputStream

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13121#pullrequestreview-1353335537

From duke at openjdk.org  Wed Mar 22 19:26:54 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 22 Mar 2023 19:26:54 GMT
Subject: RFR: 8284493: Improve computeNextExponential tail performance and
 accuracy [v16]
In-Reply-To: 
References: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
 
Message-ID: 

On Tue, 4 Oct 2022 17:36:56 GMT, Chris Hennick  wrote:

>> This PR improves both the worst-case performance of `nextExponential` and `nextGaussian` and the distribution of output at the tails. It fixes the following imperfections:
>> 
>> * Repeatedly adding DoubleZigguratTables.exponentialX0 to extra causes a rounding error to accumulate at the tail of the distribution (probably starting around `2*exponentialX0 == 0x1.e46eff20739afp3 ~ 15.1`); this PR fixes that by tracking the multiple of exponentialX0 as a long. (This distortion is worst when `x > 0x1.0p56` since in that case, a rounding error means `extra + x == extra`.
>> * Reduces several equations using `Math.fma`. (This will almost certainly improve performance, and may or may not improve output distribution.)
>> * Uses the newly-extracted `computeWinsorizedNextExponential` function to prevent `nextGaussian` from going into the `nextExponential` tail twice.
>
> Chris Hennick has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add parameter to enable/disable fixed PRNG seed

Chris, copyrights in your new (2021?) and updated (2022?) files need a 2023 update.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/8131#issuecomment-1480133470

From jvernee at openjdk.org  Wed Mar 22 19:27:47 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 22 Mar 2023 19:27:47 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v8]
In-Reply-To: <69SHPBocr-b_789_vAvfpV67J_7ZrNal8SSnAFxugyw=.a971481e-9707-4022-88bd-b80906996cc7@github.com>
References: 
 <4JIhKmX2VnDfArfFl-1YJfoUzGGBVA5Uvd3mdpatW-s=.5d86f29e-5475-4a4a-91df-d6418356e204@github.com>
 
 <69SHPBocr-b_789_vAvfpV67J_7ZrNal8SSnAFxugyw=.a971481e-9707-4022-88bd-b80906996cc7@github.com>
Message-ID: 

On Wed, 22 Mar 2023 19:02:52 GMT, Maurizio Cimadamore  wrote:

>> src/java.base/share/classes/java/lang/foreign/Linker.java line 492:
>> 
>>> 490:      * Finally, the returned method handle will throw an {@link IllegalArgumentException} if the {@link MemorySegment}
>>> 491:      * parameter passed to it is associated with the {@link MemorySegment#NULL} address, or a {@link NullPointerException}
>>> 492:      * if that parameter is {@code null}.
>> 
>> I think this isn't quite correct, as it only applies to the target address parameter. Also, we don't have to mention the NPE, as that's already mentioned in the package doc
>> Suggestion:
>> 
>>      * Finally, the returned method handle will throw an {@link IllegalArgumentException} if the {@link MemorySegment}
>>      * representing the target address of the foreign function is the {@link MemorySegment#NULL} address.
>
> Note: this text was just copied/adapted from toplevel javadoc and moved here. I think we have to say something about `null` as the text refers to `null` being passed as parameter to the returned MH, which is NOT covered by the package javadoc.

Ah. True. This is true about all the MS parameters as well.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1145303573

From alanb at openjdk.org  Wed Mar 22 19:32:43 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 22 Mar 2023 19:32:43 GMT
Subject: RFR: 8300977: Retire java.io.ExpiringCache
In-Reply-To: 
References: 
Message-ID: 

On Tue, 24 Jan 2023 14:02:26 GMT, Per Minborg  wrote:

> This PR proposed to retire the class 'java.io.ExpiringCache'. The use of the class has been off by default since Java 16 but could be explicitly turned on by means of two System properties.

The removal looks okay okay. There is some noise in this patch with changes that are nothing to do with the PR but I think are okay.

src/java.base/unix/classes/java/io/DefaultFileSystem.java line 34:

> 32: final class DefaultFileSystem {
> 33: 
> 34:     private DefaultFileSystem() {}

This seems to be another drive-up change, there is only one implementation to making it final might be useful to people reading this code.

src/java.base/unix/classes/java/io/UnixFileSystem.java line 140:

> 138:     @Override
> 139:     public boolean isInvalid(File f) {
> 140:         return f.getPath().indexOf('\u0000') >= 0;

This seems to be another drive-by change but looks okay.

src/java.base/unix/classes/java/io/UnixFileSystem.java line 358:

> 356:     @Override
> 357:     public int getNameMax(String path) {
> 358:         return (int)Math.min(getNameMax0(path), Integer.MAX_VALUE);

This change is nothing to do with this issue. It's okay to refactor it as a drive-by change but I think keep nameMax as that made it easier to debug.

src/java.base/windows/classes/java/io/WinNTFileSystem.java line 429:

> 427:         if (s != null) return s;
> 428:         s = getDriveDirectory(i + 1);
> 429:         DRIVE_DIR_CACHE[i] = s;

This change is nothing to do with this PR but it looks okay.

-------------

PR Review: https://git.openjdk.org/jdk/pull/12167#pullrequestreview-1352635189
PR Review Comment: https://git.openjdk.org/jdk/pull/12167#discussion_r1144852146
PR Review Comment: https://git.openjdk.org/jdk/pull/12167#discussion_r1144867801
PR Review Comment: https://git.openjdk.org/jdk/pull/12167#discussion_r1144848624
PR Review Comment: https://git.openjdk.org/jdk/pull/12167#discussion_r1144855446

From duke at openjdk.org  Wed Mar 22 19:46:43 2023
From: duke at openjdk.org (nbauma109)
Date: Wed, 22 Mar 2023 19:46:43 GMT
Subject: RFR: 8303214: Typo in java.util.Collections#synchronizedNavigableMap
 javadoc
Message-ID: 

I think this is a typo

-------------

Commit messages:
 - Javadoc typo

Changes: https://git.openjdk.org/jdk/pull/11679/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11679&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303214
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11679.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/11679/head:pull/11679

PR: https://git.openjdk.org/jdk/pull/11679

From martin at openjdk.org  Wed Mar 22 19:46:45 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Wed, 22 Mar 2023 19:46:45 GMT
Subject: RFR: 8303214: Typo in
 java.util.Collections#synchronizedNavigableMap javadoc
In-Reply-To: 
References: 
Message-ID: <82jjhHy6bSTIql2pAh4KIJJJ2BzrV0nIeVR3g6FkVWs=.48e2baf1-352d-4775-8ef0-64aa40cbc61f@github.com>

On Wed, 14 Dec 2022 17:43:08 GMT, nbauma109  wrote:

> I think this is a typo

Marked as reviewed by martin (Reviewer).

No CSR required for typos in code samples.

-------------

PR Review: https://git.openjdk.org/jdk/pull/11679#pullrequestreview-1314583164
PR Comment: https://git.openjdk.org/jdk/pull/11679#issuecomment-1445212295

From duke at openjdk.org  Wed Mar 22 19:46:45 2023
From: duke at openjdk.org (SWinxy)
Date: Wed, 22 Mar 2023 19:46:45 GMT
Subject: RFR: 8303214: Typo in
 java.util.Collections#synchronizedNavigableMap javadoc
In-Reply-To: 
References: 
Message-ID: 

On Wed, 14 Dec 2022 17:43:08 GMT, nbauma109  wrote:

> I think this is a typo

Yeah this looks like a typo, but it doesn't fall under the `javadoc` tag?that's for the `javadoc` tool and related, not for issues in documentation. This might require a [CSR](https://wiki.openjdk.org/display/csr/Main) despite it being a minor typo.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/11679#issuecomment-1375008690

From duke at openjdk.org  Wed Mar 22 19:46:45 2023
From: duke at openjdk.org (nbauma109)
Date: Wed, 22 Mar 2023 19:46:45 GMT
Subject: RFR: 8303214: Typo in
 java.util.Collections#synchronizedNavigableMap javadoc
In-Reply-To: 
References: 
Message-ID: 

On Wed, 14 Dec 2022 17:43:08 GMT, nbauma109  wrote:

> I think this is a typo

need help with progressing this pull request towards integration

-------------

PR Comment: https://git.openjdk.org/jdk/pull/11679#issuecomment-1423692568

From aturbanov at openjdk.org  Wed Mar 22 19:46:46 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 22 Mar 2023 19:46:46 GMT
Subject: RFR: 8303214: Typo in
 java.util.Collections#synchronizedNavigableMap javadoc
In-Reply-To: 
References: 
Message-ID: 

On Wed, 14 Dec 2022 17:43:08 GMT, nbauma109  wrote:

> I think this is a typo

Filled https://bugs.openjdk.org/browse/JDK-8303214
Please change PR title to `8303214: Typo in java.util.Collections#synchronizedNavigableMap javadoc`

-------------

PR Comment: https://git.openjdk.org/jdk/pull/11679#issuecomment-1445188505

From jpai at openjdk.org  Wed Mar 22 19:46:48 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 22 Mar 2023 19:46:48 GMT
Subject: RFR: 8303214: Typo in
 java.util.Collections#synchronizedNavigableMap javadoc
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 9 Feb 2023 06:13:51 GMT, nbauma109  wrote:

>> I think this is a typo
>
> need help with progressing this pull request towards integration

Hello @nbauma109, have you signed the OCA? If not, please follow the instructions in this comment https://github.com/openjdk/jdk/pull/11679#issuecomment-1351840872

-------------

PR Comment: https://git.openjdk.org/jdk/pull/11679#issuecomment-1447669738

From mchung at openjdk.org  Wed Mar 22 20:02:45 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 22 Mar 2023 20:02:45 GMT
Subject: RFR: 8304691: Remove jlink --post-process-path option [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 22 Mar 2023 16:25:51 GMT, Ian Graves  wrote:

>> Removing the hidden `jlink --post-process-path` option.
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates per feedback

`test/jdk/tools/lib/tests/JImageGenerator` references this option and needs update.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 392:

> 390:         ExecutableImage img = DefaultImageBuilder.getExecutableImage(existingImage);
> 391:         if (img == null) {
> 392:             throw taskHelper.newBadArgs("err.existing.image.invalid");

"err.existing.image.invalid" can be removed from `jlink.properties.`

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/TaskHelper.java line 265:

> 263:                 Path path = Paths.get(arg);
> 264:                 if (!Files.exists(path) || !Files.isDirectory(path)) {
> 265:                     throw newBadArgs("err.image.must.exist", path);

"err.image.must.exist" can be removed from `jlink.properties`

-------------

PR Review: https://git.openjdk.org/jdk/pull/13126#pullrequestreview-1353383619
PR Review Comment: https://git.openjdk.org/jdk/pull/13126#discussion_r1145341533
PR Review Comment: https://git.openjdk.org/jdk/pull/13126#discussion_r1145339835

From igraves at openjdk.org  Wed Mar 22 20:09:26 2023
From: igraves at openjdk.org (Ian Graves)
Date: Wed, 22 Mar 2023 20:09:26 GMT
Subject: RFR: 8304691: Remove jlink --post-process-path option [v3]
In-Reply-To: 
References: 
Message-ID: 

> Removing the hidden `jlink --post-process-path` option.

Ian Graves has updated the pull request incrementally with one additional commit since the last revision:

  Removing leftover properties

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13126/files
  - new: https://git.openjdk.org/jdk/pull/13126/files/df0fde69..eb8c6b05

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13126&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13126&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13126.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13126/head:pull/13126

PR: https://git.openjdk.org/jdk/pull/13126

From mcimadamore at openjdk.org  Wed Mar 22 20:09:46 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 22 Mar 2023 20:09:46 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v8]
In-Reply-To: 
References: 
 <4JIhKmX2VnDfArfFl-1YJfoUzGGBVA5Uvd3mdpatW-s=.5d86f29e-5475-4a4a-91df-d6418356e204@github.com>
 
 <69SHPBocr-b_789_vAvfpV67J_7ZrNal8SSnAFxugyw=.a971481e-9707-4022-88bd-b80906996cc7@github.com>
 
Message-ID: 

On Wed, 22 Mar 2023 19:25:05 GMT, Jorn Vernee  wrote:

>> Note: this text was just copied/adapted from toplevel javadoc and moved here. I think we have to say something about `null` as the text refers to `null` being passed as parameter to the returned MH, which is NOT covered by the package javadoc.
>
> Ah. True. This is true about all the MS parameters as well.

Yes - although there is a distinction between passed by value and by ref. I wouldn't be surprised if we just threw NPE for by-value.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1145352294

From igraves at openjdk.org  Wed Mar 22 20:09:29 2023
From: igraves at openjdk.org (Ian Graves)
Date: Wed, 22 Mar 2023 20:09:29 GMT
Subject: RFR: 8304691: Remove jlink --post-process-path option [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 22 Mar 2023 19:57:51 GMT, Mandy Chung  wrote:

>> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removing leftover properties
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 392:
> 
>> 390:         ExecutableImage img = DefaultImageBuilder.getExecutableImage(existingImage);
>> 391:         if (img == null) {
>> 392:             throw taskHelper.newBadArgs("err.existing.image.invalid");
> 
> "err.existing.image.invalid" can be removed from `jlink.properties.`

Thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13126#discussion_r1145350266

From rriggs at openjdk.org  Wed Mar 22 20:52:49 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 22 Mar 2023 20:52:49 GMT
Subject: RFR: 8303485: Replacing os.name for operating system customization
 [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 14 Mar 2023 18:21:33 GMT, Roger Riggs  wrote:

>> Improvements to support OS specific customization for JDK internal use:
>>  - To select values and code; allowing elimination of unused code and values
>>  - Optionally evaluated by build processes, compilation, or archiving (i.e. CDS)
>>  - Simple API to replace adhoc comparisons with `os.name`
>>  - Clear and consistent use across build, runtime, and JDK modules
>>  
>> The PR includes updates within java.base to use the new API.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cover default case in switch on OS.

Please review the revisions.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12931#issuecomment-1480241882

From duke at openjdk.org  Wed Mar 22 21:17:54 2023
From: duke at openjdk.org (Chris Hennick)
Date: Wed, 22 Mar 2023 21:17:54 GMT
Subject: RFR: 8284493: Improve computeNextExponential tail performance and
 accuracy [v16]
In-Reply-To: 
References: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
 
 
Message-ID: 

On Wed, 22 Mar 2023 19:23:37 GMT, Eirik Bjorsnos  wrote:

>> Chris Hennick has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add parameter to enable/disable fixed PRNG seed
>
> Chris, copyrights in your new (2021?) and updated (2022?) files need a 2023 update.

@eirbjo Done.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/8131#issuecomment-1480263904

From duke at openjdk.org  Wed Mar 22 21:17:52 2023
From: duke at openjdk.org (Chris Hennick)
Date: Wed, 22 Mar 2023 21:17:52 GMT
Subject: RFR: 8284493: Improve computeNextExponential tail performance and
 accuracy [v17]
In-Reply-To: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
References: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
Message-ID: 

> This PR improves both the worst-case performance of `nextExponential` and `nextGaussian` and the distribution of output at the tails. It fixes the following imperfections:
> 
> * Repeatedly adding DoubleZigguratTables.exponentialX0 to extra causes a rounding error to accumulate at the tail of the distribution (probably starting around `2*exponentialX0 == 0x1.e46eff20739afp3 ~ 15.1`); this PR fixes that by tracking the multiple of exponentialX0 as a long. (This distortion is worst when `x > 0x1.0p56` since in that case, a rounding error means `extra + x == extra`.
> * Reduces several equations using `Math.fma`. (This will almost certainly improve performance, and may or may not improve output distribution.)
> * Uses the newly-extracted `computeWinsorizedNextExponential` function to prevent `nextGaussian` from going into the `nextExponential` tail twice.

Chris Hennick 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 15 additional commits since the last revision:

 - Merge branch 'master' into patch-1
 - Update copyright date in RandomNext.java
 - Update copyright date in RandomGeneratorNext.java
 - Update copyright date in RandomGeneratorExponentialGaussian.java
 - Update copyright date in RandomSupport.java
 - Add parameter to enable/disable fixed PRNG seed
 - Rewrite Javadoc
 - Simplify Javadoc description
 - Weaken contract of computeWinsorizedNextExponential to save max/min calls
 - Revert "Bugfix: need a thread-local instance for throughput test"
   
   This reverts commit d903efe57225e916a5450ac31437123050e3377c.
 - ... and 5 more: https://git.openjdk.org/jdk/compare/daddeb12...cc7c425a

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/8131/files
  - new: https://git.openjdk.org/jdk/pull/8131/files/b75139c9..cc7c425a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=8131&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8131&range=15-16

  Stats: 887558 lines in 10300 files changed: 477121 ins; 285236 del; 125201 mod
  Patch: https://git.openjdk.org/jdk/pull/8131.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/8131/head:pull/8131

PR: https://git.openjdk.org/jdk/pull/8131

From mullan at openjdk.org  Wed Mar 22 21:19:48 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 22 Mar 2023 21:19:48 GMT
Subject: RFR: 8303392: Runtime.exec and ProcessBuilder.start should use
 System logger [v7]
In-Reply-To: 
References: <-1i11ZrHHgzUbCSa_RXAcGKNfgtpdui--bltZ4Ujs2A=.f5f1a7e2-d3ec-4f64-9b1e-317ef2f24ef1@github.com>
 
Message-ID: 

On Tue, 14 Mar 2023 18:08:08 GMT, Roger Riggs  wrote:

>> Runtime.exec and ProcessBuilder.start methods create a new operating system process with the program and arguments. Many applications configure a logging subsystem to monitor application events. Logging a process start message with the program, arguments, and stack trace can identify the caller and purpose.
>> Logging the process start event is complementary to the process start event generated for JFR (Java Flight Recorder).
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove dead code and whitespace removal.

Marked as reviewed by mullan (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/12862#pullrequestreview-1353491027

From gerard.ziemski at oracle.com  Wed Mar 22 22:01:33 2023
From: gerard.ziemski at oracle.com (Gerard Ziemski)
Date: Wed, 22 Mar 2023 22:01:33 +0000
Subject: =?iso-8859-1?Q?Re:_Proposal:_track_zlib_native_memory_usage_with_NMTThoma?=
 =?iso-8859-1?Q?s_St=FCfe_thomas.stuefe_at_gmail.com__?=
Message-ID: <79E98A81-0D74-47A1-93E7-B1B2B3BE6E3A@oracle.com>

> Hi all,
> 
> I am currently working on https://bugs.openjdk.org/browse/JDK-8296360; I
> was preparing the final PR [1], but then Alan did ask me to discuss this on
> core-libs first.
> 
> Backstory:
> 
> NMT tracks hotspot native allocations but does not cover the JDK libraries
> (small exception: Unsafe.AllocateMemory). However, the native memory
> footprint of JDK libraries can be significant. We have no in-VM tracker for
> these and need tools like valgrind or our SapMachine MallocTracer [2] to
> observe them.
> 
> At SAP, in our proprietary VM, we have instrumented the whole JDK. Not via
> NMT, but with an older tracker we developed 15 years ago. It has run stable
> and productively on many platforms for ~15 years now, atop quite different
> libc implementations. It is impractical to contribute it upstream, however.
> Would not make much sense either since it overlaps a lot with NMT.
> 
> 2018 I discussed the possibility of extending NMT across the JDK wholesale,
> and the associated risks and difficulties [3]. The reception was not great,
> so I backed off and did other things.
> 
> But the issue of JDK native footprint comes up regularly. It is a thorn in
> our foot. Recently we had a customer whose zlib footprint exploded into the
> tens of GB range. Luckily the customer used our proprietary VM, so we
> pinpointed the cause quickly. With the OpenJDK we would have flown blind. I
> want to change that.
> 
> 
> Proposal:
> 
> In contrast to my first proposal from 2018 I'd like to instrument the core
> libs only in small steps, and only for selected allocation hotspots. There
> are not that many. And I start with the zlib.
> 
> My proposal does not touch the zlib itself. The solution works with both
> bundled zlib and system zlib. All the instrumentation happens in the JVM
> zlib wrapper. It mainly uses the zalloc mechanism of zlib streams to
> reroute the allocations.
> 
> 
> Costs and risks:
> 
> There is a risk involved with instrumentations like these. If we overlook
> instrumentation points we end up with unbalanced malloc/frees (instrumented
> malloc+raw free, or vice versa) which would corrupt the C-heap since NMT
> uses malloc headers. But in this case, the risk is very small since the
> instrumentations are few.

I always meant to ask, why is it that we chose to dedicate the beginning of the memory chunk to NMT, and not the end?

If we used the end, then in this case with an unbalanced malloc/free, we would still be OK.

The end seems more natural to me and either way we need to track the size, and moreover, in the current case, we need the size of the header as well.


cheers

> 
> (Side note: our internal tracker sidesteps this problem entirely by
> avoiding malloc headers. Instead, it uses a hash tables to match pointers
> with their meta information. But that has other cons and I do not plan to
> change the way NMT works.)
> 
> Performance-wise, instead of calling into the libc directly, we would call
> into the hotspot, then into the libc. That indirection will cost some
> cycles. If NMT is off, there does not happen much more beside the real
> malloc call. Even NMT summary mode is very cheap. So I don't expect this to
> be a problem but will run performance tests.
> 
> --------
> 
> My patch [1] works and can be built and tested. But the PR is still a work
> in progress. I just wanted to make sure nobody generally objects to my work.
> 
> Cheers, Thomas
> 
> [1] https://github.com/openjdk/jdk/pull/10988
> [2] https://github.com/SAP/SapMachine/wiki/SapMachine-MallocTracer
> [3] https://mail.openjdk.org/pipermail/hotspot-dev/2018-November/035358.html

From naoto at openjdk.org  Wed Mar 22 22:11:49 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 22 Mar 2023 22:11:49 GMT
Subject: RFR: 8303485: Replacing os.name for operating system customization
 [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 14 Mar 2023 18:21:33 GMT, Roger Riggs  wrote:

>> Improvements to support OS specific customization for JDK internal use:
>>  - To select values and code; allowing elimination of unused code and values
>>  - Optionally evaluated by build processes, compilation, or archiving (i.e. CDS)
>>  - Simple API to replace adhoc comparisons with `os.name`
>>  - Clear and consistent use across build, runtime, and JDK modules
>>  
>> The PR includes updates within java.base to use the new API.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cover default case in switch on OS.

src/java.base/unix/classes/java/lang/ProcessImpl.java line 29:

> 27: 
> 28: import java.lang.ProcessBuilder.Redirect;
> 29: import jdk.internal.util.OperatingSystem;

Moving this import after `java.*` would be better

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12931#discussion_r1145456690

From smarks at openjdk.org  Wed Mar 22 22:20:43 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 22 Mar 2023 22:20:43 GMT
Subject: RFR: 8303214: Typo in
 java.util.Collections#synchronizedNavigableMap javadoc
In-Reply-To: 
References: 
Message-ID: 

On Wed, 14 Dec 2022 17:43:08 GMT, nbauma109  wrote:

> I think this is a typo

Marked as reviewed by smarks (Reviewer).

Agreed that there is no need for CSR. This is just a typo. Reviewed.

-------------

PR Review: https://git.openjdk.org/jdk/pull/11679#pullrequestreview-1353554321
PR Comment: https://git.openjdk.org/jdk/pull/11679#issuecomment-1480330648

From smarks at openjdk.org  Wed Mar 22 22:38:52 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 22 Mar 2023 22:38:52 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
Message-ID: 

On Tue, 21 Mar 2023 12:39:18 GMT, Chen Liang  wrote:

> I am interested in the optimization potential of `arraylist.reversed().addAll()` and similar batch operations. Though reverse list/deque views are a good start, I still wish to see customized implementations for `reversed` to perform `addAll` `removeIf` efficiently.

OK. I took a quick look over `ReverseOrderListView` and it seems like there are some things that can be optimized there. If those aren't sufficient, then additional overrides in `ArrayList` _et al_ might be warranted.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1480345189

From liach at openjdk.org  Wed Mar 22 22:52:19 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 22 Mar 2023 22:52:19 GMT
Subject: RFR: 8304031: Classfile API cannot encode Primitive Class as Condy
 [v3]
In-Reply-To: <6SEB6ZAh2b0ayMCo5EfvOW-adtsAysbf1Zk6qBbh2SI=.96417080-f2a8-424d-9a26-0ed68f6b33ac@github.com>
References: <6SEB6ZAh2b0ayMCo5EfvOW-adtsAysbf1Zk6qBbh2SI=.96417080-f2a8-424d-9a26-0ed68f6b33ac@github.com>
Message-ID: 

> Without this patch, the Classfile API tries to encode PrimitiveClassDesc as CONSTANT_Class_info and error in `toInternalName`.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  PrimitiveClassConstantTest check the other 2 API endpoints, move to junit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12996/files
  - new: https://git.openjdk.org/jdk/pull/12996/files/df3ed0c0..74021d23

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12996&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12996&range=01-02

  Stats: 18 lines in 1 file changed: 10 ins; 2 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/12996.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12996/head:pull/12996

PR: https://git.openjdk.org/jdk/pull/12996

From duke at openjdk.org  Wed Mar 22 23:48:41 2023
From: duke at openjdk.org (jmehrens)
Date: Wed, 22 Mar 2023 23:48:41 GMT
Subject: RFR: 8303923: ZipOutStream::putEntry should include an apiNote to
 indicate that the STORED compression method should be used when
 writing directory entries [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 19 Mar 2023 14:50:41 GMT, Eirik Bjorsnos  wrote:

>> ZipOutputStream currently writes directory entries using the DEFLATED compression method. This does not strictly comply with the APPNOTE.TXT specification and is also about 10x slower than using the STORED compression method.
>> 
>> Because of these concerns, `ZipOutputStream.putNextEntry` should be updated with an `@apiNote` recommending
>> the use of the STORED compression method for directory entries.
>> 
>> Suggested CSR in the first comment.
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove speculation that using DEFLATED for directory entries is not in strict compliance with APPNOTE.txt

The example code works without setting the compressed size on the entry?

Looks like there is a check in ZipOutputStream::putNextEntry at
https://github.com/openjdk/jdk/blob/6cc4bb1169f34bc091cad3e2deec37cd5585e8d5/src/java.base/share/classes/java/util/zip/ZipOutputStream.java#L233

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12899#issuecomment-1480394938

From igraves at openjdk.org  Thu Mar 23 01:08:43 2023
From: igraves at openjdk.org (Ian Graves)
Date: Thu, 23 Mar 2023 01:08:43 GMT
Subject: RFR: 8304691: Remove jlink --post-process-path option [v4]
In-Reply-To: 
References: 
Message-ID: <4fCKeyyqvizyiyJQUGZSqLnsK7gkW9toFgdncrpXj2A=.f4b5e4f6-31c7-40a9-854e-834c1c04fc26@github.com>

> Removing the hidden `jlink --post-process-path` option.

Ian Graves has updated the pull request incrementally with one additional commit since the last revision:

  Removing post process opt reference

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13126/files
  - new: https://git.openjdk.org/jdk/pull/13126/files/eb8c6b05..e1af1d5e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13126&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13126&range=02-03

  Stats: 20 lines in 1 file changed: 0 ins; 20 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13126.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13126/head:pull/13126

PR: https://git.openjdk.org/jdk/pull/13126

From jpai at openjdk.org  Thu Mar 23 01:44:18 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 23 Mar 2023 01:44:18 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v11]
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.org/browse/JDK-8206890?
> 
> The `jlink` command allows a `--endian` option to specify the byte order in the generated image. Before this change, when such a image was being launched, the code would assume the byte order in the image to be the native order of the host where the image is being launched. That would result in failure to launch java, as noted in the linked issue.
> 
> The commit in this PR, changes relevant places to not assume native order and instead determine the byte order by reading the magic bytes in the image file's header content.
> 
> A new jtreg test has been added which reproduces the issue and verifies the fix.

Jaikiran Pai has updated the pull request incrementally with four additional commits since the last revision:

 - when --endian is specified, verify it matches the implicitly determined target platform's endianness
 - trim down the architecture support to the previous values plus a few new that match target.properties
 - improve error messages as suggested by Mandy
 - formatting fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11943/files
  - new: https://git.openjdk.org/jdk/pull/11943/files/e31ef76c..3946fe40

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11943&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11943&range=09-10

  Stats: 74 lines in 3 files changed: 34 ins; 28 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/11943.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/11943/head:pull/11943

PR: https://git.openjdk.org/jdk/pull/11943

From jpai at openjdk.org  Thu Mar 23 01:44:29 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 23 Mar 2023 01:44:29 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v10]
In-Reply-To: 
References: 
 <0dJDlxKHyQs6Dtq8pvAEmg-7Q4PA__XmtvPVDSxSQhE=.e6806026-7866-492e-a976-e0640fe9e11c@github.com>
 
Message-ID: 

On Tue, 21 Mar 2023 18:07:30 GMT, Mandy Chung  wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Alan's suggestions - don't parse arch out of osname-arch for determining endianness and reduce the number of supported/known target platforms for cross linking
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 548:
> 
>> 546:                                                      Path retainModulesPath,
>> 547:                                                      boolean ignoreSigning,
>> 548:                                                      boolean bindService,
> 
> formatting nit: align the parameters with the first one.

Fixed

> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 822:
> 
>> 820:                     PrintWriter log) throws IOException {
>> 821:             if (order != null) {
>> 822:                 this.targetPlatform = Platform.runtime();
> 
> The target platform should always be fetched from `java.base` (as it was implemented in `DefaultImageBuilder`) or use the current runtime if `java.base` is from the module path of the current runtime.
> 
> If `--endian ` is specified, jlink can check if the target platform's endianness matches the specified value and emit an error if mismatch unless `Platform::getNativeByteOrder` is null.

That's a good catch. I've now fixed it as you suggested.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/11943#discussion_r1145578825
PR Review Comment: https://git.openjdk.org/jdk/pull/11943#discussion_r1145579091

From xgong at openjdk.org  Thu Mar 23 01:45:20 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 23 Mar 2023 01:45:20 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v4]
In-Reply-To: 
References: 
 <4Op0Z8whnyDXDC6zGyMbx4ugcZp5TEoAqW_myB5flxM=.1c7b59ba-efb2-4f68-90d7-2d6e33e39572@github.com>
 
 
Message-ID: 

On Wed, 22 Mar 2023 12:39:27 GMT, Quan Anh Mai  wrote:

>> src/hotspot/share/opto/vectorIntrinsics.cpp line 2426:
>> 
>>> 2424:   if (is_vector_shuffle(vbox_klass_from)) {
>>> 2425:     return false; // vector shuffles aren't supported
>>> 2426:   }
>> 
>> Is it better to change this as an "assertion" or print the log details?
>
> The change indifferentiates a vector shuffle from a normal vector in C2, so this should be removed, as vector shuffles are converted to/from normal vector using this routine

Oh, I'm sorry that I didn't notice it is a removing change. And, yes, you're right. So please ignore my previous comment. Thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1145580975

From jpai at openjdk.org  Thu Mar 23 01:46:47 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 23 Mar 2023 01:46:47 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v12]
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.org/browse/JDK-8206890?
> 
> The `jlink` command allows a `--endian` option to specify the byte order in the generated image. Before this change, when such a image was being launched, the code would assume the byte order in the image to be the native order of the host where the image is being launched. That would result in failure to launch java, as noted in the linked issue.
> 
> The commit in this PR, changes relevant places to not assume native order and instead determine the byte order by reading the magic bytes in the image file's header content.
> 
> A new jtreg test has been added which reproduces the issue and verifies the fix.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  ARM is 32 bit as per platform.m4 in OpenJDK build

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11943/files
  - new: https://git.openjdk.org/jdk/pull/11943/files/3946fe40..7a72e9c5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11943&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11943&range=10-11

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11943.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/11943/head:pull/11943

PR: https://git.openjdk.org/jdk/pull/11943

From liach at openjdk.org  Thu Mar 23 01:52:31 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 23 Mar 2023 01:52:31 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 20 Mar 2023 20:31:46 GMT, Jim Laskey  wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Tidy javadoc
>  - Rename StringTemplate classes

src/java.base/share/classes/java/lang/StringTemplate.java line 449:

> 447:      * statically imported explicitly.
> 448:      */
> 449:     static final SimpleProcessor RAW = st -> st;

Should we omit the modifiers `static final`, which are implicit for all interface fields?

src/java.base/share/classes/java/lang/StringTemplate.java line 455:

> 453:      * primary method {@link Processor#process(StringTemplate)} is used to validate
> 454:      * and compose a result using a {@link StringTemplate StringTemplate's} fragments and values lists.
> 455:      *

Paragraph break intended here?

src/java.base/share/classes/java/lang/StringTemplate.java line 550:

> 548:      * SimpleProcessor jsonProcessor = st -> new JSONObject(st.interpolate());
> 549:      * }
> 550:      * @implNote The Java compiler automatically imports {@link StringTemplate#STR}

Does this note belong here? And does this come with a rule in the Java Language Specification, which can be linked?

src/java.base/share/classes/java/lang/StringTemplate.java line 592:

> 590:          */
> 591:         @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
> 592:         public sealed interface Linkage permits FormatProcessor {

I fail to see any reason a user would call `linkage`; is there anything that's not covered by `TemplateRuntime::processStringTemplate`? And if users can't use this, this can just be relocated to one of the `jdk.internal` packages.

src/java.base/share/classes/java/lang/StringTemplate.java line 679:

> 677:     @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
> 678:     @FunctionalInterface
> 679:     public interface StringProcessor extends SimpleProcessor {

Just curious, what's the rationale of a `SimpleProcessor` or `StringProcessor` as opposed to:

static  TemplateProcessor simple(Function function) {...}
static TemplateProcessor string(Function function) {...}

which avoids the requirement of specifying the type of the template processor local variable; users can use `var` instead.

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1051:

> 1049:      * @param ptypes    list of expression types
> 1050:      *
> 1051:      * @return {@link MethodHandle}

Suggestion:

     * @return the {@link MethodHandle} for concatenation

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1169:

> 1167:      * have an extra {@link String} slot for the result from the previous
> 1168:      * {@link MethodHandle}.
> 1169:      * {@link java.lang.invoke.StringConcatFactory#makeConcatWithTemplate}

Suggestion:

     * {@link #makeConcatWithTemplate}

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1246:

> 1244:      * This method creates a {@link MethodHandle} expecting one input, the
> 1245:      * receiver of the supplied getters. This method uses
> 1246:      * {@link java.lang.invoke.StringConcatFactory#makeConcatWithTemplateCluster}

Suggestion:

     * {@link #makeConcatWithTemplateCluster}

src/java.base/share/classes/java/lang/runtime/Carriers.java line 370:

> 368:          */
> 369:         private static Map
> 370:                 methodTypeCache = ReferencedKeyMap.create(() -> new ConcurrentHashMap<>());

Suggestion:

                methodTypeCache = ReferencedKeyMap.create(ConcurrentHashMap::new);

src/java.base/share/classes/java/lang/runtime/Carriers.java line 421:

> 419:          */
> 420:         protected CarrierObject(int primitiveCount, int objectCount) {
> 421:             this.primitives = createPrimitivesArray(primitiveCount );

Suggestion:

            this.primitives = createPrimitivesArray(primitiveCount);

src/java.base/share/classes/java/lang/runtime/Carriers.java line 776:

> 774:          * @throws IllegalArgumentException if number of component slots exceeds maximum
> 775:          */
> 776:         static CarrierElements of(Class < ? >...ptypes) {

Suggestion:

        static CarrierElements of(Class... ptypes) {

src/java.base/share/classes/java/lang/runtime/Carriers.java line 824:

> 822:         private CarrierElements() {
> 823:             throw new AssertionError("private constructor");
> 824:         }

Suggestion:

src/java.base/share/classes/java/lang/runtime/ReferenceKey.java line 49:

> 47: interface ReferenceKey {
> 48:     /**
> 49:      * {@return the value of the unwrapped key.}

Suggestion:

     * {@return the value of the unwrapped key}

Inline return tag generates a period already.

src/java.base/share/classes/java/lang/runtime/ReferencedKeyMap.java line 127:

> 125:     @SuppressWarnings("unchecked")
> 126:     static  ReferencedKeyMap
> 127:     create(boolean isSoft, Supplier> supplier) {

What prevents this to take `Supplier, V>>`? Same for below.

src/java.base/share/classes/java/lang/runtime/StringTemplateImpl.java line 40:

> 38:  * 
      
> 39:  * Values are stored by subclassing {@link Carriers.CarrierObject}. This allows specializations
> 40:  * and sharing of value shapes without creating a new class for each shape.

Just curious, what specific benefits does subclassing offer over having `CarrierObject` as a field? I don't see how a new class is ever created for each shape in that scenario, as shapes are only used to construct the 2 MHs in the factory.

src/java.base/share/classes/java/lang/runtime/StringTemplateImpl.java line 65:

> 63:      * {@link java.lang.invoke.CallSite CallSite}.
> 64:      */
> 65:     private final MethodHandle valuesMH;

I don't think `java.lang.runtime` is a package where final fields are [trusted](https://github.com/openjdk/jdk/blob/91f407d6fe285c44bcc25c1acdf5dc0c43be0172/src/hotspot/share/ci/ciField.cpp#L226), so these method handles might have a performance overhead. However, records appear to be optimized and eligible for inlining.

src/java.base/share/classes/java/lang/runtime/StringTemplateImplFactory.java line 88:

> 86:      *
> 87:      * @param fragments  string template fragments
> 88:      * @param type       method type

Suggestion:

     * @param type method type accepting values' types and returning a StringTemplate

src/java.base/share/classes/java/lang/runtime/StringTemplateImplFactory.java line 169:

> 167:      * @return StringTemplate composed from fragments and values
> 168:      */
> 169:     static StringTemplate newStringTemplate(List fragments, Object[] values) {

I recommend renaming this one and the above methods (taking Object[] for values) `newTrustedStringTemplate` to indicate these two trust the passed values array.

src/java.base/share/classes/java/lang/runtime/TemplateRuntime.java line 204:

> 202:             Object[] values
> 203:     ) throws Throwable {
> 204:         List asList = Collections.unmodifiableList(new ArrayList<>(Arrays.asList(values)));

Suggestion:

        List asList = List.of(values);

For defensive copy.
Don't think processors are harmed by the null-hostile behavior of these list, for many template implementations already use null-hostile lists.

src/java.base/share/classes/java/lang/runtime/TemplateRuntime.java line 233:

> 231:      */
> 232:     private static StringTemplate fromArrays(String[] fragments, Object[] values) {
> 233:         return StringTemplateImplFactory.newStringTemplate(fragments, values);

Should perform defensive copying for the input arrays, specifically `values` (fragments is passed to `List.of`, which is already safe)

In addition, I recommend renaming methods that don't perform defensive copies to like `ofTrusted`, so we can better avoid such problems.

src/java.base/share/classes/java/util/Digits.java line 68:

> 66:      */
> 67:     final class DecimalDigits implements Digits {
> 68:         private static final short[] DIGITS;

Can add `@Stable` to speed up array element access. Same for below.

src/java.base/share/classes/java/util/FormatProcessor.java line 157:

> 155:         Objects.requireNonNull(stringTemplate);
> 156:         String format = stringTemplateFormat(stringTemplate.fragments());
> 157:         Object[] values = stringTemplate.values().toArray(new Object[0]);

Suggestion:

        Object[] values = stringTemplate.values().toArray();

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145500281
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145500568
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145503416
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145582334
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145509343
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145511968
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145520158
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145521984
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145532679
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145528633
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145531061
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145531547
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145533037
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145534263
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145566980
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145555878
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145567708
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145576079
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145577290
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145570455
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145578159
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145579950

From liach at openjdk.org  Thu Mar 23 01:52:32 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 23 Mar 2023 01:52:32 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v3]
In-Reply-To: <9vQMc2mMDyHm5uoAKuvtqGm4pyJdVdSRIKGmfrEBQvI=.f7cd331b-4185-4f9b-9e94-0893090d0e53@github.com>
References: 
 
 
 
 <9vQMc2mMDyHm5uoAKuvtqGm4pyJdVdSRIKGmfrEBQvI=.f7cd331b-4185-4f9b-9e94-0893090d0e53@github.com>
Message-ID: 

On Fri, 28 Oct 2022 20:05:22 GMT, R?mi Forax  wrote:

>> Disagree.
>
> As i said above, i consider this thread as resolved

Suggestion:

     * to {@value #MAX_INDY_CONCAT_ARG_SLOTS}.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145511120

From jpai at openjdk.org  Thu Mar 23 01:53:28 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 23 Mar 2023 01:53:28 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v12]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 23 Mar 2023 01:46:47 GMT, Jaikiran Pai  wrote:

>> Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8206890?
>> 
>> The `jlink` command allows a `--endian` option to specify the byte order in the generated image. Before this change, when such a image was being launched, the code would assume the byte order in the image to be the native order of the host where the image is being launched. That would result in failure to launch java, as noted in the linked issue.
>> 
>> The commit in this PR, changes relevant places to not assume native order and instead determine the byte order by reading the magic bytes in the image file's header content.
>> 
>> A new jtreg test has been added which reproduces the issue and verifies the fix.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ARM is 32 bit as per platform.m4 in OpenJDK build

Thank you Mandy for the review, I've updated the PR with the changes that you suggested. Existing jtreg tests in `test/jdk/tools/jlink` `test/jdk/tools/jimage` continue to pass and a manual test shows that for cross platform jlink, the code picks up the endianness correctly and also throws an error if an explicit endianness doesn't match the java.base module's target platform.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/11943#issuecomment-1480469900

From jpai at openjdk.org  Thu Mar 23 01:53:34 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 23 Mar 2023 01:53:34 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v10]
In-Reply-To: 
References: 
 <0dJDlxKHyQs6Dtq8pvAEmg-7Q4PA__XmtvPVDSxSQhE=.e6806026-7866-492e-a976-e0640fe9e11c@github.com>
 
Message-ID: <87OboLCH2UjgRTiGjm_vkdi_mGoiy6rAfkxljHiQK7E=.5a7f1459-ff55-4c7c-91ce-c2736707730f@github.com>

On Tue, 21 Mar 2023 19:02:21 GMT, Mandy Chung  wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Alan's suggestions - don't parse arch out of osname-arch for determining endianness and reduce the number of supported/known target platforms for cross linking
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 856:
> 
>> 854:                         // unsupported target platform
>> 855:                         throw new IOException(
>> 856:                                 taskHelper.getMessage("err.unsupported.target.platform",
> 
> IIUC, the current jlink implementation does not fail if the target platform is unknown as long as `--endian` option is specified.   So I think `--endian` may be useful to keep (rather than taking it out).   This error key should be `err.unknown.target.endianness` and the message can suggest to use `--endian` option to specify.

I've updated the key to match what you suggest here.

> src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties line 151:
> 
>> 149: err.signing=signed modular JAR {0} is currently not supported,\
>> 150: \ use --ignore-signing-information to suppress error
>> 151: err.cannot.determine.target.platform=cannot determine target platform for image generation
> 
> Suggestion:
> 
> err.cannot.determine.target.platform=cannot determine target platform from {0}
> 
> 
> `{0}` can be the path to `java.base.jmod`  (i.e. `ModuleReference::location`)

Done. Additionally, if the `ModuleReference::location` is unknown (it's an `Optional`) then we will print `cannot determine target platform from java.base module`

> src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties line 152:
> 
>> 150: \ use --ignore-signing-information to suppress error
>> 151: err.cannot.determine.target.platform=cannot determine target platform for image generation
>> 152: err.unsupported.target.platform=image generation for target platform {0} is not supported
> 
> Suggestion:
> 
> err.unsupported.target.endianness=Unknown native byte order for target platform {0}`
> 
> 
> `{0}` is `targetPlatformVal`

Done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/11943#discussion_r1145583060
PR Review Comment: https://git.openjdk.org/jdk/pull/11943#discussion_r1145583531
PR Review Comment: https://git.openjdk.org/jdk/pull/11943#discussion_r1145583598

From jpai at openjdk.org  Thu Mar 23 01:53:36 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 23 Mar 2023 01:53:36 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v10]
In-Reply-To: <_nMLxyEyUfuWj7Xf_DV4ArtRMB74hSTQXXuKbLkK7F8=.abfc97fc-41d4-45b4-9bab-3b3d98354d59@github.com>
References: 
 <0dJDlxKHyQs6Dtq8pvAEmg-7Q4PA__XmtvPVDSxSQhE=.e6806026-7866-492e-a976-e0640fe9e11c@github.com>
 
 <_nMLxyEyUfuWj7Xf_DV4ArtRMB74hSTQXXuKbLkK7F8=.abfc97fc-41d4-45b4-9bab-3b3d98354d59@github.com>
Message-ID: 

On Tue, 21 Mar 2023 18:55:17 GMT, Mandy Chung  wrote:

>> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Platform.java line 192:
>> 
>>> 190:             case "s390x"           -> Architecture.s390x;
>>> 191:             case "sparc"           -> Architecture.SPARC;
>>> 192:             case "sparcv9"         -> Architecture.SPARCv9;
>> 
>> This list should be trimmed to the ones supported in the mainline as in `target.properties`.
>
> Also `is64Bit` will need update for other 64-bit platforms.

I've now updated the PR to trim down the target platforms to match what we have in `target.properties`. Additionally, `is64Bit` has been enhanced too.

I would like to note that, in an intermediate version of this PR, I made `is64Bit` return true for `arm` architecture. I did so because from the materials I found, ARM supports both 32 bit and 64 bit architectures, but the recent versions are 64 bit. So I thought it would be appropriate to consider it 64 bit.

However, I then looked up the `platform.m4` build file and it marks `arm` architecture as 32 bit https://github.com/openjdk/jdk/blob/master/make/autoconf/platform.m4#L57. So I've updated the PR to return false from `is64Bit` from `arm` arch.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/11943#discussion_r1145582050

From xgong at openjdk.org  Thu Mar 23 02:25:44 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 23 Mar 2023 02:25:44 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v4]
In-Reply-To: 
References: 
 <4Op0Z8whnyDXDC6zGyMbx4ugcZp5TEoAqW_myB5flxM=.1c7b59ba-efb2-4f68-90d7-2d6e33e39572@github.com>
 
 
Message-ID: 

On Wed, 22 Mar 2023 12:42:15 GMT, Quan Anh Mai  wrote:

>> src/hotspot/share/opto/vectorIntrinsics.cpp line 2059:
>> 
>>> 2057:   if (need_load_shuffle) {
>>> 2058:     shuffle = gvn().transform(new VectorLoadShuffleNode(shuffle, vt));
>>> 2059:   }
>> 
>> How about generating `VectorLoadShuffleNode` for all platforms that support Vector API, and remove the helper method `vector_needs_load_shuffle()` ? For those platforms that do not need this shuffle preparation, we can emit nothing  in codegen.
>
> I think not emitting `VectorLoadShuffleNode` is more common so it is better to emit them only when needed, as it will simplify the graph and may allow better inspections of the indices in the future. Additionally, a do-nothing node does not alias with its input and therefore kills the input, which leads to an additional spill if they both need to live.

Yeah, I agree that saving a node have some benefits like what you said. My concern is there are more and more methods added into `Matcher::` and each platform has to do the different implementation. There is not too much meaning for those platforms that do not implement Vector API like` arm/ppc/...` for me. This makes code not so easy to maintain.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1145598639

From xgong at openjdk.org  Thu Mar 23 02:31:46 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 23 Mar 2023 02:31:46 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v3]
In-Reply-To: 
References: 
 <4Op0Z8whnyDXDC6zGyMbx4ugcZp5TEoAqW_myB5flxM=.1c7b59ba-efb2-4f68-90d7-2d6e33e39572@github.com>
 
Message-ID: <_oZaqVXsCPRK3Poj6yp7Vi4S4cCuRygQv9pGhPvTAPk=.d7139597-8b20-4170-80cc-94ec7f88b2e4@github.com>

On Wed, 22 Mar 2023 08:09:03 GMT, Xiaohong Gong  wrote:

>> Quan Anh Mai has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - missing casts
>>  - clean up
>
> Please also update the copyright to 2023 for some touched files like `vectorSupport.hpp` and other java files like `AbstractShuffle.java`, `AbstractVector.java`, `VectorShape.java`, and `VectorShuffle.java`. Thanks!

> @XiaohongGong Thanks, I have updated the copyright year and the code styles as you suggested

Thanks for your update! 

> I also noticed that the similar shuffle cast code is used more frequently. Could we wrap such code `toShuffle().cast(vspecies())` to a separate method?

And for this, is it possible to wrap such code in a single method?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13093#issuecomment-1480494762

From liach at openjdk.org  Thu Mar 23 02:36:43 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 23 Mar 2023 02:36:43 GMT
Subject: RFR: 8303930: Fix ConstantUtils.skipOverFieldSignature void case
 return value [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 21 Mar 2023 20:21:23 GMT, Chen Liang  wrote:

>> This typo doesn't allow creation of malformed ClassDesc or MethodTypeDesc, but it produces an erroneous exception on certain inputs. Running `java.lang.constant.MethodTypeDesc.ofDescriptor("(IIIII[[[V)I")` in Jshell 19.0.2 throws StringIndexOutOfBoundsException, and throws IllegalArgumentException in the Jshell for this patch.
>
> Chen Liang 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' of https://git.openjdk.java.net/jdk into 8303930
>  - Add test for skipOverFieldSignature bug
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into 8303930
>  - Copyright year
>  - 8303930: Fix ConstantUtils.skipOverFieldSignature void case return value

Could any engineer please review this patch fixing `ConstantUtils.skipOverFieldSignature` throwing `StringIndexOutOfBoundsException` on certain crafted inputs?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12964#issuecomment-1480500845

From liach at openjdk.org  Thu Mar 23 02:38:41 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 23 Mar 2023 02:38:41 GMT
Subject: RFR: 8284871: Use covariant overrides for the
 resolveConstantDesc(Lookup) method in =?UTF-8?B?c3Vi4oCRaW50ZXJmYWNlcw==?= of
 java.lang.constant.ConstantDesc
In-Reply-To: <6elA1YOQCqZutbsRVG89Q0C_5-3zu-OHco8_h2z5mKg=.a313ea66-e58d-401b-88a8-c843dcecf218@github.com>
References: <6elA1YOQCqZutbsRVG89Q0C_5-3zu-OHco8_h2z5mKg=.a313ea66-e58d-401b-88a8-c843dcecf218@github.com>
Message-ID: 

On Sat, 11 Mar 2023 04:59:07 GMT, Chen Liang  wrote:

> Also remove redundant casts to avoid javac warnings.

Please review this minor patch introducing covariant overrides to make usage of `ClassDesc::resolveConstantDesc` and `MethodTypeDesc::resolveConstantDesc` easier.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12986#issuecomment-1480505156

From thomas.stuefe at gmail.com  Thu Mar 23 06:06:17 2023
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 23 Mar 2023 07:06:17 +0100
Subject: =?UTF-8?Q?Re=3A_Proposal=3A_track_zlib_native_memory_usage_with_NM?=
 =?UTF-8?Q?TThomas_St=C3=BCfe_thomas=2Estuefe_at_gmail=2Ecom?=
In-Reply-To: <79E98A81-0D74-47A1-93E7-B1B2B3BE6E3A@oracle.com>
References: <79E98A81-0D74-47A1-93E7-B1B2B3BE6E3A@oracle.com>
Message-ID: 

I always meant to ask, why is it that we chose to dedicate the beginning of
> the memory chunk to NMT, and not the end?
>
> If we used the end, then in this case with an unbalanced malloc/free, we
> would still be OK.
>
> The end seems more natural to me and either way we need to track the size,
> and moreover, in the current case, we need the size of the header as well.
>
>
Can't use the end, since you don't know the size of the block in free(). If
you had the size, you wouldn't need the malloc header in the first place,
since its main purpose, apart from accounting tags, is to give you the size.

Cheers, Thomas


>
> cheers
>
> >
> > (Side note: our internal tracker sidesteps this problem entirely by
> > avoiding malloc headers. Instead, it uses a hash tables to match pointers
> > with their meta information. But that has other cons and I do not plan to
> > change the way NMT works.)
> >
> > Performance-wise, instead of calling into the libc directly, we would
> call
> > into the hotspot, then into the libc. That indirection will cost some
> > cycles. If NMT is off, there does not happen much more beside the real
> > malloc call. Even NMT summary mode is very cheap. So I don't expect this
> to
> > be a problem but will run performance tests.
> >
> > --------
> >
> > My patch [1] works and can be built and tested. But the PR is still a
> work
> > in progress. I just wanted to make sure nobody generally objects to my
> work.
> >
> > Cheers, Thomas
> >
> > [1] https://github.com/openjdk/jdk/pull/10988
> > [2] https://github.com/SAP/SapMachine/wiki/SapMachine-MallocTracer
> > [3]
> https://mail.openjdk.org/pipermail/hotspot-dev/2018-November/035358.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From aturbanov at openjdk.org  Thu Mar 23 06:21:47 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 23 Mar 2023 06:21:47 GMT
Subject: RFR: 8303214: Typo in
 java.util.Collections#synchronizedNavigableMap javadoc
In-Reply-To: 
References: 
Message-ID: 

On Wed, 14 Dec 2022 17:43:08 GMT, nbauma109  wrote:

> I think this is a typo

Marked as reviewed by aturbanov (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/11679#pullrequestreview-1353917356

From liach at openjdk.org  Thu Mar 23 07:15:53 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 23 Mar 2023 07:15:53 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
Message-ID: 

On Tue, 8 Feb 2022 17:23:38 GMT, Stuart Marks  wrote:

> PR for Sequenced Collections implementation.

src/java.base/share/classes/java/util/Collections.java line 5887:

> 5885:      */
> 5886:     public static  Set newSetFromMap(Map map) {
> 5887:         if (! map.isEmpty())

Suggestion:

        if (!map.isEmpty())

src/java.base/share/classes/java/util/ReverseOrderListView.java line 75:

> 73:      */
> 74:     void checkModifiable() {
> 75:         if (! modifiable)

Suggestion:

        if (!modifiable)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1142805672
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1145708887

From duke at openjdk.org  Thu Mar 23 07:19:44 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 23 Mar 2023 07:19:44 GMT
Subject: RFR: 8303923: ZipOutStream::putEntry should include an apiNote to
 indicate that the STORED compression method should be used when
 writing directory entries [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 22 Mar 2023 23:45:43 GMT, jmehrens  wrote:

> The example code works without setting the compressed size on the entry?

Yes, this is the minimal code required and is also how the `jar` tool does it. 

The current behaviour does feel a bit underspecified though.  In the `ZipEntry` and `ZipOutputStream` documentation, `getCompressedSize` documents that: 'In the case of a stored entry, the compressed size will be the same as the uncompressed size of the entry.'

Perhaps a similar note should be addded to `ZipEntry.setCompressedSize`, documenting that this method need not be called for STORED entries.

@LanceAndersen what do you think?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12899#issuecomment-1480705313

From xgong at openjdk.org  Thu Mar 23 07:34:49 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 23 Mar 2023 07:34:49 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 22 Mar 2023 12:46:33 GMT, Quan Anh Mai  wrote:

>> Hi,
>> 
>> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, VectorShuffle is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
>> 
>> 1. Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
>> 2. Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
>> 3. Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
>> 4. Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
>> 
>> Upon these changes, a `rearrange` can emit more efficient code:
>> 
>>     var species = IntVector.SPECIES_128;
>>     var v1 = IntVector.fromArray(species, SRC1, 0);
>>     var v2 = IntVector.fromArray(species, SRC2, 0);
>>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
>> 
>>     Before:
>>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>>     vmovdqu 0x10(%r10),%xmm0
>>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byte_mask
>>                                                             ;   {external_word}
>>     vpackusdw %xmm0,%xmm0,%xmm0
>>     vpackuswb %xmm0,%xmm0,%xmm0
>>     vpmovsxbd %xmm0,%xmm3
>>     vpcmpgtd %xmm3,%xmm1,%xmm3
>>     vtestps %xmm3,%xmm3
>>     jne    0x00007fc2acb4e0d8
>>     vpmovzxbd %xmm0,%xmm0
>>     vpermd %ymm2,%ymm0,%ymm0
>>     movabs $0x751588f98,%r10            ;   {oop([I{0x0000000751588f98})}
>>     vmovdqu %xmm0,0x10(%r10)
>> 
>>     After:
>>     movabs $0x751589c78,%r10            ;   {oop([I{0x0000000751589c78})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158ac88,%r10            ;   {oop([I{0x000000075158ac88})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     vpxor  %xmm0,%xmm0,%xmm0
>>     vpcmpgtd %xmm2,%xmm0,%xmm3
>>     vtestps %xmm3,%xmm3
>>     jne    0x00007fa818b27cb1
>>     vpermd %ymm1,%ymm2,%ymm0
>>     movabs $0x751588c68,%r10            ;   {oop([I{0x0000000751588c68})}
>>     vmovdqu %xmm0,0x10(%r10)
>>     
>> Please take a look and leave reviews. Thanks a lot.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reviews

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte128Vector.java line 868:

> 866:             return (Byte128Vector) Byte128Vector.VSPECIES.dummyVector()
> 867:                     .vectorFactory(s.indices());
> 868:         }

Move the implementation details to the super class?

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteMaxVector.java line 862:

> 860:             v.convertShape(VectorOperators.B2I, species, 3)
> 861:                     .reinterpretAsInts()
> 862:                     .intoArray(a, offset + species.length() * 3);

Can we add a method like `intoIntArray()` in `ByteVector` and move these common code there? The same to other vector types.

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteMaxVector.java line 919:

> 917:                     }
> 918:                     return false;
> 919:                 }

Same as `intoArray()`. Any possible that moving this function to `ByteVector` and rename it to something like `shuffleIndicesInRange` ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1145769798
PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1145781044
PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1145782910

From sspitsyn at openjdk.org  Thu Mar 23 09:22:25 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 23 Mar 2023 09:22:25 GMT
Subject: RFR: 8304448: Kitchensink failed:
 assert(!thread->is_in_any_VTMS_transition()) failed: class prepare events are
 not allowed in any VTMS transition
Message-ID: 

The fix was suggested/provided by @AlanBateman.
Continuation should use Unsafe.compareAndSetReference rather than a VH here.
We had to change CHM and VT back to Unsafe for similar reasons.

Testing: Mach5 runs of tiers 1-6 are in progress

-------------

Commit messages:
 - 8304448: Kitchensink failed: assert(!thread->is_in_any_VTMS_transition()) failed: class prepare events are not allowed in any VTMS transition

Changes: https://git.openjdk.org/jdk/pull/13154/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13154&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304448
  Stats: 14 lines in 1 file changed: 1 ins; 10 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/13154.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13154/head:pull/13154

PR: https://git.openjdk.org/jdk/pull/13154

From mcimadamore at openjdk.org  Thu Mar 23 10:30:47 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 23 Mar 2023 10:30:47 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v8]
In-Reply-To: 
References: 
 <4JIhKmX2VnDfArfFl-1YJfoUzGGBVA5Uvd3mdpatW-s=.5d86f29e-5475-4a4a-91df-d6418356e204@github.com>
 
 <69SHPBocr-b_789_vAvfpV67J_7ZrNal8SSnAFxugyw=.a971481e-9707-4022-88bd-b80906996cc7@github.com>
 
 
Message-ID: 

On Wed, 22 Mar 2023 20:07:01 GMT, Maurizio Cimadamore  wrote:

>> Ah. True. This is true about all the MS parameters as well.
>
> Yes - although there is a distinction between passed by value and by ref. I wouldn't be surprised if we just threw NPE for by-value.

Just did a test with jshell:


jshell> Linker linker = Linker.nativeLinker();

jshell> MethodHandle handleValue = linker.downcallHandle(FunctionDescriptor.ofVoid(MemoryLayout.structLayout(ValueLayout.JAVA_INT)));
handleValue ==> MethodHandle(MemorySegment,MemorySegment)void

jshell> handleValue.invoke(MemorySegment.ofAddress(1), null);
|  Exception java.lang.NullPointerException
|        at (#5:1)


So, yes, passing `null` for a "by-value" struct issues NPEs. I also get same exception when calling a method handle which passes a struct by reference:


jshell> MethodHandle handleRef = linker.downcallHandle(FunctionDescriptor.ofVoid(ValueLayout.ADDRESS));
handleRef ==> MethodHandle(MemorySegment,MemorySegment)void

jshell> handleRef.invoke(MemorySegment.ofAddress(1), null);
|  Exception java.lang.NullPointerException
|        at (#7:1)


Given what the impl does, to be fair I don't mind the NPE (it seems a good exception to throw if we're passing a raw `null`). But we should document it at such.

It also seems like the first parameter of the downcall has somewhat better checks (but still NPEs):


jshell> handleRef.invoke(null, MemorySegment.ofAddress(1));
|  Exception java.lang.NullPointerException
|        at Objects.requireNonNull (Objects.java:233)
|        at SharedUtils.checkSymbol (SharedUtils.java:351)
|        at (#8:1)


And:


jshell> handleRef.invoke(MemorySegment.NULL, MemorySegment.ofAddress(1));
|  Exception java.lang.IllegalArgumentException: Symbol is NULL: MemorySegment{ heapBase: Optional.empty address:0 limit: 0 }
|        at SharedUtils.checkSymbol (SharedUtils.java:353)
|        at (#9:1)


I think this last case is the _only_ one where IAE is warranted - as the role of the first parameter is special, and we can't tolerate a `MemorySegment::NULL` there. For all other reference parameters, the downcall handle should just check that they are non-null, and throw if so.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1145978702

From mcimadamore at openjdk.org  Thu Mar 23 10:34:50 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 23 Mar 2023 10:34:50 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v8]
In-Reply-To: 
References: 
 <4JIhKmX2VnDfArfFl-1YJfoUzGGBVA5Uvd3mdpatW-s=.5d86f29e-5475-4a4a-91df-d6418356e204@github.com>
 
 <69SHPBocr-b_789_vAvfpV67J_7ZrNal8SSnAFxugyw=.a971481e-9707-4022-88bd-b80906996cc7@github.com>
 
 
 
Message-ID: 

On Thu, 23 Mar 2023 10:28:23 GMT, Maurizio Cimadamore  wrote:

>> Yes - although there is a distinction between passed by value and by ref. I wouldn't be surprised if we just threw NPE for by-value.
>
> Just did a test with jshell:
> 
> 
> jshell> Linker linker = Linker.nativeLinker();
> 
> jshell> MethodHandle handleValue = linker.downcallHandle(FunctionDescriptor.ofVoid(MemoryLayout.structLayout(ValueLayout.JAVA_INT)));
> handleValue ==> MethodHandle(MemorySegment,MemorySegment)void
> 
> jshell> handleValue.invoke(MemorySegment.ofAddress(1), null);
> |  Exception java.lang.NullPointerException
> |        at (#5:1)
> 
> 
> So, yes, passing `null` for a "by-value" struct issues NPEs. I also get same exception when calling a method handle which passes a struct by reference:
> 
> 
> jshell> MethodHandle handleRef = linker.downcallHandle(FunctionDescriptor.ofVoid(ValueLayout.ADDRESS));
> handleRef ==> MethodHandle(MemorySegment,MemorySegment)void
> 
> jshell> handleRef.invoke(MemorySegment.ofAddress(1), null);
> |  Exception java.lang.NullPointerException
> |        at (#7:1)
> 
> 
> Given what the impl does, to be fair I don't mind the NPE (it seems a good exception to throw if we're passing a raw `null`). But we should document it at such.
> 
> It also seems like the first parameter of the downcall has somewhat better checks (but still NPEs):
> 
> 
> jshell> handleRef.invoke(null, MemorySegment.ofAddress(1));
> |  Exception java.lang.NullPointerException
> |        at Objects.requireNonNull (Objects.java:233)
> |        at SharedUtils.checkSymbol (SharedUtils.java:351)
> |        at (#8:1)
> 
> 
> And:
> 
> 
> jshell> handleRef.invoke(MemorySegment.NULL, MemorySegment.ofAddress(1));
> |  Exception java.lang.IllegalArgumentException: Symbol is NULL: MemorySegment{ heapBase: Optional.empty address:0 limit: 0 }
> |        at SharedUtils.checkSymbol (SharedUtils.java:353)
> |        at (#9:1)
> 
> 
> I think this last case is the _only_ one where IAE is warranted - as the role of the first parameter is special, and we can't tolerate a `MemorySegment::NULL` there. For all other reference parameters, the downcall handle should just check that they are non-null, and throw if so.

The returned method handle will throw an {@link IllegalArgumentException} if the {@link MemorySegment}
representing the target address of the foreign function is the {@link MemorySegment#NULL} address.
The returned method handle will additionally throw {@link NullPointerException} if any parameter of type {@link MemorySegment} is {@code null}.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1145982159

From jpai at openjdk.org  Thu Mar 23 10:37:43 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 23 Mar 2023 10:37:43 GMT
Subject: RFR: JDK-8304557:
 java/util/concurrent/CompletableFuture/CompletableFutureOrTimeoutExceptionallyTest.java
 times out
In-Reply-To: 
References: 
 
 
 
 
 
 
 
 <4o5glI2Dk1A98RhVEwr4gGXiDUW_8gTvNZDXgtYBRc4=.1da4f942-c488-4175-977d-4b5eb23eed34@github.com>
 
Message-ID: 

On Wed, 22 Mar 2023 16:49:26 GMT, Viktor Klang  wrote:

>>> The other alternative I see would be to reach into the implementation of CompletableFuture's `Delayer`'s `ScheduledThreadPoolExecutor delayer` and make sure that it's `getQueue()` eventually goes empty.
>> 
>> From what I've seen, JDK prefers blackbox tests to whitebox tests. Even though the latter might conserve resources better and are easier to implement, they are problematic in the long run: they become an obstacle if the system under tests is modified.
>
> @pavelrappo I agree with that. I have the same experience. With that said, I have implemented a whitebox test which reaches in an monitors the task queue of the Delayer. @AlanBateman & @jaikiran any preference here?

Hello Viktor, when you say whitebox test, do you mean adding:


@modules java.base/java.util.concurrent:open

to the jtreg test definition and then using reflection within the test case to assert on the internals?

The original bug which introduced this test was about the `CompletableFuture` implementation unnecessarily holding on to an internal `Future` even after its use was done. So in order to test the fix effectively, if it means adding a `:open` to the module's package, solely in this test, then I think it's OK. I see there are existing test cases which have similar usages.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13116#discussion_r1145986367

From duke at openjdk.org  Thu Mar 23 11:43:33 2023
From: duke at openjdk.org (Viktor Klang)
Date: Thu, 23 Mar 2023 11:43:33 GMT
Subject: RFR: JDK-8304557:
 java/util/concurrent/CompletableFuture/CompletableFutureOrTimeoutExceptionallyTest.java
 times out [v2]
In-Reply-To: 
References: 
Message-ID: 

> Improves the stability of the memory leak test for CompletableFuture timeout cancellation by both reducing the count by 50% (which should still be above threshold to trigger given the ample margin set initially) as well as extending the default timeout of the test run.

Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:

  Changing the test to monitor the internals instead of trying to provoke an OOME

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13116/files
  - new: https://git.openjdk.org/jdk/pull/13116/files/a135c253..4a5dd8c8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13116&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13116&range=00-01

  Stats: 32 lines in 1 file changed: 17 ins; 0 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/13116.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13116/head:pull/13116

PR: https://git.openjdk.org/jdk/pull/13116

From duke at openjdk.org  Thu Mar 23 11:43:35 2023
From: duke at openjdk.org (Viktor Klang)
Date: Thu, 23 Mar 2023 11:43:35 GMT
Subject: RFR: JDK-8304557:
 java/util/concurrent/CompletableFuture/CompletableFutureOrTimeoutExceptionallyTest.java
 times out [v2]
In-Reply-To: 
References: 
 
 
 
 
 
 
 
 <4o5glI2Dk1A98RhVEwr4gGXiDUW_8gTvNZDXgtYBRc4=.1da4f942-c488-4175-977d-4b5eb23eed34@github.com>
 
 
Message-ID: 

On Thu, 23 Mar 2023 10:35:15 GMT, Jaikiran Pai  wrote:

>> @pavelrappo I agree with that. I have the same experience. With that said, I have implemented a whitebox test which reaches in an monitors the task queue of the Delayer. @AlanBateman & @jaikiran any preference here?
>
> Hello Viktor, when you say whitebox test, do you mean adding:
> 
> 
> @modules java.base/java.util.concurrent:open
> 
> to the jtreg test definition and then using reflection within the test case to assert on the internals?
> 
> The original bug which introduced this test was about the `CompletableFuture` implementation unnecessarily holding on to an internal `Future` even after its use was done. So in order to test the fix effectively, if it means adding a `:open` to the module's package, solely in this test, then I think it's OK. I see there are existing test cases which have similar usages.

@jaikiran Yes, see the new commit I pushed which illustrates the whitebox solution (which will also run dramatically faster than the old one) which relies on the implementation detail on how the timeouts are scheduled.

@AlanBateman @pavelrappo Does the new approach seem acceptable? ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13116#discussion_r1146054535

From jlaskey at openjdk.org  Thu Mar 23 11:49:18 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Mar 2023 11:49:18 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 22 Mar 2023 23:12:02 GMT, Chen Liang  wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Tidy javadoc
>>  - Rename StringTemplate classes
>
> src/java.base/share/classes/java/lang/StringTemplate.java line 449:
> 
>> 447:      * statically imported explicitly.
>> 448:      */
>> 449:     static final SimpleProcessor RAW = st -> st;
> 
> Should we omit the modifiers `static final`, which are implicit for all interface fields?

Already changed.

> src/java.base/share/classes/java/lang/StringTemplate.java line 455:
> 
>> 453:      * primary method {@link Processor#process(StringTemplate)} is used to validate
>> 454:      * and compose a result using a {@link StringTemplate StringTemplate's} fragments and values lists.
>> 455:      *
> 
> Paragraph break intended here?

Changed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1146060615
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1146060887

From jlaskey at openjdk.org  Thu Mar 23 11:52:45 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Mar 2023 11:52:45 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 22 Mar 2023 23:16:11 GMT, Chen Liang  wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Tidy javadoc
>>  - Rename StringTemplate classes
>
> src/java.base/share/classes/java/lang/StringTemplate.java line 550:
> 
>> 548:      * SimpleProcessor jsonProcessor = st -> new JSONObject(st.interpolate());
>> 549:      * }
>> 550:      * @implNote The Java compiler automatically imports {@link StringTemplate#STR}
> 
> Does this note belong here? And does this come with a rule in the Java Language Specification, which can be linked?

This is in the changes JLS defined in https://bugs.openjdk.org/browse/JDK-8296302 . I'll be updating the @jls links when finalized.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1146066143

From alanb at openjdk.org  Thu Mar 23 12:07:12 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 23 Mar 2023 12:07:12 GMT
Subject: RFR: JDK-8304557:
 java/util/concurrent/CompletableFuture/CompletableFutureOrTimeoutExceptionallyTest.java
 times out [v2]
In-Reply-To: 
References: 
 
 
Message-ID: <6k9g24WmZExaPRw7Uc-sneFPGRvVZ60a7g-pcdWpUiA=.5d82e987-cc64-4e57-9f9d-a4cfbbbcc752@github.com>

On Tue, 21 Mar 2023 11:56:57 GMT, Alan Bateman  wrote:

>> test/jdk/java/util/concurrent/CompletableFuture/CompletableFutureOrTimeoutExceptionallyTest.java line 28:
>> 
>>> 26:  * @bug 8303742
>>> 27:  * @summary CompletableFuture.orTimeout can leak memory if completed exceptionally
>>> 28:  * @run junit/othervm/timeout=1000 -Xmx128m CompletableFutureOrTimeoutExceptionallyTest
>> 
>> Hello Viktor, a timeout of 1000 seconds is 16 minutes. This timeout value is then multiplied by the timeout factor (which is a jtreg option) to decide the final timeout. The CI on which this was reported use a timeout factor of 4. So this would translate to a timeout of 64 minutes, which I think is extremely high (although it's just the upper bound). 
>> 
>> Perhaps you could increase this timeout to maybe 5 minutes (300 seconds) and run some tests on our CI to see if that is sufficient?
>
> If there isn't any value running this test with a debug build then you could have it skip (`@requires vm.debug == false`) to save resources.
> (fixed typo in original message)

> @AlanBateman @pavelrappo Does the new approach seem acceptable? 

I don't have a strong opinion on this. The advantage is that the test is probably sub-second as it just needs one CF to complete exceptionally.  The disadvantage is that it the test would need to be updated if the implementation changes, but it's not hard.

So good with the approach if you want. As Jai mentioned, you can use @modules to open java.base/java.util.concurrent for deep reflectively. I would probably trim the overly long lines as they currently wrap when looking at the diffs.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13116#discussion_r1146081903

From alanb at openjdk.org  Thu Mar 23 12:09:03 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 23 Mar 2023 12:09:03 GMT
Subject: RFR: 8304448: Kitchensink failed:
 assert(!thread->is_in_any_VTMS_transition()) failed: class prepare events are
 not allowed in any VTMS transition
In-Reply-To: 
References: 
Message-ID: 

On Thu, 23 Mar 2023 09:10:26 GMT, Serguei Spitsyn  wrote:

> The fix was suggested/provided by @AlanBateman.
> Continuation should use Unsafe.compareAndSetReference rather than a VH here.
> We had to change CHM and VT back to Unsafe for similar reasons.
> 
> Testing: Mach5 runs of tiers 1-6 are in progress

Yes, using VH in this code is problematic as first usage will load classes and there is also possible interaction with the method type cache.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13154#issuecomment-1481076095

From jlaskey at openjdk.org  Thu Mar 23 12:16:39 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Mar 2023 12:16:39 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: 
References: 
 
 
Message-ID: <51X9oW6MmwKpahlHg8VVULoHBgaaI6kqAAefYyfbQe8=.cec29854-1afb-4ae7-ab4b-5b4996a92411@github.com>

On Wed, 22 Mar 2023 23:23:38 GMT, Chen Liang  wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Tidy javadoc
>>  - Rename StringTemplate classes
>
> src/java.base/share/classes/java/lang/StringTemplate.java line 679:
> 
>> 677:     @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
>> 678:     @FunctionalInterface
>> 679:     public interface StringProcessor extends SimpleProcessor {
> 
> Just curious, what's the rationale of a `SimpleProcessor` or `StringProcessor` as opposed to:
> 
> static  TemplateProcessor simple(Function function) {...}
> static TemplateProcessor string(Function function) {...}
> 
> which avoids the requirement of specifying the type of the template processor local variable; users can use `var` instead.

Worth considering. Thank you.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1146091987

From jlaskey at openjdk.org  Thu Mar 23 12:20:04 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Mar 2023 12:20:04 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 23 Mar 2023 01:33:59 GMT, Chen Liang  wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Tidy javadoc
>>  - Rename StringTemplate classes
>
> src/java.base/share/classes/java/lang/runtime/TemplateRuntime.java line 204:
> 
>> 202:             Object[] values
>> 203:     ) throws Throwable {
>> 204:         List asList = Collections.unmodifiableList(new ArrayList<>(Arrays.asList(values)));
> 
> Suggestion:
> 
>         List asList = List.of(values);
> 
> For defensive copy.
> Don't think processors are harmed by the null-hostile behavior of these list, for many template implementations already use null-hostile lists.

The values list can't be null-hostile for the same reason that string concatenation can't be null-hostile. Please point to examples of null-hostile lists (other that fragments) being used in the template code. Apologies if I misinterpreted your meaning.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1146098407

From jlaskey at openjdk.org  Thu Mar 23 12:28:54 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Mar 2023 12:28:54 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 23 Mar 2023 01:45:54 GMT, Chen Liang  wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Tidy javadoc
>>  - Rename StringTemplate classes
>
> src/java.base/share/classes/java/lang/StringTemplate.java line 592:
> 
>> 590:          */
>> 591:         @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
>> 592:         public sealed interface Linkage permits FormatProcessor {
> 
> I fail to see any reason a user would call `linkage`; is there anything that's not covered by `TemplateRuntime::processStringTemplate`? And if users can't use this, this can just be relocated to one of the `jdk.internal` packages.

Linkage is unfinished business for the first preview. What we are working on is a managed construction of the BSM, a ProcessorFactory per se. The hope is that this will be flushed out for the next round.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1146110189

From jlaskey at openjdk.org  Thu Mar 23 12:24:12 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Mar 2023 12:24:12 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 23 Mar 2023 01:36:14 GMT, Chen Liang  wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Tidy javadoc
>>  - Rename StringTemplate classes
>
> src/java.base/share/classes/java/util/Digits.java line 68:
> 
>> 66:      */
>> 67:     final class DecimalDigits implements Digits {
>> 68:         private static final short[] DIGITS;
> 
> Can add `@Stable` to speed up array element access. Same for below.

Changing

> src/java.base/share/classes/java/util/FormatProcessor.java line 157:
> 
>> 155:         Objects.requireNonNull(stringTemplate);
>> 156:         String format = stringTemplateFormat(stringTemplate.fragments());
>> 157:         Object[] values = stringTemplate.values().toArray(new Object[0]);
> 
> Suggestion:
> 
>         Object[] values = stringTemplate.values().toArray();

Changing

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1146101352
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1146103101

From aturbanov at openjdk.org  Thu Mar 23 12:35:57 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 23 Mar 2023 12:35:57 GMT
Subject: RFR: JDK-8304557:
 java/util/concurrent/CompletableFuture/CompletableFutureOrTimeoutExceptionallyTest.java
 times out [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 23 Mar 2023 11:43:33 GMT, Viktor Klang  wrote:

>> Improves the stability of the memory leak test for CompletableFuture timeout cancellation by both reducing the count by 50% (which should still be above threshold to trigger given the ample margin set initially) as well as extending the default timeout of the test run.
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changing the test to monitor the internals instead of trying to provoke an OOME

Changes requested by aturbanov (Committer).

test/jdk/java/util/concurrent/CompletableFuture/CompletableFutureOrTimeoutExceptionallyTest.java line 62:

> 60:         assertTrue(delayerQueue.peek() != null);
> 61:         future.completeExceptionally(new RuntimeException("This is fine"));
> 62:         while(delayerQueue.peek() != null) {

nit
Suggestion:

        while (delayerQueue.peek() != null) {

test/jdk/java/util/concurrent/CompletableFuture/CompletableFutureOrTimeoutExceptionallyTest.java line 76:

> 74:         assertTrue(delayerQueue.peek() != null);
> 75:         future.completeExceptionally(new RuntimeException("This is fine"));
> 76:         while(delayerQueue.peek() != null) {

Suggestion:

        while (delayerQueue.peek() != null) {

-------------

PR Review: https://git.openjdk.org/jdk/pull/13116#pullrequestreview-1354517634
PR Review Comment: https://git.openjdk.org/jdk/pull/13116#discussion_r1146119198
PR Review Comment: https://git.openjdk.org/jdk/pull/13116#discussion_r1146119371

From prappo at openjdk.org  Thu Mar 23 12:36:01 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 23 Mar 2023 12:36:01 GMT
Subject: RFR: JDK-8304557:
 java/util/concurrent/CompletableFuture/CompletableFutureOrTimeoutExceptionallyTest.java
 times out [v2]
In-Reply-To: <6k9g24WmZExaPRw7Uc-sneFPGRvVZ60a7g-pcdWpUiA=.5d82e987-cc64-4e57-9f9d-a4cfbbbcc752@github.com>
References: 
 
 
 <6k9g24WmZExaPRw7Uc-sneFPGRvVZ60a7g-pcdWpUiA=.5d82e987-cc64-4e57-9f9d-a4cfbbbcc752@github.com>
Message-ID: 

On Thu, 23 Mar 2023 12:04:34 GMT, Alan Bateman  wrote:

>> If there isn't any value running this test with a debug build then you could have it skip (`@requires vm.debug == false`) to save resources.
>> (fixed typo in original message)
>
>> @AlanBateman @pavelrappo Does the new approach seem acceptable? 
> 
> I don't have a strong opinion on this. The advantage is that the test is probably sub-second as it just needs one CF to complete exceptionally.  The disadvantage is that it the test would need to be updated if the implementation changes, but it's not hard.
> 
> So good with the approach if you want. As Jai mentioned, you can use @modules to open java.base/java.util.concurrent for deep reflectively. I would probably trim the overly long lines as they currently wrap when looking at the diffs.

While the approach seems okay, it might be for the JSR 166 folk to make the final decision on it.

(Looking at Thread.sleep(). Sigh: unfortunately, BlockingQueue does not provide an option to examine its head that blocks or times out.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13116#discussion_r1146118762

From jlaskey at openjdk.org  Thu Mar 23 12:44:34 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Mar 2023 12:44:34 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: 
References: 
 
 
Message-ID: <_OQ7lbvgmuySOqu5i6NIihfPAee6VjBxoyhwv_lV7cw=.b7735595-141b-4f96-b9f4-605ecfce62aa@github.com>

On Thu, 23 Mar 2023 01:31:13 GMT, Chen Liang  wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Tidy javadoc
>>  - Rename StringTemplate classes
>
> src/java.base/share/classes/java/lang/runtime/StringTemplateImplFactory.java line 169:
> 
>> 167:      * @return StringTemplate composed from fragments and values
>> 168:      */
>> 169:     static StringTemplate newStringTemplate(List fragments, Object[] values) {
> 
> I recommend renaming this one and the above methods (taking Object[] for values) `newTrustedStringTemplate` to indicate these two trust the passed values array.

I don't disagree, I will consider.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1146131084

From alanb at openjdk.org  Thu Mar 23 12:45:09 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 23 Mar 2023 12:45:09 GMT
Subject: RFR: 8300979: Lazily initialize (byte,
 char)arr in java.io.DataInputStream
In-Reply-To: 
References: 
 <3_lOBNzij1Go_ub0Rv1BzwlKbYixthhzIahk2f0s5FE=.0398c4e6-ef51-4458-930f-0a3e301f61ba@github.com>
 
Message-ID: <5h-ZA-14phjUlmiV_1-zWnQSKDvcAsBiUlKCJ24Rzuo=.ca68d1b6-eba1-4e36-975a-5614a4c4f0bd@github.com>

On Wed, 22 Mar 2023 10:17:36 GMT, Per Minborg  wrote:

> > Nice idea. Just wonder could we do the same for `BufferedInputStream`?
> 
> I think it is doable but would require some more work as nullity is used as a "closed flag".

I would nervous about changing BIS. The buf field is a protected field so lazy creating the array would lead to sub-classes throwing NPE or assuming the stream is closed. The closed state, the subclass in Process, and changing when/where OOME might be thrown are other considerations.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13121#issuecomment-1481127986

From duke at openjdk.org  Thu Mar 23 13:01:33 2023
From: duke at openjdk.org (Viktor Klang)
Date: Thu, 23 Mar 2023 13:01:33 GMT
Subject: RFR: JDK-8304557:
 java/util/concurrent/CompletableFuture/CompletableFutureOrTimeoutExceptionallyTest.java
 times out [v2]
In-Reply-To: 
References: 
 
 
 <6k9g24WmZExaPRw7Uc-sneFPGRvVZ60a7g-pcdWpUiA=.5d82e987-cc64-4e57-9f9d-a4cfbbbcc752@github.com>
 
Message-ID: 

On Thu, 23 Mar 2023 12:32:58 GMT, Pavel Rappo  wrote:

>>> @AlanBateman @pavelrappo Does the new approach seem acceptable? 
>> 
>> I don't have a strong opinion on this. The advantage is that the test is probably sub-second as it just needs one CF to complete exceptionally.  The disadvantage is that it the test would need to be updated if the implementation changes, but it's not hard.
>> 
>> So good with the approach if you want. As Jai mentioned, you can use @modules to open java.base/java.util.concurrent for deep reflectively. I would probably trim the overly long lines as they currently wrap when looking at the diffs.
>
> While the approach seems okay, it might be for the JSR 166 folk to make the final decision on it.
> 
> (Looking at Thread.sleep(). Sigh: unfortunately, BlockingQueue does not provide an option to examine its head that blocks or times out.)

@pavelrappo `peek(timeout, unit)` would be nice :)

@AlanBateman Sounds good, I'll change to use @modules ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13116#discussion_r1146160066

From jlaskey at openjdk.org  Thu Mar 23 13:07:05 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Mar 2023 13:07:05 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v47]
In-Reply-To: 
References: 
Message-ID: 

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Review recommended changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/9ba6400d..6f95d953

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=46
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=45-46

  Stats: 36 lines in 6 files changed: 6 ins; 15 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From coffeys at openjdk.org  Thu Mar 23 13:06:45 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 23 Mar 2023 13:06:45 GMT
Subject: RFR: 8304498: JShell does not switch to raw mode when there is no
 /bin/test [v2]
In-Reply-To: <3zqgbZ1T9WHdEQxojLFpW1eJ0_iqxRnmkyGgu2YiMXw=.cb6b356a-fb3c-484c-aca3-3f09304e30c8@github.com>
References: 
 <3zqgbZ1T9WHdEQxojLFpW1eJ0_iqxRnmkyGgu2YiMXw=.cb6b356a-fb3c-484c-aca3-3f09304e30c8@github.com>
Message-ID: 

On Wed, 22 Mar 2023 18:38:08 GMT, Jan Lahoda  wrote:

>> If JShell is run on a system that does not have `/bin/test` (which is, apparently, possible for some systems, which only have `/usr/bin/test`), it won't switch the terminal into the raw mode, and the input will not work properly.
>> 
>> The proposed fix herein is to detect whether `test` existing in `/usr/bin/test`, and if yes, use that location. Use the existing `/bin/test` otherwise.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Checking the executable flags instead of running the program, as suggested.

LGTM

the test call seems to be only used in one method where JLine attempts to test the tty fd value (AFAICT) - they're hacking into java.lang.ProcessBuilder$RedirectPipeImpl for that purpose.

wonder if there's anything else the JDK libs can offer.

https://github.com/openjdk/jdk/blob/master/src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/exec/ExecTerminalProvider.java#L120

-------------

Marked as reviewed by coffeys (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13100#pullrequestreview-1354582322

From duke at openjdk.org  Thu Mar 23 13:54:46 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 23 Mar 2023 13:54:46 GMT
Subject: RFR: 8300979: Lazily initialize (byte,
 char)arr in java.io.DataInputStream [v3]
In-Reply-To: <5tQ84BWMKaCnFalikXWrEtW9X21bB-ElGw-k5B-KZTQ=.703816ac-c0b1-4e08-be7d-74f6942010a6@github.com>
References: 
 <5tQ84BWMKaCnFalikXWrEtW9X21bB-ElGw-k5B-KZTQ=.703816ac-c0b1-4e08-be7d-74f6942010a6@github.com>
Message-ID: 

On Wed, 22 Mar 2023 10:12:26 GMT, Per Minborg  wrote:

>> This PR proposed to lazily initialize the scratch arrays only if/when needed.
>
> Per Minborg 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 'dis-lazy' of https://github.com/minborg/jdk into dis-lazy
>  - Update src/java.base/share/classes/java/io/DataInputStream.java
>    
>    Co-authored-by: Eirik Bjorsnos 
>  - Merge branch 'master' into dis-lazy
>  - Remove redundant initilizers
>  - Lazily initialize (byte, char)arr in java.io.DataInputStream

I cannot explain why, but the changes suggested in this PR seem to introduce a small, but significant performance regression on the `DataInputStreamTest.readInt` benchmark:

Baseline:


Benchmark                    Mode  Cnt  Score   Error  Units
DataInputStreamTest.readInt  avgt   20  5.563 ? 0.037  us/op


PR:


Benchmark                    Mode  Cnt  Score   Error  Units
DataInputStreamTest.readInt  avgt   20  6.021 ? 0.020  us/op


The reason this puzzles me is that the `readInt` benchmark don't involve the UTF code paths at all. So why would it become slower, just because two fields are no longer initialized with the default arrays?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13121#issuecomment-1481235244

From rriggs at openjdk.org  Thu Mar 23 13:56:52 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 23 Mar 2023 13:56:52 GMT
Subject: RFR: 8303485: Replacing os.name for operating system customization
 [v5]
In-Reply-To: 
References: 
Message-ID: 

> Improvements to support OS specific customization for JDK internal use:
>  - To select values and code; allowing elimination of unused code and values
>  - Optionally evaluated by build processes, compilation, or archiving (i.e. CDS)
>  - Simple API to replace adhoc comparisons with `os.name`
>  - Clear and consistent use across build, runtime, and JDK modules
>  
> The PR includes updates within java.base to use the new API.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Group imports for jdk.internal.util

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12931/files
  - new: https://git.openjdk.org/jdk/pull/12931/files/ead84379..32ee9d4a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12931&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12931&range=03-04

  Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12931.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12931/head:pull/12931

PR: https://git.openjdk.org/jdk/pull/12931

From duke at openjdk.org  Thu Mar 23 14:03:25 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 23 Mar 2023 14:03:25 GMT
Subject: RFR: 8300979: Lazily initialize (byte,
 char)arr in java.io.DataInputStream [v3]
In-Reply-To: 
References: 
 <5tQ84BWMKaCnFalikXWrEtW9X21bB-ElGw-k5B-KZTQ=.703816ac-c0b1-4e08-be7d-74f6942010a6@github.com>
 
Message-ID: <0LX-QnYnFGHJzo0-IctXMu8NthQZvxoboQmeD3WvKpM=.21fde8d5-e7b8-4f9f-ba61-3bc2e222d025@github.com>

On Thu, 23 Mar 2023 13:51:35 GMT, Eirik Bjorsnos  wrote:

> The reason this puzzles me is that the `readInt` benchmark don't involve the UTF code paths at all. So why would it become slower, just because two fields are no longer initialized with the default arrays?

Could there be some JIT optimizations not being possible because the fields are no longer 'never null'?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13121#issuecomment-1481251028

From duke at openjdk.org  Thu Mar 23 14:13:15 2023
From: duke at openjdk.org (Viktor Klang)
Date: Thu, 23 Mar 2023 14:13:15 GMT
Subject: RFR: JDK-8304557:
 java/util/concurrent/CompletableFuture/CompletableFutureOrTimeoutExceptionallyTest.java
 times out [v3]
In-Reply-To: <6k9g24WmZExaPRw7Uc-sneFPGRvVZ60a7g-pcdWpUiA=.5d82e987-cc64-4e57-9f9d-a4cfbbbcc752@github.com>
References: 
 
 
 <6k9g24WmZExaPRw7Uc-sneFPGRvVZ60a7g-pcdWpUiA=.5d82e987-cc64-4e57-9f9d-a4cfbbbcc752@github.com>
Message-ID: 

On Thu, 23 Mar 2023 12:04:34 GMT, Alan Bateman  wrote:

>> If there isn't any value running this test with a debug build then you could have it skip (`@requires vm.debug == false`) to save resources.
>> (fixed typo in original message)
>
>> @AlanBateman @pavelrappo Does the new approach seem acceptable? 
> 
> I don't have a strong opinion on this. The advantage is that the test is probably sub-second as it just needs one CF to complete exceptionally.  The disadvantage is that it the test would need to be updated if the implementation changes, but it's not hard.
> 
> So good with the approach if you want. As Jai mentioned, you can use @modules to open java.base/java.util.concurrent for deep reflectively. I would probably trim the overly long lines as they currently wrap when looking at the diffs.

@AlanBateman @jaikiran @pavelrappo I've updated the code to use an "@modules" (thanks for the hint!) and reformatted the code slightly. I think we should be good to go here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13116#discussion_r1146258760

From jvernee at openjdk.org  Thu Mar 23 14:16:03 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 23 Mar 2023 14:16:03 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v8]
In-Reply-To: 
References: 
 <4JIhKmX2VnDfArfFl-1YJfoUzGGBVA5Uvd3mdpatW-s=.5d86f29e-5475-4a4a-91df-d6418356e204@github.com>
 
 <69SHPBocr-b_789_vAvfpV67J_7ZrNal8SSnAFxugyw=.a971481e-9707-4022-88bd-b80906996cc7@github.com>
 
 
 
 
Message-ID: 

On Thu, 23 Mar 2023 10:31:27 GMT, Maurizio Cimadamore  wrote:

>> Just did a test with jshell:
>> 
>> 
>> jshell> Linker linker = Linker.nativeLinker();
>> 
>> jshell> MethodHandle handleValue = linker.downcallHandle(FunctionDescriptor.ofVoid(MemoryLayout.structLayout(ValueLayout.JAVA_INT)));
>> handleValue ==> MethodHandle(MemorySegment,MemorySegment)void
>> 
>> jshell> handleValue.invoke(MemorySegment.ofAddress(1), null);
>> |  Exception java.lang.NullPointerException
>> |        at (#5:1)
>> 
>> 
>> So, yes, passing `null` for a "by-value" struct issues NPEs. I also get same exception when calling a method handle which passes a struct by reference:
>> 
>> 
>> jshell> MethodHandle handleRef = linker.downcallHandle(FunctionDescriptor.ofVoid(ValueLayout.ADDRESS));
>> handleRef ==> MethodHandle(MemorySegment,MemorySegment)void
>> 
>> jshell> handleRef.invoke(MemorySegment.ofAddress(1), null);
>> |  Exception java.lang.NullPointerException
>> |        at (#7:1)
>> 
>> 
>> Given what the impl does, to be fair I don't mind the NPE (it seems a good exception to throw if we're passing a raw `null`). But we should document it at such.
>> 
>> It also seems like the first parameter of the downcall has somewhat better checks (but still NPEs):
>> 
>> 
>> jshell> handleRef.invoke(null, MemorySegment.ofAddress(1));
>> |  Exception java.lang.NullPointerException
>> |        at Objects.requireNonNull (Objects.java:233)
>> |        at SharedUtils.checkSymbol (SharedUtils.java:351)
>> |        at (#8:1)
>> 
>> 
>> And:
>> 
>> 
>> jshell> handleRef.invoke(MemorySegment.NULL, MemorySegment.ofAddress(1));
>> |  Exception java.lang.IllegalArgumentException: Symbol is NULL: MemorySegment{ heapBase: Optional.empty address:0 limit: 0 }
>> |        at SharedUtils.checkSymbol (SharedUtils.java:353)
>> |        at (#9:1)
>> 
>> 
>> I think this last case is the _only_ one where IAE is warranted - as the role of the first parameter is special, and we can't tolerate a `MemorySegment::NULL` there. For all other reference parameters, the downcall handle should just check that they are non-null, and throw if so.
>
> The returned method handle will throw an {@link IllegalArgumentException} if the {@link MemorySegment}
> representing the target address of the foreign function is the {@link MemorySegment#NULL} address.
> The returned method handle will additionally throw {@link NullPointerException} if any parameter of type {@link MemorySegment} is {@code null}.

We should also NPE when the passed `SegmentAllocator` for struct returns is `null`, so for the last sentence I think this should say:


The returned method handle will additionally throw {@link NullPointerException} if any argument passed to it is {@code null}.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1146264320

From duke at openjdk.org  Thu Mar 23 14:13:14 2023
From: duke at openjdk.org (Viktor Klang)
Date: Thu, 23 Mar 2023 14:13:14 GMT
Subject: RFR: JDK-8304557:
 java/util/concurrent/CompletableFuture/CompletableFutureOrTimeoutExceptionallyTest.java
 times out [v3]
In-Reply-To: 
References: 
Message-ID: 

> Improves the stability of the memory leak test for CompletableFuture timeout cancellation by both reducing the count by 50% (which should still be above threshold to trigger given the ample margin set initially) as well as extending the default timeout of the test run.

Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:

  Adding an @modules and minor code reformatting

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13116/files
  - new: https://git.openjdk.org/jdk/pull/13116/files/4a5dd8c8..572687a0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13116&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13116&range=01-02

  Stats: 8 lines in 1 file changed: 3 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/13116.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13116/head:pull/13116

PR: https://git.openjdk.org/jdk/pull/13116

From jpai at openjdk.org  Thu Mar 23 14:30:23 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 23 Mar 2023 14:30:23 GMT
Subject: RFR: JDK-8304557:
 java/util/concurrent/CompletableFuture/CompletableFutureOrTimeoutExceptionallyTest.java
 times out [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 23 Mar 2023 14:13:14 GMT, Viktor Klang  wrote:

>> Improves the stability of the memory leak test for CompletableFuture timeout cancellation by both reducing the count by 50% (which should still be above threshold to trigger given the ample margin set initially) as well as extending the default timeout of the test run.
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding an @modules and minor code reformatting

I don't have anything else to suggest on these changes. The latest change in `572687a` looks good to me.

If it's possible and easy to do, perhaps run this latest test changes against the debug build and machine on which it previously failed, to rule out any obvious issues?

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13116#pullrequestreview-1354762439

From jlaskey at openjdk.org  Thu Mar 23 14:42:27 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Mar 2023 14:42:27 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: <51X9oW6MmwKpahlHg8VVULoHBgaaI6kqAAefYyfbQe8=.cec29854-1afb-4ae7-ab4b-5b4996a92411@github.com>
References: 
 
 
 <51X9oW6MmwKpahlHg8VVULoHBgaaI6kqAAefYyfbQe8=.cec29854-1afb-4ae7-ab4b-5b4996a92411@github.com>
Message-ID: 

On Thu, 23 Mar 2023 12:12:36 GMT, Jim Laskey  wrote:

>> src/java.base/share/classes/java/lang/StringTemplate.java line 679:
>> 
>>> 677:     @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
>>> 678:     @FunctionalInterface
>>> 679:     public interface StringProcessor extends SimpleProcessor {
>> 
>> Just curious, what's the rationale of a `SimpleProcessor` or `StringProcessor` as opposed to:
>> 
>> static  TemplateProcessor simple(Function function) {...}
>> static TemplateProcessor string(Function function) {...}
>> 
>> which avoids the requirement of specifying the type of the template processor local variable; users can use `var` instead.
>
> Worth considering. Thank you.

You can, of course, reduce this to;


interface Processor {
 
    ...
    
    static  StringTemplate.Processor of(Function function) {
        return function::apply;
    }
    
    ...

}


since String is just a type. This proposal has merit and worth some thought. -2 interfaces, +1 method.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1146303119

From duke at openjdk.org  Thu Mar 23 14:47:03 2023
From: duke at openjdk.org (Viktor Klang)
Date: Thu, 23 Mar 2023 14:47:03 GMT
Subject: RFR: JDK-8304557:
 java/util/concurrent/CompletableFuture/CompletableFutureOrTimeoutExceptionallyTest.java
 times out
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 21 Mar 2023 11:02:52 GMT, Jaikiran Pai  wrote:

>> Improves the stability of the memory leak test for CompletableFuture timeout cancellation by both reducing the count by 50% (which should still be above threshold to trigger given the ample margin set initially) as well as extending the default timeout of the test run.
>
> The PR seems to be using an incorrect JBS issue id/summary. This PR should be linked with the new https://bugs.openjdk.org/browse/JDK-8304557 issue.

@jaikiran ? I'm running a test against debug builds to verify. Will integrate once that passes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13116#issuecomment-1481323888

From jlaskey at openjdk.org  Thu Mar 23 15:05:14 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Mar 2023 15:05:14 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: 
References: 
 
 
 <51X9oW6MmwKpahlHg8VVULoHBgaaI6kqAAefYyfbQe8=.cec29854-1afb-4ae7-ab4b-5b4996a92411@github.com>
 
Message-ID: 

On Thu, 23 Mar 2023 14:39:39 GMT, Jim Laskey  wrote:

>> Worth considering. Thank you.
>
> You can, of course, reduce this to;
> 
> 
> interface Processor {
>  
>     ...
>     
>     static  StringTemplate.Processor of(Function function) {
>         return function::apply;
>     }
>     
>     ...
> 
> }
> 
> var simple = Processor.of(st-> new JSONObject(st.interpolate()));
> var string = Processor.of(StringTemplate::interpolate);
> 
> 
> since String is just a type. This proposal has merit and worth some thought. -2 interfaces, +1 method.

On the flip side, for those that don't use `var`;


Processor simple = Processor.of(st-> new JSONObject(st.interpolate()));
Processor string = Processor.of(StringTemplate::interpolate);


vs.


SimpleProcessor simple = Processor.of(st-> new JSONObject(st.interpolate()));
StringProcessor string = Processor.of(StringTemplate::interpolate);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1146336461

From dfuchs at openjdk.org  Thu Mar 23 15:36:36 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 23 Mar 2023 15:36:36 GMT
Subject: RFR: 8303485: Replacing os.name for operating system customization
 [v5]
In-Reply-To: 
References: 
 
Message-ID: <8ykjfxB4LkeS2_Xpn0HEfjHATAoday-zDDgoehJKJe0=.19bddb45-8e25-4778-bb31-86b9f73def6e@github.com>

On Thu, 23 Mar 2023 13:56:52 GMT, Roger Riggs  wrote:

>> Improvements to support OS specific customization for JDK internal use:
>>  - To select values and code; allowing elimination of unused code and values
>>  - Optionally evaluated by build processes, compilation, or archiving (i.e. CDS)
>>  - Simple API to replace adhoc comparisons with `os.name`
>>  - Clear and consistent use across build, runtime, and JDK modules
>>  
>> The PR includes updates within java.base to use the new API.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Group imports for jdk.internal.util

src/java.base/share/classes/jdk/internal/util/OperatingSystem.java line 81:

> 79:      */
> 80:     AIX,
> 81:     ;

While browsing another PR I noticed that jlink also has an [OperatingSystem enum](https://github.com/openjdk/jdk/blob/master/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Platform.java#L34), which has an additional `UNKNOWN` enum constant. Would it make sense to have an `UNKNOWN` constant here too, which could also make it possible to use this enum directly with jlink too?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12931#discussion_r1146384029

From jlaskey at openjdk.org  Thu Mar 23 15:53:26 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Mar 2023 15:53:26 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: 
References: 
 
 
 <51X9oW6MmwKpahlHg8VVULoHBgaaI6kqAAefYyfbQe8=.cec29854-1afb-4ae7-ab4b-5b4996a92411@github.com>
 
 
Message-ID: <5mzBgTz3eo9ZuTM7_WLDW_Y-DC8dnn8pfSfylOAOh0o=.68b7c46c-5faf-41c5-9c0f-0033d33cb574@github.com>

On Thu, 23 Mar 2023 15:01:27 GMT, Jim Laskey  wrote:

>> You can, of course, reduce this to;
>> 
>> 
>> interface Processor {
>>  
>>     ...
>>     
>>     static  StringTemplate.Processor of(Function function) {
>>         return function::apply;
>>     }
>>     
>>     ...
>> 
>> }
>> 
>> var simple = Processor.of(st-> new JSONObject(st.interpolate()));
>> var string = Processor.of(StringTemplate::interpolate);
>> 
>> 
>> since String is just a type. This proposal has merit and worth some thought. -2 interfaces, +1 method.
>
> On the flip side, for those that don't use `var`;
> 
> 
> Processor simple = Processor.of(st-> new JSONObject(st.interpolate()));
> Processor string = Processor.of(StringTemplate::interpolate);
> 
> 
> vs.
> 
> 
> SimpleProcessor simple = st-> new JSONObject(st.interpolate());
> StringProcessor string = StringTemplate::interpolate;

It's coming back to me why we didn't do this in the first place (these projects tend to go on for months and years). `SimpleProcessor` exists because of that ugly second parameter, `E`, in `Processor`, when a majority of the time `E` will be the unchecked `RuntimeException`. `StringProcessor` exists because 90+% of template processors will produce strings. From there, we originally had `Process.of`, `SimpleProcessor.of` and `StringProcessor.of`. We realized that the `@FunctionalInterface` route was cleaner and there was no need for `of` -- keep interfaces simple. I would argue that if you are creating a template processor, it is better to expose the result type and not bury in a `var`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1146406021

From rriggs at openjdk.org  Thu Mar 23 15:55:22 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 23 Mar 2023 15:55:22 GMT
Subject: RFR: 8303485: Replacing os.name for operating system customization
 [v5]
In-Reply-To: <8ykjfxB4LkeS2_Xpn0HEfjHATAoday-zDDgoehJKJe0=.19bddb45-8e25-4778-bb31-86b9f73def6e@github.com>
References: 
 
 <8ykjfxB4LkeS2_Xpn0HEfjHATAoday-zDDgoehJKJe0=.19bddb45-8e25-4778-bb31-86b9f73def6e@github.com>
Message-ID: 

On Thu, 23 Mar 2023 15:33:59 GMT, Daniel Fuchs  wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Group imports for jdk.internal.util
>
> src/java.base/share/classes/jdk/internal/util/OperatingSystem.java line 81:
> 
>> 79:      */
>> 80:     AIX,
>> 81:     ;
> 
> While browsing another PR I noticed that jlink also has an [OperatingSystem enum](https://github.com/openjdk/jdk/blob/master/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Platform.java#L34), which has an additional `UNKNOWN` enum constant. Would it make sense to have an `UNKNOWN` constant here too, which could also make it possible to use this enum directly with jlink too?

Its not needed here. In the jlink version, that value is only used if the mapping from os.name fails.
With the new OperatingSystem enum, it is exactly one of the os's supported by the build. If there is no build support then it never gets to a runtime error.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12931#discussion_r1146408856

From rpressler at openjdk.org  Thu Mar 23 15:58:29 2023
From: rpressler at openjdk.org (Ron Pressler)
Date: Thu, 23 Mar 2023 15:58:29 GMT
Subject: RFR: 8304448: Kitchensink failed:
 assert(!thread->is_in_any_VTMS_transition()) failed: class prepare events are
 not allowed in any VTMS transition
In-Reply-To: 
References: 
Message-ID: 

On Thu, 23 Mar 2023 09:10:26 GMT, Serguei Spitsyn  wrote:

> The fix was suggested/provided by @AlanBateman.
> Continuation should use Unsafe.compareAndSetReference rather than a VH here.
> We had to change CHM and VT back to Unsafe for similar reasons.
> 
> Testing: Mach5 runs of tiers 1-6 are in progress

Marked as reviewed by rpressler (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13154#pullrequestreview-1354956634

From forax at openjdk.org  Thu Mar 23 16:38:43 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Thu, 23 Mar 2023 16:38:43 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: <5mzBgTz3eo9ZuTM7_WLDW_Y-DC8dnn8pfSfylOAOh0o=.68b7c46c-5faf-41c5-9c0f-0033d33cb574@github.com>
References: 
 
 
 <51X9oW6MmwKpahlHg8VVULoHBgaaI6kqAAefYyfbQe8=.cec29854-1afb-4ae7-ab4b-5b4996a92411@github.com>
 
 
 <5mzBgTz3eo9ZuTM7_WLDW_Y-DC8dnn8pfSfylOAOh0o=.68b7c46c-5faf-41c5-9c0f-0033d33cb574@github.com>
Message-ID: 

On Thu, 23 Mar 2023 15:49:37 GMT, Jim Laskey  wrote:

>> On the flip side, for those that don't use `var`;
>> 
>> 
>> Processor simple = Processor.of(st-> new JSONObject(st.interpolate()));
>> Processor string = Processor.of(StringTemplate::interpolate);
>> 
>> 
>> vs.
>> 
>> 
>> SimpleProcessor simple = st-> new JSONObject(st.interpolate());
>> StringProcessor string = StringTemplate::interpolate;
>
> It's coming back to me why we didn't do this in the first place (these projects tend to go on for months and years). `SimpleProcessor` exists because of that ugly second parameter, `E`, in `Processor`, when a majority of the time `E` will be the unchecked `RuntimeException`. `StringProcessor` exists because 90+% of template processors will produce strings. From there, we originally had `Process.of`, `SimpleProcessor.of` and `StringProcessor.of`. We realized that the `@FunctionalInterface` route was cleaner and there was no need for `of` -- keep interfaces simple. I would argue that if you are creating a template processor, it is better to expose the result type and not bury in a `var`.

Not a lot of people will write a processor and among those few, most of them will create a class that implement `Processor` (to have a proper name and a place to put documentation) so providing several reified names (`SimpleProcessor` and `StringProcessor`) is not that useful for implementers. For users, it's not something necessary to understand how processors work or how a specific processor should be used.

It looks like a loose loose situation for me, implementers do not need them and users will find them confusing (especially the difference between a processor and a simple processor).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1146450918

From liach at openjdk.org  Thu Mar 23 16:39:16 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 23 Mar 2023 16:39:16 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 20 Mar 2023 20:31:46 GMT, Jim Laskey  wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Tidy javadoc
>  - Rename StringTemplate classes

src/java.base/share/classes/java/lang/runtime/StringTemplateImplFactory.java line 182:

> 180:      */
> 181:     static StringTemplate newStringTemplate(List fragments, List values) {
> 182:         return new SimpleStringTemplate(List.copyOf(fragments), toList(values.stream().toArray()));

Suggestion:

        return new SimpleStringTemplate(List.copyOf(fragments), values.stream().toList());

per https://github.com/openjdk/jdk/pull/10889#discussion_r1146455491

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1146462702

From forax at openjdk.org  Thu Mar 23 16:39:44 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Thu, 23 Mar 2023 16:39:44 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Thu, 23 Mar 2023 12:17:55 GMT, Jim Laskey  wrote:

>> src/java.base/share/classes/java/lang/runtime/TemplateRuntime.java line 204:
>> 
>>> 202:             Object[] values
>>> 203:     ) throws Throwable {
>>> 204:         List asList = Collections.unmodifiableList(new ArrayList<>(Arrays.asList(values)));
>> 
>> Suggestion:
>> 
>>         List asList = List.of(values);
>> 
>> For defensive copy.
>> Don't think processors are harmed by the null-hostile behavior of these list, for many template implementations already use null-hostile lists.
>
> The values list can't be null-hostile for the same reason that string concatenation can't be null-hostile. Please point to examples of null-hostile lists (other that fragments) being used in the template code. Apologies if I misinterpreted your meaning.

There is a trick to do a defensive copy in case the list can contains a null, you can use `stream.toList()`,
so

  List asList = Arrays.stream(values).toList();

is what you are looking for.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1146455491

From mchung at openjdk.org  Thu Mar 23 16:47:35 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 23 Mar 2023 16:47:35 GMT
Subject: RFR: 8304691: Remove jlink --post-process-path option [v4]
In-Reply-To: <4fCKeyyqvizyiyJQUGZSqLnsK7gkW9toFgdncrpXj2A=.f4b5e4f6-31c7-40a9-854e-834c1c04fc26@github.com>
References: 
 <4fCKeyyqvizyiyJQUGZSqLnsK7gkW9toFgdncrpXj2A=.f4b5e4f6-31c7-40a9-854e-834c1c04fc26@github.com>
Message-ID: 

On Thu, 23 Mar 2023 01:08:43 GMT, Ian Graves  wrote:

>> Removing the hidden `jlink --post-process-path` option.
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removing post process opt reference

test/jdk/tools/lib/tests/JImageGenerator.java line 719:

> 717:         }
> 718: 
> 719:         public Result callPostProcess() {

`test/jdk/tools/lib/tests/Helper.java` references this deleted method.   jlink tests should fail compilation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13126#discussion_r1146457543

From lancea at openjdk.org  Thu Mar 23 16:49:56 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 23 Mar 2023 16:49:56 GMT
Subject: RFR: 8303923: ZipOutStream::putEntry should include an apiNote to
 indicate that the STORED compression method should be used when
 writing directory entries [v3]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Thu, 23 Mar 2023 07:16:32 GMT, Eirik Bjorsnos  wrote:

> > The example code works without setting the compressed size on the entry?
> 
> Yes, this is the minimal code required and is also how the `jar` tool does it.
> 
> The current behaviour does feel a bit underspecified though. In the `ZipEntry` and `ZipOutputStream` documentation, `getCompressedSize` documents that: 'In the case of a stored entry, the compressed size will be the same as the uncompressed size of the entry.'
> 
> Perhaps a similar note should be addded to `ZipEntry.setCompressedSize`, documenting that this method need not be called for STORED entries.
> 
> @LanceAndersen what do you think?

More thought needs to be given to a clarification as any validation of the ZipEntry values once set are  done in ZipOutPutStream.  There is some validation done in ZipEntry::setSize and ZipEntry::setCRC but  nothing to validate the note you point out in ZipEntry::getCompressedSize.

So yes, we should probably add further clarification but lets address as a separate issue

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12899#issuecomment-1481532491

From duke at openjdk.org  Thu Mar 23 16:56:17 2023
From: duke at openjdk.org (Michael Osipov)
Date: Thu, 23 Mar 2023 16:56:17 GMT
Subject: RFR: 8303485: Replacing os.name for operating system customization
 [v5]
In-Reply-To: 
References: 
 
 <8ykjfxB4LkeS2_Xpn0HEfjHATAoday-zDDgoehJKJe0=.19bddb45-8e25-4778-bb31-86b9f73def6e@github.com>
 
Message-ID: 

On Thu, 23 Mar 2023 15:51:48 GMT, Roger Riggs  wrote:

>> src/java.base/share/classes/jdk/internal/util/OperatingSystem.java line 81:
>> 
>>> 79:      */
>>> 80:     AIX,
>>> 81:     ;
>> 
>> While browsing another PR I noticed that jlink also has an [OperatingSystem enum](https://github.com/openjdk/jdk/blob/master/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Platform.java#L34), which has an additional `UNKNOWN` enum constant. Would it make sense to have an `UNKNOWN` constant here too, which could also make it possible to use this enum directly with jlink too?
>
> Its not needed here. In the jlink version, that value is only used if the mapping from os.name fails.
> With the new OperatingSystem enum, it is exactly one of the os's supported by the build. If there is no build support then it never gets to a runtime error.

Isn't the convention to have enum values uppercase?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12931#discussion_r1146490982

From igraves at openjdk.org  Thu Mar 23 16:56:33 2023
From: igraves at openjdk.org (Ian Graves)
Date: Thu, 23 Mar 2023 16:56:33 GMT
Subject: RFR: 8304691: Remove jlink --post-process-path option [v5]
In-Reply-To: 
References: 
Message-ID: 

> Removing the hidden `jlink --post-process-path` option.

Ian Graves has updated the pull request incrementally with one additional commit since the last revision:

  Removing last bits of post process test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13126/files
  - new: https://git.openjdk.org/jdk/pull/13126/files/e1af1d5e..70299e88

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13126&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13126&range=03-04

  Stats: 9 lines in 1 file changed: 0 ins; 9 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13126.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13126/head:pull/13126

PR: https://git.openjdk.org/jdk/pull/13126

From asotona at openjdk.org  Thu Mar 23 17:06:22 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 23 Mar 2023 17:06:22 GMT
Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator
 to use the Classfile API to generate proxy classes [v11]
In-Reply-To: 
References: 
Message-ID: 

> java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes and this patch converts it to use Classfile API.
> 
> Please review.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  StackMapGenerator performance improvements

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10991/files
  - new: https://git.openjdk.org/jdk/pull/10991/files/2787185c..ff79658a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10991&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10991&range=09-10

  Stats: 44 lines in 1 file changed: 18 ins; 7 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/10991.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10991/head:pull/10991

PR: https://git.openjdk.org/jdk/pull/10991

From jlaskey at openjdk.org  Thu Mar 23 17:09:14 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Mar 2023 17:09:14 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 23 Mar 2023 16:30:42 GMT, Chen Liang  wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Tidy javadoc
>>  - Rename StringTemplate classes
>
> src/java.base/share/classes/java/lang/runtime/StringTemplateImplFactory.java line 182:
> 
>> 180:      */
>> 181:     static StringTemplate newStringTemplate(List fragments, List values) {
>> 182:         return new SimpleStringTemplate(List.copyOf(fragments), toList(values.stream().toArray()));
> 
> Suggestion:
> 
>         return new SimpleStringTemplate(List.copyOf(fragments), values.stream().toList());
> 
> per https://github.com/openjdk/jdk/pull/10889#discussion_r1146455491

Changed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1146507522

From jlaskey at openjdk.org  Thu Mar 23 17:09:16 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Mar 2023 17:09:16 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Thu, 23 Mar 2023 16:25:22 GMT, R?mi Forax  wrote:

>> The values list can't be null-hostile for the same reason that string concatenation can't be null-hostile. Please point to examples of null-hostile lists (other that fragments) being used in the template code. Apologies if I misinterpreted your meaning.
>
> There is a trick to do a defensive copy in case the list can contains a null, you can use `stream.toList()`,
> so
> 
>   List asList = Arrays.stream(values).toList();
> 
> is what you are looking for.

Changed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1146507389

From jlaskey at openjdk.org  Thu Mar 23 17:12:37 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Mar 2023 17:12:37 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v48]
In-Reply-To: 
References: 
Message-ID: 

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Clean up list construction

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/6f95d953..96752c64

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=47
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=46-47

  Stats: 12 lines in 2 files changed: 4 ins; 5 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Thu Mar 23 17:24:54 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Mar 2023 17:24:54 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: 
References: 
 
 
 <51X9oW6MmwKpahlHg8VVULoHBgaaI6kqAAefYyfbQe8=.cec29854-1afb-4ae7-ab4b-5b4996a92411@github.com>
 
 
 <5mzBgTz3eo9ZuTM7_WLDW_Y-DC8dnn8pfSfylOAOh0o=.68b7c46c-5faf-41c5-9c0f-0033d33cb574@github.com>
 
Message-ID: 

On Thu, 23 Mar 2023 16:21:56 GMT, R?mi Forax  wrote:

>> It's coming back to me why we didn't do this in the first place (these projects tend to go on for months and years). `SimpleProcessor` exists because of that ugly second parameter, `E`, in `Processor`, when a majority of the time `E` will be the unchecked `RuntimeException`. `StringProcessor` exists because 90+% of template processors will produce strings. From there, we originally had `Process.of`, `SimpleProcessor.of` and `StringProcessor.of`. We realized that the `@FunctionalInterface` route was cleaner and there was no need for `of` -- keep interfaces simple. I would argue that if you are creating a template processor, it is better to expose the result type and not bury in a `var`.
>
> Not a lot of people will write a processor and among those few, most of them will create a class that implement `Processor` (to have a proper name and a place to put documentation) so providing several reified names (`SimpleProcessor` and `StringProcessor`) is not that useful for implementers. For users, it's not something necessary to understand how processors work or how a specific processor should be used.
> 
> It looks like a loose loose situation for me, implementers do not need them and users will find them confusing (especially the difference between a processor and a simple processor).

"Not a lot of people will write a processor" I am not as confident as you. Once the cat is out of the bag that you can do magic (pending Guide to String Templates), processors will become a common idiom for designating string literals, especially text blocks.

But, I do agree that a majority will do old school classes with `process` methods along with several supporting methods. On the other  hand, the API itself uses function interfaces to define STR and RAW. I guess I'll have to do a pro/con chart.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1146528863

From mchung at openjdk.org  Thu Mar 23 17:34:20 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 23 Mar 2023 17:34:20 GMT
Subject: RFR: 8304691: Remove jlink --post-process-path option [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 23 Mar 2023 16:56:33 GMT, Ian Graves  wrote:

>> Removing the hidden `jlink --post-process-path` option.
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removing last bits of post process test

Good to see this code deletion.  Looks good.

-------------

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13126#pullrequestreview-1355155346

From darcy at openjdk.org  Thu Mar 23 17:54:13 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 23 Mar 2023 17:54:13 GMT
Subject: RFR: 8294137: Review running times of java.math tests [v3]
In-Reply-To: 
References: <-dxso8siPUKzTOOKkoA5_2EAn7ACb_XJSYdQ_Af-4_I=.2e9f8478-f224-491e-a299-c59f9f373ff2@github.com>
 
Message-ID: 

On Fri, 17 Mar 2023 15:18:07 GMT, Brian Burkhalter  wrote:

>> Break up `BigIntegerTest` and `SymmetricRangeTests` into subsets which are run quasi-randomly as a function of second within the minute at the time the test is running. `LargeValueExceptions` does not appear amenable to this treatment.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8303269: Add a means to run all subtests if desired

Looks okay -- if in the future there is a more general mechanism to support this kind of sub-setting the test should be transitioned to use that.

-------------

Marked as reviewed by darcy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/12819#pullrequestreview-1355207115

From bpb at openjdk.org  Thu Mar 23 18:04:30 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 23 Mar 2023 18:04:30 GMT
Subject: Integrated: 8294137: Review running times of java.math tests
In-Reply-To: <-dxso8siPUKzTOOKkoA5_2EAn7ACb_XJSYdQ_Af-4_I=.2e9f8478-f224-491e-a299-c59f9f373ff2@github.com>
References: <-dxso8siPUKzTOOKkoA5_2EAn7ACb_XJSYdQ_Af-4_I=.2e9f8478-f224-491e-a299-c59f9f373ff2@github.com>
Message-ID: 

On Wed, 1 Mar 2023 23:36:04 GMT, Brian Burkhalter  wrote:

> Break up `BigIntegerTest` and `SymmetricRangeTests` into subsets which are run quasi-randomly as a function of second within the minute at the time the test is running. `LargeValueExceptions` does not appear amenable to this treatment.

This pull request has now been integrated.

Changeset: 51035a75
Author:    Brian Burkhalter 
URL:       https://git.openjdk.org/jdk/commit/51035a75e493f64b26f78e7fc87f6f6e536e4f56
Stats:     132 lines in 3 files changed: 53 ins; 8 del; 71 mod

8294137: Review running times of java.math tests

Reviewed-by: darcy

-------------

PR: https://git.openjdk.org/jdk/pull/12819

From mchung at openjdk.org  Thu Mar 23 18:33:37 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 23 Mar 2023 18:33:37 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v12]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 23 Mar 2023 01:46:47 GMT, Jaikiran Pai  wrote:

>> Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8206890?
>> 
>> The `jlink` command allows a `--endian` option to specify the byte order in the generated image. Before this change, when such a image was being launched, the code would assume the byte order in the image to be the native order of the host where the image is being launched. That would result in failure to launch java, as noted in the linked issue.
>> 
>> The commit in this PR, changes relevant places to not assume native order and instead determine the byte order by reading the magic bytes in the image file's header content.
>> 
>> A new jtreg test has been added which reproduces the issue and verifies the fix.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ARM is 32 bit as per platform.m4 in OpenJDK build

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 823:

> 821:             if (order != null) {
> 822:                 this.order = order;
> 823:                 String targetPlatformVal = readJavaBaseTargetPlatform(cf);

Thanks for the update.

This should also do the fast-path check `isJavaBaseFromCurrentPlatform(javaBasePath)` as in line 838-860.  I suggest to refactor line 838-860 to return the target platform (either runtime platform or from java.base in the given module path).   

I also suggest to include `endianness` in the `Platform` record class.

I sent you a patch offline with these suggestions.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/11943#discussion_r1146654036

From jlu at openjdk.org  Thu Mar 23 19:16:30 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 23 Mar 2023 19:16:30 GMT
Subject: RFR: 8304761: Update IANA Language Subtag Registry to Version
 2023-03-22
Message-ID: 

Update IANA LSR to 2023-03-22 [update](https://mm.icann.org/pipermail/ietf-languages-announcements/2023-March/000085.html). Add all new preferred languages to `ACCEPT_LANGUAGES` except `gu`.

-------------

Commit messages:
 - Update ACCEPT_LANGUAGE and EXPECTED_RANGE_LIST
 - Test headers
 - Lsr changes

Changes: https://git.openjdk.org/jdk/pull/13165/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13165&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304761
  Stats: 171 lines in 2 files changed: 155 ins; 1 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/13165.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13165/head:pull/13165

PR: https://git.openjdk.org/jdk/pull/13165

From stsypanov at openjdk.org  Thu Mar 23 19:17:26 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Thu, 23 Mar 2023 19:17:26 GMT
Subject: RFR: 8304745: Lazily initialize byte[] in java.io.BufferedInputStream
Message-ID: 

By default `BufferedInputStream` is constructed with internal buffer with capacity 8192. In some cases this buffer is never used, e.g. when we call `IS.readNBytes()` or `IS.readAllBytes()` (relying on `BIS.read1()`) or when `BufferedInputStream` is cascaded.

-------------

Commit messages:
 - 8304745: Polishing
 - 8304745: Revert JavaDoc change
 - 8304745: Adjust JavaDoc
 - 8304745: Preserve behaviour of subclasses
 - 8304745: Rework existing solution
 - 8304745: Fix test
 - 8304745: Fix build
 - 8304745: Lazily initialize byte[] in j.i.BufferedInputStream
 - 8304745: Lazily initialize byte[] in j.i.BufferedInputStream

Changes: https://git.openjdk.org/jdk/pull/13150/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13150&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304745
  Stats: 19 lines in 1 file changed: 10 ins; 1 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/13150.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13150/head:pull/13150

PR: https://git.openjdk.org/jdk/pull/13150

From liach at openjdk.org  Thu Mar 23 19:17:29 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 23 Mar 2023 19:17:29 GMT
Subject: RFR: 8304745: Lazily initialize byte[] in
 java.io.BufferedInputStream
In-Reply-To: 
References: 
Message-ID: 

On Wed, 22 Mar 2023 20:34:08 GMT, Sergey Tsypanov  wrote:

> By default `BufferedInputStream` is constructed with internal buffer with capacity 8192. In some cases this buffer is never used, e.g. when we call `IS.readNBytes()` or `IS.readAllBytes()` (relying on `BIS.read1()`) or when `BufferedInputStream` is cascaded.

Also, you should document `getBufIfOpen` to indicate that if a caller simply wants to ensure open, they should call `getInIfOpen` instead.

With the `getClass() == BufferedInputStream.class` check, the impact to subclasses is totally averted, and most BufferedInputStream usages, I believe, do not involve subclasses. And this patch should be acceptable without compatibility concerns.

Marked as reviewed by liach (Author).

This change exposes the `CLOSED` array and modifies the specification for `buf`, both of which are protected and thus public APIs. Having the subclass-accessible `buf` `null` after constructor is executed may significantly affect subclasses that reuse such a buffer.

I mean that additional API exposure is acceptable and backward compatible, but the previous contract to subclasses that the protected `buf` is initialized after superclass constructor execution breaks. Before this change proceeds, we have to check how many subclasses of `BufferedInputStream` access this `buf` in a wide range of libraries and evaluate the impact, which I anticipate to be huge.

A slightly less impactful approach would be sharing a `byte[0]` for a newly initialized state, like in ArrayList, so users anticipating a closed `BufferedInputStream` to have a null `buf` will still work. But users anticipating a usable buf after constructor will still break: for instance, since `getBufIfOpen` is private but the `buf` field it uses is protected, nothing prevents subclasses from copying the same implementation over; and the same implementation will stop working with this new optimization.

src/java.base/share/classes/java/io/BufferedInputStream.java line 78:

> 76:     private final InternalLock lock;
> 77: 
> 78:     /**

These should be reverted, now that the subclasses will see the same behavior as before.

src/java.base/share/classes/java/io/BufferedInputStream.java line 211:

> 209:             throw new IllegalArgumentException("Buffer size <= 0");
> 210:         }
> 211:         buf = new byte[0];

Two recommendations:
1. This `new byte[0]` can be safely shared, so I recommend you to put it in a static final field to avoid reallocation
2. The subclass compatibility can be retained by:
Suggestion:

        buf = (getClass() == BufferedInputStream.class) ? new byte[0] : new byte[size];

src/java.base/share/classes/java/io/BufferedInputStream.java line 216:

> 214:             throw new IllegalArgumentException("Buffer size <= 0");
> 215:         }
> 216:         buf = getClass() == BufferedInputStream.class ? EMPTY : new byte[size];

Actually, you can merge this `getClass()` check with the one below for locks.

src/java.base/share/classes/java/io/BufferedInputStream.java line 217:

> 215:         }
> 216:         this.size = size;
> 217:         // use monitors when BufferedInputStream is sub-classed

Maybe update this comment to be like:
Suggestion:

        // keep using monitors and initializing buf when BufferedInputStream is sub-classed
        // for compatibility

-------------

PR Review: https://git.openjdk.org/jdk/pull/13150#pullrequestreview-1354736052
PR Review: https://git.openjdk.org/jdk/pull/13150#pullrequestreview-1354917871
PR Comment: https://git.openjdk.org/jdk/pull/13150#issuecomment-1480363127
PR Comment: https://git.openjdk.org/jdk/pull/13150#issuecomment-1480711123
PR Review Comment: https://git.openjdk.org/jdk/pull/13150#discussion_r1146272964
PR Review Comment: https://git.openjdk.org/jdk/pull/13150#discussion_r1146268740
PR Review Comment: https://git.openjdk.org/jdk/pull/13150#discussion_r1146390661
PR Review Comment: https://git.openjdk.org/jdk/pull/13150#discussion_r1146465984

From stsypanov at openjdk.org  Thu Mar 23 19:17:39 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Thu, 23 Mar 2023 19:17:39 GMT
Subject: RFR: 8304745: Lazily initialize byte[] in
 java.io.BufferedInputStream
In-Reply-To: <3F-qgk-VK9P7eNYFKil4UvfG-XXf74a5QWfIq8A5qtM=.ca948361-c6e7-4a69-9de7-97aeff07265c@github.com>
References: 
 
 <3F-qgk-VK9P7eNYFKil4UvfG-XXf74a5QWfIq8A5qtM=.ca948361-c6e7-4a69-9de7-97aeff07265c@github.com>
Message-ID: 

On Thu, 23 Mar 2023 14:51:40 GMT, Sergey Tsypanov  wrote:

>> src/java.base/share/classes/java/io/BufferedInputStream.java line 211:
>> 
>>> 209:             throw new IllegalArgumentException("Buffer size <= 0");
>>> 210:         }
>>> 211:         buf = new byte[0];
>> 
>> Two recommendations:
>> 1. This `new byte[0]` can be safely shared, so I recommend you to put it in a static final field to avoid reallocation
>> 2. The subclass compatibility can be retained by:
>> Suggestion:
>> 
>>         buf = (getClass() == BufferedInputStream.class) ? new byte[0] : new byte[size];
>
> Good point, done!

Btw, maybe it'd be better to rename `getBufIfOpen()` into e.g. `getBuffer()` to make it less confusing?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13150#discussion_r1146344036

From liach at openjdk.org  Thu Mar 23 19:17:40 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 23 Mar 2023 19:17:40 GMT
Subject: RFR: 8304745: Lazily initialize byte[] in
 java.io.BufferedInputStream
In-Reply-To: 
References: 
 
 <3F-qgk-VK9P7eNYFKil4UvfG-XXf74a5QWfIq8A5qtM=.ca948361-c6e7-4a69-9de7-97aeff07265c@github.com>
 
Message-ID: 

On Thu, 23 Mar 2023 15:06:46 GMT, Sergey Tsypanov  wrote:

>> Good point, done!
>
> Btw, maybe it'd be better to rename `getBufIfOpen()` into e.g. `getBuffer()` to make it less confusing?

I'd say feel free to rename these private methods. I believe this patch is mature enough for public review.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13150#discussion_r1146467209

From stsypanov at openjdk.org  Thu Mar 23 19:17:33 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Thu, 23 Mar 2023 19:17:33 GMT
Subject: RFR: 8304745: Lazily initialize byte[] in
 java.io.BufferedInputStream
In-Reply-To: 
References: 
 
Message-ID: <3F-qgk-VK9P7eNYFKil4UvfG-XXf74a5QWfIq8A5qtM=.ca948361-c6e7-4a69-9de7-97aeff07265c@github.com>

On Wed, 22 Mar 2023 23:01:32 GMT, Chen Liang  wrote:

> This change exposes the CLOSED array

Otherwise we have to either call `getInIfOpen()`/`getBufIfOpen` making them at least protected or dodge this somehow via `SharedSecrets`

> I mean that additional API exposure is acceptable and backward compatible, but the previous contract to subclasses that the protected `buf` is initialized after superclass constructor execution breaks. Before this change proceeds, we have to check how many subclasses of `BufferedInputStream` access this `buf` in a wide range of libraries and evaluate the impact, which I anticipate to be huge.
> 
> A slightly less impactful approach would be sharing a `byte[0]` for a newly initialized state, like in ArrayList, so users anticipating a closed `BufferedInputStream` to have a null `buf` will still work. But users anticipating a usable buf after constructor will still break: for instance, since `getBufIfOpen` is private but the `buf` field it uses is protected, nothing prevents subclasses from copying the same implementation over; and the same implementation will stop working with this new optimization.

@liach with your approach tests are green

> src/java.base/share/classes/java/io/BufferedInputStream.java line 78:
> 
>> 76:     private final InternalLock lock;
>> 77: 
>> 78:     /**
> 
> These should be reverted, now that the subclasses will see the same behavior as before.

But it's just comment clean up

> src/java.base/share/classes/java/io/BufferedInputStream.java line 211:
> 
>> 209:             throw new IllegalArgumentException("Buffer size <= 0");
>> 210:         }
>> 211:         buf = new byte[0];
> 
> Two recommendations:
> 1. This `new byte[0]` can be safely shared, so I recommend you to put it in a static final field to avoid reallocation
> 2. The subclass compatibility can be retained by:
> Suggestion:
> 
>         buf = (getClass() == BufferedInputStream.class) ? new byte[0] : new byte[size];

Good point, done!

> src/java.base/share/classes/java/io/BufferedInputStream.java line 216:
> 
>> 214:             throw new IllegalArgumentException("Buffer size <= 0");
>> 215:         }
>> 216:         buf = getClass() == BufferedInputStream.class ? EMPTY : new byte[size];
> 
> Actually, you can merge this `getClass()` check with the one below for locks.

Done

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13150#issuecomment-1480701591
PR Comment: https://git.openjdk.org/jdk/pull/13150#issuecomment-1481236336
PR Review Comment: https://git.openjdk.org/jdk/pull/13150#discussion_r1146316757
PR Review Comment: https://git.openjdk.org/jdk/pull/13150#discussion_r1146321335
PR Review Comment: https://git.openjdk.org/jdk/pull/13150#discussion_r1146414668

From stsypanov at openjdk.org  Thu Mar 23 19:17:37 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Thu, 23 Mar 2023 19:17:37 GMT
Subject: RFR: 8304745: Lazily initialize byte[] in
 java.io.BufferedInputStream
In-Reply-To: 
References: 
 
 <3F-qgk-VK9P7eNYFKil4UvfG-XXf74a5QWfIq8A5qtM=.ca948361-c6e7-4a69-9de7-97aeff07265c@github.com>
 
Message-ID: 

On Thu, 23 Mar 2023 15:18:54 GMT, Chen Liang  wrote:

>> But it's just comment clean up
>
> No? The one above is API specification (Javadoc); the one below is comments.

Right, I'll revert it

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13150#discussion_r1146370513

From liach at openjdk.org  Thu Mar 23 19:17:36 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 23 Mar 2023 19:17:36 GMT
Subject: RFR: 8304745: Lazily initialize byte[] in
 java.io.BufferedInputStream
In-Reply-To: <3F-qgk-VK9P7eNYFKil4UvfG-XXf74a5QWfIq8A5qtM=.ca948361-c6e7-4a69-9de7-97aeff07265c@github.com>
References: 
 
 <3F-qgk-VK9P7eNYFKil4UvfG-XXf74a5QWfIq8A5qtM=.ca948361-c6e7-4a69-9de7-97aeff07265c@github.com>
Message-ID: 

On Thu, 23 Mar 2023 14:48:32 GMT, Sergey Tsypanov  wrote:

>> src/java.base/share/classes/java/io/BufferedInputStream.java line 78:
>> 
>>> 76:     private final InternalLock lock;
>>> 77: 
>>> 78:     /**
>> 
>> These should be reverted, now that the subclasses will see the same behavior as before.
>
> But it's just comment clean up

No? The one above is API specification (Javadoc); the one below is comments.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13150#discussion_r1146361942

From igraves at openjdk.org  Thu Mar 23 19:20:52 2023
From: igraves at openjdk.org (Ian Graves)
Date: Thu, 23 Mar 2023 19:20:52 GMT
Subject: Integrated: 8304691: Remove jlink --post-process-path option
In-Reply-To: 
References: 
Message-ID: 

On Tue, 21 Mar 2023 20:39:38 GMT, Ian Graves  wrote:

> Removing the hidden `jlink --post-process-path` option.

This pull request has now been integrated.

Changeset: af0504e3
Author:    Ian Graves 
URL:       https://git.openjdk.org/jdk/commit/af0504e3f3de4ba40fa6187e48b584854b8e41f3
Stats:     247 lines in 9 files changed: 0 ins; 247 del; 0 mod

8304691: Remove jlink --post-process-path option

Reviewed-by: mchung

-------------

PR: https://git.openjdk.org/jdk/pull/13126

From stsypanov at openjdk.org  Thu Mar 23 19:27:04 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Thu, 23 Mar 2023 19:27:04 GMT
Subject: RFR: 8304745: Lazily initialize byte[] in
 java.io.BufferedInputStream [v2]
In-Reply-To: 
References: 
Message-ID: 

> By default `BufferedInputStream` is constructed with internal buffer with capacity 8192. In some cases this buffer is never used, e.g. when we call `IS.readNBytes()` or `IS.readAllBytes()` (relying on `BIS.read1()`) or when `BufferedInputStream` is cascaded.

Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/io/BufferedInputStream.java
  
  Co-authored-by: liach <7806504+liach at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13150/files
  - new: https://git.openjdk.org/jdk/pull/13150/files/8a7577c3..8e493a9d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13150&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13150&range=00-01

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13150.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13150/head:pull/13150

PR: https://git.openjdk.org/jdk/pull/13150

From duke at openjdk.org  Thu Mar 23 19:43:49 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 23 Mar 2023 19:43:49 GMT
Subject: RFR: 8304745: Lazily initialize byte[] in
 java.io.BufferedInputStream [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 23 Mar 2023 19:27:04 GMT, Sergey Tsypanov  wrote:

>> By default `BufferedInputStream` is constructed with internal buffer with capacity 8192. In some cases this buffer is never used, e.g. when we call `IS.readNBytes()` or `IS.readAllBytes()` (relying on `BIS.read1()`) or when `BufferedInputStream` is cascaded.
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/io/BufferedInputStream.java
>   
>   Co-authored-by: liach <7806504+liach at users.noreply.github.com>

Benchmarks, please :-)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13150#issuecomment-1481789269

From dfuchs at openjdk.org  Thu Mar 23 19:43:51 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 23 Mar 2023 19:43:51 GMT
Subject: RFR: 8304745: Lazily initialize byte[] in
 java.io.BufferedInputStream [v2]
In-Reply-To: 
References: 
 
Message-ID: <4MAkaP5vymcoQ_FKJ-q3pP6XO99qCxN-x5Uz0dZzkjQ=.736ad552-c514-490a-b4ac-833b3d16b4b7@github.com>

On Thu, 23 Mar 2023 19:27:04 GMT, Sergey Tsypanov  wrote:

>> By default `BufferedInputStream` is constructed with internal buffer with capacity 8192. In some cases this buffer is never used, e.g. when we call `IS.readNBytes()` or `IS.readAllBytes()` (relying on `BIS.read1()`) or when `BufferedInputStream` is cascaded.
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/io/BufferedInputStream.java
>   
>   Co-authored-by: liach <7806504+liach at users.noreply.github.com>

src/java.base/share/classes/java/io/BufferedInputStream.java line 183:

> 181:         if (buffer == EMPTY) {
> 182:             buf = buffer = new byte[size];
> 183:         }

You should probably use compareAndSet here too like in fill() - to handle the case of asynchoronous close.
This patch makes me a bit nervous. I would advise to get feedback from @bplb and @AlanBateman .

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13150#discussion_r1146736923

From duke at openjdk.org  Thu Mar 23 19:51:08 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 23 Mar 2023 19:51:08 GMT
Subject: RFR: 8304745: Lazily initialize byte[] in
 java.io.BufferedInputStream [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 23 Mar 2023 19:27:04 GMT, Sergey Tsypanov  wrote:

>> By default `BufferedInputStream` is constructed with internal buffer with capacity 8192. In some cases this buffer is never used, e.g. when we call `IS.readNBytes()` or `IS.readAllBytes()` (relying on `BIS.read1()`) or when `BufferedInputStream` is cascaded.
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/io/BufferedInputStream.java
>   
>   Co-authored-by: liach <7806504+liach at users.noreply.github.com>

You are probably following #13121, but for everybody else's reference here is Alan's comment on that PR:

https://github.com/openjdk/jdk/pull/13121#issuecomment-1481127986

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13150#issuecomment-1481800729

From duke at openjdk.org  Thu Mar 23 19:57:34 2023
From: duke at openjdk.org (altrisi)
Date: Thu, 23 Mar 2023 19:57:34 GMT
Subject: RFR: 8300979: Lazily initialize (byte,
 char)arr in java.io.DataInputStream [v3]
In-Reply-To: <5tQ84BWMKaCnFalikXWrEtW9X21bB-ElGw-k5B-KZTQ=.703816ac-c0b1-4e08-be7d-74f6942010a6@github.com>
References: 
 <5tQ84BWMKaCnFalikXWrEtW9X21bB-ElGw-k5B-KZTQ=.703816ac-c0b1-4e08-be7d-74f6942010a6@github.com>
Message-ID: 

On Wed, 22 Mar 2023 10:12:26 GMT, Per Minborg  wrote:

>> This PR proposed to lazily initialize the scratch arrays only if/when needed.
>
> Per Minborg 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 'dis-lazy' of https://github.com/minborg/jdk into dis-lazy
>  - Update src/java.base/share/classes/java/io/DataInputStream.java
>    
>    Co-authored-by: Eirik Bjorsnos 
>  - Merge branch 'master' into dis-lazy
>  - Remove redundant initilizers
>  - Lazily initialize (byte, char)arr in java.io.DataInputStream

If that's the case an alternative idea could be to make them hold a (shared) empty array by default instead, that'd also match the condition (except the 0 length case) for entering the branch and wouldn't be null.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13121#issuecomment-1481808015

From liach at openjdk.org  Thu Mar 23 19:58:32 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 23 Mar 2023 19:58:32 GMT
Subject: RFR: 8304745: Lazily initialize byte[] in
 java.io.BufferedInputStream [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 23 Mar 2023 19:27:04 GMT, Sergey Tsypanov  wrote:

>> By default `BufferedInputStream` is constructed with internal buffer with capacity 8192. In some cases this buffer is never used, e.g. when we call `IS.readNBytes()` or `IS.readAllBytes()` (relying on `BIS.read1()`) or when `BufferedInputStream` is cascaded.
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/io/BufferedInputStream.java
>   
>   Co-authored-by: liach <7806504+liach at users.noreply.github.com>

> You are probably following #13121, but for everybody else's reference here is Alan's comment on that PR:
> 
> [#13121 (comment)](https://github.com/openjdk/jdk/pull/13121#issuecomment-1481127986)

The lazy creation only happens if it's the exact BufferedInputStream class, which is already handled like the internal lock.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13150#issuecomment-1481805918

From dfuchs at openjdk.org  Thu Mar 23 19:58:33 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 23 Mar 2023 19:58:33 GMT
Subject: RFR: 8304745: Lazily initialize byte[] in
 java.io.BufferedInputStream [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 23 Mar 2023 19:53:13 GMT, Chen Liang  wrote:

> The lazy creation only happens if it's the exact BufferedInputStream class, which is already handled like the internal lock.

Maybe, but how does it play with asynchronous close?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13150#issuecomment-1481809027

From alanb at openjdk.org  Thu Mar 23 19:58:37 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 23 Mar 2023 19:58:37 GMT
Subject: RFR: 8304745: Lazily initialize byte[] in
 java.io.BufferedInputStream [v2]
In-Reply-To: <4MAkaP5vymcoQ_FKJ-q3pP6XO99qCxN-x5Uz0dZzkjQ=.736ad552-c514-490a-b4ac-833b3d16b4b7@github.com>
References: 
 
 <4MAkaP5vymcoQ_FKJ-q3pP6XO99qCxN-x5Uz0dZzkjQ=.736ad552-c514-490a-b4ac-833b3d16b4b7@github.com>
Message-ID: <35mwhIt2DA6RCtTc6v5a_pqk17CybmHVi0rLoTZpkfM=.30cd0811-82c2-4440-b0a7-8597b4b876e5@github.com>

On Thu, 23 Mar 2023 19:41:24 GMT, Daniel Fuchs  wrote:

>> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/java.base/share/classes/java/io/BufferedInputStream.java
>>   
>>   Co-authored-by: liach <7806504+liach at users.noreply.github.com>
>
> src/java.base/share/classes/java/io/BufferedInputStream.java line 183:
> 
>> 181:         if (buffer == EMPTY) {
>> 182:             buf = buffer = new byte[size];
>> 183:         }
> 
> You should probably use compareAndSet here too like in fill() - to handle the case of asynchoronous close.
> This patch makes me a bit nervous. I would advise to get feedback from @bplb and @AlanBateman .

Yes, I'm nervous about changing BIS too. Most of the initial revisions of the patch introduced compatibility issues so it had to be restricted to the no sub-class case. Here, it needs to CAS buf as otherwise it will break async close. 

I think the starting point for this issue is to show examples where it avoids needing to create the byte[] on first usage. The first use of read, readAllBytes, readNBytes, .. will create the byte[] but Sergey may have spotted some usages where it does help.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13150#discussion_r1146756100

From duke at openjdk.org  Thu Mar 23 20:18:16 2023
From: duke at openjdk.org (Hannes Greule)
Date: Thu, 23 Mar 2023 20:18:16 GMT
Subject: RFR: 8304837: Classfile API throws IOOBE for MethodParameters
 attribute without parameter names
Message-ID: 

After merging master into https://github.com/openjdk/jdk/pull/9862, we encountered test failures (e.g., https://github.com/SirYwell/jdk/actions/runs/4500940829/jobs/7923018438#step:9:2541). The Classfile API tries to read from constant pool index 0 if a MethodParameters attribute has an entry without name.

The fix is simply using `readUtf8EntryOrNull` instead of `readUtf8Entry`. The related code already correctly handles nullability.

I didn't find an appropriate test class so I added a new one. Let me know if there's a better place or if the test can be improved somehow.

As I don't have a JBS account, someone needs to create a bug report there for me. Thanks.

-------------

Commit messages:
 - Read parameter name from constant pool optionally

Changes: https://git.openjdk.org/jdk/pull/13167/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13167&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304837
  Stats: 72 lines in 2 files changed: 70 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13167.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13167/head:pull/13167

PR: https://git.openjdk.org/jdk/pull/13167

From liach at openjdk.org  Thu Mar 23 20:18:20 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 23 Mar 2023 20:18:20 GMT
Subject: RFR: 8304837: Classfile API throws IOOBE for MethodParameters
 attribute without parameter names
In-Reply-To: 
References: 
Message-ID: 

On Thu, 23 Mar 2023 19:45:21 GMT, Hannes Greule  wrote:

> After merging master into https://github.com/openjdk/jdk/pull/9862, we encountered test failures (e.g., https://github.com/SirYwell/jdk/actions/runs/4500940829/jobs/7923018438#step:9:2541). The Classfile API tries to read from constant pool index 0 if a MethodParameters attribute has an entry without name.
> 
> The fix is simply using `readUtf8EntryOrNull` instead of `readUtf8Entry`. The related code already correctly handles nullability.
> 
> I didn't find an appropriate test class so I added a new one. Let me know if there's a better place or if the test can be improved somehow.
> 
> As I don't have a JBS account, someone needs to create a bug report there for me. Thanks.

Nice catch, issue opened at https://bugs.openjdk.org/browse/JDK-8304837 and marked as blocking compiler changes.

src/java.base/share/classes/jdk/internal/classfile/impl/BoundAttribute.java line 2:

> 1: /*
> 2:  * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved.

Suggestion:

 * Copyright (c) 2022, 2023, Oracle and/or its affiliates. All rights reserved.

test/jdk/jdk/classfile/BoundAttributeTest.java line 46:

> 44: /*
> 45:  * @test
> 46:  * @summary Testing BoundAttributes

Suggestion:

 * @issue 8304837
 * @summary Testing BoundAttributes

now that I've created an issue for you.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13167#issuecomment-1481828277
PR Review Comment: https://git.openjdk.org/jdk/pull/13167#discussion_r1146773987
PR Review Comment: https://git.openjdk.org/jdk/pull/13167#discussion_r1146775648

From naoto at openjdk.org  Thu Mar 23 20:25:13 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 23 Mar 2023 20:25:13 GMT
Subject: RFR: 8304761: Update IANA Language Subtag Registry to Version
 2023-03-22
In-Reply-To: 
References: 
Message-ID: 

On Thu, 23 Mar 2023 19:07:05 GMT, Justin Lu  wrote:

> Update IANA LSR to 2023-03-22 [update](https://mm.icann.org/pipermail/ietf-languages-announcements/2023-March/000085.html). Add all new preferred languages to `ACCEPT_LANGUAGES` except `gu`.

test/jdk/java/util/Locale/LanguageSubtagRegistryTest.java line 193:

> 191:             new LanguageRange("ysm", 1.0),
> 192:             new LanguageRange("sgn-ysm", 1.0),
> 193:             new LanguageRange("wkr", 1.0),

What is the reason the weight has changed?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13165#discussion_r1146786932

From liach at openjdk.org  Thu Mar 23 20:27:13 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 23 Mar 2023 20:27:13 GMT
Subject: RFR: 8304745: Lazily initialize byte[] in
 java.io.BufferedInputStream [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 23 Mar 2023 19:27:04 GMT, Sergey Tsypanov  wrote:

>> By default `BufferedInputStream` is constructed with internal buffer with capacity 8192. In some cases this buffer is never used, e.g. when we call `IS.readNBytes()` or `IS.readAllBytes()` (relying on `BIS.read1()`) or when `BufferedInputStream` is cascaded.
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/io/BufferedInputStream.java
>   
>   Co-authored-by: liach <7806504+liach at users.noreply.github.com>

So something like this?


byte[] buffer;
byte[] allocated;
do {
    buffer = buf;
    if (buffer == null) {
        throw new IOException("Stream closed");
    }
    if (buffer == EMPTY) {
        if (allocated == null) {
            allocated = new byte[size];
        }
        // defend against asynchronous close
        if (U.compareAndSetReference(this, BUF_OFFSET, EMPTY, allocated) {
            return allocated;
        } else {
            continue;
        }
    }
    return buffer;
}

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13150#issuecomment-1481844595

From duke at openjdk.org  Thu Mar 23 20:36:44 2023
From: duke at openjdk.org (Viktor Klang)
Date: Thu, 23 Mar 2023 20:36:44 GMT
Subject: RFR: JDK-8304557:
 java/util/concurrent/CompletableFuture/CompletableFutureOrTimeoutExceptionallyTest.java
 times out [v3]
In-Reply-To: 
References: 
 
Message-ID: <85KYQsX354O1CMgNrD8ekPfFvkYz_ElLR5xURnmBINI=.ddece1f4-f4fa-4869-b1fc-254b5e8e89ea@github.com>

On Thu, 23 Mar 2023 14:13:14 GMT, Viktor Klang  wrote:

>> Improves the stability of the memory leak test for CompletableFuture timeout cancellation by both reducing the count by 50% (which should still be above threshold to trigger given the ample margin set initially) as well as extending the default timeout of the test run.
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding an @modules and minor code reformatting

Also, pinging @DougLea as a gentle FYI :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13116#issuecomment-1481859000

From stsypanov at openjdk.org  Thu Mar 23 20:36:47 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Thu, 23 Mar 2023 20:36:47 GMT
Subject: RFR: 8304745: Lazily initialize byte[] in
 java.io.BufferedInputStream [v2]
In-Reply-To: <35mwhIt2DA6RCtTc6v5a_pqk17CybmHVi0rLoTZpkfM=.30cd0811-82c2-4440-b0a7-8597b4b876e5@github.com>
References: 
 
 <4MAkaP5vymcoQ_FKJ-q3pP6XO99qCxN-x5Uz0dZzkjQ=.736ad552-c514-490a-b4ac-833b3d16b4b7@github.com>
 <35mwhIt2DA6RCtTc6v5a_pqk17CybmHVi0rLoTZpkfM=.30cd0811-82c2-4440-b0a7-8597b4b876e5@github.com>
Message-ID: 

On Thu, 23 Mar 2023 19:55:04 GMT, Alan Bateman  wrote:

>> src/java.base/share/classes/java/io/BufferedInputStream.java line 183:
>> 
>>> 181:         if (buffer == EMPTY) {
>>> 182:             buf = buffer = new byte[size];
>>> 183:         }
>> 
>> You should probably use compareAndSet here too like in fill() - to handle the case of asynchoronous close.
>> This patch makes me a bit nervous. I would advise to get feedback from @bplb and @AlanBateman .
>
> Yes, I'm nervous about changing BIS too. Most of the initial revisions of the patch introduced compatibility issues so it had to be restricted to the no sub-class case. Here, it needs to CAS buf as otherwise it will break async close. 
> 
> I think the starting point for this issue is to show examples where it avoids needing to create the byte[] on first usage. The first use of read, readAllBytes, readNBytes, .. will create the byte[] but Sergey may have spotted some usages where it does help.

Some implementations of `getInputStream()` return `BufferedInputStream` which is later wrapped into `BufferedInputStream` on call site, e.g. `FileURLConnection`. With this change we can avoid allocation of byte[] in internal BIS.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13150#discussion_r1146801965

From duke at openjdk.org  Thu Mar 23 20:36:41 2023
From: duke at openjdk.org (Viktor Klang)
Date: Thu, 23 Mar 2023 20:36:41 GMT
Subject: RFR: JDK-8304557:
 java/util/concurrent/CompletableFuture/CompletableFutureOrTimeoutExceptionallyTest.java
 times out
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 21 Mar 2023 11:02:52 GMT, Jaikiran Pai  wrote:

>> Improves the stability of the memory leak test for CompletableFuture timeout cancellation by both reducing the count by 50% (which should still be above threshold to trigger given the ample margin set initially) as well as extending the default timeout of the test run.
>
> The PR seems to be using an incorrect JBS issue id/summary. This PR should be linked with the new https://bugs.openjdk.org/browse/JDK-8304557 issue.

@jaikiran The modified change has passed on a debug build now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13116#issuecomment-1481857138

From dl at openjdk.org  Thu Mar 23 20:42:26 2023
From: dl at openjdk.org (Doug Lea)
Date: Thu, 23 Mar 2023 20:42:26 GMT
Subject: RFR: JDK-8304557:
 java/util/concurrent/CompletableFuture/CompletableFutureOrTimeoutExceptionallyTest.java
 times out [v3]
In-Reply-To: 
References: 
 
Message-ID: <2UVDCQfGZubcdn5N2X7Nn-o3Bn_HykHK0UO4C7_DZ6I=.8ca22006-0a8e-407c-a9e5-95590babfc5e@github.com>

On Thu, 23 Mar 2023 14:13:14 GMT, Viktor Klang  wrote:

>> Improves the stability of the memory leak test for CompletableFuture timeout cancellation by both reducing the count by 50% (which should still be above threshold to trigger given the ample margin set initially) as well as extending the default timeout of the test run.
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding an @modules and minor code reformatting

Still lgtm :-)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13116#issuecomment-1481865983

From duke at openjdk.org  Thu Mar 23 20:47:21 2023
From: duke at openjdk.org (Viktor Klang)
Date: Thu, 23 Mar 2023 20:47:21 GMT
Subject: Integrated: JDK-8304557:
 java/util/concurrent/CompletableFuture/CompletableFutureOrTimeoutExceptionallyTest.java
 times out
In-Reply-To: 
References: 
Message-ID: <03o6eXkO1Oz-XOyjz9ZlHY--A8fIVG57Bn_2F2ner3k=.86fd9a5e-81f4-45b3-8591-0590db566d6f@github.com>

On Tue, 21 Mar 2023 10:42:55 GMT, Viktor Klang  wrote:

> Improves the stability of the memory leak test for CompletableFuture timeout cancellation by both reducing the count by 50% (which should still be above threshold to trigger given the ample margin set initially) as well as extending the default timeout of the test run.

This pull request has now been integrated.

Changeset: 6f67abd3
Author:    Viktor Klang 
Committer: Alan Bateman 
URL:       https://git.openjdk.org/jdk/commit/6f67abd352ce9605dd93188995d42a47ee07b25e
Stats:     34 lines in 1 file changed: 20 ins; 0 del; 14 mod

8304557: java/util/concurrent/CompletableFuture/CompletableFutureOrTimeoutExceptionallyTest.java times out

Reviewed-by: jpai

-------------

PR: https://git.openjdk.org/jdk/pull/13116

From stsypanov at openjdk.org  Thu Mar 23 20:49:10 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Thu, 23 Mar 2023 20:49:10 GMT
Subject: RFR: 8304745: Lazily initialize byte[] in
 java.io.BufferedInputStream [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 23 Mar 2023 19:48:40 GMT, Eirik Bjorsnos  wrote:

>> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/java.base/share/classes/java/io/BufferedInputStream.java
>>   
>>   Co-authored-by: liach <7806504+liach at users.noreply.github.com>
>
> You are probably following #13121, but for everybody else's reference here is Alan's comment on that PR:
> 
> https://github.com/openjdk/jdk/pull/13121#issuecomment-1481127986

@eirbjo you mean benchmark for BIS instantiation?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13150#issuecomment-1481874555

From duke at openjdk.org  Thu Mar 23 21:02:18 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 23 Mar 2023 21:02:18 GMT
Subject: RFR: 8304745: Lazily initialize byte[] in
 java.io.BufferedInputStream [v2]
In-Reply-To: 
References: 
 
 
Message-ID: <_AgAWzCp_sX0_4B32i4xihXRvoTXKkTGsC7gADDZGpI=.69838ea6-8bf2-4dc9-895f-924502577356@github.com>

On Thu, 23 Mar 2023 19:48:40 GMT, Eirik Bjorsnos  wrote:

>> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/java.base/share/classes/java/io/BufferedInputStream.java
>>   
>>   Co-authored-by: liach <7806504+liach at users.noreply.github.com>
>
> You are probably following #13121, but for everybody else's reference here is Alan's comment on that PR:
> 
> https://github.com/openjdk/jdk/pull/13121#issuecomment-1481127986

> @eirbjo you mean benchmark for BIS instantiation?

My general thought is that a benchmark demonstrating the  proposed performance benefits is always good and should perhaps be a requirement for such performance related changes. An effort should be made to detect regressions as well. This is just my personal preference, won't claim this is policy of any kind.

Until something is benchmarked, nobody knows if the benefit is just speculation.

I have experienced and suggested several PRs myself which benchmark work later showed dubious improvements which cased the change to be withdrawn. 

In #13121, I ran some (existing) benchmark on the PR only to discover it seems to have a weird, subtle regression.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13150#issuecomment-1481900264

From duke at openjdk.org  Thu Mar 23 21:18:32 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 23 Mar 2023 21:18:32 GMT
Subject: RFR: 8304745: Lazily initialize byte[] in
 java.io.BufferedInputStream [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 23 Mar 2023 19:27:04 GMT, Sergey Tsypanov  wrote:

>> By default `BufferedInputStream` is constructed with internal buffer with capacity 8192. In some cases this buffer is never used, e.g. when we call `IS.readNBytes()` or `IS.readAllBytes()` (relying on `BIS.read1()`) or when `BufferedInputStream` is cascaded.
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/io/BufferedInputStream.java
>   
>   Co-authored-by: liach <7806504+liach at users.noreply.github.com>

My last comment was so heavily edited, I think it makes sense to delete it and include the last edit here:

> @eirbjo you mean benchmark for BIS instantiation?

My general thought is that a benchmark demonstrating the proposed performance benefits is always good and should perhaps be a requirement for such performance related changes. An effort should be made to detect regressions as well. This is just my personal preference, won't claim this is policy of any kind.

Until something is benchmarked, nobody knows if the benefit is just speculation.

I have experienced and suggested several PRs myself which benchmark work later showed dubious improvements which cased the change to be withdrawn.

In https://github.com/openjdk/jdk/pull/13121, I ran some (existing) benchmark on the PR only to discover it seems to have a weird, subtle regression.

Besides this: A benchmark also help you save the performance improvements for the future. Without a benchmark, it is easier for someone to come along and nullify your improvements by some independent change.

Personal bottom line: When a PR is motivated by performance, suggested benefits should be demonstrated through benchmarks.

Very bottom line: I do not claim that this PR has no performance benefits.

Final bottom line: Performance claims need proofs and the proof needs to fit in the margin.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13150#issuecomment-1481922199

From jlu at openjdk.org  Thu Mar 23 21:19:35 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 23 Mar 2023 21:19:35 GMT
Subject: Integrated: 8303917: Update ISO 639 language codes table
In-Reply-To: 
References: 
Message-ID: 

On Fri, 10 Mar 2023 17:27:11 GMT, Justin Lu  wrote:

> This PR modifies `java.util.LocaleISOData.isoLanguageTable` to include (name only) changes from up-to-date [ISO 639 data](http://www.loc.gov/standards/iso639-2/php/code_list.php.).
> 
> In addition, this PR updates the ISO 639 data (generated in 1999) in `Bug4175998Test.java`. This includes modifying the `generate_Tables() `function, since the source data is now stored in a different format. The outdated raw data stored in the bottom of the file was removed.

This pull request has now been integrated.

Changeset: dd23ee9e
Author:    Justin Lu 
Committer: Naoto Sato 
URL:       https://git.openjdk.org/jdk/commit/dd23ee9e8732223475a2e8c635322503dffbb6bf
Stats:     840 lines in 2 files changed: 62 ins; 626 del; 152 mod

8303917: Update ISO 639 language codes table

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/12980

From jlu at openjdk.org  Thu Mar 23 21:30:37 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 23 Mar 2023 21:30:37 GMT
Subject: RFR: 8304761: Update IANA Language Subtag Registry to Version
 2023-03-22 [v2]
In-Reply-To: 
References: 
Message-ID: 

> Update IANA LSR to 2023-03-22 [update](https://mm.icann.org/pipermail/ietf-languages-announcements/2023-March/000085.html). Add all new preferred languages to `ACCEPT_LANGUAGES` except `gu`.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Revert incorrect weighting

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13165/files
  - new: https://git.openjdk.org/jdk/pull/13165/files/f9df542c..ff7901f4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13165&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13165&range=00-01

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/13165.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13165/head:pull/13165

PR: https://git.openjdk.org/jdk/pull/13165

From jlu at openjdk.org  Thu Mar 23 21:38:00 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 23 Mar 2023 21:38:00 GMT
Subject: RFR: 8304761: Update IANA Language Subtag Registry to Version
 2023-03-22 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 23 Mar 2023 20:21:32 GMT, Naoto Sato  wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert incorrect weighting
>
> test/jdk/java/util/Locale/LanguageSubtagRegistryTest.java line 193:
> 
>> 191:             new LanguageRange("ysm", 1.0),
>> 192:             new LanguageRange("sgn-ysm", 1.0),
>> 193:             new LanguageRange("wkr", 1.0),
> 
> What is the reason the weight has changed?

`wkr` added into `ACCEPT_LANGUAGES` incorrectly by me, fixed now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13165#discussion_r1146892276

From jwaters at openjdk.org  Thu Mar 23 21:53:33 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 23 Mar 2023 21:53:33 GMT
Subject: RFR: 8304837: Classfile API throws IOOBE for MethodParameters
 attribute without parameter names
In-Reply-To: 
References: 
Message-ID: 

On Thu, 23 Mar 2023 19:45:21 GMT, Hannes Greule  wrote:

> After merging master into https://github.com/openjdk/jdk/pull/9862, we encountered test failures (e.g., https://github.com/SirYwell/jdk/actions/runs/4500940829/jobs/7923018438#step:9:2541). The Classfile API tries to read from constant pool index 0 if a MethodParameters attribute has an entry without name.
> 
> The fix is simply using `readUtf8EntryOrNull` instead of `readUtf8Entry`. The related code already correctly handles nullability.
> 
> I didn't find an appropriate test class so I added a new one. Let me know if there's a better place or if the test can be improved somehow.
> 
> As I don't have a JBS account, someone needs to create a bug report there for me. Thanks.

Oops, looks like I was too late to create the issue haha

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13167#issuecomment-1481960385

From jwaters at openjdk.org  Thu Mar 23 22:23:00 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 23 Mar 2023 22:23:00 GMT
Subject: RFR: 8304717: Declaration aliasing between boolean and jboolean is
 wrong [v2]
In-Reply-To: <9Xij1FEbLnMYTPIZOOhGyaKnlplxP6Wp3ODS2bKP7u0=.146017ce-32ee-40f3-8496-49c014f7decb@github.com>
References: <9Xij1FEbLnMYTPIZOOhGyaKnlplxP6Wp3ODS2bKP7u0=.146017ce-32ee-40f3-8496-49c014f7decb@github.com>
Message-ID: 

> A couple of spots wrongly refer to boolean and jboolean as the same thing. While this does still compile thanks to a happy accident and implicit conversions, they are not the same at all, and should be fixed before a future compiler error happens if their declarations are touched

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  MacOSXPreferencesFile.m

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13139/files
  - new: https://git.openjdk.org/jdk/pull/13139/files/0df005b5..3f9da8b6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13139&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13139&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/13139.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13139/head:pull/13139

PR: https://git.openjdk.org/jdk/pull/13139

From duke at openjdk.org  Thu Mar 23 22:34:24 2023
From: duke at openjdk.org (Hannes Greule)
Date: Thu, 23 Mar 2023 22:34:24 GMT
Subject: RFR: 8304837: Classfile API throws IOOBE for MethodParameters
 attribute without parameter names [v2]
In-Reply-To: 
References: 
Message-ID: 

> After merging master into https://github.com/openjdk/jdk/pull/9862, we encountered test failures (e.g., https://github.com/SirYwell/jdk/actions/runs/4500940829/jobs/7923018438#step:9:2541). The Classfile API tries to read from constant pool index 0 if a MethodParameters attribute has an entry without name.
> 
> The fix is simply using `readUtf8EntryOrNull` instead of `readUtf8Entry`. The related code already correctly handles nullability.
> 
> I didn't find an appropriate test class so I added a new one. Let me know if there's a better place or if the test can be improved somehow.
> 
> As I don't have a JBS account, someone needs to create a bug report there for me. Thanks.

Hannes Greule has updated the pull request incrementally with one additional commit since the last revision:

  Apply suggestions from code review
  
  Co-authored-by: liach <7806504+liach at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13167/files
  - new: https://git.openjdk.org/jdk/pull/13167/files/4a94bb17..f4b8062c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13167&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13167&range=00-01

  Stats: 2 lines in 2 files changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13167.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13167/head:pull/13167

PR: https://git.openjdk.org/jdk/pull/13167

From jjg at openjdk.org  Thu Mar 23 22:52:57 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 23 Mar 2023 22:52:57 GMT
Subject: RFR: 8304837: Classfile API throws IOOBE for MethodParameters
 attribute without parameter names [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 23 Mar 2023 22:34:24 GMT, Hannes Greule  wrote:

>> After merging master into https://github.com/openjdk/jdk/pull/9862, we encountered test failures (e.g., https://github.com/SirYwell/jdk/actions/runs/4500940829/jobs/7923018438#step:9:2541). The Classfile API tries to read from constant pool index 0 if a MethodParameters attribute has an entry without name.
>> 
>> The fix is simply using `readUtf8EntryOrNull` instead of `readUtf8Entry`. The related code already correctly handles nullability.
>> 
>> I didn't find an appropriate test class so I added a new one. Let me know if there's a better place or if the test can be improved somehow.
>> 
>> As I don't have a JBS account, someone needs to create a bug report there for me. Thanks.
>
> Hannes Greule has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestions from code review
>   
>   Co-authored-by: liach <7806504+liach at users.noreply.github.com>

test/jdk/jdk/classfile/BoundAttributeTest.java line 46:

> 44: /*
> 45:  * @test
> 46:  * @issue 8304837

Should be `@bug`, not `@issue`. 

Did you run this test? Did it not complain at `@issue`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13167#discussion_r1146952634

From jjg at openjdk.org  Thu Mar 23 22:58:01 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 23 Mar 2023 22:58:01 GMT
Subject: RFR: 8304837: Classfile API throws IOOBE for MethodParameters
 attribute without parameter names [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 23 Mar 2023 22:34:24 GMT, Hannes Greule  wrote:

>> After merging master into https://github.com/openjdk/jdk/pull/9862, we encountered test failures (e.g., https://github.com/SirYwell/jdk/actions/runs/4500940829/jobs/7923018438#step:9:2541). The Classfile API tries to read from constant pool index 0 if a MethodParameters attribute has an entry without name.
>> 
>> The fix is simply using `readUtf8EntryOrNull` instead of `readUtf8Entry`. The related code already correctly handles nullability.
>> 
>> I didn't find an appropriate test class so I added a new one. Let me know if there's a better place or if the test can be improved somehow.
>> 
>> As I don't have a JBS account, someone needs to create a bug report there for me. Thanks.
>
> Hannes Greule has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestions from code review
>   
>   Co-authored-by: liach <7806504+liach at users.noreply.github.com>

test/jdk/jdk/classfile/BoundAttributeTest.java line 44:

> 42: import static org.junit.jupiter.api.Assertions.assertTrue;
> 43: 
> 44: /*

Generally, the style for tests is to put the test description comment _before_ the imports.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13167#discussion_r1146955092

From rriggs at openjdk.org  Fri Mar 24 00:27:42 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 24 Mar 2023 00:27:42 GMT
Subject: RFR: 8303485: Replacing os.name for operating system customization
 [v6]
In-Reply-To: 
References: 
Message-ID: 

> Improvements to support OS specific customization for JDK internal use:
>  - To select values and code; allowing elimination of unused code and values
>  - Optionally evaluated by build processes, compilation, or archiving (i.e. CDS)
>  - Simple API to replace adhoc comparisons with `os.name`
>  - Clear and consistent use across build, runtime, and JDK modules
>  
> The PR includes updates within java.base to use the new API.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Rename OperatingSystem enum values to uppercase

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12931/files
  - new: https://git.openjdk.org/jdk/pull/12931/files/32ee9d4a..8372978f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12931&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12931&range=04-05

  Stats: 25 lines in 4 files changed: 0 ins; 0 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/12931.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12931/head:pull/12931

PR: https://git.openjdk.org/jdk/pull/12931

From liach at openjdk.org  Fri Mar 24 01:30:29 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 24 Mar 2023 01:30:29 GMT
Subject: RFR: 8304837: Classfile API throws IOOBE for MethodParameters
 attribute without parameter names [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 23 Mar 2023 22:50:28 GMT, Jonathan Gibbons  wrote:

>> Hannes Greule has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apply suggestions from code review
>>   
>>   Co-authored-by: liach <7806504+liach at users.noreply.github.com>
>
> test/jdk/jdk/classfile/BoundAttributeTest.java line 46:
> 
>> 44: /*
>> 45:  * @test
>> 46:  * @issue 8304837
> 
> Should be `@bug`, not `@issue`. 
> 
> Did you run this test? Did it not complain at `@issue`?

sorry, i apparently suggested a wrong tag on github. my bad
Suggestion:

 * @bug 8304837

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13167#discussion_r1147030659

From jpai at openjdk.org  Fri Mar 24 02:18:43 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 24 Mar 2023 02:18:43 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v13]
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.org/browse/JDK-8206890?
> 
> The `jlink` command allows a `--endian` option to specify the byte order in the generated image. Before this change, when such a image was being launched, the code would assume the byte order in the image to be the native order of the host where the image is being launched. That would result in failure to launch java, as noted in the linked issue.
> 
> The commit in this PR, changes relevant places to not assume native order and instead determine the byte order by reading the magic bytes in the image file's header content.
> 
> A new jtreg test has been added which reproduces the issue and verifies the fix.

Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:

 - merge latest from master branch
 - Mandy's suggested patch improvements
 - ARM is 32 bit as per platform.m4 in OpenJDK build
 - when --endian is specified, verify it matches the implicitly determined target platform's endianness
 - trim down the architecture support to the previous values plus a few new that match target.properties
 - improve error messages as suggested by Mandy
 - formatting fix
 - Alan's suggestions - don't parse arch out of osname-arch for determining endianness and reduce the number of supported/known target platforms for cross linking
 - Mandy's suggestion - pass along target platform to the DefaultImageBuilder to prevent reparsing the value from the ModuleTarget
 - Mandy's suggestion to use Platform class for additional arch support. Plus, Jim's suggestion to use a runtime resource for endianness mapping
 - ... and 18 more: https://git.openjdk.org/jdk/compare/ac6af6a6...6f4ab9c6

-------------

Changes: https://git.openjdk.org/jdk/pull/11943/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11943&range=12
  Stats: 224 lines in 8 files changed: 180 ins; 10 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/11943.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/11943/head:pull/11943

PR: https://git.openjdk.org/jdk/pull/11943

From jpai at openjdk.org  Fri Mar 24 02:18:45 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 24 Mar 2023 02:18:45 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v12]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 23 Mar 2023 18:30:40 GMT, Mandy Chung  wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   ARM is 32 bit as per platform.m4 in OpenJDK build
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 823:
> 
>> 821:             if (order != null) {
>> 822:                 this.order = order;
>> 823:                 String targetPlatformVal = readJavaBaseTargetPlatform(cf);
> 
> Thanks for the update.
> 
> This should also do the fast-path check `isJavaBaseFromCurrentPlatform(javaBasePath)` as in line 838-860.  I suggest to refactor line 838-860 to return the target platform (either runtime platform or from java.base in the given module path).   
> 
> I also suggest to include `endianness` in the `Platform` record class.
> 
> I sent you a patch offline with these suggestions.

Thank you Mandy for the review and the improved patch. I've applied it and tests continue to pass. I've updated the PR with these changes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/11943#discussion_r1147050227

From dholmes at openjdk.org  Fri Mar 24 03:07:37 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 24 Mar 2023 03:07:37 GMT
Subject: RFR: 8304717: Declaration aliasing between boolean and jboolean is
 wrong [v2]
In-Reply-To: 
References: <9Xij1FEbLnMYTPIZOOhGyaKnlplxP6Wp3ODS2bKP7u0=.146017ce-32ee-40f3-8496-49c014f7decb@github.com>
 
Message-ID: 

On Thu, 23 Mar 2023 22:23:00 GMT, Julian Waters  wrote:

>> A couple of spots wrongly refer to boolean and jboolean as the same thing. While this does still compile thanks to a happy accident and implicit conversions, they are not the same at all, and should be fixed before a future compiler error happens if their declarations are touched
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   MacOSXPreferencesFile.m

One change has an issue but the others seem fine. You really need reviewers from each component area though.

Thanks.

src/java.prefs/macosx/native/libprefs/MacOSXPreferencesFile.m line 685:

> 683:     CFStringRef topKey;
> 684:     CFMutableDictionaryRef topValue;
> 685:     Boolean beforeAdd = false;

The return value from `CFDictionaryContainsKey` is a Boolean and is assigned to this variable. So I think these changes are the wrong way round. Keep this as a Boolean but convert the return value to jboolean:

return beforeAdd ? JNI_TRUE : JNI_FALSE;

-------------

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13139#pullrequestreview-1355937817
PR Review Comment: https://git.openjdk.org/jdk/pull/13139#discussion_r1147071367

From jwaters at openjdk.org  Fri Mar 24 04:12:35 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 24 Mar 2023 04:12:35 GMT
Subject: RFR: 8304717: Declaration aliasing between boolean and jboolean is
 wrong [v2]
In-Reply-To: 
References: <9Xij1FEbLnMYTPIZOOhGyaKnlplxP6Wp3ODS2bKP7u0=.146017ce-32ee-40f3-8496-49c014f7decb@github.com>
 
Message-ID: 

On Thu, 23 Mar 2023 22:23:00 GMT, Julian Waters  wrote:

>> A couple of spots wrongly refer to boolean and jboolean as the same thing. While this does still compile thanks to a happy accident and implicit conversions, they are not the same at all, and should be fixed before a future compiler error happens if their declarations are touched
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   MacOSXPreferencesFile.m

Correct label for awt is client to my knowledge

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13139#issuecomment-1482222230

From dholmes at openjdk.org  Fri Mar 24 05:10:30 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 24 Mar 2023 05:10:30 GMT
Subject: RFR: 8304717: Declaration aliasing between boolean and jboolean is
 wrong [v2]
In-Reply-To: 
References: <9Xij1FEbLnMYTPIZOOhGyaKnlplxP6Wp3ODS2bKP7u0=.146017ce-32ee-40f3-8496-49c014f7decb@github.com>
 
Message-ID: 

On Thu, 23 Mar 2023 22:23:00 GMT, Julian Waters  wrote:

>> A couple of spots wrongly refer to boolean and jboolean as the same thing. While this does still compile thanks to a happy accident and implicit conversions, they are not the same at all, and should be fixed before a future compiler error happens if their declarations are touched
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   MacOSXPreferencesFile.m

Thanks for the correction I thought the mailing list was awt-dev similar to swing-dev.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13139#issuecomment-1482258685

From qamai at openjdk.org  Fri Mar 24 05:37:30 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 24 Mar 2023 05:37:30 GMT
Subject: RFR: 8304717: Declaration aliasing between boolean and jboolean is
 wrong [v2]
In-Reply-To: 
References: <9Xij1FEbLnMYTPIZOOhGyaKnlplxP6Wp3ODS2bKP7u0=.146017ce-32ee-40f3-8496-49c014f7decb@github.com>
 
Message-ID: 

On Thu, 23 Mar 2023 22:23:00 GMT, Julian Waters  wrote:

>> A couple of spots wrongly refer to boolean and jboolean as the same thing. While this does still compile thanks to a happy accident and implicit conversions, they are not the same at all, and should be fixed before a future compiler error happens if their declarations are touched
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   MacOSXPreferencesFile.m

Is this needed? A boolean-to-int conversion returns `1` if the input is `true` and `0` otherwise. The opposite returns `true` for non-zero value and `false` otherwise. Unless we have some tricky `jboolean` value that should not happen they should behave the same?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13139#issuecomment-1482276217

From stsypanov at openjdk.org  Fri Mar 24 06:40:24 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Fri, 24 Mar 2023 06:40:24 GMT
Subject: RFR: 8304745: Lazily initialize byte[] in
 java.io.BufferedInputStream [v3]
In-Reply-To: 
References: 
Message-ID: 

> By default `BufferedInputStream` is constructed with internal buffer with capacity 8192. In some cases this buffer is never used, e.g. when we call `IS.readNBytes()` or `IS.readAllBytes()` (relying on `BIS.read1()`) or when `BufferedInputStream` is cascaded.

Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:

  8304745: Protect getBufIfOpen() from async close

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13150/files
  - new: https://git.openjdk.org/jdk/pull/13150/files/8e493a9d..407b26ed

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13150&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13150&range=01-02

  Stats: 19 lines in 1 file changed: 12 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/13150.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13150/head:pull/13150

PR: https://git.openjdk.org/jdk/pull/13150

From duke at openjdk.org  Fri Mar 24 06:42:30 2023
From: duke at openjdk.org (Hannes Greule)
Date: Fri, 24 Mar 2023 06:42:30 GMT
Subject: RFR: 8304837: Classfile API throws IOOBE for MethodParameters
 attribute without parameter names [v3]
In-Reply-To: 
References: 
Message-ID: 

> After merging master into https://github.com/openjdk/jdk/pull/9862, we encountered test failures (e.g., https://github.com/SirYwell/jdk/actions/runs/4500940829/jobs/7923018438#step:9:2541). The Classfile API tries to read from constant pool index 0 if a MethodParameters attribute has an entry without name.
> 
> The fix is simply using `readUtf8EntryOrNull` instead of `readUtf8Entry`. The related code already correctly handles nullability.
> 
> I didn't find an appropriate test class so I added a new one. Let me know if there's a better place or if the test can be improved somehow.
> 
> As I don't have a JBS account, someone needs to create a bug report there for me. Thanks.

Hannes Greule has updated the pull request incrementally with one additional commit since the last revision:

  Move and fix test comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13167/files
  - new: https://git.openjdk.org/jdk/pull/13167/files/f4b8062c..b77cc1b5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13167&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13167&range=01-02

  Stats: 12 lines in 1 file changed: 6 ins; 6 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13167.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13167/head:pull/13167

PR: https://git.openjdk.org/jdk/pull/13167

From duke at openjdk.org  Fri Mar 24 06:55:30 2023
From: duke at openjdk.org (Hannes Greule)
Date: Fri, 24 Mar 2023 06:55:30 GMT
Subject: RFR: 8304837: Classfile API throws IOOBE for MethodParameters
 attribute without parameter names [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 24 Mar 2023 06:42:30 GMT, Hannes Greule  wrote:

>> After merging master into https://github.com/openjdk/jdk/pull/9862, we encountered test failures (e.g., https://github.com/SirYwell/jdk/actions/runs/4500940829/jobs/7923018438#step:9:2541). The Classfile API tries to read from constant pool index 0 if a MethodParameters attribute has an entry without name.
>> 
>> The fix is simply using `readUtf8EntryOrNull` instead of `readUtf8Entry`. The related code already correctly handles nullability.
>> 
>> I didn't find an appropriate test class so I added a new one. Let me know if there's a better place or if the test can be improved somehow.
>> 
>> As I don't have a JBS account, someone needs to create a bug report there for me. Thanks.
>
> Hannes Greule has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move and fix test comment

Thanks for the review. I moved the comment and changed to `@bug`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13167#issuecomment-1482337115

From duke at openjdk.org  Fri Mar 24 08:12:30 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 24 Mar 2023 08:12:30 GMT
Subject: RFR: 8304013: Add a fast,
 non-manual alternative to test/jdk/java/util/zip/ZipFile/TestTooManyEntries
Message-ID: 

The TestTooManyEntries test was originally added to validate that ZIP64 files with CEN sizes exceeding what ZipFile  supports are rejected with a ZipException. The test does this by creating a large ZIP file (several gigabytes) with many enties. Because this is resource intensive, the test is currently tagged as manual.  (See #6927)

It would be useful to have a test which asserts the CEN size enforcement, but without the CPU, disk, memory and run time requirements of TestTooManyEntries.  Such a fast test can run non-manual,  without the @requires and manual tags as found in TestTooManyEntries.

This PR adds the EndOfCenValidation test which creates sparse test ZIPs where the CEN is "inflated" such that is matches the size declared in the "End of central directory" records.

While thee sparse files look large, they consume very little disk space on file systems supporting sparse files:


16 -rw-r--r--  1   2147483702 Feb  6 18:54 bad-cen-offset.zip
16 -rw-r--r--  1   2147483703 Feb  6 18:54 cen-size-too-large.zip
 8 -rw-r--r--  1          132 Feb  6 18:54 invalid-zen-size.zip
``` 

For good measure, two new test methods are added to excercise the remaining ZipExceptions which ZipFile may throw during validation of the END record .

-------------

Commit messages:
 - Add a third DEFLATED entry to the test ZIP. Look up CEN offset from END header instead of skipping LOC headers. Add asserts that verifies that the ZIP has the expected entries. Write some data to the entry in the sample ZIP. Remove try/catch when opening ZipFile.
 - Merge branch 'master' into zip-too-many-entries
 - Inlining the openZip method makes the tests more explicit
 - Clean up potentially big files after test
 - Sparse files must be created explicitly on NTFS
 - Merge branch 'master' into zip-too-many-entries
 - Replace expectedExceptions annotations with expectThrows and assertEquals
 - Merge branch 'master' into zip-too-many-entries
 - Fix spelling in comment
 - Inflate the CEN size using sparse files such that it matches the size declared in the End of central directory record. Add a new test which verifies the rejection of too-large CEN offset. Revert the change to END validation in ZipFile which is no longer needed.
 - ... and 13 more: https://git.openjdk.org/jdk/compare/63d4afbe...e348201f

Changes: https://git.openjdk.org/jdk/pull/12231/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12231&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304013
  Stats: 231 lines in 1 file changed: 231 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12231.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12231/head:pull/12231

PR: https://git.openjdk.org/jdk/pull/12231

From lancea at openjdk.org  Fri Mar 24 08:12:38 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 24 Mar 2023 08:12:38 GMT
Subject: RFR: 8304013: Add a fast,
 non-manual alternative to test/jdk/java/util/zip/ZipFile/TestTooManyEntries
In-Reply-To: 
References: 
Message-ID: 

On Thu, 26 Jan 2023 18:49:47 GMT, Eirik Bjorsnos  wrote:

> The TestTooManyEntries test was originally added to validate that ZIP64 files with CEN sizes exceeding what ZipFile  supports are rejected with a ZipException. The test does this by creating a large ZIP file (several gigabytes) with many enties. Because this is resource intensive, the test is currently tagged as manual.  (See #6927)
> 
> It would be useful to have a test which asserts the CEN size enforcement, but without the CPU, disk, memory and run time requirements of TestTooManyEntries.  Such a fast test can run non-manual,  without the @requires and manual tags as found in TestTooManyEntries.
> 
> This PR adds the EndOfCenValidation test which creates sparse test ZIPs where the CEN is "inflated" such that is matches the size declared in the "End of central directory" records.
> 
> While thee sparse files look large, they consume very little disk space on file systems supporting sparse files:
> 
> 
> 16 -rw-r--r--  1   2147483702 Feb  6 18:54 bad-cen-offset.zip
> 16 -rw-r--r--  1   2147483703 Feb  6 18:54 cen-size-too-large.zip
>  8 -rw-r--r--  1          132 Feb  6 18:54 invalid-zen-size.zip
> ``` 
> 
> For good measure, two new test methods are added to excercise the remaining ZipExceptions which ZipFile may throw during validation of the END record .

Thanks for the updates.

Please see the additional suggestions below

I think the changes are are looking good.  Please see the comments below.

thank you again for your efforts here

test/jdk/java/util/zip/ZipFile/CenSizeTooLarge.java line 47:

> 45: import static org.testng.Assert.fail;
> 46: 
> 47: public class CenSizeTooLarge {

I would add a comment which also points to the original test

test/jdk/java/util/zip/ZipFile/CenSizeTooLarge.java line 52:

> 50:     private static final int CEN_SIZE_OFFSET = 12; // Offset of CEN size field within ENDHDR
> 51:     private Path huge; // ZIP file with CEN size exceeding limit
> 52:     private Path big;  // ZIP file with CEN size exactly on the limit

You might consider more meaningful names for the Paths

test/jdk/java/util/zip/ZipFile/CenSizeTooLarge.java line 92:

> 90:     private void assertRejected(Path zip, String expectedMsg) throws IOException {
> 91:         try (ZipFile zf = new ZipFile(zip.toFile())) {
> 92:             fail("Expected ZipFile to throw ZipException");

You could consider using expectThrows and then validation the value of getMessage()

test/jdk/java/util/zip/ZipFile/CenSizeTooLarge.java line 107:

> 105:      * to test that the large CEN size is rejected
> 106:      */
> 107:     private Path zipWithCenSize(String name, int cenSize) throws IOException {

You could speed this up a bit more by just creating the array representing the original Zip 1 time and modify it each pass.(though it might not speed things up that much)

test/jdk/java/util/zip/ZipFile/EndOfCenValidation.java line 113:

> 111:             try (ZipFile zf = new ZipFile(zip.toFile())) {
> 112:             }
> 113:         });

You can omit the try block

test/jdk/java/util/zip/ZipFile/EndOfCenValidation.java line 133:

> 131:             }
> 132:         });
> 133: 

Same comment as above.

test/jdk/java/util/zip/ZipFile/EndOfCenValidation.java line 177:

> 175:                                           Path zip) throws IOException {
> 176: 
> 177:         Files.deleteIfExists(zip);

Is this needed?  I think I would just call the cleanup method from the setup method

test/jdk/java/util/zip/ZipFile/EndOfCenValidation.java line 219:

> 217:     }
> 218: 
> 219:     // Produce a byte array of a ZIP with a single entry

Minor nit, I would use the same comment format for the methods as above and probably add an @throws as needed so javadoc tag checks won't fail

test/jdk/java/util/zip/ZipFile/EndOfCenValidation.java line 223:

> 221:         ByteArrayOutputStream bout = new ByteArrayOutputStream();
> 222:         try (ZipOutputStream zout = new ZipOutputStream(bout)) {
> 223:             zout.putNextEntry(new ZipEntry("duke.txt"));

Perhaps clarify why you are not writing out any data...

-------------

PR Review: https://git.openjdk.org/jdk/pull/12231#pullrequestreview-1277002825
PR Review: https://git.openjdk.org/jdk/pull/12231#pullrequestreview-1355381891
PR Review Comment: https://git.openjdk.org/jdk/pull/12231#discussion_r1091806763
PR Review Comment: https://git.openjdk.org/jdk/pull/12231#discussion_r1091806173
PR Review Comment: https://git.openjdk.org/jdk/pull/12231#discussion_r1091817123
PR Review Comment: https://git.openjdk.org/jdk/pull/12231#discussion_r1091805101
PR Review Comment: https://git.openjdk.org/jdk/pull/12231#discussion_r1146689004
PR Review Comment: https://git.openjdk.org/jdk/pull/12231#discussion_r1146700985
PR Review Comment: https://git.openjdk.org/jdk/pull/12231#discussion_r1146704271
PR Review Comment: https://git.openjdk.org/jdk/pull/12231#discussion_r1146702440
PR Review Comment: https://git.openjdk.org/jdk/pull/12231#discussion_r1146705913

From duke at openjdk.org  Fri Mar 24 08:12:40 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 24 Mar 2023 08:12:40 GMT
Subject: RFR: 8304013: Add a fast,
 non-manual alternative to test/jdk/java/util/zip/ZipFile/TestTooManyEntries
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 31 Jan 2023 11:38:07 GMT, Lance Andersen  wrote:

>> The TestTooManyEntries test was originally added to validate that ZIP64 files with CEN sizes exceeding what ZipFile  supports are rejected with a ZipException. The test does this by creating a large ZIP file (several gigabytes) with many enties. Because this is resource intensive, the test is currently tagged as manual.  (See #6927)
>> 
>> It would be useful to have a test which asserts the CEN size enforcement, but without the CPU, disk, memory and run time requirements of TestTooManyEntries.  Such a fast test can run non-manual,  without the @requires and manual tags as found in TestTooManyEntries.
>> 
>> This PR adds the EndOfCenValidation test which creates sparse test ZIPs where the CEN is "inflated" such that is matches the size declared in the "End of central directory" records.
>> 
>> While thee sparse files look large, they consume very little disk space on file systems supporting sparse files:
>> 
>> 
>> 16 -rw-r--r--  1   2147483702 Feb  6 18:54 bad-cen-offset.zip
>> 16 -rw-r--r--  1   2147483703 Feb  6 18:54 cen-size-too-large.zip
>>  8 -rw-r--r--  1          132 Feb  6 18:54 invalid-zen-size.zip
>> ``` 
>> 
>> For good measure, two new test methods are added to excercise the remaining ZipExceptions which ZipFile may throw during validation of the END record .
>
> test/jdk/java/util/zip/ZipFile/CenSizeTooLarge.java line 47:
> 
>> 45: import static org.testng.Assert.fail;
>> 46: 
>> 47: public class CenSizeTooLarge {
> 
> I would add a comment which also points to the original test

Added a comment referring to TestTooManyEntries explaining why this test exists.

> test/jdk/java/util/zip/ZipFile/CenSizeTooLarge.java line 52:
> 
>> 50:     private static final int CEN_SIZE_OFFSET = 12; // Offset of CEN size field within ENDHDR
>> 51:     private Path huge; // ZIP file with CEN size exceeding limit
>> 52:     private Path big;  // ZIP file with CEN size exactly on the limit
> 
> You might consider more meaningful names for the Paths

I've removed these fields now and instead produce the files in the test methods directly, removing the need to name the fields.

> test/jdk/java/util/zip/ZipFile/CenSizeTooLarge.java line 92:
> 
>> 90:     private void assertRejected(Path zip, String expectedMsg) throws IOException {
>> 91:         try (ZipFile zf = new ZipFile(zip.toFile())) {
>> 92:             fail("Expected ZipFile to throw ZipException");
> 
> You could consider using expectThrows and then validation the value of getMessage()

Replaced with expectedExceptions and expectedExceptionsMessageRegExp

> test/jdk/java/util/zip/ZipFile/CenSizeTooLarge.java line 107:
> 
>> 105:      * to test that the large CEN size is rejected
>> 106:      */
>> 107:     private Path zipWithCenSize(String name, int cenSize) throws IOException {
> 
> You could speed this up a bit more by just creating the array representing the original Zip 1 time and modify it each pass.(though it might not speed things up that much)

I introduced the templateZip() method which returns a byte[]. While the speed is insignificat here, I think it makes it more explicit that we're producing ZIPs from a template.

> test/jdk/java/util/zip/ZipFile/EndOfCenValidation.java line 113:
> 
>> 111:             try (ZipFile zf = new ZipFile(zip.toFile())) {
>> 112:             }
>> 113:         });
> 
> You can omit the try block

I removed the try/catch block with a quivering lower lip :-)

> test/jdk/java/util/zip/ZipFile/EndOfCenValidation.java line 177:
> 
>> 175:                                           Path zip) throws IOException {
>> 176: 
>> 177:         Files.deleteIfExists(zip);
> 
> Is this needed?  I think I would just call the cleanup method from the setup method

Sparse files need to be created as such. The purpose of this delete exists to make this explicit. I moved this closer to the FileChannel.open and added a comment to explain the delete.

> test/jdk/java/util/zip/ZipFile/EndOfCenValidation.java line 219:
> 
>> 217:     }
>> 218: 
>> 219:     // Produce a byte array of a ZIP with a single entry
> 
> Minor nit, I would use the same comment format for the methods as above and probably add an @throws as needed so javadoc tag checks won't fail

Changed to block comment style and added @throws.

> test/jdk/java/util/zip/ZipFile/EndOfCenValidation.java line 223:
> 
>> 221:         ByteArrayOutputStream bout = new ByteArrayOutputStream();
>> 222:         try (ZipOutputStream zout = new ZipOutputStream(bout)) {
>> 223:             zout.putNextEntry(new ZipEntry("duke.txt"));
> 
> Perhaps clarify why you are not writing out any data...

No particular reason, so I opted to output some data instead of explaining.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12231#discussion_r1094495050
PR Review Comment: https://git.openjdk.org/jdk/pull/12231#discussion_r1094491416
PR Review Comment: https://git.openjdk.org/jdk/pull/12231#discussion_r1094495538
PR Review Comment: https://git.openjdk.org/jdk/pull/12231#discussion_r1094493992
PR Review Comment: https://git.openjdk.org/jdk/pull/12231#discussion_r1147233013
PR Review Comment: https://git.openjdk.org/jdk/pull/12231#discussion_r1147234584
PR Review Comment: https://git.openjdk.org/jdk/pull/12231#discussion_r1147233518
PR Review Comment: https://git.openjdk.org/jdk/pull/12231#discussion_r1147234962

From duke at openjdk.org  Fri Mar 24 08:12:41 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 24 Mar 2023 08:12:41 GMT
Subject: RFR: 8304013: Add a fast,
 non-manual alternative to test/jdk/java/util/zip/ZipFile/TestTooManyEntries
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 2 Feb 2023 12:57:15 GMT, Eirik Bjorsnos  wrote:

>> test/jdk/java/util/zip/ZipFile/CenSizeTooLarge.java line 92:
>> 
>>> 90:     private void assertRejected(Path zip, String expectedMsg) throws IOException {
>>> 91:         try (ZipFile zf = new ZipFile(zip.toFile())) {
>>> 92:             fail("Expected ZipFile to throw ZipException");
>> 
>> You could consider using expectThrows and then validation the value of getMessage()
>
> Replaced with expectedExceptions and expectedExceptionsMessageRegExp

Now that I finally understand what you meant by this, I've update to use expectThrows and assertEquals :-)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12231#discussion_r1105861315

From duke at openjdk.org  Fri Mar 24 08:46:36 2023
From: duke at openjdk.org (ExE Boss)
Date: Fri, 24 Mar 2023 08:46:36 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v8]
In-Reply-To: <4JIhKmX2VnDfArfFl-1YJfoUzGGBVA5Uvd3mdpatW-s=.5d86f29e-5475-4a4a-91df-d6418356e204@github.com>
References: 
 <4JIhKmX2VnDfArfFl-1YJfoUzGGBVA5Uvd3mdpatW-s=.5d86f29e-5475-4a4a-91df-d6418356e204@github.com>
Message-ID: 

On Wed, 22 Mar 2023 14:09:07 GMT, Per Minborg  wrote:

>> API changes for the FFM API (third preview)
>> 
>> Specdiff:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
>> 
>> Javadoc:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve javadocs for Linker::captureStateLayout

src/java.base/share/classes/jdk/internal/foreign/abi/SharedUtils.java line 297:

> 295:         MethodType mtype = mh.type();
> 296:         int[] perms = new int[mtype.parameterCount()];
> 297:         MethodType swappedType = MethodType.methodType(mtype.returnType());

Instead?of `MethodType::appendParameterTypes(?)` (which?performs an?expensive?lookup of?a?new?cached `MethodType` value per?call), this?method should?instead use?a?`Class[]` for?the?arguments, which?avoids that?overhead inside?a?loop:

	public static MethodHandle swapArguments(MethodHandle mh, int firstArg, int secondArg) {
		MethodType mtype = mh.type();
		int[] perms = new int[mtype.parameterCount()];
		Class[] ptypes = new Class[perms.length];
		for (int i = 0 ; i < perms.length ; i++) {
			int dst = i;
			if (i == firstArg) dst = secondArg;
			else if (i == secondArg) dst = firstArg;
			perms[i] = dst;
			ptypes[i] = mtype.parameterType(dst);
		}
		// This should use `JavaLangInvokeAccess` to invoke the internal
		// `MethodType.methodType(Class rtype, Class[] ptypes, boolean trusted)`
		// method with a `trusted` value of `true`:
		MethodType swappedType = MethodType.methodType(mtype.returnType(), ptypes);
		return permuteArguments(mh, swappedType, perms);
	}

src/java.base/share/classes/jdk/internal/foreign/abi/fallback/LibFallback.java line 61:

> 59:     static final MemorySegment VOID_TYPE = MemorySegment.ofAddress(ffi_type_void());
> 60:     static final short STRUCT_TAG = ffi_type_struct();
> 61:     private static final long SIZEOF_CIF = sizeofCif();

Won?t?calling `ffi_default_abi()` (and?the?other `ffi_*()`?methods) throw?`UnsatisfiedLinkError` if?`SUPPORTED`?is?`false`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1147259998
PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1147267292

From alanb at openjdk.org  Fri Mar 24 10:30:41 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 24 Mar 2023 10:30:41 GMT
Subject: RFR: 8304745: Lazily initialize byte[] in
 java.io.BufferedInputStream [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 24 Mar 2023 06:40:24 GMT, Sergey Tsypanov  wrote:

>> By default `BufferedInputStream` is constructed with internal buffer with capacity 8192. In some cases this buffer is never used, e.g. when we call `IS.readNBytes()` or `IS.readAllBytes()` (relying on `BIS.read1()`) or when `BufferedInputStream` is cascaded.
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8304745: Protect getBufIfOpen() from async close

I skimmed through the latest version but there are still several issues.  Can you try the patch below instead? This will ensure that read, skip, reset, etc. check buf as before. It also ensures that read1 does the same threshold check as it has always done - your patch changes that in a subtle way and I think we have to be careful with behavior changes to this really old API.

To Eirik's comment about benchmarks. This change is about memory footprint and lazily creating the internal buffer. A good example is the BIS on stdin which has an 8k buffer that is only needed if something reads from System.in. There may be a few more like this. The other case is a large read where BIS will delegate to the wrapped stream when it doesn't have any bytes buffered. It would be useful to get some data on cases where it helps (the BIS wrapping BIS only works when the enclosing BIS has the same or larger buffer than the enclosed BIS).


--- a/src/java.base/share/classes/java/io/BufferedInputStream.java
+++ b/src/java.base/share/classes/java/io/BufferedInputStream.java
@@ -57,6 +57,8 @@ public class BufferedInputStream extends FilterInputStream {
 
     private static final int DEFAULT_BUFFER_SIZE = 8192;
 
+    private static final byte[] EMPTY = new byte[0];
+
     /**
      * As this class is used early during bootstrap, it's motivated to use
      * Unsafe.compareAndSetObject instead of AtomicReferenceFieldUpdater
@@ -70,6 +72,9 @@ public class BufferedInputStream extends FilterInputStream {
     // initialized to null when BufferedInputStream is sub-classed
     private final InternalLock lock;
 
+    // initial buffer size (DEFAULT_BUFFER_SIZE or size specified to constructor)
+    private final int initialSize;
+
     /**
      * The internal buffer array where the data is stored. When necessary,
      * it may be replaced by another array of
@@ -166,16 +171,42 @@ public class BufferedInputStream extends FilterInputStream {
     }
 
     /**
-     * Check to make sure that buffer has not been nulled out due to
-     * close; if not return it;
+     * Returns the internal buffer, optionally allocating it if empty.
+     * @param allocateIfEmpty true to allocate if empty
+     * @throws IOException if the stream is closed (buf is null)
      */
-    private byte[] getBufIfOpen() throws IOException {
+    private byte[] getBufIfOpen(boolean allocateIfEmpty) throws IOException {
         byte[] buffer = buf;
-        if (buffer == null)
+        if (allocateIfEmpty && buffer == EMPTY) {
+            buffer = new byte[initialSize];
+            if (!U.compareAndSetReference(this, BUF_OFFSET, EMPTY, buffer)) {
+                // re-read buf
+                buffer = buf;
+            }
+        }
+        if (buffer == null) {
             throw new IOException("Stream closed");
+        }
         return buffer;
     }
 
+    /**
+     * Returns the internal buffer, allocating it if empty.
+     * @throws IOException if the stream is closed (buf is null)
+     */
+    private byte[] getBufIfOpen() throws IOException {
+        return getBufIfOpen(true);
+    }
+
+    /**
+     * Throws IOException if the stream is closed (buf is null).
+     */
+    private void ensureOpen() throws IOException {
+        if (buf == null) {
+            throw new IOException("Stream closed");
+        }
+    }
+
     /**
      * Creates a {@code BufferedInputStream}
      * and saves its  argument, the input stream
@@ -205,13 +236,15 @@ public class BufferedInputStream extends FilterInputStream {
         if (size <= 0) {
             throw new IllegalArgumentException("Buffer size <= 0");
         }
-        buf = new byte[size];
-
-        // use monitors when BufferedInputStream is sub-classed
+        initialSize = size;
         if (getClass() == BufferedInputStream.class) {
+            // use internal lock and lazily create buffer when not subclassed
             lock = InternalLock.newLockOrNull();
+            buf = EMPTY;
         } else {
+            // use monitors and eagerly create buffer when subclassed
             lock = null;
+            buf = new byte[size];
         }
     }
 
@@ -307,7 +340,8 @@ public class BufferedInputStream extends FilterInputStream {
                if there is no mark/reset activity, do not bother to copy the
                bytes into the local buffer.  In this way buffered streams will
                cascade harmlessly. */
-            if (len >= getBufIfOpen().length && markpos == -1) {
+            int size = Math.max(getBufIfOpen(false).length, initialSize);
+            if (len >= size && markpos == -1) {
                 return getInIfOpen().read(b, off, len);
             }
             fill();
@@ -374,7 +408,7 @@ public class BufferedInputStream extends FilterInputStream {
     }
 
     private int implRead(byte[] b, int off, int len) throws IOException {
-        getBufIfOpen(); // Check for closed stream
+        ensureOpen();
         if ((off | len | (off + len) | (b.length - (off + len))) < 0) {
             throw new IndexOutOfBoundsException();
         } else if (len == 0) {
@@ -421,7 +455,7 @@ public class BufferedInputStream extends FilterInputStream {
     }
 
     private long implSkip(long n) throws IOException {
-        getBufIfOpen(); // Check for closed stream
+        ensureOpen();
         if (n <= 0) {
             return 0;
         }
@@ -544,7 +578,7 @@ public class BufferedInputStream extends FilterInputStream {
     }
 
     private void implReset() throws IOException {
-        getBufIfOpen(); // Cause exception if closed
+        ensureOpen();
         if (markpos < 0)
             throw new IOException("Resetting to invalid mark");
         pos = markpos;

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13150#issuecomment-1482577711

From stsypanov at openjdk.org  Fri Mar 24 11:27:12 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Fri, 24 Mar 2023 11:27:12 GMT
Subject: RFR: 8304745: Lazily initialize byte[] in
 java.io.BufferedInputStream [v4]
In-Reply-To: 
References: 
Message-ID: 

> By default `BufferedInputStream` is constructed with internal buffer with capacity 8192. In some cases this buffer is never used, e.g. when we call `IS.readNBytes()` or `IS.readAllBytes()` (relying on `BIS.read1()`) or when `BufferedInputStream` is cascaded.

Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:

  8304745: Rework

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13150/files
  - new: https://git.openjdk.org/jdk/pull/13150/files/407b26ed..db4b1c93

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13150&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13150&range=02-03

  Stats: 61 lines in 1 file changed: 28 ins; 16 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/13150.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13150/head:pull/13150

PR: https://git.openjdk.org/jdk/pull/13150

From stsypanov at openjdk.org  Fri Mar 24 11:37:40 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Fri, 24 Mar 2023 11:37:40 GMT
Subject: RFR: 8304745: Lazily initialize byte[] in
 java.io.BufferedInputStream [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 24 Mar 2023 10:27:45 GMT, Alan Bateman  wrote:

> This will ensure that read, skip, reset, etc. check buf as before

Why do we so heavily rely on `buf` if we can do open/close check with `getInIfOpen()`?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13150#issuecomment-1482661477

From lancea at openjdk.org  Fri Mar 24 12:29:30 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 24 Mar 2023 12:29:30 GMT
Subject: RFR: 8304013: Add a fast,
 non-manual alternative to test/jdk/java/util/zip/ZipFile/TestTooManyEntries
In-Reply-To: 
References: 
Message-ID: 

On Thu, 26 Jan 2023 18:49:47 GMT, Eirik Bjorsnos  wrote:

> The TestTooManyEntries test was originally added to validate that ZIP64 files with CEN sizes exceeding what ZipFile  supports are rejected with a ZipException. The test does this by creating a large ZIP file (several gigabytes) with many enties. Because this is resource intensive, the test is currently tagged as manual.  (See #6927)
> 
> It would be useful to have a test which asserts the CEN size enforcement, but without the CPU, disk, memory and run time requirements of TestTooManyEntries.  Such a fast test can run non-manual,  without the @requires and manual tags as found in TestTooManyEntries.
> 
> This PR adds the EndOfCenValidation test which creates sparse test ZIPs where the CEN is "inflated" such that is matches the size declared in the "End of central directory" records.
> 
> While thee sparse files look large, they consume very little disk space on file systems supporting sparse files:
> 
> 
> 16 -rw-r--r--  1   2147483702 Feb  6 18:54 bad-cen-offset.zip
> 16 -rw-r--r--  1   2147483703 Feb  6 18:54 cen-size-too-large.zip
>  8 -rw-r--r--  1          132 Feb  6 18:54 invalid-zen-size.zip
> ``` 
> 
> For good measure, two new test methods are added to excercise the remaining ZipExceptions which ZipFile may throw during validation of the END record .

Thank you for the updates.

I am going to kick of a Mach 5 run

-------------

PR Review: https://git.openjdk.org/jdk/pull/12231#pullrequestreview-1356597699

From lancea at openjdk.org  Fri Mar 24 12:29:32 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 24 Mar 2023 12:29:32 GMT
Subject: RFR: 8304013: Add a fast,
 non-manual alternative to test/jdk/java/util/zip/ZipFile/TestTooManyEntries
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 24 Mar 2023 08:05:19 GMT, Eirik Bjorsnos  wrote:

>> test/jdk/java/util/zip/ZipFile/EndOfCenValidation.java line 177:
>> 
>>> 175:                                           Path zip) throws IOException {
>>> 176: 
>>> 177:         Files.deleteIfExists(zip);
>> 
>> Is this needed?  I think I would just call the cleanup method from the setup method
>
> Sparse files need to be created as such. The purpose of this delete exists to make this explicit. I moved this closer to the FileChannel.open and added a comment to explain the delete.

I am fine leaving it, but still not convinced it is needed if the setup method calls the cleanup method and should achieve the same result.  Again no big deal.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12231#discussion_r1147515419

From duke at openjdk.org  Fri Mar 24 12:36:30 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 24 Mar 2023 12:36:30 GMT
Subject: RFR: 8304013: Add a fast,
 non-manual alternative to test/jdk/java/util/zip/ZipFile/TestTooManyEntries
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Fri, 24 Mar 2023 12:25:55 GMT, Lance Andersen  wrote:

>> Sparse files need to be created as such. The purpose of this delete exists to make this explicit. I moved this closer to the FileChannel.open and added a comment to explain the delete.
>
> I am fine leaving it, but still not convinced it is needed if the setup method calls the cleanup method and should achieve the same result.  Again no big deal.

Thanks, I agree it is not technically required in this exact context.

The reason I want to keep it is that someone might do a search  for `StandardOpenOption.SPARSE`, find this code and copy it. I think the delete with the comment makes it explicit that preexisting files will not magically be made sparse after the fact. It makes the code samle self-contained.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12231#discussion_r1147522464

From asotona at openjdk.org  Fri Mar 24 13:06:30 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 24 Mar 2023 13:06:30 GMT
Subject: RFR: 8304837: Classfile API throws IOOBE for MethodParameters
 attribute without parameter names [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 24 Mar 2023 06:42:30 GMT, Hannes Greule  wrote:

>> After merging master into https://github.com/openjdk/jdk/pull/9862, we encountered test failures (e.g., https://github.com/SirYwell/jdk/actions/runs/4500940829/jobs/7923018438#step:9:2541). The Classfile API tries to read from constant pool index 0 if a MethodParameters attribute has an entry without name.
>> 
>> The fix is simply using `readUtf8EntryOrNull` instead of `readUtf8Entry`. The related code already correctly handles nullability.
>> 
>> I didn't find an appropriate test class so I added a new one. Let me know if there's a better place or if the test can be improved somehow.
>> 
>> As I don't have a JBS account, someone needs to create a bug report there for me. Thanks.
>
> Hannes Greule has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move and fix test comment

It looks good, thank you for finding and fixing the bug.

-------------

Marked as reviewed by asotona (Committer).

PR Review: https://git.openjdk.org/jdk/pull/13167#pullrequestreview-1356657144

From jwaters at openjdk.org  Fri Mar 24 14:50:33 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 24 Mar 2023 14:50:33 GMT
Subject: RFR: 8304717: Declaration aliasing between boolean and jboolean is
 wrong [v2]
In-Reply-To: 
References: <9Xij1FEbLnMYTPIZOOhGyaKnlplxP6Wp3ODS2bKP7u0=.146017ce-32ee-40f3-8496-49c014f7decb@github.com>
 
Message-ID: 

On Thu, 23 Mar 2023 22:23:00 GMT, Julian Waters  wrote:

>> A couple of spots wrongly refer to boolean and jboolean as the same thing. While this does still compile thanks to a happy accident and implicit conversions, they are not the same at all, and should be fixed before a future compiler error happens if their declarations are touched
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   MacOSXPreferencesFile.m

I'd argue it's more for correctness: Indeed it will still compile fine as of now, but the type of jboolean is not the only thing that can change; the other typedef'd boolean type can also be modified later on. Additionally, with compilers getting stricter as newer releases drop, it's a good idea to make sure the signatures match as best as possible, especially between declarations and definitions of the same method

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13139#issuecomment-1482925961

From stsypanov at openjdk.org  Fri Mar 24 15:40:40 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Fri, 24 Mar 2023 15:40:40 GMT
Subject: RFR: 8304745: Lazily initialize byte[] in
 java.io.BufferedInputStream [v5]
In-Reply-To: 
References: 
Message-ID: 

> By default `BufferedInputStream` is constructed with internal buffer with capacity 8192. In some cases this buffer is never used, e.g. when we call `IS.readNBytes()` or `IS.readAllBytes()` (relying on `BIS.read1()`) or when `BufferedInputStream` is cascaded.

Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:

  8304745: Add benchmark

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13150/files
  - new: https://git.openjdk.org/jdk/pull/13150/files/db4b1c93..f1877548

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13150&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13150&range=03-04

  Stats: 64 lines in 1 file changed: 64 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13150.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13150/head:pull/13150

PR: https://git.openjdk.org/jdk/pull/13150

From stsypanov at openjdk.org  Fri Mar 24 15:40:46 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Fri, 24 Mar 2023 15:40:46 GMT
Subject: RFR: 8304745: Lazily initialize byte[] in
 java.io.BufferedInputStream [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 23 Mar 2023 21:15:44 GMT, Eirik Bjorsnos  wrote:

>> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/java.base/share/classes/java/io/BufferedInputStream.java
>>   
>>   Co-authored-by: liach <7806504+liach at users.noreply.github.com>
>
> My last comment was so heavily edited, I think it makes sense to delete it and include the last edit here:
> 
>> @eirbjo you mean benchmark for BIS instantiation?
> 
> My general thought is that a benchmark demonstrating the proposed performance benefits is always good and should perhaps be a requirement for such performance related changes. An effort should be made to detect regressions as well. This is just my personal preference, won't claim this is policy of any kind.
> 
> Until something is benchmarked, nobody knows if the benefit is just speculation.
> 
> I have experienced and suggested several PRs myself which benchmark work later showed dubious improvements which cased the change to be withdrawn.
> 
> In https://github.com/openjdk/jdk/pull/13121, I ran some (existing) benchmark on the PR only to discover it seems to have a weird, subtle regression.
> 
> Besides this: A benchmark also help you save the performance improvements for the future. Without a benchmark, it is easier for someone to come along and nullify your improvements by some independent change.
> 
> Personal bottom line: When a PR is motivated by performance, suggested benefits should be demonstrated through benchmarks.
> 
> Very bottom line: I do not claim that this PR has no performance benefits.
> 
> Final bottom line: Performance claims need proofs and the proof needs to fit in the margin.

@eirbjo added benchmark

aster

Benchmark                                                             Mode  Cnt      Score     Error   Units
BufferedInputStreamBenchmark.readAllBytes                             avgt   20      4.717 ?   0.620   us/op
BufferedInputStreamBenchmark.readAllBytes:?gc.alloc.rate              avgt   20   5313.239 ? 678.404  MB/sec
BufferedInputStreamBenchmark.readAllBytes:?gc.alloc.rate.norm         avgt   20  25752.007 ?   0.001    B/op
BufferedInputStreamBenchmark.readAllBytes:?gc.count                   avgt   20    201.000            counts
BufferedInputStreamBenchmark.readAllBytes:?gc.time                    avgt   20    840.000                ms
BufferedInputStreamBenchmark.readAllBytesCascade                      avgt   20      8.815 ?   5.016   us/op
BufferedInputStreamBenchmark.readAllBytesCascade:?gc.alloc.rate       avgt   20   4156.740 ? 685.852  MB/sec
BufferedInputStreamBenchmark.readAllBytesCascade:?gc.alloc.rate.norm  avgt   20  34064.013 ?   0.007    B/op
BufferedInputStreamBenchmark.readAllBytesCascade:?gc.count            avgt   20    138.000            counts
BufferedInputStreamBenchmark.readAllBytesCascade:?gc.time             avgt   20    933.000                ms


8304745

Benchmark                                                             Mode  Cnt      Score     Error   Units
BufferedInputStreamBenchmark.readAllBytes                             avgt   20      2.931 ?   0.208   us/op
BufferedInputStreamBenchmark.readAllBytes:?gc.alloc.rate              avgt   20   5738.023 ? 369.653  MB/sec
BufferedInputStreamBenchmark.readAllBytes:?gc.alloc.rate.norm         avgt   20  17552.004 ?   0.001    B/op
BufferedInputStreamBenchmark.readAllBytes:?gc.count                   avgt   20    168.000            counts
BufferedInputStreamBenchmark.readAllBytes:?gc.time                    avgt   20   1254.000                ms
BufferedInputStreamBenchmark.readAllBytesCascade                      avgt   20      3.219 ?   0.177   us/op
BufferedInputStreamBenchmark.readAllBytesCascade:?gc.alloc.rate       avgt   20   5247.600 ? 288.255  MB/sec
BufferedInputStreamBenchmark.readAllBytesCascade:?gc.alloc.rate.norm  avgt   20  17664.005 ?   0.001    B/op
BufferedInputStreamBenchmark.readAllBytesCascade:?gc.count            avgt   20    157.000            counts
BufferedInputStreamBenchmark.readAllBytesCascade:?gc.time             avgt   20   1168.000                ms

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13150#issuecomment-1483001720

From jlaskey at openjdk.org  Fri Mar 24 15:43:37 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 24 Mar 2023 15:43:37 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v3]
In-Reply-To: 
References: 
 
 
 
 <9vQMc2mMDyHm5uoAKuvtqGm4pyJdVdSRIKGmfrEBQvI=.f7cd331b-4185-4f9b-9e94-0893090d0e53@github.com>
 
Message-ID: 

On Wed, 22 Mar 2023 23:26:13 GMT, Chen Liang  wrote:

>> As i said above, i consider this thread as resolved
>
> Suggestion:
> 
>      * to {@value #MAX_INDY_CONCAT_ARG_SLOTS}.

Changing

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1147748029

From jlaskey at openjdk.org  Fri Mar 24 15:43:45 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 24 Mar 2023 15:43:45 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 22 Mar 2023 23:27:20 GMT, Chen Liang  wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Tidy javadoc
>>  - Rename StringTemplate classes
>
> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1051:
> 
>> 1049:      * @param ptypes    list of expression types
>> 1050:      *
>> 1051:      * @return {@link MethodHandle}
> 
> Suggestion:
> 
>      * @return the {@link MethodHandle} for concatenation

Changing

> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1169:
> 
>> 1167:      * have an extra {@link String} slot for the result from the previous
>> 1168:      * {@link MethodHandle}.
>> 1169:      * {@link java.lang.invoke.StringConcatFactory#makeConcatWithTemplate}
> 
> Suggestion:
> 
>      * {@link #makeConcatWithTemplate}

Changing

> src/java.base/share/classes/java/lang/runtime/Carriers.java line 370:
> 
>> 368:          */
>> 369:         private static Map
>> 370:                 methodTypeCache = ReferencedKeyMap.create(() -> new ConcurrentHashMap<>());
> 
> Suggestion:
> 
>                 methodTypeCache = ReferencedKeyMap.create(ConcurrentHashMap::new);

Changing

> src/java.base/share/classes/java/lang/runtime/Carriers.java line 421:
> 
>> 419:          */
>> 420:         protected CarrierObject(int primitiveCount, int objectCount) {
>> 421:             this.primitives = createPrimitivesArray(primitiveCount );
> 
> Suggestion:
> 
>             this.primitives = createPrimitivesArray(primitiveCount);

Changing

> src/java.base/share/classes/java/lang/runtime/Carriers.java line 776:
> 
>> 774:          * @throws IllegalArgumentException if number of component slots exceeds maximum
>> 775:          */
>> 776:         static CarrierElements of(Class < ? >...ptypes) {
> 
> Suggestion:
> 
>         static CarrierElements of(Class... ptypes) {

Changing

> src/java.base/share/classes/java/lang/runtime/ReferenceKey.java line 49:
> 
>> 47: interface ReferenceKey {
>> 48:     /**
>> 49:      * {@return the value of the unwrapped key.}
> 
> Suggestion:
> 
>      * {@return the value of the unwrapped key}
> 
> Inline return tag generates a period already.

Changing

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1147750445
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1147752071
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1147757381
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1147752347
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1147755043
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1147757878

From sgehwolf at openjdk.org  Fri Mar 24 15:44:59 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 24 Mar 2023 15:44:59 GMT
Subject: RFR: 8304871: Use default visibility for static library builds
Message-ID: 

Please review this change for symbol visibility of static library artefacts. This fixes an issue when
OpenJDK is being used as a base for generating native images preventing the symbols from being
exported and looked up from the executable. Note that symbol visibity is now controlled by a
linker version script downstream. This changes nothing for the regularly shipped dynamic libraries.

Thoughts?

-------------

Commit messages:
 - 8304871: Use default visibility for static library builds

Changes: https://git.openjdk.org/jdk/pull/13177/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13177&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304871
  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13177.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13177/head:pull/13177

PR: https://git.openjdk.org/jdk/pull/13177

From jlaskey at openjdk.org  Fri Mar 24 15:51:17 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 24 Mar 2023 15:51:17 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 22 Mar 2023 23:56:48 GMT, Chen Liang  wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Tidy javadoc
>>  - Rename StringTemplate classes
>
> src/java.base/share/classes/java/lang/runtime/ReferencedKeyMap.java line 127:
> 
>> 125:     @SuppressWarnings("unchecked")
>> 126:     static  ReferencedKeyMap
>> 127:     create(boolean isSoft, Supplier> supplier) {
> 
> What prevents this to take `Supplier, V>>`? Same for below.

Remnants of when I was have issues with param types. Changed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1147768901

From jlaskey at openjdk.org  Fri Mar 24 15:58:13 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 24 Mar 2023 15:58:13 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 23 Mar 2023 01:12:20 GMT, Chen Liang  wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Tidy javadoc
>>  - Rename StringTemplate classes
>
> src/java.base/share/classes/java/lang/runtime/StringTemplateImpl.java line 40:
> 
>> 38:  * 
      
>> 39:  * Values are stored by subclassing {@link Carriers.CarrierObject}. This allows specializations
>> 40:  * and sharing of value shapes without creating a new class for each shape.
> 
> Just curious, what specific benefits does subclassing offer over having `CarrierObject` as a field? I don't see how a new class is ever created for each shape in that scenario, as shapes are only used to construct the 2 MHs in the factory.

About a 15-20% performance gain by not having two levels of indirection.

> src/java.base/share/classes/java/lang/runtime/StringTemplateImplFactory.java line 88:
> 
>> 86:      *
>> 87:      * @param fragments  string template fragments
>> 88:      * @param type       method type
> 
> Suggestion:
> 
>      * @param type method type accepting values' types and returning a StringTemplate

Changing

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1147771982
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1147775001

From jwaters at openjdk.org  Fri Mar 24 15:58:46 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 24 Mar 2023 15:58:46 GMT
Subject: RFR: 8304837: Classfile API throws IOOBE for MethodParameters
 attribute without parameter names [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 24 Mar 2023 06:42:30 GMT, Hannes Greule  wrote:

>> After merging master into https://github.com/openjdk/jdk/pull/9862, we encountered test failures (e.g., https://github.com/SirYwell/jdk/actions/runs/4500940829/jobs/7923018438#step:9:2541). The Classfile API tries to read from constant pool index 0 if a MethodParameters attribute has an entry without name.
>> 
>> The fix is simply using `readUtf8EntryOrNull` instead of `readUtf8Entry`. The related code already correctly handles nullability.
>> 
>> I didn't find an appropriate test class so I added a new one. Let me know if there's a better place or if the test can be improved somehow.
>> 
>> As I don't have a JBS account, someone needs to create a bug report there for me. Thanks.
>
> Hannes Greule has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move and fix test comment

Marked as reviewed by jwaters (Committer).

Great work, feel free to @ me if you need a quick sponsor once you integrate it

-------------

PR Review: https://git.openjdk.org/jdk/pull/13167#pullrequestreview-1356999586
PR Comment: https://git.openjdk.org/jdk/pull/13167#issuecomment-1483036308

From alanb at openjdk.org  Fri Mar 24 16:07:26 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 24 Mar 2023 16:07:26 GMT
Subject: RFR: 8303485: Replacing os.name for operating system customization
 [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 24 Mar 2023 00:27:42 GMT, Roger Riggs  wrote:

>> Improvements to support OS specific customization for JDK internal use:
>>  - To select values and code; allowing elimination of unused code and values
>>  - Optionally evaluated by build processes, compilation, or archiving (i.e. CDS)
>>  - Simple API to replace adhoc comparisons with `os.name`
>>  - Clear and consistent use across build, runtime, and JDK modules
>>  
>> The PR includes updates within java.base to use the new API.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename OperatingSystem enum values to uppercase

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/12931#pullrequestreview-1357008852

From rriggs at openjdk.org  Fri Mar 24 16:07:32 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 24 Mar 2023 16:07:32 GMT
Subject: RFR: 8303485: Replacing os.name for operating system customization
 [v6]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 24 Mar 2023 16:02:59 GMT, Michael Osipov  wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename OperatingSystem enum values to uppercase
>
> src/java.base/share/classes/jdk/internal/util/OperatingSystem.java line 81:
> 
>> 79:      */
>> 80:     AIX,
>> 81:     ;
> 
> So no Unknown value?

Correct, as explained above.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12931#discussion_r1147786572

From duke at openjdk.org  Fri Mar 24 16:07:29 2023
From: duke at openjdk.org (Michael Osipov)
Date: Fri, 24 Mar 2023 16:07:29 GMT
Subject: RFR: 8303485: Replacing os.name for operating system customization
 [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 24 Mar 2023 00:27:42 GMT, Roger Riggs  wrote:

>> Improvements to support OS specific customization for JDK internal use:
>>  - To select values and code; allowing elimination of unused code and values
>>  - Optionally evaluated by build processes, compilation, or archiving (i.e. CDS)
>>  - Simple API to replace adhoc comparisons with `os.name`
>>  - Clear and consistent use across build, runtime, and JDK modules
>>  
>> The PR includes updates within java.base to use the new API.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename OperatingSystem enum values to uppercase

@battleblow FYI

src/java.base/share/classes/jdk/internal/util/OperatingSystem.java line 66:

> 64: 
> 65:     /**
> 66:      * The Linux Operating system.

For the sake if completeness, Linux isn't an operating system, so this statement isn't correct.

src/java.base/share/classes/jdk/internal/util/OperatingSystem.java line 81:

> 79:      */
> 80:     AIX,
> 81:     ;

So no Unknown value?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12931#issuecomment-1483049583
PR Review Comment: https://git.openjdk.org/jdk/pull/12931#discussion_r1147785316
PR Review Comment: https://git.openjdk.org/jdk/pull/12931#discussion_r1147784804

From rriggs at openjdk.org  Fri Mar 24 16:11:24 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 24 Mar 2023 16:11:24 GMT
Subject: RFR: 8303485: Replacing os.name for operating system customization
 [v6]
In-Reply-To: 
References: 
 
 
Message-ID: <5tyWsnWAY9NxUa7yWSaYKutazCd6MSFibdY30zUb0t0=.8f24b10d-317d-418e-8e9f-a2a56c531917@github.com>

On Fri, 24 Mar 2023 16:03:26 GMT, Michael Osipov  wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename OperatingSystem enum values to uppercase
>
> src/java.base/share/classes/jdk/internal/util/OperatingSystem.java line 66:
> 
>> 64: 
>> 65:     /**
>> 66:      * The Linux Operating system.
> 
> For the sake if completeness, Linux isn't an operating system, so this statement isn't correct.

A bit of a quibble, several internet sources identify Linux as an operating system (including Redhat).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12931#discussion_r1147790687

From liach at openjdk.org  Fri Mar 24 16:15:42 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 24 Mar 2023 16:15:42 GMT
Subject: RFR: 8304745: Lazily initialize byte[] in
 java.io.BufferedInputStream [v5]
In-Reply-To: 
References: 
 
Message-ID: <0vnQv7dALYaDleC5-32GgjZvKAEjn4QQEpt2T5gV5yo=.67c87f05-824d-4104-9d8e-00d4c88d0542@github.com>

On Fri, 24 Mar 2023 15:40:40 GMT, Sergey Tsypanov  wrote:

>> By default `BufferedInputStream` is constructed with internal buffer with capacity 8192. In some cases this buffer is never used, e.g. when we call `IS.readNBytes()` or `IS.readAllBytes()` (relying on `BIS.read1()`) or when `BufferedInputStream` is cascaded.
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8304745: Add benchmark

test/micro/org/openjdk/bench/java/io/BufferedInputStreamBenchmark.java line 2:

> 1: /*
> 2:  * Copyright (c) 2020, 2022, Red Hat Inc. All rights reserved.

Copyright year, and is this really from redhat?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13150#discussion_r1147794637

From alanb at openjdk.org  Fri Mar 24 16:15:45 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 24 Mar 2023 16:15:45 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v13]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 24 Mar 2023 02:18:43 GMT, Jaikiran Pai  wrote:

>> Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8206890?
>> 
>> The `jlink` command allows a `--endian` option to specify the byte order in the generated image. Before this change, when such a image was being launched, the code would assume the byte order in the image to be the native order of the host where the image is being launched. That would result in failure to launch java, as noted in the linked issue.
>> 
>> The commit in this PR, changes relevant places to not assume native order and instead determine the byte order by reading the magic bytes in the image file's header content.
>> 
>> A new jtreg test has been added which reproduces the issue and verifies the fix.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:
> 
>  - merge latest from master branch
>  - Mandy's suggested patch improvements
>  - ARM is 32 bit as per platform.m4 in OpenJDK build
>  - when --endian is specified, verify it matches the implicitly determined target platform's endianness
>  - trim down the architecture support to the previous values plus a few new that match target.properties
>  - improve error messages as suggested by Mandy
>  - formatting fix
>  - Alan's suggestions - don't parse arch out of osname-arch for determining endianness and reduce the number of supported/known target platforms for cross linking
>  - Mandy's suggestion - pass along target platform to the DefaultImageBuilder to prevent reparsing the value from the ModuleTarget
>  - Mandy's suggestion to use Platform class for additional arch support. Plus, Jim's suggestion to use a runtime resource for endianness mapping
>  - ... and 18 more: https://git.openjdk.org/jdk/compare/ac6af6a6...6f4ab9c6

I think you've got this to a good place. The other remaining issue is the target.properties and whether it limited to endianness as proposed or whether it can be used for other properties of the target.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Platform.java line 49:

> 47:             throw new ExceptionInInitializerError(e);
> 48:         }
> 49:         KNOWN_ENDIANNESS = p;

The naming/usage suggests the value is solely for endianness but I think we want target properties to be able to support other attributes of the target too. This means "endianness" in the property name or the property value is something like a comma separate list of attributes, I don't have a strong opinion on this. But maybe your proposal is just to get the target.properties in place and we change it later?

-------------

PR Review: https://git.openjdk.org/jdk/pull/11943#pullrequestreview-1357028246
PR Review Comment: https://git.openjdk.org/jdk/pull/11943#discussion_r1147793209

From naoto at openjdk.org  Fri Mar 24 16:17:56 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 24 Mar 2023 16:17:56 GMT
Subject: RFR: 8303485: Replacing os.name for operating system customization
 [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 24 Mar 2023 00:27:42 GMT, Roger Riggs  wrote:

>> Improvements to support OS specific customization for JDK internal use:
>>  - To select values and code; allowing elimination of unused code and values
>>  - Optionally evaluated by build processes, compilation, or archiving (i.e. CDS)
>>  - Simple API to replace adhoc comparisons with `os.name`
>>  - Clear and consistent use across build, runtime, and JDK modules
>>  
>> The PR includes updates within java.base to use the new API.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename OperatingSystem enum values to uppercase

LGTM

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/12931#pullrequestreview-1357032533

From naoto at openjdk.org  Fri Mar 24 16:20:48 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 24 Mar 2023 16:20:48 GMT
Subject: RFR: 8304761: Update IANA Language Subtag Registry to Version
 2023-03-22 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 23 Mar 2023 21:30:37 GMT, Justin Lu  wrote:

>> Update IANA LSR to 2023-03-22 [update](https://mm.icann.org/pipermail/ietf-languages-announcements/2023-March/000085.html). Add all new preferred languages to `ACCEPT_LANGUAGES` except `gu`.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert incorrect weighting

LGTM

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13165#pullrequestreview-1357036078

From rriggs at openjdk.org  Fri Mar 24 16:24:53 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 24 Mar 2023 16:24:53 GMT
Subject: RFR: 8303485: Replacing os.name for operating system customization
 [v6]
In-Reply-To: 
References: 
 
 
 
Message-ID: <6dRuSmuwGaOkWGpDKTsvUhO1cCDCWSUVzF_nzD7ntkA=.62397399-fbcd-4af4-8d7e-fa1df2b218ee@github.com>

On Fri, 24 Mar 2023 16:04:38 GMT, Roger Riggs  wrote:

>> src/java.base/share/classes/jdk/internal/util/OperatingSystem.java line 81:
>> 
>>> 79:      */
>>> 80:     AIX,
>>> 81:     ;
>> 
>> So no Unknown value?
>
> Correct, as explained above.

If additional OS values are needed, they can be added to the enum and add the corresponding `isXXX()` method building on the same pattern used in OperatingSystemProps.java.template.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12931#discussion_r1147804555

From lancea at openjdk.org  Fri Mar 24 16:39:57 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 24 Mar 2023 16:39:57 GMT
Subject: RFR: 8304013: Add a fast,
 non-manual alternative to test/jdk/java/util/zip/ZipFile/TestTooManyEntries
In-Reply-To: 
References: 
Message-ID: 

On Thu, 26 Jan 2023 18:49:47 GMT, Eirik Bjorsnos  wrote:

> The TestTooManyEntries test was originally added to validate that ZIP64 files with CEN sizes exceeding what ZipFile  supports are rejected with a ZipException. The test does this by creating a large ZIP file (several gigabytes) with many enties. Because this is resource intensive, the test is currently tagged as manual.  (See #6927)
> 
> It would be useful to have a test which asserts the CEN size enforcement, but without the CPU, disk, memory and run time requirements of TestTooManyEntries.  Such a fast test can run non-manual,  without the @requires and manual tags as found in TestTooManyEntries.
> 
> This PR adds the EndOfCenValidation test which creates sparse test ZIPs where the CEN is "inflated" such that is matches the size declared in the "End of central directory" records.
> 
> While thee sparse files look large, they consume very little disk space on file systems supporting sparse files:
> 
> 
> 16 -rw-r--r--  1   2147483702 Feb  6 18:54 bad-cen-offset.zip
> 16 -rw-r--r--  1   2147483703 Feb  6 18:54 cen-size-too-large.zip
>  8 -rw-r--r--  1          132 Feb  6 18:54 invalid-zen-size.zip
> ``` 
> 
> For good measure, two new test methods are added to excercise the remaining ZipExceptions which ZipFile may throw during validation of the END record .

Mach 5 test runs are clean so you are good to go Eirik, thank you again

-------------

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/12231#pullrequestreview-1357069395

From duke at openjdk.org  Fri Mar 24 16:44:13 2023
From: duke at openjdk.org (Michael Osipov)
Date: Fri, 24 Mar 2023 16:44:13 GMT
Subject: RFR: 8303485: Replacing os.name for operating system customization
 [v6]
In-Reply-To: <5tyWsnWAY9NxUa7yWSaYKutazCd6MSFibdY30zUb0t0=.8f24b10d-317d-418e-8e9f-a2a56c531917@github.com>
References: 
 
 
 <5tyWsnWAY9NxUa7yWSaYKutazCd6MSFibdY30zUb0t0=.8f24b10d-317d-418e-8e9f-a2a56c531917@github.com>
Message-ID: 

On Fri, 24 Mar 2023 16:08:30 GMT, Roger Riggs  wrote:

>> src/java.base/share/classes/jdk/internal/util/OperatingSystem.java line 66:
>> 
>>> 64: 
>>> 65:     /**
>>> 66:      * The Linux Operating system.
>> 
>> For the sake if completeness, Linux isn't an operating system, so this statement isn't correct.
>
> A bit of a quibble, several internet sources identify Linux as an operating system (including Redhat).

Well, no. It is just a kernel. Without a userland not an OS. That is why they call it GNU/Linux. Kernel + userland.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12931#discussion_r1147826504

From mchung at openjdk.org  Fri Mar 24 16:55:32 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 24 Mar 2023 16:55:32 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v13]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 24 Mar 2023 02:18:43 GMT, Jaikiran Pai  wrote:

>> Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8206890?
>> 
>> The `jlink` command allows a `--endian` option to specify the byte order in the generated image. Before this change, when such a image was being launched, the code would assume the byte order in the image to be the native order of the host where the image is being launched. That would result in failure to launch java, as noted in the linked issue.
>> 
>> The commit in this PR, changes relevant places to not assume native order and instead determine the byte order by reading the magic bytes in the image file's header content.
>> 
>> A new jtreg test has been added which reproduces the issue and verifies the fix.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:
> 
>  - merge latest from master branch
>  - Mandy's suggested patch improvements
>  - ARM is 32 bit as per platform.m4 in OpenJDK build
>  - when --endian is specified, verify it matches the implicitly determined target platform's endianness
>  - trim down the architecture support to the previous values plus a few new that match target.properties
>  - improve error messages as suggested by Mandy
>  - formatting fix
>  - Alan's suggestions - don't parse arch out of osname-arch for determining endianness and reduce the number of supported/known target platforms for cross linking
>  - Mandy's suggestion - pass along target platform to the DefaultImageBuilder to prevent reparsing the value from the ModuleTarget
>  - Mandy's suggestion to use Platform class for additional arch support. Plus, Jim's suggestion to use a runtime resource for endianness mapping
>  - ... and 18 more: https://git.openjdk.org/jdk/compare/ac6af6a6...6f4ab9c6

src/jdk.jlink/share/classes/jdk/tools/jlink/builder/DefaultImageBuilder.java line 168:

> 166:      * @throws IOException
> 167:      * @throws NullPointerException If any of the params is null
> 168:      * @since 21

you can drop this as this is not a public API.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/11943#discussion_r1147826351

From mchung at openjdk.org  Fri Mar 24 16:55:35 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 24 Mar 2023 16:55:35 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v13]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 24 Mar 2023 16:10:54 GMT, Alan Bateman  wrote:

>> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:
>> 
>>  - merge latest from master branch
>>  - Mandy's suggested patch improvements
>>  - ARM is 32 bit as per platform.m4 in OpenJDK build
>>  - when --endian is specified, verify it matches the implicitly determined target platform's endianness
>>  - trim down the architecture support to the previous values plus a few new that match target.properties
>>  - improve error messages as suggested by Mandy
>>  - formatting fix
>>  - Alan's suggestions - don't parse arch out of osname-arch for determining endianness and reduce the number of supported/known target platforms for cross linking
>>  - Mandy's suggestion - pass along target platform to the DefaultImageBuilder to prevent reparsing the value from the ModuleTarget
>>  - Mandy's suggestion to use Platform class for additional arch support. Plus, Jim's suggestion to use a runtime resource for endianness mapping
>>  - ... and 18 more: https://git.openjdk.org/jdk/compare/ac6af6a6...6f4ab9c6
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Platform.java line 49:
> 
>> 47:             throw new ExceptionInInitializerError(e);
>> 48:         }
>> 49:         KNOWN_ENDIANNESS = p;
> 
> The naming/usage suggests the value is solely for endianness but I think we want target properties to be able to support other attributes of the target too. This means "endianness" in the property name or the property value is something like a comma separate list of attributes, I don't have a strong opinion on this. But maybe your proposal is just to get the target.properties in place and we change it later?

I read this as for endianness only and so the filename should be "target-endianness.properties" or something like that.   OTOH,  I like keeping it `target.properties` and add `.endianness` as the property name suffix will make it extensible to support other attributes easily.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/11943#discussion_r1147838681

From chegar999 at gmail.com  Fri Mar 24 16:55:40 2023
From: chegar999 at gmail.com (Chris Hegarty)
Date: Fri, 24 Mar 2023 16:55:40 +0000
Subject: JDK 20 EA builds (archive?)
Message-ID: <87e96963-97a6-be5f-935f-df3c27f393e8@gmail.com>

Hi,

While definitely not the right list, someone here will surely know ...

Where can I download archive EA builds of JDK 20, so I can perform 
bisect experiments to help narrow when something changed between JDK 19 
and JDK 20.  ( I have some builds, but not that many )

---
Informational: I'm not expecting anyone to do my work for me ;-) but if 
you have ideas or hints!

I'm try to track down a change in G1 GC behaviour, where the number of 
GC's of the Young generation has decreased ( by ~20% ), but the 
cumulative total time spent in GC of the Young generation has increased 
marginally ( ~2% ) for a particular workload benchmark ( that runs for a 
medium amount of time, ~20 mins ).

Thanks,
-Chris.

From duke at openjdk.org  Fri Mar 24 16:56:47 2023
From: duke at openjdk.org (David M. Lloyd)
Date: Fri, 24 Mar 2023 16:56:47 GMT
Subject: RFR: 8303485: Replacing os.name for operating system customization
 [v6]
In-Reply-To: 
References: 
 
 
 <5tyWsnWAY9NxUa7yWSaYKutazCd6MSFibdY30zUb0t0=.8f24b10d-317d-418e-8e9f-a2a56c531917@github.com>
 
Message-ID: <5sQVvvND57nlCMzdGIAX_3Znf6Yexv_tCqHuZTJrTIk=.d1c2a120-27e8-4db8-8518-c29b11adfbf5@github.com>

On Fri, 24 Mar 2023 16:41:02 GMT, Michael Osipov  wrote:

>> A bit of a quibble, several internet sources identify Linux as an operating system (including Redhat).
>
> Well, no. It is just a kernel. Without a userland not an OS. That is why they call it GNU/Linux. Kernel + userland.

If you are referring to "Red Hat Enterprise Linux", it'd be correct (AFAIK) to say that Red Hat identifies "Red Hat Enterprise Linux" as an operating system, but I wouldn't go so far as to say that Red Hat calls "Linux" an operating system (well... subject to the reality of human inaccuracy). And the validity and correctness of the term "GNU/Linux" is *definitely* disputed (and likely always will be).

Maybe "Operating systems based on the Linux kernel" would be satisfactory?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12931#discussion_r1147838269

From stsypanov at openjdk.org  Fri Mar 24 16:56:53 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Fri, 24 Mar 2023 16:56:53 GMT
Subject: RFR: 8304745: Lazily initialize byte[] in
 java.io.BufferedInputStream [v5]
In-Reply-To: <0vnQv7dALYaDleC5-32GgjZvKAEjn4QQEpt2T5gV5yo=.67c87f05-824d-4104-9d8e-00d4c88d0542@github.com>
References: 
 
 <0vnQv7dALYaDleC5-32GgjZvKAEjn4QQEpt2T5gV5yo=.67c87f05-824d-4104-9d8e-00d4c88d0542@github.com>
Message-ID: <7wGoQ25hkWVCw_GTD-Aqjjt6CKUgRZ2wmS49_vvPlso=.8010bc73-12b5-438e-8b09-199ce699ac8d@github.com>

On Fri, 24 Mar 2023 16:12:13 GMT, Chen Liang  wrote:

>> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8304745: Add benchmark
>
> test/micro/org/openjdk/bench/java/io/BufferedInputStreamBenchmark.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2020, 2022, Red Hat Inc. All rights reserved.
> 
> Copyright year, and is this really from redhat?

Nope, it's just copy-pasted

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13150#discussion_r1147840260

From duke at openjdk.org  Fri Mar 24 16:56:49 2023
From: duke at openjdk.org (Michael Osipov)
Date: Fri, 24 Mar 2023 16:56:49 GMT
Subject: RFR: 8303485: Replacing os.name for operating system customization
 [v6]
In-Reply-To: <5sQVvvND57nlCMzdGIAX_3Znf6Yexv_tCqHuZTJrTIk=.d1c2a120-27e8-4db8-8518-c29b11adfbf5@github.com>
References: 
 
 
 <5tyWsnWAY9NxUa7yWSaYKutazCd6MSFibdY30zUb0t0=.8f24b10d-317d-418e-8e9f-a2a56c531917@github.com>
 
 <5sQVvvND57nlCMzdGIAX_3Znf6Yexv_tCqHuZTJrTIk=.d1c2a120-27e8-4db8-8518-c29b11adfbf5@github.com>
Message-ID: 

On Fri, 24 Mar 2023 16:51:46 GMT, David M. Lloyd  wrote:

>> Well, no. It is just a kernel. Without a userland not an OS. That is why they call it GNU/Linux. Kernel + userland.
>
> If you are referring to "Red Hat Enterprise Linux", it'd be correct (AFAIK) to say that Red Hat identifies "Red Hat Enterprise Linux" as an operating system, but I wouldn't go so far as to say that Red Hat calls "Linux" an operating system (well... subject to the reality of human inaccuracy). And the validity and correctness of the term "GNU/Linux" is *definitely* disputed (and likely always will be).
> 
> Maybe "Operating systems based on the Linux kernel" would be satisfactory?

That is acceptable, totally.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12931#discussion_r1147839641

From stsypanov at openjdk.org  Fri Mar 24 17:02:30 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Fri, 24 Mar 2023 17:02:30 GMT
Subject: RFR: 8304745: Lazily initialize byte[] in
 java.io.BufferedInputStream [v6]
In-Reply-To: 
References: 
Message-ID: 

> By default `BufferedInputStream` is constructed with internal buffer with capacity 8192. In some cases this buffer is never used, e.g. when we call `IS.readNBytes()` or `IS.readAllBytes()` (relying on `BIS.read1()`) or when `BufferedInputStream` is cascaded.

Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:

  8304745: Amend copyright

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13150/files
  - new: https://git.openjdk.org/jdk/pull/13150/files/f1877548..e55ed936

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13150&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13150&range=04-05

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13150.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13150/head:pull/13150

PR: https://git.openjdk.org/jdk/pull/13150

From rriggs at openjdk.org  Fri Mar 24 17:06:45 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 24 Mar 2023 17:06:45 GMT
Subject: RFR: 8303485: Replacing os.name for operating system customization
 [v7]
In-Reply-To: 
References: 
Message-ID: 

> Improvements to support OS specific customization for JDK internal use:
>  - To select values and code; allowing elimination of unused code and values
>  - Optionally evaluated by build processes, compilation, or archiving (i.e. CDS)
>  - Simple API to replace adhoc comparisons with `os.name`
>  - Clear and consistent use across build, runtime, and JDK modules
>  
> The PR includes updates within java.base to use the new API.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  clarify Linux

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12931/files
  - new: https://git.openjdk.org/jdk/pull/12931/files/8372978f..bfc3de93

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12931&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12931&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12931.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12931/head:pull/12931

PR: https://git.openjdk.org/jdk/pull/12931

From rriggs at openjdk.org  Fri Mar 24 17:06:47 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 24 Mar 2023 17:06:47 GMT
Subject: RFR: 8303485: Replacing os.name for operating system customization
 [v6]
In-Reply-To: 
References: 
 
 
 <5tyWsnWAY9NxUa7yWSaYKutazCd6MSFibdY30zUb0t0=.8f24b10d-317d-418e-8e9f-a2a56c531917@github.com>
 
 <5sQVvvND57nlCMzdGIAX_3Znf6Yexv_tCqHuZTJrTIk=.d1c2a120-27e8-4db8-8518-c29b11adfbf5@github.com>
 
Message-ID: <-_VpYPMNB-6G0nYrcb7I5Vm6KiSMvg4gDNvcnKHsVN8=.5be28fce-c566-4dc9-8f3c-c261949fccc0@github.com>

On Fri, 24 Mar 2023 16:53:05 GMT, Michael Osipov  wrote:

>> If you are referring to "Red Hat Enterprise Linux", it'd be correct (AFAIK) to say that Red Hat identifies "Red Hat Enterprise Linux" as an operating system, but I wouldn't go so far as to say that Red Hat calls "Linux" an operating system (well... subject to the reality of human inaccuracy). And the validity and correctness of the term "GNU/Linux" is *definitely* disputed (and likely always will be).
>> 
>> Maybe "Operating systems based on the Linux kernel" would be satisfactory?
>
> That is acceptable, totally.

Not the rabbit-hole I expected to go down today or for an informal comment on an internal API.
I have no skin in that game.
https://www.redhat.com/en/topics/linux/what-is-linux

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12931#discussion_r1147850108

From duke at openjdk.org  Fri Mar 24 17:10:42 2023
From: duke at openjdk.org (Michael Osipov)
Date: Fri, 24 Mar 2023 17:10:42 GMT
Subject: RFR: 8303485: Replacing os.name for operating system customization
 [v6]
In-Reply-To: <-_VpYPMNB-6G0nYrcb7I5Vm6KiSMvg4gDNvcnKHsVN8=.5be28fce-c566-4dc9-8f3c-c261949fccc0@github.com>
References: 
 
 
 <5tyWsnWAY9NxUa7yWSaYKutazCd6MSFibdY30zUb0t0=.8f24b10d-317d-418e-8e9f-a2a56c531917@github.com>
 
 <5sQVvvND57nlCMzdGIAX_3Znf6Yexv_tCqHuZTJrTIk=.d1c2a120-27e8-4db8-8518-c29b11adfbf5@github.com>
 
 <-_VpYPMNB-6G0nYrcb7I5Vm6KiSMvg4gDNvcnKHsVN8=.5be28fce-c566-4dc9-8f3c-c261949fccc0@github.com>
Message-ID: 

On Fri, 24 Mar 2023 17:01:37 GMT, Roger Riggs  wrote:

>> That is acceptable, totally.
>
> Not the rabbit-hole I expected to go down today or for an informal comment on an internal API.
> I have no skin in that game.
> https://www.redhat.com/en/topics/linux/what-is-linux

Joke, they should know it better especially because they use the registered trademark symbol. Really surprising.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12931#discussion_r1147855868

From pavel.rappo at oracle.com  Fri Mar 24 17:16:53 2023
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Fri, 24 Mar 2023 17:16:53 +0000
Subject: JDK 20 EA builds (archive?)
In-Reply-To: <87e96963-97a6-be5f-935f-df3c27f393e8@gmail.com>
References: <87e96963-97a6-be5f-935f-df3c27f393e8@gmail.com>
Message-ID: 

Hi Chris,

Would you not be able to bisect by tags? Checkout, build, and run your test(s) possibly (semi-) automatically using git bisect? What's the OS?

-Pavel

> On 24 Mar 2023, at 16:55, Chris Hegarty  wrote:
> 
> Hi,
> 
> While definitely not the right list, someone here will surely know ...
> 
> Where can I download archive EA builds of JDK 20, so I can perform bisect experiments to help narrow when something changed between JDK 19 and JDK 20.  ( I have some builds, but not that many )
> 
> ---
> Informational: I'm not expecting anyone to do my work for me ;-) but if you have ideas or hints!
> 
> I'm try to track down a change in G1 GC behaviour, where the number of GC's of the Young generation has decreased ( by ~20% ), but the cumulative total time spent in GC of the Young generation has increased marginally ( ~2% ) for a particular workload benchmark ( that runs for a medium amount of time, ~20 mins ).
> 
> Thanks,
> -Chris.


From chegar999 at gmail.com  Fri Mar 24 17:18:50 2023
From: chegar999 at gmail.com (Chris Hegarty)
Date: Fri, 24 Mar 2023 17:18:50 +0000
Subject: The non-deterministic iteration order of Immutable Collections
Message-ID: <1cf6bcc4-b7f9-fc72-8b3e-d3a3c785f54e@gmail.com>

I know that this has come up a number of times before, but I cannot seem 
to find anything directly relevant to my use-case, or recent.

The iteration order of immutable Sets and Maps (created by the `of` 
factories) is clearly unspecified - good. Code should not depend upon 
this iteration order, and if so that code is broken. I completely agree 
and am aligned with this principle.

The Elasticsearch code base heavily uses these collection 
implementations, and their iterators. On occasion we run into issues, 
where our code (because of a bug or a race), inadvertently has a 
dependency on the iteration order. To be clear, this is a bug in our 
code, and we want to reproduce and fix it.  The problem we are 
encountering is that the iteration order is not determinable or 
reproducible, which makes it extremely challenging to reproduce the bug 
even when we have reproducible testcase to hand. ( whereas, for example, 
it is common practice in other parts of the code to log a seed used for 
randomization )

We very much like using the immutable collections, and we definitely 
don't want to pay the price of sorting things in the code, since we 
don't want to, and should not, depend upon the iteration order. The only 
concern is with reproducibility when we run into (our own) bugs.

I don't (yet) want to be prescriptive in any potential solution. And I 
know that this has been discussed before. I mostly just want to start a 
conversation and see how much traction it gets.

Thanks,
-Chris.

From duke at openjdk.org  Fri Mar 24 17:51:05 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 24 Mar 2023 17:51:05 GMT
Subject: RFR: 8304013: Add a fast,
 non-manual alternative to test/jdk/java/util/zip/ZipFile/TestTooManyEntries
In-Reply-To: 
References: 
Message-ID: 

On Thu, 26 Jan 2023 18:49:47 GMT, Eirik Bjorsnos  wrote:

> The TestTooManyEntries test was originally added to validate that ZIP64 files with CEN sizes exceeding what ZipFile  supports are rejected with a ZipException. The test does this by creating a large ZIP file (several gigabytes) with many enties. Because this is resource intensive, the test is currently tagged as manual.  (See #6927)
> 
> It would be useful to have a test which asserts the CEN size enforcement, but without the CPU, disk, memory and run time requirements of TestTooManyEntries.  Such a fast test can run non-manual,  without the @requires and manual tags as found in TestTooManyEntries.
> 
> This PR adds the EndOfCenValidation test which creates sparse test ZIPs where the CEN is "inflated" such that is matches the size declared in the "End of central directory" records.
> 
> While thee sparse files look large, they consume very little disk space on file systems supporting sparse files:
> 
> 
> 16 -rw-r--r--  1   2147483702 Feb  6 18:54 bad-cen-offset.zip
> 16 -rw-r--r--  1   2147483703 Feb  6 18:54 cen-size-too-large.zip
>  8 -rw-r--r--  1          132 Feb  6 18:54 invalid-zen-size.zip
> ``` 
> 
> For good measure, two new test methods are added to excercise the remaining ZipExceptions which ZipFile may throw during validation of the END record .

Thanks for all your help and careful reviews getting this ball across the net, Lance! Feels good to have one less manual test.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12231#issuecomment-1483189432

From holo3146 at gmail.com  Fri Mar 24 17:53:24 2023
From: holo3146 at gmail.com (Holo The Sage Wolf)
Date: Fri, 24 Mar 2023 20:53:24 +0300
Subject: The non-deterministic iteration order of Immutable Collections
In-Reply-To: <1cf6bcc4-b7f9-fc72-8b3e-d3a3c785f54e@gmail.com>
References: <1cf6bcc4-b7f9-fc72-8b3e-d3a3c785f54e@gmail.com>
Message-ID: 

It is highly dependent on the exact implementation, but the situation you
are describing us weird.

In most cases the order *is* deterministic for a read-only view (which is
the case in, for example, HashMap (and hence for HashSet)).

In a deterministic implementation the only cases where the iteration order
will change is if you modify the collection, change the implementation
(e.g. downcast, or change version), or, in rare cases, when you copy the
collection.

If you are using non-determinsitic implementation (which I do not know if
such implementation exists in the std) then the means of reproduction would
probably comes down to set a seed correctly

On Fri, Mar 24, 2023, 20:19 Chris Hegarty  wrote:

> I know that this has come up a number of times before, but I cannot seem
> to find anything directly relevant to my use-case, or recent.
>
> The iteration order of immutable Sets and Maps (created by the `of`
> factories) is clearly unspecified - good. Code should not depend upon
> this iteration order, and if so that code is broken. I completely agree
> and am aligned with this principle.
>
> The Elasticsearch code base heavily uses these collection
> implementations, and their iterators. On occasion we run into issues,
> where our code (because of a bug or a race), inadvertently has a
> dependency on the iteration order. To be clear, this is a bug in our
> code, and we want to reproduce and fix it.  The problem we are
> encountering is that the iteration order is not determinable or
> reproducible, which makes it extremely challenging to reproduce the bug
> even when we have reproducible testcase to hand. ( whereas, for example,
> it is common practice in other parts of the code to log a seed used for
> randomization )
>
> We very much like using the immutable collections, and we definitely
> don't want to pay the price of sorting things in the code, since we
> don't want to, and should not, depend upon the iteration order. The only
> concern is with reproducibility when we run into (our own) bugs.
>
> I don't (yet) want to be prescriptive in any potential solution. And I
> know that this has been discussed before. I mostly just want to start a
> conversation and see how much traction it gets.
>
> Thanks,
> -Chris.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From duke at openjdk.org  Fri Mar 24 17:53:55 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 24 Mar 2023 17:53:55 GMT
Subject: RFR: 8304745: Lazily initialize byte[] in
 java.io.BufferedInputStream [v6]
In-Reply-To: 
References: 
 
Message-ID: <3YR2uusWXsWVdyhRqrSfZQMnj-CRZEWktfXrABgGVvU=.762d1997-7248-42b1-b419-145894aeb19a@github.com>

On Fri, 24 Mar 2023 17:02:30 GMT, Sergey Tsypanov  wrote:

>> By default `BufferedInputStream` is constructed with internal buffer with capacity 8192. In some cases this buffer is never used, e.g. when we call `IS.readNBytes()` or `IS.readAllBytes()` (relying on `BIS.read1()`) or when `BufferedInputStream` is cascaded.
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8304745: Amend copyright

Is something wrong with line endings in the added benchmark? jcheck seems to complain a lot?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13150#issuecomment-1483192270

From kasperni at gmail.com  Fri Mar 24 17:53:51 2023
From: kasperni at gmail.com (Kasper Nielsen)
Date: Fri, 24 Mar 2023 17:53:51 +0000
Subject: The non-deterministic iteration order of Immutable Collections
In-Reply-To: <1cf6bcc4-b7f9-fc72-8b3e-d3a3c785f54e@gmail.com>
References: <1cf6bcc4-b7f9-fc72-8b3e-d3a3c785f54e@gmail.com>
Message-ID: 

>
> I don't (yet) want to be prescriptive in any potential solution. And I
> know that this has been discussed before. I mostly just want to start a
> conversation and see how much traction it gets.
>
Would
java.util.SequencedMap.of(...)
java.util.SequencedMap.copyOf(SequencedMap map)
java.util.SequencedSet.of(...)
java.util.SequencedSet.copyOf(SequencedSet set)
solve your problem?

I would love to see them included in JEP 431.
Should be fairly simply to implement just have a side
array that maintains the elements in order.

/Kasper

From liach at openjdk.org  Fri Mar 24 18:02:29 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 24 Mar 2023 18:02:29 GMT
Subject: RFR: 8304745: Lazily initialize byte[] in
 java.io.BufferedInputStream [v6]
In-Reply-To: <3YR2uusWXsWVdyhRqrSfZQMnj-CRZEWktfXrABgGVvU=.762d1997-7248-42b1-b419-145894aeb19a@github.com>
References: 
 
 <3YR2uusWXsWVdyhRqrSfZQMnj-CRZEWktfXrABgGVvU=.762d1997-7248-42b1-b419-145894aeb19a@github.com>
Message-ID: 

On Fri, 24 Mar 2023 17:51:03 GMT, Eirik Bjorsnos  wrote:

> Is something wrong with line endings in the added benchmark? jcheck seems to complain a lot?

It often happens when copying a file on windows. Can usually be fixed in intellij idea by navigating to the file and changing line endings to LF from CRLF, as long as git config is right (as per https://github.com/openjdk/jdk/blob/master/doc/building.md#special-considerations) the line ending will be fixed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13150#issuecomment-1483200334

From liach at openjdk.org  Fri Mar 24 18:02:35 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 24 Mar 2023 18:02:35 GMT
Subject: RFR: 8304745: Lazily initialize byte[] in
 java.io.BufferedInputStream [v6]
In-Reply-To: 
References: 
 
Message-ID: <9HhJB3WN2_G6DJmTQyyBERJ2RtwTSz3mbhe5G7jG1N0=.bd6eea1b-0cd1-45c3-a0f3-187e6f592351@github.com>

On Fri, 24 Mar 2023 17:02:30 GMT, Sergey Tsypanov  wrote:

>> By default `BufferedInputStream` is constructed with internal buffer with capacity 8192. In some cases this buffer is never used, e.g. when we call `IS.readNBytes()` or `IS.readAllBytes()` (relying on `BIS.read1()`) or when `BufferedInputStream` is cascaded.
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8304745: Amend copyright

test/micro/org/openjdk/bench/java/io/BufferedInputStreamBenchmark.java line 1:

> 1: /*

Need to update the line ending of this file, like through intellij idea bottom right or sublime text view->line endings

test/micro/org/openjdk/bench/java/io/BufferedInputStreamBenchmark.java line 2:

> 1: /*
> 2:  * Copyright (c) 2020, 2023, Oracle and/or its affiliates. All rights reserved.

Suggestion:

 * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13150#discussion_r1147906565
PR Review Comment: https://git.openjdk.org/jdk/pull/13150#discussion_r1147905408

From liangchenblue at gmail.com  Fri Mar 24 18:03:21 2023
From: liangchenblue at gmail.com (-)
Date: Fri, 24 Mar 2023 13:03:21 -0500
Subject: The non-deterministic iteration order of Immutable Collections
In-Reply-To: 
References: <1cf6bcc4-b7f9-fc72-8b3e-d3a3c785f54e@gmail.com>
 
Message-ID: 

https://github.com/openjdk/jdk/blob/97649489d078a3aa34a73e7f686e507f34155788/src/java.base/share/classes/java/util/ImmutableCollections.java#L76-L79

Looking at these, it seems you can add `-Xshare:dump` to VM arguments
to obtain a deterministic iteration order for the same JDK builds.
This can help you reproduce the problem reliably.

On Fri, Mar 24, 2023 at 1:02?PM Kasper Nielsen  wrote:
>
> >
> > I don't (yet) want to be prescriptive in any potential solution. And I
> > know that this has been discussed before. I mostly just want to start a
> > conversation and see how much traction it gets.
> >
> Would
> java.util.SequencedMap.of(...)
> java.util.SequencedMap.copyOf(SequencedMap map)
> java.util.SequencedSet.of(...)
> java.util.SequencedSet.copyOf(SequencedSet set)
> solve your problem?
>
> I would love to see them included in JEP 431.
> Should be fairly simply to implement just have a side
> array that maintains the elements in order.
>
> /Kasper

From igraves at openjdk.org  Fri Mar 24 18:04:19 2023
From: igraves at openjdk.org (Ian Graves)
Date: Fri, 24 Mar 2023 18:04:19 GMT
Subject: RFR: 8304898: Fix Copyright Headers for JLink Source Files
Message-ID: 

Updating copyright headers on some files missed in a previous commit

-------------

Commit messages:
 - 8304898: Fix Copyright Headers for JLink Source Files

Changes: https://git.openjdk.org/jdk/pull/13181/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13181&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304898
  Stats: 8 lines in 8 files changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/13181.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13181/head:pull/13181

PR: https://git.openjdk.org/jdk/pull/13181

From dalibor.topic at oracle.com  Fri Mar 24 18:04:26 2023
From: dalibor.topic at oracle.com (Dalibor Topic)
Date: Fri, 24 Mar 2023 19:04:26 +0100
Subject: JDK 20 EA builds (archive?)
In-Reply-To: <87e96963-97a6-be5f-935f-df3c27f393e8@gmail.com>
References: <87e96963-97a6-be5f-935f-df3c27f393e8@gmail.com>
Message-ID: <222171d4-7de0-efc9-79ed-ea0066ad969e@oracle.com>



On 24.03.2023 17:55, Chris Hegarty wrote:
> Hi,
> 
> While definitely not the right list, someone here will surely know ...
> 
> Where can I download archive EA builds of JDK 20, so I can perform 
> bisect experiments to help narrow when something changed between JDK 19 
> and JDK 20.? ( I have some builds, but not that many )

On Linux, you can try to use the Dockerhub OpenJDK image, which picks up 
and tags the early access builds on a weekly basis, as far as I recall.

cheers,
dalibor topic

-- 
 Dalibor Topic
Consulting Product Manager
Phone: +494089091214 , Mobile: +491737185961


Oracle Global Services Germany GmbH
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRB 246209
Gesch?ftsf?hrer: Ralf Herrmann


From jlu at openjdk.org  Fri Mar 24 18:17:32 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 24 Mar 2023 18:17:32 GMT
Subject: RFR: 8225641: Calendar.roll(int field) does not work correctly for
 WEEK_OF_YEAR [v2]
In-Reply-To: 
References: 
Message-ID: <3LYhtu7WPIFHrmKz1OnDiGGEaJR76JP33cQ3Rz3caCM=.cfcd0c61-d22e-4078-9320-4324a9a8186c@github.com>

> This PR fixes the bug which occurred when `Calendar.roll(WEEK_OF_YEAR)` rolled into a minimal first week with an invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo.
> 
> For example, Rolling _Monday, 30 December 2019_ by 1 week produced _Monday, 31 December 2018_, which is incorrect. This is because `WEEK_OF_YEAR` is rolled from 52 to 1, and the original `DAY_OF_WEEK` is 1. However, there is no Monday in week 1 of 2019. This is exposed when a future method calls `Calendar.complete()`, which eventually calculates a `fixedDate` with the invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo.
> 
> To prevent this, a check is added for rolls into week 1, which determines if the first week is minimal. If it is indeed minimal, then it is checked if  `DAY_OF_WEEK` exists in that week, if not, `WEEK_OF_YEAR` must be incremented by one.
> 
> After the fix, Rolling _Monday, 30 December 2019_ by 1 week produces _Monday, 7 January 2019_

Justin Lu has updated the pull request incrementally with two additional commits since the last revision:

 - Test all possible min week and first day of week combos for bugged date
 - Add safety check that amount is positive

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13031/files
  - new: https://git.openjdk.org/jdk/pull/13031/files/22387486..fe2f92f0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13031&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13031&range=00-01

  Stats: 106 lines in 2 files changed: 48 ins; 19 del; 39 mod
  Patch: https://git.openjdk.org/jdk/pull/13031.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13031/head:pull/13031

PR: https://git.openjdk.org/jdk/pull/13031

From iris at openjdk.org  Fri Mar 24 18:18:35 2023
From: iris at openjdk.org (Iris Clark)
Date: Fri, 24 Mar 2023 18:18:35 GMT
Subject: RFR: 8304898: Fix Copyright Headers for JLink Source Files
In-Reply-To: 
References: 
Message-ID: 

On Fri, 24 Mar 2023 17:56:03 GMT, Ian Graves  wrote:

> Updating copyright headers on some files missed in a previous commit

Confirmed all files listed in 8304691 save the deleted JLinkPostProcessingTest.java now have updated copyright year.

-------------

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13181#pullrequestreview-1357219435

From mchung at openjdk.org  Fri Mar 24 18:18:36 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 24 Mar 2023 18:18:36 GMT
Subject: RFR: 8304898: Fix Copyright Headers for JLink Source Files
In-Reply-To: 
References: 
Message-ID: 

On Fri, 24 Mar 2023 17:56:03 GMT, Ian Graves  wrote:

> Updating copyright headers on some files missed in a previous commit

Marked as reviewed by mchung (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13181#pullrequestreview-1357222570

From jlu at openjdk.org  Fri Mar 24 18:23:13 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 24 Mar 2023 18:23:13 GMT
Subject: RFR: 8225641: Calendar.roll(int field) does not work correctly for
 WEEK_OF_YEAR [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 15 Mar 2023 19:47:24 GMT, Naoto Sato  wrote:

>> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Test all possible min week and first day of week combos for bugged date
>>  - Add safety check that amount is positive
>
> src/java.base/share/classes/java/util/GregorianCalendar.java line 1314:
> 
>> 1312:                     // current DAY_OF_WEEK
>> 1313:                     if (newWeekOfYear == 1 && isInvalidWeek1()) {
>> 1314:                         newWeekOfYear+=1;
> 
> is `+1` always correct? Does it work when the amount is negative?

When a week is rolled down to 1 (and it does not have a valid day_of_week), the existing code would appropriately adjust min, so that the new week set would be 52. However, yes, it should only be incremented if amount is positive, but there does not need to be a case for when amount is negative.

> test/jdk/java/util/Calendar/RollToMinWeek.java line 95:
> 
>> 93: 
>> 94:     private static Calendar buildCalendar(int day, int month, int year, Locale locale) {
>> 95:         Calendar calendar = Calendar.getInstance(locale);
> 
> If the fix is `GregorianCalendar` specific, should it check the type?

Yes, I have changed it so that it is intentionally set as Gregorian, and also tested for being Gregorian.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13031#discussion_r1147922575
PR Review Comment: https://git.openjdk.org/jdk/pull/13031#discussion_r1147924484

From openjdk at icemanx.nl  Fri Mar 24 18:25:43 2023
From: openjdk at icemanx.nl (Rob Spoor)
Date: Fri, 24 Mar 2023 19:25:43 +0100
Subject: The non-deterministic iteration order of Immutable Collections
In-Reply-To: 
References: <1cf6bcc4-b7f9-fc72-8b3e-d3a3c785f54e@gmail.com>
 
Message-ID: <506cebc8-6d65-f26a-361a-f2902f35a3eb@icemanx.nl>

Check these:
* 
https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/util/Map.html#unmodifiable: 
"The iteration order of mappings is unspecified and is subject to change."
* 
https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/util/Set.html#unmodifiable: 
"The iteration order of set elements is unspecified and is subject to 
change."

Unlike HashSet, the implementation will have a different iteration order 
for the same content if you restart the JVM, as stated here: 
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/ImmutableCollections.java#L54
In other words, it not only discourages callers to not rely on iteration 
order, it punishes them; any code that relies on it will break after the 
JVM is restarted. The problem the Elasticsearch team has is *finding* 
these errors.


On 24/03/2023 18:53, Holo The Sage Wolf wrote:
> It is highly dependent on the exact implementation, but the situation you
> are describing us weird.
> 
> In most cases the order *is* deterministic for a read-only view (which is
> the case in, for example, HashMap (and hence for HashSet)).
> 
> In a deterministic implementation the only cases where the iteration order
> will change is if you modify the collection, change the implementation
> (e.g. downcast, or change version), or, in rare cases, when you copy the
> collection.
> 
> If you are using non-determinsitic implementation (which I do not know if
> such implementation exists in the std) then the means of reproduction would
> probably comes down to set a seed correctly
> 
> On Fri, Mar 24, 2023, 20:19 Chris Hegarty  wrote:
> 
>> I know that this has come up a number of times before, but I cannot seem
>> to find anything directly relevant to my use-case, or recent.
>>
>> The iteration order of immutable Sets and Maps (created by the `of`
>> factories) is clearly unspecified - good. Code should not depend upon
>> this iteration order, and if so that code is broken. I completely agree
>> and am aligned with this principle.
>>
>> The Elasticsearch code base heavily uses these collection
>> implementations, and their iterators. On occasion we run into issues,
>> where our code (because of a bug or a race), inadvertently has a
>> dependency on the iteration order. To be clear, this is a bug in our
>> code, and we want to reproduce and fix it.  The problem we are
>> encountering is that the iteration order is not determinable or
>> reproducible, which makes it extremely challenging to reproduce the bug
>> even when we have reproducible testcase to hand. ( whereas, for example,
>> it is common practice in other parts of the code to log a seed used for
>> randomization )
>>
>> We very much like using the immutable collections, and we definitely
>> don't want to pay the price of sorting things in the code, since we
>> don't want to, and should not, depend upon the iteration order. The only
>> concern is with reproducibility when we run into (our own) bugs.
>>
>> I don't (yet) want to be prescriptive in any potential solution. And I
>> know that this has been discussed before. I mostly just want to start a
>> conversation and see how much traction it gets.
>>
>> Thanks,
>> -Chris.
>>
> 


From martin at openjdk.org  Fri Mar 24 18:34:47 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Fri, 24 Mar 2023 18:34:47 GMT
Subject: RFR: 8304013: Add a fast,
 non-manual alternative to test/jdk/java/util/zip/ZipFile/TestTooManyEntries
In-Reply-To: 
References: 
Message-ID: 

On Thu, 26 Jan 2023 18:49:47 GMT, Eirik Bjorsnos  wrote:

> The TestTooManyEntries test was originally added to validate that ZIP64 files with CEN sizes exceeding what ZipFile  supports are rejected with a ZipException. The test does this by creating a large ZIP file (several gigabytes) with many enties. Because this is resource intensive, the test is currently tagged as manual.  (See #6927)
> 
> It would be useful to have a test which asserts the CEN size enforcement, but without the CPU, disk, memory and run time requirements of TestTooManyEntries.  Such a fast test can run non-manual,  without the @requires and manual tags as found in TestTooManyEntries.
> 
> This PR adds the EndOfCenValidation test which creates sparse test ZIPs where the CEN is "inflated" such that is matches the size declared in the "End of central directory" records.
> 
> While thee sparse files look large, they consume very little disk space on file systems supporting sparse files:
> 
> 
> 16 -rw-r--r--  1   2147483702 Feb  6 18:54 bad-cen-offset.zip
> 16 -rw-r--r--  1   2147483703 Feb  6 18:54 cen-size-too-large.zip
>  8 -rw-r--r--  1          132 Feb  6 18:54 invalid-zen-size.zip
> ``` 
> 
> For good measure, two new test methods are added to excercise the remaining ZipExceptions which ZipFile may throw during validation of the END record .

Changes requested by martin (Reviewer).

test/jdk/java/util/zip/ZipFile/EndOfCenValidation.java line 52:

> 50: 
> 51: /**
> 52:  * This test augments {@link TestTooManyEntries}. It creates sparse ZIPs where the

remove the "the" stutter

test/jdk/java/util/zip/ZipFile/EndOfCenValidation.java line 120:

> 118:     /**
> 119:      * Validate that an end of central directory record with a
> 120:      * CEN size which exceeds the position of the EOC record is rejected.

EOC is not a standard zip file technical term.  Did you mean "END header" ?

test/jdk/java/util/zip/ZipFile/EndOfCenValidation.java line 139:

> 137:      * Validate that an end of central directory record with a CEN offset which
> 138:      * is larger than the EOC position minus the CEN size is rejected
> 139:      * @throws IOException

I don't think `@throws` javadoc comments in tests are useful; especially checked ones

-------------

PR Review: https://git.openjdk.org/jdk/pull/12231#pullrequestreview-1357235702
PR Review Comment: https://git.openjdk.org/jdk/pull/12231#discussion_r1147929032
PR Review Comment: https://git.openjdk.org/jdk/pull/12231#discussion_r1147931418
PR Review Comment: https://git.openjdk.org/jdk/pull/12231#discussion_r1147932862

From igraves at openjdk.org  Fri Mar 24 18:35:50 2023
From: igraves at openjdk.org (Ian Graves)
Date: Fri, 24 Mar 2023 18:35:50 GMT
Subject: Integrated: 8304898: Fix Copyright Headers for JLink Source Files
In-Reply-To: 
References: 
Message-ID: 

On Fri, 24 Mar 2023 17:56:03 GMT, Ian Graves  wrote:

> Updating copyright headers on some files missed in a previous commit

This pull request has now been integrated.

Changeset: 3f59b75b
Author:    Ian Graves 
URL:       https://git.openjdk.org/jdk/commit/3f59b75bd8a858d2327ca975a57079747ff11b8e
Stats:     8 lines in 8 files changed: 0 ins; 0 del; 8 mod

8304898: Fix Copyright Headers for JLink Source Files

Reviewed-by: iris, mchung

-------------

PR: https://git.openjdk.org/jdk/pull/13181

From sspitsyn at openjdk.org  Fri Mar 24 18:40:12 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 24 Mar 2023 18:40:12 GMT
Subject: RFR: 8304448: Kitchensink failed:
 assert(!thread->is_in_any_VTMS_transition()) failed: class prepare events are
 not allowed in any VTMS transition
In-Reply-To: 
References: 
Message-ID: 

On Thu, 23 Mar 2023 09:10:26 GMT, Serguei Spitsyn  wrote:

> The fix was suggested/provided by @AlanBateman.
> Continuation should use Unsafe.compareAndSetReference rather than a VH here.
> We had to change CHM and VT back to Unsafe for similar reasons.
> 
> Testing: Mach5 runs of tiers 1-6 are in progress

Ron, thank you for review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13154#issuecomment-1483251518

From jlu at openjdk.org  Fri Mar 24 18:43:35 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 24 Mar 2023 18:43:35 GMT
Subject: RFR: 8225641: Calendar.roll(int field) does not work correctly for
 WEEK_OF_YEAR [v3]
In-Reply-To: 
References: 
Message-ID: 

> This PR fixes the bug which occurred when `Calendar.roll(WEEK_OF_YEAR)` rolled into a minimal first week with an invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo.
> 
> For example, Rolling _Monday, 30 December 2019_ by 1 week produced _Monday, 31 December 2018_, which is incorrect. This is because `WEEK_OF_YEAR` is rolled from 52 to 1, and the original `DAY_OF_WEEK` is 1. However, there is no Monday in week 1 of 2019. This is exposed when a future method calls `Calendar.complete()`, which eventually calculates a `fixedDate` with the invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo.
> 
> To prevent this, a check is added for rolls into week 1, which determines if the first week is minimal. If it is indeed minimal, then it is checked if  `DAY_OF_WEEK` exists in that week, if not, `WEEK_OF_YEAR` must be incremented by one.
> 
> After the fix, Rolling _Monday, 30 December 2019_ by 1 week produces _Monday, 7 January 2019_

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Expand testing to all end of year days that roll into week 1

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13031/files
  - new: https://git.openjdk.org/jdk/pull/13031/files/fe2f92f0..a844bb9d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13031&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13031&range=01-02

  Stats: 20 lines in 1 file changed: 12 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/13031.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13031/head:pull/13031

PR: https://git.openjdk.org/jdk/pull/13031

From jlu at openjdk.org  Fri Mar 24 18:43:36 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 24 Mar 2023 18:43:36 GMT
Subject: RFR: 8225641: Calendar.roll(int field) does not work correctly for
 WEEK_OF_YEAR [v2]
In-Reply-To: <3LYhtu7WPIFHrmKz1OnDiGGEaJR76JP33cQ3Rz3caCM=.cfcd0c61-d22e-4078-9320-4324a9a8186c@github.com>
References: 
 <3LYhtu7WPIFHrmKz1OnDiGGEaJR76JP33cQ3Rz3caCM=.cfcd0c61-d22e-4078-9320-4324a9a8186c@github.com>
Message-ID: 

On Fri, 24 Mar 2023 18:17:32 GMT, Justin Lu  wrote:

>> This PR fixes the bug which occurred when `Calendar.roll(WEEK_OF_YEAR)` rolled into a minimal first week with an invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo.
>> 
>> For example, Rolling _Monday, 30 December 2019_ by 1 week produced _Monday, 31 December 2018_, which is incorrect. This is because `WEEK_OF_YEAR` is rolled from 52 to 1, and the original `DAY_OF_WEEK` is 1. However, there is no Monday in week 1 of 2019. This is exposed when a future method calls `Calendar.complete()`, which eventually calculates a `fixedDate` with the invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo.
>> 
>> To prevent this, a check is added for rolls into week 1, which determines if the first week is minimal. If it is indeed minimal, then it is checked if  `DAY_OF_WEEK` exists in that week, if not, `WEEK_OF_YEAR` must be incremented by one.
>> 
>> After the fix, Rolling _Monday, 30 December 2019_ by 1 week produces _Monday, 7 January 2019_
>
> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Test all possible min week and first day of week combos for bugged date
>  - Add safety check that amount is positive

The test currently tests 343 combinations for rolling from the end of the year into week 1

Before patch:
[ JUnit Tests: found 343, started 343, succeeded 308, failed 35, aborted 0, skipped 0]

After patch:
[ JUnit Tests: found 343, started 343, succeeded 343, failed 0, aborted 0, skipped 0]

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13031#issuecomment-1483252698

From jlu at openjdk.org  Fri Mar 24 18:43:39 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 24 Mar 2023 18:43:39 GMT
Subject: RFR: 8225641: Calendar.roll(int field) does not work correctly for
 WEEK_OF_YEAR [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 15 Mar 2023 19:57:43 GMT, Naoto Sato  wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Expand testing to all end of year days that roll into week 1
>
> test/jdk/java/util/Calendar/RollToMinWeek.java line 79:
> 
>> 77:         return Stream.of(
>> 78:                 // Test a variety of rolls that previously produced incorrect results
>> 79:                 Arguments.of(buildCalendar(27, 11, 2020, Locale.ENGLISH),
> 
> The first day of week depends on the region, not the language. In fact, I would prefer explicitly specifying it via a locale like `en-US-u-fw-mon`, and testing all the weekdays.

Updated the testing

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13031#discussion_r1147939908

From jlu at openjdk.org  Fri Mar 24 18:48:41 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 24 Mar 2023 18:48:41 GMT
Subject: RFR: 8225641: Calendar.roll(int field) does not work correctly for
 WEEK_OF_YEAR [v4]
In-Reply-To: 
References: 
Message-ID: 

> This PR fixes the bug which occurred when `Calendar.roll(WEEK_OF_YEAR)` rolled into a minimal first week with an invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo.
> 
> For example, Rolling _Monday, 30 December 2019_ by 1 week produced _Monday, 31 December 2018_, which is incorrect. This is because `WEEK_OF_YEAR` is rolled from 52 to 1, and the original `DAY_OF_WEEK` is 1. However, there is no Monday in week 1 of 2019. This is exposed when a future method calls `Calendar.complete()`, which eventually calculates a `fixedDate` with the invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo.
> 
> To prevent this, a check is added for rolls into week 1, which determines if the first week is minimal. If it is indeed minimal, then it is checked if  `DAY_OF_WEEK` exists in that week, if not, `WEEK_OF_YEAR` must be incremented by one.
> 
> After the fix, Rolling _Monday, 30 December 2019_ by 1 week produces _Monday, 7 January 2019_

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Remove max week methods accidentally comitted

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13031/files
  - new: https://git.openjdk.org/jdk/pull/13031/files/a844bb9d..f837268c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13031&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13031&range=02-03

  Stats: 23 lines in 1 file changed: 0 ins; 23 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13031.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13031/head:pull/13031

PR: https://git.openjdk.org/jdk/pull/13031

From stsypanov at openjdk.org  Fri Mar 24 19:20:24 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Fri, 24 Mar 2023 19:20:24 GMT
Subject: RFR: 8304745: Lazily initialize byte[] in
 java.io.BufferedInputStream [v7]
In-Reply-To: 
References: 
Message-ID: <4tsiifY6SW4DZNjhSoGfoPdxh5VF84N2r-WaRCJ8nHs=.e7bc7cdb-3773-47e3-95c6-31565f2edd08@github.com>

> By default `BufferedInputStream` is constructed with internal buffer with capacity 8192. In some cases this buffer is never used, e.g. when we call `IS.readNBytes()` or `IS.readAllBytes()` (relying on `BIS.read1()`) or when `BufferedInputStream` is cascaded.

Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:

  Update test/micro/org/openjdk/bench/java/io/BufferedInputStreamBenchmark.java
  
  Co-authored-by: liach <7806504+liach at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13150/files
  - new: https://git.openjdk.org/jdk/pull/13150/files/e55ed936..cb426530

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13150&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13150&range=05-06

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13150.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13150/head:pull/13150

PR: https://git.openjdk.org/jdk/pull/13150

From stsypanov at openjdk.org  Fri Mar 24 19:30:22 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Fri, 24 Mar 2023 19:30:22 GMT
Subject: RFR: 8304745: Lazily initialize byte[] in
 java.io.BufferedInputStream [v8]
In-Reply-To: 
References: 
Message-ID: 

> By default `BufferedInputStream` is constructed with internal buffer with capacity 8192. In some cases this buffer is never used, e.g. when we call `IS.readNBytes()` or `IS.readAllBytes()` (relying on `BIS.read1()`) or when `BufferedInputStream` is cascaded.

Sergey Tsypanov has updated the pull request incrementally with two additional commits since the last revision:

 - Merge remote-tracking branch 'origin/8304745' into 8304745
   
   # Conflicts:
   #	test/micro/org/openjdk/bench/java/io/BufferedInputStreamBenchmark.java
 - 8304745: Fix line breaks

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13150/files
  - new: https://git.openjdk.org/jdk/pull/13150/files/cb426530..783a383b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13150&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13150&range=06-07

  Stats: 67 lines in 1 file changed: 1 ins; 0 del; 66 mod
  Patch: https://git.openjdk.org/jdk/pull/13150.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13150/head:pull/13150

PR: https://git.openjdk.org/jdk/pull/13150

From stsypanov at openjdk.org  Fri Mar 24 19:30:27 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Fri, 24 Mar 2023 19:30:27 GMT
Subject: RFR: 8304745: Lazily initialize byte[] in
 java.io.BufferedInputStream [v6]
In-Reply-To: <9HhJB3WN2_G6DJmTQyyBERJ2RtwTSz3mbhe5G7jG1N0=.bd6eea1b-0cd1-45c3-a0f3-187e6f592351@github.com>
References: 
 
 <9HhJB3WN2_G6DJmTQyyBERJ2RtwTSz3mbhe5G7jG1N0=.bd6eea1b-0cd1-45c3-a0f3-187e6f592351@github.com>
Message-ID: 

On Fri, 24 Mar 2023 17:59:24 GMT, Chen Liang  wrote:

>> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8304745: Amend copyright
>
> test/micro/org/openjdk/bench/java/io/BufferedInputStreamBenchmark.java line 1:
> 
>> 1: /*
> 
> Need to update the line ending of this file, like through intellij idea bottom right or sublime text view->line endings

Fixed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13150#discussion_r1147978115

From rriggs at openjdk.org  Fri Mar 24 19:34:32 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 24 Mar 2023 19:34:32 GMT
Subject: RFR: 8300818: Reduce complexity of padding with DateTimeFormatter
 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 22 Jan 2023 09:50:21 GMT, Sergey Tsypanov  wrote:

>> Currently it's O(n) - we do `n` shifts of bytes within `StringBuilder`. This can be reduced to O(1) improving the code like:
>> 
>> DateTimeFormatter dtf = new DateTimeFormatterBuilder()
>>   .appendLiteral("Date:")
>>   .padNext(20, ' ')
>>   .append(DateTimeFormatter.ISO_DATE)
>>   .toFormatter();
>> String text = dtf.format(LocalDateTime.now());
>
> Sergey Tsypanov 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 'master' into dtfb
>  - Improve padding of DateTimeFormatter

fyi, you might want to wait for https://github.com/openjdk/jdk/pull/12728

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12131#issuecomment-1466817993

From stsypanov at openjdk.org  Fri Mar 24 19:34:33 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Fri, 24 Mar 2023 19:34:33 GMT
Subject: RFR: 8300818: Reduce complexity of padding with DateTimeFormatter
 [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 13 Mar 2023 19:24:38 GMT, Roger Riggs  wrote:

>> Sergey Tsypanov 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 'master' into dtfb
>>  - Improve padding of DateTimeFormatter
>
> fyi, you might want to wait for https://github.com/openjdk/jdk/pull/12728

@RogerRiggs thanks for pointing this out. Could we also have an overloaded method for inserting apart from appending?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12131#issuecomment-1467740231

From stsypanov at openjdk.org  Fri Mar 24 19:34:33 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Fri, 24 Mar 2023 19:34:33 GMT
Subject: RFR: 8300818: Reduce complexity of padding with DateTimeFormatter
 [v2]
In-Reply-To: 
References: 
 
Message-ID: <86nDjsiZW-sBTnrBdVN95GWDGayZSZrCI0iI3eCbhFM=.8311443e-b3f6-48c4-91a6-119a0327c192@github.com>

On Sun, 22 Jan 2023 09:50:21 GMT, Sergey Tsypanov  wrote:

>> Currently it's O(n) - we do `n` shifts of bytes within `StringBuilder`. This can be reduced to O(1) improving the code like:
>> 
>> DateTimeFormatter dtf = new DateTimeFormatterBuilder()
>>   .appendLiteral("Date:")
>>   .padNext(20, ' ')
>>   .append(DateTimeFormatter.ISO_DATE)
>>   .toFormatter();
>> String text = dtf.format(LocalDateTime.now());
>
> Sergey Tsypanov 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 'master' into dtfb
>  - Improve padding of DateTimeFormatter

Benchmarking:

make test TEST="micro:time.format.DateTimeFormatterBench" MICRO="OPTIONS=-prof gc"

master

Benchmark                                                          Mode  Cnt     Score      Error   Units
DateTimeFormatterBench.formatWithPadding                          thrpt   15  1621.744 ?  216.203  ops/ms
DateTimeFormatterBench.formatWithPadding:?gc.alloc.rate           thrpt   15   295.938 ?   39.238  MB/sec
DateTimeFormatterBench.formatWithPadding:?gc.alloc.rate.norm      thrpt   15   192.000 ?    0.001    B/op
DateTimeFormatterBench.formatWithPadding:?gc.count                thrpt   15    23.000             counts
DateTimeFormatterBench.formatWithPadding:?gc.time                 thrpt   15   353.000                 ms
DateTimeFormatterBench.formatWithZeroPadding                      thrpt   15  2787.775 ? 1383.428  ops/ms
DateTimeFormatterBench.formatWithZeroPadding:?gc.alloc.rate       thrpt   15   401.775 ?  201.097  MB/sec
DateTimeFormatterBench.formatWithZeroPadding:?gc.alloc.rate.norm  thrpt   15   152.000 ?    0.001    B/op
DateTimeFormatterBench.formatWithZeroPadding:?gc.count            thrpt   15    22.000             counts
DateTimeFormatterBench.formatWithZeroPadding:?gc.time             thrpt   15   396.000                 ms


dtfb

Benchmark                                                          Mode  Cnt      Score     Error   Units
DateTimeFormatterBench.formatWithPadding                          thrpt   15   5489.480 ? 200.120  ops/ms
DateTimeFormatterBench.formatWithPadding:?gc.alloc.rate           thrpt   15   1171.637 ?  42.648  MB/sec
DateTimeFormatterBench.formatWithPadding:?gc.alloc.rate.norm      thrpt   15    224.000 ?   0.001    B/op
DateTimeFormatterBench.formatWithPadding:?gc.count                thrpt   15     62.000            counts
DateTimeFormatterBench.formatWithPadding:?gc.time                 thrpt   15    342.000                ms
DateTimeFormatterBench.formatWithZeroPadding                      thrpt   15  14355.239 ? 640.377  ops/ms
DateTimeFormatterBench.formatWithZeroPadding:?gc.alloc.rate       thrpt   15   2078.802 ?  93.278  MB/sec
DateTimeFormatterBench.formatWithZeroPadding:?gc.alloc.rate.norm  thrpt   15    152.000 ?   0.001    B/op
DateTimeFormatterBench.formatWithZeroPadding:?gc.count            thrpt   15     77.000            counts
DateTimeFormatterBench.formatWithZeroPadding:?gc.time             thrpt   15    555.000                ms

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12131#issuecomment-1483302436

From stsypanov at openjdk.org  Fri Mar 24 19:34:34 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Fri, 24 Mar 2023 19:34:34 GMT
Subject: RFR: 8300818: Reduce complexity of padding with DateTimeFormatter
 [v2]
In-Reply-To: <_gJmYty5eyRbpGo3AIlFE4HDkmGWAWPsAOqwJri3mqo=.70b5927c-2be5-484c-98f4-f21933166c55@github.com>
References: 
 
 
 <3Im4RP5-AmauuIjCVgA3V4h0HellqriqIlbTSjXjrWU=.a3b7c98f-276a-423a-8d48-c3415633b2cc@github.com>
 <_gJmYty5eyRbpGo3AIlFE4HDkmGWAWPsAOqwJri3mqo=.70b5927c-2be5-484c-98f4-f21933166c55@github.com>
Message-ID: <8-pc62MG2Qcj0reM0zl85Kunw2rZlQOMVZHyjKKSSSY=.4af17266-9d26-42e3-a357-fcda22f1fd5b@github.com>

On Mon, 23 Jan 2023 11:34:27 GMT, Claes Redestad  wrote:

>> The modified code is called only when a user explicitly calls `padNext(int, char)`, i.e. if I modified the example snippet as
>> 
>> DateTimeFormatter dtf = new DateTimeFormatterBuilder()
>>   .appendLiteral("Date:")
>> //.padNext(20, ' ')
>>   .append(DateTimeFormatter.ISO_DATE)
>>   .toFormatter();
>> String text = dtf.format(LocalDateTime.now());
>> 
>> there's no regression.
>> 
>> Right now I cannot build ad-hoc JDK with my changes and check it with JMH, so I'd convert this to draft until I can verify it
>
> Meant that you should verify that something like this, which just add a little padding, doesn't regress with your changes: 
> 
> DateTimeFormatter dtf = new DateTimeFormatterBuilder()
>     .appendLiteral("Year:")
>     .padNext(5)
>     .appendValue(ChronoField.YEAR)
>     .toFormatter();
> ... 
> dtf.format(LocalDateTime.now());
> 
> And similar for effectively no padding (`.padNext(4)` in the above example). As this API might often be used to ensure short 2-4 char fields are correctly padded I think it's important that we're not adding overhead to such use cases.

Added benchmark for this

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12131#discussion_r1147980908

From jlu at openjdk.org  Fri Mar 24 20:45:21 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 24 Mar 2023 20:45:21 GMT
Subject: RFR: 8177352: Calendar.getDisplayName(s) in non-lenient mode
 inconsistent, does not match spec
Message-ID: 

This PR updates the javadoc of `java.util.Calendar.getDisplayName()` and `java.util.Calendar.getDisplayNames()` to better reflect the actual behavior when the calendar is non-lenient.

This involves adding the **implSpec** tag to both methods to clarify behavior, as well as removing false behavior from the **throws** tag in `java.util.Calendar.getDisplayNames()`.

-------------

Commit messages:
 - Adjust wording of spec for getDisplayName()
 - Copyright year
 - Change to normal spec changes (as opposed to implSpec)
 - JDK-8177352

Changes: https://git.openjdk.org/jdk/pull/13083/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13083&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8177352
  Stats: 16 lines in 1 file changed: 12 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13083.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13083/head:pull/13083

PR: https://git.openjdk.org/jdk/pull/13083

From mchung at openjdk.org  Fri Mar 24 20:49:23 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 24 Mar 2023 20:49:23 GMT
Subject: RFR: 8304846: Provide a shared utility to dump generated classes
 defined via Lookup API
Message-ID: 

This implements a shared utility to dump generated classes defined as normal/hidden classes via `Lookup` API.   This replaces the implementation in `LambdaMetaFactory` and method handle implementation that dumps the hidden class bytes on disk for debugging.   

For classes defined via `Lookup::defineClass`, `Lookup::defineHiddenClass` and `Lookup::defineHiddenClassWithClassData`, by default they will be dumped to the path specified in `-Djava.lang.invoke.Lookup.dumpClasses=` 

The hidden classes generated for lambdas, `LambdaForms` and method handle implementation use non-default dumper so that they can be controlled via a separate system property and path as in the current implementation.

To dump lambda proxy classes, set this system property:
   -Djdk.internal.lambda.dumpProxyClasses=

To dump LambdaForms and method handle implementation, set this system property:
   -Djava.lang.invoke.MethodHandle.DUMP_CLASS_FILES=true
   
P.S. `ProxyClassesDumper` is renamed to `ClassFileDumper` but for some reason, it's not shown as rename.

-------------

Commit messages:
 - rename the system property
 - 8304846: Provide a shared utility to dump generated classes defined via Lookup API

Changes: https://git.openjdk.org/jdk/pull/13182/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13182&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304846
  Stats: 636 lines in 10 files changed: 317 ins; 262 del; 57 mod
  Patch: https://git.openjdk.org/jdk/pull/13182.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13182/head:pull/13182

PR: https://git.openjdk.org/jdk/pull/13182

From liach at openjdk.org  Fri Mar 24 21:08:31 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 24 Mar 2023 21:08:31 GMT
Subject: RFR: 8304846: Provide a shared utility to dump generated classes
 defined via Lookup API
In-Reply-To: 
References: 
Message-ID: 

On Fri, 24 Mar 2023 20:41:41 GMT, Mandy Chung  wrote:

> This implements a shared utility to dump generated classes defined as normal/hidden classes via `Lookup` API.   This replaces the implementation in `LambdaMetaFactory` and method handle implementation that dumps the hidden class bytes on disk for debugging.   
> 
> For classes defined via `Lookup::defineClass`, `Lookup::defineHiddenClass` and `Lookup::defineHiddenClassWithClassData`, by default they will be dumped to the path specified in `-Djava.lang.invoke.Lookup.dumpClasses=` 
> 
> The hidden classes generated for lambdas, `LambdaForms` and method handle implementation use non-default dumper so that they can be controlled via a separate system property and path as in the current implementation.
> 
> To dump lambda proxy classes, set this system property:
>    -Djdk.internal.lambda.dumpProxyClasses=
> 
> To dump LambdaForms and method handle implementation, set this system property:
>    -Djava.lang.invoke.MethodHandle.DUMP_CLASS_FILES=true
>    
> P.S. `ProxyClassesDumper` is renamed to `ClassFileDumper` but for some reason, it's not shown as rename.

src/java.base/share/classes/java/lang/invoke/ClassFileDumper.java line 88:

> 86:                 dir = validateDumpDir(Path.of(path.trim()));
> 87:             }
> 88:             DUMPER_MAP.putIfAbsent(key, new ClassFileDumper(key, dir));

Can just return `putIfAbsent` result to avoid another map lookup

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13182#discussion_r1148045563

From darcy at openjdk.org  Fri Mar 24 21:10:31 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 24 Mar 2023 21:10:31 GMT
Subject: RFR: 8304837: Classfile API throws IOOBE for MethodParameters
 attribute without parameter names [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 24 Mar 2023 06:42:30 GMT, Hannes Greule  wrote:

>> After merging master into https://github.com/openjdk/jdk/pull/9862, we encountered test failures (e.g., https://github.com/SirYwell/jdk/actions/runs/4500940829/jobs/7923018438#step:9:2541). The Classfile API tries to read from constant pool index 0 if a MethodParameters attribute has an entry without name.
>> 
>> The fix is simply using `readUtf8EntryOrNull` instead of `readUtf8Entry`. The related code already correctly handles nullability.
>> 
>> I didn't find an appropriate test class so I added a new one. Let me know if there's a better place or if the test can be improved somehow.
>> 
>> As I don't have a JBS account, someone needs to create a bug report there for me. Thanks.
>
> Hannes Greule has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move and fix test comment

And just to double-check, the JVMS does allow the parameter name information to be missing even if the access flags are defined:
https://docs.oracle.com/javase/specs/jvms/se20/html/jvms-4.html#jvms-4.7.24

> name_index
> 
>     The value of the name_index item must either be zero or a valid index into the constant_pool table.
> 
>     If the value of the name_index item is zero, then this parameters element indicates a formal parameter with no name.
> 
>     If the value of the name_index item is nonzero, the constant_pool entry at that index must be a CONSTANT_Utf8_info structure representing a valid unqualified name denoting a formal parameter ([?4.2.2](https://docs.oracle.com/javase/specs/jvms/se20/html/jvms-4.html#jvms-4.2.2)).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13167#issuecomment-1483407717

From naoto at openjdk.org  Fri Mar 24 22:09:32 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 24 Mar 2023 22:09:32 GMT
Subject: RFR: 8177352: Calendar.getDisplayName(s) in non-lenient mode
 inconsistent, does not match spec
In-Reply-To: 
References: 
Message-ID: 

On Fri, 17 Mar 2023 18:22:17 GMT, Justin Lu  wrote:

> This PR updates the javadoc of `java.util.Calendar.getDisplayName()` and `java.util.Calendar.getDisplayNames()` to better reflect the actual behavior when the calendar is non-lenient.
> 
> This involves updating the spec of both methods to clarify behavior, as well as removing false behavior from the **throws** tag in `java.util.Calendar.getDisplayNames()`.

Looks good. Please add `noreg-doc` label to the issue.

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13083#pullrequestreview-1357494038

From forax at univ-mlv.fr  Fri Mar 24 22:12:52 2023
From: forax at univ-mlv.fr (Remi Forax)
Date: Fri, 24 Mar 2023 23:12:52 +0100 (CET)
Subject: The non-deterministic iteration order of Immutable Collections
In-Reply-To: 
References: <1cf6bcc4-b7f9-fc72-8b3e-d3a3c785f54e@gmail.com>
 
Message-ID: <1736486140.20049663.1679695972064.JavaMail.zimbra@univ-eiffel.fr>

----- Original Message -----
> From: "Kasper Nielsen" 
> To: "Chris Hegarty" 
> Cc: "core-libs-dev" 
> Sent: Friday, March 24, 2023 6:53:51 PM
> Subject: Re: The non-deterministic iteration order of Immutable Collections

>>
>> I don't (yet) want to be prescriptive in any potential solution. And I
>> know that this has been discussed before. I mostly just want to start a
>> conversation and see how much traction it gets.
>>
> Would
> java.util.SequencedMap.of(...)
> java.util.SequencedMap.copyOf(SequencedMap map)
> java.util.SequencedSet.of(...)
> java.util.SequencedSet.copyOf(SequencedSet set)
> solve your problem?
> 
> I would love to see them included in JEP 431.
> Should be fairly simply to implement just have a side
> array that maintains the elements in order.

I do not think SequenceMap or SequencedSet should be use for copyOf(), Map and Collection should be used instead because the iteration order is enough.

This is sadly not something acknowledged by JEP 431, but SequencedSet or SequencedMap are not very useful as interfaces for typing the parameters of public methods. Like NavigableSet/NavigableMap, they can be handy for typing a specific implementation for a field or a local variable but for methods, they are not general enough.

> 
> /Kasper

regards,
R?mi

From tvaleev at openjdk.org  Fri Mar 24 22:28:49 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Fri, 24 Mar 2023 22:28:49 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
Message-ID: 

On Tue, 8 Feb 2022 17:23:38 GMT, Stuart Marks  wrote:

> PR for Sequenced Collections implementation.

Hello, Stuart!

I'm really glad that this proposal progresses, and now we have a solid implementation draft. In general, I like it very much. You may find a couple of comments from me in this review, hopefully, they are useful. Sorry if I wrote some nonsense, it's already too late here :-)

src/java.base/share/classes/java/util/LinkedHashMap.java line 782:

> 780:             return svs;
> 781:         } else {
> 782:             return new LinkedValues(false);

Is it possible that this branch is visited? If yes, probably it worth adding a comment when this happens.

src/java.base/share/classes/java/util/LinkedHashMap.java line 1123:

> 1121: 
> 1122:         public V put(K key, V value) {
> 1123:             return base.put(key, value);

Why `put()` simply delegates to `base.put()` while `putAll()` below does more complex containsKey-put-putFirst procedure? I think that `putAll()` should be equivalent to `for(var e : m.entrySet()) put(e.getKey(), e.getValue());`. Am I missing something?

src/java.base/share/classes/java/util/LinkedHashMap.java line 1197:

> 1195: 
> 1196:         public V computeIfAbsent(K key, Function mappingFunction) {
> 1197:             return base.computeIfAbsent(key, mappingFunction);

Again, it's somewhat worrysome that methods like `computeIfAbsent` will actually add new nodes to the end of original LinkedHashMap instead of to the beginning. Probably not very big deal but looks inconsistent...

src/java.base/share/classes/java/util/ReverseOrderDequeView.java line 64:

> 62: 
> 63:     public Spliterator spliterator() {
> 64:         return Spliterators.spliteratorUnknownSize(base.descendingIterator(), 0);

Could we use here `Spliterators.spliterator(this, base.spliterator().characteristics())`? Current implementation is not late-binding and never sized.

src/java.base/share/classes/java/util/ReverseOrderDequeView.java line 103:

> 101:     }
> 102: 
> 103:     // copied from AbstractCollection

Probably not the part of this PR, but it could be reasonable to create some utility CollectionSupport class and create static methods (e.g. `static boolean remove(Collection c, Object o)`) with the implementations of common collection algorithms, like this one. WDYT?

src/java.base/share/classes/java/util/ReverseOrderDequeView.java line 167:

> 165:     public  T[] toArray(T[] a) {
> 166:         // TODO can probably optimize this
> 167:         return toArray(i -> (T[]) java.lang.reflect.Array.newInstance(a.getClass().getComponentType(), i));

Hm... Does it follow the spec when the size of `a` is greater than the size of this collection? In this case, we should return the supplied array filling it partially and setting the next element to null. Here, we will always create a new array, which seems to violate the spec.

src/java.base/share/classes/java/util/ReverseOrderListView.java line 153:

> 151:     public Spliterator spliterator() {
> 152:         // TODO can probably improve this
> 153:         return Spliterators.spliteratorUnknownSize(new DescendingIterator(), 0);

Again, `Spliterators.spliterator(this, base.spliterator().characteristics())` may work better (though haven't checked)

src/java.base/share/classes/java/util/ReverseOrderListView.java line 168:

> 166:         boolean modified = false;
> 167:         for (E e : c) {
> 168:             base.add(0, e);

This is worrysome from performance point of view for base implementations like ArrayList where every insertion means shifting the whole array. At least, we could optimize if `c` is `SequencedCollection`, like `if (c instanceof SequencedCollection sc) base.addAll(0, sc.reversed())`. Otherwise, we can use `base.addAll(0, Arrays.asList(sc.toArray()).reversed())` (with a couple of unchecked casts).

src/java.base/share/classes/java/util/ReverseOrderListView.java line 288:

> 286:     public  T[] toArray(T[] a) {
> 287:         // TODO can probably optimize this
> 288:         return toArray(i -> (T[]) java.lang.reflect.Array.newInstance(a.getClass().getComponentType(), i));

Incorrect implementation again

src/java.base/share/classes/java/util/ReverseOrderListView.java line 316:

> 314:     public void add(int index, E element) {
> 315:         checkModifiable();
> 316:         base.add(base.size() - index, element);

Note that if index is out of bounds, the original collection may throw a confusing exception, as `base.size() - index` will be reported instead. Probably adding explicit bounds checking call before delegation would be better. Same applies to other index-based operations.

src/java.base/share/classes/java/util/ReverseOrderListView.java line 319:

> 317:     }
> 318: 
> 319:     public boolean addAll(int index, Collection c) {

Similar considerations, as for `addAll(Collection)`.

src/java.base/share/classes/java/util/ReverseOrderSortedMapView.java line 99:

> 97: 
> 98:     public Set keySet() {
> 99:         return new AbstractSet<>() {

At very least, please delegate `contains`, `remove`, and `clear`, to avoid O(N) complexity there. Same for `values()` and `entrySet()`

src/java.base/share/classes/java/util/ReverseOrderSortedMapView.java line 185:

> 183: 
> 184:     static  Iterator descendingKeyIterator(SortedMap map) {
> 185:         return new Iterator<>() {

Probably create `descendingEntryIterator` as base, and derive `descendingKeyIterator` and `descendingValueIterator`? This way, `map.get()` inside `descendingValueIterator` and `descendingEntryIterator` could be avoided.

-------------

PR Review: https://git.openjdk.org/jdk/pull/7387#pullrequestreview-1357459425
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1148075441
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1148079423
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1148081322
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1148090986
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1148092195
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1148096483
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1148097411
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1148098823
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1148099182
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1148099726
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1148100155
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1148102202
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1148103978

From tvaleev at openjdk.org  Fri Mar 24 22:28:50 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Fri, 24 Mar 2023 22:28:50 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
 <9_34ZKelWdc1dC_aPGVB9zo4caFdMa2xPmnjlzd94CY=.491ae57b-b117-4372-a71f-4669e2fd3545@github.com>
 
Message-ID: 

On Thu, 3 Nov 2022 00:49:52 GMT, Stuart Marks  wrote:

>> @stuart-marks What are examples of cases where it wouldn't be reasonable: https://github.com/openjdk/jdk/pull/7387/files#diff-2b261a88d9ed30893d24186a36ef500d284d82e8f345591fc6c44ed5ae15da4fR161 ?
>
> I had to uncomment that line to figure out what broke. :-) Turns out `TreeSet.reversed().reversed()` doesn't return the original TreeSet. This is because `descendingSet().descendingSet()` doesn't unwrap, and neither does TreeMap's `descendingMap().descendingMap()`. I don't know what this wasn't done in the first place. Nonetheless, since unwrapping isn't done in the underlying implementation, it doesn't seem reasonable for the specification to require it be done. Furthermore this enables `reversed()` to be implemented as a default method that simply delegates to the respective `descending*()` method.

Also, `unmodifiableSequencedCollection(c).reversed().reversed()` does not return the original `unmodifiableSequencedCollection(c)`. And we probably cannot even specify that `x.reversed().reversed().equals(x)`, due to lack of `equals()` specification for all collections (in particular, Deques)...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1148106570

From kasperni at gmail.com  Fri Mar 24 22:29:24 2023
From: kasperni at gmail.com (Kasper Nielsen)
Date: Fri, 24 Mar 2023 22:29:24 +0000
Subject: The non-deterministic iteration order of Immutable Collections
In-Reply-To: <1736486140.20049663.1679695972064.JavaMail.zimbra@univ-eiffel.fr>
References: <1cf6bcc4-b7f9-fc72-8b3e-d3a3c785f54e@gmail.com>
 
 <1736486140.20049663.1679695972064.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: 

> >>
> >> I don't (yet) want to be prescriptive in any potential solution. And I
> >> know that this has been discussed before. I mostly just want to start a
> >> conversation and see how much traction it gets.
> >>
> > Would
> > java.util.SequencedMap.of(...)
> > java.util.SequencedMap.copyOf(SequencedMap map)
> > java.util.SequencedSet.of(...)
> > java.util.SequencedSet.copyOf(SequencedSet set)
> > solve your problem?
> >
> > I would love to see them included in JEP 431.
> > Should be fairly simply to implement just have a side
> > array that maintains the elements in order.
>
> I do not think SequenceMap or SequencedSet should be use for copyOf(), Map and Collection should be used instead because the iteration order is enough.

Agreed, I realized it after having sent the mail.

/Kasper

From xenoamess at gmail.com  Fri Mar 24 22:30:37 2023
From: xenoamess at gmail.com (Xeno Amess)
Date: Sat, 25 Mar 2023 06:30:37 +0800
Subject: The non-deterministic iteration order of Immutable Collections
In-Reply-To: <1736486140.20049663.1679695972064.JavaMail.zimbra@univ-eiffel.fr>
References: <1cf6bcc4-b7f9-fc72-8b3e-d3a3c785f54e@gmail.com>
 
 <1736486140.20049663.1679695972064.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: 

maybe you can use some java agent to hack in the of function, and change it
to some strange order, to make you see where goes wrong easier?

Remi Forax  ?2023?3?25??? 06:13???

> ----- Original Message -----
> > From: "Kasper Nielsen" 
> > To: "Chris Hegarty" 
> > Cc: "core-libs-dev" 
> > Sent: Friday, March 24, 2023 6:53:51 PM
> > Subject: Re: The non-deterministic iteration order of Immutable
> Collections
>
> >>
> >> I don't (yet) want to be prescriptive in any potential solution. And I
> >> know that this has been discussed before. I mostly just want to start a
> >> conversation and see how much traction it gets.
> >>
> > Would
> > java.util.SequencedMap.of(...)
> > java.util.SequencedMap.copyOf(SequencedMap map)
> > java.util.SequencedSet.of(...)
> > java.util.SequencedSet.copyOf(SequencedSet set)
> > solve your problem?
> >
> > I would love to see them included in JEP 431.
> > Should be fairly simply to implement just have a side
> > array that maintains the elements in order.
>
> I do not think SequenceMap or SequencedSet should be use for copyOf(), Map
> and Collection should be used instead because the iteration order is enough.
>
> This is sadly not something acknowledged by JEP 431, but SequencedSet or
> SequencedMap are not very useful as interfaces for typing the parameters of
> public methods. Like NavigableSet/NavigableMap, they can be handy for
> typing a specific implementation for a field or a local variable but for
> methods, they are not general enough.
>
> >
> > /Kasper
>
> regards,
> R?mi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From mchung at openjdk.org  Fri Mar 24 23:00:12 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 24 Mar 2023 23:00:12 GMT
Subject: RFR: 8304846: Provide a shared utility to dump generated classes
 defined via Lookup API [v2]
In-Reply-To: 
References: 
Message-ID: 

> This implements a shared utility to dump generated classes defined as normal/hidden classes via `Lookup` API.   This replaces the implementation in `LambdaMetaFactory` and method handle implementation that dumps the hidden class bytes on disk for debugging.   
> 
> For classes defined via `Lookup::defineClass`, `Lookup::defineHiddenClass` and `Lookup::defineHiddenClassWithClassData`, by default they will be dumped to the path specified in `-Djava.lang.invoke.Lookup.dumpClasses=` 
> 
> The hidden classes generated for lambdas, `LambdaForms` and method handle implementation use non-default dumper so that they can be controlled via a separate system property and path as in the current implementation.
> 
> To dump lambda proxy classes, set this system property:
>    -Djdk.internal.lambda.dumpProxyClasses=
> 
> To dump LambdaForms and method handle implementation, set this system property:
>    -Djava.lang.invoke.MethodHandle.DUMP_CLASS_FILES=true
>    
> P.S. `ProxyClassesDumper` is renamed to `ClassFileDumper` but for some reason, it's not shown as rename.

Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:

  avoid another map lookup

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13182/files
  - new: https://git.openjdk.org/jdk/pull/13182/files/d1c739cf..04406e3b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13182&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13182&range=00-01

  Stats: 14 lines in 1 file changed: 8 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/13182.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13182/head:pull/13182

PR: https://git.openjdk.org/jdk/pull/13182

From mchung at openjdk.org  Fri Mar 24 23:00:17 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 24 Mar 2023 23:00:17 GMT
Subject: RFR: 8304846: Provide a shared utility to dump generated classes
 defined via Lookup API [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 24 Mar 2023 20:54:25 GMT, Chen Liang  wrote:

>> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   avoid another map lookup
>
> src/java.base/share/classes/java/lang/invoke/ClassFileDumper.java line 88:
> 
>> 86:                 dir = validateDumpDir(Path.of(path.trim()));
>> 87:             }
>> 88:             DUMPER_MAP.putIfAbsent(key, new ClassFileDumper(key, dir));
> 
> Can just return `putIfAbsent` result to avoid another map lookup

This is not performance critical.  I updated it anyway.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13182#discussion_r1148129324

From stuart.marks at oracle.com  Sat Mar 25 00:16:39 2023
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 24 Mar 2023 17:16:39 -0700
Subject: The non-deterministic iteration order of Immutable Collections
In-Reply-To: <1cf6bcc4-b7f9-fc72-8b3e-d3a3c785f54e@gmail.com>
References: <1cf6bcc4-b7f9-fc72-8b3e-d3a3c785f54e@gmail.com>
Message-ID: <39ceb9e6-3681-13f4-4fa3-b9e298203a70@oracle.com>



On 3/24/23 10:18 AM, Chris Hegarty wrote:
> I know that this has come up a number of times before, but I cannot seem to find 
> anything directly relevant to my use-case, or recent.
> 
> The iteration order of immutable Sets and Maps (created by the `of` factories) is 
> clearly unspecified - good. Code should not depend upon this iteration order, and if 
> so that code is broken. I completely agree and am aligned with this principle.
> 
> The Elasticsearch code base heavily uses these collection implementations, and their 
> iterators. On occasion we run into issues, where our code (because of a bug or a 
> race), inadvertently has a dependency on the iteration order. To be clear, this is a 
> bug in our code, and we want to reproduce and fix it.? The problem we are 
> encountering is that the iteration order is not determinable or reproducible, which 
> makes it extremely challenging to reproduce the bug even when we have reproducible 
> testcase to hand. ( whereas, for example, it is common practice in other parts of 
> the code to log a seed used for randomization )
> 
> We very much like using the immutable collections, and we definitely don't want to 
> pay the price of sorting things in the code, since we don't want to, and should not, 
> depend upon the iteration order. The only concern is with reproducibility when we 
> run into (our own) bugs.
> 
> I don't (yet) want to be prescriptive in any potential solution. And I know that 
> this has been discussed before. I mostly just want to start a conversation and see 
> how much traction it gets.

Hi Chris,

Yes, this has come up before, but it's been mostly theoretical. That is, people 
worry about this when they hear of the idea of randomized iteration order, but I've 
never heard any followup. This is in fact the first time I've heard of an actual 
case where this is a real problem. So thanks for bringing it up.

(And unfortunately, it's notoriously difficult to make code truly iteration-order 
dependent. We've had our own history of problems with this in the JDK. I'd be 
interested in hearing from you at some point about the exact pathology of how this 
occurred.)

There's currently no debugging or experimental interface that will let one print or 
set the random seed that's in use. The obvious approach of using an agent to hack 
away at runtime doesn't work, because the unmodifiable collections implementations 
are used very early in startup and they're usually loaded before the agent runs. 
There are limitations on what an agent can do when redefining an already-loaded 
class, for example, removing the 'final' modifier from fields isn't supported. (Well 
I suppose one can always use Unsafe.)

Here's another approach that might work for you.

1. Write a little program that extracts the class bytes of ImmutableCollection.class 
from the runtime image, and use something like ASM or ClassFile to make the class 
public and to make the REVERSE and SALT32L fields public and non-final.

2. Launch a VM using the --patch-module option to use this class instead of the 
built-in one.

3. Write an agent, or some debugging library that's called at the right time, to use 
simple reflective access to get or set those fields as desired.

This is a bit fiddly but it might be easier than rebuilding and deploying a custom JDK.

Setting (formerly) final fields after the VM is initialized is often somewhat risky. 
In this case these particular fields are used only during iteration, and they don't 
actually change the layout of any data structures. So setting them to some desired 
value should apply to all subsequent iterations, even of existing data structures.

I'll think about better ways to do this in the product. The best approach isn't 
obvious. The typical way of doing things like this using system properties is 
tricky, as it depends on order of class initialization at startup (and you know how 
fragile that is).

s'marks

From stuart.marks at oracle.com  Sat Mar 25 00:17:44 2023
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 24 Mar 2023 17:17:44 -0700
Subject: The non-deterministic iteration order of Immutable Collections
In-Reply-To: 
References: <1cf6bcc4-b7f9-fc72-8b3e-d3a3c785f54e@gmail.com>
 
Message-ID: 



On 3/24/23 10:53 AM, Kasper Nielsen wrote:
> Would
> java.util.SequencedMap.of(...)
> java.util.SequencedMap.copyOf(SequencedMap map)
> java.util.SequencedSet.of(...)
> java.util.SequencedSet.copyOf(SequencedSet set)
> solve your problem?
> 
> I would love to see them included in JEP 431.
> Should be fairly simply to implement just have a side
> array that maintains the elements in order.

These are fine ideas, but they won't be part of JEP 431. They might be reasonable as 
a future enhancement, though.

s'marks


From smarks at openjdk.org  Sat Mar 25 03:19:38 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Sat, 25 Mar 2023 03:19:38 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
Message-ID: 

On Fri, 24 Mar 2023 22:26:03 GMT, Tagir F. Valeev  wrote:

>> PR for Sequenced Collections implementation.
>
> Hello, Stuart!
> 
> I'm really glad that this proposal progresses, and now we have a solid implementation draft. In general, I like it very much. You may find a couple of comments from me in this review, hopefully, they are useful. Sorry if I wrote some nonsense, it's already too late here :-)

@amaembo 

> I'm really glad that this proposal progresses, and now we have a solid implementation draft. In general, I like it very much. You may find a couple of comments from me in this review, hopefully, they are useful. Sorry if I wrote some nonsense, it's already too late here :-)

Thanks for looking! I took a quick look through the comments and they seem reasonable. Right now I'm concentrating on the specification in order to get the CSR Finalized. Do you have any comments on the specifications? I'll take a look at the implementation comments afterward. Some I'll be able to address before integration, but some I might need to postpone until later.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1483701691

From smarks at openjdk.org  Sat Mar 25 03:54:23 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Sat, 25 Mar 2023 03:54:23 GMT
Subject: RFR: 8266571: Sequenced Collections [v2]
In-Reply-To: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
Message-ID: 

> PR for Sequenced Collections implementation.

Stuart Marks has updated the pull request incrementally with two additional commits since the last revision:

 - More specification tweaks.
 - Add simple overrides to ArrayList.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/7387/files
  - new: https://git.openjdk.org/jdk/pull/7387/files/31f7d102..500841de

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=7387&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=7387&range=00-01

  Stats: 155 lines in 10 files changed: 110 ins; 13 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/7387.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/7387/head:pull/7387

PR: https://git.openjdk.org/jdk/pull/7387

From duke at openjdk.org  Sat Mar 25 05:58:34 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Sat, 25 Mar 2023 05:58:34 GMT
Subject: RFR: 8304745: Lazily initialize byte[] in
 java.io.BufferedInputStream [v8]
In-Reply-To: 
References: 
 
Message-ID: <6WBr0oAq4e23dolVX_iixK6Q2OOwZtgLfcCQoqkdp5o=.f277f498-f00c-43c6-82d5-3bf884b7dd9d@github.com>

On Fri, 24 Mar 2023 19:30:22 GMT, Sergey Tsypanov  wrote:

>> By default `BufferedInputStream` is constructed with internal buffer with capacity 8192. In some cases this buffer is never used, e.g. when we call `IS.readNBytes()` or `IS.readAllBytes()` (relying on `BIS.read1()`) or when `BufferedInputStream` is cascaded.
>
> Sergey Tsypanov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/8304745' into 8304745
>    
>    # Conflicts:
>    #	test/micro/org/openjdk/bench/java/io/BufferedInputStreamBenchmark.java
>  - 8304745: Fix line breaks

I think the benchmark would benefit with a few words explaining why you focused on those methods/calling patterns. For someone walking past this benchmark, this is not obvious why you picked those.

Either a class block comment or block comments for each of the benchmark methods would help understandability.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13150#issuecomment-1483735781

From liach at openjdk.org  Sat Mar 25 05:59:20 2023
From: liach at openjdk.org (Chen Liang)
Date: Sat, 25 Mar 2023 05:59:20 GMT
Subject: RFR: 8304918: Remove unused decl field from AnnotatedType
 implementations
Message-ID: 

In `AnnotatedTypeBaseImpl`, a `decl` field is declared, referring to the declaration that the AnnotatedType is from. However, this field is not used anywhere except passing to constructors of other implementations; it's not used in debug messages (unlike in `TypeAnnotation`), not involved in equality checks. Since these implementations are not serializable, we can safely remove the decl field from the implementations. All 1048 java/lang tests pass on my machine.

-------------

Commit messages:
 - Remove unused decl field from AnnotatedType implementations

Changes: https://git.openjdk.org/jdk/pull/13183/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13183&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304918
  Stats: 52 lines in 2 files changed: 0 ins; 25 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/13183.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13183/head:pull/13183

PR: https://git.openjdk.org/jdk/pull/13183

From duke at openjdk.org  Sat Mar 25 06:47:21 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Sat, 25 Mar 2023 06:47:21 GMT
Subject: RFR: 8304013: Add a fast,
 non-manual alternative to test/jdk/java/util/zip/ZipFile/TestTooManyEntries
 [v2]
In-Reply-To: 
References: 
Message-ID: <8x4IT78E3DFOATV8qda98Zib0m_Vt87btY5rpe2dhbI=.066d4614-6dff-432a-b4dd-cd109add66a8@github.com>

> The TestTooManyEntries test was originally added to validate that ZIP64 files with CEN sizes exceeding what ZipFile  supports are rejected with a ZipException. The test does this by creating a large ZIP file (several gigabytes) with many enties. Because this is resource intensive, the test is currently tagged as manual.  (See #6927)
> 
> It would be useful to have a test which asserts the CEN size enforcement, but without the CPU, disk, memory and run time requirements of TestTooManyEntries.  Such a fast test can run non-manual,  without the @requires and manual tags as found in TestTooManyEntries.
> 
> This PR adds the EndOfCenValidation test which creates sparse test ZIPs where the CEN is "inflated" such that is matches the size declared in the "End of central directory" records.
> 
> While thee sparse files look large, they consume very little disk space on file systems supporting sparse files:
> 
> 
> 16 -rw-r--r--  1   2147483702 Feb  6 18:54 bad-cen-offset.zip
> 16 -rw-r--r--  1   2147483703 Feb  6 18:54 cen-size-too-large.zip
>  8 -rw-r--r--  1          132 Feb  6 18:54 invalid-zen-size.zip
> ``` 
> 
> For good measure, two new test methods are added to excercise the remaining ZipExceptions which ZipFile may throw during validation of the END record .

Eirik Bjorsnos has updated the pull request incrementally with three additional commits since the last revision:

 - Remove @throws as per review feedback
 - Consistently use the term "END header" when referring to the "End of central directory record".
 - Remove "the the" repetition

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12231/files
  - new: https://git.openjdk.org/jdk/pull/12231/files/e348201f..623d3749

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12231&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12231&range=00-01

  Stats: 20 lines in 1 file changed: 0 ins; 3 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/12231.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12231/head:pull/12231

PR: https://git.openjdk.org/jdk/pull/12231

From duke at openjdk.org  Sat Mar 25 06:47:23 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Sat, 25 Mar 2023 06:47:23 GMT
Subject: RFR: 8304013: Add a fast,
 non-manual alternative to test/jdk/java/util/zip/ZipFile/TestTooManyEntries
 [v2]
In-Reply-To: 
References: 
 
Message-ID: <7FhqMvP8gxssuoAbq9Uu5-YUlmlx4RCF1qCUPTtSqq8=.962f226c-2231-4e78-b84f-ba278ee29311@github.com>

On Fri, 24 Mar 2023 18:26:02 GMT, Martin Buchholz  wrote:

>> Eirik Bjorsnos has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Remove @throws as per review feedback
>>  - Consistently use the term "END header" when referring to the "End of central directory record".
>>  - Remove "the the" repetition
>
> test/jdk/java/util/zip/ZipFile/EndOfCenValidation.java line 52:
> 
>> 50: 
>> 51: /**
>> 52:  * This test augments {@link TestTooManyEntries}. It creates sparse ZIPs where the
> 
> remove the "the" stutter

"the" stutter has been removed ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12231#discussion_r1148316463

From duke at openjdk.org  Sat Mar 25 06:49:33 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Sat, 25 Mar 2023 06:49:33 GMT
Subject: RFR: 8304013: Add a fast,
 non-manual alternative to test/jdk/java/util/zip/ZipFile/TestTooManyEntries
 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 24 Mar 2023 18:28:36 GMT, Martin Buchholz  wrote:

>> Eirik Bjorsnos has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Remove @throws as per review feedback
>>  - Consistently use the term "END header" when referring to the "End of central directory record".
>>  - Remove "the the" repetition
>
> test/jdk/java/util/zip/ZipFile/EndOfCenValidation.java line 120:
> 
>> 118:     /**
>> 119:      * Validate that an end of central directory record with a
>> 120:      * CEN size which exceeds the position of the EOC record is rejected.
> 
> EOC is not a standard zip file technical term.  Did you mean "END header" ?

If by "standard" you mean "APPNOTE.TXT", then that uses "end of central directory record" which is a bit long.

The Java implementation seems to use END, like in `ZipFile.ENDHDR`, "END header", etc.

It is probably better to be consistent than correct here, so I've changed the test to use "END header" consistently when referring to the "end of central directory record".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12231#discussion_r1148316828

From duke at openjdk.org  Sat Mar 25 06:53:31 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Sat, 25 Mar 2023 06:53:31 GMT
Subject: RFR: 8304013: Add a fast,
 non-manual alternative to test/jdk/java/util/zip/ZipFile/TestTooManyEntries
 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 24 Mar 2023 18:30:26 GMT, Martin Buchholz  wrote:

>> Eirik Bjorsnos has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Remove @throws as per review feedback
>>  - Consistently use the term "END header" when referring to the "End of central directory record".
>>  - Remove "the the" repetition
>
> test/jdk/java/util/zip/ZipFile/EndOfCenValidation.java line 139:
> 
>> 137:      * Validate that an end of central directory record with a CEN offset which
>> 138:      * is larger than the EOC position minus the CEN size is rejected
>> 139:      * @throws IOException
> 
> I don't think `@throws` javadoc comments in tests are useful; especially checked ones

I recently added a `@throws` by review comment from Lance. I tend to agree that is not very useful, so I'm removing both ocurrences as per your recommendation.

If Lance wants it back, he can add a review comment saying so. I don't particularly care which professor gets the last word in this matter :-)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12231#discussion_r1148317170

From duke at openjdk.org  Sat Mar 25 06:57:32 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Sat, 25 Mar 2023 06:57:32 GMT
Subject: RFR: 8304013: Add a fast,
 non-manual alternative to test/jdk/java/util/zip/ZipFile/TestTooManyEntries
 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 24 Mar 2023 16:36:46 GMT, Lance Andersen  wrote:

>> Eirik Bjorsnos has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Remove @throws as per review feedback
>>  - Consistently use the term "END header" when referring to the "End of central directory record".
>>  - Remove "the the" repetition
>
> Mach 5 test runs are clean so you are good to go Eirik, thank you again

@LanceAndersen Would you like to do a final review after the changes suggested by Martin in his late review?

It is mostly comment changes, and some stray variable renames. I have run the test locally after the last changes, and it passes on my machine.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12231#issuecomment-1483744996

From forax at openjdk.org  Sat Mar 25 07:13:38 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Sat, 25 Mar 2023 07:13:38 GMT
Subject: RFR: 8266571: Sequenced Collections [v2]
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
Message-ID: <3e6DVS8g_L4Yv27PiLlRyv6Fu7RsSR43gvKKHZKQvmw=.296a96fe-6134-407b-8078-d65e54bfbc30@github.com>

On Sat, 25 Mar 2023 03:54:23 GMT, Stuart Marks  wrote:

>> PR for Sequenced Collections implementation.
>
> Stuart Marks has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - More specification tweaks.
>  - Add simple overrides to ArrayList.

src/java.base/share/classes/java/util/ArrayList.java line 573:

> 571:         } else {
> 572:             Object[] es = elementData;
> 573:             sz--;

This line and the following two lines can be understood as the field size being updated which is not the case.
I think it's more readable to use

@SuppressWarnings("unchecked") E oldValue = (E) es[sz - 1];
fastRemove(es, sz - 1);

The JIT will common the subexpression 'sz - 1' at runtime.

src/java.base/share/classes/java/util/Collections.java line 1173:

> 1171:      * @serial include
> 1172:      */
> 1173:     static class UnmodifiableSequencedCollection extends UnmodifiableCollection

`private` is missing

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1148319735
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1148319899

From forax at openjdk.org  Sat Mar 25 07:22:40 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Sat, 25 Mar 2023 07:22:40 GMT
Subject: RFR: 8266571: Sequenced Collections [v2]
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
Message-ID: 

On Sat, 25 Mar 2023 03:54:23 GMT, Stuart Marks  wrote:

>> PR for Sequenced Collections implementation.
>
> Stuart Marks has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - More specification tweaks.
>  - Add simple overrides to ArrayList.

src/java.base/share/classes/java/util/Collections.java line 1184:

> 1182: 
> 1183:         @SuppressWarnings("unchecked")
> 1184:         private SequencedCollection rc() {

I suggest to use 'delegate' as name instead of 'rc' (no idea what 'rc' means)

src/java.base/share/classes/java/util/Collections.java line 6014:

> 6012:      */
> 6013:     public static  SequencedSet newSequencedSetFromMap(SequencedMap map) {
> 6014:         if (! map.isEmpty())

This line does an implicit NPE check, either make it explicit using requireNonNull or at least add a comment

src/java.base/share/classes/java/util/Collections.java line 6023:

> 6021:      */
> 6022:     private static class SequencedSetFromMap extends SetFromMap implements SequencedSet {
> 6023:         private final E nsee(Map.Entry e) {

`static` instead of `final`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1148320373
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1148320720
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1148320942

From forax at openjdk.org  Sat Mar 25 07:43:47 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Sat, 25 Mar 2023 07:43:47 GMT
Subject: RFR: 8266571: Sequenced Collections [v2]
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
Message-ID: 

On Sat, 25 Mar 2023 03:54:23 GMT, Stuart Marks  wrote:

>> PR for Sequenced Collections implementation.
>
> Stuart Marks has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - More specification tweaks.
>  - Add simple overrides to ArrayList.

src/java.base/share/classes/java/util/LinkedHashSet.java line 297:

> 295:      */
> 296:     public SequencedSet reversed() {
> 297:         class ReverseLinkedHashSetView extends AbstractSet implements SequencedSet {

This class should be declared `static` (and private) which means it should not be declared inside reversed.

src/java.base/share/classes/java/util/LinkedHashSet.java line 313:

> 311:                 boolean present = LinkedHashSet.this.contains(e);
> 312:                 LinkedHashSet.this.addFirst(e);
> 313:                 return ! present;

why there is a space between '!' and 'present' given that you have removed this space in another change above ?

src/java.base/share/classes/java/util/LinkedList.java line 1293:

> 1291:     @SuppressWarnings("serial")
> 1292:     static class ReverseOrderLinkedListView extends LinkedList implements java.io.Externalizable {
> 1293:         final LinkedList list;

Using 3 different fields feel ugly given it seems you only need one.
Why do you not use the casting strategy you are using for the other views ?

src/java.base/share/classes/java/util/List.java line 802:

> 800:      */
> 801:     default E getFirst() {
> 802:         if (this.isEmpty())

weirdly, sometimes you use braces around the ''if and sometimes you don't ?

src/java.base/share/classes/java/util/ReverseOrderListView.java line 60:

> 58:     }
> 59: 
> 60:     ReverseOrderListView(List list, boolean modifiable) {

should be 'private' to force users to use 'of'

src/java.base/share/classes/java/util/ReverseOrderListView.java line 191:

> 189:         if (o == this)
> 190:             return true;
> 191:         if (!(o instanceof List))

should be `if (!(o instanceof List list))`

src/java.base/share/classes/java/util/ReverseOrderListView.java line 209:

> 207:         int hashCode = 1;
> 208:         for (E e : this)
> 209:             hashCode = 31*hashCode + (e==null ? 0 : e.hashCode());

`31 * hashCode` instead of `31*hashCode`

src/java.base/share/classes/java/util/ReverseOrderSortedMapView.java line 44:

> 42:     public static  SortedMap of(SortedMap map) {
> 43:         if (map instanceof ReverseOrderSortedMapView) {
> 44:             return ((ReverseOrderSortedMapView)map).base;

use `map instanceof ReverseOrderSortedMapView view` instead to remove the ugly cast below

src/java.base/share/classes/java/util/ReverseOrderSortedMapView.java line 215:

> 213:     static  Iterator descendingValueIterator(SortedMap map) {
> 214:         return new Iterator<>() {
> 215:             Iterator keyIterator = descendingKeyIterator(map);

`private final` or better declare it above as a local variable and capture it inside the anonymous class

src/java.base/share/classes/java/util/ReverseOrderSortedMapView.java line 329:

> 327:                 K prevKey = null;
> 328:                 boolean dead = false;
> 329:                 Iterator> it = descendingEntryIterator(base);

see above about declare it as a local variable, all other fields should be `private`

src/java.base/share/classes/java/util/ReverseOrderSortedSetView.java line 61:

> 59:             return true;
> 60: 
> 61:         if (!(o instanceof Set))

use `if (!(o instanceof Set set))` to avoid the cast below

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1148321554
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1148321635
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1148321852
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1148322049
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1148322292
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1148322490
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1148322511
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1148322728
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1148322895
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1148323316
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1148323602

From forax at openjdk.org  Sat Mar 25 08:22:41 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Sat, 25 Mar 2023 08:22:41 GMT
Subject: RFR: 8266571: Sequenced Collections [v2]
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
Message-ID: <7hyZMdc6JI-92HcIQyh4gFMimualCSo-kSuApHjRPks=.4d53a75e-9caa-448d-a087-d1a03da8130a@github.com>

On Sat, 25 Mar 2023 03:54:23 GMT, Stuart Marks  wrote:

>> PR for Sequenced Collections implementation.
>
> Stuart Marks has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - More specification tweaks.
>  - Add simple overrides to ArrayList.

This change is absolutely massive, implementing reversed() basically doubles the number of implementations which means multiple years of debugging / spec fixing.

Reversing a List makes sense, reversing a LinkedHashSet/LinkedHashMap is a nice to have. Having the concept of first and last (getFirst()/getLast()/etc) on Collection is something long awaited. 

I understand that wanting to separate the concept of Collection and SequencedCollection can be conceptually nice, but 
multiplying the number of interfaces also multiplies the number of implementations. Pragmatically, this patch is too big compared to how useful it is.

I get that Oracle is rich, but this JEP is not only a burden for Oracle but for the whole community.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1483761783

From alanb at openjdk.org  Sat Mar 25 09:07:33 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 25 Mar 2023 09:07:33 GMT
Subject: RFR: 8304745: Lazily initialize byte[] in
 java.io.BufferedInputStream [v8]
In-Reply-To: <6WBr0oAq4e23dolVX_iixK6Q2OOwZtgLfcCQoqkdp5o=.f277f498-f00c-43c6-82d5-3bf884b7dd9d@github.com>
References: 
 
 <6WBr0oAq4e23dolVX_iixK6Q2OOwZtgLfcCQoqkdp5o=.f277f498-f00c-43c6-82d5-3bf884b7dd9d@github.com>
Message-ID: <7PtgaE4v-MJ0H0B2O4QxQBi82JE0sSWOtRFpuNb_5iE=.401f416f-b90a-42a3-ad50-a2dc5c77206e@github.com>

On Sat, 25 Mar 2023 05:55:46 GMT, Eirik Bjorsnos  wrote:

> I think the benchmark would benefit with a few words explaining why you focused on those methods/calling patterns. For someone walking past this benchmark, this is not obvious why you picked those.

I think the interesting case is where a BIS is created and either not used, or isn't used for a long time. We have this with System.in where it has 8k byte[] that isn't used until something reads from System.in.

The other case is is a read of 8k or more (or rather than BIS's internal buffer size) and no previous reads/buffered bytes. The subtle thing in the benchmark is that readAllBytes attempts to read 16k so it will bypass the internal buffer before it gets created. I agree that should be documented in the comments or the benchmark changed to read 16k or something large so it's more obvious what it does.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13150#issuecomment-1483770874

From duke at openjdk.org  Sat Mar 25 10:10:29 2023
From: duke at openjdk.org (Thiago Henrique =?UTF-8?B?SMO8cG5lcg==?=)
Date: Sat, 25 Mar 2023 10:10:29 GMT
Subject: RFR: 8304917: Remove unused function declarations in check_classname.h
Message-ID: 

Both functions "VerifyClassname" and "VerifyFixClassname" are not used. The functions that are used in the Class.c are "verifyClassname" and "verifyFixClassname", which are declared in the "check_classname.h" header

-------------

Commit messages:
 - Fix copyright
 - Remove unused function declarations

Changes: https://git.openjdk.org/jdk/pull/13077/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13077&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304917
  Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13077.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13077/head:pull/13077

PR: https://git.openjdk.org/jdk/pull/13077

From lancea at openjdk.org  Sat Mar 25 10:50:31 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Sat, 25 Mar 2023 10:50:31 GMT
Subject: RFR: 8304013: Add a fast,
 non-manual alternative to test/jdk/java/util/zip/ZipFile/TestTooManyEntries
 [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Sat, 25 Mar 2023 06:50:16 GMT, Eirik Bjorsnos  wrote:

>> test/jdk/java/util/zip/ZipFile/EndOfCenValidation.java line 139:
>> 
>>> 137:      * Validate that an end of central directory record with a CEN offset which
>>> 138:      * is larger than the EOC position minus the CEN size is rejected
>>> 139:      * @throws IOException
>> 
>> I don't think `@throws` javadoc comments in tests are useful; especially checked ones
>
> I recently added a `@throws` by review comment from Lance. I tend to agree that is not very useful, so I'm removing both ocurrences as per your recommendation.
> 
> If Lance wants it back, he can add a review comment saying so. I don't particularly care which professor gets the last word in this matter :-)

Please add them back before pushing with `@throws IOException if an error occurs`

Yes I understand they do not add much value but it will reduce noise from IDEs and if/when we add more checks for missing javadoc tags, it will save us from  having to revisit this

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12231#discussion_r1148348992

From duke at openjdk.org  Sat Mar 25 11:04:18 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Sat, 25 Mar 2023 11:04:18 GMT
Subject: RFR: 8304013: Add a fast,
 non-manual alternative to test/jdk/java/util/zip/ZipFile/TestTooManyEntries
 [v3]
In-Reply-To: 
References: 
Message-ID: 

> The TestTooManyEntries test was originally added to validate that ZIP64 files with CEN sizes exceeding what ZipFile  supports are rejected with a ZipException. The test does this by creating a large ZIP file (several gigabytes) with many enties. Because this is resource intensive, the test is currently tagged as manual.  (See #6927)
> 
> It would be useful to have a test which asserts the CEN size enforcement, but without the CPU, disk, memory and run time requirements of TestTooManyEntries.  Such a fast test can run non-manual,  without the @requires and manual tags as found in TestTooManyEntries.
> 
> This PR adds the EndOfCenValidation test which creates sparse test ZIPs where the CEN is "inflated" such that is matches the size declared in the "End of central directory" records.
> 
> While thee sparse files look large, they consume very little disk space on file systems supporting sparse files:
> 
> 
> 16 -rw-r--r--  1   2147483702 Feb  6 18:54 bad-cen-offset.zip
> 16 -rw-r--r--  1   2147483703 Feb  6 18:54 cen-size-too-large.zip
>  8 -rw-r--r--  1          132 Feb  6 18:54 invalid-zen-size.zip
> ``` 
> 
> For good measure, two new test methods are added to excercise the remaining ZipExceptions which ZipFile may throw during validation of the END record .

Eirik Bjorsnos has updated the pull request incrementally with two additional commits since the last revision:

 - Add consistent '@throws IOException if an error occurs' tags to all methods throwing IOException
 - Revert "Remove @throws as per review feedback"
   
   This reverts commit 623d37496cdfd7b1dd45fbaadda1df8b718be36d.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12231/files
  - new: https://git.openjdk.org/jdk/pull/12231/files/623d3749..1b253a14

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12231&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12231&range=01-02

  Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12231.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12231/head:pull/12231

PR: https://git.openjdk.org/jdk/pull/12231

From lancea at openjdk.org  Sat Mar 25 11:04:21 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Sat, 25 Mar 2023 11:04:21 GMT
Subject: RFR: 8304013: Add a fast,
 non-manual alternative to test/jdk/java/util/zip/ZipFile/TestTooManyEntries
 [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Sat, 25 Mar 2023 06:46:22 GMT, Eirik Bjorsnos  wrote:

>> test/jdk/java/util/zip/ZipFile/EndOfCenValidation.java line 120:
>> 
>>> 118:     /**
>>> 119:      * Validate that an end of central directory record with a
>>> 120:      * CEN size which exceeds the position of the EOC record is rejected.
>> 
>> EOC is not a standard zip file technical term.  Did you mean "END header" ?
>
> If by "standard" you mean "APPNOTE.TXT", then that uses "end of central directory record" which is a bit long.
> 
> The Java implementation seems to use END, like in `ZipFile.ENDHDR`, "END header", etc.
> 
> It is probably better to be consistent than correct here, so I've changed the test to use "END header" consistently when referring to the "end of central directory record".

So, what I would suggest is adding a comment somewhere regarding _end of central directory record_ and note the reference to _ENDHDR_ or _END Header_

I don't think you want to spend too much time here just the wording reference the _end of central directory record_ was clear and where you were abbreviating,  then I would reference ENDHDR

I would be looking at the APP.NOTE  when looking at this test then the ZipFile constant verbiage, but that is just me :-)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12231#discussion_r1148350853

From duke at openjdk.org  Sat Mar 25 11:10:32 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Sat, 25 Mar 2023 11:10:32 GMT
Subject: RFR: 8304013: Add a fast,
 non-manual alternative to test/jdk/java/util/zip/ZipFile/TestTooManyEntries
 [v3]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Sat, 25 Mar 2023 10:47:20 GMT, Lance Andersen  wrote:

>> I recently added a `@throws` by review comment from Lance. I tend to agree that is not very useful, so I'm removing both ocurrences as per your recommendation.
>> 
>> If Lance wants it back, he can add a review comment saying so. I don't particularly care which professor gets the last word in this matter :-)
>
> Please add them back before pushing with `@throws IOException if an error occurs`
> 
> Yes I understand they do not add much value but it will reduce noise from IDEs and if/when we add more checks for missing javadoc tags, it will save us from  having to revisit this

Thanks, I've added `@throws IOException if an error occurs` to all methods throwing `IOException`.

For the record, let me state my personal (rather strong) opinion:

I think this a pretty crazy level of boilerplate noise for a test and that it affects readability negatively. My IDE (IntelliJ) does not complain about this at all. Any IDE which complains should be fixed or configured to not complain. Changing Javadoc to complain about this in a scope like this  would be a poor decision.

I think the PR is ready to be sponsored after this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12231#discussion_r1148352043

From lancea at openjdk.org  Sat Mar 25 11:21:30 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Sat, 25 Mar 2023 11:21:30 GMT
Subject: RFR: 8304013: Add a fast,
 non-manual alternative to test/jdk/java/util/zip/ZipFile/TestTooManyEntries
 [v3]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Sat, 25 Mar 2023 11:07:24 GMT, Eirik Bjorsnos  wrote:

>> Please add them back before pushing with `@throws IOException if an error occurs`
>> 
>> Yes I understand they do not add much value but it will reduce noise from IDEs and if/when we add more checks for missing javadoc tags, it will save us from  having to revisit this
>
> Thanks, I've added `@throws IOException if an error occurs` to all methods throwing `IOException`.
> 
> For the record, let me state my personal (rather strong) opinion:
> 
> I think this a pretty crazy level of boilerplate noise for a test and that it affects readability negatively. My IDE (IntelliJ) does not complain about this at all. Any IDE which complains should be fixed or configured to not complain. Changing Javadoc to complain about this in a scope like this  would be a poor decision.
> 
> I think the PR is ready to be sponsored after this.

I hear you but the option is not to use javadoc comments and use block comments :-) 

I think we can agree to disagree on impacting readability ;-) this comes down to personal preferences

Again thank you for making the change.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12231#discussion_r1148353477

From lancea at openjdk.org  Sat Mar 25 11:58:30 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Sat, 25 Mar 2023 11:58:30 GMT
Subject: RFR: 8304013: Add a fast,
 non-manual alternative to test/jdk/java/util/zip/ZipFile/TestTooManyEntries
 [v3]
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: 

On Sat, 25 Mar 2023 11:18:32 GMT, Lance Andersen  wrote:

>> Thanks, I've added `@throws IOException if an error occurs` to all methods throwing `IOException`.
>> 
>> For the record, let me state my personal (rather strong) opinion:
>> 
>> I think this a pretty crazy level of boilerplate noise for a test and that it affects readability negatively. My IDE (IntelliJ) does not complain about this at all. Any IDE which complains should be fixed or configured to not complain. Changing Javadoc to complain about this in a scope like this  would be a poor decision.
>> 
>> I think the PR is ready to be sponsored after this.
>
> I hear you but the option is not to use javadoc comments and use block comments :-) 
> 
> I think we can agree to disagree on impacting readability ;-) this comes down to personal preferences
> 
> Again thank you for making the change.

> I think the PR is ready to be sponsored after this.

Please see my comment regarding the  end of central directory record.

I would prefer to tweak that in a fashion similar to what I indicated as I thought your original version was clearer.  I understand what Martin was indicating of the use of EOC and that could have been addressed by adding  _(EOC)_ or _ENDHDR_ after _end of central directory record_ to make it clearer

I will leave it up to you as to whether you want to make the change but it would be clearer as I think we took a small step backwards.

Either way you should not need a sponsor and should be good to integrated when you are ready

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12231#discussion_r1148353953

From duke at openjdk.org  Sat Mar 25 11:58:31 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Sat, 25 Mar 2023 11:58:31 GMT
Subject: RFR: 8304013: Add a fast,
 non-manual alternative to test/jdk/java/util/zip/ZipFile/TestTooManyEntries
 [v3]
In-Reply-To: 
References: 
 
 
 
 
 
 
Message-ID: 

On Sat, 25 Mar 2023 11:23:01 GMT, Lance Andersen  wrote:

>> I hear you but the option is not to use javadoc comments and use block comments :-) 
>> 
>> I think we can agree to disagree on impacting readability ;-) this comes down to personal preferences
>> 
>> Again thank you for making the change.
>
>> I think the PR is ready to be sponsored after this.
> 
> Please see my comment regarding the  end of central directory record.
> 
> I would prefer to tweak that in a fashion similar to what I indicated as I thought your original version was clearer.  I understand what Martin was indicating of the use of EOC and that could have been addressed by adding  _(EOC)_ or _ENDHDR_ after _end of central directory record_ to make it clearer
> 
> I will leave it up to you as to whether you want to make the change but it would be clearer as I think we took a small step backwards.
> 
> Either way you should not need a sponsor and should be good to integrated when you are ready

> I hear you but the option is not to use javadoc comments and use block comments :-)

I learned something new today: Javadoc comments and block comments are not the same!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12231#discussion_r1148357449

From duke at openjdk.org  Sat Mar 25 12:12:21 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Sat, 25 Mar 2023 12:12:21 GMT
Subject: RFR: 8304013: Add a fast,
 non-manual alternative to test/jdk/java/util/zip/ZipFile/TestTooManyEntries
 [v4]
In-Reply-To: 
References: 
Message-ID: 

> The TestTooManyEntries test was originally added to validate that ZIP64 files with CEN sizes exceeding what ZipFile  supports are rejected with a ZipException. The test does this by creating a large ZIP file (several gigabytes) with many enties. Because this is resource intensive, the test is currently tagged as manual.  (See #6927)
> 
> It would be useful to have a test which asserts the CEN size enforcement, but without the CPU, disk, memory and run time requirements of TestTooManyEntries.  Such a fast test can run non-manual,  without the @requires and manual tags as found in TestTooManyEntries.
> 
> This PR adds the EndOfCenValidation test which creates sparse test ZIPs where the CEN is "inflated" such that is matches the size declared in the "End of central directory" records.
> 
> While thee sparse files look large, they consume very little disk space on file systems supporting sparse files:
> 
> 
> 16 -rw-r--r--  1   2147483702 Feb  6 18:54 bad-cen-offset.zip
> 16 -rw-r--r--  1   2147483703 Feb  6 18:54 cen-size-too-large.zip
>  8 -rw-r--r--  1          132 Feb  6 18:54 invalid-zen-size.zip
> ``` 
> 
> For good measure, two new test methods are added to excercise the remaining ZipExceptions which ZipFile may throw during validation of the END record .

Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:

  Consistently refer to the ultimate ZIP header/record like this: 'End of central directory record' (END header)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12231/files
  - new: https://git.openjdk.org/jdk/pull/12231/files/1b253a14..a93248f0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12231&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12231&range=02-03

  Stats: 13 lines in 1 file changed: 2 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/12231.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12231/head:pull/12231

PR: https://git.openjdk.org/jdk/pull/12231

From duke at openjdk.org  Sat Mar 25 12:14:31 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Sat, 25 Mar 2023 12:14:31 GMT
Subject: RFR: 8304013: Add a fast,
 non-manual alternative to test/jdk/java/util/zip/ZipFile/TestTooManyEntries
 [v4]
In-Reply-To: 
References: 
 
 
 
 
 
 
 
Message-ID: 

On Sat, 25 Mar 2023 11:55:44 GMT, Eirik Bjorsnos  wrote:

>>> I think the PR is ready to be sponsored after this.
>> 
>> Please see my comment regarding the  end of central directory record.
>> 
>> I would prefer to tweak that in a fashion similar to what I indicated as I thought your original version was clearer.  I understand what Martin was indicating of the use of EOC and that could have been addressed by adding  _(EOC)_ or _ENDHDR_ after _end of central directory record_ to make it clearer
>> 
>> I will leave it up to you as to whether you want to make the change but it would be clearer as I think we took a small step backwards.
>> 
>> Either way you should not need a sponsor and should be good to integrated when you are ready
>
>> I hear you but the option is not to use javadoc comments and use block comments :-)
> 
> I learned something new today: Javadoc comments and block comments are not the same!

So I changed the references to this ultimate ZIP structure to read like this:

'End of central directory record' (END header)

Example:


/**
     * Validate that an 'End of central directory record' (END header)
     * where the value of the CEN size field exceeds the position of
     * the END header is rejected.


This way we stick to the 'official' ZIP verbiage but also allow using the shorter 'END header'.

What do you think?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12231#discussion_r1148359628

From duke at openjdk.org  Sat Mar 25 12:21:31 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Sat, 25 Mar 2023 12:21:31 GMT
Subject: RFR: 8304013: Add a fast,
 non-manual alternative to test/jdk/java/util/zip/ZipFile/TestTooManyEntries
 [v4]
In-Reply-To: 
References: 
 
 
 
 
 
 
 
 
Message-ID: <1CsJ7LxcpfWPNTfcm_YTAgnMBk3yWhctqpEHnLoV244=.5db05d0a-e94a-44ec-ab60-fc184a2c86da@github.com>

On Sat, 25 Mar 2023 12:11:18 GMT, Eirik Bjorsnos  wrote:

>>> I hear you but the option is not to use javadoc comments and use block comments :-)
>> 
>> I learned something new today: Javadoc comments and block comments are not the same!
>
> So I changed the references to this ultimate ZIP structure to read like this:
> 
> 'End of central directory record' (END header)
> 
> Example:
> 
> 
> /**
>      * Validate that an 'End of central directory record' (END header)
>      * where the value of the CEN size field exceeds the position of
>      * the END header is rejected.
> 
> 
> This way we stick to the 'official' ZIP verbiage but also allow using the shorter 'END header'.
> 
> What do you think?

> Either way you should not need a sponsor and should be good to integrated when you are ready

As a non-committer, I still think I need help from a committer to `/sponsor` this change, right?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12231#discussion_r1148360373

From lancea at openjdk.org  Sat Mar 25 15:11:34 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Sat, 25 Mar 2023 15:11:34 GMT
Subject: RFR: 8304013: Add a fast,
 non-manual alternative to test/jdk/java/util/zip/ZipFile/TestTooManyEntries
 [v4]
In-Reply-To: 
References: 
 
Message-ID: <6x3iqg6ziM_gtk9QOTvXS7em_gIXyvOSNbXk70reRDI=.4a1aa42e-40a2-421d-98b9-057ba45bab71@github.com>

On Sat, 25 Mar 2023 12:12:21 GMT, Eirik Bjorsnos  wrote:

>> The TestTooManyEntries test was originally added to validate that ZIP64 files with CEN sizes exceeding what ZipFile  supports are rejected with a ZipException. The test does this by creating a large ZIP file (several gigabytes) with many enties. Because this is resource intensive, the test is currently tagged as manual.  (See #6927)
>> 
>> It would be useful to have a test which asserts the CEN size enforcement, but without the CPU, disk, memory and run time requirements of TestTooManyEntries.  Such a fast test can run non-manual,  without the @requires and manual tags as found in TestTooManyEntries.
>> 
>> This PR adds the EndOfCenValidation test which creates sparse test ZIPs where the CEN is "inflated" such that is matches the size declared in the "End of central directory" records.
>> 
>> While thee sparse files look large, they consume very little disk space on file systems supporting sparse files:
>> 
>> 
>> 16 -rw-r--r--  1   2147483702 Feb  6 18:54 bad-cen-offset.zip
>> 16 -rw-r--r--  1   2147483703 Feb  6 18:54 cen-size-too-large.zip
>>  8 -rw-r--r--  1          132 Feb  6 18:54 invalid-zen-size.zip
>> ``` 
>> 
>> For good measure, two new test methods are added to excercise the remaining ZipExceptions which ZipFile may throw during validation of the END record .
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Consistently refer to the ultimate ZIP header/record like this: 'End of central directory record' (END header)

Thank you for the updates here Eirik. They look fine.

You are right, you do need a sponsor still and I will do so Monday morning so that Martin has a chance to provide any last input on your comment updates regarding the _End of central directory record_.

-------------

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/12231#pullrequestreview-1357853065

From duke at openjdk.org  Sat Mar 25 16:04:34 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Sat, 25 Mar 2023 16:04:34 GMT
Subject: RFR: 8304013: Add a fast,
 non-manual alternative to test/jdk/java/util/zip/ZipFile/TestTooManyEntries
 [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Sat, 25 Mar 2023 12:12:21 GMT, Eirik Bjorsnos  wrote:

>> The TestTooManyEntries test was originally added to validate that ZIP64 files with CEN sizes exceeding what ZipFile  supports are rejected with a ZipException. The test does this by creating a large ZIP file (several gigabytes) with many enties. Because this is resource intensive, the test is currently tagged as manual.  (See #6927)
>> 
>> It would be useful to have a test which asserts the CEN size enforcement, but without the CPU, disk, memory and run time requirements of TestTooManyEntries.  Such a fast test can run non-manual,  without the @requires and manual tags as found in TestTooManyEntries.
>> 
>> This PR adds the EndOfCenValidation test which creates sparse test ZIPs where the CEN is "inflated" such that is matches the size declared in the "End of central directory" records.
>> 
>> While thee sparse files look large, they consume very little disk space on file systems supporting sparse files:
>> 
>> 
>> 16 -rw-r--r--  1   2147483702 Feb  6 18:54 bad-cen-offset.zip
>> 16 -rw-r--r--  1   2147483703 Feb  6 18:54 cen-size-too-large.zip
>>  8 -rw-r--r--  1          132 Feb  6 18:54 invalid-zen-size.zip
>> ``` 
>> 
>> For good measure, two new test methods are added to excercise the remaining ZipExceptions which ZipFile may throw during validation of the END record .
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Consistently refer to the ultimate ZIP header/record like this: 'End of central directory record' (END header)

Thanks Lance! Allow me to underline just how much I appreciate that we can have differences of opinion while still being friends and making productive progress. Looking around the world, this is not always a given. I see this as a sign of a healty community.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12231#issuecomment-1483857855

From mik3hall at gmail.com  Sat Mar 25 16:33:19 2023
From: mik3hall at gmail.com (Michael Hall)
Date: Sat, 25 Mar 2023 11:33:19 -0500
Subject: jextract OS/X
Message-ID: <39D687B6-453A-46FF-A45E-3A12AF2F1F9C@gmail.com>

For the jdk-19 release this is included in the bin directory but not in the jdk-19.0.2. Is there a reason for this?

From mik3hall at gmail.com  Sat Mar 25 17:48:48 2023
From: mik3hall at gmail.com (Michael Hall)
Date: Sat, 25 Mar 2023 12:48:48 -0500
Subject: jextract OS/X
In-Reply-To: <39D687B6-453A-46FF-A45E-3A12AF2F1F9C@gmail.com>
References: <39D687B6-453A-46FF-A45E-3A12AF2F1F9C@gmail.com>
Message-ID: <0ED6ECE9-F5FA-43A3-8E09-D63463604B2D@gmail.com>



> On Mar 25, 2023, at 11:33 AM, Michael Hall  wrote:
> 
> For the jdk-19 release this is included in the bin directory but not in the jdk-19.0.2. Is there a reason for this?

I remembered I think my jdk-19 was a Panama specific. The jdk-19.0.2 was the current general release. Probably why.


From eirbjo at gmail.com  Sat Mar 25 18:05:02 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Sat, 25 Mar 2023 19:05:02 +0100
Subject: RFD: Should jextract be extracted from the JDK?
Message-ID: 

Hi,

I'll raise this periodic (?) question for discussion, but first I want to
make it clear I have no opinion myself.

Here is the question in question:

Should jextract be extracted from the JDK? If so, would it make sense to do
it now rather than later?

I'm asking this because I remember this being presented as an open question
early in the introduction of project Panama. As time has passed by, maybe
we have learned something which could influence this discussion?

There seems to be an increasing number of questions and concerns related to
jextract in OpenJDK, perhaps containing them in a separate release cycle
would do good?

Thanks,
Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From liach at openjdk.org  Sun Mar 26 01:00:37 2023
From: liach at openjdk.org (Chen Liang)
Date: Sun, 26 Mar 2023 01:00:37 GMT
Subject: RFR: 8304846: Provide a shared utility to dump generated classes
 defined via Lookup API [v2]
In-Reply-To: 
References: 
 
Message-ID: <80sjn-PEAHWtef1zC_ENj4o2mFTdIxJ9DxvU46sleQ4=.b826661a-af70-4d1c-8373-171f39e6b2e0@github.com>

On Fri, 24 Mar 2023 23:00:12 GMT, Mandy Chung  wrote:

>> This implements a shared utility to dump generated classes defined as normal/hidden classes via `Lookup` API.   This replaces the implementation in `LambdaMetaFactory` and method handle implementation that dumps the hidden class bytes on disk for debugging.   
>> 
>> For classes defined via `Lookup::defineClass`, `Lookup::defineHiddenClass` and `Lookup::defineHiddenClassWithClassData`, by default they will be dumped to the path specified in `-Djava.lang.invoke.Lookup.dumpClasses=` 
>> 
>> The hidden classes generated for lambdas, `LambdaForms` and method handle implementation use non-default dumper so that they can be controlled via a separate system property and path as in the current implementation.
>> 
>> To dump lambda proxy classes, set this system property:
>>    -Djdk.internal.lambda.dumpProxyClasses=
>> 
>> To dump LambdaForms and method handle implementation, set this system property:
>>    -Djava.lang.invoke.MethodHandle.DUMP_CLASS_FILES=true
>>    
>> P.S. `ProxyClassesDumper` is renamed to `ClassFileDumper` but for some reason, it's not shown as rename.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   avoid another map lookup

On a side note, can the class dumper be moved to jdk.internal so infrastructure like j.l.r.Proxy can use it too?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13182#issuecomment-1483961127

From liach at openjdk.org  Sun Mar 26 05:31:27 2023
From: liach at openjdk.org (Chen Liang)
Date: Sun, 26 Mar 2023 05:31:27 GMT
Subject: RFR: 8304932: MethodTypeDescImpl can be mutated by argument passed to
 MethodTypeDesc.of
Message-ID: 

Fixed the bug where if a caller keeps a reference to the array passed into `MethodTypeDesc.of`, the caller may mutate the Desc via the array and can create invalid MethodTypeDesc.

Unfortunately, since the input array now needs to be copied, the `of` factory suffers from a performance drop. But otherwise, this patch has minor performance gains on `ofDescriptor` factory, even compared to Adam's patch that optimized `ofDescriptor` in #12945.

This patch moves the parameters to an immutable list, to avoid allocations on `parameterList` as well.

Benchmark of Oracle JDK 20: https://gist.github.com/683c6219e183cbc2b336224fc2c0d50a
Benchmark of this patch: https://gist.github.com/22be9371a2370fb4a7b44f1684750ec4
Benchmark of [asotona's patch](https://github.com/openjdk/jdk/pull/12945/files#diff-ac8e413d3e13532a2b0d34a90253c6ddd7a4f04082f792b9d076e9b5a33f2078): https://gist.github.com/eb98579c3b51cafae481049a95a78f80

[sotona vs this](https://jmh.morethan.io/?gists=eb98579c3b51cafae481049a95a78f80,22be9371a2370fb4a7b44f1684750ec4); [20 vs this](https://jmh.morethan.io/?gists=683c6219e183cbc2b336224fc2c0d50a,22be9371a2370fb4a7b44f1684750ec4); [20 vs sotona](https://jmh.morethan.io/?gists=683c6219e183cbc2b336224fc2c0d50a,eb98579c3b51cafae481049a95a78f80), for reference

-------------

Commit messages:
 - Add benchmark
 - 8304932: MethodTypeDescImpl can be mutated by argument passed to MethodTypeDesc.of

Changes: https://git.openjdk.org/jdk/pull/13186/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13186&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304932
  Stats: 314 lines in 5 files changed: 155 ins; 87 del; 72 mod
  Patch: https://git.openjdk.org/jdk/pull/13186.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13186/head:pull/13186

PR: https://git.openjdk.org/jdk/pull/13186

From liach at openjdk.org  Sun Mar 26 05:41:28 2023
From: liach at openjdk.org (Chen Liang)
Date: Sun, 26 Mar 2023 05:41:28 GMT
Subject: RFR: 8304932: MethodTypeDescImpl can be mutated by argument passed
 to MethodTypeDesc.of
In-Reply-To: 
References: 
Message-ID: 

On Sun, 26 Mar 2023 05:23:54 GMT, Chen Liang  wrote:

> Fixed the bug where if a caller keeps a reference to the array passed into `MethodTypeDesc.of`, the caller may mutate the Desc via the array and can create invalid MethodTypeDesc.
> 
> Unfortunately, since the input array now needs to be copied, the `of` factory suffers from a performance drop. But otherwise, this patch has minor performance gains on `ofDescriptor` factory, even compared to Adam's patch that optimized `ofDescriptor` in #12945.
> 
> This patch moves the parameters to an immutable list, to avoid allocations on `parameterList` as well.
> 
> Benchmark of Oracle JDK 20: https://gist.github.com/683c6219e183cbc2b336224fc2c0d50a
> Benchmark of this patch: https://gist.github.com/22be9371a2370fb4a7b44f1684750ec4
> Benchmark of [asotona's patch](https://github.com/openjdk/jdk/pull/12945/files#diff-ac8e413d3e13532a2b0d34a90253c6ddd7a4f04082f792b9d076e9b5a33f2078): https://gist.github.com/eb98579c3b51cafae481049a95a78f80
> 
> [sotona vs this](https://jmh.morethan.io/?gists=eb98579c3b51cafae481049a95a78f80,22be9371a2370fb4a7b44f1684750ec4); [20 vs this](https://jmh.morethan.io/?gists=683c6219e183cbc2b336224fc2c0d50a,22be9371a2370fb4a7b44f1684750ec4); [20 vs sotona](https://jmh.morethan.io/?gists=683c6219e183cbc2b336224fc2c0d50a,eb98579c3b51cafae481049a95a78f80), for reference

Additional comments:
1. Maybe it's feasible to add another factory:

static MethodTypeDesc of(ClassDesc returnType, List parameterTypes) {
    return new MethodTypeDescImpl(returnType, List.copyOf(parameterTypes));
}

which would avoid another copy if `parameterTypes` is already a list from `List.of` factories.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13186#issuecomment-1484001253

From liach at openjdk.org  Sun Mar 26 07:03:32 2023
From: liach at openjdk.org (Chen Liang)
Date: Sun, 26 Mar 2023 07:03:32 GMT
Subject: RFR: 8304932: MethodTypeDescImpl can be mutated by argument passed
 to MethodTypeDesc.of
In-Reply-To: 
References: 
Message-ID: <17Gg94Zbzda-oAKe78bj1Z-95xcSSTnQ7_sjPmgwFOk=.c0a18232-af17-4319-a124-16352b5491a2@github.com>

On Sun, 26 Mar 2023 05:23:54 GMT, Chen Liang  wrote:

> Fixed the bug where if a caller keeps a reference to the array passed into `MethodTypeDesc.of`, the caller may mutate the Desc via the array and can create invalid MethodTypeDesc.
> 
> Unfortunately, since the input array now needs to be copied, the `of` factory suffers from a performance drop. But otherwise, this patch has minor performance gains on `ofDescriptor` factory, even compared to Adam's patch that optimized `ofDescriptor` in #12945.
> 
> This patch moves the parameters to an immutable list, to avoid allocations on `parameterList` as well.
> 
> Benchmark of Oracle JDK 20: https://gist.github.com/683c6219e183cbc2b336224fc2c0d50a
> Benchmark of this patch: https://gist.github.com/22be9371a2370fb4a7b44f1684750ec4
> Benchmark of [asotona's patch](https://github.com/openjdk/jdk/pull/12945/files#diff-ac8e413d3e13532a2b0d34a90253c6ddd7a4f04082f792b9d076e9b5a33f2078): https://gist.github.com/eb98579c3b51cafae481049a95a78f80
> 
> [sotona vs this](https://jmh.morethan.io/?gists=eb98579c3b51cafae481049a95a78f80,22be9371a2370fb4a7b44f1684750ec4); [20 vs this](https://jmh.morethan.io/?gists=683c6219e183cbc2b336224fc2c0d50a,22be9371a2370fb4a7b44f1684750ec4); [20 vs sotona](https://jmh.morethan.io/?gists=683c6219e183cbc2b336224fc2c0d50a,eb98579c3b51cafae481049a95a78f80), for reference

src/java.base/share/classes/java/lang/constant/MethodTypeDescImpl.java line 141:

> 139:     @Override
> 140:     public MethodTypeDesc changeReturnType(ClassDesc returnType) {
> 141:         return new MethodTypeDescImpl(returnType, argTypes);

missing null check, will add later

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13186#discussion_r1148491806

From jens at lidestrom.se  Sun Mar 26 09:38:07 2023
From: jens at lidestrom.se (=?UTF-8?Q?Jens_Lidestr=c3=b6m?=)
Date: Sun, 26 Mar 2023 11:38:07 +0200
Subject: The non-deterministic iteration order of Immutable Collections
In-Reply-To: <39ceb9e6-3681-13f4-4fa3-b9e298203a70@oracle.com>
References: <1cf6bcc4-b7f9-fc72-8b3e-d3a3c785f54e@gmail.com>
 <39ceb9e6-3681-13f4-4fa3-b9e298203a70@oracle.com>
Message-ID: <8ed0b1ba-edec-1b25-3f99-bbacef92db2b@lidestrom.se>

I think Map#of and friends would be more useful and less error prone if they where to return collections that have a fixed iteration order, where the order is defined by the insertion order when the map is created.

### My experience with jdeps

I encountered this as a problem when I tried to generate a module dependency graph using jdeps. I had my classpath wrong and got an error message. The error message contained a list of modules or jar-files (I don't remember the details, unfortunately).

The relevant part of this story for collection iteration order is this: Each time I re-run the jdeps command I got a different list of modules in the error message.

It took me a long time and a lot of confusion before I realised that it was actually not a different list of modules, but instead the same list, in different order.

I never came around to verify it, but a likely explanation for this confusing behaviour is that jdeps used Map#ofEntries internally, and printed the entries in the error message, which gave a new random order for each program execution.

Map#of probably works fine for the main functionality of jdeps, which probably is to use the map for lookups, but for error message printouts the result was confusing.


### Map encounter order in general

I think a large part of all maps that are used in Java applications end up being iterated over in some situations: Either they are displayed in a GUI, or serialised and sent over a network connection, or, as in my example, being displayed in an error message.

In neither of these cases is it a strait-out bug to use a random iteration order, but in all of them it is likely bad and confusing to do so.

Because of this I think that general purpose maps should by default preserve the insertion order of the entries.

Not preserving insertion order should be considered to be a niche use case, used only to optimize memory footprint when the users opt in to it because they decide that it is acceptable.


### Other collection frameworks

The Guava immutable map factories create implementations that preserve the iteration order:

https://github.com/google/guava/wiki/ImmutableCollectionsExplained#how

https://guava.dev/releases/23.0/api/docs/com/google/common/collect/ImmutableMap.Builder.html

Because of the iteration order issue of Map#of I have continued to used these.


### Memory cost to store insertion order

The Guava RegularImmutableMap uses a separate array of references to map entries to define the iteration order. This implementation gives an extra memory overhead per entry of one reference.

The size of a map using the standard library immutable map implementation, MapN, is approximately the following. (MapN uses a memory efficient implementation which avoids the need to allocate entry objects.)

Size per entry, measured in the number of references that are used:

1 - Reference to key
1 - Reference to value
1 - Hash table extra space at 66 % load

1 - Key object header
1 - Approximate size contents of a small key object
1 - Value object header
1 - Approximate size contents of a small value object

Total: 7

The addition of one extra reference for tracking the insertion order gives a memory increase of 1/7 = 14 % in this scenario. To me this sounds like a good trade-off for a map with better behaviour.


Best regards,
Jens Lidestr?m
Java and Mumps programming enthusiast

On 2023-03-25 01:16, Stuart Marks wrote:
> 
> 
> On 3/24/23 10:18 AM, Chris Hegarty wrote:
>> I know that this has come up a number of times before, but I cannot seem to find anything directly relevant to my use-case, or recent.
>>
>> The iteration order of immutable Sets and Maps (created by the `of` factories) is clearly unspecified - good. Code should not depend upon this iteration order, and if so that code is broken. I completely agree and am aligned with this principle.
>>
>> The Elasticsearch code base heavily uses these collection implementations, and their iterators. On occasion we run into issues, where our code (because of a bug or a race), inadvertently has a dependency on the iteration order. To be clear, this is a bug in our code, and we want to reproduce and fix it.? The problem we are encountering is that the iteration order is not determinable or reproducible, which makes it extremely challenging to reproduce the bug even when we have reproducible testcase to hand. ( whereas, for example, it is common practice in other parts of the code to log a seed used for randomization )
>>
>> We very much like using the immutable collections, and we definitely don't want to pay the price of sorting things in the code, since we don't want to, and should not, depend upon the iteration order. The only concern is with reproducibility when we run into (our own) bugs.
>>
>> I don't (yet) want to be prescriptive in any potential solution. And I know that this has been discussed before. I mostly just want to start a conversation and see how much traction it gets.
> 
> Hi Chris,
> 
> Yes, this has come up before, but it's been mostly theoretical. That is, people worry about this when they hear of the idea of randomized iteration order, but I've never heard any followup. This is in fact the first time I've heard of an actual case where this is a real problem. So thanks for bringing it up.
> 
> (And unfortunately, it's notoriously difficult to make code truly iteration-order dependent. We've had our own history of problems with this in the JDK. I'd be interested in hearing from you at some point about the exact pathology of how this occurred.)
> 
> There's currently no debugging or experimental interface that will let one print or set the random seed that's in use. The obvious approach of using an agent to hack away at runtime doesn't work, because the unmodifiable collections implementations are used very early in startup and they're usually loaded before the agent runs. There are limitations on what an agent can do when redefining an already-loaded class, for example, removing the 'final' modifier from fields isn't supported. (Well I suppose one can always use Unsafe.)
> 
> Here's another approach that might work for you.
> 
> 1. Write a little program that extracts the class bytes of ImmutableCollection.class from the runtime image, and use something like ASM or ClassFile to make the class public and to make the REVERSE and SALT32L fields public and non-final.
> 
> 2. Launch a VM using the --patch-module option to use this class instead of the built-in one.
> 
> 3. Write an agent, or some debugging library that's called at the right time, to use simple reflective access to get or set those fields as desired.
> 
> This is a bit fiddly but it might be easier than rebuilding and deploying a custom JDK.
> 
> Setting (formerly) final fields after the VM is initialized is often somewhat risky. In this case these particular fields are used only during iteration, and they don't actually change the layout of any data structures. So setting them to some desired value should apply to all subsequent iterations, even of existing data structures.
> 
> I'll think about better ways to do this in the product. The best approach isn't obvious. The typical way of doing things like this using system properties is tricky, as it depends on order of class initialization at startup (and you know how fragile that is).
> 
> s'marks

From kasperni at gmail.com  Sun Mar 26 10:48:54 2023
From: kasperni at gmail.com (Kasper Nielsen)
Date: Sun, 26 Mar 2023 11:48:54 +0100
Subject: The non-deterministic iteration order of Immutable Collections
In-Reply-To: <8ed0b1ba-edec-1b25-3f99-bbacef92db2b@lidestrom.se>
References: <1cf6bcc4-b7f9-fc72-8b3e-d3a3c785f54e@gmail.com>
 <39ceb9e6-3681-13f4-4fa3-b9e298203a70@oracle.com>
 <8ed0b1ba-edec-1b25-3f99-bbacef92db2b@lidestrom.se>
Message-ID: 

On Sun, 26 Mar 2023 at 10:38, Jens Lidestr?m  wrote:
>
> I think Map#of and friends would be more useful and less error prone if they where to return collections that have a fixed iteration order, where the order is defined by the insertion order when the map is created.

The problem is that everyone will have to pay for the extra storage cost for
maintaining insertion order. Even if people don't need it. Hence, why I
suggested adding factory/copyOf methods for SequencedMap/SequencedSet
for those people that need to rely on order. (Rereading Chris's email I know it
wouldn't help his use-case).

/Kasper

From forax at univ-mlv.fr  Sun Mar 26 11:41:01 2023
From: forax at univ-mlv.fr (Remi Forax)
Date: Sun, 26 Mar 2023 13:41:01 +0200 (CEST)
Subject: The non-deterministic iteration order of Immutable Collections
In-Reply-To: <8ed0b1ba-edec-1b25-3f99-bbacef92db2b@lidestrom.se>
References: <1cf6bcc4-b7f9-fc72-8b3e-d3a3c785f54e@gmail.com>
 <39ceb9e6-3681-13f4-4fa3-b9e298203a70@oracle.com>
 <8ed0b1ba-edec-1b25-3f99-bbacef92db2b@lidestrom.se>
Message-ID: <1739984468.20458716.1679830861882.JavaMail.zimbra@univ-eiffel.fr>

----- Original Message -----
> From: "Jens Lidestr?m" 
> To: "core-libs-dev" 
> Sent: Sunday, March 26, 2023 11:38:07 AM
> Subject: Re: The non-deterministic iteration order of Immutable Collections

> I think Map#of and friends would be more useful and less error prone if they
> where to return collections that have a fixed iteration order, where the order
> is defined by the insertion order when the map is created.

I agree.

They are several use cases for Set.of()/Map.of(), for testing you want them to not have an order but for a defensive copy (Set.copyOf()/Map.copyOf()) you want them to keep the order. Currently, the implementation rotates toward the former instead of the later.

A lot of my students struggle with the semantics of Set.of()/Map.of() because this choice makes the unmodifiable set/map not beginners friendly.
To the point where a student will prefer to use a List instead of a Set, because List.copyOf() seems to work "correctly" compared to Set.copyOf().

Python 3.7 has changed the implementation of its set and dictionaries to keep the insertion order for this exact reason.

Java could do the same.

regards,
R?mi

From maurizio.cimadamore at oracle.com  Sun Mar 26 12:41:14 2023
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Sun, 26 Mar 2023 13:41:14 +0100
Subject: RFD: Should jextract be extracted from the JDK?
In-Reply-To: 
References: 
Message-ID: <6f5b93b0-3e7e-c983-dd99-fe7bc9a6cf94@oracle.com>

Hi,
not sure I understand your question correctly.

But if you are referring to the fact that jextract should *not* be part 
of the JDK, please note that the FFM API does _not_ include jextract. 
The jextract tool is instead made available in a standalone repository:

https://github.com/openjdk/jextract

For which binary snapshots are also provided here:

https://jdk.java.net/jextract/

(this change happened roughly an year ago [1]).

Cheers
Maurizio

[1] - https://mail.openjdk.org/pipermail/panama-dev/2022-March/016632.html


On 25/03/2023 18:05, Eirik Bj?rsn?s wrote:
> Hi,
>
> I'll raise this periodic (?) question for discussion, but first I want 
> to make it clear I have no opinion myself.
>
> Here is the question in question:
>
> Should?jextract be extracted from the JDK? If?so, would it make sense 
> to do it now rather than later?
>
> I'm asking this because?I remember this being presented as an open 
> question early in the introduction of project Panama. As time has 
> passed by, maybe we have learned something which could influence this 
> discussion?
>
> There seems to be an increasing number of questions and concerns 
> related to jextract in OpenJDK, perhaps containing them in a separate 
> release cycle would do good?
>
> Thanks,
> Eirik.

From eirbjo at gmail.com  Sun Mar 26 12:48:37 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Sun, 26 Mar 2023 14:48:37 +0200
Subject: RFD: Should jextract be extracted from the JDK?
In-Reply-To: <6f5b93b0-3e7e-c983-dd99-fe7bc9a6cf94@oracle.com>
References: 
 <6f5b93b0-3e7e-c983-dd99-fe7bc9a6cf94@oracle.com>
Message-ID: 

Sorry Maurizio,

It's not your understanding that is lacking, it is mine. I did not get the
news.

Mea culpa for not understanding the current situation properly.

Thanks,
Eirik

On Sun, Mar 26, 2023 at 2:41?PM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> Hi,
> not sure I understand your question correctly.
>
> But if you are referring to the fact that jextract should *not* be part
> of the JDK, please note that the FFM API does _not_ include jextract.
> The jextract tool is instead made available in a standalone repository:
>
> https://github.com/openjdk/jextract
>
> For which binary snapshots are also provided here:
>
> https://jdk.java.net/jextract/
>
> (this change happened roughly an year ago [1]).
>
> Cheers
> Maurizio
>
> [1] - https://mail.openjdk.org/pipermail/panama-dev/2022-March/016632.html
>
>
> On 25/03/2023 18:05, Eirik Bj?rsn?s wrote:
> > Hi,
> >
> > I'll raise this periodic (?) question for discussion, but first I want
> > to make it clear I have no opinion myself.
> >
> > Here is the question in question:
> >
> > Should jextract be extracted from the JDK? If so, would it make sense
> > to do it now rather than later?
> >
> > I'm asking this because I remember this being presented as an open
> > question early in the introduction of project Panama. As time has
> > passed by, maybe we have learned something which could influence this
> > discussion?
> >
> > There seems to be an increasing number of questions and concerns
> > related to jextract in OpenJDK, perhaps containing them in a separate
> > release cycle would do good?
> >
> > Thanks,
> > Eirik.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jens at lidestrom.se  Sun Mar 26 12:58:37 2023
From: jens at lidestrom.se (=?UTF-8?Q?Jens_Lidestr=c3=b6m?=)
Date: Sun, 26 Mar 2023 14:58:37 +0200
Subject: The non-deterministic iteration order of Immutable Collections
In-Reply-To: 
References: <1cf6bcc4-b7f9-fc72-8b3e-d3a3c785f54e@gmail.com>
 <39ceb9e6-3681-13f4-4fa3-b9e298203a70@oracle.com>
 <8ed0b1ba-edec-1b25-3f99-bbacef92db2b@lidestrom.se>
 
Message-ID: 

 > The problem is that everyone will have to pay for the extra storage cost for maintaining insertion order. Even if people don't need it.

I understand that.

The main point of my message is that I think it is worth the cost, that a fixed iteration order should be the default, and that it should be considered to be a niche use case to prioritize the memory savings of a random iteration order. This use case should be catered to by third-party libraries or alternative API:s.

These are a summary of the arguments (which I failed to provide in my original message):

* Many, probably most, uses of maps in Java benefit from a fixed iteration order.
* It is easy to get bugs or confusing behaviour by mistake when random iteration order is the default.
* The memory cost of an insertion-based iteration order is not very high.
* The Guava developers, and, as Remi notes, the Python developers, have also drawn this conclusion. (Argument from authority.)

Best regard,
Jens Lidestr?m

On 2023-03-26 12:48, Kasper Nielsen wrote:
> On Sun, 26 Mar 2023 at 10:38, Jens Lidestr?m  wrote:
>> I think Map#of and friends would be more useful and less error prone if they where to return collections that have a fixed iteration order, where the order is defined by the insertion order when the map is created.
> The problem is that everyone will have to pay for the extra storage cost for
> maintaining insertion order. Even if people don't need it. Hence, why I
> suggested adding factory/copyOf methods for SequencedMap/SequencedSet
> for those people that need to rely on order. (Rereading Chris's email I know it
> wouldn't help his use-case).
>
> /Kasper


From Alan.Bateman at oracle.com  Sun Mar 26 13:19:42 2023
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 26 Mar 2023 14:19:42 +0100
Subject: The non-deterministic iteration order of Immutable Collections
In-Reply-To: <8ed0b1ba-edec-1b25-3f99-bbacef92db2b@lidestrom.se>
References: <1cf6bcc4-b7f9-fc72-8b3e-d3a3c785f54e@gmail.com>
 <39ceb9e6-3681-13f4-4fa3-b9e298203a70@oracle.com>
 <8ed0b1ba-edec-1b25-3f99-bbacef92db2b@lidestrom.se>
Message-ID: <5ba2784d-d11c-6131-d009-a1a47fffabeb@oracle.com>

On 26/03/2023 10:38, Jens Lidestr?m wrote:
> :
>
> I encountered this as a problem when I tried to generate a module 
> dependency graph using jdeps. I had my classpath wrong and got an 
> error message. The error message contained a list of modules or 
> jar-files (I don't remember the details, unfortunately).

If you do remember, then please report a bug as this sounds like an 
issue with jdeps rather than an issue with the design choice that the 
iteration order of unmodifable maps be unspecified.

-Alan.

From ecki at zusammenkunft.net  Sun Mar 26 13:54:27 2023
From: ecki at zusammenkunft.net (Bernd)
Date: Sun, 26 Mar 2023 15:54:27 +0200
Subject: The non-deterministic iteration order of Immutable Collections
In-Reply-To: <1739984468.20458716.1679830861882.JavaMail.zimbra@univ-eiffel.fr>
References: <1cf6bcc4-b7f9-fc72-8b3e-d3a3c785f54e@gmail.com>
 <39ceb9e6-3681-13f4-4fa3-b9e298203a70@oracle.com>
 <8ed0b1ba-edec-1b25-3f99-bbacef92db2b@lidestrom.se>,
 <1739984468.20458716.1679830861882.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <93E15227-9D19-214C-B259-9FF3FD1A2C0E@hxcore.ol>

An HTML attachment was scrubbed...
URL: 

From martin at openjdk.org  Sun Mar 26 16:54:40 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Sun, 26 Mar 2023 16:54:40 GMT
Subject: RFR: 8304013: Add a fast,
 non-manual alternative to test/jdk/java/util/zip/ZipFile/TestTooManyEntries
 [v4]
In-Reply-To: 
References: 
 
 
 
Message-ID: <20IXMHNWuWG3YT5S0b13mYwXlEHlaKT4fv5uElcHScw=.c6c51b8f-d921-4e45-bdfc-b6d70d4146a3@github.com>

On Sat, 25 Mar 2023 10:59:36 GMT, Lance Andersen  wrote:

>> If by "standard" you mean "APPNOTE.TXT", then that uses "end of central directory record" which is a bit long.
>> 
>> The Java implementation seems to use END, like in `ZipFile.ENDHDR`, "END header", etc.
>> 
>> It is probably better to be consistent than correct here, so I've changed the test to use "END header" consistently when referring to the "end of central directory record".
>
> So, what I would suggest is adding a comment somewhere regarding _end of central directory record_ and note the reference to _ENDHDR_ or _END Header_
> 
> I don't think you want to spend too much time here just the wording reference the _end of central directory record_ was clear and where you were abbreviating,  then I would reference ENDHDR
> 
> I would be looking at the APP.NOTE  when looking at this test, not the ZipFile constant verbiage, but that is just me :-)

Neither APPNOTE nor JDK doc zip  terminology is great, but a test is not the place to invent something better.

(But I'm surprised no one seems to be using "EOCD")

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12231#discussion_r1148594475

From duke at openjdk.org  Sun Mar 26 17:01:41 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Sun, 26 Mar 2023 17:01:41 GMT
Subject: RFR: 8304013: Add a fast,
 non-manual alternative to test/jdk/java/util/zip/ZipFile/TestTooManyEntries
 [v4]
In-Reply-To: <20IXMHNWuWG3YT5S0b13mYwXlEHlaKT4fv5uElcHScw=.c6c51b8f-d921-4e45-bdfc-b6d70d4146a3@github.com>
References: 
 
 
 
 <20IXMHNWuWG3YT5S0b13mYwXlEHlaKT4fv5uElcHScw=.c6c51b8f-d921-4e45-bdfc-b6d70d4146a3@github.com>
Message-ID: 

On Sun, 26 Mar 2023 16:51:28 GMT, Martin Buchholz  wrote:

>> So, what I would suggest is adding a comment somewhere regarding _end of central directory record_ and note the reference to _ENDHDR_ or _END Header_
>> 
>> I don't think you want to spend too much time here just the wording reference the _end of central directory record_ was clear and where you were abbreviating,  then I would reference ENDHDR
>> 
>> I would be looking at the APP.NOTE  when looking at this test, not the ZipFile constant verbiage, but that is just me :-)
>
> Neither APPNOTE nor JDK doc zip  terminology is great, but a test is not the place to invent something better.
> 
> (But I'm surprised no one seems to be using "EOCD")

I think that would be ?EOCDR?. (Hides behind the bike shed..)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12231#discussion_r1148595939

From brian.goetz at oracle.com  Sun Mar 26 17:06:39 2023
From: brian.goetz at oracle.com (Brian Goetz)
Date: Sun, 26 Mar 2023 13:06:39 -0400
Subject: RFR: 8304846: Provide a shared utility to dump generated classes
 defined via Lookup API
In-Reply-To: 
References: 
Message-ID: <1535b07c-d226-6e55-e837-a690edfaeb26@oracle.com>

Since LMF goes through Lookup::defineHiddenClass, does this mean that 
they will be potentially dumped twice, once through Lookup, and once 
through LMF?

Now that there is a shared implementation, perhaps we should migrate use 
in LMF to something more like

    -Djava.lang.invoke.MethodHandle.DUMP_LAMBDA_PROXY_CLASS_FILES=true

and retire the separate dumpProxyClasses flag.

On 3/24/2023 4:49 PM, Mandy Chung wrote:
> For classes defined via `Lookup::defineClass`, `Lookup::defineHiddenClass` and `Lookup::defineHiddenClassWithClassData`, by default they will be dumped to the path specified in `-Djava.lang.invoke.Lookup.dumpClasses=`
>
> The hidden classes generated for lambdas, `LambdaForms` and method handle implementation use non-default dumper so that they can be controlled via a separate system property and path as in the current implementation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From martin at openjdk.org  Sun Mar 26 17:09:41 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Sun, 26 Mar 2023 17:09:41 GMT
Subject: RFR: 8304013: Add a fast,
 non-manual alternative to test/jdk/java/util/zip/ZipFile/TestTooManyEntries
 [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Sat, 25 Mar 2023 12:12:21 GMT, Eirik Bjorsnos  wrote:

>> The TestTooManyEntries test was originally added to validate that ZIP64 files with CEN sizes exceeding what ZipFile  supports are rejected with a ZipException. The test does this by creating a large ZIP file (several gigabytes) with many enties. Because this is resource intensive, the test is currently tagged as manual.  (See #6927)
>> 
>> It would be useful to have a test which asserts the CEN size enforcement, but without the CPU, disk, memory and run time requirements of TestTooManyEntries.  Such a fast test can run non-manual,  without the @requires and manual tags as found in TestTooManyEntries.
>> 
>> This PR adds the EndOfCenValidation test which creates sparse test ZIPs where the CEN is "inflated" such that is matches the size declared in the "End of central directory" records.
>> 
>> While thee sparse files look large, they consume very little disk space on file systems supporting sparse files:
>> 
>> 
>> 16 -rw-r--r--  1   2147483702 Feb  6 18:54 bad-cen-offset.zip
>> 16 -rw-r--r--  1   2147483703 Feb  6 18:54 cen-size-too-large.zip
>>  8 -rw-r--r--  1          132 Feb  6 18:54 invalid-zen-size.zip
>> ``` 
>> 
>> For good measure, two new test methods are added to excercise the remaining ZipExceptions which ZipFile may throw during validation of the END record .
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Consistently refer to the ultimate ZIP header/record like this: 'End of central directory record' (END header)

Marked as reviewed by martin (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/12231#pullrequestreview-1358064525

From martin at openjdk.org  Sun Mar 26 17:09:42 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Sun, 26 Mar 2023 17:09:42 GMT
Subject: RFR: 8304013: Add a fast,
 non-manual alternative to test/jdk/java/util/zip/ZipFile/TestTooManyEntries
 [v4]
In-Reply-To: <1CsJ7LxcpfWPNTfcm_YTAgnMBk3yWhctqpEHnLoV244=.5db05d0a-e94a-44ec-ab60-fc184a2c86da@github.com>
References: 
 
 
 
 
 
 
 
 
 <1CsJ7LxcpfWPNTfcm_YTAgnMBk3yWhctqpEHnLoV244=.5db05d0a-e94a-44ec-ab60-fc184a2c86da@github.com>
Message-ID: 

On Sat, 25 Mar 2023 12:18:46 GMT, Eirik Bjorsnos  wrote:

>> So I changed the references to this ultimate ZIP structure to read like this:
>> 
>> 'End of central directory record' (END header)
>> 
>> Example:
>> 
>> 
>> /**
>>      * Validate that an 'End of central directory record' (END header)
>>      * where the value of the CEN size field exceeds the position of
>>      * the END header is rejected.
>> 
>> 
>> This way we stick to the 'official' ZIP verbiage but also allow using the shorter 'END header'.
>> 
>> What do you think?
>
>> Either way you should not need a sponsor and should be good to integrated when you are ready
> 
> As a non-committer, I still think I need help from a committer to `/sponsor` this change, right?

> I think this a pretty crazy level of boilerplate noise for a test and that it affects readability negatively. 

I'm with Eirik here.

I've maintained jdk tests for 20 years and have never had to worry about nagging to add javadoc boilerplate.

doclint should restrict itself to checking what's there, not to check for completeness, in tests and private APIs.

And it looks like the jdk makefiles are in fact set up to work this way.  

I see:
./make/Docs.gmk:102:JAVADOC_DISABLED_DOCLINT_WARNINGS := missing

Especially for test methods, the contract of a test is very simple: "do nothing", but possibly throw an informative exception.  If the compiler requires a throws declaration, then I like `throws Throwable`  which evokes this contract.  A javadoc `@throws` declaration is the sort of useless boilerplate that makes people hate Java.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12231#discussion_r1148596927

From liach at openjdk.org  Sun Mar 26 20:44:32 2023
From: liach at openjdk.org (Chen Liang)
Date: Sun, 26 Mar 2023 20:44:32 GMT
Subject: RFR: 8304937: BufferedFieldBuilder.Model missing
 writeTo(DirectClassBuilder)
Message-ID: 

Please review this simple patch to Classfile API that fixes a missing override that otherwise affects usage of chained class transforms. A test is included, that it fails on the missing method without this patch.

Please review a few other patches fixing bugs affecting normal usage of the Classfile API as well:
#13167 #13021 #12996

I am trying to write a test for my in-progress patch to unify parameter mapping in core reflection in anticipation of #9862, however this bug prevents me from dropping method Signature and MethodParameters attributes with chained class transforms.

-------------

Commit messages:
 - 8304937: BufferedFieldBuilder.Model missing writeTo(DirectClassBuilder)

Changes: https://git.openjdk.org/jdk/pull/13187/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13187&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304937
  Stats: 86 lines in 2 files changed: 85 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13187.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13187/head:pull/13187

PR: https://git.openjdk.org/jdk/pull/13187

From liach at openjdk.org  Sun Mar 26 20:45:19 2023
From: liach at openjdk.org (Chen Liang)
Date: Sun, 26 Mar 2023 20:45:19 GMT
Subject: RFR: 8304932: MethodTypeDescImpl can be mutated by argument passed
 to MethodTypeDesc.of [v2]
In-Reply-To: 
References: 
Message-ID: 

> Fixed the bug where if a caller keeps a reference to the array passed into `MethodTypeDesc.of`, the caller may mutate the Desc via the array and can create invalid MethodTypeDesc.
> 
> Unfortunately, since the input array now needs to be copied, the `of` factory suffers from a performance drop. But otherwise, this patch has minor performance gains on `ofDescriptor` factory, even compared to Adam's patch that optimized `ofDescriptor` in #12945.
> 
> This patch moves the parameters to an immutable list, to avoid allocations on `parameterList` as well.
> 
> Benchmark of Oracle JDK 20: https://gist.github.com/683c6219e183cbc2b336224fc2c0d50a
> Benchmark of this patch: https://gist.github.com/22be9371a2370fb4a7b44f1684750ec4
> Benchmark of [asotona's patch](https://github.com/openjdk/jdk/pull/12945/files#diff-ac8e413d3e13532a2b0d34a90253c6ddd7a4f04082f792b9d076e9b5a33f2078): https://gist.github.com/eb98579c3b51cafae481049a95a78f80
> 
> [sotona vs this](https://jmh.morethan.io/?gists=eb98579c3b51cafae481049a95a78f80,22be9371a2370fb4a7b44f1684750ec4); [20 vs this](https://jmh.morethan.io/?gists=683c6219e183cbc2b336224fc2c0d50a,22be9371a2370fb4a7b44f1684750ec4); [20 vs sotona](https://jmh.morethan.io/?gists=683c6219e183cbc2b336224fc2c0d50a,eb98579c3b51cafae481049a95a78f80), for reference

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Fix some inconsistencies in the method descriptor derivation methods

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13186/files
  - new: https://git.openjdk.org/jdk/pull/13186/files/4aa2fe0c..2c940b25

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13186&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13186&range=00-01

  Stats: 10 lines in 1 file changed: 4 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/13186.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13186/head:pull/13186

PR: https://git.openjdk.org/jdk/pull/13186

From duke at openjdk.org  Sun Mar 26 23:03:48 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Sun, 26 Mar 2023 23:03:48 GMT
Subject: Integrated: 8304013: Add a fast,
 non-manual alternative to test/jdk/java/util/zip/ZipFile/TestTooManyEntries
In-Reply-To: 
References: 
Message-ID: 

On Thu, 26 Jan 2023 18:49:47 GMT, Eirik Bjorsnos  wrote:

> The TestTooManyEntries test was originally added to validate that ZIP64 files with CEN sizes exceeding what ZipFile  supports are rejected with a ZipException. The test does this by creating a large ZIP file (several gigabytes) with many enties. Because this is resource intensive, the test is currently tagged as manual.  (See #6927)
> 
> It would be useful to have a test which asserts the CEN size enforcement, but without the CPU, disk, memory and run time requirements of TestTooManyEntries.  Such a fast test can run non-manual,  without the @requires and manual tags as found in TestTooManyEntries.
> 
> This PR adds the EndOfCenValidation test which creates sparse test ZIPs where the CEN is "inflated" such that is matches the size declared in the "End of central directory" records.
> 
> While thee sparse files look large, they consume very little disk space on file systems supporting sparse files:
> 
> 
> 16 -rw-r--r--  1   2147483702 Feb  6 18:54 bad-cen-offset.zip
> 16 -rw-r--r--  1   2147483703 Feb  6 18:54 cen-size-too-large.zip
>  8 -rw-r--r--  1          132 Feb  6 18:54 invalid-zen-size.zip
> ``` 
> 
> For good measure, two new test methods are added to excercise the remaining ZipExceptions which ZipFile may throw during validation of the END record .

This pull request has now been integrated.

Changeset: 65e01da9
Author:    Eirik Bjorsnos 
Committer: Lance Andersen 
URL:       https://git.openjdk.org/jdk/commit/65e01da925d49b77341551e38ffb7f0ea7141650
Stats:     238 lines in 1 file changed: 238 ins; 0 del; 0 mod

8304013: Add a fast, non-manual alternative to test/jdk/java/util/zip/ZipFile/TestTooManyEntries

Reviewed-by: lancea, martin

-------------

PR: https://git.openjdk.org/jdk/pull/12231

From david.holmes at oracle.com  Mon Mar 27 02:52:31 2023
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 27 Mar 2023 12:52:31 +1000
Subject: RFR: 8303485: Replacing os.name for operating system
 customization [v6]
In-Reply-To: <-_VpYPMNB-6G0nYrcb7I5Vm6KiSMvg4gDNvcnKHsVN8=.5be28fce-c566-4dc9-8f3c-c261949fccc0@github.com>
References: 
 
 
 <5tyWsnWAY9NxUa7yWSaYKutazCd6MSFibdY30zUb0t0=.8f24b10d-317d-418e-8e9f-a2a56c531917@github.com>
 
 <5sQVvvND57nlCMzdGIAX_3Znf6Yexv_tCqHuZTJrTIk=.d1c2a120-27e8-4db8-8518-c29b11adfbf5@github.com>
 
 <-_VpYPMNB-6G0nYrcb7I5Vm6KiSMvg4gDNvcnKHsVN8=.5be28fce-c566-4dc9-8f3c-c261949fccc0@github.com>
Message-ID: <405cbf63-6c29-3f3e-48b2-7dfa49212b0f@oracle.com>

On 25/03/2023 3:06 am, Roger Riggs wrote:
> On Fri, 24 Mar 2023 16:53:05 GMT, Michael Osipov  wrote:
> 
>>> If you are referring to "Red Hat Enterprise Linux", it'd be correct (AFAIK) to say that Red Hat identifies "Red Hat Enterprise Linux" as an operating system, but I wouldn't go so far as to say that Red Hat calls "Linux" an operating system (well... subject to the reality of human inaccuracy). And the validity and correctness of the term "GNU/Linux" is *definitely* disputed (and likely always will be).
>>>
>>> Maybe "Operating systems based on the Linux kernel" would be satisfactory?
>>
>> That is acceptable, totally.
> 
> Not the rabbit-hole I expected to go down today or for an informal comment on an internal API.
> I have no skin in that game.
> https://www.redhat.com/en/topics/linux/what-is-linux

Also:

https://www.oracle.com/au/linux/

David

From dholmes at openjdk.org  Mon Mar 27 05:26:31 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 27 Mar 2023 05:26:31 GMT
Subject: RFR: 8304871: Use default visibility for static library builds
In-Reply-To: 
References: 
Message-ID: 

On Fri, 24 Mar 2023 15:31:32 GMT, Severin Gehwolf  wrote:

> Please review this change for symbol visibility of static library artefacts. This fixes an issue when
> OpenJDK is being used as a base for generating native images preventing the symbols from being
> exported and looked up from the executable. Note that symbol visibity is now controlled by a
> linker version script downstream. This changes nothing for the regularly shipped dynamic libraries.
> 
> Thoughts?

make/autoconf/flags-cflags.m4 line 639:

> 637:   STATIC_LIBS_CFLAGS="-DSTATIC_BUILD=1"
> 638:   if test "x$TOOLCHAIN_TYPE" = xgcc || test "x$TOOLCHAIN_TYPE" = xclang; then
> 639:     STATIC_LIBS_CFLAGS="$STATIC_LIBS_CFLAGS -ffunction-sections -fdata-sections"

Is it better/clearer to make the use of the default explicit as we do in the source:

#define JNIEXPORT     __attribute__((visibility("default")))

?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13177#discussion_r1148797430

From asotona at openjdk.org  Mon Mar 27 07:56:33 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 27 Mar 2023 07:56:33 GMT
Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator
 to use the Classfile API to generate proxy classes [v12]
In-Reply-To: 
References: 
Message-ID: 

> java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes and this patch converts it to use Classfile API.
> 
> Please review.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  Apply suggestions from code review
  
  Co-authored-by: liach <7806504+liach at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10991/files
  - new: https://git.openjdk.org/jdk/pull/10991/files/ff79658a..36927822

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10991&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10991&range=10-11

  Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10991.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10991/head:pull/10991

PR: https://git.openjdk.org/jdk/pull/10991

From asotona at openjdk.org  Mon Mar 27 08:14:21 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 27 Mar 2023 08:14:21 GMT
Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator
 to use the Classfile API to generate proxy classes [v13]
In-Reply-To: 
References: 
Message-ID: 

> java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes and this patch converts it to use Classfile API.
> 
> Please review.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  cleanup of NAME_CTOR and NAME_CLINIT in ProxyGenerator

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10991/files
  - new: https://git.openjdk.org/jdk/pull/10991/files/36927822..3352329d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10991&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10991&range=11-12

  Stats: 9 lines in 1 file changed: 0 ins; 2 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/10991.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10991/head:pull/10991

PR: https://git.openjdk.org/jdk/pull/10991

From asotona at openjdk.org  Mon Mar 27 08:14:27 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 27 Mar 2023 08:14:27 GMT
Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator
 to use the Classfile API to generate proxy classes [v10]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 22 Mar 2023 17:46:37 GMT, Chen Liang  wrote:

>> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 201 commits:
>> 
>>  - Merge branch 'master' into JDK-8294961
>>    
>>    # Conflicts:
>>    #	src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java
>>  - ClassEntry caching ClassDesc to improve performance
>>  - MethodTypeDesc performance improvements
>>  - improved method descriptor construction
>>  - Apply suggestions from code review
>>    
>>    Co-authored-by: liach <7806504+liach at users.noreply.github.com>
>>  - Merge branch 'master' into JDK-8294961-proxy
>>  - Merge branch 'master' into JDK-8294961-proxy
>>  - Merge branch 'JDK-8294982' into JDK-8294961
>>  - removed obsolete javadoc from implementation classes
>>  - minor fix in CodeBuilder and added test cases to LDCTest
>>  - ... and 191 more: https://git.openjdk.org/jdk/compare/a2d8f634...2787185c
>
> src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 91:
> 
>> 89: 
>> 90:     private static final String NAME_CTOR = "";
>> 91:     private static final String NAME_CLINIT = "";
> 
> Can be replaced with `ConstantDescs.INIT_NAME` and `CLASS_INIT_NAME`

fixed, thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10991#discussion_r1148940422

From sgehwolf at openjdk.org  Mon Mar 27 08:59:31 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 27 Mar 2023 08:59:31 GMT
Subject: RFR: 8304871: Use default visibility for static library builds
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 27 Mar 2023 05:23:26 GMT, David Holmes  wrote:

>> Please review this change for symbol visibility of static library artefacts. This fixes an issue when
>> OpenJDK is being used as a base for generating native images preventing the symbols from being
>> exported and looked up from the executable. Note that symbol visibity is now controlled by a
>> linker version script downstream. This changes nothing for the regularly shipped dynamic libraries.
>> 
>> Thoughts?
>
> make/autoconf/flags-cflags.m4 line 639:
> 
>> 637:   STATIC_LIBS_CFLAGS="-DSTATIC_BUILD=1"
>> 638:   if test "x$TOOLCHAIN_TYPE" = xgcc || test "x$TOOLCHAIN_TYPE" = xclang; then
>> 639:     STATIC_LIBS_CFLAGS="$STATIC_LIBS_CFLAGS -ffunction-sections -fdata-sections"
> 
> Is it better/clearer to make the use of the default explicit as we do in the source:
> 
> #define JNIEXPORT     __attribute__((visibility("default")))
> 
> ?

@dholmes-ora Do you mean something like this (instead of removing the `-D` expression)?


STATIC_LIBS_CFLAGS="$STATIC_LIBS_CFLAGS -ffunction-sections -fdata-sections \
      -DJNIEXPORT='__attribute__((visibility("default")))'"


I can surely do that if that's preferred. No preference either way as far as I'm concerned.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13177#discussion_r1149000471

From aturbanov at openjdk.org  Mon Mar 27 09:28:42 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 27 Mar 2023 09:28:42 GMT
Subject: RFR: 8303485: Replacing os.name for operating system customization
 [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 24 Mar 2023 17:06:45 GMT, Roger Riggs  wrote:

>> Improvements to support OS specific customization for JDK internal use:
>>  - To select values and code; allowing elimination of unused code and values
>>  - Optionally evaluated by build processes, compilation, or archiving (i.e. CDS)
>>  - Simple API to replace adhoc comparisons with `os.name`
>>  - Clear and consistent use across build, runtime, and JDK modules
>>  
>> The PR includes updates within java.base to use the new API.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   clarify Linux

src/java.base/unix/classes/java/lang/ProcessImpl.java line 95:

> 93:     /**
> 94:      * {@return the default or requested launch mechanism}
> 95:      * @throw Error if the requested launch mechanism is not found or valid

Shouldn't it be `@throws` instead of `@throw` ?

src/java.base/unix/classes/java/lang/ProcessImpl.java line 97:

> 95:      * @throw Error if the requested launch mechanism is not found or valid
> 96:      */
> 97:     @SuppressWarnings("removal")

What is deprecated for removal in this method?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12931#discussion_r1149036771
PR Review Comment: https://git.openjdk.org/jdk/pull/12931#discussion_r1149038057

From sgehwolf at openjdk.org  Mon Mar 27 09:40:22 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 27 Mar 2023 09:40:22 GMT
Subject: RFR: 8304871: Use default visibility for static library builds
 [v2]
In-Reply-To: 
References: 
Message-ID: 

> Please review this change for symbol visibility of static library artefacts. This fixes an issue when
> OpenJDK is being used as a base for generating native images preventing the symbols from being
> exported and looked up from the executable. Note that symbol visibity is now controlled by a
> linker version script downstream. This changes nothing for the regularly shipped dynamic libraries.
> 
> Thoughts?

Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:

  Explicitly set the JNI_EXPORT define for static libs

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13177/files
  - new: https://git.openjdk.org/jdk/pull/13177/files/6732c880..119b8947

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13177&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13177&range=00-01

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13177.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13177/head:pull/13177

PR: https://git.openjdk.org/jdk/pull/13177

From sgehwolf at openjdk.org  Mon Mar 27 09:40:24 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 27 Mar 2023 09:40:24 GMT
Subject: RFR: 8304871: Use default visibility for static library builds
 [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 27 Mar 2023 08:56:15 GMT, Severin Gehwolf  wrote:

>> make/autoconf/flags-cflags.m4 line 639:
>> 
>>> 637:   STATIC_LIBS_CFLAGS="-DSTATIC_BUILD=1"
>>> 638:   if test "x$TOOLCHAIN_TYPE" = xgcc || test "x$TOOLCHAIN_TYPE" = xclang; then
>>> 639:     STATIC_LIBS_CFLAGS="$STATIC_LIBS_CFLAGS -ffunction-sections -fdata-sections"
>> 
>> Is it better/clearer to make the use of the default explicit as we do in the source:
>> 
>> #define JNIEXPORT     __attribute__((visibility("default")))
>> 
>> ?
>
> @dholmes-ora Do you mean something like this (instead of removing the `-D` expression)?
> 
> 
> STATIC_LIBS_CFLAGS="$STATIC_LIBS_CFLAGS -ffunction-sections -fdata-sections \
>       -DJNIEXPORT='__attribute__((visibility("default")))'"
> 
> 
> I can surely do that if that's preferred. No preference either way as far as I'm concerned.

I've done that now. Let me know if that's what you had in mind.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13177#discussion_r1149050621

From rgiulietti at openjdk.org  Mon Mar 27 10:17:33 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 27 Mar 2023 10:17:33 GMT
Subject: RFR: JDK-8304028: Port fdlibm IEEEremainder to Java
In-Reply-To: 
References: 
Message-ID: 

On Tue, 21 Mar 2023 06:11:57 GMT, Joe Darcy  wrote:

> Last but not least, a port of fdlibm IEEEremainder from C to Java. I plan to write some more implementation-specific tests around decision points in the FDLIBM algorithm, but I wanted to get the bulk of the changes out for review first.
> 
> Note that since IEEEremainder was the last native method in StrictMath.java, the StrictMath.c file needed to be deleted (or modified) since StrictMath.h was no longer generated as part of the build. (StrictMath.c was one of the file deleted as part of JDK-8302801).
> 
> For testing, Mach 5 tier 1 through 3 were successful (other than an unrelated test failure that was problem listed) and the exhaustive test was locally run and passed with "16, 16" to increase the testing density.

src/java.base/share/classes/java/lang/FdLibm.java line 3331:

> 3329: 
> 3330:             if (hp <= 0x7fdf_ffff) {  // now x < 2p
> 3331:                 x = __ieee754_fmod(x, p + p);

if (hp <= 0x7fdf_ffff) {
                x = __ieee754_fmod(x, p + p);  // now x < 2p

src/java.base/share/classes/java/lang/FdLibm.java line 3372:

> 3370:             // purge off exception values
> 3371:             if((hy | ly) == 0 || (hx >= 0x7ff0_0000)||       // y = 0, or x not finite
> 3372:                ((hy | ((ly | -ly) >> 31)) > 0x7ff0_0000))    // or y is NaN

Suggestion:

               ((hy | ((ly | -ly) >>> 31)) > 0x7ff0_0000))    // or y is NaN, unsigned shift

test/jdk/java/lang/StrictMath/FdlibmTranslit.java line 2652:

> 2650:             /* purge off exception values */
> 2651:             if((hy|ly)==0||(hx>=0x7ff00000)||       /* y=0,or x not finite */
> 2652:                ((hy|((ly|-ly)>>31))>0x7ff00000))     /* or y is NaN */

Suggestion:

               ((hy|((ly|-ly)>>>31))>0x7ff00000))     /* or y is NaN */

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13113#discussion_r1149070401
PR Review Comment: https://git.openjdk.org/jdk/pull/13113#discussion_r1149074081
PR Review Comment: https://git.openjdk.org/jdk/pull/13113#discussion_r1149058824

From jpai at openjdk.org  Mon Mar 27 11:07:34 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 27 Mar 2023 11:07:34 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v14]
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.org/browse/JDK-8206890?
> 
> The `jlink` command allows a `--endian` option to specify the byte order in the generated image. Before this change, when such a image was being launched, the code would assume the byte order in the image to be the native order of the host where the image is being launched. That would result in failure to launch java, as noted in the linked issue.
> 
> The commit in this PR, changes relevant places to not assume native order and instead determine the byte order by reading the magic bytes in the image file's header content.
> 
> A new jtreg test has been added which reproduces the issue and verifies the fix.

Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:

 - update the property key names in target.properties to use ".endianness" suffix
 - remove @since 21 on internal class

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11943/files
  - new: https://git.openjdk.org/jdk/pull/11943/files/6f4ab9c6..6ef19a97

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11943&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11943&range=12-13

  Stats: 26 lines in 3 files changed: 12 ins; 1 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/11943.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/11943/head:pull/11943

PR: https://git.openjdk.org/jdk/pull/11943

From jpai at openjdk.org  Mon Mar 27 11:07:41 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 27 Mar 2023 11:07:41 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v13]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 24 Mar 2023 16:40:55 GMT, Mandy Chung  wrote:

>> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:
>> 
>>  - merge latest from master branch
>>  - Mandy's suggested patch improvements
>>  - ARM is 32 bit as per platform.m4 in OpenJDK build
>>  - when --endian is specified, verify it matches the implicitly determined target platform's endianness
>>  - trim down the architecture support to the previous values plus a few new that match target.properties
>>  - improve error messages as suggested by Mandy
>>  - formatting fix
>>  - Alan's suggestions - don't parse arch out of osname-arch for determining endianness and reduce the number of supported/known target platforms for cross linking
>>  - Mandy's suggestion - pass along target platform to the DefaultImageBuilder to prevent reparsing the value from the ModuleTarget
>>  - Mandy's suggestion to use Platform class for additional arch support. Plus, Jim's suggestion to use a runtime resource for endianness mapping
>>  - ... and 18 more: https://git.openjdk.org/jdk/compare/ac6af6a6...6f4ab9c6
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/builder/DefaultImageBuilder.java line 168:
> 
>> 166:      * @throws IOException
>> 167:      * @throws NullPointerException If any of the params is null
>> 168:      * @since 21
> 
> you can drop this as this is not a public API.

Removed in latest update of the PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/11943#discussion_r1149148648

From jpai at openjdk.org  Mon Mar 27 11:08:13 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 27 Mar 2023 11:08:13 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v13]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Fri, 24 Mar 2023 16:52:10 GMT, Mandy Chung  wrote:

>> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Platform.java line 49:
>> 
>>> 47:             throw new ExceptionInInitializerError(e);
>>> 48:         }
>>> 49:         KNOWN_ENDIANNESS = p;
>> 
>> The naming/usage suggests the value is solely for endianness but I think we want target properties to be able to support other attributes of the target too. This means "endianness" in the property name or the property value is something like a comma separate list of attributes, I don't have a strong opinion on this. But maybe your proposal is just to get the target.properties in place and we change it later?
>
> I read this as for endianness only and so the filename might be "target-endianness.properties" or something like that.   OTOH,  I like keeping it `target.properties` and add `.endianness` as the property name suffix will make it extensible to support other attributes easily.

Given these inputs, I've now updated the PR to use `.endianness` as a suffix to individual keys in the properties file, to allow us reuse this `target.properties` for other details.

Existing tests continue to pass and manual testing shows the correct endianness is detected during cross platform image creation.

I'll trigger a tier testing to make sure nothing breaks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/11943#discussion_r1149150867

From asotona at openjdk.org  Mon Mar 27 11:26:15 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 27 Mar 2023 11:26:15 GMT
Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator
 to use the Classfile API to generate proxy classes [v14]
In-Reply-To: 
References: 
Message-ID: 

> java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes and this patch converts it to use Classfile API.
> 
> Please review.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  SplitConstantPool performance improvement

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10991/files
  - new: https://git.openjdk.org/jdk/pull/10991/files/3352329d..14d7a24d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10991&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10991&range=12-13

  Stats: 9 lines in 2 files changed: 6 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10991.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10991/head:pull/10991

PR: https://git.openjdk.org/jdk/pull/10991

From erikj at openjdk.org  Mon Mar 27 13:07:30 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 27 Mar 2023 13:07:30 GMT
Subject: RFR: 8304871: Use default visibility for static library builds
 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 27 Mar 2023 09:40:22 GMT, Severin Gehwolf  wrote:

>> Please review this change for symbol visibility of static library artefacts. This fixes an issue when
>> OpenJDK is being used as a base for generating native images preventing the symbols from being
>> exported and looked up from the executable. Note that symbol visibity is now controlled by a
>> linker version script downstream. This changes nothing for the regularly shipped dynamic libraries.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Explicitly set the JNI_EXPORT define for static libs

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13177#pullrequestreview-1359012423

From liach at openjdk.org  Mon Mar 27 13:21:11 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 27 Mar 2023 13:21:11 GMT
Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator
 to use the Classfile API to generate proxy classes [v14]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 27 Mar 2023 11:26:15 GMT, Adam Sotona  wrote:

>> java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes and this patch converts it to use Classfile API.
>> 
>> Please review.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   SplitConstantPool performance improvement

src/java.base/share/classes/java/lang/constant/MethodTypeDescImpl.java line 79:

> 77:             paramTypes[i] = ClassDesc.ofDescriptor(types.get(i + 1));
> 78:         }
> 79:         return new MethodTypeDescImpl(ret, paramTypes);

I have an alternative implementation in #13186 which somewhat speeds up for no-arg method types too; the code there no longer copies the parameter arrays on `parameterList()` calls, might help too (as a few places in Classfile API uses MethodTypeDesc.parameterList())

src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java line 256:

> 254: 
> 255:     private Frame getFrame(int offset) {
> 256:         for (var f : frames) {

How large is the frames list expected to be? We can probably perform binary searches if the list is too large.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10991#discussion_r1149225345
PR Review Comment: https://git.openjdk.org/jdk/pull/10991#discussion_r1149225218

From jvernee at openjdk.org  Mon Mar 27 13:26:28 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 27 Mar 2023 13:26:28 GMT
Subject: RFR: 8303524: Check FunctionDescriptor byte order when linking
Message-ID: 

Linkers are strongly tied to a particular byte order, because they are tied to a particular platform. So, the linker should reject layouts that have another byte order. This patch implements that check.

-------------

Depends on: https://git.openjdk.org/jdk/pull/13079

Commit messages:
 - Check byte order of layouts passed to linker

Changes: https://git.openjdk.org/jdk/pull/13161/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13161&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303524
  Stats: 81 lines in 9 files changed: 73 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/13161.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13161/head:pull/13161

PR: https://git.openjdk.org/jdk/pull/13161

From duke at openjdk.org  Mon Mar 27 13:26:33 2023
From: duke at openjdk.org (ExE Boss)
Date: Mon, 27 Mar 2023 13:26:33 GMT
Subject: RFR: 8303524: Check FunctionDescriptor byte order when linking
In-Reply-To: 
References: 
Message-ID: 

On Thu, 23 Mar 2023 16:47:08 GMT, Jorn Vernee  wrote:

> Linkers are strongly tied to a particular byte order, because they are tied to a particular platform. So, the linker should reject layouts that have another byte order. This patch implements that check.

src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java line 114:

> 112:     private void checkLayouts(FunctionDescriptor descriptor) {
> 113:         descriptor.returnLayout().ifPresent(this::checkLayoutsRecursive);
> 114:         descriptor.argumentLayouts().forEach(this::checkLayoutsRecursive);

Storing?`this::checkLayoutsRecursive` in?a?local?variable allows the?`Consumer` to?be?reused for?the?return and?argument?layouts, thus?only one?lambda?class and?instance needs?to?be?allocated instead?of?two.
Suggestion:

        final Consumer checker = this::checkLayoutsRecursive;
        descriptor.returnLayout().ifPresent(checker);
        descriptor.argumentLayouts().forEach(checker);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13161#discussion_r1147232059

From jvernee at openjdk.org  Mon Mar 27 13:26:34 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 27 Mar 2023 13:26:34 GMT
Subject: RFR: 8303524: Check FunctionDescriptor byte order when linking
In-Reply-To: 
References: 
 
Message-ID: <45oiT1a3wYXoB3xdGEGs57EjHPuj0Ap1k4-HnLVlgyw=.869387ab-786b-43b7-b99b-e353afd42cf8@github.com>

On Fri, 24 Mar 2023 08:02:05 GMT, ExE Boss  wrote:

>> Linkers are strongly tied to a particular byte order, because they are tied to a particular platform. So, the linker should reject layouts that have another byte order. This patch implements that check.
>
> src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java line 114:
> 
>> 112:     private void checkLayouts(FunctionDescriptor descriptor) {
>> 113:         descriptor.returnLayout().ifPresent(this::checkLayoutsRecursive);
>> 114:         descriptor.argumentLayouts().forEach(this::checkLayoutsRecursive);
> 
> Storing?`this::checkLayoutsRecursive` in?a?local?variable allows the?`Consumer` to?be?reused for?the?return and?argument?layouts, thus?only one?lambda?class and?instance needs?to?be?allocated instead?of?two.
> Suggestion:
> 
>         final Consumer checker = this::checkLayoutsRecursive;
>         descriptor.returnLayout().ifPresent(checker);
>         descriptor.argumentLayouts().forEach(checker);

Thanks for the suggestion, but I won't engage in speculative performance engineering. Any attempts to improve performance should be paired with thorough benchmarking to verify that effort is being made in the right area (the `checkLayouts` method barely shows up in profiles) and to validate the changes made actually result in a net improvement. But I think that's outside of the scope of this PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13161#discussion_r1147673174

From dfuchs at openjdk.org  Mon Mar 27 13:29:26 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 27 Mar 2023 13:29:26 GMT
Subject: RFR: 8303485: Replacing os.name for operating system customization
 [v7]
In-Reply-To: 
References: 
 
 
Message-ID: <59dcZbGNkr3y6izHSIehO5V9SN3kLH7o1OWPkfSknbo=.adf7219e-a986-4390-b13a-a246ff0dd0a7@github.com>

On Mon, 27 Mar 2023 09:26:03 GMT, Andrey Turbanov  wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   clarify Linux
>
> src/java.base/unix/classes/java/lang/ProcessImpl.java line 97:
> 
>> 95:      * @throw Error if the requested launch mechanism is not found or valid
>> 96:      */
>> 97:     @SuppressWarnings("removal")
> 
> What is deprecated for removal in this method?

`GetPropertyAction::privilegedGetProperty` has been marked deprecated for removal because it uses the SecurityManager

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12931#discussion_r1149236777

From sgehwolf at openjdk.org  Mon Mar 27 13:39:57 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 27 Mar 2023 13:39:57 GMT
Subject: RFR: 8304871: Use default visibility for static library builds
 [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 27 Mar 2023 13:04:28 GMT, Erik Joelsson  wrote:

>> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Explicitly set the JNI_EXPORT define for static libs
>
> Marked as reviewed by erikj (Reviewer).

Thanks for the review @erikj79!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13177#issuecomment-1485107322

From liach at openjdk.org  Mon Mar 27 13:40:32 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 27 Mar 2023 13:40:32 GMT
Subject: RFR: 8304425: ClassHierarchyResolver from Reflection [v4]
In-Reply-To: <08Hy6pEhV75yr_F4mCP-dkKOKMCSoFxWI2E7OnM4iyQ=.cfa14992-8e94-4d6d-bdf9-e6689549c83e@github.com>
References: <08Hy6pEhV75yr_F4mCP-dkKOKMCSoFxWI2E7OnM4iyQ=.cfa14992-8e94-4d6d-bdf9-e6689549c83e@github.com>
Message-ID: <4FoY7mLOxN0W4PmOmmfAoFO_4Q3fwxmBi0iUwDFrb8g=.9fc31cc9-3d68-4cb6-a98a-b9754981dabf@github.com>

> Add API to explore Class Hierarchy with a `ClassLoader` or a `Lookup` with proper privileges, with tests.
> 
> This addition is useful in case classes at runtime are not loaded from the system class loader, such as Proxy. This is also useful to APIs that generate bytecode with a `Lookup` object, such as a custom single-abstract-method class implementations from a method handle.
> 
> See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000249.html as well.
> 
> Current questions, which I wish to discuss with @asotona:
> 1. Should the resolver fail fast on `IllegalAccessException` from the lookup? This usually indicates the hierarchy resolver is set up improperly, and proceeding may simply yield verification errors in class loading that are hard to track. For bytecode-generating APIs, throwing access errors for the Lookup eagerly is also more preferable than later silent generation failure.
> 2. Whether the default resolver should be reading from jrt alone, reflection alone, or jrt then reflection. I personally believe reflection alone is more reliable, for classes may redefined with instrumentation or jfr, which may not be reflected in the system resources.
> 3. In addition, I don't think chaining system class loader reflection after system resource retrieval is really meaningful: is there any case where reflection always works while the system resource retrieval always fails?

Chen Liang 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 hierarchy-resolve
 - Update src/java.base/share/classes/jdk/internal/classfile/impl/ClassHierarchyImpl.java
   
   Co-authored-by: Andrey Turbanov 
 - Make lookup based resolver throw on illegal access eagerly
 - 8304425: ClassHierarchyResolver from Reflection
 - ClassHierarchyResolver using Reflection

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13082/files
  - new: https://git.openjdk.org/jdk/pull/13082/files/5ab4056f..5e2ff7bf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13082&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13082&range=02-03

  Stats: 18280 lines in 593 files changed: 8151 ins; 7170 del; 2959 mod
  Patch: https://git.openjdk.org/jdk/pull/13082.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13082/head:pull/13082

PR: https://git.openjdk.org/jdk/pull/13082

From jvernee at openjdk.org  Mon Mar 27 13:59:17 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 27 Mar 2023 13:59:17 GMT
Subject: RFR: 8303002: Reject packed structs from linker
Message-ID: <7USKvbFzmmi7JWK2OpNi4p-JGLLLzGZUL_FqjE72jNM=.8ec33082-9300-4990-893c-d70744cc7003@github.com>

This patch adds checks in AbstractLinker to reject packed structs and structs with excess padding (e.g. unnamed bitfields), since both of those are currently not supported, and the ABI/spec seems too vague to base support on.

-------------

Depends on: https://git.openjdk.org/jdk/pull/13161

Commit messages:
 - fix check for padding. Add check for trailing padding too
 - Reject packed structs and structs with extra padding

Changes: https://git.openjdk.org/jdk/pull/13164/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13164&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303002
  Stats: 73 lines in 4 files changed: 63 ins; 3 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/13164.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13164/head:pull/13164

PR: https://git.openjdk.org/jdk/pull/13164

From aturbanov at openjdk.org  Mon Mar 27 14:22:09 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 27 Mar 2023 14:22:09 GMT
Subject: RFR: 8303485: Replacing os.name for operating system customization
 [v7]
In-Reply-To: <59dcZbGNkr3y6izHSIehO5V9SN3kLH7o1OWPkfSknbo=.adf7219e-a986-4390-b13a-a246ff0dd0a7@github.com>
References: 
 
 
 <59dcZbGNkr3y6izHSIehO5V9SN3kLH7o1OWPkfSknbo=.adf7219e-a986-4390-b13a-a246ff0dd0a7@github.com>
Message-ID: 

On Mon, 27 Mar 2023 13:26:22 GMT, Daniel Fuchs  wrote:

>> src/java.base/unix/classes/java/lang/ProcessImpl.java line 97:
>> 
>>> 95:      * @throw Error if the requested launch mechanism is not found or valid
>>> 96:      */
>>> 97:     @SuppressWarnings("removal")
>> 
>> What is deprecated for removal in this method?
>
> `GetPropertyAction::privilegedGetProperty` has been marked deprecated for removal because it uses the SecurityManager

As I can see it uses deprecated `SecurityManager`, but it's not deprecated itself.
Do I miss something? Or javac generates warning even in such cases?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12931#discussion_r1149314439

From aturbanov at openjdk.org  Mon Mar 27 14:22:10 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 27 Mar 2023 14:22:10 GMT
Subject: RFR: 8303485: Replacing os.name for operating system customization
 [v7]
In-Reply-To: 
References: 
 
 
 <59dcZbGNkr3y6izHSIehO5V9SN3kLH7o1OWPkfSknbo=.adf7219e-a986-4390-b13a-a246ff0dd0a7@github.com>
 
Message-ID: 

On Mon, 27 Mar 2023 14:15:59 GMT, Andrey Turbanov  wrote:

>> `GetPropertyAction::privilegedGetProperty` has been marked deprecated for removal because it uses the SecurityManager
>
> As I can see it uses deprecated `SecurityManager`, but it's not deprecated itself.
> Do I miss something? Or javac generates warning even in such cases?

As I can see it uses deprecated `SecurityManager`, but it's not deprecated itself.
Do I miss something? Or javac generates warning even in such cases?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12931#discussion_r1149314772

From dfuchs at openjdk.org  Mon Mar 27 14:22:12 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 27 Mar 2023 14:22:12 GMT
Subject: RFR: 8303485: Replacing os.name for operating system customization
 [v7]
In-Reply-To: 
References: 
 
 
 <59dcZbGNkr3y6izHSIehO5V9SN3kLH7o1OWPkfSknbo=.adf7219e-a986-4390-b13a-a246ff0dd0a7@github.com>
 
 
Message-ID: <_OU-NarNYw_ljAEL254LZmwPZgBuhnC90zaSjQnUWlQ=.9c27898b-b14b-4bbb-ac47-e6f8a23478e9@github.com>

On Mon, 27 Mar 2023 14:16:12 GMT, Andrey Turbanov  wrote:

>> As I can see it uses deprecated `SecurityManager`, but it's not deprecated itself.
>> Do I miss something? Or javac generates warning even in such cases?
>
> As I can see it uses deprecated `SecurityManager`, but it's not deprecated itself.
> Do I miss something? Or javac generates warning even in such cases?

https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/action/GetPropertyAction.java#L104

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12931#discussion_r1149318962

From liach at openjdk.org  Mon Mar 27 14:34:06 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 27 Mar 2023 14:34:06 GMT
Subject: RFR: 8304425: ClassHierarchyResolver from Reflection [v5]
In-Reply-To: <08Hy6pEhV75yr_F4mCP-dkKOKMCSoFxWI2E7OnM4iyQ=.cfa14992-8e94-4d6d-bdf9-e6689549c83e@github.com>
References: <08Hy6pEhV75yr_F4mCP-dkKOKMCSoFxWI2E7OnM4iyQ=.cfa14992-8e94-4d6d-bdf9-e6689549c83e@github.com>
Message-ID: 

> Add API to explore Class Hierarchy with a `ClassLoader` or a `Lookup` with proper privileges, with tests.
> 
> This addition is useful in case classes at runtime are not loaded from the system class loader, such as Proxy. This is also useful to APIs that generate bytecode with a `Lookup` object, such as a custom single-abstract-method class implementations from a method handle.
> 
> See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000249.html as well.
> 
> Current questions, which I wish to discuss with @asotona:
> 1. Should the resolver fail fast on `IllegalAccessException` from the lookup? This usually indicates the hierarchy resolver is set up improperly, and proceeding may simply yield verification errors in class loading that are hard to track. For bytecode-generating APIs, throwing access errors for the Lookup eagerly is also more preferable than later silent generation failure.
> 2. Whether the default resolver should be reading from jrt alone, reflection alone, or jrt then reflection. I personally believe reflection alone is more reliable, for classes may redefined with instrumentation or jfr, which may not be reflected in the system resources.
> 3. In addition, I don't think chaining system class loader reflection after system resource retrieval is really meaningful: is there any case where reflection always works while the system resource retrieval always fails?

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Update the class hierarchy resolver api as per mailing list last week

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13082/files
  - new: https://git.openjdk.org/jdk/pull/13082/files/5e2ff7bf..655b0276

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13082&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13082&range=03-04

  Stats: 174 lines in 4 files changed: 104 ins; 23 del; 47 mod
  Patch: https://git.openjdk.org/jdk/pull/13082.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13082/head:pull/13082

PR: https://git.openjdk.org/jdk/pull/13082

From aturbanov at openjdk.org  Mon Mar 27 14:34:36 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 27 Mar 2023 14:34:36 GMT
Subject: RFR: 8303485: Replacing os.name for operating system customization
 [v7]
In-Reply-To: <_OU-NarNYw_ljAEL254LZmwPZgBuhnC90zaSjQnUWlQ=.9c27898b-b14b-4bbb-ac47-e6f8a23478e9@github.com>
References: 
 
 
 <59dcZbGNkr3y6izHSIehO5V9SN3kLH7o1OWPkfSknbo=.adf7219e-a986-4390-b13a-a246ff0dd0a7@github.com>
 
 
 <_OU-NarNYw_ljAEL254LZmwPZgBuhnC90zaSjQnUWlQ=.9c27898b-b14b-4bbb-ac47-e6f8a23478e9@github.com>
Message-ID: <0g4LQtdPvD4eMKe7AInVTLxik4kR6_VdWsiOXkwygCM=.e0d5c731-ef86-448a-b4de-f79db505a2f0@github.com>

On Mon, 27 Mar 2023 14:19:04 GMT, Daniel Fuchs  wrote:

>> As I can see it uses deprecated `SecurityManager`, but it's not deprecated itself.
>> Do I miss something? Or javac generates warning even in such cases?
>
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/action/GetPropertyAction.java#L104

But it's not a deprecation of the method/class. It just suppression of the warning.
`GetPropertyAction.privilegedGetProperty` is used in many places in JDK, without `@SuppressWarnings("removal")`. It doesn't create any problems.
As an example `java.lang.VirtualThread#createDelayedTaskScheduler`. There is no redundant suppression https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/VirtualThread.java#L1107

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12931#discussion_r1149337687

From dfuchs at openjdk.org  Mon Mar 27 14:39:47 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 27 Mar 2023 14:39:47 GMT
Subject: RFR: 8303485: Replacing os.name for operating system customization
 [v7]
In-Reply-To: <0g4LQtdPvD4eMKe7AInVTLxik4kR6_VdWsiOXkwygCM=.e0d5c731-ef86-448a-b4de-f79db505a2f0@github.com>
References: 
 
 
 <59dcZbGNkr3y6izHSIehO5V9SN3kLH7o1OWPkfSknbo=.adf7219e-a986-4390-b13a-a246ff0dd0a7@github.com>
 
 
 <_OU-NarNYw_ljAEL254LZmwPZgBuhnC90zaSjQnUWlQ=.9c27898b-b14b-4bbb-ac47-e6f8a23478e9@github.com>
 <0g4LQtdPvD4eMKe7AInVTLxik4kR6_VdWsiOXkwygCM=.e0d5c731-ef86-448a-b4de-f79db505a2f0@github.com>
Message-ID: 

On Mon, 27 Mar 2023 14:31:14 GMT, Andrey Turbanov  wrote:

>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/action/GetPropertyAction.java#L104
>
> But it's not a deprecation of the method/class. It just suppression of the warning.
> `GetPropertyAction.privilegedGetProperty` is used in many places in JDK, without `@SuppressWarnings("removal")`. It doesn't create any problems.
> As an example `java.lang.VirtualThread#createDelayedTaskScheduler`. There is no redundant suppression https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/VirtualThread.java#L1107

Ah - sorry you're right.  Apologies for the confusion.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12931#discussion_r1149343410

From mcimadamore at openjdk.org  Mon Mar 27 14:46:54 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 27 Mar 2023 14:46:54 GMT
Subject: RFR: 8303524: Check FunctionDescriptor byte order when linking
In-Reply-To: 
References: 
Message-ID: 

On Thu, 23 Mar 2023 16:47:08 GMT, Jorn Vernee  wrote:

> Linkers are strongly tied to a particular byte order, because they are tied to a particular platform. So, the linker should reject layouts that have another byte order. This patch implements that check.

The code changes look good, but the javadoc should be updated to reflect the new constraints.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13161#pullrequestreview-1359225396

From alanb at openjdk.org  Mon Mar 27 14:52:23 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 27 Mar 2023 14:52:23 GMT
Subject: RFR: 8304448: Kitchensink failed:
 assert(!thread->is_in_any_VTMS_transition()) failed: class prepare events are
 not allowed in any VTMS transition
In-Reply-To: 
References: 
Message-ID: 

On Thu, 23 Mar 2023 09:10:26 GMT, Serguei Spitsyn  wrote:

> The fix was suggested/provided by @AlanBateman.
> Continuation should use Unsafe.compareAndSetReference rather than a VH here.
> We had to change CHM and VT back to Unsafe for similar reasons.
> 
> Testing: Mach5 runs of tiers 1-6 are in progress

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13154#pullrequestreview-1359239534

From mcimadamore at openjdk.org  Mon Mar 27 14:54:37 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 27 Mar 2023 14:54:37 GMT
Subject: RFR: 8303002: Reject packed structs from linker
In-Reply-To: <7USKvbFzmmi7JWK2OpNi4p-JGLLLzGZUL_FqjE72jNM=.8ec33082-9300-4990-893c-d70744cc7003@github.com>
References: <7USKvbFzmmi7JWK2OpNi4p-JGLLLzGZUL_FqjE72jNM=.8ec33082-9300-4990-893c-d70744cc7003@github.com>
Message-ID: 

On Thu, 23 Mar 2023 18:11:18 GMT, Jorn Vernee  wrote:

> This patch adds checks in AbstractLinker to reject packed structs and structs with excess padding (e.g. unnamed bitfields), since both of those are currently not supported, and the ABI/spec seems too vague to base support on.

src/java.base/share/classes/java/lang/foreign/Linker.java line 200:

> 198:  * 
> 199:  * 
      
> 200:  * Note that due to limited ABI specification coverage, none of the native linker implementations supports

Is there something bigger to say here? E.g. can I pass a C int with an alignment other than its size? E.g. is there a requirement that the alignment of _all_ layouts should be identical to their natural alignment? If so, we should say so.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13164#discussion_r1149370526

From asotona at openjdk.org  Mon Mar 27 15:11:20 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 27 Mar 2023 15:11:20 GMT
Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator
 to use the Classfile API to generate proxy classes [v14]
In-Reply-To: 
References: 
 
 
Message-ID: <-U2LIrdBboxOJ6FRLMuH2hCCHg8hVrSS4g0X2SrzTlI=.8c4d8680-edea-4530-bdcb-6b3f44ec2134@github.com>

On Mon, 27 Mar 2023 13:17:35 GMT, Chen Liang  wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   SplitConstantPool performance improvement
>
> src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java line 256:
> 
>> 254: 
>> 255:     private Frame getFrame(int offset) {
>> 256:         for (var f : frames) {
> 
> How large is the frames list expected to be? We can probably perform binary searches if the list is too large.

The number of frames is usually low, however I'll try to benchmark the difference.
Thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10991#discussion_r1149395671

From jvernee at openjdk.org  Mon Mar 27 15:13:38 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 27 Mar 2023 15:13:38 GMT
Subject: RFR: 8303524: Check FunctionDescriptor byte order when linking
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 27 Mar 2023 14:44:10 GMT, Maurizio Cimadamore  wrote:

> The code changes look good, but the javadoc should be updated to reflect the new constraints.

We currently have this:

    @throws IllegalArgumentException if the provided function descriptor is not supported by this linker.

Which technically seems enough to cover this as well, as byte order is part of the layouts that are part of the function descriptor. I'm not sure if we want to get very detailed here. Different linker implementations might make different decisions, at least theoretically, but this is also the case for the fallback linker which e.g. rejects unions and accepts layouts with any byte order.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13161#issuecomment-1485296463

From bpb at openjdk.org  Mon Mar 27 15:27:06 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 27 Mar 2023 15:27:06 GMT
Subject: RFR: 8304745: Lazily initialize byte[] in
 java.io.BufferedInputStream [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 24 Mar 2023 10:27:45 GMT, Alan Bateman  wrote:

> Can you try the patch below instead? This will ensure that read, skip, reset, etc. check buf as before.

I think that the implementation provided by @AlanBateman looks good.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13150#issuecomment-1485331836

From mcimadamore at openjdk.org  Mon Mar 27 15:29:57 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 27 Mar 2023 15:29:57 GMT
Subject: RFR: 8303524: Check FunctionDescriptor byte order when linking
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 27 Mar 2023 15:09:57 GMT, Jorn Vernee  wrote:

> > The code changes look good, but the javadoc should be updated to reflect the new constraints.
> 
> We currently have this:
> 
> ```
> @throws IllegalArgumentException if the provided function descriptor is not supported by this linker.
> ```
> 
> Which technically seems enough to cover this as well, as byte order is part of the layouts that are part of the function descriptor. I'm not sure if we want to get very detailed here. Different linker implementations might make different decisions, at least theoretically, but this is also the case for the fallback linker which e.g. rejects unions and accepts layouts with any byte order.

I'm noting an asymmetry between this and https://github.com/openjdk/jdk/pull/13164. I think the same arguments apply for/against both.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13161#issuecomment-1485336428

From vromero at openjdk.org  Mon Mar 27 15:38:57 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 27 Mar 2023 15:38:57 GMT
Subject: RFR: 8304498: JShell does not switch to raw mode when there is no
 /bin/test [v2]
In-Reply-To: <3zqgbZ1T9WHdEQxojLFpW1eJ0_iqxRnmkyGgu2YiMXw=.cb6b356a-fb3c-484c-aca3-3f09304e30c8@github.com>
References: 
 <3zqgbZ1T9WHdEQxojLFpW1eJ0_iqxRnmkyGgu2YiMXw=.cb6b356a-fb3c-484c-aca3-3f09304e30c8@github.com>
Message-ID: 

On Wed, 22 Mar 2023 18:38:08 GMT, Jan Lahoda  wrote:

>> If JShell is run on a system that does not have `/bin/test` (which is, apparently, possible for some systems, which only have `/usr/bin/test`), it won't switch the terminal into the raw mode, and the input will not work properly.
>> 
>> The proposed fix herein is to detect whether `test` existing in `/usr/bin/test`, and if yes, use that location. Use the existing `/bin/test` otherwise.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Checking the executable flags instead of running the program, as suggested.

looks sensible

-------------

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13100#pullrequestreview-1359340541

From jvernee at openjdk.org  Mon Mar 27 16:04:43 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 27 Mar 2023 16:04:43 GMT
Subject: RFR: 8303524: Check FunctionDescriptor byte order when linking
In-Reply-To: 
References: 
Message-ID: 

On Thu, 23 Mar 2023 16:47:08 GMT, Jorn Vernee  wrote:

> Linkers are strongly tied to a particular byte order, because they are tied to a particular platform. So, the linker should reject layouts that have another byte order. This patch implements that check.

> > > The code changes look good, but the javadoc should be updated to reflect the new constraints.
> > 
> > 
> > We currently have this:
> > ```
> > @throws IllegalArgumentException if the provided function descriptor is not supported by this linker.
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > Which technically seems enough to cover this as well, as byte order is part of the layouts that are part of the function descriptor. I'm not sure if we want to get very detailed here. Different linker implementations might make different decisions, at least theoretically, but this is also the case for the fallback linker which e.g. rejects unions and accepts layouts with any byte order.
> 
> I'm noting an asymmetry between this and #13164. I think the same arguments apply for/against both.

Ok. I think there is room for some text in the class javadoc, since that is talking specifically about the native linker. But I don't think we should add more text on the `downcallHandle`/`upcallStub` methods.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13161#issuecomment-1485405979

From rriggs at openjdk.org  Mon Mar 27 16:04:49 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 27 Mar 2023 16:04:49 GMT
Subject: RFR: 8303485: Replacing os.name for operating system customization
 [v8]
In-Reply-To: 
References: 
Message-ID: 

> Improvements to support OS specific customization for JDK internal use:
>  - To select values and code; allowing elimination of unused code and values
>  - Optionally evaluated by build processes, compilation, or archiving (i.e. CDS)
>  - Simple API to replace adhoc comparisons with `os.name`
>  - Clear and consistent use across build, runtime, and JDK modules
>  
> The PR includes updates within java.base to use the new API.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Correct javadoc throws keyword

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12931/files
  - new: https://git.openjdk.org/jdk/pull/12931/files/bfc3de93..3b88f233

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12931&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12931&range=06-07

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12931.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12931/head:pull/12931

PR: https://git.openjdk.org/jdk/pull/12931

From aturbanov at openjdk.org  Mon Mar 27 16:04:53 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 27 Mar 2023 16:04:53 GMT
Subject: RFR: 8303485: Replacing os.name for operating system customization
 [v8]
In-Reply-To: 
References: 
 
Message-ID: <04JvpwSdWh1F_Ztv1U9ZDj4zvK3gUln4lLaS6qNSJwU=.bf56b01b-690b-4965-9037-a3cfd0fdae67@github.com>

On Mon, 27 Mar 2023 16:00:00 GMT, Roger Riggs  wrote:

>> Improvements to support OS specific customization for JDK internal use:
>>  - To select values and code; allowing elimination of unused code and values
>>  - Optionally evaluated by build processes, compilation, or archiving (i.e. CDS)
>>  - Simple API to replace adhoc comparisons with `os.name`
>>  - Clear and consistent use across build, runtime, and JDK modules
>>  
>> The PR includes updates within java.base to use the new API.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct javadoc throws keyword

Changes requested by aturbanov (Committer).

src/java.base/unix/classes/java/lang/ProcessImpl.java line 97:

> 95:      * @throws Error if the requested launch mechanism is not found or valid
> 96:      */
> 97:     @SuppressWarnings("removal")

So, we can remove it
Suggestion:

-------------

PR Review: https://git.openjdk.org/jdk/pull/12931#pullrequestreview-1359391095
PR Review Comment: https://git.openjdk.org/jdk/pull/12931#discussion_r1149469843

From jlaskey at openjdk.org  Mon Mar 27 16:17:44 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 27 Mar 2023 16:17:44 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v49]
In-Reply-To: 
References: 
Message-ID: 

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Requested review changes.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/96752c64..58eeb319

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=48
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=47-48

  Stats: 179 lines in 12 files changed: 31 ins; 116 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From stsypanov at openjdk.org  Mon Mar 27 16:18:22 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Mon, 27 Mar 2023 16:18:22 GMT
Subject: RFR: 8304745: Lazily initialize byte[] in
 java.io.BufferedInputStream [v9]
In-Reply-To: 
References: 
Message-ID: 

> By default `BufferedInputStream` is constructed with internal buffer with capacity 8192. In some cases this buffer is never used, e.g. when we call `IS.readNBytes()` or `IS.readAllBytes()` (relying on `BIS.read1()`) or when `BufferedInputStream` is cascaded.

Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:

  8304745: Add comments for benchmark

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13150/files
  - new: https://git.openjdk.org/jdk/pull/13150/files/783a383b..439460bc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13150&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13150&range=07-08

  Stats: 24 lines in 1 file changed: 23 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13150.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13150/head:pull/13150

PR: https://git.openjdk.org/jdk/pull/13150

From stsypanov at openjdk.org  Mon Mar 27 16:18:26 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Mon, 27 Mar 2023 16:18:26 GMT
Subject: RFR: 8304745: Lazily initialize byte[] in
 java.io.BufferedInputStream [v8]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 24 Mar 2023 19:30:22 GMT, Sergey Tsypanov  wrote:

>> By default `BufferedInputStream` is constructed with internal buffer with capacity 8192. In some cases this buffer is never used, e.g. when we call `IS.readNBytes()` or `IS.readAllBytes()` (relying on `BIS.read1()`) or when `BufferedInputStream` is cascaded.
>
> Sergey Tsypanov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/8304745' into 8304745
>    
>    # Conflicts:
>    #	test/micro/org/openjdk/bench/java/io/BufferedInputStreamBenchmark.java
>  - 8304745: Fix line breaks

Comments added to benchmark.

make test TEST="micro:io.BufferedInputStreamBenchmark" MICRO="OPTIONS=-prof gc"

master

Benchmark                                                             (size)  Mode  Cnt      Score     Error   Units
BufferedInputStreamBenchmark.readAllBytes                               1024  avgt   20      7.278 ?   0.286   us/op
BufferedInputStreamBenchmark.readAllBytes:?gc.alloc.rate                1024  avgt   20   3377.138 ? 131.745  MB/sec
BufferedInputStreamBenchmark.readAllBytes:?gc.alloc.rate.norm           1024  avgt   20  25752.011 ?   0.001    B/op
BufferedInputStreamBenchmark.readAllBytes:?gc.count                     1024  avgt   20    123.000            counts
BufferedInputStreamBenchmark.readAllBytes:?gc.time                      1024  avgt   20   1085.000                ms
BufferedInputStreamBenchmark.readAllBytes                              16384  avgt   20     13.538 ?   0.759   us/op
BufferedInputStreamBenchmark.readAllBytes:?gc.alloc.rate               16384  avgt   20   2901.305 ? 167.849  MB/sec
BufferedInputStreamBenchmark.readAllBytes:?gc.alloc.rate.norm          16384  avgt   20  41112.228 ?   0.013    B/op
BufferedInputStreamBenchmark.readAllBytes:?gc.count                    16384  avgt   20    107.000            counts
BufferedInputStreamBenchmark.readAllBytes:?gc.time                     16384  avgt   20   1012.000                ms
BufferedInputStreamBenchmark.readAllBytesCascade                        1024  avgt   20     13.273 ?   0.729   us/op
BufferedInputStreamBenchmark.readAllBytesCascade:?gc.alloc.rate         1024  avgt   20   2452.198 ? 136.123  MB/sec
BufferedInputStreamBenchmark.readAllBytesCascade:?gc.alloc.rate.norm    1024  avgt   20  34064.020 ?   0.001    B/op
BufferedInputStreamBenchmark.readAllBytesCascade:?gc.count              1024  avgt   20     93.000            counts
BufferedInputStreamBenchmark.readAllBytesCascade:?gc.time               1024  avgt   20   1081.000                ms
BufferedInputStreamBenchmark.readAllBytesCascade                       16384  avgt   20     24.633 ?   3.127   us/op
BufferedInputStreamBenchmark.readAllBytesCascade:?gc.alloc.rate        16384  avgt   20   1943.798 ? 229.336  MB/sec
BufferedInputStreamBenchmark.readAllBytesCascade:?gc.alloc.rate.norm   16384  avgt   20  49424.413 ?   0.052    B/op
BufferedInputStreamBenchmark.readAllBytesCascade:?gc.count             16384  avgt   20     72.000            counts
BufferedInputStreamBenchmark.readAllBytesCascade:?gc.time              16384  avgt   20    993.000                ms

8304745

Benchmark                                                             (size)  Mode  Cnt      Score      Error   Units
BufferedInputStreamBenchmark.readAllBytes                               1024  avgt   20      2.212 ?    0.038   us/op
BufferedInputStreamBenchmark.readAllBytes:?gc.alloc.rate                1024  avgt   20   7563.662 ?  135.402  MB/sec
BufferedInputStreamBenchmark.readAllBytes:?gc.alloc.rate.norm           1024  avgt   20  17552.003 ?    0.001    B/op
BufferedInputStreamBenchmark.readAllBytes:?gc.count                     1024  avgt   20    339.000             counts
BufferedInputStreamBenchmark.readAllBytes:?gc.time                      1024  avgt   20    691.000                 ms
BufferedInputStreamBenchmark.readAllBytes                              16384  avgt   20      3.127 ?    0.071   us/op
BufferedInputStreamBenchmark.readAllBytes:?gc.alloc.rate               16384  avgt   20  10034.809 ?  222.058  MB/sec
BufferedInputStreamBenchmark.readAllBytes:?gc.alloc.rate.norm          16384  avgt   20  32912.053 ?    0.001    B/op
BufferedInputStreamBenchmark.readAllBytes:?gc.count                    16384  avgt   20    388.000             counts
BufferedInputStreamBenchmark.readAllBytes:?gc.time                     16384  avgt   20    953.000                 ms
BufferedInputStreamBenchmark.readAllBytesCascade                        1024  avgt   20      2.521 ?    0.048   us/op
BufferedInputStreamBenchmark.readAllBytesCascade:?gc.alloc.rate         1024  avgt   20   6678.812 ?  126.007  MB/sec
BufferedInputStreamBenchmark.readAllBytesCascade:?gc.alloc.rate.norm    1024  avgt   20  17664.004 ?    0.001    B/op
BufferedInputStreamBenchmark.readAllBytesCascade:?gc.count              1024  avgt   20    176.000             counts
BufferedInputStreamBenchmark.readAllBytesCascade:?gc.time               1024  avgt   20   1049.000                 ms
BufferedInputStreamBenchmark.readAllBytesCascade                       16384  avgt   20      4.728 ?    0.905   us/op
BufferedInputStreamBenchmark.readAllBytesCascade:?gc.alloc.rate        16384  avgt   20   6911.193 ? 1061.227  MB/sec
BufferedInputStreamBenchmark.readAllBytesCascade:?gc.alloc.rate.norm   16384  avgt   20  33024.080 ?    0.015    B/op
BufferedInputStreamBenchmark.readAllBytesCascade:?gc.count             16384  avgt   20    191.000             counts
BufferedInputStreamBenchmark.readAllBytesCascade:?gc.time              16384  avgt   20   1157.000                 ms

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13150#issuecomment-1485425304
PR Comment: https://git.openjdk.org/jdk/pull/13150#issuecomment-1485427789

From stsypanov at openjdk.org  Mon Mar 27 16:26:16 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Mon, 27 Mar 2023 16:26:16 GMT
Subject: RFR: 8304918: Remove unused decl field from AnnotatedType
 implementations
In-Reply-To: 
References: 
Message-ID: 

On Sat, 25 Mar 2023 05:52:44 GMT, Chen Liang  wrote:

> In `AnnotatedTypeBaseImpl`, a `decl` field is declared, referring to the declaration that the AnnotatedType is from. However, this field is not used anywhere except passing to constructors of other implementations; it's not used in debug messages (unlike in `TypeAnnotation`), not involved in equality checks. Since these implementations are not serializable, we can safely remove the decl field from the implementations. All 1048 java/lang tests pass on my machine.

Marked as reviewed by stsypanov (Author).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13183#pullrequestreview-1359433318

From stsypanov at openjdk.org  Mon Mar 27 16:27:18 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Mon, 27 Mar 2023 16:27:18 GMT
Subject: RFR: 8304976: Optimize
 DateTimeFormatterBuilder.ZoneTextPrinterParser.getTree()
Message-ID: 

1) When `DateTimeFormatter` is reused we don't need to copy `availableZoneIds` and allocate `nonRegionIds` as PrefixTree can be taken from cache. In the related benchmark allocation of `HashSet` takes ~93% of all time, so avoiding it should bring some improvement for cases when we reuse `DateTimeFormatter` to parse a string into `ZoneDateTime`
![image](https://user-images.githubusercontent.com/10835776/219609028-af48eae4-d326-4719-8366-c215baa85835.png)

2) `DateTimeFormatter` is mostly used with one locale, so `cachedTree` and `cachedTreeCI` can have predefined size.


@State(Scope.Thread)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
public class DateTimeFormatterBenchmark {

    private static final DateTimeFormatter df = new DateTimeFormatterBuilder().appendPattern("yyyy:MM:dd:HH:mm:v").toFormatter();
    private static final String TEXT = "2015:03:10:12:13:ECT";

    @Setup
    public void setUp() {
        ZonedDateTime.parse(TEXT, df);
    }

    @Benchmark
    public ZonedDateTime parse() {
        return ZonedDateTime.parse(TEXT, df);
    }
}

-------------

Commit messages:
 - Revert irrelevant
 - Revert irrelevant
 - Measure average time
 - Delete duplicated
 - Merge branch 'master' into date-time-formatter-build
 - Add benchmark
 - Add JavaDoc and imports
 - Optimize DateTimeFormatterBuilder

Changes: https://git.openjdk.org/jdk/pull/12612/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12612&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304976
  Stats: 62 lines in 2 files changed: 57 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/12612.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12612/head:pull/12612

PR: https://git.openjdk.org/jdk/pull/12612

From stsypanov at openjdk.org  Mon Mar 27 16:27:19 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Mon, 27 Mar 2023 16:27:19 GMT
Subject: RFR: 8304976: Optimize
 DateTimeFormatterBuilder.ZoneTextPrinterParser.getTree()
In-Reply-To: 
References: 
Message-ID: <2UjizIpykQCtRLPmFK4Xh8AsL2N38BuR5AVvuIrc0hk=.532bbab1-4c8c-4ed1-8356-17abb715b8a3@github.com>

On Fri, 17 Feb 2023 09:50:16 GMT, Sergey Tsypanov  wrote:

> 1) When `DateTimeFormatter` is reused we don't need to copy `availableZoneIds` and allocate `nonRegionIds` as PrefixTree can be taken from cache. In the related benchmark allocation of `HashSet` takes ~93% of all time, so avoiding it should bring some improvement for cases when we reuse `DateTimeFormatter` to parse a string into `ZoneDateTime`
> ![image](https://user-images.githubusercontent.com/10835776/219609028-af48eae4-d326-4719-8366-c215baa85835.png)
> 
> 2) `DateTimeFormatter` is mostly used with one locale, so `cachedTree` and `cachedTreeCI` can have predefined size.
> 
> 
> @State(Scope.Thread)
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> public class DateTimeFormatterBenchmark {
> 
>     private static final DateTimeFormatter df = new DateTimeFormatterBuilder().appendPattern("yyyy:MM:dd:HH:mm:v").toFormatter();
>     private static final String TEXT = "2015:03:10:12:13:ECT";
> 
>     @Setup
>     public void setUp() {
>         ZonedDateTime.parse(TEXT, df);
>     }
> 
>     @Benchmark
>     public ZonedDateTime parse() {
>         return ZonedDateTime.parse(TEXT, df);
>     }
> }

Benchmarking

make test TEST="micro:time.format.ZonedDateTimeFormatterBenchmark" MICRO="OPTIONS=-prof gc"

master

Benchmark                                                              Mode  Cnt      Score     Error   Units
ZonedDateTimeFormatterBenchmark.parse                                  avgt   20  13545.737 ? 451.164   ns/op
ZonedDateTimeFormatterBenchmark.parse:?gc.alloc.rate                   avgt   20   1713.579 ?  56.517  MB/sec
ZonedDateTimeFormatterBenchmark.parse:?gc.alloc.rate.norm              avgt   20  24320.006 ?   0.001    B/op
ZonedDateTimeFormatterBenchmark.parse:?gc.count                        avgt   20    110.000            counts
ZonedDateTimeFormatterBenchmark.parse:?gc.time                         avgt   20    514.000                ms


patch

Benchmark                                                              Mode  Cnt     Score    Error   Units
ZonedDateTimeFormatterBenchmark.parse                                  avgt   20  1276.063 ? 52.543   ns/op
ZonedDateTimeFormatterBenchmark.parse:?gc.alloc.rate                   avgt   20   622.223 ? 26.456  MB/sec
ZonedDateTimeFormatterBenchmark.parse:?gc.alloc.rate.norm              avgt   20   832.001 ?  0.001    B/op
ZonedDateTimeFormatterBenchmark.parse:?gc.count                        avgt   20    58.000           counts
ZonedDateTimeFormatterBenchmark.parse:?gc.time                         avgt   20   475.000               ms

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12612#issuecomment-1483893997

From asotona at openjdk.org  Mon Mar 27 16:43:17 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 27 Mar 2023 16:43:17 GMT
Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator
 to use the Classfile API to generate proxy classes [v15]
In-Reply-To: 
References: 
Message-ID: 

> java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes and this patch converts it to use Classfile API.
> 
> Please review.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  StackMapGenerator performance improvements

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10991/files
  - new: https://git.openjdk.org/jdk/pull/10991/files/14d7a24d..8de24dc8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10991&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10991&range=13-14

  Stats: 158 lines in 3 files changed: 36 ins; 17 del; 105 mod
  Patch: https://git.openjdk.org/jdk/pull/10991.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10991/head:pull/10991

PR: https://git.openjdk.org/jdk/pull/10991

From asotona at openjdk.org  Mon Mar 27 16:43:49 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 27 Mar 2023 16:43:49 GMT
Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator
 to use the Classfile API to generate proxy classes [v14]
In-Reply-To: <-U2LIrdBboxOJ6FRLMuH2hCCHg8hVrSS4g0X2SrzTlI=.8c4d8680-edea-4530-bdcb-6b3f44ec2134@github.com>
References: 
 
 
 <-U2LIrdBboxOJ6FRLMuH2hCCHg8hVrSS4g0X2SrzTlI=.8c4d8680-edea-4530-bdcb-6b3f44ec2134@github.com>
Message-ID: 

On Mon, 27 Mar 2023 15:07:42 GMT, Adam Sotona  wrote:

>> src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java line 256:
>> 
>>> 254: 
>>> 255:     private Frame getFrame(int offset) {
>>> 256:         for (var f : frames) {
>> 
>> How large is the frames list expected to be? We can probably perform binary searches if the list is too large.
>
> The number of frames is usually low, however I'll try to benchmark the difference.
> Thanks.

For ProxyGenerator the difference was insignificant, however in benchmarks transforming also more complex code it improved StackMapGenerator performance by approx. 7%.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10991#discussion_r1149520090

From mchung at openjdk.org  Mon Mar 27 16:44:45 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 27 Mar 2023 16:44:45 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v14]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 27 Mar 2023 11:07:34 GMT, Jaikiran Pai  wrote:

>> Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8206890?
>> 
>> The `jlink` command allows a `--endian` option to specify the byte order in the generated image. Before this change, when such a image was being launched, the code would assume the byte order in the image to be the native order of the host where the image is being launched. That would result in failure to launch java, as noted in the linked issue.
>> 
>> The commit in this PR, changes relevant places to not assume native order and instead determine the byte order by reading the magic bytes in the image file's header content.
>> 
>> A new jtreg test has been added which reproduces the issue and verifies the fix.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - update the property key names in target.properties to use ".endianness" suffix
>  - remove @since 21 on internal class

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Platform.java line 57:

> 55:                 if (platform.isEmpty()) {
> 56:                     throw new InternalError("Incorrect key '" + key + "'");
> 57:                 }

If you scan all entries, this can probably check the value is valid (`little` or `big`) and store them in a `Map` so that `parsePlatform` can simply get the byte order by `KNOWN_ENDIANNESS.get(platformString)`.

Or the other option can just be doing in the `parsePlatform` method and not needed to scan all entries.


   String v = KNOWN_ENDIANNESS.getProperty(platformString + ENDIANNESS_KEY_SUFFIX);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/11943#discussion_r1149519476

From duke at openjdk.org  Mon Mar 27 16:59:17 2023
From: duke at openjdk.org (ExE Boss)
Date: Mon, 27 Mar 2023 16:59:17 GMT
Subject: RFR: JDK-8304028: Port fdlibm IEEEremainder to Java
In-Reply-To: 
References: 
Message-ID: 

On Tue, 21 Mar 2023 06:11:57 GMT, Joe Darcy  wrote:

> Last but not least, a port of fdlibm IEEEremainder from C to Java. I plan to write some more implementation-specific tests around decision points in the FDLIBM algorithm, but I wanted to get the bulk of the changes out for review first.
> 
> Note that since IEEEremainder was the last native method in StrictMath.java, the StrictMath.c file needed to be deleted (or modified) since StrictMath.h was no longer generated as part of the build. (StrictMath.c was one of the file deleted as part of JDK-8302801).
> 
> For testing, Mach 5 tier 1 through 3 were successful (other than an unrelated test failure that was problem listed) and the exhaustive test was locally run and passed with "16, 16" to increase the testing density.

src/java.base/share/classes/java/lang/FdLibm.java line 3475:

> 3473:          */
> 3474:         private static double signedZero(int sign) {
> 3475:             return +0.0 * ( (double)sign);

Suggestion:

            return +0.0 * ((double) sign);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13113#discussion_r1149549191

From mchung at openjdk.org  Mon Mar 27 17:06:31 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 27 Mar 2023 17:06:31 GMT
Subject: RFR: 8304846: Provide a shared utility to dump generated classes
 defined via Lookup API
In-Reply-To: <1535b07c-d226-6e55-e837-a690edfaeb26@oracle.com>
References: 
 <1535b07c-d226-6e55-e837-a690edfaeb26@oracle.com>
Message-ID: 

On Sun, 26 Mar 2023 18:41:12 GMT, Brian Goetz  wrote:

> Since LMF goes through Lookup::defineHiddenClass, does this mean that they will be potentially dumped twice, once through Lookup, and once through LMF?

No, only once.  The old dumping code in LMF is removed.

> Now that there is a shared implementation, perhaps we should migrate use in LMF to something more like
> 
> -Djava.lang.invoke.MethodHandle.DUMP_LAMBDA_PROXY_CLASS_FILES=true
> 
> and retire the separate dumpProxyClasses flag.

+1.   I think it's simpler to use a boolean property and dump to a known directory.

As this is implementation-specific, I will rename the property name with `jdk.` prefix.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13182#issuecomment-1485516316

From rriggs at openjdk.org  Mon Mar 27 17:50:51 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 27 Mar 2023 17:50:51 GMT
Subject: RFR: 8303485: Replacing os.name for operating system customization
 [v9]
In-Reply-To: 
References: 
Message-ID: 

> Improvements to support OS specific customization for JDK internal use:
>  - To select values and code; allowing elimination of unused code and values
>  - Optionally evaluated by build processes, compilation, or archiving (i.e. CDS)
>  - Simple API to replace adhoc comparisons with `os.name`
>  - Clear and consistent use across build, runtime, and JDK modules
>  
> The PR includes updates within java.base to use the new API.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Remove unused SuppressWarnings

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12931/files
  - new: https://git.openjdk.org/jdk/pull/12931/files/3b88f233..574e37be

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12931&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12931&range=07-08

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12931.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12931/head:pull/12931

PR: https://git.openjdk.org/jdk/pull/12931

From rriggs at openjdk.org  Mon Mar 27 17:50:55 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 27 Mar 2023 17:50:55 GMT
Subject: Integrated: 8303485: Replacing os.name for operating system
 customization
In-Reply-To: 
References: 
Message-ID: 

On Wed, 8 Mar 2023 19:15:16 GMT, Roger Riggs  wrote:

> Improvements to support OS specific customization for JDK internal use:
>  - To select values and code; allowing elimination of unused code and values
>  - Optionally evaluated by build processes, compilation, or archiving (i.e. CDS)
>  - Simple API to replace adhoc comparisons with `os.name`
>  - Clear and consistent use across build, runtime, and JDK modules
>  
> The PR includes updates within java.base to use the new API.

This pull request has now been integrated.

Changeset: 6c3b10fb
Author:    Roger Riggs 
URL:       https://git.openjdk.org/jdk/commit/6c3b10fb1d95fb03e2f7d988d4c772960af11c91
Stats:     411 lines in 13 files changed: 297 ins; 40 del; 74 mod

8303485: Replacing os.name for operating system customization

Reviewed-by: naoto, erikj, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/12931

From mchung at openjdk.org  Mon Mar 27 18:23:24 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 27 Mar 2023 18:23:24 GMT
Subject: RFR: 8304846: Provide a shared utility to dump generated classes
 defined via Lookup API [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 24 Mar 2023 23:00:12 GMT, Mandy Chung  wrote:

>> This implements a shared utility to dump generated classes defined as normal/hidden classes via `Lookup` API.   This replaces the implementation in `LambdaMetaFactory` and method handle implementation that dumps the hidden class bytes on disk for debugging.   
>> 
>> For classes defined via `Lookup::defineClass`, `Lookup::defineHiddenClass` and `Lookup::defineHiddenClassWithClassData`, by default they will be dumped to the path specified in `-Djava.lang.invoke.Lookup.dumpClasses=` 
>> 
>> The hidden classes generated for lambdas, `LambdaForms` and method handle implementation use non-default dumper so that they can be controlled via a separate system property and path as in the current implementation.
>> 
>> To dump lambda proxy classes, set this system property:
>>    -Djdk.internal.lambda.dumpProxyClasses=
>> 
>> To dump LambdaForms and method handle implementation, set this system property:
>>    -Djava.lang.invoke.MethodHandle.DUMP_CLASS_FILES=true
>>    
>> P.S. `ProxyClassesDumper` is renamed to `ClassFileDumper` but for some reason, it's not shown as rename.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   avoid another map lookup

My thought on the property names:

`Lookup::defineClass` and `Lookup::defineHiddenClass` default to enable dumping of the class files via:
`-Djdk.invoke.MethodHandle.dumpClassFiles=true`

LMF and LambdaForms (and other method handle internal classes) are special cases to dump via a different system property respectively:
`-Djdk.invoke.LambdaMetafactory.dumpProxyClassFiles=true`
`-Djdk.invoke.MethodHandle.dumpLambdaForms=true`  or `-Djdk.invoke.MethodHandle.dumpInternalClassFiles=true`

Thoughts/comments?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13182#issuecomment-1485640639

From jlaskey at openjdk.org  Mon Mar 27 18:29:55 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 27 Mar 2023 18:29:55 GMT
Subject: RFR: JDK-8302323 Add repeat methods to StringBuilder/StringBuffer
 [v9]
In-Reply-To: 
References: 
Message-ID: 

> Add the ability to repeatedly append char and CharSequence data to StringBuilder/StringBuffer.

Jim Laskey 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 13 additional commits since the last revision:

 - Merge branch 'master' into 8302323
 - Expand test for StringBuffer and illegal code points
 - Add snippet
 - Support code points
 - Move @since in subclasses
 - Move @since
 - Remove @throws IndexOutOfBoundsException
 - Change error report to use "is negative"
 - Optimize for empty CharSequence
 - PR Cleanup
 - ... and 3 more: https://git.openjdk.org/jdk/compare/e62798ac...54a34cf8

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12728/files
  - new: https://git.openjdk.org/jdk/pull/12728/files/1a77988b..54a34cf8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12728&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12728&range=07-08

  Stats: 379977 lines in 3074 files changed: 221471 ins; 125619 del; 32887 mod
  Patch: https://git.openjdk.org/jdk/pull/12728.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12728/head:pull/12728

PR: https://git.openjdk.org/jdk/pull/12728

From liach at openjdk.org  Mon Mar 27 18:31:05 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 27 Mar 2023 18:31:05 GMT
Subject: RFR: 8304846: Provide a shared utility to dump generated classes
 defined via Lookup API [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 24 Mar 2023 23:00:12 GMT, Mandy Chung  wrote:

>> This implements a shared utility to dump generated classes defined as normal/hidden classes via `Lookup` API.   This replaces the implementation in `LambdaMetaFactory` and method handle implementation that dumps the hidden class bytes on disk for debugging.   
>> 
>> For classes defined via `Lookup::defineClass`, `Lookup::defineHiddenClass` and `Lookup::defineHiddenClassWithClassData`, by default they will be dumped to the path specified in `-Djava.lang.invoke.Lookup.dumpClasses=` 
>> 
>> The hidden classes generated for lambdas, `LambdaForms` and method handle implementation use non-default dumper so that they can be controlled via a separate system property and path as in the current implementation.
>> 
>> To dump lambda proxy classes, set this system property:
>>    -Djdk.internal.lambda.dumpProxyClasses=
>> 
>> To dump LambdaForms and method handle implementation, set this system property:
>>    -Djava.lang.invoke.MethodHandle.DUMP_CLASS_FILES=true
>>    
>> P.S. `ProxyClassesDumper` is renamed to `ClassFileDumper` but for some reason, it's not shown as rename.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   avoid another map lookup

Is there any other place in JDK where classfile dumping is needed but isn't covered by this new utility? I know j.l.r.Proxy for one, but how it declares classes is incompatible with lookups.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13182#issuecomment-1485660542

From jlaskey at openjdk.org  Mon Mar 27 18:37:12 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 27 Mar 2023 18:37:12 GMT
Subject: RFR: JDK-8302323 Add repeat methods to StringBuilder/StringBuffer
 [v10]
In-Reply-To: 
References: 
Message-ID: 

> Add the ability to repeatedly append char and CharSequence data to StringBuilder/StringBuffer.

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Use Arrays.fill

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12728/files
  - new: https://git.openjdk.org/jdk/pull/12728/files/54a34cf8..796406b5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12728&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12728&range=08-09

  Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12728.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12728/head:pull/12728

PR: https://git.openjdk.org/jdk/pull/12728

From jlaskey at openjdk.org  Mon Mar 27 18:37:14 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 27 Mar 2023 18:37:14 GMT
Subject: RFR: JDK-8302323 Add repeat methods to StringBuilder/StringBuffer
 [v8]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 14 Mar 2023 10:14:44 GMT, Claes Redestad  wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Expand test for StringBuffer and illegal code points
>
> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1832:
> 
>> 1830:         if (isLatin1 && StringLatin1.canEncode(c)) {
>> 1831:             byte b = (byte)c;
>> 1832:             for (int index = this.count; index < limit; index++) {
> 
> This loop could even be replaced with `Arrays.fill(value, this.count, limit, b)` - a plausible candidate for intrinsification?  There's an added range check in that method, however, but that shouldn't be too hard for the JIT to eliminate.

I bounded back and forth on this one.  Performance is a little give and take.  Will use Arrays.fill for maintainability.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12728#discussion_r1149648398

From mchung at openjdk.org  Mon Mar 27 18:39:07 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 27 Mar 2023 18:39:07 GMT
Subject: RFR: 8304846: Provide a shared utility to dump generated classes
 defined via Lookup API [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 24 Mar 2023 23:00:12 GMT, Mandy Chung  wrote:

>> This implements a shared utility to dump generated classes defined as normal/hidden classes via `Lookup` API.   This replaces the implementation in `LambdaMetaFactory` and method handle implementation that dumps the hidden class bytes on disk for debugging.   
>> 
>> For classes defined via `Lookup::defineClass`, `Lookup::defineHiddenClass` and `Lookup::defineHiddenClassWithClassData`, by default they will be dumped to the path specified in `-Djava.lang.invoke.Lookup.dumpClasses=` 
>> 
>> The hidden classes generated for lambdas, `LambdaForms` and method handle implementation use non-default dumper so that they can be controlled via a separate system property and path as in the current implementation.
>> 
>> To dump lambda proxy classes, set this system property:
>>    -Djdk.internal.lambda.dumpProxyClasses=
>> 
>> To dump LambdaForms and method handle implementation, set this system property:
>>    -Djava.lang.invoke.MethodHandle.DUMP_CLASS_FILES=true
>>    
>> P.S. `ProxyClassesDumper` is renamed to `ClassFileDumper` but for some reason, it's not shown as rename.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   avoid another map lookup

j.l.r.Proxy needs to define the class file with null protection domain; that's why it can't be converted to use `Lookup::defineClass` yet until security manager is removed.

It's okay to move `ClassFileDumper` to `jdk.internal.util` package as a general dumping facility for j.l.r.Proxy and other areas to use.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13182#issuecomment-1485676366

From christoph.langer at sap.com  Mon Mar 27 21:00:33 2023
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 27 Mar 2023 21:00:33 +0000
Subject: JDK 20 EA builds (archive?)
In-Reply-To: <87e96963-97a6-be5f-935f-df3c27f393e8@gmail.com>
References: <87e96963-97a6-be5f-935f-df3c27f393e8@gmail.com>
Message-ID: 

Hi Chris,

SapMachine has all the ea builds in its GitHub Repo: https://github.com/SAP/SapMachine/releases. Should be fine enough for chasing G1 GC behaviour changes.

Cheers
Christoph

> -----Original Message-----
> From: core-libs-dev  On Behalf Of Chris
> Hegarty
> Sent: Freitag, 24. M?rz 2023 17:56
> To: core-libs-dev at openjdk.org
> Subject: JDK 20 EA builds (archive?)
> 
> Hi,
> 
> While definitely not the right list, someone here will surely know ...
> 
> Where can I download archive EA builds of JDK 20, so I can perform bisect
> experiments to help narrow when something changed between JDK 19 and JDK
> 20.  ( I have some builds, but not that many )
> 
> ---
> Informational: I'm not expecting anyone to do my work for me ;-) but if you
> have ideas or hints!
> 
> I'm try to track down a change in G1 GC behaviour, where the number of GC's
> of the Young generation has decreased ( by ~20% ), but the cumulative total
> time spent in GC of the Young generation has increased marginally ( ~2% ) for a
> particular workload benchmark ( that runs for a medium amount of time, ~20
> mins ).
> 
> Thanks,
> -Chris.

From mchung at openjdk.org  Mon Mar 27 21:12:28 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 27 Mar 2023 21:12:28 GMT
Subject: RFR: 8304846: Provide a shared utility to dump generated classes
 defined via Lookup API [v3]
In-Reply-To: 
References: 
Message-ID: 

> This implements a shared utility to dump generated classes defined as normal/hidden classes via `Lookup` API.   This replaces the implementation in `LambdaMetaFactory` and method handle implementation that dumps the hidden class bytes on disk for debugging.   
> 
> For classes defined via `Lookup::defineClass`, `Lookup::defineHiddenClass` and `Lookup::defineHiddenClassWithClassData`, by default they will be dumped to the path specified in `-Djava.lang.invoke.Lookup.dumpClasses=` 
> 
> The hidden classes generated for lambdas, `LambdaForms` and method handle implementation use non-default dumper so that they can be controlled via a separate system property and path as in the current implementation.
> 
> To dump lambda proxy classes, set this system property:
>    -Djdk.internal.lambda.dumpProxyClasses=
> 
> To dump LambdaForms and method handle implementation, set this system property:
>    -Djava.lang.invoke.MethodHandle.DUMP_CLASS_FILES=true
>    
> P.S. `ProxyClassesDumper` is renamed to `ClassFileDumper` but for some reason, it's not shown as rename.

Mandy Chung has updated the pull request incrementally with two additional commits since the last revision:

 - move ClassFileDumper to jdk.internal.util
 - rename the system property for dumping class files

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13182/files
  - new: https://git.openjdk.org/jdk/pull/13182/files/04406e3b..e424810c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13182&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13182&range=01-02

  Stats: 160 lines in 9 files changed: 55 ins; 46 del; 59 mod
  Patch: https://git.openjdk.org/jdk/pull/13182.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13182/head:pull/13182

PR: https://git.openjdk.org/jdk/pull/13182

From jlu at openjdk.org  Mon Mar 27 21:39:42 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 27 Mar 2023 21:39:42 GMT
Subject: Integrated: 8177352: Calendar.getDisplayName(s) in non-lenient mode
 inconsistent, does not match spec
In-Reply-To: 
References: 
Message-ID: 

On Fri, 17 Mar 2023 18:22:17 GMT, Justin Lu  wrote:

> This PR updates the javadoc of `java.util.Calendar.getDisplayName()` and `java.util.Calendar.getDisplayNames()` to better reflect the actual behavior when the calendar is non-lenient.
> 
> This involves updating the spec of both methods to clarify behavior, as well as removing false behavior from the **throws** tag in `java.util.Calendar.getDisplayNames()`.

This pull request has now been integrated.

Changeset: f8e8fc7e
Author:    Justin Lu 
Committer: Naoto Sato 
URL:       https://git.openjdk.org/jdk/commit/f8e8fc7e29f9b27bc6031804f916c34b8ef5a83e
Stats:     16 lines in 1 file changed: 12 ins; 2 del; 2 mod

8177352: Calendar.getDisplayName(s) in non-lenient mode inconsistent, does not match spec

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/13083

From jlu at openjdk.org  Mon Mar 27 21:40:48 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 27 Mar 2023 21:40:48 GMT
Subject: Integrated: 8304761: Update IANA Language Subtag Registry to Version
 2023-03-22
In-Reply-To: 
References: 
Message-ID: 

On Thu, 23 Mar 2023 19:07:05 GMT, Justin Lu  wrote:

> Update IANA LSR to 2023-03-22 [update](https://mm.icann.org/pipermail/ietf-languages-announcements/2023-March/000085.html). Add all new preferred languages to `ACCEPT_LANGUAGES` except `gu`.

This pull request has now been integrated.

Changeset: 3b88b2a9
Author:    Justin Lu 
Committer: Naoto Sato 
URL:       https://git.openjdk.org/jdk/commit/3b88b2a9f88f47b850bd975a76c4a7050ccd8fd0
Stats:     170 lines in 2 files changed: 155 ins; 1 del; 14 mod

8304761: Update IANA Language Subtag Registry to Version 2023-03-22

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/13165

From sspitsyn at openjdk.org  Mon Mar 27 21:47:52 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 27 Mar 2023 21:47:52 GMT
Subject: RFR: 8304448: Kitchensink failed:
 assert(!thread->is_in_any_VTMS_transition()) failed: class prepare events are
 not allowed in any VTMS transition
In-Reply-To: 
References: 
Message-ID: 

On Thu, 23 Mar 2023 09:10:26 GMT, Serguei Spitsyn  wrote:

> The fix was suggested/provided by @AlanBateman.
> Continuation should use Unsafe.compareAndSetReference rather than a VH here.
> We had to change CHM and VT back to Unsafe for similar reasons.
> 
> Testing: Mach5 runs of tiers 1-6 are in progress

Thank you for review, Alan. :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13154#issuecomment-1485898849

From sspitsyn at openjdk.org  Mon Mar 27 21:47:53 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 27 Mar 2023 21:47:53 GMT
Subject: Integrated: 8304448: Kitchensink failed:
 assert(!thread->is_in_any_VTMS_transition()) failed: class prepare events are
 not allowed in any VTMS transition
In-Reply-To: 
References: 
Message-ID: 

On Thu, 23 Mar 2023 09:10:26 GMT, Serguei Spitsyn  wrote:

> The fix was suggested/provided by @AlanBateman.
> Continuation should use Unsafe.compareAndSetReference rather than a VH here.
> We had to change CHM and VT back to Unsafe for similar reasons.
> 
> Testing: Mach5 runs of tiers 1-6 are in progress

This pull request has now been integrated.

Changeset: 554bccf0
Author:    Serguei Spitsyn 
URL:       https://git.openjdk.org/jdk/commit/554bccf0469fbaf65ac692b4e52bddedafadca6f
Stats:     14 lines in 1 file changed: 1 ins; 10 del; 3 mod

8304448: Kitchensink failed: assert(!thread->is_in_any_VTMS_transition()) failed: class prepare events are not allowed in any VTMS transition

Co-authored-by: Alan Bateman 
Reviewed-by: rpressler, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/13154

From naoto at openjdk.org  Mon Mar 27 22:41:40 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 27 Mar 2023 22:41:40 GMT
Subject: RFR: 8225641: Calendar.roll(int field) does not work correctly for
 WEEK_OF_YEAR [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 24 Mar 2023 18:48:41 GMT, Justin Lu  wrote:

>> This PR fixes the bug which occurred when `Calendar.roll(WEEK_OF_YEAR)` rolled into a minimal first week with an invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo.
>> 
>> For example, Rolling _Monday, 30 December 2019_ by 1 week produced _Monday, 31 December 2018_, which is incorrect. This is because `WEEK_OF_YEAR` is rolled from 52 to 1, and the original `DAY_OF_WEEK` is 1. However, there is no Monday in week 1 of 2019. This is exposed when a future method calls `Calendar.complete()`, which eventually calculates a `fixedDate` with the invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo.
>> 
>> To prevent this, a check is added for rolls into week 1, which determines if the first week is minimal. If it is indeed minimal, then it is checked if  `DAY_OF_WEEK` exists in that week, if not, `WEEK_OF_YEAR` must be incremented by one.
>> 
>> After the fix, Rolling _Monday, 30 December 2019_ by 1 week produces _Monday, 7 January 2019_
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove max week methods accidentally comitted

Looks good. Mostly cosmetic comments follow

src/java.base/share/classes/java/util/GregorianCalendar.java line 1315:

> 1313:                     // rolling up into week 1, as the existing checks
> 1314:                     // sufficiently handle rolling down into week 1.
> 1315:                     if (newWeekOfYear == 1 && (isInvalidWeek1())) {

Extra parens around `isInvalidWeek1()`

src/java.base/share/classes/java/util/GregorianCalendar.java line 1316:

> 1314:                     // sufficiently handle rolling down into week 1.
> 1315:                     if (newWeekOfYear == 1 && (isInvalidWeek1())) {
> 1316:                         if (amount > 0) {

Can be folded into the above `if`

src/java.base/share/classes/java/util/GregorianCalendar.java line 3015:

> 3013:     private boolean isMinWeek (int days) {
> 3014:         return days >= getMinimalDaysInFirstWeek();
> 3015:     }

Since this method is only used above once, maybe make the check inline?

src/java.base/share/classes/java/util/GregorianCalendar.java line 3032:

> 3030:             // not between 6 7 1 2 3
> 3031:             return !(day >= startDay || day <= endDay);
> 3032:         }

Could be more readable if the method does not have `Not`, i.e, `daysInMinWeek`? This would remove the negation in the return statements.

test/jdk/java/util/Calendar/RollToMinWeek.java line 28:

> 26:  * @bug 8225641
> 27:  * @summary Test the behavior of Calendar.roll(WEEK_OF_YEAR) when the last week
> 28:  * is rolled up into a minimal week 1 of the same year

`minimal week 1` may be unclear.

test/jdk/java/util/Calendar/RollToMinWeek.java line 43:

> 41: /**
> 42:  * Test to validate the behavior of Calendar.roll(WEEK_OF_YEAR, +1)
> 43:  * when rolling into a minimal week 1 from the max week. WEEK_OF_YEAR can

IIUC, `minimal` and `max` mean `first` and `last` respectively? I'd rather change those as it would confuse with `minimal days in the first week`.

test/jdk/java/util/Calendar/RollToMinWeek.java line 52:

> 50:     public void rollUpTest(Calendar calendar, String[] validDates){
> 51:         if (calendar instanceof GregorianCalendar) {
> 52:             testRoll(calendar, validDates, +1);

If the amount is fixed to `+1`, no need to pass it as an argument

test/jdk/java/util/Calendar/RollToMinWeek.java line 98:

> 96:                 for (int firstDay = 1; firstDay <= 7; firstDay++) {
> 97:                     calList.add(Arguments.of(buildCalendar("gregory", firstDay, weekLength,
> 98:                                     dayOfMonth, 11, 2019), validDates[date]));

`11` may better be replaced with `Calendar.DECEMBER`.

test/jdk/java/util/Calendar/RollToMinWeek.java line 114:

> 112:         calBuilder.setDate(year, month, dayOfMonth);
> 113:         return calBuilder.build();
> 114:     }

`Builder` instance can be reused. Also since Builder can method chain, you could write

static Calendar.Builder CAL_BUILDER = new Builder().setCalendarType(type);

return CAL_BUILDER
    .setWeekDefinition(...)
    .setDate(...)
    .build();

-------------

PR Review: https://git.openjdk.org/jdk/pull/13031#pullrequestreview-1359843143
PR Review Comment: https://git.openjdk.org/jdk/pull/13031#discussion_r1149772051
PR Review Comment: https://git.openjdk.org/jdk/pull/13031#discussion_r1149771259
PR Review Comment: https://git.openjdk.org/jdk/pull/13031#discussion_r1149777645
PR Review Comment: https://git.openjdk.org/jdk/pull/13031#discussion_r1149779427
PR Review Comment: https://git.openjdk.org/jdk/pull/13031#discussion_r1149838007
PR Review Comment: https://git.openjdk.org/jdk/pull/13031#discussion_r1149838132
PR Review Comment: https://git.openjdk.org/jdk/pull/13031#discussion_r1149843461
PR Review Comment: https://git.openjdk.org/jdk/pull/13031#discussion_r1149847360
PR Review Comment: https://git.openjdk.org/jdk/pull/13031#discussion_r1149851739

From liach at openjdk.org  Mon Mar 27 23:41:32 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 27 Mar 2023 23:41:32 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion
Message-ID: 

As John Rose has pointed out in this issue, the current j.l.r.Proxy based implementation of MethodHandleProxies.asInterface has a few issues:
1. Exposes too much information via Proxy supertype (and WrapperInstance interface)
2. Does not allow future expansion to support SAM[^1] abstract classes
3. Slow (in fact, very slow)

This patch addresses all 3 problems:
1. It implements proxies with one hidden class for each requested interface and replaced WrapperInstance inheritance with an annotation. This can avoid unexpected passing of `instanceof`, and avoids the nasty problem of exporting a JDK interface to a dynamic module to ensure access.
2. This patch obtains already generated classes from a ClassValue by the requested interface type; the ClassValue can later be updated to compute implementation generation for abstract classes as well.
3. This patch's generated hidden classes has acceptable call and creation performance compared to the baseline; though the methods to access wrapper information see huge performance drops, they are not anticipated to be used in a very frequent basis, while the old implementation's wrapper access methods are more optimized (2ns/op) than interface implementation methods (6ns/op). [Oracle JDK 20 vs this](https://jmh.morethan.io/?gists=bf98de7b2128e7e5d14e697fd9921eb9,e5115a2a8fa0a45159e15fab0d95b5d8)

Additionally, an obsolete `ProxyForMethodHandle` test was removed, for it's no longer applicable. Tests in `jdk/java/lang/invoke` and `jdk/java/lang/reflect` pass.

Alternative implementation:
[An alternative implementation](https://github.com/openjdk/jdk/commit/72dbf9d4e01c455854d9b865cb2a47c38f37a8e0) was to generate a proxy class for each methodhandle than sharing across methodhandles. That implementation was abandoned for its bad proxy creation performance, despite it having excellent call performance. [Alternative implementation vs this](https://jmh.morethan.io/?gists=08abb39f224574550925beb8be1b2f59,e5115a2a8fa0a45159e15fab0d95b5d8)

In addition, I have a question: in [8161245](https://bugs.openjdk.org/browse/JDK-8161245) it seems some fields can be optimized as seen in [ciField.cpp](https://github.com/openjdk/jdk/blob/6aec6f3a842ead30b26cd31dc57a2ab268f67875/src/hotspot/share/ci/ciField.cpp#L219). Does it affect the execution performance of MethodHandle in hidden classes' Condy vs. MethodHandle in regular final field in hidden classes?

[^1]: single abstract method

-------------

Commit messages:
 - Wrapper instance type is already available
 - mark records as private
 - Merge branch 'master' into explore/mhp-iface
 - Only generate one class for each interface, sped up creation
 - classvalue cache, check performance difference
 - 6983726: remove Proxy from MethodHandleProxies.asInterfaceInstance SAM conversion

Changes: https://git.openjdk.org/jdk/pull/13197/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13197&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-6983726
  Stats: 577 lines in 4 files changed: 397 ins; 117 del; 63 mod
  Patch: https://git.openjdk.org/jdk/pull/13197.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13197/head:pull/13197

PR: https://git.openjdk.org/jdk/pull/13197

From smarks at openjdk.org  Tue Mar 28 00:01:50 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 28 Mar 2023 00:01:50 GMT
Subject: RFR: 8266571: Sequenced Collections [v3]
In-Reply-To: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
Message-ID: 

> PR for Sequenced Collections implementation.

Stuart Marks 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 JDK-8266571-SequencedCollections
 - Update copyrights.
 - More specification tweaks.
 - Add simple overrides to ArrayList.
 - Specification cleanups.
 - Update spec of CopyOnWriteArrayList::reversed.
 - Move AbstractViewCollection to AbstractMap.ViewCollection to avoid exposing it publicly.
 - Merge branch 'master' into JDK-8266571-SequencedCollections
   Resolve conflict by deleting IdentityLinkedList.java
 - Merge branch 'master' into JDK-8266571-SequencedCollections
 - Fix indentation.
 - ... and 68 more: https://git.openjdk.org/jdk/compare/6aec6f3a...91c4eabe

-------------

Changes: https://git.openjdk.org/jdk/pull/7387/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=7387&range=02
  Stats: 6647 lines in 39 files changed: 6509 ins; 11 del; 127 mod
  Patch: https://git.openjdk.org/jdk/pull/7387.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/7387/head:pull/7387

PR: https://git.openjdk.org/jdk/pull/7387

From smarks at openjdk.org  Tue Mar 28 00:04:46 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 28 Mar 2023 00:04:46 GMT
Subject: RFR: 8266571: Sequenced Collections [v2]
In-Reply-To: <7hyZMdc6JI-92HcIQyh4gFMimualCSo-kSuApHjRPks=.4d53a75e-9caa-448d-a087-d1a03da8130a@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
 <7hyZMdc6JI-92HcIQyh4gFMimualCSo-kSuApHjRPks=.4d53a75e-9caa-448d-a087-d1a03da8130a@github.com>
Message-ID: 

On Sat, 25 Mar 2023 08:19:18 GMT, R?mi Forax  wrote:

>> Stuart Marks has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - More specification tweaks.
>>  - Add simple overrides to ArrayList.
>
> This change is absolutely massive, implementing reversed() basically doubles the number of implementations which means multiple years of debugging / spec fixing.
> 
> Reversing a List makes sense, reversing a LinkedHashSet/LinkedHashMap is a nice to have. Having the concept of first and last (getFirst()/getLast()/etc) on Collection is something long awaited. 
> 
> I understand that wanting to separate the concept of Collection and SequencedCollection can be conceptually nice, but 
> multiplying the number of interfaces also multiplies the number of implementations. Pragmatically, this patch is too big compared to how useful it is.
> 
> I get that Oracle is rich, but this JEP is not only a burden for Oracle but for the whole community.

@forax 

Funnily, I was thinking the other day that this change is quite small given that I've been working on it for over two years. :-)

Anyway, thanks for looking through the implementation.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1486016843

From smarks at openjdk.org  Tue Mar 28 01:14:01 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 28 Mar 2023 01:14:01 GMT
Subject: RFR: 8266571: Sequenced Collections [v3]
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
Message-ID: 

On Fri, 24 Mar 2023 21:28:18 GMT, Tagir F. Valeev  wrote:

>> Stuart Marks 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 JDK-8266571-SequencedCollections
>>  - Update copyrights.
>>  - More specification tweaks.
>>  - Add simple overrides to ArrayList.
>>  - Specification cleanups.
>>  - Update spec of CopyOnWriteArrayList::reversed.
>>  - Move AbstractViewCollection to AbstractMap.ViewCollection to avoid exposing it publicly.
>>  - Merge branch 'master' into JDK-8266571-SequencedCollections
>>    Resolve conflict by deleting IdentityLinkedList.java
>>  - Merge branch 'master' into JDK-8266571-SequencedCollections
>>  - Fix indentation.
>>  - ... and 68 more: https://git.openjdk.org/jdk/compare/6aec6f3a...91c4eabe
>
> src/java.base/share/classes/java/util/LinkedHashMap.java line 782:
> 
>> 780:             return svs;
>> 781:         } else {
>> 782:             return new LinkedValues(false);
> 
> Is it possible that this branch is visited? If yes, probably it worth adding a comment when this happens.

Good point! This was a vestige of an earlier incarnation where a values() view from a subclass could be stored in the `values` field, and of course it would not be a SequencedCollection; thus a new one would have to be created in order to satisfy this method's requirements. However, because the `values` field is a cache that is only set here, we can rely on it to be sequenced. So I've simplified this to assume that the downcast will be successful.

This highlights the fact that a subclass that overrides values() to create and return its own view collection will potentially have different semantics from the view returned by sequencedValues(). For example, they might return different mappings. Unfortunately I think this is unavoidable.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1149926145

From smarks at openjdk.org  Tue Mar 28 01:31:45 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 28 Mar 2023 01:31:45 GMT
Subject: RFR: 8266571: Sequenced Collections [v3]
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
Message-ID: 

On Fri, 24 Mar 2023 21:35:22 GMT, Tagir F. Valeev  wrote:

>> Stuart Marks 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 JDK-8266571-SequencedCollections
>>  - Update copyrights.
>>  - More specification tweaks.
>>  - Add simple overrides to ArrayList.
>>  - Specification cleanups.
>>  - Update spec of CopyOnWriteArrayList::reversed.
>>  - Move AbstractViewCollection to AbstractMap.ViewCollection to avoid exposing it publicly.
>>  - Merge branch 'master' into JDK-8266571-SequencedCollections
>>    Resolve conflict by deleting IdentityLinkedList.java
>>  - Merge branch 'master' into JDK-8266571-SequencedCollections
>>  - Fix indentation.
>>  - ... and 68 more: https://git.openjdk.org/jdk/compare/6aec6f3a...91c4eabe
>
> src/java.base/share/classes/java/util/LinkedHashMap.java line 1123:
> 
>> 1121: 
>> 1122:         public V put(K key, V value) {
>> 1123:             return base.put(key, value);
> 
> Why `put()` simply delegates to `base.put()` while `putAll()` below does more complex containsKey-put-putFirst procedure? I think that `putAll()` should be equivalent to `for(var e : m.entrySet()) put(e.getKey(), e.getValue());`. Am I missing something?

I think you're right, you're not missing anything. The entry that is put() should always go at the end of this view, and since this is the reversed view, it should go at the front of the base map. And putAll() should follow.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1149933611

From jpai at openjdk.org  Tue Mar 28 02:23:05 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 28 Mar 2023 02:23:05 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v15]
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.org/browse/JDK-8206890?
> 
> The `jlink` command allows a `--endian` option to specify the byte order in the generated image. Before this change, when such a image was being launched, the code would assume the byte order in the image to be the native order of the host where the image is being launched. That would result in failure to launch java, as noted in the linked issue.
> 
> The commit in this PR, changes relevant places to not assume native order and instead determine the byte order by reading the magic bytes in the image file's header content.
> 
> A new jtreg test has been added which reproduces the issue and verifies the fix.

Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:

 - don't iterate over the properties file keys and instead do lookup when needed
 - update CDSPluginTest to correctly "simulate" cross-platform test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11943/files
  - new: https://git.openjdk.org/jdk/pull/11943/files/6ef19a97..64781fdd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11943&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11943&range=13-14

  Stats: 52 lines in 2 files changed: 35 ins; 11 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/11943.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/11943/head:pull/11943

PR: https://git.openjdk.org/jdk/pull/11943

From jpai at openjdk.org  Tue Mar 28 02:23:05 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 28 Mar 2023 02:23:05 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v14]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 27 Mar 2023 16:41:09 GMT, Mandy Chung  wrote:

>> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - update the property key names in target.properties to use ".endianness" suffix
>>  - remove @since 21 on internal class
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Platform.java line 57:
> 
>> 55:                 if (platform.isEmpty()) {
>> 56:                     throw new InternalError("Incorrect key '" + key + "'");
>> 57:                 }
> 
> If you scan all entries, this can probably check the value is valid (`little` or `big`) and store them in a `Map` so that `parsePlatform` can simply get the byte order by `KNOWN_ENDIANNESS.get(platformString)`.
> 
> Or the other option can just be doing in the `parsePlatform` method and not needed to scan all entries.
> 
> 
>    String v = KNOWN_ENDIANNESS.getProperty(platformString + ENDIANNESS_KEY_SUFFIX);

Hello Mandy, I was in two minds when I added that iteration logic. I wasn't sure if that was necessary or we could just check for the values when looking up. I have now updated the PR to remove the iteration and just rely on looking up the key, as you suggested, and then checking the value.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/11943#discussion_r1149955754

From jpai at openjdk.org  Tue Mar 28 02:25:37 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 28 Mar 2023 02:25:37 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v14]
In-Reply-To: 
References: 
 
Message-ID: <7Kj2en2z9ypP49lPWSfsDwAW2zPXnsnzV8IMoP-D_iA=.da041c40-b3c7-40e9-abdb-0cc1732b3ddf@github.com>

On Mon, 27 Mar 2023 11:07:34 GMT, Jaikiran Pai  wrote:

>> Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8206890?
>> 
>> The `jlink` command allows a `--endian` option to specify the byte order in the generated image. Before this change, when such a image was being launched, the code would assume the byte order in the image to be the native order of the host where the image is being launched. That would result in failure to launch java, as noted in the linked issue.
>> 
>> The commit in this PR, changes relevant places to not assume native order and instead determine the byte order by reading the magic bytes in the image file's header content.
>> 
>> A new jtreg test has been added which reproduces the issue and verifies the fix.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - update the property key names in target.properties to use ".endianness" suffix
>  - remove @since 21 on internal class

> I'll trigger a tier testing to make sure nothing breaks.

tier tests revealed that we have a `test/jdk/tools/jlink/plugins/CDSPluginTest.java` test which tries to simulate a cross platform jlink image generation. Given our changes in this PR, which only reads the `ModuleTarget` of java.base when the java.base module comes from a different file than the one in the current platform, this caused that simulation to fail and thus the test case failed. I've now updated the test to enhance it in the way in which simulates the cross platform image generation. That test and the rest of them in tier1, tier2 and tier3 all pass with this change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/11943#issuecomment-1486111886

From smarks at openjdk.org  Tue Mar 28 02:37:22 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 28 Mar 2023 02:37:22 GMT
Subject: RFR: 8266571: Sequenced Collections [v4]
In-Reply-To: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
Message-ID: <-BNnKi-AQ6XTBe-GxXIn9Zq7WdROvR9mX73H_gr2rs8=.4c034fa8-781f-4739-ade8-e24f507f55be@github.com>

> PR for Sequenced Collections implementation.

Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:

  Simplify handling of cached keySet, values, and entrySet views.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/7387/files
  - new: https://git.openjdk.org/jdk/pull/7387/files/91c4eabe..3b7762d6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=7387&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=7387&range=02-03

  Stats: 18 lines in 1 file changed: 6 ins; 6 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/7387.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/7387/head:pull/7387

PR: https://git.openjdk.org/jdk/pull/7387

From dholmes at openjdk.org  Tue Mar 28 04:43:28 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 28 Mar 2023 04:43:28 GMT
Subject: RFR: 8304871: Use default visibility for static library builds
 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 27 Mar 2023 09:40:22 GMT, Severin Gehwolf  wrote:

>> Please review this change for symbol visibility of static library artefacts. This fixes an issue when
>> OpenJDK is being used as a base for generating native images preventing the symbols from being
>> exported and looked up from the executable. Note that symbol visibity is now controlled by a
>> linker version script downstream. This changes nothing for the regularly shipped dynamic libraries.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Explicitly set the JNI_EXPORT define for static libs

I also added this to JBS:

JDK-8239563 was also done to support Graal, and this change is now undoing that. Do the Graal folk who want this understand it will restore the problem that JDK-8239563 fixed?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13177#issuecomment-1486205397

From mchung at openjdk.org  Tue Mar 28 04:53:37 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 28 Mar 2023 04:53:37 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v15]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 28 Mar 2023 02:23:05 GMT, Jaikiran Pai  wrote:

>> Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8206890?
>> 
>> The `jlink` command allows a `--endian` option to specify the byte order in the generated image. Before this change, when such a image was being launched, the code would assume the byte order in the image to be the native order of the host where the image is being launched. That would result in failure to launch java, as noted in the linked issue.
>> 
>> The commit in this PR, changes relevant places to not assume native order and instead determine the byte order by reading the magic bytes in the image file's header content.
>> 
>> A new jtreg test has been added which reproduces the issue and verifies the fix.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - don't iterate over the properties file keys and instead do lookup when needed
>  - update CDSPluginTest to correctly "simulate" cross-platform test

Looks good.  Minor comment in `CDSPluginTest.java`.

test/jdk/tools/jlink/plugins/CDSPluginTest.java line 98:

> 96:            // the java.base module-info.class to identify the target platform for the image
> 97:            // being generated.
> 98:            Path jdkRoot = Path.of(jlinkPath).getParent().getParent();

Or simply get from `test.jdk` system property:

Suggestion:

          Path jdkRoot = Path.of(System.getProperty("test.jdk"));

-------------

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/11943#pullrequestreview-1360197068
PR Review Comment: https://git.openjdk.org/jdk/pull/11943#discussion_r1150021265

From jpai at openjdk.org  Tue Mar 28 06:28:17 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 28 Mar 2023 06:28:17 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v16]
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.org/browse/JDK-8206890?
> 
> The `jlink` command allows a `--endian` option to specify the byte order in the generated image. Before this change, when such a image was being launched, the code would assume the byte order in the image to be the native order of the host where the image is being launched. That would result in failure to launch java, as noted in the linked issue.
> 
> The commit in this PR, changes relevant places to not assume native order and instead determine the byte order by reading the magic bytes in the image file's header content.
> 
> A new jtreg test has been added which reproduces the issue and verifies the fix.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  use test.jdk system property in test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11943/files
  - new: https://git.openjdk.org/jdk/pull/11943/files/64781fdd..47717cad

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11943&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11943&range=14-15

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11943.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/11943/head:pull/11943

PR: https://git.openjdk.org/jdk/pull/11943

From jpai at openjdk.org  Tue Mar 28 06:28:21 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 28 Mar 2023 06:28:21 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v15]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 28 Mar 2023 04:46:52 GMT, Mandy Chung  wrote:

>> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - don't iterate over the properties file keys and instead do lookup when needed
>>  - update CDSPluginTest to correctly "simulate" cross-platform test
>
> test/jdk/tools/jlink/plugins/CDSPluginTest.java line 98:
> 
>> 96:            // the java.base module-info.class to identify the target platform for the image
>> 97:            // being generated.
>> 98:            Path jdkRoot = Path.of(jlinkPath).getParent().getParent();
> 
> Or simply get from `test.jdk` system property:
> 
> Suggestion:
> 
>           Path jdkRoot = Path.of(System.getProperty("test.jdk"));

Hello Mandy, the `JDKToolFinder.getJDKTool("jlink")` uses the `test.jdk` to try and find the tool and then falls back to another system property, if the tool wasn't found. That's why I had used this `getParent()` technique to locate the JDK root. But I think using just the `test.jdk` system property should be fine too, since as far as I can see in the test definition of this test, there isn't anything specific that would require the test JDK to be present in any different place than the `test.jdk` system property. I've updated the PR to use this suggested approach.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/11943#discussion_r1150081505

From pminborg at openjdk.org  Tue Mar 28 06:55:26 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 28 Mar 2023 06:55:26 GMT
Subject: RFR: 8300977: Retire java.io.ExpiringCache [v2]
In-Reply-To: 
References: 
Message-ID: 

> This PR proposed to retire the class 'java.io.ExpiringCache'. The use of the class has been off by default since Java 16 but could be explicitly turned on by means of two System properties.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Revert change after comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12167/files
  - new: https://git.openjdk.org/jdk/pull/12167/files/fcc4c96b..105d4583

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12167&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12167&range=00-01

  Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12167.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12167/head:pull/12167

PR: https://git.openjdk.org/jdk/pull/12167

From pminborg at openjdk.org  Tue Mar 28 06:55:30 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 28 Mar 2023 06:55:30 GMT
Subject: RFR: 8300977: Retire java.io.ExpiringCache [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 22 Mar 2023 13:51:23 GMT, Alan Bateman  wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert change after comments
>
> src/java.base/unix/classes/java/io/UnixFileSystem.java line 358:
> 
>> 356:     @Override
>> 357:     public int getNameMax(String path) {
>> 358:         return (int)Math.min(getNameMax0(path), Integer.MAX_VALUE);
> 
> This change is nothing to do with this issue. It's okay to refactor it as a drive-by change but I think keep nameMax as that made it easier to debug.

Reverted

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12167#discussion_r1150105121

From pminborg at openjdk.org  Tue Mar 28 07:21:15 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 28 Mar 2023 07:21:15 GMT
Subject: RFR: 8300979: Lazily initialize (byte,
 char)arr in java.io.DataInputStream [v4]
In-Reply-To: 
References: 
Message-ID: 

> This PR proposed to lazily initialize the scratch arrays only if/when needed.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Use zero-lenght arrays rather than null

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13121/files
  - new: https://git.openjdk.org/jdk/pull/13121/files/efece452..ca165dfa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13121&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13121&range=02-03

  Stats: 6 lines in 1 file changed: 3 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/13121.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13121/head:pull/13121

PR: https://git.openjdk.org/jdk/pull/13121

From pminborg at openjdk.org  Tue Mar 28 07:21:18 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 28 Mar 2023 07:21:18 GMT
Subject: RFR: 8300979: Lazily initialize (byte,
 char)arr in java.io.DataInputStream [v3]
In-Reply-To: <0LX-QnYnFGHJzo0-IctXMu8NthQZvxoboQmeD3WvKpM=.21fde8d5-e7b8-4f9f-ba61-3bc2e222d025@github.com>
References: 
 <5tQ84BWMKaCnFalikXWrEtW9X21bB-ElGw-k5B-KZTQ=.703816ac-c0b1-4e08-be7d-74f6942010a6@github.com>
 
 <0LX-QnYnFGHJzo0-IctXMu8NthQZvxoboQmeD3WvKpM=.21fde8d5-e7b8-4f9f-ba61-3bc2e222d025@github.com>
Message-ID: 

On Thu, 23 Mar 2023 14:00:40 GMT, Eirik Bjorsnos  wrote:

>> I cannot explain why, but the changes suggested in this PR seem to introduce a small, but significant performance regression on the `DataInputStreamTest.readInt` benchmark:
>> 
>> Baseline:
>> 
>> 
>> Benchmark                    Mode  Cnt  Score   Error  Units
>> DataInputStreamTest.readInt  avgt   20  5.563 ? 0.037  us/op
>> 
>> 
>> PR:
>> 
>> 
>> Benchmark                    Mode  Cnt  Score   Error  Units
>> DataInputStreamTest.readInt  avgt   20  6.021 ? 0.020  us/op
>> 
>> 
>> The reason this puzzles me is that the `readInt` benchmark don't involve the UTF code paths at all. So why would it become slower, just because two fields are no longer initialized with the default arrays?
>
>> The reason this puzzles me is that the `readInt` benchmark don't involve the UTF code paths at all. So why would it become slower, just because two fields are no longer initialized with the default arrays?
> 
> Could there be some JIT optimizations not being possible because the fields are no longer 'never null'?

@eirbjo I've updated the PR so we hold zero-length arrays rather than null arrays. Please re-run your benchmark to see if there is any change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13121#issuecomment-1486338760

From jpai at openjdk.org  Tue Mar 28 07:36:33 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 28 Mar 2023 07:36:33 GMT
Subject: RFR: 8300977: Retire java.io.ExpiringCache [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 28 Mar 2023 06:55:26 GMT, Per Minborg  wrote:

>> This PR proposed to retire the class 'java.io.ExpiringCache'. The use of the class has been off by default since Java 16 but could be explicitly turned on by means of two System properties.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert change after comments

Hello Per, the changes look good to me.

I was a bit surprised that the PR didn't have any removal/changes of existing test cases, but looking in the repo I don't see any test using any of these system properties. So it appears that this code was never exercised in recent times.

Please wait for another review from someone with more experience in this area before integrating.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/12167#pullrequestreview-1360396191

From jpai at openjdk.org  Tue Mar 28 07:43:36 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 28 Mar 2023 07:43:36 GMT
Subject: RFR: 8300977: Retire java.io.ExpiringCache [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 28 Mar 2023 06:55:26 GMT, Per Minborg  wrote:

>> This PR proposed to retire the class 'java.io.ExpiringCache'. The use of the class has been off by default since Java 16 but could be explicitly turned on by means of two System properties.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert change after comments

src/java.base/windows/classes/java/io/WinNTFileSystem.java line 425:

> 423:         // Updates might not be visible to other threads so there
> 424:         // is no guarantee getDriveDirectory(i+1) is called just once
> 425:         // for any given value of i.

I found this comment a bit odd in this PR, since this isn't related to any changes in this PR and this behaviour has been this way even in mainline. I'm guessing this has been added just as an informational comment for future maintainers of this code to be aware of this detail; and that's fine with me.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12167#discussion_r1150157968

From jpai at openjdk.org  Tue Mar 28 07:54:33 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 28 Mar 2023 07:54:33 GMT
Subject: RFR: 8303214: Typo in
 java.util.Collections#synchronizedNavigableMap javadoc
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 9 Feb 2023 06:13:51 GMT, nbauma109  wrote:

>> I think this is a typo
>
> need help with progressing this pull request towards integration

Hello @nbauma109, this change is now ready to be merged. For that to happen, you will have to add an `/integrate` comment to this PR so that someone can the sponsor it for you.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/11679#issuecomment-1486380525

From asotona at openjdk.org  Tue Mar 28 08:03:34 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 28 Mar 2023 08:03:34 GMT
Subject: RFR: 8304425: ClassHierarchyResolver from Reflection [v5]
In-Reply-To: 
References: <08Hy6pEhV75yr_F4mCP-dkKOKMCSoFxWI2E7OnM4iyQ=.cfa14992-8e94-4d6d-bdf9-e6689549c83e@github.com>
 
Message-ID: <3AV6oWF8zzkRDvLRhnVej16Bbhf5qdt0hA59oDTshh8=.2ddc50c4-e0e1-4ec4-8dc9-e1d910d89f81@github.com>

On Mon, 27 Mar 2023 14:34:06 GMT, Chen Liang  wrote:

>> Add API to explore Class Hierarchy with a `ClassLoader` or a `Lookup` with proper privileges, with tests.
>> 
>> This addition is useful in case classes at runtime are not loaded from the system class loader, such as Proxy. This is also useful to APIs that generate bytecode with a `Lookup` object, such as a custom single-abstract-method class implementations from a method handle.
>> 
>> See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000249.html as well.
>> 
>> Current questions, which I wish to discuss with @asotona:
>> 1. Should the resolver fail fast on `IllegalAccessException` from the lookup? This usually indicates the hierarchy resolver is set up improperly, and proceeding may simply yield verification errors in class loading that are hard to track. For bytecode-generating APIs, throwing access errors for the Lookup eagerly is also more preferable than later silent generation failure.
>> 2. Whether the default resolver should be reading from jrt alone, reflection alone, or jrt then reflection. I personally believe reflection alone is more reliable, for classes may redefined with instrumentation or jfr, which may not be reflected in the system resources.
>> 3. In addition, I don't think chaining system class loader reflection after system resource retrieval is really meaningful: is there any case where reflection always works while the system resource retrieval always fails?
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update the class hierarchy resolver api as per mailing list last week

test/jdk/jdk/classfile/ClassHierarchyInfoTest.java line 93:

> 91:     void testProvideCustomClassStreamResolver() throws Exception {
> 92:         var fs = FileSystems.getFileSystem(URI.create("jrt:/"));
> 93:         transformAndVerify(ClassHierarchyResolver.ofParsing(classDesc -> {

Caching here is important, otherwise the class will be parsed again for each request.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13082#discussion_r1150186193

From asotona at openjdk.org  Tue Mar 28 08:11:35 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 28 Mar 2023 08:11:35 GMT
Subject: RFR: 8304425: ClassHierarchyResolver from Reflection [v5]
In-Reply-To: 
References: <08Hy6pEhV75yr_F4mCP-dkKOKMCSoFxWI2E7OnM4iyQ=.cfa14992-8e94-4d6d-bdf9-e6689549c83e@github.com>
 
Message-ID: 

On Mon, 27 Mar 2023 14:34:06 GMT, Chen Liang  wrote:

>> Add API to explore Class Hierarchy with a `ClassLoader` or a `Lookup` with proper privileges, with tests.
>> 
>> This addition is useful in case classes at runtime are not loaded from the system class loader, such as Proxy. This is also useful to APIs that generate bytecode with a `Lookup` object, such as a custom single-abstract-method class implementations from a method handle.
>> 
>> See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000249.html as well.
>> 
>> Current questions, which I wish to discuss with @asotona:
>> 1. Should the resolver fail fast on `IllegalAccessException` from the lookup? This usually indicates the hierarchy resolver is set up improperly, and proceeding may simply yield verification errors in class loading that are hard to track. For bytecode-generating APIs, throwing access errors for the Lookup eagerly is also more preferable than later silent generation failure.
>> 2. Whether the default resolver should be reading from jrt alone, reflection alone, or jrt then reflection. I personally believe reflection alone is more reliable, for classes may redefined with instrumentation or jfr, which may not be reflected in the system resources.
>> 3. In addition, I don't think chaining system class loader reflection after system resource retrieval is really meaningful: is there any case where reflection always works while the system resource retrieval always fails?
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update the class hierarchy resolver api as per mailing list last week

test/jdk/jdk/classfile/ClassHierarchyInfoTest.java line 126:

> 124:     }
> 125: 
> 126:     void transformAndVerify(ClassHierarchyResolver res) throws Exception {

It might be useful to cache any provided resolver.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13082#discussion_r1150196054

From pminborg at openjdk.org  Tue Mar 28 08:13:31 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 28 Mar 2023 08:13:31 GMT
Subject: RFR: 8300979: Lazily initialize (byte,
 char)arr in java.io.DataInputStream [v5]
In-Reply-To: 
References: 
Message-ID: 

> This PR proposed to lazily initialize the scratch arrays only if/when needed.

Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:

 - Merge branch 'master' into dis-lazy
 - Use zero-lenght arrays rather than null
 - Merge branch 'dis-lazy' of https://github.com/minborg/jdk into dis-lazy
 - Update src/java.base/share/classes/java/io/DataInputStream.java
   
   Co-authored-by: Eirik Bjorsnos 
 - Merge branch 'master' into dis-lazy
 - Remove redundant initilizers
 - Lazily initialize (byte, char)arr in java.io.DataInputStream

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13121/files
  - new: https://git.openjdk.org/jdk/pull/13121/files/ca165dfa..3b1257cc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13121&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13121&range=03-04

  Stats: 12655 lines in 339 files changed: 4774 ins; 5523 del; 2358 mod
  Patch: https://git.openjdk.org/jdk/pull/13121.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13121/head:pull/13121

PR: https://git.openjdk.org/jdk/pull/13121

From pminborg at openjdk.org  Tue Mar 28 08:13:34 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 28 Mar 2023 08:13:34 GMT
Subject: RFR: 8300979: Lazily initialize (byte,
 char)arr in java.io.DataInputStream [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 28 Mar 2023 07:21:15 GMT, Per Minborg  wrote:

>> This PR proposed to lazily initialize the scratch arrays only if/when needed.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use zero-lenght arrays rather than null

With the new non-null proposal and on my Mac M1, I get:

Baseline:

Benchmark                     Mode  Cnt  Score   Error  Units
DataInputStreamTest.readChar  avgt   20  5.077 ? 0.052  us/op
DataInputStreamTest.readInt   avgt   20  2.630 ? 0.014  us/op


PR (updated version):

Benchmark                     Mode  Cnt  Score   Error  Units
DataInputStreamTest.readChar  avgt   20  5.052 ? 0.028  us/op
DataInputStreamTest.readInt   avgt   20  2.615 ? 0.022  us/op


So, on my platform, the performance is unchanged.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13121#issuecomment-1486399781

From jpai at openjdk.org  Tue Mar 28 08:14:26 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 28 Mar 2023 08:14:26 GMT
Subject: RFR: 8304989: unnecessary dash in @param gives double-dash in docs
Message-ID: <2HdD4m85fiWtDb2iFX1hNHzAfv8rlmlLzTNu8zAcMpI=.baba4ae9-cba9-4262-9799-dd6a012e3075@github.com>

Can I please get a review of this trivial doc-only change that addresses https://bugs.openjdk.org/browse/JDK-8304989?

I ran `make docs-image` with this change and the generated javadocs look fine.

-------------

Commit messages:
 - 8304989: unnecessary dash in @param gives double-dash in docs

Changes: https://git.openjdk.org/jdk/pull/13204/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13204&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304989
  Stats: 8 lines in 3 files changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/13204.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13204/head:pull/13204

PR: https://git.openjdk.org/jdk/pull/13204

From sgehwolf at openjdk.org  Tue Mar 28 08:51:32 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 28 Mar 2023 08:51:32 GMT
Subject: RFR: 8304871: Use default visibility for static library builds
 [v2]
In-Reply-To: 
References: 
 
 
Message-ID: <45tCxmdpLp-KXAgMJdhgqkTlEIgerKTAcfRW29zwwKQ=.3d143acd-ed1b-406f-b723-38be0ddfa39e@github.com>

On Tue, 28 Mar 2023 04:40:24 GMT, David Holmes  wrote:

> I also added this to JBS:
> 
> JDK-8239563 was also done to support Graal, and this change is now undoing that. Do the Graal folk who want this understand it will restore the problem that JDK-8239563 fixed?

I have no insight as to why JDK-8239563 was done. It could be that it was done at at time where awt wasn't anything supported. The gist of this change is aligning with labs openjdk. Anyway, I've added this comment to the bug for your information:

https://bugs.openjdk.org/browse/JDK-8304871?focusedCommentId=14569960&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14569960

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13177#issuecomment-1486460694

From duke at openjdk.org  Tue Mar 28 08:51:46 2023
From: duke at openjdk.org (nbauma109)
Date: Tue, 28 Mar 2023 08:51:46 GMT
Subject: Integrated: 8303214: Typo in
 java.util.Collections#synchronizedNavigableMap javadoc
In-Reply-To: 
References: 
Message-ID: 

On Wed, 14 Dec 2022 17:43:08 GMT, nbauma109  wrote:

> I think this is a typo

This pull request has now been integrated.

Changeset: a06f4619
Author:    nbauma109 
Committer: Andrey Turbanov 
URL:       https://git.openjdk.org/jdk/commit/a06f46196afd015db300ecf10bbb2a309b74e9d8
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8303214: Typo in java.util.Collections#synchronizedNavigableMap javadoc

Reviewed-by: martin, smarks, aturbanov

-------------

PR: https://git.openjdk.org/jdk/pull/11679

From lancea at openjdk.org  Tue Mar 28 10:03:32 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 28 Mar 2023 10:03:32 GMT
Subject: RFR: 8304989: unnecessary dash in @param gives double-dash in docs
In-Reply-To: <2HdD4m85fiWtDb2iFX1hNHzAfv8rlmlLzTNu8zAcMpI=.baba4ae9-cba9-4262-9799-dd6a012e3075@github.com>
References: <2HdD4m85fiWtDb2iFX1hNHzAfv8rlmlLzTNu8zAcMpI=.baba4ae9-cba9-4262-9799-dd6a012e3075@github.com>
Message-ID: 

On Tue, 28 Mar 2023 08:06:48 GMT, Jaikiran Pai  wrote:

> Can I please get a review of this trivial doc-only change that addresses https://bugs.openjdk.org/browse/JDK-8304989?
> 
> I ran `make docs-image` with this change and the generated javadocs look fine.

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13204#pullrequestreview-1360674266

From pminborg at openjdk.org  Tue Mar 28 10:03:37 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 28 Mar 2023 10:03:37 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v8]
In-Reply-To: 
References: 
 <4JIhKmX2VnDfArfFl-1YJfoUzGGBVA5Uvd3mdpatW-s=.5d86f29e-5475-4a4a-91df-d6418356e204@github.com>
 
Message-ID: 

On Fri, 24 Mar 2023 08:35:06 GMT, ExE Boss  wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve javadocs for Linker::captureStateLayout
>
> src/java.base/share/classes/jdk/internal/foreign/abi/SharedUtils.java line 297:
> 
>> 295:         MethodType mtype = mh.type();
>> 296:         int[] perms = new int[mtype.parameterCount()];
>> 297:         MethodType swappedType = MethodType.methodType(mtype.returnType());
> 
> Instead?of `MethodType::appendParameterTypes(?)` (which?performs an?expensive?lookup of?a?new?cached `MethodType` value per?call), this?method should?instead use?a?`Class[]` for?the?arguments, which?avoids that?overhead inside?a?loop:
> 
> 	public static MethodHandle swapArguments(MethodHandle mh, int firstArg, int secondArg) {
> 		MethodType mtype = mh.type();
> 		int[] perms = new int[mtype.parameterCount()];
> 		Class[] ptypes = new Class[perms.length];
> 		for (int i = 0 ; i < perms.length ; i++) {
> 			int dst = i;
> 			if (i == firstArg) dst = secondArg;
> 			else if (i == secondArg) dst = firstArg;
> 			perms[i] = dst;
> 			ptypes[i] = mtype.parameterType(dst);
> 		}
> 		// This should use `JavaLangInvokeAccess` to invoke the internal
> 		// `MethodType.methodType(Class rtype, Class[] ptypes, boolean trusted)`
> 		// method with a `trusted` value of `true`:
> 		MethodType swappedType = MethodType.methodType(mtype.returnType(), ptypes);
> 		return permuteArguments(mh, swappedType, perms);
> 	}

Thanks for this enhancement proposal. I hope you do not mind me asking if you could file a separate issue about this where you describe the above? We can then merge that proposal independent of this PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1150341545

From pminborg at openjdk.org  Tue Mar 28 10:15:13 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 28 Mar 2023 10:15:13 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v9]
In-Reply-To: 
References: 
Message-ID: 

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

Per Minborg has updated the pull request incrementally with eight additional commits since the last revision:

 - Make fallbacklinker.c consistent with downcallLinker.cpp
 - Add bug number
 - Use @return
 - Update Linker.downcallHandle() javadoc
 - Fix typos in Arena
 - Make checking method handle zero case
 - Add snippet to Linker.Option.captureStateLayout()
 - Apply RISCV port patch

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13079/files
  - new: https://git.openjdk.org/jdk/pull/13079/files/6df28a78..3dab13da

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=07-08

  Stats: 125 lines in 13 files changed: 39 ins; 20 del; 66 mod
  Patch: https://git.openjdk.org/jdk/pull/13079.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13079/head:pull/13079

PR: https://git.openjdk.org/jdk/pull/13079

From pminborg at openjdk.org  Tue Mar 28 10:15:19 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 28 Mar 2023 10:15:19 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v8]
In-Reply-To: 
References: 
 <4JIhKmX2VnDfArfFl-1YJfoUzGGBVA5Uvd3mdpatW-s=.5d86f29e-5475-4a4a-91df-d6418356e204@github.com>
 
Message-ID: <82NY-GyOk1U9SLOqfPdRjwT_ypxKVEJx0JItDO0VXik=.5b5c7184-6d6d-4627-8803-03461a2297bc@github.com>

On Fri, 24 Mar 2023 08:42:37 GMT, ExE Boss  wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve javadocs for Linker::captureStateLayout
>
> src/java.base/share/classes/jdk/internal/foreign/abi/fallback/LibFallback.java line 61:
> 
>> 59:     static final MemorySegment VOID_TYPE = MemorySegment.ofAddress(ffi_type_void());
>> 60:     static final short STRUCT_TAG = ffi_type_struct();
>> 61:     private static final long SIZEOF_CIF = sizeofCif();
> 
> Won?t?calling `ffi_default_abi()` (and?the?other `ffi_*()`?methods) throw?`UnsatisfiedLinkError` if?`SUPPORTED`?is?`false`?

I think so too. How do we guard agains this @JornVernee ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1150350299

From redestad at openjdk.org  Tue Mar 28 10:51:38 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 28 Mar 2023 10:51:38 GMT
Subject: RFR: JDK-8302323 Add repeat methods to StringBuilder/StringBuffer
 [v10]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 27 Mar 2023 18:37:12 GMT, Jim Laskey  wrote:

>> Add the ability to repeatedly append char and CharSequence data to StringBuilder/StringBuffer.
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use Arrays.fill

test/jdk/java/lang/StringBuilder/StringBuilderRepeat.java line 180:

> 178: 
> 179:         try {
> 180:             sb.repeat(0x10FFFF + 1, -1);

Should these tests that test invalid codepoints use a valid repeat count as to verify the IAE is correctly thrown for the out-of-bound codepoint? Tests where both params are illegal are fine, too, of course.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12728#discussion_r1150396671

From alanb at openjdk.org  Tue Mar 28 10:52:41 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 28 Mar 2023 10:52:41 GMT
Subject: RFR: 8300977: Retire java.io.ExpiringCache [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 28 Mar 2023 06:55:26 GMT, Per Minborg  wrote:

>> This PR proposed to retire the class 'java.io.ExpiringCache'. The use of the class has been off by default since Java 16 but could be explicitly turned on by means of two System properties.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert change after comments

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/12167#pullrequestreview-1360760097

From redestad at openjdk.org  Tue Mar 28 10:54:47 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 28 Mar 2023 10:54:47 GMT
Subject: RFR: JDK-8302323 Add repeat methods to StringBuilder/StringBuffer
 [v10]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 27 Mar 2023 18:37:12 GMT, Jim Laskey  wrote:

>> Add the ability to repeatedly append char and CharSequence data to StringBuilder/StringBuffer.
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use Arrays.fill

Looks ok. I don't have a strong opinion on insert-repeat. 

I think tests that check for illegal code points should use a legal repeat value.

-------------

Marked as reviewed by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/12728#pullrequestreview-1360764390

From alanb at openjdk.org  Tue Mar 28 10:55:41 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 28 Mar 2023 10:55:41 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads
Message-ID: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>

JEP 444 proposes to make virtual threads a permanent feature in Java 21. The APIs that were preview APIs in Java 19/20 are changed to permanent and their `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The JNI and JVMTI versions are bumped as this is the first change in 21 to need the new version number. A lot of tests are updated to drop `@enablePreview` and --enable-preview.

There is one API change from Java 19/20, the preview API Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an update to the JVMTI GetThreadInfo implementation to read the TCCL consistently.

In addition, there are a small number of implementation changes to sync up from the loom fibers branch:

- A number of stack frames are `@Hidden` to reduce noise in the stack traces. This exposed a few issues with the stack walker code. More specifically, the cases where  end of a continuation falls precisely at the end of the batch, or where the remaining frames are hidden, weren't handled correctly.
- The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in Thread rather than in two classes.
- A few robustness improvements for OOME and SOE. There is more to do here, for future PRs.
- New system property to print a trace dump when virtual thread sets its own value of a TL.
- ThreadPerTaskExecutor is changed to use FutureTask.

Testing: tier1-6.

-------------

Commit messages:
 - Merge
 - Initial sync from fibers branch

Changes: https://git.openjdk.org/jdk/pull/13203/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13203&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304919
  Stats: 1964 lines in 198 files changed: 698 ins; 760 del; 506 mod
  Patch: https://git.openjdk.org/jdk/pull/13203.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13203/head:pull/13203

PR: https://git.openjdk.org/jdk/pull/13203

From pminborg at openjdk.org  Tue Mar 28 10:56:07 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 28 Mar 2023 10:56:07 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v10]
In-Reply-To: 
References: 
Message-ID: <_n0HMK1noQxNPICydcCIuSNqJfKIxLHO8S5_lAivyy4=.794689fc-f8e9-4582-8e24-82503ed1073b@github.com>

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:

 - Merge with master
 - Make fallbacklinker.c consistent with downcallLinker.cpp
 - Add bug number
 - Use @return
 - Update Linker.downcallHandle() javadoc
 - Fix typos in Arena
 - Make checking method handle zero case
 - Add snippet to Linker.Option.captureStateLayout()
 - Apply RISCV port patch
 - Improve javadocs for Linker::captureStateLayout
 - ... and 12 more: https://git.openjdk.org/jdk/compare/cddaf686...bc29c6fc

-------------

Changes: https://git.openjdk.org/jdk/pull/13079/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=09
  Stats: 13027 lines in 267 files changed: 5006 ins; 6015 del; 2006 mod
  Patch: https://git.openjdk.org/jdk/pull/13079.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13079/head:pull/13079

PR: https://git.openjdk.org/jdk/pull/13079

From alanb at openjdk.org  Tue Mar 28 10:56:57 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 28 Mar 2023 10:56:57 GMT
Subject: RFR: 8300979: Lazily initialize (byte,
 char)arr in java.io.DataInputStream [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 28 Mar 2023 08:13:31 GMT, Per Minborg  wrote:

>> This PR proposed to lazily initialize the scratch arrays only if/when needed.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge branch 'master' into dis-lazy
>  - Use zero-lenght arrays rather than null
>  - Merge branch 'dis-lazy' of https://github.com/minborg/jdk into dis-lazy
>  - Update src/java.base/share/classes/java/io/DataInputStream.java
>    
>    Co-authored-by: Eirik Bjorsnos 
>  - Merge branch 'master' into dis-lazy
>  - Remove redundant initilizers
>  - Lazily initialize (byte, char)arr in java.io.DataInputStream

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13121#pullrequestreview-1360767352

From alanb at openjdk.org  Tue Mar 28 11:00:10 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 28 Mar 2023 11:00:10 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v16]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 28 Mar 2023 06:28:17 GMT, Jaikiran Pai  wrote:

>> Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8206890?
>> 
>> The `jlink` command allows a `--endian` option to specify the byte order in the generated image. Before this change, when such a image was being launched, the code would assume the byte order in the image to be the native order of the host where the image is being launched. That would result in failure to launch java, as noted in the linked issue.
>> 
>> The commit in this PR, changes relevant places to not assume native order and instead determine the byte order by reading the magic bytes in the image file's header content.
>> 
>> A new jtreg test has been added which reproduces the issue and verifies the fix.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use test.jdk system property in test

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Platform.java line 39:

> 37:  */
> 38: public record Platform(OperatingSystem os, Architecture arch, ByteOrder endianness) {
> 39:     private static final Properties KNOWN_ENDIANNESS;

I assume this should be renamed to something like PLATFORM_PROPERTIES as the properties are not specific to endianness now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/11943#discussion_r1150405901

From forax at openjdk.org  Tue Mar 28 11:01:10 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Tue, 28 Mar 2023 11:01:10 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion
In-Reply-To: 
References: 
Message-ID: 

On Mon, 27 Mar 2023 23:34:52 GMT, Chen Liang  wrote:

> As John Rose has pointed out in this issue, the current j.l.r.Proxy based implementation of MethodHandleProxies.asInterface has a few issues:
> 1. Exposes too much information via Proxy supertype (and WrapperInstance interface)
> 2. Does not allow future expansion to support SAM[^1] abstract classes
> 3. Slow (in fact, very slow)
> 
> This patch addresses all 3 problems:
> 1. It implements proxies with one hidden class for each requested interface and replaced WrapperInstance inheritance with an annotation. This can avoid unexpected passing of `instanceof`, and avoids the nasty problem of exporting a JDK interface to a dynamic module to ensure access.
> 2. This patch obtains already generated classes from a ClassValue by the requested interface type; the ClassValue can later be updated to compute implementation generation for abstract classes as well.
> 3. This patch's generated hidden classes has acceptable call and creation performance compared to the baseline; though the methods to access wrapper information see huge performance drops, they are not anticipated to be used in a very frequent basis, while the old implementation's wrapper access methods are more optimized (2ns/op) than interface implementation methods (6ns/op). [Oracle JDK 20 vs this](https://jmh.morethan.io/?gists=bf98de7b2128e7e5d14e697fd9921eb9,e5115a2a8fa0a45159e15fab0d95b5d8)
> 
> Additionally, an obsolete `ProxyForMethodHandle` test was removed, for it's no longer applicable. Tests in `jdk/java/lang/invoke` and `jdk/java/lang/reflect` pass.
> 
> Alternative implementation:
> [An alternative implementation](https://github.com/openjdk/jdk/commit/72dbf9d4e01c455854d9b865cb2a47c38f37a8e0) was to generate a proxy class for each methodhandle than sharing across methodhandles. That implementation was abandoned for its bad proxy creation performance, despite it having excellent call performance. [Alternative implementation vs this](https://jmh.morethan.io/?gists=08abb39f224574550925beb8be1b2f59,e5115a2a8fa0a45159e15fab0d95b5d8)
> 
> In addition, I have a question: in [8161245](https://bugs.openjdk.org/browse/JDK-8161245) it seems some fields can be optimized as seen in [ciField.cpp](https://github.com/openjdk/jdk/blob/6aec6f3a842ead30b26cd31dc57a2ab268f67875/src/hotspot/share/ci/ciField.cpp#L219). Does it affect the execution performance of MethodHandle in hidden classes' Condy vs. MethodHandle in regular final field in hidden classes?
> 
> [^1]: single abstract method

src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 206:

> 204:         try {
> 205:             proxy = (Object) info.ctor.invokeExact(mhs); // non-varargs
> 206:         } catch (Throwable e) {

At least Error should be directly propagated (especially OutOfMemoryError)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1150405757

From pminborg at openjdk.org  Tue Mar 28 11:02:38 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 28 Mar 2023 11:02:38 GMT
Subject: Integrated: 8300979: Lazily initialize (byte,
 char)arr in java.io.DataInputStream
In-Reply-To: 
References: 
Message-ID: 

On Tue, 21 Mar 2023 15:41:13 GMT, Per Minborg  wrote:

> This PR proposed to lazily initialize the scratch arrays only if/when needed.

This pull request has now been integrated.

Changeset: 60640a21
Author:    Per Minborg 
URL:       https://git.openjdk.org/jdk/commit/60640a216d65b89a3421625ae088823e0d478267
Stats:     6 lines in 1 file changed: 3 ins; 0 del; 3 mod

8300979: Lazily initialize (byte, char)arr in java.io.DataInputStream

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/13121

From mcimadamore at openjdk.org  Tue Mar 28 11:03:39 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 28 Mar 2023 11:03:39 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v10]
In-Reply-To: <_n0HMK1noQxNPICydcCIuSNqJfKIxLHO8S5_lAivyy4=.794689fc-f8e9-4582-8e24-82503ed1073b@github.com>
References: 
 <_n0HMK1noQxNPICydcCIuSNqJfKIxLHO8S5_lAivyy4=.794689fc-f8e9-4582-8e24-82503ed1073b@github.com>
Message-ID: 

On Tue, 28 Mar 2023 10:56:07 GMT, Per Minborg  wrote:

>> API changes for the FFM API (third preview)
>> 
>> Specdiff:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
>> 
>> Javadoc:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
> 
>  - Merge with master
>  - Make fallbacklinker.c consistent with downcallLinker.cpp
>  - Add bug number
>  - Use @return
>  - Update Linker.downcallHandle() javadoc
>  - Fix typos in Arena
>  - Make checking method handle zero case
>  - Add snippet to Linker.Option.captureStateLayout()
>  - Apply RISCV port patch
>  - Improve javadocs for Linker::captureStateLayout
>  - ... and 12 more: https://git.openjdk.org/jdk/compare/cddaf686...bc29c6fc

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 2310:

> 2308:         /**
> 2309:          * {@return {@code true}, if the provided object is also a scope, which models the same lifetime as that
> 2310:          * modelled by this scope}. In that case, it is always the case that

This brace (after `scope`) seems spurious?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1150408522

From alanb at openjdk.org  Tue Mar 28 11:06:06 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 28 Mar 2023 11:06:06 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v16]
In-Reply-To: 
References: 
 
Message-ID: <_X148gAz795J-ExMjOAyvrykzc7a9vLdqg9pY2EaHKo=.40e38e68-013b-436e-bab0-933208fe4242@github.com>

On Tue, 28 Mar 2023 06:28:17 GMT, Jaikiran Pai  wrote:

>> Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8206890?
>> 
>> The `jlink` command allows a `--endian` option to specify the byte order in the generated image. Before this change, when such a image was being launched, the code would assume the byte order in the image to be the native order of the host where the image is being launched. That would result in failure to launch java, as noted in the linked issue.
>> 
>> The commit in this PR, changes relevant places to not assume native order and instead determine the byte order by reading the magic bytes in the image file's header content.
>> 
>> A new jtreg test has been added which reproduces the issue and verifies the fix.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use test.jdk system property in test

test/jdk/tools/jlink/plugins/CDSPluginTest.java line 93:

> 91:            System.out.println("---- Test different platforms scenario ----");
> 92:            String jlinkPath = JDKToolFinder.getJDKTool("jlink");
> 93:            // copy over the java.base and java.logging module file to a temporary directory

This should say that it copies the packaged modules for java.base and java.logging.

test/jdk/tools/jlink/plugins/CDSPluginTest.java line 97:

> 95:            // separate --module-path will force the JLink task to read the ModuleTarget from
> 96:            // the java.base module-info.class to identify the target platform for the image
> 97:            // being generated.

I'm a bit uncomfortable with change the test for the CDS plugin as part of this change but can live with it.

test/jdk/tools/jlink/plugins/CDSPluginTest.java line 125:

> 123:     }
> 124: 
> 125:     private static void copyModuleFiles(Path jdkRoot, Path targetDir, String[] modules)

This method copies "packaged modules" so I think should be renamed to copyPackagedModules.

test/jdk/tools/jlink/plugins/CDSPluginTest.java line 136:

> 134:             if (!Files.exists(copy)) {
> 135:                 throw new AssertionError("Could not copy '" + module
> 136:                         + "' module file to directory: " + targetDir);

Files.copy throws if it fails so no need for the Files.exists check here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/11943#discussion_r1150410251
PR Review Comment: https://git.openjdk.org/jdk/pull/11943#discussion_r1150411725
PR Review Comment: https://git.openjdk.org/jdk/pull/11943#discussion_r1150409630
PR Review Comment: https://git.openjdk.org/jdk/pull/11943#discussion_r1150409681

From forax at openjdk.org  Tue Mar 28 11:16:45 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Tue, 28 Mar 2023 11:16:45 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion
In-Reply-To: 
References: 
Message-ID: <4Q4X-8wnDv2zSCx8pYpqI1EqpANjh2WLzfuxqrFEJmI=.496b8ee6-cb44-4463-9deb-bec39b689fb4@github.com>

On Mon, 27 Mar 2023 23:34:52 GMT, Chen Liang  wrote:

> As John Rose has pointed out in this issue, the current j.l.r.Proxy based implementation of MethodHandleProxies.asInterface has a few issues:
> 1. Exposes too much information via Proxy supertype (and WrapperInstance interface)
> 2. Does not allow future expansion to support SAM[^1] abstract classes
> 3. Slow (in fact, very slow)
> 
> This patch addresses all 3 problems:
> 1. It implements proxies with one hidden class for each requested interface and replaced WrapperInstance inheritance with an annotation. This can avoid unexpected passing of `instanceof`, and avoids the nasty problem of exporting a JDK interface to a dynamic module to ensure access.
> 2. This patch obtains already generated classes from a ClassValue by the requested interface type; the ClassValue can later be updated to compute implementation generation for abstract classes as well.
> 3. This patch's generated hidden classes has acceptable call and creation performance compared to the baseline; though the methods to access wrapper information see huge performance drops, they are not anticipated to be used in a very frequent basis, while the old implementation's wrapper access methods are more optimized (2ns/op) than interface implementation methods (6ns/op). [Oracle JDK 20 vs this](https://jmh.morethan.io/?gists=bf98de7b2128e7e5d14e697fd9921eb9,e5115a2a8fa0a45159e15fab0d95b5d8)
> 
> Additionally, an obsolete `ProxyForMethodHandle` test was removed, for it's no longer applicable. Tests in `jdk/java/lang/invoke` and `jdk/java/lang/reflect` pass.
> 
> Alternative implementation:
> [An alternative implementation](https://github.com/openjdk/jdk/commit/72dbf9d4e01c455854d9b865cb2a47c38f37a8e0) was to generate a proxy class for each methodhandle than sharing across methodhandles. That implementation was abandoned for its bad proxy creation performance, despite it having excellent call performance. [Alternative implementation vs this](https://jmh.morethan.io/?gists=08abb39f224574550925beb8be1b2f59,e5115a2a8fa0a45159e15fab0d95b5d8)
> 
> In addition, I have a question: in [8161245](https://bugs.openjdk.org/browse/JDK-8161245) it seems some fields can be optimized as seen in [ciField.cpp](https://github.com/openjdk/jdk/blob/6aec6f3a842ead30b26cd31dc57a2ab268f67875/src/hotspot/share/ci/ciField.cpp#L219). Does it affect the execution performance of MethodHandle in hidden classes' Condy vs. MethodHandle in regular final field in hidden classes?
> 
> [^1]: single abstract method

I believe you can have better performance if you pass the method handle as the class data of the hidden class and you load it with a constant dynamic
  https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/lang/invoke/MethodHandles.Lookup.html#defineHiddenClassWithClassData(byte[],java.lang.Object,boolean,java.lang.invoke.MethodHandles.Lookup.ClassOption...)
and
  https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/lang/invoke/MethodHandles.html#classData(java.lang.invoke.MethodHandles.Lookup,java.lang.String,java.lang.Class)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13197#issuecomment-1486668297

From rgiulietti at openjdk.org  Tue Mar 28 11:57:33 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 28 Mar 2023 11:57:33 GMT
Subject: RFR: 8291598: Matcher.appendReplacement should not create new
 StringBuilder instances [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 15 Mar 2023 20:01:05 GMT, Raffaello Giulietti  wrote:

>> Remove instantiation of `StringBuilder`
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8291598: Matcher.appendReplacement should not create new StringBuilder instances
>   
>   Removed other allocations of StringBuilder when processing named groups in replacement string.

Waiting for other comments and review

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13048#issuecomment-1486727782

From jpai at openjdk.org  Tue Mar 28 12:05:47 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 28 Mar 2023 12:05:47 GMT
Subject: RFR: 8304989: unnecessary dash in @param gives double-dash in docs
In-Reply-To: <2HdD4m85fiWtDb2iFX1hNHzAfv8rlmlLzTNu8zAcMpI=.baba4ae9-cba9-4262-9799-dd6a012e3075@github.com>
References: <2HdD4m85fiWtDb2iFX1hNHzAfv8rlmlLzTNu8zAcMpI=.baba4ae9-cba9-4262-9799-dd6a012e3075@github.com>
Message-ID: 

On Tue, 28 Mar 2023 08:06:48 GMT, Jaikiran Pai  wrote:

> Can I please get a review of this trivial doc-only change that addresses https://bugs.openjdk.org/browse/JDK-8304989?
> 
> I ran `make docs-image` with this change and the generated javadocs look fine.

Thank you Lance for the review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13204#issuecomment-1486741616

From jpai at openjdk.org  Tue Mar 28 12:05:48 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 28 Mar 2023 12:05:48 GMT
Subject: Integrated: 8304989: unnecessary dash in @param gives double-dash in
 docs
In-Reply-To: <2HdD4m85fiWtDb2iFX1hNHzAfv8rlmlLzTNu8zAcMpI=.baba4ae9-cba9-4262-9799-dd6a012e3075@github.com>
References: <2HdD4m85fiWtDb2iFX1hNHzAfv8rlmlLzTNu8zAcMpI=.baba4ae9-cba9-4262-9799-dd6a012e3075@github.com>
Message-ID: <4O-0TCbRxzgpSUxZRjGupTBxMGmlya65sZz6WL2j2Hc=.8def790a-5085-424d-88af-ecb8bd6c4671@github.com>

On Tue, 28 Mar 2023 08:06:48 GMT, Jaikiran Pai  wrote:

> Can I please get a review of this trivial doc-only change that addresses https://bugs.openjdk.org/browse/JDK-8304989?
> 
> I ran `make docs-image` with this change and the generated javadocs look fine.

This pull request has now been integrated.

Changeset: c90699ea
Author:    Jaikiran Pai 
URL:       https://git.openjdk.org/jdk/commit/c90699eae7698481c10d10196e6199582f0c10aa
Stats:     8 lines in 3 files changed: 0 ins; 0 del; 8 mod

8304989: unnecessary dash in @param gives double-dash in docs

Reviewed-by: lancea

-------------

PR: https://git.openjdk.org/jdk/pull/13204

From jvernee at openjdk.org  Tue Mar 28 12:39:41 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 28 Mar 2023 12:39:41 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v10]
In-Reply-To: 
References: 
 <_n0HMK1noQxNPICydcCIuSNqJfKIxLHO8S5_lAivyy4=.794689fc-f8e9-4582-8e24-82503ed1073b@github.com>
 
Message-ID: 

On Tue, 28 Mar 2023 11:00:00 GMT, Maurizio Cimadamore  wrote:

>> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
>> 
>>  - Merge with master
>>  - Make fallbacklinker.c consistent with downcallLinker.cpp
>>  - Add bug number
>>  - Use @return
>>  - Update Linker.downcallHandle() javadoc
>>  - Fix typos in Arena
>>  - Make checking method handle zero case
>>  - Add snippet to Linker.Option.captureStateLayout()
>>  - Apply RISCV port patch
>>  - Improve javadocs for Linker::captureStateLayout
>>  - ... and 12 more: https://git.openjdk.org/jdk/compare/cddaf686...bc29c6fc
>
> src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 2310:
> 
>> 2308:         /**
>> 2309:          * {@return {@code true}, if the provided object is also a scope, which models the same lifetime as that
>> 2310:          * modelled by this scope}. In that case, it is always the case that
> 
> This brace (after `scope`) seems spurious?

It's to close the text span for the `{@return`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1150540008

From pminborg at openjdk.org  Tue Mar 28 13:06:07 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 28 Mar 2023 13:06:07 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v11]
In-Reply-To: 
References: 
Message-ID: 

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright years

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13079/files
  - new: https://git.openjdk.org/jdk/pull/13079/files/bc29c6fc..e7471d02

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=09-10

  Stats: 93 lines in 93 files changed: 0 ins; 0 del; 93 mod
  Patch: https://git.openjdk.org/jdk/pull/13079.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13079/head:pull/13079

PR: https://git.openjdk.org/jdk/pull/13079

From pminborg at openjdk.org  Tue Mar 28 13:14:09 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 28 Mar 2023 13:14:09 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v12]
In-Reply-To: 
References: 
Message-ID: 

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Fix copyrigth year issues

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13079/files
  - new: https://git.openjdk.org/jdk/pull/13079/files/e7471d02..24bea62e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=10-11

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13079.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13079/head:pull/13079

PR: https://git.openjdk.org/jdk/pull/13079

From pminborg at openjdk.org  Tue Mar 28 13:14:10 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 28 Mar 2023 13:14:10 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v10]
In-Reply-To: 
References: 
 <_n0HMK1noQxNPICydcCIuSNqJfKIxLHO8S5_lAivyy4=.794689fc-f8e9-4582-8e24-82503ed1073b@github.com>
 
 
Message-ID: 

On Tue, 28 Mar 2023 12:36:28 GMT, Jorn Vernee  wrote:

>> src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 2310:
>> 
>>> 2308:         /**
>>> 2309:          * {@return {@code true}, if the provided object is also a scope, which models the same lifetime as that
>>> 2310:          * modelled by this scope}. In that case, it is always the case that
>> 
>> This brace (after `scope`) seems spurious?
>
> It's to close the text span for the `{@return`

image

It belongs to the opening brace for `{@return`. Hard to see with other curls in between.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1150584776

From pminborg at openjdk.org  Tue Mar 28 13:14:10 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 28 Mar 2023 13:14:10 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v10]
In-Reply-To: 
References: 
 <_n0HMK1noQxNPICydcCIuSNqJfKIxLHO8S5_lAivyy4=.794689fc-f8e9-4582-8e24-82503ed1073b@github.com>
 
 
 
Message-ID: 

On Tue, 28 Mar 2023 13:08:22 GMT, Per Minborg  wrote:

>> It's to close the text span for the `{@return`
>
> image
> 
> It belongs to the opening brace for `{@return`. Hard to see with other curls in between.

I would have written:


{@return if the provided object ...


`true` seams redundant to me but I know this style is used within the JDK.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1150586639

From pminborg at openjdk.org  Tue Mar 28 13:18:23 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 28 Mar 2023 13:18:23 GMT
Subject: Integrated: 8300977: Retire java.io.ExpiringCache
In-Reply-To: 
References: 
Message-ID: 

On Tue, 24 Jan 2023 14:02:26 GMT, Per Minborg  wrote:

> This PR proposed to retire the class 'java.io.ExpiringCache'. The use of the class has been off by default since Java 16 but could be explicitly turned on by means of two System properties.

This pull request has now been integrated.

Changeset: 927e674c
Author:    Per Minborg 
URL:       https://git.openjdk.org/jdk/commit/927e674c12aa7965c63059b8f650d8f60156cefc
Stats:     441 lines in 6 files changed: 7 ins; 409 del; 25 mod

8300977: Retire java.io.ExpiringCache

Reviewed-by: alanb, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/12167

From liach at openjdk.org  Tue Mar 28 13:36:39 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 28 Mar 2023 13:36:39 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion
In-Reply-To: 
References: 
Message-ID: 

On Mon, 27 Mar 2023 23:34:52 GMT, Chen Liang  wrote:

> As John Rose has pointed out in this issue, the current j.l.r.Proxy based implementation of MethodHandleProxies.asInterface has a few issues:
> 1. Exposes too much information via Proxy supertype (and WrapperInstance interface)
> 2. Does not allow future expansion to support SAM[^1] abstract classes
> 3. Slow (in fact, very slow)
> 
> This patch addresses all 3 problems:
> 1. It implements proxies with one hidden class for each requested interface and replaced WrapperInstance inheritance with an annotation. This can avoid unexpected passing of `instanceof`, and avoids the nasty problem of exporting a JDK interface to a dynamic module to ensure access.
> 2. This patch obtains already generated classes from a ClassValue by the requested interface type; the ClassValue can later be updated to compute implementation generation for abstract classes as well.
> 3. This patch's generated hidden classes has acceptable call and creation performance compared to the baseline; though the methods to access wrapper information see huge performance drops, they are not anticipated to be used in a very frequent basis, while the old implementation's wrapper access methods are more optimized (2ns/op) than interface implementation methods (6ns/op). [Oracle JDK 20 vs this](https://jmh.morethan.io/?gists=bf98de7b2128e7e5d14e697fd9921eb9,e5115a2a8fa0a45159e15fab0d95b5d8)
> 
> Additionally, an obsolete `ProxyForMethodHandle` test was removed, for it's no longer applicable. Tests in `jdk/java/lang/invoke` and `jdk/java/lang/reflect` pass.
> 
> Alternative implementation:
> [An alternative implementation](https://github.com/openjdk/jdk/commit/72dbf9d4e01c455854d9b865cb2a47c38f37a8e0) was to generate a proxy class for each methodhandle than sharing across methodhandles. That implementation was abandoned for its bad proxy creation performance, despite it having excellent call performance. [Alternative implementation vs this](https://jmh.morethan.io/?gists=08abb39f224574550925beb8be1b2f59,e5115a2a8fa0a45159e15fab0d95b5d8)
> 
> In addition, I have a question: in [8161245](https://bugs.openjdk.org/browse/JDK-8161245) it seems some fields can be optimized as seen in [ciField.cpp](https://github.com/openjdk/jdk/blob/6aec6f3a842ead30b26cd31dc57a2ab268f67875/src/hotspot/share/ci/ciField.cpp#L219). Does it affect the execution performance of MethodHandle in hidden classes' Condy vs. MethodHandle in regular final field in hidden classes?
> 
> [^1]: single abstract method

> I believe you can have better performance if you pass the method handle as the class data of the hidden class and you load it with a constant dynamic [https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/lang/invoke/MethodHandles.Lookup.html#defineHiddenClassWithClassData(byte[],java.lang.Object,boolean,java.lang.invoke.MethodHandles.Lookup.ClassOption...)](https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/lang/invoke/MethodHandles.Lookup.html#defineHiddenClassWithClassData(byte%5B%5D,java.lang.Object,boolean,java.lang.invoke.MethodHandles.Lookup.ClassOption...)) and https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/lang/invoke/MethodHandles.html#classData(java.lang.invoke.MethodHandles.Lookup,java.lang.String,java.lang.Class)

With one class per method handle + classdata, you do have better performance for invocations, but the penalties on creation is insurmountable: [JMH results comparison](https://jmh.morethan.io/?gists=bf98de7b2128e7e5d14e697fd9921eb9,08abb39f224574550925beb8be1b2f59) between OracleJDK 20 and [my initial patch](https://github.com/openjdk/jdk/commit/72dbf9d4e01c455854d9b865cb2a47c38f37a8e0), implemented based on this idea

> EDIT: you may have to use invokedynamic instead of a ldc constant dynamic + invokeExact() because the interface can have several methods to implement due to bridge methods (inheritance + generics)

Since this API needs to call `asType` on the input method handle to perform input validation, I just decided to pass the validated method handles wholesale to the generated class, either as condy (initial patch) or constructor arguments.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13197#issuecomment-1486899719

From alanb at openjdk.org  Tue Mar 28 13:39:36 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 28 Mar 2023 13:39:36 GMT
Subject: RFR: 8205129: Remove java.lang.Compiler
In-Reply-To: 
References: 
Message-ID: 

On Sun, 19 Mar 2023 09:01:26 GMT, Eirik Bjorsnos  wrote:

> Please help review this PR which suggests we remove the class `java.lang.Compiler`. The class seems non-functional for a decade, and was terminally deprecated in Java 9. Time has come to let it go.

I think you should be able to finalize the CSR JDK-8304458.

I think it would be good to remove "java.compiler" from the list of standard properties (table in System.getProperties) in the same release.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13092#issuecomment-1486903863

From forax at openjdk.org  Tue Mar 28 13:41:36 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Tue, 28 Mar 2023 13:41:36 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion
In-Reply-To: 
References: 
Message-ID: 

On Mon, 27 Mar 2023 23:34:52 GMT, Chen Liang  wrote:

> As John Rose has pointed out in this issue, the current j.l.r.Proxy based implementation of MethodHandleProxies.asInterface has a few issues:
> 1. Exposes too much information via Proxy supertype (and WrapperInstance interface)
> 2. Does not allow future expansion to support SAM[^1] abstract classes
> 3. Slow (in fact, very slow)
> 
> This patch addresses all 3 problems:
> 1. It implements proxies with one hidden class for each requested interface and replaced WrapperInstance inheritance with an annotation. This can avoid unexpected passing of `instanceof`, and avoids the nasty problem of exporting a JDK interface to a dynamic module to ensure access.
> 2. This patch obtains already generated classes from a ClassValue by the requested interface type; the ClassValue can later be updated to compute implementation generation for abstract classes as well.
> 3. This patch's generated hidden classes has acceptable call and creation performance compared to the baseline; though the methods to access wrapper information see huge performance drops, they are not anticipated to be used in a very frequent basis, while the old implementation's wrapper access methods are more optimized (2ns/op) than interface implementation methods (6ns/op). [Oracle JDK 20 vs this](https://jmh.morethan.io/?gists=bf98de7b2128e7e5d14e697fd9921eb9,e5115a2a8fa0a45159e15fab0d95b5d8)
> 
> Additionally, an obsolete `ProxyForMethodHandle` test was removed, for it's no longer applicable. Tests in `jdk/java/lang/invoke` and `jdk/java/lang/reflect` pass.
> 
> Alternative implementation:
> [An alternative implementation](https://github.com/openjdk/jdk/commit/72dbf9d4e01c455854d9b865cb2a47c38f37a8e0) was to generate a proxy class for each methodhandle than sharing across methodhandles. That implementation was abandoned for its bad proxy creation performance, despite it having excellent call performance. [Alternative implementation vs this](https://jmh.morethan.io/?gists=08abb39f224574550925beb8be1b2f59,e5115a2a8fa0a45159e15fab0d95b5d8)
> 
> In addition, I have a question: in [8161245](https://bugs.openjdk.org/browse/JDK-8161245) it seems some fields can be optimized as seen in [ciField.cpp](https://github.com/openjdk/jdk/blob/6aec6f3a842ead30b26cd31dc57a2ab268f67875/src/hotspot/share/ci/ciField.cpp#L219). Does it affect the execution performance of MethodHandle in hidden classes' Condy vs. MethodHandle in regular final field in hidden classes?
> 
> [^1]: single abstract method

Let suppose you have an interface like:

interface StringConsumer extends Consumer {}


The implementation needs to override both accept(Object) and accept(String).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13197#issuecomment-1486908491

From jvernee at openjdk.org  Tue Mar 28 13:53:27 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 28 Mar 2023 13:53:27 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v8]
In-Reply-To: <82NY-GyOk1U9SLOqfPdRjwT_ypxKVEJx0JItDO0VXik=.5b5c7184-6d6d-4627-8803-03461a2297bc@github.com>
References: 
 <4JIhKmX2VnDfArfFl-1YJfoUzGGBVA5Uvd3mdpatW-s=.5d86f29e-5475-4a4a-91df-d6418356e204@github.com>
 
 <82NY-GyOk1U9SLOqfPdRjwT_ypxKVEJx0JItDO0VXik=.5b5c7184-6d6d-4627-8803-03461a2297bc@github.com>
Message-ID: 

On Tue, 28 Mar 2023 10:07:12 GMT, Per Minborg  wrote:

>> src/java.base/share/classes/jdk/internal/foreign/abi/fallback/LibFallback.java line 61:
>> 
>>> 59:     static final MemorySegment VOID_TYPE = MemorySegment.ofAddress(ffi_type_void());
>>> 60:     static final short STRUCT_TAG = ffi_type_struct();
>>> 61:     private static final long SIZEOF_CIF = sizeofCif();
>> 
>> Won?t?calling `ffi_default_abi()` (and?the?other `ffi_*()`?methods) throw?`UnsatisfiedLinkError` if?`SUPPORTED`?is?`false`?
>
> I think so too. How do we guard agains this @JornVernee ?

You're right. Fix here: https://github.com/minborg/jdk/pull/1

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1150645955

From jvernee at openjdk.org  Tue Mar 28 13:53:29 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 28 Mar 2023 13:53:29 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v12]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 28 Mar 2023 13:14:09 GMT, Per Minborg  wrote:

>> API changes for the FFM API (third preview)
>> 
>> Specdiff:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
>> 
>> Javadoc:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyrigth year issues

src/java.base/share/classes/jdk/internal/vm/ForeignLinkerSupport.java line 52:

> 50:         }
> 51:     }
> 52: 

I also noticed that this method is not used and can be removed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1150647849

From jvernee at openjdk.org  Tue Mar 28 14:03:15 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 28 Mar 2023 14:03:15 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion
In-Reply-To: 
References: 
 
Message-ID: <6N1wKps-M239ceVuAojyvUIc-HjAEhcMLhxB6-jlkwI=.fc4f560f-9e98-4688-98a2-187e4f3f8758@github.com>

On Tue, 28 Mar 2023 13:34:05 GMT, Chen Liang  wrote:

> 



> > I believe you can have better performance if you pass the method handle as the class data of the hidden class and you load it with a constant dynamic [https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/lang/invoke/MethodHandles.Lookup.html#defineHiddenClassWithClassData(byte[],java.lang.Object,boolean,java.lang.invoke.MethodHandles.Lookup.ClassOption...)](https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/lang/invoke/MethodHandles.Lookup.html#defineHiddenClassWithClassData(byte%5B%5D,java.lang.Object,boolean,java.lang.invoke.MethodHandles.Lookup.ClassOption...)) and https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/lang/invoke/MethodHandles.html#classData(java.lang.invoke.MethodHandles.Lookup,java.lang.String,java.lang.Class)
> 
> With one class per method handle + classdata, you do have better performance for invocations, but the penalties on creation is insurmountable: [JMH results comparison](https://jmh.morethan.io/?gists=bf98de7b2128e7e5d14e697fd9921eb9,08abb39f224574550925beb8be1b2f59) between OracleJDK 20 and [my initial patch](https://github.com/openjdk/jdk/commit/72dbf9d4e01c455854d9b865cb2a47c38f37a8e0), implemented based on this idea

But this doesn't implement the same ClassValue cache. And spinning byte code can indeed be slow (I've seen this in other profiles).

I think it should be possible to spin the class bytes once, stick the result in a `ClassValue` cache, but then use the bytes to define multiple classes with different class data (MethodHandles).

Also, it would be nice if you could include the benchmarks you used in the patch as well.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13197#issuecomment-1486950348

From mcimadamore at openjdk.org  Tue Mar 28 14:11:51 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 28 Mar 2023 14:11:51 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v10]
In-Reply-To: 
References: 
 <_n0HMK1noQxNPICydcCIuSNqJfKIxLHO8S5_lAivyy4=.794689fc-f8e9-4582-8e24-82503ed1073b@github.com>
 
 
 
 
Message-ID: <2k3-c9kKwEOuBAu-fO4a1xSmATAR3kGECTYUQafoSy4=.1ed80abc-a8ae-4151-bcfa-52cdd2855ead@github.com>

On Tue, 28 Mar 2023 13:09:45 GMT, Per Minborg  wrote:

>> image
>> 
>> It belongs to the opening brace for `{@return`. Hard to see with other curls in between.
>
> I would have written:
> 
> 
> {@return if the provided object ...
> 
> 
> `true` seams redundant to me but I know this style is used within the JDK.

Whoops - thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1150685611

From jvernee at openjdk.org  Tue Mar 28 14:18:54 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 28 Mar 2023 14:18:54 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion
In-Reply-To: 
References: 
Message-ID: 

On Mon, 27 Mar 2023 23:34:52 GMT, Chen Liang  wrote:

> As John Rose has pointed out in this issue, the current j.l.r.Proxy based implementation of MethodHandleProxies.asInterface has a few issues:
> 1. Exposes too much information via Proxy supertype (and WrapperInstance interface)
> 2. Does not allow future expansion to support SAM[^1] abstract classes
> 3. Slow (in fact, very slow)
> 
> This patch addresses all 3 problems:
> 1. It implements proxies with one hidden class for each requested interface and replaced WrapperInstance inheritance with an annotation. This can avoid unexpected passing of `instanceof`, and avoids the nasty problem of exporting a JDK interface to a dynamic module to ensure access.
> 2. This patch obtains already generated classes from a ClassValue by the requested interface type; the ClassValue can later be updated to compute implementation generation for abstract classes as well.
> 3. This patch's generated hidden classes has acceptable call and creation performance compared to the baseline; though the methods to access wrapper information see huge performance drops, they are not anticipated to be used in a very frequent basis, while the old implementation's wrapper access methods are more optimized (2ns/op) than interface implementation methods (6ns/op). [Oracle JDK 20 vs this](https://jmh.morethan.io/?gists=bf98de7b2128e7e5d14e697fd9921eb9,e5115a2a8fa0a45159e15fab0d95b5d8)
> 
> Additionally, an obsolete `ProxyForMethodHandle` test was removed, for it's no longer applicable. Tests in `jdk/java/lang/invoke` and `jdk/java/lang/reflect` pass.
> 
> Alternative implementation:
> [An alternative implementation](https://github.com/openjdk/jdk/commit/72dbf9d4e01c455854d9b865cb2a47c38f37a8e0) was to generate a proxy class for each methodhandle than sharing across methodhandles. That implementation was abandoned for its bad proxy creation performance, despite it having excellent call performance. [Alternative implementation vs this](https://jmh.morethan.io/?gists=08abb39f224574550925beb8be1b2f59,e5115a2a8fa0a45159e15fab0d95b5d8)
> 
> In addition, I have a question: in [8161245](https://bugs.openjdk.org/browse/JDK-8161245) it seems some fields can be optimized as seen in [ciField.cpp](https://github.com/openjdk/jdk/blob/6aec6f3a842ead30b26cd31dc57a2ab268f67875/src/hotspot/share/ci/ciField.cpp#L219). Does it affect the execution performance of MethodHandle in hidden classes' Condy vs. MethodHandle in regular final field in hidden classes?
> 
> [^1]: single abstract method

Also, some history.

- I've worked on something similar before: https://bugs.openjdk.org/browse/JDK-8257605 The idea then was to add a new API in `MethodHandles` but since then I've been thinking that enhancing the performance of `MethodHandleProxies` might be better. The only issue I saw with that is that the current API doesn't accept a `MethodHandles.Lookup` object which would be needed to define an interface instance if the interface is in a non-exported package. Your solution just creates the lookup directly. Typically we have to be careful with injecting classes into other packages/modules since it can lead to access escalation, but maybe in this case it is fine. I don't think there's a way that this could be used to escalate access, though it seems strange that anyone could now define a class in a non-exported package/some other module.

- We've also recently discussed `LambdaMetafactory` https://github.com/openjdk/jdk/pull/12493 which will produce classes strongly tied to the class loader. If we can bring MethodHandleProxies up to the same performance level as the classes produced by LambdaMetaFactory, it could serve as an alternative and people could move away from using the LambdaMetafactory runtime API (which is not really meant to be used directly). WRT that, I think the fact that the implementation proposed by this patch defines classes that are _not_ strongly tied to the defining loader is a good thing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13197#issuecomment-1486980533

From liach at openjdk.org  Tue Mar 28 14:37:13 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 28 Mar 2023 14:37:13 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion
In-Reply-To: <6N1wKps-M239ceVuAojyvUIc-HjAEhcMLhxB6-jlkwI=.fc4f560f-9e98-4688-98a2-187e4f3f8758@github.com>
References: 
 
 <6N1wKps-M239ceVuAojyvUIc-HjAEhcMLhxB6-jlkwI=.fc4f560f-9e98-4688-98a2-187e4f3f8758@github.com>
Message-ID: 

On Tue, 28 Mar 2023 14:00:41 GMT, Jorn Vernee  wrote:

> I think it should be possible to spin the class bytes once, stick the result in a ClassValue cache, but then use the bytes to define multiple classes with different class data (MethodHandles).

Great point, I was dumbfounded there.

> Let suppose you have an interface like:
> 
> ```
> interface StringConsumer extends Consumer {}
> ```
> 
> The implementation needs to override both accept(Object) and accept(String).

It already does, and there are multiple test cases covering that: [mine](https://github.com/openjdk/jdk/pull/13197/files#diff-9753e5dae7b27070a1fe0d6c12eb65db605ee479d0e93d214ce710a8bbfc4922R176) and another in [MethodHandlesGeneralTest](https://github.com/openjdk/jdk/blob/927e674c12aa7965c63059b8f650d8f60156cefc/test/jdk/java/lang/invoke/MethodHandlesGeneralTest.java#L1785)

> Also, it would be nice if you could include the benchmarks you used in the patch as well.

They are from the JDK itself: https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/java/lang/invoke/MethodHandleProxiesSuppl.java https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/java/lang/invoke/MethodHandleProxiesAsIFInstance.java

Due to make issues (it passed `/` for module exports as `` on my windows somehow), I ran the test by copying them to a separate Gradle project with Gradle JMH plugin.

> I've worked on something similar before: https://bugs.openjdk.org/browse/JDK-8257605 The idea then was to add a new API in MethodHandles but since then I've been thinking that enhancing the performance of MethodHandleProxies might be better. The only issue I saw with that is that the current API doesn't accept a MethodHandles.Lookup object which would be needed to define an interface instance if the interface is in a non-exported package. Your solution just creates the lookup directly. Typically we have to be careful with injecting classes into other packages/modules since it can lead to access escalation, but maybe in this case it is fine. I don't think there's a way that this could be used to escalate access, though it seems strange that anyone could now define a class in a non-exported package/some other module.

About access:
1. The method handle itself is already access-checked upon creation. 
2. The interface access may be problematic: A non-exported interface Class object can be obtained via Reflection inspection on exported types, such as java packages and jdk.internal packages. 
   - In that case, it might not be of best interest to create an interface, but I don't think the current asInterfaceInstance API rejects such creations either.
3. The class definition under the interface and its classloader IMO is safe, as the class will not refer to any type the interface itself does not refer to; the annotation is not involved in class loading either.

> We've also recently discussed LambdaMetafactory https://github.com/openjdk/jdk/pull/12493 which will produce classes strongly tied to the class loader. If we can bring MethodHandleProxies up to the same performance level as the classes produced by LambdaMetaFactory, it could serve as an alternative and people could move away from using the LambdaMetafactory runtime API (which is not really meant to be used directly). WRT that, I think the fact that the implementation proposed by this patch defines classes that are not strongly tied to the defining loader is a good thing.

Sounds good; it's not hard to make a benchmark that compares asInterfaceInstance and metafactory side-by-side either. The non-strong feature was intended indeed when one class is defined for each class + methodhandle combination. I agree `asInterfaceInstance` would be extremely useful to users, like a plugin loader converting json-based static method references into SAM implementations, which definitely should not become defined as a part of the plugin loader; or an event bus firing events.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13197#issuecomment-1487012367

From jlaskey at openjdk.org  Tue Mar 28 15:14:44 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 28 Mar 2023 15:14:44 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v50]
In-Reply-To: 
References: 
Message-ID: 

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Update StringTemplate.combine javadoc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/58eeb319..c9696c2b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=49
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=48-49

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From naoto at openjdk.org  Tue Mar 28 16:44:26 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 28 Mar 2023 16:44:26 GMT
Subject: RFR: 8304976: Optimize
 DateTimeFormatterBuilder.ZoneTextPrinterParser.getTree()
In-Reply-To: 
References: 
Message-ID: 

On Fri, 17 Feb 2023 09:50:16 GMT, Sergey Tsypanov  wrote:

> 1) When `DateTimeFormatter` is reused we don't need to copy `availableZoneIds` and allocate `nonRegionIds` as PrefixTree can be taken from cache. In the related benchmark allocation of `HashSet` takes ~93% of all time, so avoiding it should bring some improvement for cases when we reuse `DateTimeFormatter` to parse a string into `ZoneDateTime`
> ![image](https://user-images.githubusercontent.com/10835776/219609028-af48eae4-d326-4719-8366-c215baa85835.png)
> 
> 2) `DateTimeFormatter` is mostly used with one locale, so `cachedTree` and `cachedTreeCI` can have predefined size.
> 
> 
> @State(Scope.Thread)
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> public class DateTimeFormatterBenchmark {
> 
>     private static final DateTimeFormatter df = new DateTimeFormatterBuilder().appendPattern("yyyy:MM:dd:HH:mm:v").toFormatter();
>     private static final String TEXT = "2015:03:10:12:13:ECT";
> 
>     @Setup
>     public void setUp() {
>         ZonedDateTime.parse(TEXT, df);
>     }
> 
>     @Benchmark
>     public ZonedDateTime parse() {
>         return ZonedDateTime.parse(TEXT, df);
>     }
> }

Looks like a nice fix to me.

test/micro/org/openjdk/bench/java/time/format/ZonedDateTimeFormatterBenchmark.java line 23:

> 21:  * questions.
> 22:  */
> 23: package time.format;

package should be `org.openjdk.bench.java.time.format`?

-------------

Changes requested by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/12612#pullrequestreview-1361520443
PR Review Comment: https://git.openjdk.org/jdk/pull/12612#discussion_r1150894573

From jlahoda at openjdk.org  Tue Mar 28 17:00:26 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 28 Mar 2023 17:00:26 GMT
Subject: Integrated: 8304498: JShell does not switch to raw mode when there is
 no /bin/test
In-Reply-To: 
References: 
Message-ID: 

On Mon, 20 Mar 2023 12:10:04 GMT, Jan Lahoda  wrote:

> If JShell is run on a system that does not have `/bin/test` (which is, apparently, possible for some systems, which only have `/usr/bin/test`), it won't switch the terminal into the raw mode, and the input will not work properly.
> 
> The proposed fix herein is to detect whether `test` existing in `/usr/bin/test`, and if yes, use that location. Use the existing `/bin/test` otherwise.

This pull request has now been integrated.

Changeset: fab23577
Author:    Jan Lahoda 
URL:       https://git.openjdk.org/jdk/commit/fab23577ab7fb88f90df638588e14da6bb620a3a
Stats:     59 lines in 2 files changed: 58 ins; 0 del; 1 mod

8304498: JShell does not switch to raw mode when there is no /bin/test

Reviewed-by: coffeys, vromero

-------------

PR: https://git.openjdk.org/jdk/pull/13100

From rriggs at openjdk.org  Tue Mar 28 17:38:29 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 28 Mar 2023 17:38:29 GMT
Subject: RFR: 8291598: Matcher.appendReplacement should not create new
 StringBuilder instances [v3]
In-Reply-To: 
References: 
 
Message-ID: <6xBpMzEXqGtsHNkn9SukwH9Nd7g2Xin4DYtgXmieO8c=.d60b8e38-1a67-43e4-8df2-d98f4988b5c2@github.com>

On Wed, 15 Mar 2023 20:01:05 GMT, Raffaello Giulietti  wrote:

>> Remove instantiation of `StringBuilder`
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8291598: Matcher.appendReplacement should not create new StringBuilder instances
>   
>   Removed other allocations of StringBuilder when processing named groups in replacement string.

Sorry for the delay.
The workaround for appending to StringBuffer/StringBuilder is awkward, adding a try/catch that can't happen.  But I don't have a better suggestion. 
It is scoped to the appendExpandedReplacement method and has no runtime impact.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13048#pullrequestreview-1361610772

From duke at openjdk.org  Tue Mar 28 17:52:31 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 28 Mar 2023 17:52:31 GMT
Subject: RFR: 8205129: Remove java.lang.Compiler
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 28 Mar 2023 13:36:38 GMT, Alan Bateman  wrote:

> I think you should be able to finalize the CSR JDK-8304458.

Thanks for the gentle nudge, Alan.

I was actually not aware that finalization could be initiated by the assignee! I've seen the CSR lead handle this workflow previously. I pressed the "Finalize" button.

> I think it would be good to remove "java.compiler" from the list of standard properties (table in System.getProperties) in the same release.

Yes, these seem closely related.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13092#issuecomment-1487357673

From jvernee at openjdk.org  Tue Mar 28 17:57:36 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 28 Mar 2023 17:57:36 GMT
Subject: Withdrawn: 8303524: Check FunctionDescriptor byte order when linking
In-Reply-To: 
References: 
Message-ID: 

On Thu, 23 Mar 2023 16:47:08 GMT, Jorn Vernee  wrote:

> Linkers are strongly tied to a particular byte order, because they are tied to a particular platform. So, the linker should reject layouts that have another byte order. This patch implements that check.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/13161

From duke at openjdk.org  Tue Mar 28 17:57:38 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 28 Mar 2023 17:57:38 GMT
Subject: RFR: 8302819: Remove JAR Index
Message-ID: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>

This PR removes the JAR index feature from the runtime:

- `URLClassPath` is  updated to remove the `enableJarIndex` system property and any code which would be called when this property was `true`
- The `JarIndex` implementation class is moved into `jdk.jartool` module.
- The `InvalidJarIndexError` exception class is removed because it falls out of use
- The test `test/jdk/sun/misc/JarIndex/metaInfFileNames/Basic.java` is removed because it depends on the JarIndex feature being present
- The test `test/jdk/sun/misc/JarIndex/JarIndexMergeForClassLoaderTest.java` is removed because it depends on the JarIndex feature being present
- The test `test/jdk/sun/misc/JarIndex/JarIndexMergeTest.java` is removed because it end up being the only caller of the  JarIndex.merge feature
- All `JarIndex` methods/constructors which are not used by the `jar -i` implementation are removed. 
- `JarIndex` is given package-private access.

Outstanding code work:

- Create tests for `JarFile` and `JarInputStream` accepting dusty INDEX jars.

Outstanding work:

- CSR for the removal
- Release notes for the removal
- Coordination of the update of the Jar File Specification

-------------

Commit messages:
 - Remove JarIndex default constructor
 - Make JarIndex.INDEX_NAME package private
 - Remove outdated reference to URLClassLoader using JarIndex
 - Make JarIndex package private
 - The JarIndex.merge method ended up being used only by the JarIndexMergeTest test. Removing this test, the JarIndex.merge methods and a number of other JarIndex methods not used by the 'jar' tool
 - Revert the export of sun.security.action to jdk.jartool. JarIndex can use System.property instead since the 'jar' tool does not run with a SecurityManager
 - Revert noisy whitespace changes
 - Revert noisy whitespace changes
 - Remove jar index feature from the runtime. Move JarIndex into jdk.jartool. Remove tests which depend on the jar index feature being considered during class loading.

Changes: https://git.openjdk.org/jdk/pull/13158/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13158&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302819
  Stats: 1809 lines in 24 files changed: 221 ins; 1576 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/13158.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13158/head:pull/13158

PR: https://git.openjdk.org/jdk/pull/13158

From jpai at openjdk.org  Tue Mar 28 17:57:39 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 28 Mar 2023 17:57:39 GMT
Subject: RFR: 8302819: Remove JAR Index
In-Reply-To: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
Message-ID: 

On Thu, 23 Mar 2023 12:05:50 GMT, Eirik Bjorsnos  wrote:

> This PR removes the JAR index feature from the runtime:
> 
> - `URLClassPath` is  updated to remove the `enableJarIndex` system property and any code which would be called when this property was `true`
> - The `JarIndex` implementation class is moved into `jdk.jartool` module.
> - The `InvalidJarIndexError` exception class is removed because it falls out of use
> - The test `test/jdk/sun/misc/JarIndex/metaInfFileNames/Basic.java` is removed because it depends on the JarIndex feature being present
> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeForClassLoaderTest.java` is removed because it depends on the JarIndex feature being present
> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeTest.java` is removed because it end up being the only caller of the  JarIndex.merge feature
> - All `JarIndex` methods/constructors which are not used by the `jar -i` implementation are removed. 
> - `JarIndex` is given package-private access.
> 
> Outstanding code work:
> 
> - Create tests for `JarFile` and `JarInputStream` accepting dusty INDEX jars.
> 
> Outstanding work:
> 
> - CSR for the removal
> - Release notes for the removal
> - Coordination of the update of the Jar File Specification

Hello Eirik,

> Note that this PR does not aim to remove the ability for the jar tool to produce JAR files with indexes. Such a removal could be handled separately from this PR.

My understanding of https://bugs.openjdk.org/browse/JDK-8302819 is that we are removing the JAR Index since it is no longer usable in recent versions.

The work, that by default disabled support for jar indexes in URLClassLoader https://bugs.openjdk.org/browse/JDK-8273473 did not deprecate the `jar -i` option and explicitly noted that it would continue to work the way it used to.
Perhaps now is the time to add a deprecation/warning message when `jar -i` option is used? JDK-8302819 does note this as a possibility as part of this change:
> The jar -i (--generate-index=FILE) option can continue to generate the JAR index or the option can be changed to just emit a warning.

> 
>  The `InvalidJarIndexError` exception class is removed because it falls out of use

Since `Throwable` classes are serializable, I looked up the serialization spec to see if this removal would have any compatibility issues that need to be accounted for. The specification https://docs.oracle.com/en/java/javase/20/docs/specs/serialization/version.html#compatible-changes states that removing classes is a compatible change, so this should be fine. Plus, this exception appears to be thrown only when index file is being processed (as the name suggests).

Sorry my previous message wasn't clear.

> Hooking in a simple deprecation warning in this PR would propably not require a lot of extra review cycles, perhaps the opposite. So I'm happy to do that if that is what you meant

Yes, that's what I meant - I think we should add a warning message when that option is used, as part of these changes. I don't think we can completely remove that option in this release, since it wasn't deprecated (for removal) before, so it would be a good idea to start warning. Like you, I too would let Alan provide guidance on whether this should be done as part of this PR.

Hello Eirik, thank you for the updates to the PR.
I see that Alan suggested that we take up the `jar -i` deprecation in a separate PR. I think that simplifies the work in this PR. I'll run some tests with these changes and do another review soon, but you don't have to wait for it, if you want to move this PR out of draft status.

Hello Eirik, I ran our tier tests against the current state of this PR and they came back fine.

With the removal of support for `META-INF/INDEX.LIST`, this PR rightly removes the related test cases. I think we should introduce a new test class with some test methods which verifies that the `java.util.jar.JarFile` and `java.util.jar.JarInputStream` APIs continue to work fine when they are presented with a jar which has a `META-INF/INDEX.LIST`. Some such tests would be to use these APIs to load:

 - A jar which has a META-INF/MANIFEST.MF and a META-INF/INDEX.LIST
 - A jar which has a META-INF/INDEX.LIST but no manifest file
 - A signed jar which has a META-INF/INDEX.LIST

Adding these tests I think will help us verify that these APIs  and also exercise the code in these classes where we have checks for `META-INF/INDEX.LIST` entry. Is that something you could consider adding as part of this PR?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1481267431
PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1481283448
PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1481306676
PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1483076228
PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1485073282

From duke at openjdk.org  Tue Mar 28 17:57:41 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 28 Mar 2023 17:57:41 GMT
Subject: RFR: 8302819: Remove JAR Index
In-Reply-To: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
Message-ID: 

On Thu, 23 Mar 2023 12:05:50 GMT, Eirik Bjorsnos  wrote:

> This PR removes the JAR index feature from the runtime:
> 
> - `URLClassPath` is  updated to remove the `enableJarIndex` system property and any code which would be called when this property was `true`
> - The `JarIndex` implementation class is moved into `jdk.jartool` module.
> - The `InvalidJarIndexError` exception class is removed because it falls out of use
> - The test `test/jdk/sun/misc/JarIndex/metaInfFileNames/Basic.java` is removed because it depends on the JarIndex feature being present
> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeForClassLoaderTest.java` is removed because it depends on the JarIndex feature being present
> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeTest.java` is removed because it end up being the only caller of the  JarIndex.merge feature
> - All `JarIndex` methods/constructors which are not used by the `jar -i` implementation are removed. 
> - `JarIndex` is given package-private access.
> 
> Outstanding code work:
> 
> - Create tests for `JarFile` and `JarInputStream` accepting dusty INDEX jars.
> 
> Outstanding work:
> 
> - CSR for the removal
> - Release notes for the removal
> - Coordination of the update of the Jar File Specification

If we include the deprecation of `jar -i` in this PR, then the CSR for this PR would need to also cover that deprecation. Same is true for release notes. Not seeing any problem with that myself, but thought it would be good to take note here.

Regarding `JarIndex`:

>Additionally you could even make it package-private there, instead of public. It would anyway need some updates to its javadoc and maybe remove any no longer used methods.

Making it package-private did not work because of the `JarIndexMergeTest` test which directly depends on `JarIndex`. Changing package of the test did not work because of split packages.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1481314347
PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1481730500

From jpai at openjdk.org  Tue Mar 28 17:57:43 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 28 Mar 2023 17:57:43 GMT
Subject: RFR: 8302819: Remove JAR Index
In-Reply-To: 
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 
Message-ID: 

On Thu, 23 Mar 2023 14:33:19 GMT, Jaikiran Pai  wrote:

>> This PR removes the JAR index feature from the runtime:
>> 
>> - `URLClassPath` is  updated to remove the `enableJarIndex` system property and any code which would be called when this property was `true`
>> - The `JarIndex` implementation class is moved into `jdk.jartool` module.
>> - The `InvalidJarIndexError` exception class is removed because it falls out of use
>> - The test `test/jdk/sun/misc/JarIndex/metaInfFileNames/Basic.java` is removed because it depends on the JarIndex feature being present
>> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeForClassLoaderTest.java` is removed because it depends on the JarIndex feature being present
>> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeTest.java` is removed because it end up being the only caller of the  JarIndex.merge feature
>> - All `JarIndex` methods/constructors which are not used by the `jar -i` implementation are removed. 
>> - `JarIndex` is given package-private access.
>> 
>> Outstanding code work:
>> 
>> - Create tests for `JarFile` and `JarInputStream` accepting dusty INDEX jars.
>> 
>> Outstanding work:
>> 
>> - CSR for the removal
>> - Release notes for the removal
>> - Coordination of the update of the Jar File Specification
>
> Sorry my previous message wasn't clear.
> 
>> Hooking in a simple deprecation warning in this PR would propably not require a lot of extra review cycles, perhaps the opposite. So I'm happy to do that if that is what you meant
> 
> Yes, that's what I meant - I think we should add a warning message when that option is used, as part of these changes. I don't think we can completely remove that option in this release, since it wasn't deprecated (for removal) before, so it would be a good idea to start warning. Like you, I too would let Alan provide guidance on whether this should be done as part of this PR.

> @jaikiran Do you agree with the move of `JarIndex` from `java.base` to `jdk.jartool`? Since it ends up only being used there, I thought it would be cleaner if we moved it. But the move is not strictly necessary. What's your thoughts?

With the changes in this PR, the `JarIndex` (an internal) class would only be relevant/useful in the `jar` tool. So I think it makes sense to move it to the `jdk.jartool` module. Additionally you could even make it package-private there, instead of public. It would anyway need some updates to its javadoc and maybe remove any no longer used methods.

On a related note, I see that the `module-info.java` of `java.base` module has been updated to export `sun.security.action` package to the `jdk.jartool`. I think that is because the (now moved) `JarIndex` uses the `sun.security.action.GetPropertyAction.privilegedGetProperty` utility method to read a system property. I don't think we should be exporting that package. Instead, the `JarIndex` class can be updated to do `AccessController.doPrivileged(...)`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1481371199

From jpai at openjdk.org  Tue Mar 28 17:57:45 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 28 Mar 2023 17:57:45 GMT
Subject: RFR: 8302819: Remove JAR Index
In-Reply-To: 
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 
 
 
Message-ID: <6yfUz_5fyZiGWdcg6s6KuwtX12GUHZkuovhdtVQuYs4=.c7fa3c4e-fa12-4d33-97bc-a3da172589d3@github.com>

On Thu, 23 Mar 2023 15:31:31 GMT, Eirik Bjorsnos  wrote:

> > I don't think we should be exporting that package. Instead, the `JarIndex` class can be updated to do `AccessController.doPrivileged(...)`.
> 
> Nice, I'll try that!
> 
> Do you know if the `jar` tool allows running with a `SecurityManager`? If not, we could perhaps simply use `System.getProperty`?

I had a look at the existing code in the jar tool. It appears that it doesn't run with a SecurityManager - there's direct calls to `System.getProperty()` in some places in the code. So I think just calling `System.getProperty()` should be fine. When this PR goes into a published state for review, I'm sure others who have more knowledge about this area will help decide.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1482267543

From duke at openjdk.org  Tue Mar 28 17:57:46 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 28 Mar 2023 17:57:46 GMT
Subject: RFR: 8302819: Remove JAR Index
In-Reply-To: <6yfUz_5fyZiGWdcg6s6KuwtX12GUHZkuovhdtVQuYs4=.c7fa3c4e-fa12-4d33-97bc-a3da172589d3@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 
 
 
 <6yfUz_5fyZiGWdcg6s6KuwtX12GUHZkuovhdtVQuYs4=.c7fa3c4e-fa12-4d33-97bc-a3da172589d3@github.com>
Message-ID: 

On Fri, 24 Mar 2023 05:20:34 GMT, Jaikiran Pai  wrote:

>>> I don't think we should be exporting that package. Instead, the `JarIndex` class can be updated to do `AccessController.doPrivileged(...)`.
>> 
>> Nice, I'll try that!
>> 
>>  Do you know if the `jar` tool allows running with a `SecurityManager`? If not, we could perhaps simply use `System.getProperty`?
>
>> > I don't think we should be exporting that package. Instead, the `JarIndex` class can be updated to do `AccessController.doPrivileged(...)`.
>> 
>> Nice, I'll try that!
>> 
>> Do you know if the `jar` tool allows running with a `SecurityManager`? If not, we could perhaps simply use `System.getProperty`?
> 
> I had a look at the existing code in the jar tool. It appears that it doesn't run with a SecurityManager - there's direct calls to `System.getProperty()` in some places in the code. So I think just calling `System.getProperty()` should be fine. When this PR goes into a published state for review, I'm sure others who have more knowledge about this area will help decide.

@jaikiran 

Looking into how the deprecation warning could be implemented, it seems `jar` has some existing infrastructure for deprecation warnings, so the deprecation could be implemented with the following small patch:


Subject: [PATCH] Remove JarIndex default constructor
---
Index: src/jdk.jartool/share/classes/sun/tools/jar/Main.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/src/jdk.jartool/share/classes/sun/tools/jar/Main.java b/src/jdk.jartool/share/classes/sun/tools/jar/Main.java
--- a/src/jdk.jartool/share/classes/sun/tools/jar/Main.java	(revision fee0da27be832a7413886ddd2cfd5586bfd2e37a)
+++ b/src/jdk.jartool/share/classes/sun/tools/jar/Main.java	(date 1679654673667)
@@ -396,6 +396,9 @@
                     }
                 }
             } else if (iflag) {
+                if (!suppressDeprecateMsg) {
+                    warn(formatMsg("warn.flag.is.deprecated", "-i"));
+                }
                 String[] files = filesMap.get(BASE_VERSION);  // base entries only, can be null
                 genIndex(rootjar, files);
             } else if (dflag) {


This gives the following warning message on use:


% build/macosx-x86_64-server-release/images/jdk/bin/jar --generate-index file.jar
Warning: The -i option is deprecated, and is planned for removal in a future JDK release


Which may be overridden by using `-XDsuppress-tool-removal-message`:


% build/macosx-x86_64-server-release/images/jdk/bin/jar --generate-index file.jar -XDsuppress-tool-removal-message

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1482612735

From alanb at openjdk.org  Tue Mar 28 17:57:48 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 28 Mar 2023 17:57:48 GMT
Subject: RFR: 8302819: Remove JAR Index
In-Reply-To: 
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 
Message-ID: 

On Fri, 24 Mar 2023 16:22:33 GMT, Jaikiran Pai  wrote:

> I see that Alan suggested that we take up the `jar -i` deprecation in a separate PR. I think that simplifies the work in this PR.

Yes, there are options for `jar -i` that include "leave it as is", have the option create the index and emit a warning that the feature is deprecated, or remove the index creation and emit a warning that it is ignored. I don't think we should change "jar -i` to fail with an error as that would break existing scripts. None of these directions impact the JAR file spec or the API docs, it's just the jar tool so I think can be separated to another PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1483778627

From alanb at openjdk.org  Tue Mar 28 17:57:48 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 28 Mar 2023 17:57:48 GMT
Subject: RFR: 8302819: Remove JAR Index
In-Reply-To: <46YSN3xN-klcZdEOVWQgKIp1rxW0Zpt9Ad1uJ2CoYIs=.8f277496-0f2c-456c-b897-7ac416876c0e@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 
 <46YSN3xN-klcZdEOVWQgKIp1rxW0Zpt9Ad1uJ2CoYIs=.8f277496-0f2c-456c-b897-7ac416876c0e@github.com>
Message-ID: 

On Mon, 27 Mar 2023 17:12:25 GMT, Eirik Bjorsnos  wrote:

> > Adding these tests I think will help us verify that these APIs and also exercise the code in these classes where we have checks for `META-INF/INDEX.LIST` entry. Is that something you could consider adding as part of this PR?
> 
> Yes, I agree this should be done. For now, I've added a note in the "Outstanding code work" section at the top of this PR.

Adding a test would be good. In the mean-time, I think it would be good to get the review started to flush out any concerns about removing this index.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1486914564

From duke at openjdk.org  Tue Mar 28 17:57:48 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 28 Mar 2023 17:57:48 GMT
Subject: RFR: 8302819: Remove JAR Index
In-Reply-To: 
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 
 <46YSN3xN-klcZdEOVWQgKIp1rxW0Zpt9Ad1uJ2CoYIs=.8f277496-0f2c-456c-b897-7ac416876c0e@github.com>
 
Message-ID: 

On Tue, 28 Mar 2023 13:42:21 GMT, Alan Bateman  wrote:

>Adding a test would be good. In the mean-time, I think it would be good to get the review started to flush out any concerns about removing this index.

Good! I will mark this ready for review. 

(I did not find time to write a test today)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1487361023

From jvernee at openjdk.org  Tue Mar 28 17:57:36 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 28 Mar 2023 17:57:36 GMT
Subject: RFR: 8303524: Check FunctionDescriptor byte order when linking
In-Reply-To: 
References: 
Message-ID: 

On Thu, 23 Mar 2023 16:47:08 GMT, Jorn Vernee  wrote:

> Linkers are strongly tied to a particular byte order, because they are tied to a particular platform. So, the linker should reject layouts that have another byte order. This patch implements that check.

I will fold this into https://github.com/openjdk/jdk/pull/13164 I think. I think the changes logically go together (as the review comments also show), and it would avoid having to create 2 separate CSRs

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13161#issuecomment-1487363852

From duke at openjdk.org  Tue Mar 28 17:57:41 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 28 Mar 2023 17:57:41 GMT
Subject: RFR: 8302819: Remove JAR Index
In-Reply-To: 
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 
Message-ID: <46YSN3xN-klcZdEOVWQgKIp1rxW0Zpt9Ad1uJ2CoYIs=.8f277496-0f2c-456c-b897-7ac416876c0e@github.com>

On Thu, 23 Mar 2023 14:09:32 GMT, Jaikiran Pai  wrote:

> Perhaps now is the time to add a deprecation/warning message when `jar -i` option is used?

I'm not entirely sure I know what you mean or suggest here, so I'll try to be explicit with what I do (think I) understand and what my reasoning is:

I one of my early comments on JDK-8302819, I suggest / recommend that the deprecation and/or eventual removal of the `jar -i` options is handled as a follow-up to this PR. My reasoning was the usual concerns about PRs: Reducing the scope seems to make the review process simpler, faster, more efficient.

Hooking in a simple deprecation warning  in this PR would propably not require a lot of extra review cycles, perhaps the opposite. So I'm happy to do that if that is what you meant and Alan also agrees.

Do you think I understood your comment?

> Sorry my previous message wasn't clear.

Thanks for clarifying, Jaikiran. I think our understanding is in sync now, which is always good!

@jaikiran Do you agree with the move of `JarIndex` from `java.base` to `jdk.jartool`? Since it ends up only being used there, I thought it would be cleaner if we moved it. But the move is not strictly necessary. What's your thoughts?

> Like you, I too would let Alan provide guidance on whether this should be done as part of this PR.

The alternative to including it in this PR would be to do it immediately following the integration of this PR. For users it maybe does not matter much as long as two changes are included in the same JDK/Java SE version?

> Adding these tests I think will help us verify that these APIs and also exercise the code in these classes where we have checks for `META-INF/INDEX.LIST` entry. Is that something you could consider adding as part of this PR?

Yes, I agree this should be done. For now, I've added a note in the "Outstanding code work" section at the top of this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1481293806
PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1481309871
PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1481321377
PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1481348568
PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1485529082

From duke at openjdk.org  Tue Mar 28 17:57:44 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 28 Mar 2023 17:57:44 GMT
Subject: RFR: 8302819: Remove JAR Index
In-Reply-To: 
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 
 
 
Message-ID: 

On Thu, 23 Mar 2023 15:31:31 GMT, Eirik Bjorsnos  wrote:

> Do you know if the `jar` tool allows running with a `SecurityManager`? If not, we could perhaps simply use `System.getProperty`?

I ended up feeling opimistic and replaced the current code with just `System.getProperty`. If that is any concern doing that, let me know and I can use `AccessController` instead.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1481727128

From duke at openjdk.org  Tue Mar 28 17:57:44 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 28 Mar 2023 17:57:44 GMT
Subject: RFR: 8302819: Remove JAR Index
In-Reply-To: 
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 
 
Message-ID: 

On Thu, 23 Mar 2023 15:10:39 GMT, Jaikiran Pai  wrote:

> I don't think we should be exporting that package. Instead, the `JarIndex` class can be updated to do `AccessController.doPrivileged(...)`.

Nice, I'll try that!

 Do you know if the `jar` tool allows running with a `SecurityManager`? If not, we could perhaps simply use `System.getProperty`?

@jaikiran made the good observation that the `JarIndex` class has various cruft left which is not needed for the `jar -i` implementation.

Since we at the moment do not know when `jar -i` will be removed (if ever), we would risk leaving a lot of unused code around if we chose to postpone this cleanup.

Becuse of this, I suggest we extend the scope of this PR to clean up `IndexJar` for use by `jdk.jartool` only.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1481407490
PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1481783142

From jvernee at openjdk.org  Tue Mar 28 17:59:33 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 28 Mar 2023 17:59:33 GMT
Subject: RFR: 8303002: Reject packed structs from linker [v2]
In-Reply-To: <7USKvbFzmmi7JWK2OpNi4p-JGLLLzGZUL_FqjE72jNM=.8ec33082-9300-4990-893c-d70744cc7003@github.com>
References: <7USKvbFzmmi7JWK2OpNi4p-JGLLLzGZUL_FqjE72jNM=.8ec33082-9300-4990-893c-d70744cc7003@github.com>
Message-ID: 

> This patch adds checks in AbstractLinker to reject packed structs and structs with excess padding (e.g. unnamed bitfields), since both of those are currently not supported, and the ABI/spec seems too vague to base support on.

Jorn Vernee 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.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13164/files
  - new: https://git.openjdk.org/jdk/pull/13164/files/e11fc6b5..e11fc6b5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13164&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13164&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13164.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13164/head:pull/13164

PR: https://git.openjdk.org/jdk/pull/13164

From rgiulietti at openjdk.org  Tue Mar 28 17:59:37 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 28 Mar 2023 17:59:37 GMT
Subject: RFR: 8291598: Matcher.appendReplacement should not create new
 StringBuilder instances [v3]
In-Reply-To: <6xBpMzEXqGtsHNkn9SukwH9Nd7g2Xin4DYtgXmieO8c=.d60b8e38-1a67-43e4-8df2-d98f4988b5c2@github.com>
References: 
 
 <6xBpMzEXqGtsHNkn9SukwH9Nd7g2Xin4DYtgXmieO8c=.d60b8e38-1a67-43e4-8df2-d98f4988b5c2@github.com>
Message-ID: 

On Tue, 28 Mar 2023 17:35:22 GMT, Roger Riggs  wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8291598: Matcher.appendReplacement should not create new StringBuilder instances
>>   
>>   Removed other allocations of StringBuilder when processing named groups in replacement string.
>
> Sorry for the delay.
> The workaround for appending to StringBuffer/StringBuilder is awkward, adding a try/catch that can't happen.  But I don't have a better suggestion. 
> It is scoped to the appendExpandedReplacement method and has no runtime impact.

@RogerRiggs Yes, it would be nice to be able to write

private void appendExpandedReplacement(StringBuilder | StringBuffer app, String replacement) 

and get rid of the `try` statement altogether.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13048#issuecomment-1487363161

From rgiulietti at openjdk.org  Tue Mar 28 17:59:40 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 28 Mar 2023 17:59:40 GMT
Subject: Integrated: 8291598: Matcher.appendReplacement should not create new
 StringBuilder instances
In-Reply-To: 
References: 
Message-ID: 

On Wed, 15 Mar 2023 18:15:02 GMT, Raffaello Giulietti  wrote:

> Remove instantiation of `StringBuilder`

This pull request has now been integrated.

Changeset: ca745cb4
Author:    Raffaello Giulietti 
URL:       https://git.openjdk.org/jdk/commit/ca745cb426a3287167ba5bbf1a554e56a84fd91c
Stats:     152 lines in 1 file changed: 61 ins; 52 del; 39 mod

8291598: Matcher.appendReplacement should not create new StringBuilder instances

Reviewed-by: rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/13048

From duke at openjdk.org  Tue Mar 28 18:18:43 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 28 Mar 2023 18:18:43 GMT
Subject: RFR: 8300979: Lazily initialize (byte,
 char)arr in java.io.DataInputStream [v3]
In-Reply-To: <0LX-QnYnFGHJzo0-IctXMu8NthQZvxoboQmeD3WvKpM=.21fde8d5-e7b8-4f9f-ba61-3bc2e222d025@github.com>
References: 
 <5tQ84BWMKaCnFalikXWrEtW9X21bB-ElGw-k5B-KZTQ=.703816ac-c0b1-4e08-be7d-74f6942010a6@github.com>
 
 <0LX-QnYnFGHJzo0-IctXMu8NthQZvxoboQmeD3WvKpM=.21fde8d5-e7b8-4f9f-ba61-3bc2e222d025@github.com>
Message-ID: 

On Thu, 23 Mar 2023 14:00:40 GMT, Eirik Bjorsnos  wrote:

>> I cannot explain why, but the changes suggested in this PR seem to introduce a small, but significant performance regression on the `DataInputStreamTest.readInt` benchmark:
>> 
>> Baseline:
>> 
>> 
>> Benchmark                    Mode  Cnt  Score   Error  Units
>> DataInputStreamTest.readInt  avgt   20  5.563 ? 0.037  us/op
>> 
>> 
>> PR:
>> 
>> 
>> Benchmark                    Mode  Cnt  Score   Error  Units
>> DataInputStreamTest.readInt  avgt   20  6.021 ? 0.020  us/op
>> 
>> 
>> The reason this puzzles me is that the `readInt` benchmark don't involve the UTF code paths at all. So why would it become slower, just because two fields are no longer initialized with the default arrays?
>
>> The reason this puzzles me is that the `readInt` benchmark don't involve the UTF code paths at all. So why would it become slower, just because two fields are no longer initialized with the default arrays?
> 
> Could there be some JIT optimizations not being possible because the fields are no longer 'never null'?

> @eirbjo I've updated the PR so we hold zero-length arrays rather than null arrays. Please re-run your benchmark to see if there is any change.

@minborg I ran the test now after your integration and I no longer observe the regression I did before.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13121#issuecomment-1487396449

From liach at openjdk.org  Tue Mar 28 18:32:34 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 28 Mar 2023 18:32:34 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion
In-Reply-To: <6N1wKps-M239ceVuAojyvUIc-HjAEhcMLhxB6-jlkwI=.fc4f560f-9e98-4688-98a2-187e4f3f8758@github.com>
References: 
 
 <6N1wKps-M239ceVuAojyvUIc-HjAEhcMLhxB6-jlkwI=.fc4f560f-9e98-4688-98a2-187e4f3f8758@github.com>
Message-ID: 

On Tue, 28 Mar 2023 14:00:41 GMT, Jorn Vernee  wrote:

> But this doesn't implement the same ClassValue cache? And spinning byte code can indeed be slow (I've seen this in other profiles).

https://github.com/liachmodded/jdk/commit/821d6b382aeceb70c67c59771deb7438f3b4b7fd

I attempted to spin one class for each mh+interface combination again. The creation time is [halved](https://jmh.morethan.io/?gists=08abb39f224574550925beb8be1b2f59,7fa6627fdd6bbdbd3f5c01ba37247f38) compared to the no-template version, but the creation time is still [very long (factor of 1000)](https://jmh.morethan.io/?gists=e5115a2a8fa0a45159e15fab0d95b5d8,7fa6627fdd6bbdbd3f5c01ba37247f38) compared to the passing to instance approach.

I think we need to determine our approach based on the call patterns of this API:
1. how often asInterfaceInstance is called with the same interface
2. how often asInterfaceInstance is called vs. how often the implementations are called

In addition, we might write a benchmark for fresh creation performance as well (as Proxy does class caching, and LambdaMetafactory also caches class in CallSite). I don't think that asInterfaceInstance class spinning is much slower than metafactory.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13197#issuecomment-1487412044

From liach at openjdk.org  Tue Mar 28 18:32:36 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 28 Mar 2023 18:32:36 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion
In-Reply-To: 
References: 
Message-ID: <_J0Qoxc-ndPs-wflipSpZrWYmaiZ-u3kUYhCYcHUefA=.889aa782-0cce-4087-89d6-8ec14c944d67@github.com>

On Mon, 27 Mar 2023 23:34:52 GMT, Chen Liang  wrote:

> As John Rose has pointed out in this issue, the current j.l.r.Proxy based implementation of MethodHandleProxies.asInterface has a few issues:
> 1. Exposes too much information via Proxy supertype (and WrapperInstance interface)
> 2. Does not allow future expansion to support SAM[^1] abstract classes
> 3. Slow (in fact, very slow)
> 
> This patch addresses all 3 problems:
> 1. It implements proxies with one hidden class for each requested interface and replaced WrapperInstance inheritance with an annotation. This can avoid unexpected passing of `instanceof`, and avoids the nasty problem of exporting a JDK interface to a dynamic module to ensure access.
> 2. This patch obtains already generated classes from a ClassValue by the requested interface type; the ClassValue can later be updated to compute implementation generation for abstract classes as well.
> 3. This patch's generated hidden classes has acceptable call and creation performance compared to the baseline; though the methods to access wrapper information see huge performance drops, they are not anticipated to be used in a very frequent basis, while the old implementation's wrapper access methods are more optimized (2ns/op) than interface implementation methods (6ns/op). [Oracle JDK 20 vs this](https://jmh.morethan.io/?gists=bf98de7b2128e7e5d14e697fd9921eb9,e5115a2a8fa0a45159e15fab0d95b5d8)
> 
> Additionally, an obsolete `ProxyForMethodHandle` test was removed, for it's no longer applicable. Tests in `jdk/java/lang/invoke` and `jdk/java/lang/reflect` pass.
> 
> Alternative implementation:
> [An alternative implementation](https://github.com/openjdk/jdk/commit/72dbf9d4e01c455854d9b865cb2a47c38f37a8e0) was to generate a proxy class for each methodhandle than sharing across methodhandles. That implementation was abandoned for its bad proxy creation performance, despite it having excellent call performance. [Alternative implementation vs this](https://jmh.morethan.io/?gists=08abb39f224574550925beb8be1b2f59,e5115a2a8fa0a45159e15fab0d95b5d8)
> 
> In addition, I have a question: in [8161245](https://bugs.openjdk.org/browse/JDK-8161245) it seems some fields can be optimized as seen in [ciField.cpp](https://github.com/openjdk/jdk/blob/6aec6f3a842ead30b26cd31dc57a2ab268f67875/src/hotspot/share/ci/ciField.cpp#L219). Does it affect the execution performance of MethodHandle in hidden classes' Condy vs. MethodHandle in regular final field in hidden classes?
> 
> [^1]: single abstract method

On a side note, one implementation class for one interface and passing handles via final fields approach (currently in this PR) is the closest to the current Proxy approach, that it almost always have better performance than the existing Proxy implementations. But this approach needs to be subject to the fresh creation performance checks as well.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13197#issuecomment-1487414818

From lancea at openjdk.org  Tue Mar 28 18:34:32 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 28 Mar 2023 18:34:32 GMT
Subject: RFR: 8302819: Remove JAR Index
In-Reply-To: 
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 
 
Message-ID: 

On Sat, 25 Mar 2023 09:35:56 GMT, Alan Bateman  wrote:

> > I see that Alan suggested that we take up the `jar -i` deprecation in a separate PR. I think that simplifies the work in this PR.
> 
> Yes, there are options for `jar -i` that include "leave it as is", have the option create the index and emit a warning that the feature is deprecated, or remove the index creation and emit a warning that it is ignored. I don't think we should change "jar -i` to fail with an error as that would break existing scripts. None of these directions impact the JAR file spec or the API docs, it's just the jar tool so I think can be separated to another PR.

Agree, we should handle this separately.  If we are thinking of emitting a warning, we probably should do that in = JDK 22  as that could break tests with golden files so we might want to give a heads up in JDK 21  before doing this

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1487416516

From aturbanov at openjdk.org  Tue Mar 28 18:36:57 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 28 Mar 2023 18:36:57 GMT
Subject: RFR: 8304498: JShell does not switch to raw mode when there is no
 /bin/test [v2]
In-Reply-To: <3zqgbZ1T9WHdEQxojLFpW1eJ0_iqxRnmkyGgu2YiMXw=.cb6b356a-fb3c-484c-aca3-3f09304e30c8@github.com>
References: 
 <3zqgbZ1T9WHdEQxojLFpW1eJ0_iqxRnmkyGgu2YiMXw=.cb6b356a-fb3c-484c-aca3-3f09304e30c8@github.com>
Message-ID: 

On Wed, 22 Mar 2023 18:38:08 GMT, Jan Lahoda  wrote:

>> If JShell is run on a system that does not have `/bin/test` (which is, apparently, possible for some systems, which only have `/usr/bin/test`), it won't switch the terminal into the raw mode, and the input will not work properly.
>> 
>> The proposed fix herein is to detect whether `test` existing in `/usr/bin/test`, and if yes, use that location. Use the existing `/bin/test` otherwise.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Checking the executable flags instead of running the program, as suggested.

@lahodaj was the issue reported to the upstream?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13100#issuecomment-1487419384

From alanb at openjdk.org  Tue Mar 28 19:19:30 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 28 Mar 2023 19:19:30 GMT
Subject: RFR: 8304840: Dangling `CharacterCodingException` in a few javadoc
 descriptions
In-Reply-To: 
References: 
Message-ID: 

On Tue, 28 Mar 2023 18:25:21 GMT, Naoto Sato  wrote:

> Fixing a documentation bug for `CharacterCodingException` without any description to it as attached. A corresponding CSR is also drafted.
> 
> ![Screenshot 2023-03-28 at 11 19 00 AM](https://user-images.githubusercontent.com/3122603/228332508-74606c64-bce1-4135-a4cf-b0c76b902676.png)

It means the descriptions are duplicate but I think better than making reader be concerned about other conditions that aren't specified. So I think this is okay.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13214#pullrequestreview-1361763158

From alanb at openjdk.org  Tue Mar 28 19:34:29 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 28 Mar 2023 19:34:29 GMT
Subject: RFR: 8302819: Remove JAR Index
In-Reply-To: 
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 
 
 
Message-ID: 

On Tue, 28 Mar 2023 18:31:28 GMT, Lance Andersen  wrote:

> If we are thinking of emitting a warning, we probably should do that in = JDK 22 as that could break tests with golden files so we might want to give a heads up in JDK 21 before doing this

The best option might be to just have `jar -i` work as before (as it does in the current proposal) but have it warn that -i may be changed to do nothing and/or be removed in a future release. If there are tests that looking for META/INDEX.list then they will work as before.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1487486680

From alanb at openjdk.org  Tue Mar 28 19:36:18 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 28 Mar 2023 19:36:18 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v2]
In-Reply-To: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
Message-ID: <9RJ4unb3FjazYLi0BbWs1NGN9h50Z1fvAz1ZNds5mO4=.cb02f148-66bd-4429-9c30-ea4a6dcbe4d7@github.com>

> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The APIs that were preview APIs in Java 19/20 are changed to permanent and their `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The JNI and JVMTI versions are bumped as this is the first change in 21 to need the new version number. A lot of tests are updated to drop `@enablePreview` and --enable-preview.
> 
> There is one API change from Java 19/20, the preview API Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an update to the JVMTI GetThreadInfo implementation to read the TCCL consistently.
> 
> In addition, there are a small number of implementation changes to sync up from the loom fibers branch:
> 
> - A number of stack frames are `@Hidden` to reduce noise in the stack traces. This exposed a few issues with the stack walker code. More specifically, the cases where  end of a continuation falls precisely at the end of the batch, or where the remaining frames are hidden, weren't handled correctly.
> - The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in Thread rather than in two classes.
> - A few robustness improvements for OOME and SOE. There is more to do here, for future PRs.
> - New system property to print a stack trace when a virtual thread sets its own value of a TL.
> - ThreadPerTaskExecutor is changed to use FutureTask.
> 
> Testing: tier1-6.

Alan Bateman 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:

 - ThreadSleepEvent refactoring
 - Merge
 - Merge
 - Initial sync from fibers branch

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13203/files
  - new: https://git.openjdk.org/jdk/pull/13203/files/1c62dc8a..7906dbb4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13203&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13203&range=00-01

  Stats: 2112 lines in 47 files changed: 1050 ins; 822 del; 240 mod
  Patch: https://git.openjdk.org/jdk/pull/13203.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13203/head:pull/13203

PR: https://git.openjdk.org/jdk/pull/13203

From iris at openjdk.org  Tue Mar 28 19:40:32 2023
From: iris at openjdk.org (Iris Clark)
Date: Tue, 28 Mar 2023 19:40:32 GMT
Subject: RFR: 8304840: Dangling `CharacterCodingException` in a few javadoc
 descriptions
In-Reply-To: 
References: 
Message-ID: 

On Tue, 28 Mar 2023 18:25:21 GMT, Naoto Sato  wrote:

> Fixing a documentation bug for `CharacterCodingException` without any description to it as attached. A corresponding CSR is also drafted.
> 
> ![Screenshot 2023-03-28 at 11 19 00 AM](https://user-images.githubusercontent.com/3122603/228332508-74606c64-bce1-4135-a4cf-b0c76b902676.png)

Associated CSR also Reviewed.

-------------

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13214#pullrequestreview-1361791244

From rriggs at openjdk.org  Tue Mar 28 19:46:35 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 28 Mar 2023 19:46:35 GMT
Subject: RFR: 8304840: Dangling `CharacterCodingException` in a few javadoc
 descriptions
In-Reply-To: 
References: 
Message-ID: <9ciZnawfhUvvH3Kierv1zLf526z1R9q7huHKy7vonio=.72ce3961-b42f-4b9f-82c6-c9b872af460c@github.com>

On Tue, 28 Mar 2023 18:25:21 GMT, Naoto Sato  wrote:

> Fixing a documentation bug for `CharacterCodingException` without any description to it as attached. A corresponding CSR is also drafted.
> 
> ![Screenshot 2023-03-28 at 11 19 00 AM](https://user-images.githubusercontent.com/3122603/228332508-74606c64-bce1-4135-a4cf-b0c76b902676.png)

LGTM

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13214#pullrequestreview-1361798141

From psandoz at openjdk.org  Tue Mar 28 20:00:35 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 28 Mar 2023 20:00:35 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v2]
In-Reply-To: <9RJ4unb3FjazYLi0BbWs1NGN9h50Z1fvAz1ZNds5mO4=.cb02f148-66bd-4429-9c30-ea4a6dcbe4d7@github.com>
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 <9RJ4unb3FjazYLi0BbWs1NGN9h50Z1fvAz1ZNds5mO4=.cb02f148-66bd-4429-9c30-ea4a6dcbe4d7@github.com>
Message-ID: 

On Tue, 28 Mar 2023 19:36:18 GMT, Alan Bateman  wrote:

>> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The APIs that were preview APIs in Java 19/20 are changed to permanent and their `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The JNI and JVMTI versions are bumped as this is the first change in 21 to need the new version number. A lot of tests are updated to drop `@enablePreview` and --enable-preview.
>> 
>> There is one API change from Java 19/20, the preview API Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an update to the JVMTI GetThreadInfo implementation to read the TCCL consistently.
>> 
>> In addition, there are a small number of implementation changes to sync up from the loom fibers branch:
>> 
>> - A number of stack frames are `@Hidden` to reduce noise in the stack traces. This exposed a few issues with the stack walker code. More specifically, the cases where  end of a continuation falls precisely at the end of the batch, or where the remaining frames are hidden, weren't handled correctly.
>> - The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in Thread rather than in two classes.
>> - A few robustness improvements for OOME and SOE. There is more to do here, for future PRs.
>> - New system property to print a stack trace when a virtual thread sets its own value of a TL.
>> - ThreadPerTaskExecutor is changed to use FutureTask.
>> 
>> Testing: tier1-6.
>
> Alan Bateman 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:
> 
>  - ThreadSleepEvent refactoring
>  - Merge
>  - Merge
>  - Initial sync from fibers branch

src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 72:

> 70:         RECORD_PATTERNS,
> 71:         // not used
> 72:         VIRTUAL_THREADS,

Can the enum constant also be removed?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1151091740

From mchung at openjdk.org  Tue Mar 28 20:13:33 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 28 Mar 2023 20:13:33 GMT
Subject: RFR: 8302819: Remove JAR Index
In-Reply-To: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
Message-ID: 

On Thu, 23 Mar 2023 12:05:50 GMT, Eirik Bjorsnos  wrote:

> This PR removes the JAR index feature from the runtime:
> 
> - `URLClassPath` is  updated to remove the `enableJarIndex` system property and any code which would be called when this property was `true`
> - The `JarIndex` implementation class is moved into `jdk.jartool` module.
> - The `InvalidJarIndexError` exception class is removed because it falls out of use
> - The test `test/jdk/sun/misc/JarIndex/metaInfFileNames/Basic.java` is removed because it depends on the JarIndex feature being present
> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeForClassLoaderTest.java` is removed because it depends on the JarIndex feature being present
> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeTest.java` is removed because it end up being the only caller of the  JarIndex.merge feature
> - All `JarIndex` methods/constructors which are not used by the `jar -i` implementation are removed. 
> - `JarIndex` is given package-private access.
> 
> Outstanding code work:
> 
> - Create tests for `JarFile` and `JarInputStream` accepting dusty INDEX jars.
> 
> Outstanding work:
> 
> - CSR for the removal
> - Release notes for the removal
> - Coordination of the update of the Jar File Specification

Happy to see this work!  This change looks fine in general.    I agree that it's good to keep this issue to remove the runtime support and separate the `jar -i` change.   JDK tools don't run with security manager enabled and no need to wrap `System::getProperty` with `doPrivileged`.

src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 936:

> 934:         @Override
> 935:         URL[] getClassPath() throws IOException {
> 936: 

Nit: extra line 936 can be removed.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13158#pullrequestreview-1361828286
PR Review Comment: https://git.openjdk.org/jdk/pull/13158#discussion_r1151099546

From jlu at openjdk.org  Tue Mar 28 21:06:34 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 28 Mar 2023 21:06:34 GMT
Subject: RFR: 8225641: Calendar.roll(int field) does not work correctly for
 WEEK_OF_YEAR [v5]
In-Reply-To: 
References: 
Message-ID: 

> This PR fixes the bug which occurred when `Calendar.roll(WEEK_OF_YEAR)` rolled into a minimal first week with an invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo.
> 
> For example, Rolling _Monday, 30 December 2019_ by 1 week produced _Monday, 31 December 2018_, which is incorrect. This is because `WEEK_OF_YEAR` is rolled from 52 to 1, and the original `DAY_OF_WEEK` is 1. However, there is no Monday in week 1 of 2019. This is exposed when a future method calls `Calendar.complete()`, which eventually calculates a `fixedDate` with the invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo.
> 
> To prevent this, a check is added for rolls into week 1, which determines if the first week is minimal. If it is indeed minimal, then it is checked if  `DAY_OF_WEEK` exists in that week, if not, `WEEK_OF_YEAR` must be incremented by one.
> 
> After the fix, Rolling _Monday, 30 December 2019_ by 1 week produces _Monday, 7 January 2019_

Justin Lu has updated the pull request incrementally with five additional commits since the last revision:

 - Impl cleanup, add Saturday end day conditional
 - Rename test, clarify test documentation
 - Add type to static declaration of Cal.Builder, since only concerned with Gregorian for this test
 - Pass in amount as 1 directly
 - Reuse Calendar.Builder

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13031/files
  - new: https://git.openjdk.org/jdk/pull/13031/files/f837268c..60d0621b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13031&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13031&range=03-04

  Stats: 278 lines in 3 files changed: 132 ins; 133 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/13031.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13031/head:pull/13031

PR: https://git.openjdk.org/jdk/pull/13031

From jlu at openjdk.org  Tue Mar 28 21:10:30 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 28 Mar 2023 21:10:30 GMT
Subject: RFR: 8304993: bad sentence break in DateFormat
Message-ID: 

This PR fixes a bad sentence break in DateFormat.FIELD AM_PM that caused incomplete API

Before:
Screen Shot 2023-03-27

After:


-------------

Commit messages:
 - Wrap e.g. with @literal to fix first sentence detection

Changes: https://git.openjdk.org/jdk/pull/13216/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13216&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304993
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13216.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13216/head:pull/13216

PR: https://git.openjdk.org/jdk/pull/13216

From forax at openjdk.org  Tue Mar 28 21:34:47 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Tue, 28 Mar 2023 21:34:47 GMT
Subject: RFR: 8266571: Sequenced Collections [v2]
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
 <7hyZMdc6JI-92HcIQyh4gFMimualCSo-kSuApHjRPks=.4d53a75e-9caa-448d-a087-d1a03da8130a@github.com>
 
Message-ID: 

On Tue, 28 Mar 2023 00:01:27 GMT, Stuart Marks  wrote:

>> This change is absolutely massive, implementing reversed() basically doubles the number of implementations which means multiple years of debugging / spec fixing.
>> 
>> Reversing a List makes sense, reversing a LinkedHashSet/LinkedHashMap is a nice to have. Having the concept of first and last (getFirst()/getLast()/etc) on Collection is something long awaited. 
>> 
>> I understand that wanting to separate the concept of Collection and SequencedCollection can be conceptually nice, but 
>> multiplying the number of interfaces also multiplies the number of implementations. Pragmatically, this patch is too big compared to how useful it is.
>> 
>> I get that Oracle is rich, but this JEP is not only a burden for Oracle but for the whole community.
>
> @forax 
> 
> Funnily, I was thinking the other day that this change is quite small given that I've been working on it for over two years. :-)
> 
> Anyway, thanks for looking through the implementation.

@stuart-marks, i read your message as not too not far from the sunken cost fallacy.

I still believe that introducing an interface for the concept of sequenced collection makes this change far bigger that it could be. After all, there is no interface for non-null collections, read-only collections, non structurally modifiable collections or sorted collections, so why an interface for ordered collection ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1487621122

From lancea at openjdk.org  Tue Mar 28 21:54:20 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 28 Mar 2023 21:54:20 GMT
Subject: RFR: 8304990: unnecessary dash in @param gives double-dash in docs
Message-ID: 

Please review this trivial change which removes a redundant `-` from an `@param` and cleans up the formatting  for the `invalid` method.


It looks like there is some additional formatting clean up that can be done but I will handle that under a separate PR.

-------------

Commit messages:
 - Remove extra -

Changes: https://git.openjdk.org/jdk/pull/13217/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13217&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304990
  Stats: 6 lines in 1 file changed: 0 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/13217.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13217/head:pull/13217

PR: https://git.openjdk.org/jdk/pull/13217

From rriggs at openjdk.org  Tue Mar 28 21:54:33 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 28 Mar 2023 21:54:33 GMT
Subject: RFR: 8304846: Provide a shared utility to dump generated classes
 defined via Lookup API [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 27 Mar 2023 21:12:28 GMT, Mandy Chung  wrote:

>> This implements a shared utility to dump generated classes defined as normal/hidden classes via `Lookup` API.   This replaces the implementation in `LambdaMetaFactory` and method handle implementation that dumps the hidden class bytes on disk for debugging.   
>> 
>> For classes defined via `Lookup::defineClass`, `Lookup::defineHiddenClass` and `Lookup::defineHiddenClassWithClassData`, by default they will be dumped to the path specified in `-Djava.lang.invoke.Lookup.dumpClasses=` 
>> 
>> The hidden classes generated for lambdas, `LambdaForms` and method handle implementation use non-default dumper so that they can be controlled via a separate system property and path as in the current implementation.
>> 
>> To dump lambda proxy classes, set this system property:
>>    -Djdk.internal.lambda.dumpProxyClasses=
>> 
>> To dump LambdaForms and method handle implementation, set this system property:
>>    -Djava.lang.invoke.MethodHandle.DUMP_CLASS_FILES=true
>>    
>> P.S. `ProxyClassesDumper` is renamed to `ClassFileDumper` but for some reason, it's not shown as rename.
>
> Mandy Chung has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - move ClassFileDumper to jdk.internal.util
>  - rename the system property for dumping class files

src/java.base/share/classes/jdk/internal/util/ClassFileDumper.java line 209:

> 207:         final int len = className.length();
> 208:         StringBuilder sb = new StringBuilder(len);
> 209: 

This could be fewer lines of adhoc conversions, the replacements are hex encoding of the characters, so the replacement array is not needed. 
java.util.HexFormat should be used for the hex encoding. The `formatHex` methods append to a StringBuilder.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13182#discussion_r1151185689

From rriggs at openjdk.org  Tue Mar 28 21:58:30 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 28 Mar 2023 21:58:30 GMT
Subject: RFR: 8304993: bad sentence break in DateFormat
In-Reply-To: 
References: 
Message-ID: 

On Tue, 28 Mar 2023 21:01:45 GMT, Justin Lu  wrote:

> This PR fixes a bad sentence break in DateFormat.FIELD AM_PM that caused incomplete API
> 
> Before:
> Screen Shot 2023-03-27
> 
> After:
> 

An unusual case... LGTM

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13216#pullrequestreview-1361961557

From bpb at openjdk.org  Tue Mar 28 21:58:30 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 28 Mar 2023 21:58:30 GMT
Subject: RFR: 8304990: unnecessary dash in @param gives double-dash in docs
In-Reply-To: 
References: 
Message-ID: 

On Tue, 28 Mar 2023 21:48:23 GMT, Lance Andersen  wrote:

> Please review this trivial change which removes a redundant `-` from an `@param` and cleans up the formatting  for the `isValid` method.
> 
> 
> It looks like there is some additional formatting clean up that can be done but I will handle that under a separate PR.

Marked as reviewed by bpb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13217#pullrequestreview-1361961495

From naoto at openjdk.org  Tue Mar 28 22:02:29 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 28 Mar 2023 22:02:29 GMT
Subject: RFR: 8304993: bad sentence break in DateFormat
In-Reply-To: 
References: 
Message-ID: 

On Tue, 28 Mar 2023 21:01:45 GMT, Justin Lu  wrote:

> This PR fixes a bad sentence break in DateFormat.FIELD AM_PM that caused incomplete API
> 
> Before:
> Screen Shot 2023-03-27
> 
> After:
> 

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13216#pullrequestreview-1361965055

From lancea at openjdk.org  Tue Mar 28 22:06:29 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 28 Mar 2023 22:06:29 GMT
Subject: RFR: 8304993: bad sentence break in DateFormat
In-Reply-To: 
References: 
Message-ID: 

On Tue, 28 Mar 2023 21:01:45 GMT, Justin Lu  wrote:

> This PR fixes a bad sentence break in DateFormat.FIELD AM_PM that caused incomplete API
> 
> Before:
> Screen Shot 2023-03-27
> 
> After:
> 

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13216#pullrequestreview-1361969887

From naoto at openjdk.org  Tue Mar 28 22:13:28 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 28 Mar 2023 22:13:28 GMT
Subject: RFR: 8304990: unnecessary dash in @param gives double-dash in docs
In-Reply-To: 
References: 
Message-ID: 

On Tue, 28 Mar 2023 21:48:23 GMT, Lance Andersen  wrote:

> Please review this trivial change which removes a redundant `-` from an `@param` and cleans up the formatting  for the `isValid` method.
> 
> 
> It looks like there is some additional formatting clean up that can be done but I will handle that under a separate PR.

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13217#pullrequestreview-1361979087

From mchung at openjdk.org  Tue Mar 28 22:14:32 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 28 Mar 2023 22:14:32 GMT
Subject: RFR: 8304846: Provide a shared utility to dump generated classes
 defined via Lookup API [v3]
In-Reply-To: 
References: 
 
 
Message-ID: <0lFAeE4ghsKZ8Z1WoGZhNFtJdSoTOCsMdUjvWlcDFR4=.090b2575-6374-4d9b-9acf-1166f1a56576@github.com>

On Tue, 28 Mar 2023 21:51:21 GMT, Roger Riggs  wrote:

>> Mandy Chung has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - move ClassFileDumper to jdk.internal.util
>>  - rename the system property for dumping class files
>
> src/java.base/share/classes/jdk/internal/util/ClassFileDumper.java line 209:
> 
>> 207:         final int len = className.length();
>> 208:         StringBuilder sb = new StringBuilder(len);
>> 209: 
> 
> This could be fewer lines of adhoc conversions, the replacements are hex encoding of the characters, so the replacement array is not needed. 
> java.util.HexFormat should be used for the hex encoding. The `formatHex` methods append to a StringBuilder.

This old code was from ProxyClassesDumper.  Yes it can be converted to use HexFormat.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13182#discussion_r1151200144

From iris at openjdk.org  Tue Mar 28 23:30:30 2023
From: iris at openjdk.org (Iris Clark)
Date: Tue, 28 Mar 2023 23:30:30 GMT
Subject: RFR: 8304993: bad sentence break in DateFormat
In-Reply-To: 
References: 
Message-ID: 

On Tue, 28 Mar 2023 21:01:45 GMT, Justin Lu  wrote:

> This PR fixes a bad sentence break in DateFormat.FIELD AM_PM that caused incomplete API
> 
> Before:
> Screen Shot 2023-03-27
> 
> After:
> 

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13216#pullrequestreview-1362044318

From jvernee at openjdk.org  Tue Mar 28 23:42:15 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 28 Mar 2023 23:42:15 GMT
Subject: RFR: 8303002: Reject packed structs from linker [v3]
In-Reply-To: <7USKvbFzmmi7JWK2OpNi4p-JGLLLzGZUL_FqjE72jNM=.8ec33082-9300-4990-893c-d70744cc7003@github.com>
References: <7USKvbFzmmi7JWK2OpNi4p-JGLLLzGZUL_FqjE72jNM=.8ec33082-9300-4990-893c-d70744cc7003@github.com>
Message-ID: 

> This patch adds checks in AbstractLinker to reject packed structs and structs with excess padding (e.g. unnamed bitfields), since both of those are currently not supported, and the ABI/spec seems too vague to base support on.

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  add javadoc + fixes for trailing padding

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13164/files
  - new: https://git.openjdk.org/jdk/pull/13164/files/e11fc6b5..0698b9e3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13164&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13164&range=01-02

  Stats: 57 lines in 3 files changed: 30 ins; 2 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/13164.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13164/head:pull/13164

PR: https://git.openjdk.org/jdk/pull/13164

From jvernee at openjdk.org  Tue Mar 28 23:42:22 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 28 Mar 2023 23:42:22 GMT
Subject: RFR: 8303002: Reject packed structs from linker [v2]
In-Reply-To: 
References: <7USKvbFzmmi7JWK2OpNi4p-JGLLLzGZUL_FqjE72jNM=.8ec33082-9300-4990-893c-d70744cc7003@github.com>
 
Message-ID: 

On Mon, 27 Mar 2023 14:51:28 GMT, Maurizio Cimadamore  wrote:

>> Jorn Vernee 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.
>
> src/java.base/share/classes/java/lang/foreign/Linker.java line 200:
> 
>> 198:  * 
>> 199:  * 
      
>> 200:  * Note that due to limited ABI specification coverage, none of the native linker implementations supports
> 
> Is there something bigger to say here? E.g. can I pass a C int with an alignment other than its size? E.g. is there a requirement that the alignment of _all_ layouts should be identical to their natural alignment? If so, we should say so.

I've added a list of constraints to the linker class javadoc which covers this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13164#discussion_r1151250648

From jvernee at openjdk.org  Tue Mar 28 23:42:19 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 28 Mar 2023 23:42:19 GMT
Subject: RFR: 8303002: Reject packed structs from linker [v2]
In-Reply-To: 
References: <7USKvbFzmmi7JWK2OpNi4p-JGLLLzGZUL_FqjE72jNM=.8ec33082-9300-4990-893c-d70744cc7003@github.com>
 
Message-ID: 

On Tue, 28 Mar 2023 17:59:33 GMT, Jorn Vernee  wrote:

>> This patch adds checks in AbstractLinker to reject packed structs and structs with excess padding (e.g. unnamed bitfields), since both of those are currently not supported, and the ABI/spec seems too vague to base support on.
>
> Jorn Vernee 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.

Added the missing javadoc and also fixed an issue I found where the current check was not catching excess trailing padding that still resulted in the size of a group being a multiple of its alignment constraint (added a test case for that as well)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13164#issuecomment-1487742616

From jvernee at openjdk.org  Tue Mar 28 23:46:22 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 28 Mar 2023 23:46:22 GMT
Subject: RFR: 8303002: Reject packed structs from linker [v4]
In-Reply-To: <7USKvbFzmmi7JWK2OpNi4p-JGLLLzGZUL_FqjE72jNM=.8ec33082-9300-4990-893c-d70744cc7003@github.com>
References: <7USKvbFzmmi7JWK2OpNi4p-JGLLLzGZUL_FqjE72jNM=.8ec33082-9300-4990-893c-d70744cc7003@github.com>
Message-ID: 

> This patch adds checks in AbstractLinker to reject packed structs and structs with excess padding (e.g. unnamed bitfields), since both of those are currently not supported, and the ABI/spec seems too vague to base support on.

Jorn Vernee 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 'PR_21' into RejectPacked
 - add javadoc + fixes for trailing padding
 - fix check for padding. Add check for trailing padding too
 - Reject packed structs and structs with extra padding
 - Check byte order of layouts passed to linker

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13164/files
  - new: https://git.openjdk.org/jdk/pull/13164/files/0698b9e3..819214b2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13164&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13164&range=02-03

  Stats: 20894 lines in 676 files changed: 10200 ins; 7269 del; 3425 mod
  Patch: https://git.openjdk.org/jdk/pull/13164.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13164/head:pull/13164

PR: https://git.openjdk.org/jdk/pull/13164

From lmesnik at openjdk.org  Tue Mar 28 23:53:35 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 28 Mar 2023 23:53:35 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v2]
In-Reply-To: <9RJ4unb3FjazYLi0BbWs1NGN9h50Z1fvAz1ZNds5mO4=.cb02f148-66bd-4429-9c30-ea4a6dcbe4d7@github.com>
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 <9RJ4unb3FjazYLi0BbWs1NGN9h50Z1fvAz1ZNds5mO4=.cb02f148-66bd-4429-9c30-ea4a6dcbe4d7@github.com>
Message-ID: 

On Tue, 28 Mar 2023 19:36:18 GMT, Alan Bateman  wrote:

>> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The APIs that were preview APIs in Java 19/20 are changed to permanent and their `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The JNI and JVMTI versions are bumped as this is the first change in 21 to need the new version number. A lot of tests are updated to drop `@enablePreview` and --enable-preview.
>> 
>> There is one API change from Java 19/20, the preview API Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an update to the JVMTI GetThreadInfo implementation to read the TCCL consistently.
>> 
>> In addition, there are a small number of implementation changes to sync up from the loom fibers branch:
>> 
>> - A number of stack frames are `@Hidden` to reduce noise in the stack traces. This exposed a few issues with the stack walker code. More specifically, the cases where  end of a continuation falls precisely at the end of the batch, or where the remaining frames are hidden, weren't handled correctly.
>> - The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in Thread rather than in two classes.
>> - A few robustness improvements for OOME and SOE. There is more to do here, for future PRs.
>> - New system property to print a stack trace when a virtual thread sets its own value of a TL.
>> - ThreadPerTaskExecutor is changed to use FutureTask.
>> 
>> Testing: tier1-6.
>
> Alan Bateman 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:
> 
>  - ThreadSleepEvent refactoring
>  - Merge
>  - Merge
>  - Initial sync from fibers branch

Changes requested by lmesnik (Reviewer).

src/java.base/share/classes/java/lang/System.java line 2566:

> 2564: 
> 2565:             public  V executeOnCarrierThread(Callable task) throws Exception {
> 2566:                 if (Thread.currentThread() instanceof VirtualThread vthread) {

Any specific reason to don't use Thread.currentThread().isVirtual()?

test/hotspot/jtreg/runtime/vthread/JNIMonitor/JNIMonitor.java line 31:

> 29:  * @summary Tests that JNI monitors work correctly with virtual threads
> 30:  * @library /test/lib
> 31:  * @compile JNIMonitor.java

I think that test file is compiled implicitly. So this line could be just removed. 
The same is for all other similar tests.

test/jdk/com/sun/jdi/TestScaffold.java line 980:

> 978: 
> 979:         if (wrapper.equals("Virtual")) {
> 980:             threadFactory = Thread.ofVirtual().factory();

Should be line 
469: argInfo.targetVMArgs += "--enable-preview ";
removed also?

test/jdk/com/sun/management/ThreadMXBean/VirtualThreads.java line 143:

> 141:             long[] tids = new long[] { tid0, tid1 };
> 142:             long[] cpuTimes = bean.getThreadCpuTime(tids);
> 143:             if (Thread.currentThread().isVirtual()) {

How it worked before?

test/jdk/java/lang/Thread/virtual/GetStackTrace.java line 30:

> 28:  * @requires vm.continuations
> 29:  * @modules java.base/java.lang:+open
> 30:  * @run testng/othervm -XX:+UnlockDiagnosticVMOptions -XX:+ShowHiddenFrames GetStackTrace

shouldn't be main/othervm ?

test/jdk/java/lang/Thread/virtual/VirtualThreadPinnedEventThrows.java line 29:

> 27:  * @modules java.base/jdk.internal.event
> 28:  * @compile/module=java.base jdk/internal/event/VirtualThreadPinnedEvent.java
> 29:  * @run junit VirtualThreadPinnedEventThrows

Shouldn't be 'junit/othervm' used here to ensure that updated VirtualThreadPinnedEvent is used? I don't know these details of jtreg.

test/jdk/jdk/incubator/concurrent/StructuredTaskScope/PreviewFeaturesNotEnabled.java line 2:

> 1: /*
> 2:  * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved.

Not sure I understand what happens. The file is 
test/jdk/jdk/incubator/concurrent/StructuredTaskScope/PreviewFeaturesNotEnabled.java
while it contains is public class VirtualThreadPinnedEvent. Copied by mistake?

-------------

PR Review: https://git.openjdk.org/jdk/pull/13203#pullrequestreview-1361847681
PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1151259675
PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1151175072
PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1151168150
PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1151168861
PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1151112603
PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1151153758
PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1151119165

From prappo at openjdk.org  Wed Mar 29 00:11:36 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 29 Mar 2023 00:11:36 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v2]
In-Reply-To: 
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 <9RJ4unb3FjazYLi0BbWs1NGN9h50Z1fvAz1ZNds5mO4=.cb02f148-66bd-4429-9c30-ea4a6dcbe4d7@github.com>
 
Message-ID: 

On Tue, 28 Mar 2023 23:47:02 GMT, Leonid Mesnik  wrote:

>> Alan Bateman 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:
>> 
>>  - ThreadSleepEvent refactoring
>>  - Merge
>>  - Merge
>>  - Initial sync from fibers branch
>
> src/java.base/share/classes/java/lang/System.java line 2566:
> 
>> 2564: 
>> 2565:             public  V executeOnCarrierThread(Callable task) throws Exception {
>> 2566:                 if (Thread.currentThread() instanceof VirtualThread vthread) {
> 
> Any specific reason to don't use Thread.currentThread().isVirtual()?

To use the pattern variable to call `executeOnCarrierThread` on it?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1151270089

From lmesnik at openjdk.org  Wed Mar 29 00:18:34 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 29 Mar 2023 00:18:34 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v2]
In-Reply-To: 
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 <9RJ4unb3FjazYLi0BbWs1NGN9h50Z1fvAz1ZNds5mO4=.cb02f148-66bd-4429-9c30-ea4a6dcbe4d7@github.com>
 
 
Message-ID: <6cV6Ar01qN8gh-PiP5uhsR294ceiYKVv3k7CR5qllw4=.d428e6ad-4fb4-4d33-8705-672eef534f1d@github.com>

On Wed, 29 Mar 2023 00:08:21 GMT, Pavel Rappo  wrote:

>> src/java.base/share/classes/java/lang/System.java line 2566:
>> 
>>> 2564: 
>>> 2565:             public  V executeOnCarrierThread(Callable task) throws Exception {
>>> 2566:                 if (Thread.currentThread() instanceof VirtualThread vthread) {
>> 
>> Any specific reason to don't use Thread.currentThread().isVirtual()?
>
> To use the pattern variable to call `executeOnCarrierThread` on it?

ough, missed the last words in the line, thanks

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1151273326

From jkuhn at openjdk.org  Wed Mar 29 00:28:34 2023
From: jkuhn at openjdk.org (Johannes Kuhn)
Date: Wed, 29 Mar 2023 00:28:34 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion
In-Reply-To: 
References: 
Message-ID: 

On Mon, 27 Mar 2023 23:34:52 GMT, Chen Liang  wrote:

> As John Rose has pointed out in this issue, the current j.l.r.Proxy based implementation of MethodHandleProxies.asInterface has a few issues:
> 1. Exposes too much information via Proxy supertype (and WrapperInstance interface)
> 2. Does not allow future expansion to support SAM[^1] abstract classes
> 3. Slow (in fact, very slow)
> 
> This patch addresses all 3 problems:
> 1. It implements proxies with one hidden class for each requested interface and replaced WrapperInstance inheritance with an annotation. This can avoid unexpected passing of `instanceof`, and avoids the nasty problem of exporting a JDK interface to a dynamic module to ensure access.
> 2. This patch obtains already generated classes from a ClassValue by the requested interface type; the ClassValue can later be updated to compute implementation generation for abstract classes as well.
> 3. This patch's generated hidden classes has acceptable call and creation performance compared to the baseline; though the methods to access wrapper information see huge performance drops, they are not anticipated to be used in a very frequent basis, while the old implementation's wrapper access methods are more optimized (2ns/op) than interface implementation methods (6ns/op). [Oracle JDK 20 vs this](https://jmh.morethan.io/?gists=bf98de7b2128e7e5d14e697fd9921eb9,e5115a2a8fa0a45159e15fab0d95b5d8)
> 
> Additionally, an obsolete `ProxyForMethodHandle` test was removed, for it's no longer applicable. Tests in `jdk/java/lang/invoke` and `jdk/java/lang/reflect` pass.
> 
> Alternative implementation:
> [An alternative implementation](https://github.com/openjdk/jdk/commit/72dbf9d4e01c455854d9b865cb2a47c38f37a8e0) was to generate a proxy class for each methodhandle than sharing across methodhandles. That implementation was abandoned for its bad proxy creation performance, despite it having excellent call performance. [Alternative implementation vs this](https://jmh.morethan.io/?gists=08abb39f224574550925beb8be1b2f59,e5115a2a8fa0a45159e15fab0d95b5d8)
> 
> In addition, I have a question: in [8161245](https://bugs.openjdk.org/browse/JDK-8161245) it seems some fields can be optimized as seen in [ciField.cpp](https://github.com/openjdk/jdk/blob/6aec6f3a842ead30b26cd31dc57a2ab268f67875/src/hotspot/share/ci/ciField.cpp#L219). Does it affect the execution performance of MethodHandle in hidden classes' Condy vs. MethodHandle in regular final field in hidden classes?
> 
> [^1]: single abstract method

Changes requested by jkuhn (Author).

src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 338:

> 336:                     .aload(1)
> 337:                     .ifThenElse(Opcode.IF_ACMPEQ, CodeBuilder::iconst_1, CodeBuilder::iconst_0)
> 338:                     .ireturn());

The object methods could be left untouched, as the class inherits the default implementation from `java.lang.Object`. Interfaces can't have default methods with those signatures.

src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 386:

> 384:         try {
> 385:             return IMPLEMENTATION_INFOS.get(anno.implementedType()).resultClass == clz;
> 386:         } catch (Throwable ex) {

Again, rethrow `Error`s.

src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 399:

> 397:         try {
> 398:             ret = IMPLEMENTATION_INFOS.get(anno.implementedType());
> 399:         } catch (Throwable ex) {

As mentioned by others, propagate `Error`s.

src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 422:

> 420:         try {
> 421:             return (MethodHandle) t.getTarget.invokeExact(x);
> 422:         } catch (Throwable ex) {

Propagate `Error`s.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13197#pullrequestreview-1362084946
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1151272557
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1151274364
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1151273360
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1151274996

From liach at openjdk.org  Wed Mar 29 00:28:37 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 29 Mar 2023 00:28:37 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 29 Mar 2023 00:13:56 GMT, Johannes Kuhn  wrote:

>> As John Rose has pointed out in this issue, the current j.l.r.Proxy based implementation of MethodHandleProxies.asInterface has a few issues:
>> 1. Exposes too much information via Proxy supertype (and WrapperInstance interface)
>> 2. Does not allow future expansion to support SAM[^1] abstract classes
>> 3. Slow (in fact, very slow)
>> 
>> This patch addresses all 3 problems:
>> 1. It implements proxies with one hidden class for each requested interface and replaced WrapperInstance inheritance with an annotation. This can avoid unexpected passing of `instanceof`, and avoids the nasty problem of exporting a JDK interface to a dynamic module to ensure access.
>> 2. This patch obtains already generated classes from a ClassValue by the requested interface type; the ClassValue can later be updated to compute implementation generation for abstract classes as well.
>> 3. This patch's generated hidden classes has acceptable call and creation performance compared to the baseline; though the methods to access wrapper information see huge performance drops, they are not anticipated to be used in a very frequent basis, while the old implementation's wrapper access methods are more optimized (2ns/op) than interface implementation methods (6ns/op). [Oracle JDK 20 vs this](https://jmh.morethan.io/?gists=bf98de7b2128e7e5d14e697fd9921eb9,e5115a2a8fa0a45159e15fab0d95b5d8)
>> 
>> Additionally, an obsolete `ProxyForMethodHandle` test was removed, for it's no longer applicable. Tests in `jdk/java/lang/invoke` and `jdk/java/lang/reflect` pass.
>> 
>> Alternative implementation:
>> [An alternative implementation](https://github.com/openjdk/jdk/commit/72dbf9d4e01c455854d9b865cb2a47c38f37a8e0) was to generate a proxy class for each methodhandle than sharing across methodhandles. That implementation was abandoned for its bad proxy creation performance, despite it having excellent call performance. [Alternative implementation vs this](https://jmh.morethan.io/?gists=08abb39f224574550925beb8be1b2f59,e5115a2a8fa0a45159e15fab0d95b5d8)
>> 
>> In addition, I have a question: in [8161245](https://bugs.openjdk.org/browse/JDK-8161245) it seems some fields can be optimized as seen in [ciField.cpp](https://github.com/openjdk/jdk/blob/6aec6f3a842ead30b26cd31dc57a2ab268f67875/src/hotspot/share/ci/ciField.cpp#L219). Does it affect the execution performance of MethodHandle in hidden classes' Condy vs. MethodHandle in regular final field in hidden classes?
>> 
>> [^1]: single abstract method
>
> src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 338:
> 
>> 336:                     .aload(1)
>> 337:                     .ifThenElse(Opcode.IF_ACMPEQ, CodeBuilder::iconst_1, CodeBuilder::iconst_0)
>> 338:                     .ireturn());
> 
> The object methods could be left untouched, as the class inherits the default implementation from `java.lang.Object`. Interfaces can't have default methods with those signatures.

Do interfaces still implement these properly without definition if they extend interfaces that declare `@Override boolean equals();` etc.?

> src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 399:
> 
>> 397:         try {
>> 398:             ret = IMPLEMENTATION_INFOS.get(anno.implementedType());
>> 399:         } catch (Throwable ex) {
> 
> As mentioned by others, propagate `Error`s.

This is already obsolete by https://github.com/liachmodded/jdk/commit/821d6b382aeceb70c67c59771deb7438f3b4b7fd, which I plan to push soon.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1151277383
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1151277583

From jkuhn at openjdk.org  Wed Mar 29 00:34:32 2023
From: jkuhn at openjdk.org (Johannes Kuhn)
Date: Wed, 29 Mar 2023 00:34:32 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 29 Mar 2023 00:25:09 GMT, Chen Liang  wrote:

>> src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 338:
>> 
>>> 336:                     .aload(1)
>>> 337:                     .ifThenElse(Opcode.IF_ACMPEQ, CodeBuilder::iconst_1, CodeBuilder::iconst_0)
>>> 338:                     .ireturn());
>> 
>> The object methods could be left untouched, as the class inherits the default implementation from `java.lang.Object`. Interfaces can't have default methods with those signatures.
>
> Do interfaces still implement these properly without definition if they extend interfaces that declare `@Override boolean equals();` etc.?

Yes. You can use [`Comperator`][1]  as test.

[1]: https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/Comparator.html#equals(java.lang.Object)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1151280131

From liach at openjdk.org  Wed Mar 29 00:59:18 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 29 Mar 2023 00:59:18 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion [v2]
In-Reply-To: 
References: 
Message-ID: 

> As John Rose has pointed out in this issue, the current j.l.r.Proxy based implementation of MethodHandleProxies.asInterface has a few issues:
> 1. Exposes too much information via Proxy supertype (and WrapperInstance interface)
> 2. Does not allow future expansion to support SAM[^1] abstract classes
> 3. Slow (in fact, very slow)
> 
> This patch addresses all 3 problems:
> 1. It implements proxies with one hidden class for each requested interface and replaced WrapperInstance inheritance with an annotation. This can avoid unexpected passing of `instanceof`, and avoids the nasty problem of exporting a JDK interface to a dynamic module to ensure access.
> 2. This patch obtains already generated classes from a ClassValue by the requested interface type; the ClassValue can later be updated to compute implementation generation for abstract classes as well.
> 3. This patch's generated hidden classes has acceptable call and creation performance compared to the baseline; though the methods to access wrapper information see huge performance drops, they are not anticipated to be used in a very frequent basis, while the old implementation's wrapper access methods are more optimized (2ns/op) than interface implementation methods (6ns/op). [Oracle JDK 20 vs this](https://jmh.morethan.io/?gists=bf98de7b2128e7e5d14e697fd9921eb9,e5115a2a8fa0a45159e15fab0d95b5d8)
> 
> Additionally, an obsolete `ProxyForMethodHandle` test was removed, for it's no longer applicable. Tests in `jdk/java/lang/invoke` and `jdk/java/lang/reflect` pass.
> 
> Alternative implementation:
> [An alternative implementation](https://github.com/openjdk/jdk/commit/72dbf9d4e01c455854d9b865cb2a47c38f37a8e0) was to generate a proxy class for each methodhandle than sharing across methodhandles. That implementation was abandoned for its bad proxy creation performance, despite it having excellent call performance. [Alternative implementation vs this](https://jmh.morethan.io/?gists=08abb39f224574550925beb8be1b2f59,e5115a2a8fa0a45159e15fab0d95b5d8)
> 
> In addition, I have a question: in [8161245](https://bugs.openjdk.org/browse/JDK-8161245) it seems some fields can be optimized as seen in [ciField.cpp](https://github.com/openjdk/jdk/blob/6aec6f3a842ead30b26cd31dc57a2ab268f67875/src/hotspot/share/ci/ciField.cpp#L219). Does it affect the execution performance of MethodHandle in hidden classes' Condy vs. MethodHandle in regular final field in hidden classes?
> 
> [^1]: single abstract method

Chen Liang has updated the pull request incrementally with two additional commits since the last revision:

 - Benchmark compareing to lamda metafactory, various minor updates
 - Cache the spinned class, loading is still slow

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13197/files
  - new: https://git.openjdk.org/jdk/pull/13197/files/953fcc9f..0158ffe5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13197&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13197&range=00-01

  Stats: 250 lines in 4 files changed: 110 ins; 99 del; 41 mod
  Patch: https://git.openjdk.org/jdk/pull/13197.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13197/head:pull/13197

PR: https://git.openjdk.org/jdk/pull/13197

From liach at openjdk.org  Wed Mar 29 00:59:20 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 29 Mar 2023 00:59:20 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Wed, 29 Mar 2023 00:31:46 GMT, Johannes Kuhn  wrote:

>> Do interfaces still implement these properly without definition if they extend interfaces that declare `@Override boolean equals();` etc.?
>
> Yes. You can use [`Comperator`][1]  as test.
> 
> [1]: https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/Comparator.html#equals(java.lang.Object)

Added a test and confirmed they work in the latest patch.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1151289342

From liach at openjdk.org  Wed Mar 29 01:00:06 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 29 Mar 2023 01:00:06 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion
In-Reply-To: 
References: 
Message-ID: 

On Mon, 27 Mar 2023 23:34:52 GMT, Chen Liang  wrote:

> As John Rose has pointed out in this issue, the current j.l.r.Proxy based implementation of MethodHandleProxies.asInterface has a few issues:
> 1. Exposes too much information via Proxy supertype (and WrapperInstance interface)
> 2. Does not allow future expansion to support SAM[^1] abstract classes
> 3. Slow (in fact, very slow)
> 
> This patch addresses all 3 problems:
> 1. It implements proxies with one hidden class for each requested interface and replaced WrapperInstance inheritance with an annotation. This can avoid unexpected passing of `instanceof`, and avoids the nasty problem of exporting a JDK interface to a dynamic module to ensure access.
> 2. This patch obtains already generated classes from a ClassValue by the requested interface type; the ClassValue can later be updated to compute implementation generation for abstract classes as well.
> 3. This patch's generated hidden classes has acceptable call and creation performance compared to the baseline; though the methods to access wrapper information see huge performance drops, they are not anticipated to be used in a very frequent basis, while the old implementation's wrapper access methods are more optimized (2ns/op) than interface implementation methods (6ns/op). [Oracle JDK 20 vs this](https://jmh.morethan.io/?gists=bf98de7b2128e7e5d14e697fd9921eb9,e5115a2a8fa0a45159e15fab0d95b5d8)
> 
> Additionally, an obsolete `ProxyForMethodHandle` test was removed, for it's no longer applicable. Tests in `jdk/java/lang/invoke` and `jdk/java/lang/reflect` pass.
> 
> Alternative implementation:
> [An alternative implementation](https://github.com/openjdk/jdk/commit/72dbf9d4e01c455854d9b865cb2a47c38f37a8e0) was to generate a proxy class for each methodhandle than sharing across methodhandles. That implementation was abandoned for its bad proxy creation performance, despite it having excellent call performance. [Alternative implementation vs this](https://jmh.morethan.io/?gists=08abb39f224574550925beb8be1b2f59,e5115a2a8fa0a45159e15fab0d95b5d8)
> 
> In addition, I have a question: in [8161245](https://bugs.openjdk.org/browse/JDK-8161245) it seems some fields can be optimized as seen in [ciField.cpp](https://github.com/openjdk/jdk/blob/6aec6f3a842ead30b26cd31dc57a2ab268f67875/src/hotspot/share/ci/ciField.cpp#L219). Does it affect the execution performance of MethodHandle in hidden classes' Condy vs. MethodHandle in regular final field in hidden classes?
> 
> [^1]: single abstract method

I think the current MethodHandleProxies implementation is indeed on par with LambdaMetafactory:
https://jmh.morethan.io/?gist=fcb946d83ee4ac7386901795ca49b224

The creation performance is slightly slower than that of Lmf (maybe because of heads-up asType conversions, which is required by the API specification), but the execution performance is already on par with it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13197#issuecomment-1487795084

From liach at openjdk.org  Wed Mar 29 01:04:44 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 29 Mar 2023 01:04:44 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion [v3]
In-Reply-To: 
References: 
Message-ID: 

> As John Rose has pointed out in this issue, the current j.l.r.Proxy based implementation of MethodHandleProxies.asInterface has a few issues:
> 1. Exposes too much information via Proxy supertype (and WrapperInstance interface)
> 2. Does not allow future expansion to support SAM[^1] abstract classes
> 3. Slow (in fact, very slow)
> 
> This patch addresses all 3 problems:
> 1. It implements proxies with one hidden class for each requested interface and replaced WrapperInstance inheritance with an annotation. This can avoid unexpected passing of `instanceof`, and avoids the nasty problem of exporting a JDK interface to a dynamic module to ensure access.
> 2. This patch obtains already generated classes from a ClassValue by the requested interface type; the ClassValue can later be updated to compute implementation generation for abstract classes as well.
> 3. This patch's generated hidden classes has acceptable call and creation performance compared to the baseline; though the methods to access wrapper information see huge performance drops, they are not anticipated to be used in a very frequent basis, while the old implementation's wrapper access methods are more optimized (2ns/op) than interface implementation methods (6ns/op). [Oracle JDK 20 vs this](https://jmh.morethan.io/?gists=bf98de7b2128e7e5d14e697fd9921eb9,e5115a2a8fa0a45159e15fab0d95b5d8)
> 
> Additionally, an obsolete `ProxyForMethodHandle` test was removed, for it's no longer applicable. Tests in `jdk/java/lang/invoke` and `jdk/java/lang/reflect` pass.
> 
> Alternative implementation:
> [An alternative implementation](https://github.com/openjdk/jdk/commit/72dbf9d4e01c455854d9b865cb2a47c38f37a8e0) was to generate a proxy class for each methodhandle than sharing across methodhandles. That implementation was abandoned for its bad proxy creation performance, despite it having excellent call performance. [Alternative implementation vs this](https://jmh.morethan.io/?gists=08abb39f224574550925beb8be1b2f59,e5115a2a8fa0a45159e15fab0d95b5d8)
> 
> In addition, I have a question: in [8161245](https://bugs.openjdk.org/browse/JDK-8161245) it seems some fields can be optimized as seen in [ciField.cpp](https://github.com/openjdk/jdk/blob/6aec6f3a842ead30b26cd31dc57a2ab268f67875/src/hotspot/share/ci/ciField.cpp#L219). Does it affect the execution performance of MethodHandle in hidden classes' Condy vs. MethodHandle in regular final field in hidden classes?
> 
> [^1]: single abstract method

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  rethrow error

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13197/files
  - new: https://git.openjdk.org/jdk/pull/13197/files/0158ffe5..fade6200

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13197&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13197&range=01-02

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13197.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13197/head:pull/13197

PR: https://git.openjdk.org/jdk/pull/13197

From liach at openjdk.org  Wed Mar 29 01:06:36 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 29 Mar 2023 01:06:36 GMT
Subject: RFR: 6983726: remove Proxy from
 MethodHandleProxies.asInterfaceInstance SAM conversion [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 28 Mar 2023 10:57:28 GMT, R?mi Forax  wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   rethrow error
>
> src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 206:
> 
>> 204:         try {
>> 205:             proxy = (Object) info.ctor.invokeExact(mhs); // non-varargs
>> 206:         } catch (Throwable e) {
> 
> At least Error should be directly propagated (especially OutOfMemoryError)

Done. I just noticed LambdaMetafactory has the same problem at no-arg constructor call site, might be worthy to create a bug as well.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1151293383

From jpai at openjdk.org  Wed Mar 29 01:40:36 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 29 Mar 2023 01:40:36 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v17]
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.org/browse/JDK-8206890?
> 
> The `jlink` command allows a `--endian` option to specify the byte order in the generated image. Before this change, when such a image was being launched, the code would assume the byte order in the image to be the native order of the host where the image is being launched. That would result in failure to launch java, as noted in the linked issue.
> 
> The commit in this PR, changes relevant places to not assume native order and instead determine the byte order by reading the magic bytes in the image file's header content.
> 
> A new jtreg test has been added which reproduces the issue and verifies the fix.

Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:

 - cleanup test - rename method and update code comment as suggested by Alan
 - Rename KNOWN_ENDIANNESS to PLATFORM_PROPERTIES

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11943/files
  - new: https://git.openjdk.org/jdk/pull/11943/files/47717cad..f623d0f5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11943&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11943&range=15-16

  Stats: 12 lines in 2 files changed: 0 ins; 6 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/11943.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/11943/head:pull/11943

PR: https://git.openjdk.org/jdk/pull/11943

From jpai at openjdk.org  Wed Mar 29 01:42:42 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 29 Mar 2023 01:42:42 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v16]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 28 Mar 2023 10:57:36 GMT, Alan Bateman  wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use test.jdk system property in test
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Platform.java line 39:
> 
>> 37:  */
>> 38: public record Platform(OperatingSystem os, Architecture arch, ByteOrder endianness) {
>> 39:     private static final Properties KNOWN_ENDIANNESS;
> 
> I assume this should be renamed to something like PLATFORM_PROPERTIES as the properties are not specific to endianness now.

Hello Alan, I've updated the PR with this and the other test related suggestions.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/11943#discussion_r1151308182

From liach at openjdk.org  Wed Mar 29 01:43:07 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 29 Mar 2023 01:43:07 GMT
Subject: RFR: 8304425: ClassHierarchyResolver from Reflection [v6]
In-Reply-To: <08Hy6pEhV75yr_F4mCP-dkKOKMCSoFxWI2E7OnM4iyQ=.cfa14992-8e94-4d6d-bdf9-e6689549c83e@github.com>
References: <08Hy6pEhV75yr_F4mCP-dkKOKMCSoFxWI2E7OnM4iyQ=.cfa14992-8e94-4d6d-bdf9-e6689549c83e@github.com>
Message-ID: 

> Add API to explore Class Hierarchy with a `ClassLoader` or a `Lookup` with proper privileges, with tests.
> 
> This addition is useful in case classes at runtime are not loaded from the system class loader, such as Proxy. This is also useful to APIs that generate bytecode with a `Lookup` object, such as a custom single-abstract-method class implementations from a method handle.
> 
> See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000249.html as well.
> 
> Current questions, which I wish to discuss with @asotona:
> 1. Should the resolver fail fast on `IllegalAccessException` from the lookup? This usually indicates the hierarchy resolver is set up improperly, and proceeding may simply yield verification errors in class loading that are hard to track. For bytecode-generating APIs, throwing access errors for the Lookup eagerly is also more preferable than later silent generation failure.
> 2. Whether the default resolver should be reading from jrt alone, reflection alone, or jrt then reflection. I personally believe reflection alone is more reliable, for classes may redefined with instrumentation or jfr, which may not be reflected in the system resources.
> 3. In addition, I don't think chaining system class loader reflection after system resource retrieval is really meaningful: is there any case where reflection always works while the system resource retrieval always fails?

Chen Liang 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 eight additional commits since the last revision:

 - Merge branch 'master' into hierarchy-resolve
 - Test both cached and uncached resolvers
 - Update the class hierarchy resolver api as per mailing list last week
 - Merge branch 'master' into hierarchy-resolve
 - Update src/java.base/share/classes/jdk/internal/classfile/impl/ClassHierarchyImpl.java
   
   Co-authored-by: Andrey Turbanov 
 - Make lookup based resolver throw on illegal access eagerly
 - 8304425: ClassHierarchyResolver from Reflection
 - ClassHierarchyResolver using Reflection

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13082/files
  - new: https://git.openjdk.org/jdk/pull/13082/files/655b0276..78c8f2f7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13082&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13082&range=04-05

  Stats: 6888 lines in 211 files changed: 4666 ins; 1269 del; 953 mod
  Patch: https://git.openjdk.org/jdk/pull/13082.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13082/head:pull/13082

PR: https://git.openjdk.org/jdk/pull/13082

From mchung at openjdk.org  Wed Mar 29 02:10:10 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 29 Mar 2023 02:10:10 GMT
Subject: RFR: 8304846: Provide a shared utility to dump generated classes
 defined via Lookup API [v4]
In-Reply-To: 
References: 
Message-ID: 

> This implements a shared utility to dump generated classes defined as normal/hidden classes via `Lookup` API.   This replaces the implementation in `LambdaMetaFactory` and method handle implementation that dumps the hidden class bytes on disk for debugging.   
> 
> For classes defined via `Lookup::defineClass`, `Lookup::defineHiddenClass` and `Lookup::defineHiddenClassWithClassData`, by default they will be dumped to the path specified in `-Djava.lang.invoke.Lookup.dumpClasses=` 
> 
> The hidden classes generated for lambdas, `LambdaForms` and method handle implementation use non-default dumper so that they can be controlled via a separate system property and path as in the current implementation.
> 
> To dump lambda proxy classes, set this system property:
>    -Djdk.internal.lambda.dumpProxyClasses=
> 
> To dump LambdaForms and method handle implementation, set this system property:
>    -Djava.lang.invoke.MethodHandle.DUMP_CLASS_FILES=true
>    
> P.S. `ProxyClassesDumper` is renamed to `ClassFileDumper` but for some reason, it's not shown as rename.

Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:

  Convert to use HexFormat

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13182/files
  - new: https://git.openjdk.org/jdk/pull/13182/files/e424810c..2c305fae

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13182&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13182&range=02-03

  Stats: 34 lines in 1 file changed: 4 ins; 25 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/13182.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13182/head:pull/13182

PR: https://git.openjdk.org/jdk/pull/13182

From duke at openjdk.org  Wed Mar 29 02:23:44 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Wed, 29 Mar 2023 02:23:44 GMT
Subject: Withdrawn: 8301043: Super-interface for PrintStream and PrintWriter
In-Reply-To: 
References: 
Message-ID: <3UvRps04XGGYvjyc-M4WTO9ipALFhr10Vj98a-U0GTA=.3ea765d6-094b-4486-87d4-9d56460fba2c@github.com>

On Sun, 29 Jan 2023 01:54:02 GMT, Tingjun Yuan  wrote:

> Add `java.io.PrintOutput` to represent print operations, and modify `java.io.PrintStream` and `java.io.PrintWriter` to implement it.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/12277

From darcy at openjdk.org  Wed Mar 29 04:14:26 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 29 Mar 2023 04:14:26 GMT
Subject: RFR: JDK-8304028: Port fdlibm IEEEremainder to Java [v2]
In-Reply-To: 
References: 
Message-ID: <1yBpEbGiKOLXd-B38Uhq12C8E0wvmivsZw-ZsRihM8I=.7073272b-bc42-42b7-b789-34c2742088e9@github.com>

> Last but not least, a port of fdlibm IEEEremainder from C to Java. I plan to write some more implementation-specific tests around decision points in the FDLIBM algorithm, but I wanted to get the bulk of the changes out for review first.
> 
> Note that since IEEEremainder was the last native method in StrictMath.java, the StrictMath.c file needed to be deleted (or modified) since StrictMath.h was no longer generated as part of the build. (StrictMath.c was one of the file deleted as part of JDK-8302801).
> 
> For testing, Mach 5 tier 1 through 3 were successful (other than an unrelated test failure that was problem listed) and the exhaustive test was locally run and passed with "16, 16" to increase the testing density.

Joe Darcy 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:

 - Respond to review feedback, expand tests.
 - Merge branch 'master' into JDK-8304028
 - JDK-8304028: Port fdlibm IEEEremainder to Java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13113/files
  - new: https://git.openjdk.org/jdk/pull/13113/files/8f3d9d78..e23662a1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13113&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13113&range=00-01

  Stats: 12541 lines in 354 files changed: 4313 ins; 5848 del; 2380 mod
  Patch: https://git.openjdk.org/jdk/pull/13113.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13113/head:pull/13113

PR: https://git.openjdk.org/jdk/pull/13113

From darcy at openjdk.org  Wed Mar 29 04:14:30 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 29 Mar 2023 04:14:30 GMT
Subject: RFR: JDK-8304028: Port fdlibm IEEEremainder to Java [v2]
In-Reply-To: 
References: 
 
Message-ID: <71iJlrEFvhw6CTGIqprCF9u534ptF1FFoMkyhXU22bc=.0bf3b01c-f76d-4da5-a56c-3de67cb98780@github.com>

On Mon, 27 Mar 2023 09:43:03 GMT, Raffaello Giulietti  wrote:

>> Joe Darcy 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:
>> 
>>  - Respond to review feedback, expand tests.
>>  - Merge branch 'master' into JDK-8304028
>>  - JDK-8304028: Port fdlibm IEEEremainder to Java
>
> test/jdk/java/lang/StrictMath/FdlibmTranslit.java line 2652:
> 
>> 2650:             /* purge off exception values */
>> 2651:             if((hy|ly)==0||(hx>=0x7ff00000)||       /* y=0,or x not finite */
>> 2652:                ((hy|((ly|-ly)>>31))>0x7ff00000))     /* or y is NaN */
> 
> Suggestion:
> 
>                ((hy|((ly|-ly)>>>31))>0x7ff00000))     /* or y is NaN */

Updated to latest push in both FdlibmTranslit and Fdlibm; thanks,

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13113#discussion_r1151372326

From darcy at openjdk.org  Wed Mar 29 04:21:10 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 29 Mar 2023 04:21:10 GMT
Subject: RFR: JDK-8304028: Port fdlibm IEEEremainder to Java [v3]
In-Reply-To: 
References: 
Message-ID: <_4MDhzG22C7qUHR9ZXOAGrv52fkDTW0l-s1SaqPLz-U=.1b296196-9242-4438-9cd0-e8edf3bf135c@github.com>

> Last but not least, a port of fdlibm IEEEremainder from C to Java. I plan to write some more implementation-specific tests around decision points in the FDLIBM algorithm, but I wanted to get the bulk of the changes out for review first.
> 
> Note that since IEEEremainder was the last native method in StrictMath.java, the StrictMath.c file needed to be deleted (or modified) since StrictMath.h was no longer generated as part of the build. (StrictMath.c was one of the file deleted as part of JDK-8302801).
> 
> For testing, Mach 5 tier 1 through 3 were successful (other than an unrelated test failure that was problem listed) and the exhaustive test was locally run and passed with "16, 16" to increase the testing density.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Appease jcheck.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13113/files
  - new: https://git.openjdk.org/jdk/pull/13113/files/e23662a1..cce01395

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13113&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13113&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13113.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13113/head:pull/13113

PR: https://git.openjdk.org/jdk/pull/13113

From jpai at openjdk.org  Wed Mar 29 05:13:30 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 29 Mar 2023 05:13:30 GMT
Subject: RFR: 8304840: Dangling `CharacterCodingException` in a few javadoc
 descriptions
In-Reply-To: 
References: 
Message-ID: 

On Tue, 28 Mar 2023 18:25:21 GMT, Naoto Sato  wrote:

> Fixing a documentation bug for `CharacterCodingException` without any description to it as attached. A corresponding CSR is also drafted.
> 
> ![Screenshot 2023-03-28 at 11 19 00 AM](https://user-images.githubusercontent.com/3122603/228332508-74606c64-bce1-4135-a4cf-b0c76b902676.png)

Marked as reviewed by jpai (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13214#pullrequestreview-1362262058

From duke at openjdk.org  Wed Mar 29 06:55:47 2023
From: duke at openjdk.org (ExE Boss)
Date: Wed, 29 Mar 2023 06:55:47 GMT
Subject: RFR: 8266571: Sequenced Collections [v2]
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
 <7hyZMdc6JI-92HcIQyh4gFMimualCSo-kSuApHjRPks=.4d53a75e-9caa-448d-a087-d1a03da8130a@github.com>
 
 
Message-ID: 

On Tue, 28 Mar 2023 21:31:20 GMT, R?mi Forax  wrote:

> After all, there is no interface for non-null collections, read-only collections, non structurally modifiable collections or sorted collections, so why an interface for ordered collection ?

There is?`SortedMap`, and?non?null collection?interfaces are?unnecessary with?[JEP?draft: Null?Restricted and?Nullable?Types (Preview)][JEP?8303099].

[JEP?8303099]: https://openjdk.org/jeps/8303099 "JEP?draft: Null?Restricted and?Nullable?Types (Preview)"

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1488036900

From pminborg at openjdk.org  Wed Mar 29 07:26:06 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 29 Mar 2023 07:26:06 GMT
Subject: RFR: 8300979: Lazily initialize (byte,
 char)arr in java.io.DataInputStream [v3]
In-Reply-To: 
References: 
 <5tQ84BWMKaCnFalikXWrEtW9X21bB-ElGw-k5B-KZTQ=.703816ac-c0b1-4e08-be7d-74f6942010a6@github.com>
 
 <0LX-QnYnFGHJzo0-IctXMu8NthQZvxoboQmeD3WvKpM=.21fde8d5-e7b8-4f9f-ba61-3bc2e222d025@github.com>
 
Message-ID: 

On Tue, 28 Mar 2023 18:15:57 GMT, Eirik Bjorsnos  wrote:

> > @eirbjo I've updated the PR so we hold zero-length arrays rather than null arrays. Please re-run your benchmark to see if there is any change.
> 
> @minborg I ran the test now after your integration and I no longer observe the regression I did before.

Thanks @eirbjo for finding and verifying the performance regression.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13121#issuecomment-1488074350

From alanb at openjdk.org  Wed Mar 29 07:37:09 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 29 Mar 2023 07:37:09 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v3]
In-Reply-To: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
Message-ID: 

> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The APIs that were preview APIs in Java 19/20 are changed to permanent and their `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The JNI and JVMTI versions are bumped as this is the first change in 21 to need the new version number. A lot of tests are updated to drop `@enablePreview` and --enable-preview.
> 
> There is one API change from Java 19/20, the preview API Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an update to the JVMTI GetThreadInfo implementation to read the TCCL consistently.
> 
> In addition, there are a small number of implementation changes to sync up from the loom fibers branch:
> 
> - A number of stack frames are `@Hidden` to reduce noise in the stack traces. This exposed a few issues with the stack walker code. More specifically, the cases where  end of a continuation falls precisely at the end of the batch, or where the remaining frames are hidden, weren't handled correctly.
> - The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in Thread rather than in two classes.
> - A few robustness improvements for OOME and SOE. There is more to do here, for future PRs.
> - New system property to print a stack trace when a virtual thread sets its own value of a TL.
> - ThreadPerTaskExecutor is changed to use FutureTask.
> 
> Testing: tier1-6.

Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:

  Test updates

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13203/files
  - new: https://git.openjdk.org/jdk/pull/13203/files/7906dbb4..8170e463

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13203&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13203&range=01-02

  Stats: 67 lines in 3 files changed: 0 ins; 64 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/13203.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13203/head:pull/13203

PR: https://git.openjdk.org/jdk/pull/13203

From alanb at openjdk.org  Wed Mar 29 07:37:14 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 29 Mar 2023 07:37:14 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v2]
In-Reply-To: 
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 <9RJ4unb3FjazYLi0BbWs1NGN9h50Z1fvAz1ZNds5mO4=.cb02f148-66bd-4429-9c30-ea4a6dcbe4d7@github.com>
 
Message-ID: 

On Tue, 28 Mar 2023 19:57:12 GMT, Paul Sandoz  wrote:

>> Alan Bateman 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:
>> 
>>  - ThreadSleepEvent refactoring
>>  - Merge
>>  - Merge
>>  - Initial sync from fibers branch
>
> src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 72:
> 
>> 70:         RECORD_PATTERNS,
>> 71:         // not used
>> 72:         VIRTUAL_THREADS,
> 
> Can the enum constant also be removed?

Unfortunately not due to the bootstrapping issues with the build. It was the same for sealed classes where the constant couldn't be removed until the end of the release.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1151497635

From alanb at openjdk.org  Wed Mar 29 07:37:21 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 29 Mar 2023 07:37:21 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v2]
In-Reply-To: 
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 <9RJ4unb3FjazYLi0BbWs1NGN9h50Z1fvAz1ZNds5mO4=.cb02f148-66bd-4429-9c30-ea4a6dcbe4d7@github.com>
 
Message-ID: 

On Tue, 28 Mar 2023 21:36:04 GMT, Leonid Mesnik  wrote:

>> Alan Bateman 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:
>> 
>>  - ThreadSleepEvent refactoring
>>  - Merge
>>  - Merge
>>  - Initial sync from fibers branch
>
> test/hotspot/jtreg/runtime/vthread/JNIMonitor/JNIMonitor.java line 31:
> 
>> 29:  * @summary Tests that JNI monitors work correctly with virtual threads
>> 30:  * @library /test/lib
>> 31:  * @compile JNIMonitor.java
> 
> I think that test file is compiled implicitly. So this line could be just removed. 
> The same is for all other similar tests.

Most of the test changes were just a few sed commands remove lines with `@enablePreview`, remove  `--enable-preview -source ${jdk.version}` from `@compile` tags. We can remove the `@compile` tags that don't specify any other options as they aren't needed now, up to you.

> test/jdk/com/sun/management/ThreadMXBean/VirtualThreads.java line 143:
> 
>> 141:             long[] tids = new long[] { tid0, tid1 };
>> 142:             long[] cpuTimes = bean.getThreadCpuTime(tids);
>> 143:             if (Thread.currentThread().isVirtual()) {
> 
> How it worked before?

tid0 is the thread ID of a platform therad. tid1 is the threadID of a virtual thread. The only change here is allow this test run with the main wrapper plugin ([CODETOOLS-7903373](https://bugs.openjdk.org/browse/CODETOOLS-7903373)), it would otherwise have to be excluded for those runs.

> test/jdk/java/lang/Thread/virtual/GetStackTrace.java line 30:
> 
>> 28:  * @requires vm.continuations
>> 29:  * @modules java.base/java.lang:+open
>> 30:  * @run testng/othervm -XX:+UnlockDiagnosticVMOptions -XX:+ShowHiddenFrames GetStackTrace
> 
> shouldn't be main/othervm ?

You're right, this came over from the loom repo and I didn't know that it wasn't running (no @Test).  I think it would be better to run this test without ShowHiddenFrames, it's just need to known the expected bottom most frame.

> test/jdk/java/lang/Thread/virtual/VirtualThreadPinnedEventThrows.java line 29:
> 
>> 27:  * @modules java.base/jdk.internal.event
>> 28:  * @compile/module=java.base jdk/internal/event/VirtualThreadPinnedEvent.java
>> 29:  * @run junit VirtualThreadPinnedEventThrows
> 
> Shouldn't be 'junit/othervm' used here to ensure that updated VirtualThreadPinnedEvent is used? I don't know these details of jtreg.

This is using the jtreg support for patching system modules. jtreg runs the test in a new VM with --patch-module.

> test/jdk/jdk/incubator/concurrent/StructuredTaskScope/PreviewFeaturesNotEnabled.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved.
> 
> Not sure I understand what happens. The file is 
> test/jdk/jdk/incubator/concurrent/StructuredTaskScope/PreviewFeaturesNotEnabled.java
> while it contains is public class VirtualThreadPinnedEvent. Copied by mistake?

Thank, I'm not sure what happened there as this test is deleted.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1151507288
PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1151502964
PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1151500272
PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1151495733
PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1151496227

From aturbanov at openjdk.org  Wed Mar 29 07:37:21 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 29 Mar 2023 07:37:21 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v3]
In-Reply-To: 
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 
Message-ID: 

On Wed, 29 Mar 2023 07:31:40 GMT, Alan Bateman  wrote:

>> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The APIs that were preview APIs in Java 19/20 are changed to permanent and their `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The JNI and JVMTI versions are bumped as this is the first change in 21 to need the new version number. A lot of tests are updated to drop `@enablePreview` and --enable-preview.
>> 
>> There is one API change from Java 19/20, the preview API Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an update to the JVMTI GetThreadInfo implementation to read the TCCL consistently.
>> 
>> In addition, there are a small number of implementation changes to sync up from the loom fibers branch:
>> 
>> - A number of stack frames are `@Hidden` to reduce noise in the stack traces. This exposed a few issues with the stack walker code. More specifically, the cases where  end of a continuation falls precisely at the end of the batch, or where the remaining frames are hidden, weren't handled correctly.
>> - The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in Thread rather than in two classes.
>> - A few robustness improvements for OOME and SOE. There is more to do here, for future PRs.
>> - New system property to print a stack trace when a virtual thread sets its own value of a TL.
>> - ThreadPerTaskExecutor is changed to use FutureTask.
>> 
>> Testing: tier1-6.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test updates

test/hotspot/jtreg/serviceability/jvmti/vthread/premain/AgentWithVThreadTest.java line 40:

> 38:     public static void main(String[] args) throws Exception  {
> 39: 
> 40:         ProcessBuilder pb = ProcessTools.createTestJvm("-javaagent:agent.jar",  "-version");

Suggestion:

        ProcessBuilder pb = ProcessTools.createTestJvm("-javaagent:agent.jar", "-version");

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1151504517

From alanb at openjdk.org  Wed Mar 29 08:00:36 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 29 Mar 2023 08:00:36 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v4]
In-Reply-To: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
Message-ID: 

> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The APIs that were preview APIs in Java 19/20 are changed to permanent and their `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The JNI and JVMTI versions are bumped as this is the first change in 21 to need the new version number. A lot of tests are updated to drop `@enablePreview` and --enable-preview.
> 
> There is one API change from Java 19/20, the preview API Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an update to the JVMTI GetThreadInfo implementation to read the TCCL consistently.
> 
> In addition, there are a small number of implementation changes to sync up from the loom fibers branch:
> 
> - A number of stack frames are `@Hidden` to reduce noise in the stack traces. This exposed a few issues with the stack walker code. More specifically, the cases where  end of a continuation falls precisely at the end of the batch, or where the remaining frames are hidden, weren't handled correctly.
> - The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in Thread rather than in two classes.
> - A few robustness improvements for OOME and SOE. There is more to do here, for future PRs.
> - New system property to print a stack trace when a virtual thread sets its own value of a TL.
> - ThreadPerTaskExecutor is changed to use FutureTask.
> 
> Testing: tier1-6.

Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:

  Fix ThreadSleepEvent again

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13203/files
  - new: https://git.openjdk.org/jdk/pull/13203/files/8170e463..bfd2c816

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13203&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13203&range=02-03

  Stats: 8 lines in 1 file changed: 4 ins; 3 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13203.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13203/head:pull/13203

PR: https://git.openjdk.org/jdk/pull/13203

From aturbanov at openjdk.org  Wed Mar 29 08:04:50 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 29 Mar 2023 08:04:50 GMT
Subject: RFR: 8304846: Provide a shared utility to dump generated classes
 defined via Lookup API [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 29 Mar 2023 02:10:10 GMT, Mandy Chung  wrote:

>> This implements a shared utility to dump generated classes defined as normal/hidden classes via `Lookup` API.   This replaces the implementation in `LambdaMetaFactory` and method handle implementation that dumps the hidden class bytes on disk for debugging.   
>> 
>> For classes defined via `Lookup::defineClass`, `Lookup::defineHiddenClass` and `Lookup::defineHiddenClassWithClassData`, by default they will be dumped to the path specified in `-Djava.lang.invoke.Lookup.dumpClasses=` 
>> 
>> The hidden classes generated for lambdas, `LambdaForms` and method handle implementation use non-default dumper so that they can be controlled via a separate system property and path as in the current implementation.
>> 
>> To dump lambda proxy classes, set this system property:
>>    -Djdk.internal.lambda.dumpProxyClasses=
>> 
>> To dump LambdaForms and method handle implementation, set this system property:
>>    -Djava.lang.invoke.MethodHandle.DUMP_CLASS_FILES=true
>>    
>> P.S. `ProxyClassesDumper` is renamed to `ClassFileDumper` but for some reason, it's not shown as rename.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Convert to use HexFormat

src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java line 173:

> 171:     /** instance counters for dumped classes */
> 172:     private static final HashMap DUMP_CLASS_FILES_COUNTERS =
> 173:             dumper().isEnabled() ?  new HashMap<>(): null;

Suggestion:

            dumper().isEnabled() ? new HashMap<>(): null;

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13182#discussion_r1151540169

From alanb at openjdk.org  Wed Mar 29 08:05:59 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 29 Mar 2023 08:05:59 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v3]
In-Reply-To: 
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 
 
Message-ID: 

On Wed, 29 Mar 2023 07:29:06 GMT, Andrey Turbanov  wrote:

>> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Test updates
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/premain/AgentWithVThreadTest.java line 40:
> 
>> 38:     public static void main(String[] args) throws Exception  {
>> 39: 
>> 40:         ProcessBuilder pb = ProcessTools.createTestJvm("-javaagent:agent.jar",  "-version");
> 
> Suggestion:
> 
>         ProcessBuilder pb = ProcessTools.createTestJvm("-javaagent:agent.jar", "-version");

This is noise in the original test, the only change here is to drop the "--enable-preview" from the command.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1151542296

From stsypanov at openjdk.org  Wed Mar 29 08:16:32 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Wed, 29 Mar 2023 08:16:32 GMT
Subject: RFR: 8304976: Optimize
 DateTimeFormatterBuilder.ZoneTextPrinterParser.getTree() [v2]
In-Reply-To: 
References: 
Message-ID: 

> 1) When `DateTimeFormatter` is reused we don't need to copy `availableZoneIds` and allocate `nonRegionIds` as PrefixTree can be taken from cache. In the related benchmark allocation of `HashSet` takes ~93% of all time, so avoiding it should bring some improvement for cases when we reuse `DateTimeFormatter` to parse a string into `ZoneDateTime`
> ![image](https://user-images.githubusercontent.com/10835776/219609028-af48eae4-d326-4719-8366-c215baa85835.png)
> 
> 2) `DateTimeFormatter` is mostly used with one locale, so `cachedTree` and `cachedTreeCI` can have predefined size.
> 
> 
> @State(Scope.Thread)
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> public class DateTimeFormatterBenchmark {
> 
>     private static final DateTimeFormatter df = new DateTimeFormatterBuilder().appendPattern("yyyy:MM:dd:HH:mm:v").toFormatter();
>     private static final String TEXT = "2015:03:10:12:13:ECT";
> 
>     @Setup
>     public void setUp() {
>         ZonedDateTime.parse(TEXT, df);
>     }
> 
>     @Benchmark
>     public ZonedDateTime parse() {
>         return ZonedDateTime.parse(TEXT, df);
>     }
> }

Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:

  8304745: Fix package

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12612/files
  - new: https://git.openjdk.org/jdk/pull/12612/files/b542ae06..623a7730

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12612&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12612&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12612.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12612/head:pull/12612

PR: https://git.openjdk.org/jdk/pull/12612

From stsypanov at openjdk.org  Wed Mar 29 08:16:36 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Wed, 29 Mar 2023 08:16:36 GMT
Subject: RFR: 8304976: Optimize
 DateTimeFormatterBuilder.ZoneTextPrinterParser.getTree() [v2]
In-Reply-To: 
References: 
 
Message-ID: <6K_R-M2fNeC8LQNtX2hZBTmHFfsw-XO0NCtEx3nzuBg=.9de30de6-00a1-4206-9dcc-34a5e68a0421@github.com>

On Tue, 28 Mar 2023 16:40:17 GMT, Naoto Sato  wrote:

>> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8304745: Fix package
>
> test/micro/org/openjdk/bench/java/time/format/ZonedDateTimeFormatterBenchmark.java line 23:
> 
>> 21:  * questions.
>> 22:  */
>> 23: package time.format;
> 
> package should be `org.openjdk.bench.java.time.format`?

Renamed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12612#discussion_r1151551588

From pminborg at openjdk.org  Wed Mar 29 08:21:00 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 29 Mar 2023 08:21:00 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v13]
In-Reply-To: 
References: 
Message-ID: 

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Remove unused method and declare class final

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13079/files
  - new: https://git.openjdk.org/jdk/pull/13079/files/24bea62e..54e49e0a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=11-12

  Stats: 11 lines in 1 file changed: 0 ins; 10 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13079.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13079/head:pull/13079

PR: https://git.openjdk.org/jdk/pull/13079

From pminborg at openjdk.org  Wed Mar 29 08:23:06 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 29 Mar 2023 08:23:06 GMT
Subject: RFR: 8305157: The java.util.Arrays class should be declared final
Message-ID: 

Non-instantiable utility classes should be declared `final` and have a private constructors. 

See Effective Java, Third Edition, Joshua Bloch (for example, Item 19 or Item 22).

-------------

Commit messages:
 - Make java.util.Arrays final

Changes: https://git.openjdk.org/jdk/pull/13221/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13221&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305157
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13221.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13221/head:pull/13221

PR: https://git.openjdk.org/jdk/pull/13221

From pminborg at openjdk.org  Wed Mar 29 08:25:17 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 29 Mar 2023 08:25:17 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v14]
In-Reply-To: 
References: 
Message-ID: 

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

Per Minborg has updated the pull request incrementally with two additional commits since the last revision:

 - Merge pull request #1 from JornVernee/Fix_ULE
   
   Fix ULE when intializing LibFallback
 - fix ULE when intializing LibFallback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13079/files
  - new: https://git.openjdk.org/jdk/pull/13079/files/54e49e0a..846eaf30

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=12-13

  Stats: 48 lines in 4 files changed: 20 ins; 1 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/13079.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13079/head:pull/13079

PR: https://git.openjdk.org/jdk/pull/13079

From alanb at openjdk.org  Wed Mar 29 08:27:19 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 29 Mar 2023 08:27:19 GMT
Subject: RFR: 8305157: The java.util.Arrays class should be declared final
In-Reply-To: 
References: 
Message-ID: <1_vg3znW3bcx-IBHXt6DQetOvIwtVvZ90wlQJ_Jak4s=.c227fad8-4670-4b44-a2da-aa4e5fc7215e@github.com>

On Wed, 29 Mar 2023 08:13:06 GMT, Per Minborg  wrote:

> Non-instantiable utility classes should be declared `final` and have a private constructors. 
> 
> See Effective Java, Third Edition, Joshua Bloch (for example, Item 19 or Item 22).

Look fine, it can't be subclassed anyway so there is no compatibility impact.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13221#pullrequestreview-1362514656

From pminborg at openjdk.org  Wed Mar 29 08:55:08 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 29 Mar 2023 08:55:08 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v15]
In-Reply-To: 
References: 
Message-ID: 

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Cleanup finality

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13079/files
  - new: https://git.openjdk.org/jdk/pull/13079/files/846eaf30..c787a282

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=13-14

  Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13079.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13079/head:pull/13079

PR: https://git.openjdk.org/jdk/pull/13079

From pminborg at openjdk.org  Wed Mar 29 09:02:34 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 29 Mar 2023 09:02:34 GMT
Subject: RFR: 8305157: The java.util.Arrays class should be declared final
In-Reply-To: <1_vg3znW3bcx-IBHXt6DQetOvIwtVvZ90wlQJ_Jak4s=.c227fad8-4670-4b44-a2da-aa4e5fc7215e@github.com>
References: 
 <1_vg3znW3bcx-IBHXt6DQetOvIwtVvZ90wlQJ_Jak4s=.c227fad8-4670-4b44-a2da-aa4e5fc7215e@github.com>
Message-ID: 

On Wed, 29 Mar 2023 08:24:38 GMT, Alan Bateman  wrote:

> Look fine, it can't be subclassed anyway so there is no compatibility impact.

I thought the change would trigger a change in the public API as the modifiers are changed for the class. This would likely be picked up by compatibility checks and so, a CSR would be needed?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13221#issuecomment-1488202249

From alanb at openjdk.org  Wed Mar 29 09:06:48 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 29 Mar 2023 09:06:48 GMT
Subject: RFR: 8305157: The java.util.Arrays class should be declared final
In-Reply-To: 
References: 
 <1_vg3znW3bcx-IBHXt6DQetOvIwtVvZ90wlQJ_Jak4s=.c227fad8-4670-4b44-a2da-aa4e5fc7215e@github.com>
 
Message-ID: 

On Wed, 29 Mar 2023 08:59:50 GMT, Per Minborg  wrote:

> I thought the change would trigger a change in the public API as the modifiers are changed for the class. This would likely be picked up by compatibility checks and so, a CSR would be needed?

It's not a compatibility issue but a CSR is needed to track the change to the signature.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13221#issuecomment-1488209332

From duke at openjdk.org  Wed Mar 29 09:06:50 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 29 Mar 2023 09:06:50 GMT
Subject: RFR: 8205129: Remove java.lang.Compiler
In-Reply-To: 
References: 
Message-ID: 

On Sun, 19 Mar 2023 09:01:26 GMT, Eirik Bjorsnos  wrote:

> Please help review this PR which suggests we remove the class `java.lang.Compiler`. The class seems non-functional for a decade, and was terminally deprecated in Java 9. Time has come to let it go.

The CSR for this PR has now been approved.

@jddarcy comments in the CSR:

> Per comments in the PR, please link to any follow-up bugs to remove java.compiler support.

My guess is the "comment" here refers to @AlanBateman comment above that it would be good to handle the removal of -Djava.compiler in the same release:

> I think it would be good to remove "java.compiler" from the list of standard properties (table in System.getProperties) in the same release.

I have linked to [JDK-8041676](https://bugs.openjdk.org/browse/JDK-8041676), even though that issue strictly describes the deprecation of -Djava.compiler, not the removal.

I think what I'm trying to express here is that it's ok to refer to  [JDK-8041676](https://bugs.openjdk.org/browse/JDK-8041676) for the task that deals with the `java.compiler` system property. And that we should take care of [JDK-8041676](https://bugs.openjdk.org/browse/JDK-8041676) in the same release as this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13092#issuecomment-1488208464

From duke at openjdk.org  Wed Mar 29 09:32:20 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 29 Mar 2023 09:32:20 GMT
Subject: RFR: 8304014: Convert
 test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java to testNG
Message-ID: 

CorruptedZipFiles could benefit from some spring cleaning and a conversion to testNG:

- The actual tests are moved into their own `@Test` methods, given more meaningful names and a Javadoc comment explaining the constraint being verified
- The setup code is moved to a `@Before` method, slightly modernized and rewritten to take advantage of `assertEquals` 
- `checkZipExceptionImpl` is updated to take advantage of `expectThrows`
- A bunch of constants copied over from `ZipFile` can be deleted since JDK-6225935 has long been fixed

-------------

Commit messages:
 - Merge branch 'master' into corrupted-zip-files-ng
 - Give the @BeforeMethod and @AfterMethod more meaningful names
 - Improve comments and method names to help future maintainers understand what these tests verify.
 - Merge branch 'master' into corrupted-zip-files-ng
 - Trim whitespace and fix some spelling
 - Convert test CorruptedZipFiles to testNG and delete ZipFile constants copies which are now obsolete.

Changes: https://git.openjdk.org/jdk/pull/12563/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12563&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304014
  Stats: 268 lines in 1 file changed: 89 ins; 54 del; 125 mod
  Patch: https://git.openjdk.org/jdk/pull/12563.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12563/head:pull/12563

PR: https://git.openjdk.org/jdk/pull/12563

From lancea at openjdk.org  Wed Mar 29 09:32:35 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 29 Mar 2023 09:32:35 GMT
Subject: RFR: 8304014: Convert
 test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java to testNG
In-Reply-To: 
References: 
Message-ID: 

On Tue, 14 Feb 2023 17:46:21 GMT, Eirik Bjorsnos  wrote:

> CorruptedZipFiles could benefit from some spring cleaning and a conversion to testNG:
> 
> - The actual tests are moved into their own `@Test` methods, given more meaningful names and a Javadoc comment explaining the constraint being verified
> - The setup code is moved to a `@Before` method, slightly modernized and rewritten to take advantage of `assertEquals` 
> - `checkZipExceptionImpl` is updated to take advantage of `expectThrows`
> - A bunch of constants copied over from `ZipFile` can be deleted since JDK-6225935 has long been fixed

Hi Eirik,

Thank you for  your suggested changes to this test.

I think if we are going to re-work this test, we should go further including improving the comments for future maintainers

I made a quick pass and some initial thoughts are below

Best
Lance

test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java line 53:

> 51:     // Copy of the template for modification in tests
> 52:     private byte[] bad;
> 53:     // Some well-known locations in the golden ZIP

Would be a good opportunity to provide better naming

test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java line 58:

> 56:     @BeforeTest
> 57:     public void setup() throws IOException {
> 58:         // Make a ZIP with a single entry

Please change either this method name or the other `setup()` method.

I would also add a Files.delete(zip) here

test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java line 70:

> 68:         good = Files.readAllBytes(zip);
> 69:         Files.delete(zip);
> 70: 

I would add a `cleanup` method in addition to deleting earlier on

test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java line 71:

> 69:         Files.delete(zip);
> 70: 
> 71:         // Set up some well-known offsets

please expand the comments

test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java line 90:

> 88:      */
> 89:     @BeforeMethod
> 90:     public void setUp() {

As mentioned above, please rename this method or the other

test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java line 95:

> 93: 
> 94:     @Test
> 95:     public void corruptedENDSIZ() {

Please add a comment to this and the other tests describing the purpose of the test

test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java line 164:

> 162:     }
> 163:     static int uniquifier = 432;
> 164: 

I am not sure how many people would know what a `uniquifier` is though it is an interesting phrase which I know from SQL Server.  Perhaps consider renaming this variable

test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java line 184:

> 182:                     "Unexpected ZipException message: " + ex.getMessage());
> 183: 
> 184:         } catch (IOException e) {

Another option is to throw the IOException and add IOException to the test method signature as we are going to fail anyways for the IOException

-------------

PR Review: https://git.openjdk.org/jdk/pull/12563#pullrequestreview-1316410758
PR Review Comment: https://git.openjdk.org/jdk/pull/12563#discussion_r1119295384
PR Review Comment: https://git.openjdk.org/jdk/pull/12563#discussion_r1119297073
PR Review Comment: https://git.openjdk.org/jdk/pull/12563#discussion_r1119298405
PR Review Comment: https://git.openjdk.org/jdk/pull/12563#discussion_r1119299133
PR Review Comment: https://git.openjdk.org/jdk/pull/12563#discussion_r1119300038
PR Review Comment: https://git.openjdk.org/jdk/pull/12563#discussion_r1119300500
PR Review Comment: https://git.openjdk.org/jdk/pull/12563#discussion_r1119316956
PR Review Comment: https://git.openjdk.org/jdk/pull/12563#discussion_r1119310517

From duke at openjdk.org  Wed Mar 29 09:32:35 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 29 Mar 2023 09:32:35 GMT
Subject: RFR: 8304014: Convert
 test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java to testNG
In-Reply-To: 
References: 
Message-ID: 

On Tue, 14 Feb 2023 17:46:21 GMT, Eirik Bjorsnos  wrote:

> CorruptedZipFiles could benefit from some spring cleaning and a conversion to testNG:
> 
> - The actual tests are moved into their own `@Test` methods, given more meaningful names and a Javadoc comment explaining the constraint being verified
> - The setup code is moved to a `@Before` method, slightly modernized and rewritten to take advantage of `assertEquals` 
> - `checkZipExceptionImpl` is updated to take advantage of `expectThrows`
> - A bunch of constants copied over from `ZipFile` can be deleted since JDK-6225935 has long been fixed

Hopefully this test is now easier to understand for someone who is not intimately familiar with the ZIP format. I am hearing a voice in the back of my head (Martin?) saying "this level of documentation is excessive" though. As always a trade off I guess.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12563#issuecomment-1447807905

From duke at openjdk.org  Wed Mar 29 09:32:37 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 29 Mar 2023 09:32:37 GMT
Subject: RFR: 8304014: Convert
 test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java to testNG
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 27 Feb 2023 20:47:42 GMT, Lance Andersen  wrote:

>> CorruptedZipFiles could benefit from some spring cleaning and a conversion to testNG:
>> 
>> - The actual tests are moved into their own `@Test` methods, given more meaningful names and a Javadoc comment explaining the constraint being verified
>> - The setup code is moved to a `@Before` method, slightly modernized and rewritten to take advantage of `assertEquals` 
>> - `checkZipExceptionImpl` is updated to take advantage of `expectThrows`
>> - A bunch of constants copied over from `ZipFile` can be deleted since JDK-6225935 has long been fixed
>
> test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java line 53:
> 
>> 51:     // Copy of the template for modification in tests
>> 52:     private byte[] bad;
>> 53:     // Some well-known locations in the golden ZIP
> 
> Would be a good opportunity to provide better naming

I went for "template" and "copy" here.

> test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java line 58:
> 
>> 56:     @BeforeTest
>> 57:     public void setup() throws IOException {
>> 58:         // Make a ZIP with a single entry
> 
> Please change either this method name or the other `setup()` method.
> 
> I would also add a Files.delete(zip) here

Renamed the `@BeforeMethod` one to `makeCopy`

> test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java line 70:
> 
>> 68:         good = Files.readAllBytes(zip);
>> 69:         Files.delete(zip);
>> 70: 
> 
> I would add a `cleanup` method in addition to deleting earlier on

This one I did not fully understand. In any case, there is really no need to write the template ZIP to disk, so I opted for a ByteArrayOutputStream instead. I added a cleanup method to delete the ZIP file produced by each test.

> test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java line 71:
> 
>> 69:         Files.delete(zip);
>> 70: 
>> 71:         // Set up some well-known offsets
> 
> please expand the comments

Done

> test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java line 90:
> 
>> 88:      */
>> 89:     @BeforeMethod
>> 90:     public void setUp() {
> 
> As mentioned above, please rename this method or the other

Yes, renamed to `makeCopy`

> test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java line 95:
> 
>> 93: 
>> 94:     @Test
>> 95:     public void corruptedENDSIZ() {
> 
> Please add a comment to this and the other tests describing the purpose of the test

I have given each `@Test` method a more meaningful name and added comments explaining the constraint or error condition being tested.

> test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java line 164:
> 
>> 162:     }
>> 163:     static int uniquifier = 432;
>> 164: 
> 
> I am not sure how many people would know what a `uniquifier` is though it is an interesting phrase which I know from SQL Server.  Perhaps consider renaming this variable

I'm not sure we need unique file names for this test. Opted for a single ZIP Path instead and removed this variable.

> test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java line 184:
> 
>> 182:                     "Unexpected ZipException message: " + ex.getMessage());
>> 183: 
>> 184:         } catch (IOException e) {
> 
> Another option is to throw the IOException and add IOException to the test method signature as we are going to fail anyways for the IOException

Changed to propagate the `IOException`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12563#discussion_r1119742719
PR Review Comment: https://git.openjdk.org/jdk/pull/12563#discussion_r1119743179
PR Review Comment: https://git.openjdk.org/jdk/pull/12563#discussion_r1119744775
PR Review Comment: https://git.openjdk.org/jdk/pull/12563#discussion_r1119744908
PR Review Comment: https://git.openjdk.org/jdk/pull/12563#discussion_r1119745171
PR Review Comment: https://git.openjdk.org/jdk/pull/12563#discussion_r1119746099
PR Review Comment: https://git.openjdk.org/jdk/pull/12563#discussion_r1119747423
PR Review Comment: https://git.openjdk.org/jdk/pull/12563#discussion_r1119746553

From duke at openjdk.org  Wed Mar 29 09:34:30 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 29 Mar 2023 09:34:30 GMT
Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64 ZIP
 files
Message-ID: 

ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the number of compressed or uncompressed bytes read from the inflater is larger than the Zip64 magic value.

While the ZIP format  mandates that the data descriptor `SHOULD be stored in ZIP64 format (as 8 byte values) when a file's size exceeds 0xFFFFFFFF`, it also states that `ZIP64 format MAY be used regardless of the size of a file`. For such small entries, the above assumption does not hold.

This PR augments ZipInputStream.readEnd to also assume 8-byte sizes if the ZipEntry includes a Zip64 extra information field. This brings ZipInputStream into alignment with the APPNOTE format spec:


When extracting, if the zip64 extended information extra 
field is present for the file the compressed and 
uncompressed sizes will be 8 byte values.


While small Zip64 files with 8-byte data descriptors are not commonly found in the wild, it is possible to create one using the Info-ZIP command line `-fd` flag:

`echo hello | zip -fd > hello.zip`

The PR also adds a test verifying that such a small Zip64 file can be parsed by ZipInputStream.

-------------

Commit messages:
 - Merge branch 'master' into data-descriptor
 - Zip64 extra field of a LOC header has 1-3 long components
 - Clarify comment for shouldIgnoreExcessiveExtraSize
 - Update test to use a Zip64 file produced using the zip command with the -fd flag
 - Add comment to explaining the setExtraSize and readZipInputStream methods and the zip64File field.
 - Add comment to the call site of hasZip64 extra
 - Improve the documentation of ZipInputStream.hasZip64Extra, explaining how the method is used and adding a reference to the APPNOTE.txt specification.
 - Make (2 * Short.BYTES) less magic my extracting a variable with a comment
 - Merge branch 'master' into data-descriptor
 - Validate that the Zip64 extra field is right sized (8, 16, 24 or 28 bytes). Add tests for excessive and invalid extra data sizes.
 - ... and 7 more: https://git.openjdk.org/jdk/compare/6d30bbe6...0633c807

Changes: https://git.openjdk.org/jdk/pull/12524/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12524&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303866
  Stats: 214 lines in 2 files changed: 212 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12524.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12524/head:pull/12524

PR: https://git.openjdk.org/jdk/pull/12524

From lancea at openjdk.org  Wed Mar 29 09:34:38 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 29 Mar 2023 09:34:38 GMT
Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files
In-Reply-To: 
References: 
Message-ID: 

On Sun, 12 Feb 2023 15:41:55 GMT, Eirik Bjorsnos  wrote:

> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the number of compressed or uncompressed bytes read from the inflater is larger than the Zip64 magic value.
> 
> While the ZIP format  mandates that the data descriptor `SHOULD be stored in ZIP64 format (as 8 byte values) when a file's size exceeds 0xFFFFFFFF`, it also states that `ZIP64 format MAY be used regardless of the size of a file`. For such small entries, the above assumption does not hold.
> 
> This PR augments ZipInputStream.readEnd to also assume 8-byte sizes if the ZipEntry includes a Zip64 extra information field. This brings ZipInputStream into alignment with the APPNOTE format spec:
> 
> 
> When extracting, if the zip64 extended information extra 
> field is present for the file the compressed and 
> uncompressed sizes will be 8 byte values.
> 
> 
> While small Zip64 files with 8-byte data descriptors are not commonly found in the wild, it is possible to create one using the Info-ZIP command line `-fd` flag:
> 
> `echo hello | zip -fd > hello.zip`
> 
> The PR also adds a test verifying that such a small Zip64 file can be parsed by ZipInputStream.

Hi Eirik,

Thank you for your continued work in this area.

I have not had a chance to test this yet but will early next week.  Are you aware of any tools that would create this scenario as to the best of my knowledge we have not encountered one that does as of yet?


The comments below are mainly to provide more clarity for future maintainers.

src/java.base/share/classes/java/util/zip/ZipInputStream.java line 578:

> 576:         if ((flag & 8) == 8) {
> 577:             /* "Data Descriptor" present */
> 578:             if (hasZip64Extra(e)

A comment would be useful here as well

src/java.base/share/classes/java/util/zip/ZipInputStream.java line 627:

> 625:         }
> 626:     }
> 627:     // Returns true if the ZipEntry has a ZIP64 extended information extra field

Please add a comment which clarifies the purpose of this method(such as what you are traversing...etc) and cite the section of the APP.NOTE that is being referenced for future maintainers (similar to the description you created)

src/java.base/share/classes/java/util/zip/ZipInputStream.java line 640:

> 638:                     break; // Invalid size
> 639:                 }
> 640:                 i += size + (2 * Short.BYTES);

Probably  could assign ` 2 * Short.BYTES ` to a variable or create a constant.

test/jdk/java/util/zip/ZipInputStream/Zip64DataDescriptor.java line 50:

> 48: public class Zip64DataDescriptor {
> 49: 
> 50:     private byte[] zip;

Please add a comment to the purpose of the field

test/jdk/java/util/zip/ZipInputStream/Zip64DataDescriptor.java line 89:

> 87:                 0000b20000000000000001000000504b050600000000010001005c000000
> 88:                 560000000000""";
> 89: 

It would be useful to describe how the Zip was created in case it needs to be recreated at a future date

test/jdk/java/util/zip/ZipInputStream/Zip64DataDescriptor.java line 140:

> 138:     }
> 139: 
> 140:     private void setExtraSize(short invalidSize) {

Please add a comment describing the method (and any others without).  As we add new tests, we are trying to. follow this practice the best that we can.

-------------

PR Review: https://git.openjdk.org/jdk/pull/12524#pullrequestreview-1305594238
PR Review Comment: https://git.openjdk.org/jdk/pull/12524#discussion_r1111822893
PR Review Comment: https://git.openjdk.org/jdk/pull/12524#discussion_r1111822289
PR Review Comment: https://git.openjdk.org/jdk/pull/12524#discussion_r1111821880
PR Review Comment: https://git.openjdk.org/jdk/pull/12524#discussion_r1120663321
PR Review Comment: https://git.openjdk.org/jdk/pull/12524#discussion_r1119159694
PR Review Comment: https://git.openjdk.org/jdk/pull/12524#discussion_r1120661558

From alanb at openjdk.org  Wed Mar 29 09:34:39 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 29 Mar 2023 09:34:39 GMT
Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files
In-Reply-To: 
References: 
Message-ID: 

On Sun, 12 Feb 2023 15:41:55 GMT, Eirik Bjorsnos  wrote:

> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the number of compressed or uncompressed bytes read from the inflater is larger than the Zip64 magic value.
> 
> While the ZIP format  mandates that the data descriptor `SHOULD be stored in ZIP64 format (as 8 byte values) when a file's size exceeds 0xFFFFFFFF`, it also states that `ZIP64 format MAY be used regardless of the size of a file`. For such small entries, the above assumption does not hold.
> 
> This PR augments ZipInputStream.readEnd to also assume 8-byte sizes if the ZipEntry includes a Zip64 extra information field. This brings ZipInputStream into alignment with the APPNOTE format spec:
> 
> 
> When extracting, if the zip64 extended information extra 
> field is present for the file the compressed and 
> uncompressed sizes will be 8 byte values.
> 
> 
> While small Zip64 files with 8-byte data descriptors are not commonly found in the wild, it is possible to create one using the Info-ZIP command line `-fd` flag:
> 
> `echo hello | zip -fd > hello.zip`
> 
> The PR also adds a test verifying that such a small Zip64 file can be parsed by ZipInputStream.

This proposed change will require a lot of review cycles and a lot of testing. The current implementation came about because of issues with several zip tools so we have to be very careful changing it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12524#issuecomment-1427082322

From duke at openjdk.org  Wed Mar 29 09:34:41 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 29 Mar 2023 09:34:41 GMT
Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 12 Feb 2023 17:04:51 GMT, Alan Bateman  wrote:

> The current implementation came about because of issues with several zip tools so we have to be very careful changing it.

Thanks for providing historical context, that's very useful!  Do you happen to know a few of the zip tools the current implementation has been tested with?

Let me add that the purpose of the change is mainly to facilitate automated testing of Zip64 features without the need to create ZIP files with sizes exceeding the 0XFFFFFF limit.

(I am not aware of any existing zip tools producing such small Zip64 files, but they would be valid according to the APPNOTE format description)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12524#issuecomment-1427101204

From duke at openjdk.org  Wed Mar 29 09:34:42 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 29 Mar 2023 09:34:42 GMT
Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files
In-Reply-To: 
References: 
Message-ID: 

On Sun, 12 Feb 2023 15:41:55 GMT, Eirik Bjorsnos  wrote:

> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the number of compressed or uncompressed bytes read from the inflater is larger than the Zip64 magic value.
> 
> While the ZIP format  mandates that the data descriptor `SHOULD be stored in ZIP64 format (as 8 byte values) when a file's size exceeds 0xFFFFFFFF`, it also states that `ZIP64 format MAY be used regardless of the size of a file`. For such small entries, the above assumption does not hold.
> 
> This PR augments ZipInputStream.readEnd to also assume 8-byte sizes if the ZipEntry includes a Zip64 extra information field. This brings ZipInputStream into alignment with the APPNOTE format spec:
> 
> 
> When extracting, if the zip64 extended information extra 
> field is present for the file the compressed and 
> uncompressed sizes will be 8 byte values.
> 
> 
> While small Zip64 files with 8-byte data descriptors are not commonly found in the wild, it is possible to create one using the Info-ZIP command line `-fd` flag:
> 
> `echo hello | zip -fd > hello.zip`
> 
> The PR also adds a test verifying that such a small Zip64 file can be parsed by ZipInputStream.

FWIW, i reverted the refactoring and the CRC == SIGEXT support, leaving only the change to how Zip64 format is determined. Perhaps this may make the change somewhat easier to reason about.

The last version of this PR augments the Zip64 check instead of replacing it, further reducing the risk associated with this proposed change.

With the latest version of this PR, I believe we strictly expand the universe of allowable ZIP entries for ZipInputStream. 

The set of added entries is the set of entries where  a Zip64 extra field exists in the Loc, and where the compressed and uncompressed file data sizes do not exceed 0xFFFFFFFF.

Added even stricter validation to hasZip64Extra checking that the extra data field is right-sized for Zip64.

Thanks a lot for looking into this, Lance!

> Are you aware of any tools that would create this scenario as to the best of my knowledge we have not encountered one that does as of yet?

~~The following on my Mac produces a Zip64 file with an 8-byte data descriptor:~~

`echo hellohellohellohellohellohellohellohello | zip > hello.zip`

(The Zip64 mode is triggered by the streaming mode, the use of a data descriptor seems sensitive to the length of the input)

I have updated the test to use a ZIP produced using `zip -fd` as mentioned above.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12524#issuecomment-1427105000
PR Comment: https://git.openjdk.org/jdk/pull/12524#issuecomment-1427115724
PR Comment: https://git.openjdk.org/jdk/pull/12524#issuecomment-1427951442
PR Comment: https://git.openjdk.org/jdk/pull/12524#issuecomment-1440659920
PR Comment: https://git.openjdk.org/jdk/pull/12524#issuecomment-1448869467
PR Comment: https://git.openjdk.org/jdk/pull/12524#issuecomment-1448937656

From duke at openjdk.org  Wed Mar 29 09:34:46 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 29 Mar 2023 09:34:46 GMT
Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 28 Feb 2023 20:48:47 GMT, Eirik Bjorsnos  wrote:

> > Thanks a lot for looking into this, Lance!
> > > Are you aware of any tools that would create this scenario as to the best of my knowledge we have not encountered one that does as of yet?
> > 
> > 
> > The following on my Mac produces a Zip64 file with an 8-byte data descriptor:
> > `echo hellohellohellohellohellohellohellohello | zip > hello.zip`
> 
> Scratch that, I must have looked at the wrong trace output. This produces a file with a Zip64 extra field, but without the Data Descriptor following the File data.

Ok, it turns out `zip` has a `-fd` option (force descriptor). This allows small Zip64 files with Data Descriptors to be created the following way:

`echo hello | zip -fd > hello.zip`

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12524#issuecomment-1448924965

From duke at openjdk.org  Wed Mar 29 09:34:45 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 29 Mar 2023 09:34:45 GMT
Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 28 Feb 2023 20:31:43 GMT, Eirik Bjorsnos  wrote:

> Thanks a lot for looking into this, Lance!
> 
> > Are you aware of any tools that would create this scenario as to the best of my knowledge we have not encountered one that does as of yet?
> 
> The following on my Mac produces a Zip64 file with an 8-byte data descriptor:
> 
> `echo hellohellohellohellohellohellohellohello | zip > hello.zip`

Scratch that, I must have looked at the wrong trace output. This produces a file with a Zip64 extra field, but without the Data Descriptor following the File data. 

At any rate, the motivation for this change is not mainly to support any existing zip producer, but to implement the specification and to allow tests to create small, parseable Zip64 files with 8-byte data descriptors.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12524#issuecomment-1448893609

From duke at openjdk.org  Wed Mar 29 09:34:47 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 29 Mar 2023 09:34:47 GMT
Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 20 Feb 2023 11:28:29 GMT, Lance Andersen  wrote:

>> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the number of compressed or uncompressed bytes read from the inflater is larger than the Zip64 magic value.
>> 
>> While the ZIP format  mandates that the data descriptor `SHOULD be stored in ZIP64 format (as 8 byte values) when a file's size exceeds 0xFFFFFFFF`, it also states that `ZIP64 format MAY be used regardless of the size of a file`. For such small entries, the above assumption does not hold.
>> 
>> This PR augments ZipInputStream.readEnd to also assume 8-byte sizes if the ZipEntry includes a Zip64 extra information field. This brings ZipInputStream into alignment with the APPNOTE format spec:
>> 
>> 
>> When extracting, if the zip64 extended information extra 
>> field is present for the file the compressed and 
>> uncompressed sizes will be 8 byte values.
>> 
>> 
>> While small Zip64 files with 8-byte data descriptors are not commonly found in the wild, it is possible to create one using the Info-ZIP command line `-fd` flag:
>> 
>> `echo hello | zip -fd > hello.zip`
>> 
>> The PR also adds a test verifying that such a small Zip64 file can be parsed by ZipInputStream.
>
> src/java.base/share/classes/java/util/zip/ZipInputStream.java line 578:
> 
>> 576:         if ((flag & 8) == 8) {
>> 577:             /* "Data Descriptor" present */
>> 578:             if (hasZip64Extra(e)
> 
> A comment would be useful here as well

Added a short comment here, although I'm not fully convinced of the usefulness.

> src/java.base/share/classes/java/util/zip/ZipInputStream.java line 627:
> 
>> 625:         }
>> 626:     }
>> 627:     // Returns true if the ZipEntry has a ZIP64 extended information extra field
> 
> Please add a comment which clarifies the purpose of this method(such as what you are traversing...etc) and cite the section of the APP.NOTE that is being referenced for future maintainers (similar to the description you created)

Added a quite extensive explainer in the Javadocs of this method, including a citation of the relevant APPNOTE.txt spec.

> src/java.base/share/classes/java/util/zip/ZipInputStream.java line 640:
> 
>> 638:                     break; // Invalid size
>> 639:                 }
>> 640:                 i += size + (2 * Short.BYTES);
> 
> Probably  could assign ` 2 * Short.BYTES ` to a variable or create a constant.

Extracted to a variable with a comment, also replaced the constant 4 earlier in the method.

> test/jdk/java/util/zip/ZipInputStream/Zip64DataDescriptor.java line 50:
> 
>> 48: public class Zip64DataDescriptor {
>> 49: 
>> 50:     private byte[] zip;
> 
> Please add a comment to the purpose of the field

Comment added.

> test/jdk/java/util/zip/ZipInputStream/Zip64DataDescriptor.java line 89:
> 
>> 87:                 0000b20000000000000001000000504b050600000000010001005c000000
>> 88:                 560000000000""";
>> 89: 
> 
> It would be useful to describe how the Zip was created in case it needs to be recreated at a future date

This Zip was produced using my ZIP stream transformation library. This is not in the JDK, so probably not so useful to reference. Let me see if I can rework the test to use a Zip created using the `zip` streaming mode I described instead, that would allow a more independent reproduction.

> test/jdk/java/util/zip/ZipInputStream/Zip64DataDescriptor.java line 140:
> 
>> 138:     }
>> 139: 
>> 140:     private void setExtraSize(short invalidSize) {
> 
> Please add a comment describing the method (and any others without).  As we add new tests, we are trying to. follow this practice the best that we can.

Added comments for these methods and also for the zip field which I renamed to zip64Zip.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12524#discussion_r1120734693
PR Review Comment: https://git.openjdk.org/jdk/pull/12524#discussion_r1120734271
PR Review Comment: https://git.openjdk.org/jdk/pull/12524#discussion_r1120733599
PR Review Comment: https://git.openjdk.org/jdk/pull/12524#discussion_r1120736858
PR Review Comment: https://git.openjdk.org/jdk/pull/12524#discussion_r1120736283
PR Review Comment: https://git.openjdk.org/jdk/pull/12524#discussion_r1120736656

From forax at openjdk.org  Wed Mar 29 09:55:07 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 29 Mar 2023 09:55:07 GMT
Subject: RFR: 8266571: Sequenced Collections [v2]
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
 <7hyZMdc6JI-92HcIQyh4gFMimualCSo-kSuApHjRPks=.4d53a75e-9caa-448d-a087-d1a03da8130a@github.com>
 
 
 
Message-ID: 

On Wed, 29 Mar 2023 06:52:35 GMT, ExE Boss  wrote:

> There is SortedMap, 
yes, but no sorted "collection". An interface with a special semantic for set, map or list do not have the same impact in term of number of lines to maintain than a collection with a special semantics.

And java.util.Collection is a kind like java.lang.Object, it does not define a real semantics, equals/hashCode are defined in set and list not collection, so it's more that Collection is defined by its lack of semantics. So the same way, it's weird to have two java.lang.Object, it's weird to have two Collections.

> and non?null collection interfaces are unnecessary with JEP Null?Restricted and Nullable Types
i think we are agreeing here, there is no need for a special interface for non-null collections, so why do we need one for ordered collections.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1488287644

From duke at openjdk.org  Wed Mar 29 10:40:17 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 29 Mar 2023 10:40:17 GMT
Subject: RFR: 8266571: Sequenced Collections [v2]
In-Reply-To: <7hyZMdc6JI-92HcIQyh4gFMimualCSo-kSuApHjRPks=.4d53a75e-9caa-448d-a087-d1a03da8130a@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
 <7hyZMdc6JI-92HcIQyh4gFMimualCSo-kSuApHjRPks=.4d53a75e-9caa-448d-a087-d1a03da8130a@github.com>
Message-ID: 

On Sat, 25 Mar 2023 08:19:18 GMT, R?mi Forax  wrote:

> I get that Oracle is rich, but this JEP is not only a burden for Oracle but for the whole community.

I'm going to have to call you out on this one, Remi.

Since both of us are non-native Enlish speakers, I'm going to define "calling out" as drawing critical attention to someone's unacceptable actions or behaviour.

I think judging a contribution based on the contributor's payslip is unacceptable. Some of us might be payed by Oracle. Some by other commercial companies. Some of us don't even have payslips. We're all contributors. Our work should be judged by technical  merits, not payslips.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1488352086

From duke at openjdk.org  Wed Mar 29 10:48:57 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 29 Mar 2023 10:48:57 GMT
Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files [v2]
In-Reply-To: 
References: 
Message-ID: 

> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the number of compressed or uncompressed bytes read from the inflater is larger than the Zip64 magic value.
> 
> While the ZIP format  mandates that the data descriptor `SHOULD be stored in ZIP64 format (as 8 byte values) when a file's size exceeds 0xFFFFFFFF`, it also states that `ZIP64 format MAY be used regardless of the size of a file`. For such small entries, the above assumption does not hold.
> 
> This PR augments ZipInputStream.readEnd to also assume 8-byte sizes if the ZipEntry includes a Zip64 extra information field. This brings ZipInputStream into alignment with the APPNOTE format spec:
> 
> 
> When extracting, if the zip64 extended information extra 
> field is present for the file the compressed and 
> uncompressed sizes will be 8 byte values.
> 
> 
> While small Zip64 files with 8-byte data descriptors are not commonly found in the wild, it is possible to create one using the Info-ZIP command line `-fd` flag:
> 
> `echo hello | zip -fd > hello.zip`
> 
> The PR also adds a test verifying that such a small Zip64 file can be parsed by ZipInputStream.

Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:

  Use block comments instead of javadoc comments to avoid doclint warnings

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12524/files
  - new: https://git.openjdk.org/jdk/pull/12524/files/0633c807..01216ef7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12524&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12524&range=00-01

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/12524.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12524/head:pull/12524

PR: https://git.openjdk.org/jdk/pull/12524

From forax at openjdk.org  Wed Mar 29 11:31:22 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 29 Mar 2023 11:31:22 GMT
Subject: RFR: 8266571: Sequenced Collections [v4]
In-Reply-To: <-BNnKi-AQ6XTBe-GxXIn9Zq7WdROvR9mX73H_gr2rs8=.4c034fa8-781f-4739-ade8-e24f507f55be@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <-BNnKi-AQ6XTBe-GxXIn9Zq7WdROvR9mX73H_gr2rs8=.4c034fa8-781f-4739-ade8-e24f507f55be@github.com>
Message-ID: <2aOEUKoRMGzd9OgSr7www_FPNVczFnP_E7DI4nWITfk=.744a9e1c-79e9-4e77-af5f-fbcd62b3fd01@github.com>

On Tue, 28 Mar 2023 02:37:22 GMT, Stuart Marks  wrote:

>> PR for Sequenced Collections implementation.
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify handling of cached keySet, values, and entrySet views.

Hi Erik,
I think you misunderstood me, currently Oracle supports most of the development of the OpenJDK financially, that's a fact and i'm glad that Oracle has taken that mantle because I'm remembering very well the sad state of Java at the time SUN was dying. 

I believe that introducing the interface SequencedCollection instead of adding the methods to Collection (i get it's not the exact same semantics) have an impact that is too big and will require more work than it should for both the maintainers of the JDK and the maintainers of the libraries having their own implementations of the Java collections.

This has nothing to do with the paycheck of some of us.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1488423778

From duke at openjdk.org  Wed Mar 29 12:10:54 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 29 Mar 2023 12:10:54 GMT
Subject: RFR: 8266571: Sequenced Collections [v4]
In-Reply-To: <2aOEUKoRMGzd9OgSr7www_FPNVczFnP_E7DI4nWITfk=.744a9e1c-79e9-4e77-af5f-fbcd62b3fd01@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <-BNnKi-AQ6XTBe-GxXIn9Zq7WdROvR9mX73H_gr2rs8=.4c034fa8-781f-4739-ade8-e24f507f55be@github.com>
 <2aOEUKoRMGzd9OgSr7www_FPNVczFnP_E7DI4nWITfk=.744a9e1c-79e9-4e77-af5f-fbcd62b3fd01@github.com>
Message-ID: 

On Wed, 29 Mar 2023 11:28:39 GMT, R?mi Forax  wrote:

> Hi Erik, I think you misunderstood me, currently Oracle supports most of the development of the OpenJDK financially, that's a fact and i'm glad that Oracle has taken that mantle because I'm remembering very well the sad state of Java at the time SUN was dying.

Please do not avoid critisism by claiming to be misunderstood. This just annoys me. I'm presenting you feedback. Rather direct and tough feedback, I'll admit. Please embrace this opportunity to improve rather than drafting your defence.   

> I believe that introducing the interface SequencedCollection instead of adding the methods to Collection (i get it's not the exact same semantics) have an impact that is too big and will require more work than it should for both the maintainers of the JDK and the maintainers of the libraries having their own implementations of the Java collections.

Then just say so.
 
> This has nothing to do with the paycheck of some of us.

Fine, then let's agree to try and avoid using that paycheck as an argument for or against the merit of any PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1488481290

From duke at openjdk.org  Wed Mar 29 12:19:18 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 29 Mar 2023 12:19:18 GMT
Subject: RFR: 8304014: Convert
 test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java to testNG [v2]
In-Reply-To: 
References: 
Message-ID: 

> CorruptedZipFiles could benefit from some spring cleaning and a conversion to testNG:
> 
> - The actual tests are moved into their own `@Test` methods, given more meaningful names and a Javadoc comment explaining the constraint being verified
> - The setup code is moved to a `@Before` method, slightly modernized and rewritten to take advantage of `assertEquals` 
> - `checkZipExceptionImpl` is updated to take advantage of `expectThrows`
> - A bunch of constants copied over from `ZipFile` can be deleted since JDK-6225935 has long been fixed

Eirik Bjorsnos 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 ten additional commits since the last revision:

 - Replace the u8, u16, u32 methods with using a little-endian ByteBuffer. Collapse the checkZipException and checkZipExceptionInGetInputStream into one method by always consuming the InputStream. Add a block comment for the assertZipException method.
 - Use block comments instead of javadoc comments
 - Merge branch 'master' into corrupted-zip-files-ng
 - Merge branch 'master' into corrupted-zip-files-ng
 - Give the @BeforeMethod and @AfterMethod more meaningful names
 - Improve comments and method names to help future maintainers understand what these tests verify.
 - Merge branch 'master' into corrupted-zip-files-ng
 - Trim whitespace and fix some spelling
 - Convert test CorruptedZipFiles to testNG and delete ZipFile constants copies which are now obsolete.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12563/files
  - new: https://git.openjdk.org/jdk/pull/12563/files/f2fd8974..e46fc5b3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12563&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12563&range=00-01

  Stats: 96611 lines in 1305 files changed: 56104 ins; 28357 del; 12150 mod
  Patch: https://git.openjdk.org/jdk/pull/12563.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12563/head:pull/12563

PR: https://git.openjdk.org/jdk/pull/12563

From forax at openjdk.org  Wed Mar 29 13:13:05 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 29 Mar 2023 13:13:05 GMT
Subject: RFR: 8266571: Sequenced Collections [v4]
In-Reply-To: <-BNnKi-AQ6XTBe-GxXIn9Zq7WdROvR9mX73H_gr2rs8=.4c034fa8-781f-4739-ade8-e24f507f55be@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <-BNnKi-AQ6XTBe-GxXIn9Zq7WdROvR9mX73H_gr2rs8=.4c034fa8-781f-4739-ade8-e24f507f55be@github.com>
Message-ID: 

On Tue, 28 Mar 2023 02:37:22 GMT, Stuart Marks  wrote:

>> PR for Sequenced Collections implementation.
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify handling of cached keySet, values, and entrySet views.

This is taking a personal turn and I do not see the point of discussing that matter here, so please send me an email at forax at univ-mlv.fr

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1488580845

From duke at openjdk.org  Wed Mar 29 13:20:14 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 29 Mar 2023 13:20:14 GMT
Subject: RFR: 8266571: Sequenced Collections [v4]
In-Reply-To: <-BNnKi-AQ6XTBe-GxXIn9Zq7WdROvR9mX73H_gr2rs8=.4c034fa8-781f-4739-ade8-e24f507f55be@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <-BNnKi-AQ6XTBe-GxXIn9Zq7WdROvR9mX73H_gr2rs8=.4c034fa8-781f-4739-ade8-e24f507f55be@github.com>
Message-ID: 

On Tue, 28 Mar 2023 02:37:22 GMT, Stuart Marks  wrote:

>> PR for Sequenced Collections implementation.
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify handling of cached keySet, values, and entrySet views.

> This is taking a personal turn and I do not see the point of discussing that matter here, so please send me an email at [forax at univ-mlv.fr](mailto:forax at univ-mlv.fr)

I agree we have both made our case and that a further discussion in this PR is becoming increasingly moot.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1488595053

From dfuchs at openjdk.org  Wed Mar 29 13:25:57 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 29 Mar 2023 13:25:57 GMT
Subject: RFR: 8304014: Convert
 test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java to testNG [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 29 Mar 2023 12:19:18 GMT, Eirik Bjorsnos  wrote:

>> CorruptedZipFiles could benefit from some spring cleaning and a conversion to testNG:
>> 
>> - The actual tests are moved into their own `@Test` methods, given more meaningful names and a Javadoc comment explaining the constraint being verified
>> - The setup code is moved to a `@Before` method, slightly modernized and rewritten to take advantage of `assertEquals` 
>> - `checkZipExceptionImpl` is updated to take advantage of `expectThrows`
>> - A bunch of constants copied over from `ZipFile` can be deleted since JDK-6225935 has long been fixed
>
> Eirik Bjorsnos 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 ten additional commits since the last revision:
> 
>  - Replace the u8, u16, u32 methods with using a little-endian ByteBuffer. Collapse the checkZipException and checkZipExceptionInGetInputStream into one method by always consuming the InputStream. Add a block comment for the assertZipException method.
>  - Use block comments instead of javadoc comments
>  - Merge branch 'master' into corrupted-zip-files-ng
>  - Merge branch 'master' into corrupted-zip-files-ng
>  - Give the @BeforeMethod and @AfterMethod more meaningful names
>  - Improve comments and method names to help future maintainers understand what these tests verify.
>  - Merge branch 'master' into corrupted-zip-files-ng
>  - Trim whitespace and fix some spelling
>  - Convert test CorruptedZipFiles to testNG and delete ZipFile constants copies which are now obsolete.

High level comment: these days we usually try to use junit 5 / jupiter instead of TestNG.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12563#issuecomment-1488606123

From duke at openjdk.org  Wed Mar 29 13:32:50 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 29 Mar 2023 13:32:50 GMT
Subject: RFR: 8304014: Convert
 test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java to testNG [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 29 Mar 2023 13:23:19 GMT, Daniel Fuchs  wrote:

> High level comment: these days we usually try to use junit 5 / jupiter instead of TestNG.

I think my choice of testNG here might have been influenced by other ZIP area tests using testNG. I guess a rewrite to junit should be pretty straightforward.

@LanceAndersen Do you have any opinion on junit/testNG for tests like this?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12563#issuecomment-1488617459

From rriggs at openjdk.org  Wed Mar 29 13:53:42 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 29 Mar 2023 13:53:42 GMT
Subject: RFR: 8303392: Runtime.exec and ProcessBuilder.start should use
 System logger [v8]
In-Reply-To: <-1i11ZrHHgzUbCSa_RXAcGKNfgtpdui--bltZ4Ujs2A=.f5f1a7e2-d3ec-4f64-9b1e-317ef2f24ef1@github.com>
References: <-1i11ZrHHgzUbCSa_RXAcGKNfgtpdui--bltZ4Ujs2A=.f5f1a7e2-d3ec-4f64-9b1e-317ef2f24ef1@github.com>
Message-ID: 

> Runtime.exec and ProcessBuilder.start methods create a new operating system process with the program and arguments. Many applications configure a logging subsystem to monitor application events. Logging a process start message with the program, arguments, and stack trace can identify the caller and purpose.
> Logging the process start event is complementary to the process start event generated for JFR (Java Flight Recorder).

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Update wording to add "In the reference implementation" qualification
  of the logging as recommended by the CSR review.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12862/files
  - new: https://git.openjdk.org/jdk/pull/12862/files/32f05be9..105eb174

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12862&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12862&range=06-07

  Stats: 16 lines in 2 files changed: 8 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/12862.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12862/head:pull/12862

PR: https://git.openjdk.org/jdk/pull/12862

From rriggs at openjdk.org  Wed Mar 29 14:00:32 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 29 Mar 2023 14:00:32 GMT
Subject: RFR: 8305157: The java.util.Arrays class should be declared final
In-Reply-To: 
References: 
Message-ID: 

On Wed, 29 Mar 2023 08:13:06 GMT, Per Minborg  wrote:

> Non-instantiable utility classes should be declared `final` and have a private constructors. 
> 
> See Effective Java, Third Edition, Joshua Bloch (for example, Item 19 or Item 22).

Marked as reviewed by rriggs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13221#pullrequestreview-1363175535

From duke at openjdk.org  Wed Mar 29 14:04:49 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 29 Mar 2023 14:04:49 GMT
Subject: RFR: 8304014: Convert
 test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java to testNG [v2]
In-Reply-To: 
References: 
 
Message-ID: <1BuZYTJHlqYEw6eQljlDkGtSIHMdu4BSbA50VLbl748=.f445f7a9-84f7-4a90-8738-fc9039246680@github.com>

On Mon, 27 Feb 2023 21:13:47 GMT, Lance Andersen  wrote:

>> Eirik Bjorsnos 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 ten additional commits since the last revision:
>> 
>>  - Replace the u8, u16, u32 methods with using a little-endian ByteBuffer. Collapse the checkZipException and checkZipExceptionInGetInputStream into one method by always consuming the InputStream. Add a block comment for the assertZipException method.
>>  - Use block comments instead of javadoc comments
>>  - Merge branch 'master' into corrupted-zip-files-ng
>>  - Merge branch 'master' into corrupted-zip-files-ng
>>  - Give the @BeforeMethod and @AfterMethod more meaningful names
>>  - Improve comments and method names to help future maintainers understand what these tests verify.
>>  - Merge branch 'master' into corrupted-zip-files-ng
>>  - Trim whitespace and fix some spelling
>>  - Convert test CorruptedZipFiles to testNG and delete ZipFile constants copies which are now obsolete.
>
> Hi Eirik,
> 
> Thank you for  your suggested changes to this test.
> 
> I think if we are going to re-work this test, we should go further including improving the comments for future maintainers
> 
> I made a quick pass and some initial thoughts are below
> 
> Best
> Lance

> @LanceAndersen Do you have any opinion on junit/testNG for tests like this?

Here's a junit version for consideration:

https://github.com/eirbjo/jdk/blob/corrupted-zip-files-ng-junit/test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12563#issuecomment-1488678652

From jvernee at openjdk.org  Wed Mar 29 14:45:11 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 29 Mar 2023 14:45:11 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v15]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 29 Mar 2023 08:55:08 GMT, Per Minborg  wrote:

>> API changes for the FFM API (third preview)
>> 
>> Specdiff:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
>> 
>> Javadoc:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup finality

Marked as reviewed by jvernee (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13079#pullrequestreview-1363295684

From lancea at openjdk.org  Wed Mar 29 14:55:07 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 29 Mar 2023 14:55:07 GMT
Subject: Integrated: 8304990: unnecessary dash in @param gives double-dash in
 docs
In-Reply-To: 
References: 
Message-ID: 

On Tue, 28 Mar 2023 21:48:23 GMT, Lance Andersen  wrote:

> Please review this trivial change which removes a redundant `-` from an `@param` and cleans up the formatting  for the `isValid` method.
> 
> 
> It looks like there is some additional formatting clean up that can be done but I will handle that under a separate PR.

This pull request has now been integrated.

Changeset: 2fa09333
Author:    Lance Andersen 
URL:       https://git.openjdk.org/jdk/commit/2fa09333ef0ac2dc1e44292f8d45d4571cb22cca
Stats:     6 lines in 1 file changed: 0 ins; 1 del; 5 mod

8304990: unnecessary dash in @param gives double-dash in docs

Reviewed-by: bpb, naoto

-------------

PR: https://git.openjdk.org/jdk/pull/13217

From jlaskey at openjdk.org  Wed Mar 29 14:57:06 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 29 Mar 2023 14:57:06 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v51]
In-Reply-To: 
References: 
Message-ID: 

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 69 commits:

 - Merge branch 'master' into 8285932
 - Update StringTemplate.combine javadoc
 - Requested review changes.
 - Clean up list construction
 - Review recommended changes
 - Tidy javadoc
 - Rename StringTemplate classes
 - Merge branch 'master' into 8285932
 - Correction
 - Merge branch 'master' into 8285932
 - ... and 59 more: https://git.openjdk.org/jdk/compare/50a995f0...3e1cc74a

-------------

Changes: https://git.openjdk.org/jdk/pull/10889/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=50
  Stats: 9255 lines in 75 files changed: 9156 ins; 24 del; 75 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From bpb at openjdk.org  Wed Mar 29 15:01:32 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 29 Mar 2023 15:01:32 GMT
Subject: RFR: 8305157: The java.util.Arrays class should be declared final
In-Reply-To: 
References: 
Message-ID: 

On Wed, 29 Mar 2023 08:13:06 GMT, Per Minborg  wrote:

> Non-instantiable utility classes should be declared `final` and have a private constructors. 
> 
> See Effective Java, Third Edition, Joshua Bloch (for example, Item 19 or Item 22).

Marked as reviewed by bpb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13221#pullrequestreview-1363333102

From prappo at openjdk.org  Wed Mar 29 15:07:33 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 29 Mar 2023 15:07:33 GMT
Subject: RFR: 8305157: The java.util.Arrays class should be declared final
In-Reply-To: 
References: 
 <1_vg3znW3bcx-IBHXt6DQetOvIwtVvZ90wlQJ_Jak4s=.c227fad8-4670-4b44-a2da-aa4e5fc7215e@github.com>
 
 
Message-ID: <98uOyHur5ntDIK80QfLTqr7Sx6RLofx0giL4dF80UAE=.70127ed8-fa85-498a-9ab2-9c165c1606f4@github.com>

On Wed, 29 Mar 2023 09:03:58 GMT, Alan Bateman  wrote:

> > I thought the change would trigger a change in the public API as the modifiers are changed for the class. This would likely be picked up by compatibility checks and so, a CSR would be needed?
> 
> It's not a compatibility issue but a CSR is needed to track the change to the signature.

Not that I disagree with this PR, but it would be interesting to see rationale for it in CSR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13221#issuecomment-1488804341

From bpb at openjdk.org  Wed Mar 29 15:12:03 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 29 Mar 2023 15:12:03 GMT
Subject: RFR: 8298619: java/io/File/GetXSpace.java is failing [v3]
In-Reply-To: <2d5h6HANV8vMQbQnVvsuiYiO_n1IG-2zQuz-facvwK0=.ca21cf4e-5f06-4893-a115-c9adb5310fff@github.com>
References: <6LnAAIclo5mZZgba4XUSTSc72vyNrBinzUlO9-kJXbU=.fe0c5e94-9e36-4484-b8e7-0f19cb10cb05@github.com>
 <2d5h6HANV8vMQbQnVvsuiYiO_n1IG-2zQuz-facvwK0=.ca21cf4e-5f06-4893-a115-c9adb5310fff@github.com>
Message-ID: 

On Mon, 27 Feb 2023 22:05:20 GMT, Brian Burkhalter  wrote:

>> Modify the `Space` instances used for size comparison to be created with total number of bytes derived from the Windows `diskFree` utility instead of Cygwin?s `df`.
>
> Brian Burkhalter 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:
> 
>  - 8298619: Change getSpace0() to return a boolean; print warning if total size is estimated instead of exact
>  - Merge
>  - 8298619: Load GetDiskSpaceInformationW dynamically
>  - 8298619: Replace df and diskFree with native calls
>  - 8298619: java/io/File/GetXSpace.java is failing

> This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity.

Ping.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12397#issuecomment-1488814079

From jlahoda at openjdk.org  Wed Mar 29 15:15:40 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 29 Mar 2023 15:15:40 GMT
Subject: RFR: 8304498: JShell does not switch to raw mode when there is no
 /bin/test [v2]
In-Reply-To: 
References: 
 <3zqgbZ1T9WHdEQxojLFpW1eJ0_iqxRnmkyGgu2YiMXw=.cb6b356a-fb3c-484c-aca3-3f09304e30c8@github.com>
 
Message-ID: 

On Tue, 28 Mar 2023 18:33:46 GMT, Andrey Turbanov  wrote:

> @lahodaj was the issue reported to the upstream?

I've just filled:
https://github.com/jline/jline3/issues/839

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13100#issuecomment-1488819982

From lancea at openjdk.org  Wed Mar 29 15:23:59 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 29 Mar 2023 15:23:59 GMT
Subject: RFR: 8304014: Convert
 test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java to testNG [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Wed, 29 Mar 2023 13:30:21 GMT, Eirik Bjorsnos  wrote:

> > High level comment: these days we usually try to use junit 5 / jupiter instead of TestNG.
> 
> I think my choice of testNG here might have been influenced by other ZIP area tests using testNG. I guess a rewrite to junit should be pretty straightforward.
> 
> @LanceAndersen Do you have any opinion on junit/testNG for tests like this?

We have had some discussion about using junit vs testNG but we have not mandated it so I am OK with either but certainly if you would like to move to junit as it should be fairly straight forward for this test, I think that would be nice

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12563#issuecomment-1488832703

From lancea at openjdk.org  Wed Mar 29 15:27:32 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 29 Mar 2023 15:27:32 GMT
Subject: RFR: 8304014: Convert
 test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java to testNG [v2]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Wed, 29 Mar 2023 15:21:04 GMT, Lance Andersen  wrote:

>>> High level comment: these days we usually try to use junit 5 / jupiter instead of TestNG.
>> 
>> I think my choice of testNG here might have been influenced by other ZIP area tests using testNG. I guess a rewrite to junit should be pretty straightforward.
>> 
>> @LanceAndersen Do you have any opinion on junit/testNG for tests like this?
>
>> > High level comment: these days we usually try to use junit 5 / jupiter instead of TestNG.
>> 
>> I think my choice of testNG here might have been influenced by other ZIP area tests using testNG. I guess a rewrite to junit should be pretty straightforward.
>> 
>> @LanceAndersen Do you have any opinion on junit/testNG for tests like this?
> 
> We have had some discussion about using junit vs testNG but we have not mandated it so I am OK with either but certainly if you would like to move to junit as it should be fairly straight forward for this test, I think that would be nice

> > @LanceAndersen Do you have any opinion on junit/testNG for tests like this?
> 
> Here's a junit version for consideration:
> 
> https://github.com/eirbjo/jdk/blob/corrupted-zip-files-ng-junit/test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java

Let's go with reviewing this version,  Thank you for the update Eirik

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12563#issuecomment-1488838303

From jlaskey at openjdk.org  Wed Mar 29 15:46:34 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 29 Mar 2023 15:46:34 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v52]
In-Reply-To: 
References: 
Message-ID: 

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Update combine example

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/3e1cc74a..67ffbccc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=51
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=50-51

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From stsypanov at openjdk.org  Wed Mar 29 16:09:34 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Wed, 29 Mar 2023 16:09:34 GMT
Subject: RFR: 8301492: Modernize equals() method of ResourceBundle.CacheKey
 and Bundles.CacheKey [v3]
In-Reply-To: 
References: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
 
Message-ID: 

On Wed, 1 Feb 2023 10:36:12 GMT, Sergey Tsypanov  wrote:

>> `ResourceBundle.CacheKey.equals()` and `Bundles.CacheKey.equals()` are quire outdated. This simple clean-up modernizes them.
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore logic

Let's wait

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12328#issuecomment-1488898753

From rgiulietti at openjdk.org  Wed Mar 29 16:12:31 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 29 Mar 2023 16:12:31 GMT
Subject: RFR: 8305157: The java.util.Arrays class should be declared final
In-Reply-To: 
References: 
Message-ID: 

On Wed, 29 Mar 2023 08:13:06 GMT, Per Minborg  wrote:

> Non-instantiable utility classes should be declared `final` and have a private constructors. 
> 
> See Effective Java, Third Edition, Joshua Bloch (for example, Item 19 or Item 22).

Would it make sense to throw an `AssertionError` in the constructor? Just in case...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13221#issuecomment-1488903069

From rriggs at openjdk.org  Wed Mar 29 16:13:35 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 29 Mar 2023 16:13:35 GMT
Subject: RFR: 8298619: java/io/File/GetXSpace.java is failing [v3]
In-Reply-To: <2d5h6HANV8vMQbQnVvsuiYiO_n1IG-2zQuz-facvwK0=.ca21cf4e-5f06-4893-a115-c9adb5310fff@github.com>
References: <6LnAAIclo5mZZgba4XUSTSc72vyNrBinzUlO9-kJXbU=.fe0c5e94-9e36-4484-b8e7-0f19cb10cb05@github.com>
 <2d5h6HANV8vMQbQnVvsuiYiO_n1IG-2zQuz-facvwK0=.ca21cf4e-5f06-4893-a115-c9adb5310fff@github.com>
Message-ID: 

On Mon, 27 Feb 2023 22:05:20 GMT, Brian Burkhalter  wrote:

>> Modify the `Space` instances used for size comparison to be created with total number of bytes derived from the Windows `diskFree` utility instead of Cygwin?s `df`.
>
> Brian Burkhalter 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:
> 
>  - 8298619: Change getSpace0() to return a boolean; print warning if total size is estimated instead of exact
>  - Merge
>  - 8298619: Load GetDiskSpaceInformationW dynamically
>  - 8298619: Replace df and diskFree with native calls
>  - 8298619: java/io/File/GetXSpace.java is failing

test/jdk/java/io/File/GetXSpace.java line 278:

> 276:                 fail(s.name() + " free space (quota)", fs, ">", s.size());
> 277:             } else {
> 278:                 pass();

Can the inverted check and if/else clauses be swapped. It would read more naturally as:

 if (windows()) {
    ...windows code...
 } else {
    ... non-windows code...
 }

test/jdk/java/io/File/libGetXSpace.c line 66:

> 64:     if (chars == NULL) {
> 65:         JNU_ThrowByNameWithLastError(env, "java/lang/RuntimeException",
> 66:                                      "GetStringChars");

Add a `return JNI_FALSE`; otherwise it falls through.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12397#discussion_r1152181659
PR Review Comment: https://git.openjdk.org/jdk/pull/12397#discussion_r1152177771

From rriggs at openjdk.org  Wed Mar 29 16:19:28 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 29 Mar 2023 16:19:28 GMT
Subject: RFR: 8305157: The java.util.Arrays class should be declared final
In-Reply-To: 
References: 
Message-ID: <8tu_-ePSofVeKUwlinVZE7caVLQtxLa_-Cv9jEvX4Fo=.7c192ba6-56df-47f9-8785-62b0ee488f6b@github.com>

On Wed, 29 Mar 2023 08:13:06 GMT, Per Minborg  wrote:

> Non-instantiable utility classes should be declared `final` and have a private constructors. 
> 
> See Effective Java, Third Edition, Joshua Bloch (for example, Item 19 or Item 22).

The CSR implies that java.util.Arrays has a non-private constructor but it does.
The CSR should mention that the constructor is private and the Array cannot be subclassed as part of the compatibility comments.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13221#issuecomment-1488909617

From rriggs at openjdk.org  Wed Mar 29 16:19:30 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 29 Mar 2023 16:19:30 GMT
Subject: RFR: 8305157: The java.util.Arrays class should be declared final
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 29 Mar 2023 16:09:18 GMT, Raffaello Giulietti  wrote:

> 



> Would it make sense to throw an `AssertionError` in the constructor? Just in case...

It hardly seems worth the bytecode; the constructor could only be invoked by breaking in using reflection and the result would be an instance with no instance methods.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13221#issuecomment-1488911733

From naoto at openjdk.org  Wed Mar 29 16:23:37 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 29 Mar 2023 16:23:37 GMT
Subject: RFR: 8304840: Dangling `CharacterCodingException` in a few javadoc
 descriptions [v2]
In-Reply-To: 
References: 
Message-ID: 

> Fixing a documentation bug for `CharacterCodingException` without any description to it as attached. A corresponding CSR is also drafted.
> 
> ![Screenshot 2023-03-28 at 11 19 00 AM](https://user-images.githubusercontent.com/3122603/228332508-74606c64-bce1-4135-a4cf-b0c76b902676.png)

Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - Merge branch 'master' into JDK-8304840-CharacterCodingException
 - Duplicate descriptions in CharacterCodingException
 - 8304840: Dangling `CharacterCodingException` in a few javadoc descriptions

-------------

Changes: https://git.openjdk.org/jdk/pull/13214/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13214&range=01
  Stats: 15 lines in 2 files changed: 14 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13214.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13214/head:pull/13214

PR: https://git.openjdk.org/jdk/pull/13214

From naoto at openjdk.org  Wed Mar 29 16:23:39 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 29 Mar 2023 16:23:39 GMT
Subject: Integrated: 8304840: Dangling `CharacterCodingException` in a few
 javadoc descriptions
In-Reply-To: 
References: 
Message-ID: 

On Tue, 28 Mar 2023 18:25:21 GMT, Naoto Sato  wrote:

> Fixing a documentation bug for `CharacterCodingException` without any description to it as attached. A corresponding CSR is also drafted.
> 
> ![Screenshot 2023-03-28 at 11 19 00 AM](https://user-images.githubusercontent.com/3122603/228332508-74606c64-bce1-4135-a4cf-b0c76b902676.png)

This pull request has now been integrated.

Changeset: e3855d00
Author:    Naoto Sato 
URL:       https://git.openjdk.org/jdk/commit/e3855d005408945ea00e3bc38a0f10bef45cd627
Stats:     15 lines in 2 files changed: 14 ins; 0 del; 1 mod

8304840: Dangling `CharacterCodingException` in a few javadoc descriptions

Reviewed-by: alanb, iris, rriggs, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/13214

From naoto at openjdk.org  Wed Mar 29 16:24:33 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 29 Mar 2023 16:24:33 GMT
Subject: RFR: 8304976: Optimize
 DateTimeFormatterBuilder.ZoneTextPrinterParser.getTree() [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 29 Mar 2023 08:16:32 GMT, Sergey Tsypanov  wrote:

>> 1) When `DateTimeFormatter` is reused we don't need to copy `availableZoneIds` and allocate `nonRegionIds` as PrefixTree can be taken from cache. In the related benchmark allocation of `HashSet` takes ~93% of all time, so avoiding it should bring some improvement for cases when we reuse `DateTimeFormatter` to parse a string into `ZoneDateTime`
>> ![image](https://user-images.githubusercontent.com/10835776/219609028-af48eae4-d326-4719-8366-c215baa85835.png)
>> 
>> 2) `DateTimeFormatter` is mostly used with one locale, so `cachedTree` and `cachedTreeCI` can have predefined size.
>> 
>> 
>> @State(Scope.Thread)
>> @BenchmarkMode(Mode.AverageTime)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> public class DateTimeFormatterBenchmark {
>> 
>>     private static final DateTimeFormatter df = new DateTimeFormatterBuilder().appendPattern("yyyy:MM:dd:HH:mm:v").toFormatter();
>>     private static final String TEXT = "2015:03:10:12:13:ECT";
>> 
>>     @Setup
>>     public void setUp() {
>>         ZonedDateTime.parse(TEXT, df);
>>     }
>> 
>>     @Benchmark
>>     public ZonedDateTime parse() {
>>         return ZonedDateTime.parse(TEXT, df);
>>     }
>> }
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8304745: Fix package

LGTM

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/12612#pullrequestreview-1363506079

From rgiulietti at openjdk.org  Wed Mar 29 16:27:31 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 29 Mar 2023 16:27:31 GMT
Subject: RFR: 8305157: The java.util.Arrays class should be declared final
In-Reply-To: 
References: 
Message-ID: 

On Wed, 29 Mar 2023 08:13:06 GMT, Per Minborg  wrote:

> Non-instantiable utility classes should be declared `final` and have a private constructors. 
> 
> See Effective Java, Third Edition, Joshua Bloch (for example, Item 19 or Item 22).

In some future, one could mistakenly instantiate the class from some new method in the class itself.
Throwing protects against such mistakes already during testing, avoiding a reviewer to purposely checking that the empty constructor is never invoked.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13221#issuecomment-1488920408

From darcy at openjdk.org  Wed Mar 29 16:38:32 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 29 Mar 2023 16:38:32 GMT
Subject: RFR: 8305157: The java.util.Arrays class should be declared final
In-Reply-To: 
References: 
Message-ID: 

On Wed, 29 Mar 2023 08:13:06 GMT, Per Minborg  wrote:

> Non-instantiable utility classes should be declared `final` and have a private constructors. 
> 
> See Effective Java, Third Edition, Joshua Bloch (for example, Item 19 or Item 22).

> 

There are numerous examples in the JDK where we have the lone private constructor throw an exception to make sure the class isn't instantiated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13221#issuecomment-1488934132

From shade at openjdk.org  Wed Mar 29 16:44:34 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 29 Mar 2023 16:44:34 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity
Message-ID: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>

Java API has the `Thread.sleep(millis, nanos)` method exposed to users. The documentation for that method clearly says the precision and accuracy are dependent on the underlying system behavior. However, it always rounds up `nanos` to 1ms when doing the actual sleep. This means users cannot do the micro-second precision sleeps, even when the underlying platform allows it. Sub-millisecond sleeps are useful to build interesting primitives, like the rate limiters that run with >1000 RPS.

When faced with this, some users reach for more awkward APIs like `java.util.concurrent.locks.LockSupport.parkNanos`. The use of that API for sleeps is not in line with its intent, and while it "seems to work", it might have interesting interactions with other uses of `LockSupport`. Additionally, these "sleeps" are no longer visible to monitoring tools as "normal sleeps", e.g. as `Thread.sleep` events. Therefore, it would be prudent to improve current `Thread.sleep(millis, nanos)` for sub-millisecond granularity. 

Fortunately, the underlying code is almost ready for this, at least on POSIX side. I skipped Windows paths, because its timers are still no good. Note that on both Linux and MacOS timers oversleep by about 50us. I have a few ideas how to improve the accuracy for them, which would be a topic for a separate PR.

Motivational improvements on new benchmark below:

m6g.9xlarge (Linux, Xeon, x86_64):


Benchmark                 (sleep)  Mode  Cnt           Score       Error  Units

# ========= no regressions for Thread.sleep(millis)

# Baseline
ThreadSleep.millis             0  avgt    5         463.606 ?     8.256  ns/op
ThreadSleep.millis             1  avgt    5         459.434 ?     0.453  ns/op
ThreadSleep.millis            10  avgt    5         462.828 ?     1.283  ns/op
ThreadSleep.millis           100  avgt    5         459.495 ?     3.244  ns/op
ThreadSleep.millis          1000  avgt    5         457.962 ?     5.769  ns/op
ThreadSleep.millis         10000  avgt    5         457.960 ?     1.195  ns/op
ThreadSleep.millis        100000  avgt    5         459.197 ?     3.054  ns/op
ThreadSleep.millis       1000000  avgt    5     1058342.873 ?   304.169  ns/op
ThreadSleep.millis      10000000  avgt    5    10059945.148 ?  1642.411  ns/op
ThreadSleep.millis     100000000  avgt    5   100062181.340 ?  1863.186  ns/op
ThreadSleep.millis    1000000000  avgt    5  1000070015.600 ? 11379.631  ns/op

# Patched
ThreadSleep.millis             0  avgt    5         461.295 ?     6.700  ns/op
ThreadSleep.millis             1  avgt    5         463.383 ?     3.065  ns/op
ThreadSleep.millis            10  avgt    5         468.109 ?     1.607  ns/op
ThreadSleep.millis           100  avgt    5         467.316 ?     0.270  ns/op
ThreadSleep.millis          1000  avgt    5         461.999 ?     2.341  ns/op
ThreadSleep.millis         10000  avgt    5         465.075 ?     0.324  ns/op
ThreadSleep.millis        100000  avgt    5         462.588 ?     5.321  ns/op
ThreadSleep.millis       1000000  avgt    5     1058285.440 ?   409.376  ns/op
ThreadSleep.millis      10000000  avgt    5    10060437.490 ?   177.754  ns/op
ThreadSleep.millis     100000000  avgt    5   100060665.980 ?  1167.514  ns/op
ThreadSleep.millis    1000000000  avgt    5  1000071917.300 ? 17438.906  ns/op

# ========= Significant improvements for Thread.sleep(millis, nanos)

# Baseline
ThreadSleep.millisNanos           0  avgt    5         462.831 ?     0.251  ns/op
ThreadSleep.millisNanos           1  avgt    5     1058708.668 ?   960.683  ns/op
ThreadSleep.millisNanos          10  avgt    5     1058364.414 ?   197.700  ns/op
ThreadSleep.millisNanos         100  avgt    5     1058451.889 ?   561.979  ns/op
ThreadSleep.millisNanos        1000  avgt    5     1058372.010 ?    96.867  ns/op
ThreadSleep.millisNanos       10000  avgt    5     1058354.100 ?   297.148  ns/op
ThreadSleep.millisNanos      100000  avgt    5     1058485.092 ?  1093.340  ns/op
ThreadSleep.millisNanos     1000000  avgt    5     1059004.036 ?  1899.950  ns/op
ThreadSleep.millisNanos    10000000  avgt    5    10059733.302 ?  1725.908  ns/op
ThreadSleep.millisNanos   100000000  avgt    5   100063327.840 ?  6244.805  ns/op
ThreadSleep.millisNanos  1000000000  avgt    5  1000074542.300 ? 17898.173  ns/op

# Patched
ThreadSleep.millisNanos           0  avgt    5         467.968 ?     9.202  ns/op
ThreadSleep.millisNanos           1  avgt    5         579.448 ?     1.363  ns/op
ThreadSleep.millisNanos          10  avgt    5         577.656 ?     0.278  ns/op
ThreadSleep.millisNanos         100  avgt    5       58092.815 ?  2410.401  ns/op
ThreadSleep.millisNanos        1000  avgt    5       58592.249 ?   189.232  ns/op
ThreadSleep.millisNanos       10000  avgt    5       67668.688 ?   591.365  ns/op
ThreadSleep.millisNanos      100000  avgt    5      158143.164 ?  2281.540  ns/op
ThreadSleep.millisNanos     1000000  avgt    5     1058508.682 ?   155.767  ns/op
ThreadSleep.millisNanos    10000000  avgt    5    10059979.272 ?  1095.207  ns/op
ThreadSleep.millisNanos   100000000  avgt    5   100066844.180 ?  4287.440  ns/op
ThreadSleep.millisNanos  1000000000  avgt    5  1000075313.100 ?  9665.656  ns/op


m6g.4xlarge (Linux, Graviton, AArch64):


# ========= no regressions for Thread.sleep(millis)

# Baseline
ThreadSleep.millis             0  avgt    5         429.403 ?    24.947  ns/op
ThreadSleep.millis             1  avgt    5         427.533 ?     7.969  ns/op
ThreadSleep.millis            10  avgt    5         438.464 ?    10.277  ns/op
ThreadSleep.millis           100  avgt    5         425.626 ?     3.371  ns/op
ThreadSleep.millis          1000  avgt    5         426.465 ?     4.501  ns/op
ThreadSleep.millis         10000  avgt    5         427.235 ?     6.916  ns/op
ThreadSleep.millis        100000  avgt    5         430.311 ?     4.073  ns/op
ThreadSleep.millis       1000000  avgt    5     1054808.881 ?   469.409  ns/op
ThreadSleep.millis      10000000  avgt    5    10055497.206 ?  2123.591  ns/op
ThreadSleep.millis     100000000  avgt    5   100059355.520 ? 11597.426  ns/op
ThreadSleep.millis    1000000000  avgt    5  1000073145.400 ?  7659.244  ns/op

# Patched
ThreadSleep.millis             0  avgt    5         429.535 ?     2.597  ns/op
ThreadSleep.millis             1  avgt    5         425.209 ?     3.620  ns/op
ThreadSleep.millis            10  avgt    5         432.416 ?     9.350  ns/op
ThreadSleep.millis           100  avgt    5         432.867 ?     3.978  ns/op
ThreadSleep.millis          1000  avgt    5         426.627 ?     1.064  ns/op
ThreadSleep.millis         10000  avgt    5         427.180 ?     4.691  ns/op
ThreadSleep.millis        100000  avgt    5         438.554 ?     4.271  ns/op
ThreadSleep.millis       1000000  avgt    5     1054693.226 ?   323.240  ns/op
ThreadSleep.millis      10000000  avgt    5    10056408.240 ?  1759.211  ns/op
ThreadSleep.millis     100000000  avgt    5   100062449.780 ? 15133.808  ns/op
ThreadSleep.millis    1000000000  avgt    5  1000066918.500 ? 15817.822  ns/op

# ========= Significant improvements for Thread.sleep(millis, nanos)

# Baseline
ThreadSleep.millisNanos           0  avgt    5         439.163 ?     5.559  ns/op
ThreadSleep.millisNanos           1  avgt    5     1054751.231 ?   431.842  ns/op
ThreadSleep.millisNanos          10  avgt    5     1054640.725 ?   525.901  ns/op
ThreadSleep.millisNanos         100  avgt    5     1054807.619 ?  1009.104  ns/op
ThreadSleep.millisNanos        1000  avgt    5     1054894.829 ?  1946.551  ns/op
ThreadSleep.millisNanos       10000  avgt    5     1054765.444 ?   701.873  ns/op
ThreadSleep.millisNanos      100000  avgt    5     1054707.758 ?   619.054  ns/op
ThreadSleep.millisNanos     1000000  avgt    5     1054802.230 ?  1294.035  ns/op
ThreadSleep.millisNanos    10000000  avgt    5    10055265.430 ?  1184.281  ns/op
ThreadSleep.millisNanos   100000000  avgt    5   100057484.300 ?  7960.939  ns/op
ThreadSleep.millisNanos  1000000000  avgt    5  1000062244.700 ? 20244.067  ns/op

# Patched
ThreadSleep.millisNanos           0  avgt    5         426.482 ?    10.284  ns/op
ThreadSleep.millisNanos           1  avgt    5         565.819 ?     1.098  ns/op
ThreadSleep.millisNanos          10  avgt    5         564.108 ?     3.493  ns/op
ThreadSleep.millisNanos         100  avgt    5       53698.839 ?   942.506  ns/op
ThreadSleep.millisNanos        1000  avgt    5       55205.929 ?   416.951  ns/op
ThreadSleep.millisNanos       10000  avgt    5       64206.709 ?   382.213  ns/op
ThreadSleep.millisNanos      100000  avgt    5      154477.045 ?   125.316  ns/op
ThreadSleep.millisNanos     1000000  avgt    5     1054889.472 ?  2152.765  ns/op
ThreadSleep.millisNanos    10000000  avgt    5    10055273.582 ?   691.628  ns/op
ThreadSleep.millisNanos   100000000  avgt    5   100058261.300 ?  5222.946  ns/op
ThreadSleep.millisNanos  1000000000  avgt    5  1000065434.000 ? 30213.137  ns/op


MacBook 2021 (MacOS X, M1, AArch64):


# ========= no regressions for Thread.sleep(millis)

# Baseline
Benchmark                 (sleep)  Mode  Cnt           Score          Error  Units
ThreadSleep.millis             0  avgt    5         555,871 ?      525,544  ns/op
ThreadSleep.millis             1  avgt    5         405,761 ?      153,981  ns/op
ThreadSleep.millis            10  avgt    5         403,906 ?      279,245  ns/op
ThreadSleep.millis           100  avgt    5         402,787 ?      223,658  ns/op
ThreadSleep.millis          1000  avgt    5         439,250 ?      374,150  ns/op
ThreadSleep.millis         10000  avgt    5         435,769 ?      352,067  ns/op
ThreadSleep.millis        100000  avgt    5        1853,664 ?     7254,716  ns/op
ThreadSleep.millis       1000000  avgt    5     1364788,214 ?    66446,869  ns/op
ThreadSleep.millis      10000000  avgt    5    11819681,019 ?   473810,685  ns/op
ThreadSleep.millis     100000000  avgt    5   103536901,660 ?  1423282,032  ns/op
ThreadSleep.millis    1000000000  avgt    5  1002995262,600 ?  6576388,880  ns/op

# Patched
ThreadSleep.millis             0  avgt    5         662,597 ?     459,888  ns/op
ThreadSleep.millis             1  avgt    5         433,561 ?     214,850  ns/op
ThreadSleep.millis            10  avgt    5         388,614 ?      65,199  ns/op
ThreadSleep.millis           100  avgt    5         436,823 ?     636,901  ns/op
ThreadSleep.millis          1000  avgt    5         337,046 ?     129,440  ns/op
ThreadSleep.millis         10000  avgt    5         366,557 ?     510,494  ns/op
ThreadSleep.millis        100000  avgt    5         278,339 ?     102,443  ns/op
ThreadSleep.millis       1000000  avgt    5     1520092,133 ?   26217,972  ns/op
ThreadSleep.millis      10000000  avgt    5    13116509,001 ?  855508,621  ns/op
ThreadSleep.millis     100000000  avgt    5   107010708,340 ? 1667080,292  ns/op
ThreadSleep.millis    1000000000  avgt    5  1005412095,700 ? 6141267,753  ns/op

# ========= Significant improvements for Thread.sleep(millis, nanos)

# Baseline
ThreadSleep.millisNanos           0  avgt    5         245,942 ?       44,338  ns/op
ThreadSleep.millisNanos           1  avgt    5     1313354,886 ?    71820,989  ns/op
ThreadSleep.millisNanos          10  avgt    5     1310358,568 ?    42731,583  ns/op
ThreadSleep.millisNanos         100  avgt    5     1335221,078 ?   122031,471  ns/op
ThreadSleep.millisNanos        1000  avgt    5     1313977,625 ?    30683,810  ns/op
ThreadSleep.millisNanos       10000  avgt    5     1553321,472 ?    75181,324  ns/op
ThreadSleep.millisNanos      100000  avgt    5     1553317,573 ?   132998,558  ns/op
ThreadSleep.millisNanos     1000000  avgt    5     1544944,015 ?    41587,129  ns/op
ThreadSleep.millisNanos    10000000  avgt    5    13228565,376 ?   902384,381  ns/op
ThreadSleep.millisNanos   100000000  avgt    5   106866740,840 ?  2518606,524  ns/op
ThreadSleep.millisNanos  1000000000  avgt    5  1006669020,800 ? 10961093,568  ns/op

# Patched
ThreadSleep.millisNanos           0  avgt    5         394,716 ?     310,886  ns/op
ThreadSleep.millisNanos           1  avgt    5        9945,543 ?     905,136  ns/op
ThreadSleep.millisNanos          10  avgt    5        9863,605 ?     557,909  ns/op
ThreadSleep.millisNanos         100  avgt    5        2454,862 ?     323,279  ns/op
ThreadSleep.millisNanos        1000  avgt    5        3834,507 ?    2427,033  ns/op
ThreadSleep.millisNanos       10000  avgt    5       16667,415 ?     508,814  ns/op
ThreadSleep.millisNanos      100000  avgt    5      154202,589 ?     258,406  ns/op
ThreadSleep.millisNanos     1000000  avgt    5     1557886,136 ?  192080,832  ns/op
ThreadSleep.millisNanos    10000000  avgt    5    13077385,237 ?  887650,194  ns/op
ThreadSleep.millisNanos   100000000  avgt    5   106225257,480 ? 3288589,410  ns/op
ThreadSleep.millisNanos  1000000000  avgt    5  1006589558,200 ? 3677828,811  ns/op


Additional testing:
  - [x] New regression test
  - [x] New benchmark
  - [x] Linux x86_64 `tier1`
  - [x] Linux AArch64 `tier1`

-------------

Commit messages:
 - More fixes
 - Fix Windows yet again
 - Helper method should be inline, not static
 - Work

Changes: https://git.openjdk.org/jdk/pull/13225/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13225&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305092
  Stats: 300 lines in 13 files changed: 247 ins; 36 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/13225.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13225/head:pull/13225

PR: https://git.openjdk.org/jdk/pull/13225

From duke at openjdk.org  Wed Mar 29 16:51:51 2023
From: duke at openjdk.org (David M. Lloyd)
Date: Wed, 29 Mar 2023 16:51:51 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity
In-Reply-To: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
Message-ID: 

On Wed, 29 Mar 2023 11:28:53 GMT, Aleksey Shipilev  wrote:

> Java API has the `Thread.sleep(millis, nanos)` method exposed to users. The documentation for that method clearly says the precision and accuracy are dependent on the underlying system behavior. However, it always rounds up `nanos` to 1ms when doing the actual sleep. This means users cannot do the micro-second precision sleeps, even when the underlying platform allows it. Sub-millisecond sleeps are useful to build interesting primitives, like the rate limiters that run with >1000 RPS.
> 
> When faced with this, some users reach for more awkward APIs like `java.util.concurrent.locks.LockSupport.parkNanos`. The use of that API for sleeps is not in line with its intent, and while it "seems to work", it might have interesting interactions with other uses of `LockSupport`. Additionally, these "sleeps" are no longer visible to monitoring tools as "normal sleeps", e.g. as `Thread.sleep` events. Therefore, it would be prudent to improve current `Thread.sleep(millis, nanos)` for sub-millisecond granularity. 
> 
> Fortunately, the underlying code is almost ready for this, at least on POSIX side. I skipped Windows paths, because its timers are still no good. Note that on both Linux and MacOS timers oversleep by about 50us. I have a few ideas how to improve the accuracy for them, which would be a topic for a separate PR.
> 
> Motivational improvements on new benchmark below:
> 
> m6g.9xlarge (Linux, Xeon, x86_64):
> 
> 
> Benchmark                 (sleep)  Mode  Cnt           Score       Error  Units
> 
> # ========= no regressions for Thread.sleep(millis)
> 
> # Baseline
> ThreadSleep.millis             0  avgt    5         463.606 ?     8.256  ns/op
> ThreadSleep.millis             1  avgt    5         459.434 ?     0.453  ns/op
> ThreadSleep.millis            10  avgt    5         462.828 ?     1.283  ns/op
> ThreadSleep.millis           100  avgt    5         459.495 ?     3.244  ns/op
> ThreadSleep.millis          1000  avgt    5         457.962 ?     5.769  ns/op
> ThreadSleep.millis         10000  avgt    5         457.960 ?     1.195  ns/op
> ThreadSleep.millis        100000  avgt    5         459.197 ?     3.054  ns/op
> ThreadSleep.millis       1000000  avgt    5     1058342.873 ?   304.169  ns/op
> ThreadSleep.millis      10000000  avgt    5    10059945.148 ?  1642.411  ns/op
> ThreadSleep.millis     100000000  avgt    5   100062181.340 ?  1863.186  ns/op
> ThreadSleep.millis    1000000000  avgt    5  1000070015.600 ? 11379.631  ns/op
> 
> # Patched
> ThreadSleep.millis             0  avgt    5         461.295 ?     6.700  ns/op
> ThreadSleep.millis             1  avgt    5         463.383 ?     3.065  ns/op
> ThreadSleep.millis            10  avgt    5         468.109 ?     1.607  ns/op
> ThreadSleep.millis           100  avgt    5         467.316 ?     0.270  ns/op
> ThreadSleep.millis          1000  avgt    5         461.999 ?     2.341  ns/op
> ThreadSleep.millis         10000  avgt    5         465.075 ?     0.324  ns/op
> ThreadSleep.millis        100000  avgt    5         462.588 ?     5.321  ns/op
> ThreadSleep.millis       1000000  avgt    5     1058285.440 ?   409.376  ns/op
> ThreadSleep.millis      10000000  avgt    5    10060437.490 ?   177.754  ns/op
> ThreadSleep.millis     100000000  avgt    5   100060665.980 ?  1167.514  ns/op
> ThreadSleep.millis    1000000000  avgt    5  1000071917.300 ? 17438.906  ns/op
> 
> # ========= Significant improvements for Thread.sleep(millis, nanos)
> 
> # Baseline
> ThreadSleep.millisNanos           0  avgt    5         462.831 ?     0.251  ns/op
> ThreadSleep.millisNanos           1  avgt    5     1058708.668 ?   960.683  ns/op
> ThreadSleep.millisNanos          10  avgt    5     1058364.414 ?   197.700  ns/op
> ThreadSleep.millisNanos         100  avgt    5     1058451.889 ?   561.979  ns/op
> ThreadSleep.millisNanos        1000  avgt    5     1058372.010 ?    96.867  ns/op
> ThreadSleep.millisNanos       10000  avgt    5     1058354.100 ?   297.148  ns/op
> ThreadSleep.millisNanos      100000  avgt    5     1058485.092 ?  1093.340  ns/op
> ThreadSleep.millisNanos     1000000  avgt    5     1059004.036 ?  1899.950  ns/op
> ThreadSleep.millisNanos    10000000  avgt    5    10059733.302 ?  1725.908  ns/op
> ThreadSleep.millisNanos   100000000  avgt    5   100063327.840 ?  6244.805  ns/op
> ThreadSleep.millisNanos  1000000000  avgt    5  1000074542.300 ? 17898.173  ns/op
> 
> # Patched
> ThreadSleep.millisNanos           0  avgt    5         467.968 ?     9.202  ns/op
> ThreadSleep.millisNanos           1  avgt    5         579.448 ?     1.363  ns/op
> ThreadSleep.millisNanos          10  avgt    5         577.656 ?     0.278  ns/op
> ThreadSleep.millisNanos         100  avgt    5       58092.815 ?  2410.401  ns/op
> ThreadSleep.millisNanos        1000  avgt    5       58592.249 ?   189.232  ns/op
> ThreadSleep.millisNanos       10000  avgt    5       67668.688 ?   591.365  ns/op
> ThreadSleep.millisNanos      100000  avgt    5      158143.164 ?  2281.540  ns/op
> ThreadSleep.millisNanos     1000000  avgt    5     1058508.682 ?   155.767  ns/op
> ThreadSleep.millisNanos    10000000  avgt    5    10059979.272 ?  1095.207  ns/op
> ThreadSleep.millisNanos   100000000  avgt    5   100066844.180 ?  4287.440  ns/op
> ThreadSleep.millisNanos  1000000000  avgt    5  1000075313.100 ?  9665.656  ns/op
> 
> 
> m6g.4xlarge (Linux, Graviton, AArch64):
> 
> 
> # ========= no regressions for Thread.sleep(millis)
> 
> # Baseline
> ThreadSleep.millis             0  avgt    5         429.403 ?    24.947  ns/op
> ThreadSleep.millis             1  avgt    5         427.533 ?     7.969  ns/op
> ThreadSleep.millis            10  avgt    5         438.464 ?    10.277  ns/op
> ThreadSleep.millis           100  avgt    5         425.626 ?     3.371  ns/op
> ThreadSleep.millis          1000  avgt    5         426.465 ?     4.501  ns/op
> ThreadSleep.millis         10000  avgt    5         427.235 ?     6.916  ns/op
> ThreadSleep.millis        100000  avgt    5         430.311 ?     4.073  ns/op
> ThreadSleep.millis       1000000  avgt    5     1054808.881 ?   469.409  ns/op
> ThreadSleep.millis      10000000  avgt    5    10055497.206 ?  2123.591  ns/op
> ThreadSleep.millis     100000000  avgt    5   100059355.520 ? 11597.426  ns/op
> ThreadSleep.millis    1000000000  avgt    5  1000073145.400 ?  7659.244  ns/op
> 
> # Patched
> ThreadSleep.millis             0  avgt    5         429.535 ?     2.597  ns/op
> ThreadSleep.millis             1  avgt    5         425.209 ?     3.620  ns/op
> ThreadSleep.millis            10  avgt    5         432.416 ?     9.350  ns/op
> ThreadSleep.millis           100  avgt    5         432.867 ?     3.978  ns/op
> ThreadSleep.millis          1000  avgt    5         426.627 ?     1.064  ns/op
> ThreadSleep.millis         10000  avgt    5         427.180 ?     4.691  ns/op
> ThreadSleep.millis        100000  avgt    5         438.554 ?     4.271  ns/op
> ThreadSleep.millis       1000000  avgt    5     1054693.226 ?   323.240  ns/op
> ThreadSleep.millis      10000000  avgt    5    10056408.240 ?  1759.211  ns/op
> ThreadSleep.millis     100000000  avgt    5   100062449.780 ? 15133.808  ns/op
> ThreadSleep.millis    1000000000  avgt    5  1000066918.500 ? 15817.822  ns/op
> 
> # ========= Significant improvements for Thread.sleep(millis, nanos)
> 
> # Baseline
> ThreadSleep.millisNanos           0  avgt    5         439.163 ?     5.559  ns/op
> ThreadSleep.millisNanos           1  avgt    5     1054751.231 ?   431.842  ns/op
> ThreadSleep.millisNanos          10  avgt    5     1054640.725 ?   525.901  ns/op
> ThreadSleep.millisNanos         100  avgt    5     1054807.619 ?  1009.104  ns/op
> ThreadSleep.millisNanos        1000  avgt    5     1054894.829 ?  1946.551  ns/op
> ThreadSleep.millisNanos       10000  avgt    5     1054765.444 ?   701.873  ns/op
> ThreadSleep.millisNanos      100000  avgt    5     1054707.758 ?   619.054  ns/op
> ThreadSleep.millisNanos     1000000  avgt    5     1054802.230 ?  1294.035  ns/op
> ThreadSleep.millisNanos    10000000  avgt    5    10055265.430 ?  1184.281  ns/op
> ThreadSleep.millisNanos   100000000  avgt    5   100057484.300 ?  7960.939  ns/op
> ThreadSleep.millisNanos  1000000000  avgt    5  1000062244.700 ? 20244.067  ns/op
> 
> # Patched
> ThreadSleep.millisNanos           0  avgt    5         426.482 ?    10.284  ns/op
> ThreadSleep.millisNanos           1  avgt    5         565.819 ?     1.098  ns/op
> ThreadSleep.millisNanos          10  avgt    5         564.108 ?     3.493  ns/op
> ThreadSleep.millisNanos         100  avgt    5       53698.839 ?   942.506  ns/op
> ThreadSleep.millisNanos        1000  avgt    5       55205.929 ?   416.951  ns/op
> ThreadSleep.millisNanos       10000  avgt    5       64206.709 ?   382.213  ns/op
> ThreadSleep.millisNanos      100000  avgt    5      154477.045 ?   125.316  ns/op
> ThreadSleep.millisNanos     1000000  avgt    5     1054889.472 ?  2152.765  ns/op
> ThreadSleep.millisNanos    10000000  avgt    5    10055273.582 ?   691.628  ns/op
> ThreadSleep.millisNanos   100000000  avgt    5   100058261.300 ?  5222.946  ns/op
> ThreadSleep.millisNanos  1000000000  avgt    5  1000065434.000 ? 30213.137  ns/op
> 
> 
> MacBook 2021 (MacOS X, M1, AArch64):
> 
> 
> # ========= no regressions for Thread.sleep(millis)
> 
> # Baseline
> Benchmark                 (sleep)  Mode  Cnt           Score          Error  Units
> ThreadSleep.millis             0  avgt    5         555,871 ?      525,544  ns/op
> ThreadSleep.millis             1  avgt    5         405,761 ?      153,981  ns/op
> ThreadSleep.millis            10  avgt    5         403,906 ?      279,245  ns/op
> ThreadSleep.millis           100  avgt    5         402,787 ?      223,658  ns/op
> ThreadSleep.millis          1000  avgt    5         439,250 ?      374,150  ns/op
> ThreadSleep.millis         10000  avgt    5         435,769 ?      352,067  ns/op
> ThreadSleep.millis        100000  avgt    5        1853,664 ?     7254,716  ns/op
> ThreadSleep.millis       1000000  avgt    5     1364788,214 ?    66446,869  ns/op
> ThreadSleep.millis      10000000  avgt    5    11819681,019 ?   473810,685  ns/op
> ThreadSleep.millis     100000000  avgt    5   103536901,660 ?  1423282,032  ns/op
> ThreadSleep.millis    1000000000  avgt    5  1002995262,600 ?  6576388,880  ns/op
> 
> # Patched
> ThreadSleep.millis             0  avgt    5         662,597 ?     459,888  ns/op
> ThreadSleep.millis             1  avgt    5         433,561 ?     214,850  ns/op
> ThreadSleep.millis            10  avgt    5         388,614 ?      65,199  ns/op
> ThreadSleep.millis           100  avgt    5         436,823 ?     636,901  ns/op
> ThreadSleep.millis          1000  avgt    5         337,046 ?     129,440  ns/op
> ThreadSleep.millis         10000  avgt    5         366,557 ?     510,494  ns/op
> ThreadSleep.millis        100000  avgt    5         278,339 ?     102,443  ns/op
> ThreadSleep.millis       1000000  avgt    5     1520092,133 ?   26217,972  ns/op
> ThreadSleep.millis      10000000  avgt    5    13116509,001 ?  855508,621  ns/op
> ThreadSleep.millis     100000000  avgt    5   107010708,340 ? 1667080,292  ns/op
> ThreadSleep.millis    1000000000  avgt    5  1005412095,700 ? 6141267,753  ns/op
> 
> # ========= Significant improvements for Thread.sleep(millis, nanos)
> 
> # Baseline
> ThreadSleep.millisNanos           0  avgt    5         245,942 ?       44,338  ns/op
> ThreadSleep.millisNanos           1  avgt    5     1313354,886 ?    71820,989  ns/op
> ThreadSleep.millisNanos          10  avgt    5     1310358,568 ?    42731,583  ns/op
> ThreadSleep.millisNanos         100  avgt    5     1335221,078 ?   122031,471  ns/op
> ThreadSleep.millisNanos        1000  avgt    5     1313977,625 ?    30683,810  ns/op
> ThreadSleep.millisNanos       10000  avgt    5     1553321,472 ?    75181,324  ns/op
> ThreadSleep.millisNanos      100000  avgt    5     1553317,573 ?   132998,558  ns/op
> ThreadSleep.millisNanos     1000000  avgt    5     1544944,015 ?    41587,129  ns/op
> ThreadSleep.millisNanos    10000000  avgt    5    13228565,376 ?   902384,381  ns/op
> ThreadSleep.millisNanos   100000000  avgt    5   106866740,840 ?  2518606,524  ns/op
> ThreadSleep.millisNanos  1000000000  avgt    5  1006669020,800 ? 10961093,568  ns/op
> 
> # Patched
> ThreadSleep.millisNanos           0  avgt    5         394,716 ?     310,886  ns/op
> ThreadSleep.millisNanos           1  avgt    5        9945,543 ?     905,136  ns/op
> ThreadSleep.millisNanos          10  avgt    5        9863,605 ?     557,909  ns/op
> ThreadSleep.millisNanos         100  avgt    5        2454,862 ?     323,279  ns/op
> ThreadSleep.millisNanos        1000  avgt    5        3834,507 ?    2427,033  ns/op
> ThreadSleep.millisNanos       10000  avgt    5       16667,415 ?     508,814  ns/op
> ThreadSleep.millisNanos      100000  avgt    5      154202,589 ?     258,406  ns/op
> ThreadSleep.millisNanos     1000000  avgt    5     1557886,136 ?  192080,832  ns/op
> ThreadSleep.millisNanos    10000000  avgt    5    13077385,237 ?  887650,194  ns/op
> ThreadSleep.millisNanos   100000000  avgt    5   106225257,480 ? 3288589,410  ns/op
> ThreadSleep.millisNanos  1000000000  avgt    5  1006589558,200 ? 3677828,811  ns/op
> 
> 
> Additional testing:
>   - [x] New regression test
>   - [x] New benchmark
>   - [x] Linux x86_64 `tier1`
>   - [x] Linux AArch64 `tier1`

Are there specific factors which would make it unreasonable to implement `sleep` in terms of `parkNanos`?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13225#issuecomment-1488952226

From rriggs at openjdk.org  Wed Mar 29 16:57:48 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 29 Mar 2023 16:57:48 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity
In-Reply-To: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
Message-ID: <2hw99L82zHuf9I4l22-pcEDp5FqkIZW10uU3ql-F0No=.0886f77f-9dec-4e6d-bfc2-9887d023a875@github.com>

On Wed, 29 Mar 2023 11:28:53 GMT, Aleksey Shipilev  wrote:

> Java API has the `Thread.sleep(millis, nanos)` method exposed to users. The documentation for that method clearly says the precision and accuracy are dependent on the underlying system behavior. However, it always rounds up `nanos` to 1ms when doing the actual sleep. This means users cannot do the micro-second precision sleeps, even when the underlying platform allows it. Sub-millisecond sleeps are useful to build interesting primitives, like the rate limiters that run with >1000 RPS.
> 
> When faced with this, some users reach for more awkward APIs like `java.util.concurrent.locks.LockSupport.parkNanos`. The use of that API for sleeps is not in line with its intent, and while it "seems to work", it might have interesting interactions with other uses of `LockSupport`. Additionally, these "sleeps" are no longer visible to monitoring tools as "normal sleeps", e.g. as `Thread.sleep` events. Therefore, it would be prudent to improve current `Thread.sleep(millis, nanos)` for sub-millisecond granularity. 
> 
> Fortunately, the underlying code is almost ready for this, at least on POSIX side. I skipped Windows paths, because its timers are still no good. Note that on both Linux and MacOS timers oversleep by about 50us. I have a few ideas how to improve the accuracy for them, which would be a topic for a separate PR.
> 
> Motivational improvements on new benchmark below:
> 
> m6g.9xlarge (Linux, Xeon, x86_64):
> 
> 
> Benchmark                 (sleep)  Mode  Cnt           Score       Error  Units
> 
> # ========= no regressions for Thread.sleep(millis)
> 
> # Baseline
> ThreadSleep.millis             0  avgt    5         463.606 ?     8.256  ns/op
> ThreadSleep.millis             1  avgt    5         459.434 ?     0.453  ns/op
> ThreadSleep.millis            10  avgt    5         462.828 ?     1.283  ns/op
> ThreadSleep.millis           100  avgt    5         459.495 ?     3.244  ns/op
> ThreadSleep.millis          1000  avgt    5         457.962 ?     5.769  ns/op
> ThreadSleep.millis         10000  avgt    5         457.960 ?     1.195  ns/op
> ThreadSleep.millis        100000  avgt    5         459.197 ?     3.054  ns/op
> ThreadSleep.millis       1000000  avgt    5     1058342.873 ?   304.169  ns/op
> ThreadSleep.millis      10000000  avgt    5    10059945.148 ?  1642.411  ns/op
> ThreadSleep.millis     100000000  avgt    5   100062181.340 ?  1863.186  ns/op
> ThreadSleep.millis    1000000000  avgt    5  1000070015.600 ? 11379.631  ns/op
> 
> # Patched
> ThreadSleep.millis             0  avgt    5         461.295 ?     6.700  ns/op
> ThreadSleep.millis             1  avgt    5         463.383 ?     3.065  ns/op
> ThreadSleep.millis            10  avgt    5         468.109 ?     1.607  ns/op
> ThreadSleep.millis           100  avgt    5         467.316 ?     0.270  ns/op
> ThreadSleep.millis          1000  avgt    5         461.999 ?     2.341  ns/op
> ThreadSleep.millis         10000  avgt    5         465.075 ?     0.324  ns/op
> ThreadSleep.millis        100000  avgt    5         462.588 ?     5.321  ns/op
> ThreadSleep.millis       1000000  avgt    5     1058285.440 ?   409.376  ns/op
> ThreadSleep.millis      10000000  avgt    5    10060437.490 ?   177.754  ns/op
> ThreadSleep.millis     100000000  avgt    5   100060665.980 ?  1167.514  ns/op
> ThreadSleep.millis    1000000000  avgt    5  1000071917.300 ? 17438.906  ns/op
> 
> # ========= Significant improvements for Thread.sleep(millis, nanos)
> 
> # Baseline
> ThreadSleep.millisNanos           0  avgt    5         462.831 ?     0.251  ns/op
> ThreadSleep.millisNanos           1  avgt    5     1058708.668 ?   960.683  ns/op
> ThreadSleep.millisNanos          10  avgt    5     1058364.414 ?   197.700  ns/op
> ThreadSleep.millisNanos         100  avgt    5     1058451.889 ?   561.979  ns/op
> ThreadSleep.millisNanos        1000  avgt    5     1058372.010 ?    96.867  ns/op
> ThreadSleep.millisNanos       10000  avgt    5     1058354.100 ?   297.148  ns/op
> ThreadSleep.millisNanos      100000  avgt    5     1058485.092 ?  1093.340  ns/op
> ThreadSleep.millisNanos     1000000  avgt    5     1059004.036 ?  1899.950  ns/op
> ThreadSleep.millisNanos    10000000  avgt    5    10059733.302 ?  1725.908  ns/op
> ThreadSleep.millisNanos   100000000  avgt    5   100063327.840 ?  6244.805  ns/op
> ThreadSleep.millisNanos  1000000000  avgt    5  1000074542.300 ? 17898.173  ns/op
> 
> # Patched
> ThreadSleep.millisNanos           0  avgt    5         467.968 ?     9.202  ns/op
> ThreadSleep.millisNanos           1  avgt    5         579.448 ?     1.363  ns/op
> ThreadSleep.millisNanos          10  avgt    5         577.656 ?     0.278  ns/op
> ThreadSleep.millisNanos         100  avgt    5       58092.815 ?  2410.401  ns/op
> ThreadSleep.millisNanos        1000  avgt    5       58592.249 ?   189.232  ns/op
> ThreadSleep.millisNanos       10000  avgt    5       67668.688 ?   591.365  ns/op
> ThreadSleep.millisNanos      100000  avgt    5      158143.164 ?  2281.540  ns/op
> ThreadSleep.millisNanos     1000000  avgt    5     1058508.682 ?   155.767  ns/op
> ThreadSleep.millisNanos    10000000  avgt    5    10059979.272 ?  1095.207  ns/op
> ThreadSleep.millisNanos   100000000  avgt    5   100066844.180 ?  4287.440  ns/op
> ThreadSleep.millisNanos  1000000000  avgt    5  1000075313.100 ?  9665.656  ns/op
> 
> 
> m6g.4xlarge (Linux, Graviton, AArch64):
> 
> 
> # ========= no regressions for Thread.sleep(millis)
> 
> # Baseline
> ThreadSleep.millis             0  avgt    5         429.403 ?    24.947  ns/op
> ThreadSleep.millis             1  avgt    5         427.533 ?     7.969  ns/op
> ThreadSleep.millis            10  avgt    5         438.464 ?    10.277  ns/op
> ThreadSleep.millis           100  avgt    5         425.626 ?     3.371  ns/op
> ThreadSleep.millis          1000  avgt    5         426.465 ?     4.501  ns/op
> ThreadSleep.millis         10000  avgt    5         427.235 ?     6.916  ns/op
> ThreadSleep.millis        100000  avgt    5         430.311 ?     4.073  ns/op
> ThreadSleep.millis       1000000  avgt    5     1054808.881 ?   469.409  ns/op
> ThreadSleep.millis      10000000  avgt    5    10055497.206 ?  2123.591  ns/op
> ThreadSleep.millis     100000000  avgt    5   100059355.520 ? 11597.426  ns/op
> ThreadSleep.millis    1000000000  avgt    5  1000073145.400 ?  7659.244  ns/op
> 
> # Patched
> ThreadSleep.millis             0  avgt    5         429.535 ?     2.597  ns/op
> ThreadSleep.millis             1  avgt    5         425.209 ?     3.620  ns/op
> ThreadSleep.millis            10  avgt    5         432.416 ?     9.350  ns/op
> ThreadSleep.millis           100  avgt    5         432.867 ?     3.978  ns/op
> ThreadSleep.millis          1000  avgt    5         426.627 ?     1.064  ns/op
> ThreadSleep.millis         10000  avgt    5         427.180 ?     4.691  ns/op
> ThreadSleep.millis        100000  avgt    5         438.554 ?     4.271  ns/op
> ThreadSleep.millis       1000000  avgt    5     1054693.226 ?   323.240  ns/op
> ThreadSleep.millis      10000000  avgt    5    10056408.240 ?  1759.211  ns/op
> ThreadSleep.millis     100000000  avgt    5   100062449.780 ? 15133.808  ns/op
> ThreadSleep.millis    1000000000  avgt    5  1000066918.500 ? 15817.822  ns/op
> 
> # ========= Significant improvements for Thread.sleep(millis, nanos)
> 
> # Baseline
> ThreadSleep.millisNanos           0  avgt    5         439.163 ?     5.559  ns/op
> ThreadSleep.millisNanos           1  avgt    5     1054751.231 ?   431.842  ns/op
> ThreadSleep.millisNanos          10  avgt    5     1054640.725 ?   525.901  ns/op
> ThreadSleep.millisNanos         100  avgt    5     1054807.619 ?  1009.104  ns/op
> ThreadSleep.millisNanos        1000  avgt    5     1054894.829 ?  1946.551  ns/op
> ThreadSleep.millisNanos       10000  avgt    5     1054765.444 ?   701.873  ns/op
> ThreadSleep.millisNanos      100000  avgt    5     1054707.758 ?   619.054  ns/op
> ThreadSleep.millisNanos     1000000  avgt    5     1054802.230 ?  1294.035  ns/op
> ThreadSleep.millisNanos    10000000  avgt    5    10055265.430 ?  1184.281  ns/op
> ThreadSleep.millisNanos   100000000  avgt    5   100057484.300 ?  7960.939  ns/op
> ThreadSleep.millisNanos  1000000000  avgt    5  1000062244.700 ? 20244.067  ns/op
> 
> # Patched
> ThreadSleep.millisNanos           0  avgt    5         426.482 ?    10.284  ns/op
> ThreadSleep.millisNanos           1  avgt    5         565.819 ?     1.098  ns/op
> ThreadSleep.millisNanos          10  avgt    5         564.108 ?     3.493  ns/op
> ThreadSleep.millisNanos         100  avgt    5       53698.839 ?   942.506  ns/op
> ThreadSleep.millisNanos        1000  avgt    5       55205.929 ?   416.951  ns/op
> ThreadSleep.millisNanos       10000  avgt    5       64206.709 ?   382.213  ns/op
> ThreadSleep.millisNanos      100000  avgt    5      154477.045 ?   125.316  ns/op
> ThreadSleep.millisNanos     1000000  avgt    5     1054889.472 ?  2152.765  ns/op
> ThreadSleep.millisNanos    10000000  avgt    5    10055273.582 ?   691.628  ns/op
> ThreadSleep.millisNanos   100000000  avgt    5   100058261.300 ?  5222.946  ns/op
> ThreadSleep.millisNanos  1000000000  avgt    5  1000065434.000 ? 30213.137  ns/op
> 
> 
> MacBook 2021 (MacOS X, M1, AArch64):
> 
> 
> # ========= no regressions for Thread.sleep(millis)
> 
> # Baseline
> Benchmark                 (sleep)  Mode  Cnt           Score          Error  Units
> ThreadSleep.millis             0  avgt    5         555,871 ?      525,544  ns/op
> ThreadSleep.millis             1  avgt    5         405,761 ?      153,981  ns/op
> ThreadSleep.millis            10  avgt    5         403,906 ?      279,245  ns/op
> ThreadSleep.millis           100  avgt    5         402,787 ?      223,658  ns/op
> ThreadSleep.millis          1000  avgt    5         439,250 ?      374,150  ns/op
> ThreadSleep.millis         10000  avgt    5         435,769 ?      352,067  ns/op
> ThreadSleep.millis        100000  avgt    5        1853,664 ?     7254,716  ns/op
> ThreadSleep.millis       1000000  avgt    5     1364788,214 ?    66446,869  ns/op
> ThreadSleep.millis      10000000  avgt    5    11819681,019 ?   473810,685  ns/op
> ThreadSleep.millis     100000000  avgt    5   103536901,660 ?  1423282,032  ns/op
> ThreadSleep.millis    1000000000  avgt    5  1002995262,600 ?  6576388,880  ns/op
> 
> # Patched
> ThreadSleep.millis             0  avgt    5         662,597 ?     459,888  ns/op
> ThreadSleep.millis             1  avgt    5         433,561 ?     214,850  ns/op
> ThreadSleep.millis            10  avgt    5         388,614 ?      65,199  ns/op
> ThreadSleep.millis           100  avgt    5         436,823 ?     636,901  ns/op
> ThreadSleep.millis          1000  avgt    5         337,046 ?     129,440  ns/op
> ThreadSleep.millis         10000  avgt    5         366,557 ?     510,494  ns/op
> ThreadSleep.millis        100000  avgt    5         278,339 ?     102,443  ns/op
> ThreadSleep.millis       1000000  avgt    5     1520092,133 ?   26217,972  ns/op
> ThreadSleep.millis      10000000  avgt    5    13116509,001 ?  855508,621  ns/op
> ThreadSleep.millis     100000000  avgt    5   107010708,340 ? 1667080,292  ns/op
> ThreadSleep.millis    1000000000  avgt    5  1005412095,700 ? 6141267,753  ns/op
> 
> # ========= Significant improvements for Thread.sleep(millis, nanos)
> 
> # Baseline
> ThreadSleep.millisNanos           0  avgt    5         245,942 ?       44,338  ns/op
> ThreadSleep.millisNanos           1  avgt    5     1313354,886 ?    71820,989  ns/op
> ThreadSleep.millisNanos          10  avgt    5     1310358,568 ?    42731,583  ns/op
> ThreadSleep.millisNanos         100  avgt    5     1335221,078 ?   122031,471  ns/op
> ThreadSleep.millisNanos        1000  avgt    5     1313977,625 ?    30683,810  ns/op
> ThreadSleep.millisNanos       10000  avgt    5     1553321,472 ?    75181,324  ns/op
> ThreadSleep.millisNanos      100000  avgt    5     1553317,573 ?   132998,558  ns/op
> ThreadSleep.millisNanos     1000000  avgt    5     1544944,015 ?    41587,129  ns/op
> ThreadSleep.millisNanos    10000000  avgt    5    13228565,376 ?   902384,381  ns/op
> ThreadSleep.millisNanos   100000000  avgt    5   106866740,840 ?  2518606,524  ns/op
> ThreadSleep.millisNanos  1000000000  avgt    5  1006669020,800 ? 10961093,568  ns/op
> 
> # Patched
> ThreadSleep.millisNanos           0  avgt    5         394,716 ?     310,886  ns/op
> ThreadSleep.millisNanos           1  avgt    5        9945,543 ?     905,136  ns/op
> ThreadSleep.millisNanos          10  avgt    5        9863,605 ?     557,909  ns/op
> ThreadSleep.millisNanos         100  avgt    5        2454,862 ?     323,279  ns/op
> ThreadSleep.millisNanos        1000  avgt    5        3834,507 ?    2427,033  ns/op
> ThreadSleep.millisNanos       10000  avgt    5       16667,415 ?     508,814  ns/op
> ThreadSleep.millisNanos      100000  avgt    5      154202,589 ?     258,406  ns/op
> ThreadSleep.millisNanos     1000000  avgt    5     1557886,136 ?  192080,832  ns/op
> ThreadSleep.millisNanos    10000000  avgt    5    13077385,237 ?  887650,194  ns/op
> ThreadSleep.millisNanos   100000000  avgt    5   106225257,480 ? 3288589,410  ns/op
> ThreadSleep.millisNanos  1000000000  avgt    5  1006589558,200 ? 3677828,811  ns/op
> 
> 
> Additional testing:
>   - [x] New regression test
>   - [x] New benchmark
>   - [x] Linux x86_64 `tier1`
>   - [x] Linux AArch64 `tier1`

@shipilev Given that Github includes the entire problem description in every email, can you move the benchmark stats to a comment and out of the description.  Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13225#issuecomment-1488962749

From shade at openjdk.org  Wed Mar 29 17:13:28 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 29 Mar 2023 17:13:28 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity
In-Reply-To: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
Message-ID: <1pHVHcAs9DI3b3aAElZ2fduWNb7hVhxLtcDOwzQ7k-0=.c01caf59-b05e-4055-a529-b1be043deaab@github.com>

On Wed, 29 Mar 2023 11:28:53 GMT, Aleksey Shipilev  wrote:

> Java API has the `Thread.sleep(millis, nanos)` method exposed to users. The documentation for that method clearly says the precision and accuracy are dependent on the underlying system behavior. However, it always rounds up `nanos` to 1ms when doing the actual sleep. This means users cannot do the micro-second precision sleeps, even when the underlying platform allows it. Sub-millisecond sleeps are useful to build interesting primitives, like the rate limiters that run with >1000 RPS.
> 
> When faced with this, some users reach for more awkward APIs like `java.util.concurrent.locks.LockSupport.parkNanos`. The use of that API for sleeps is not in line with its intent, and while it "seems to work", it might have interesting interactions with other uses of `LockSupport`. Additionally, these "sleeps" are no longer visible to monitoring tools as "normal sleeps", e.g. as `Thread.sleep` events. Therefore, it would be prudent to improve current `Thread.sleep(millis, nanos)` for sub-millisecond granularity. 
> 
> Fortunately, the underlying code is almost ready for this, at least on POSIX side. I skipped Windows paths, because its timers are still no good. Note that on both Linux and MacOS timers oversleep by about 50us. I have a few ideas how to improve the accuracy for them, which would be a topic for a separate PR.
> 
> Additional testing:
>   - [x] New regression test
>   - [x] New benchmark
>   - [x] Linux x86_64 `tier1`
>   - [x] Linux AArch64 `tier1`

Motivational improvements on new benchmark below:

m6g.9xlarge (Linux, Xeon, x86_64):


Benchmark                 (sleep)  Mode  Cnt           Score       Error  Units

# ========= no regressions for Thread.sleep(millis)

# Baseline
ThreadSleep.millis             0  avgt    5         463.606 ?     8.256  ns/op
ThreadSleep.millis             1  avgt    5         459.434 ?     0.453  ns/op
ThreadSleep.millis            10  avgt    5         462.828 ?     1.283  ns/op
ThreadSleep.millis           100  avgt    5         459.495 ?     3.244  ns/op
ThreadSleep.millis          1000  avgt    5         457.962 ?     5.769  ns/op
ThreadSleep.millis         10000  avgt    5         457.960 ?     1.195  ns/op
ThreadSleep.millis        100000  avgt    5         459.197 ?     3.054  ns/op
ThreadSleep.millis       1000000  avgt    5     1058342.873 ?   304.169  ns/op
ThreadSleep.millis      10000000  avgt    5    10059945.148 ?  1642.411  ns/op
ThreadSleep.millis     100000000  avgt    5   100062181.340 ?  1863.186  ns/op
ThreadSleep.millis    1000000000  avgt    5  1000070015.600 ? 11379.631  ns/op

# Patched
ThreadSleep.millis             0  avgt    5         461.295 ?     6.700  ns/op
ThreadSleep.millis             1  avgt    5         463.383 ?     3.065  ns/op
ThreadSleep.millis            10  avgt    5         468.109 ?     1.607  ns/op
ThreadSleep.millis           100  avgt    5         467.316 ?     0.270  ns/op
ThreadSleep.millis          1000  avgt    5         461.999 ?     2.341  ns/op
ThreadSleep.millis         10000  avgt    5         465.075 ?     0.324  ns/op
ThreadSleep.millis        100000  avgt    5         462.588 ?     5.321  ns/op
ThreadSleep.millis       1000000  avgt    5     1058285.440 ?   409.376  ns/op
ThreadSleep.millis      10000000  avgt    5    10060437.490 ?   177.754  ns/op
ThreadSleep.millis     100000000  avgt    5   100060665.980 ?  1167.514  ns/op
ThreadSleep.millis    1000000000  avgt    5  1000071917.300 ? 17438.906  ns/op

# ========= Significant improvements for Thread.sleep(millis, nanos)

# Baseline
ThreadSleep.millisNanos           0  avgt    5         462.831 ?     0.251  ns/op
ThreadSleep.millisNanos           1  avgt    5     1058708.668 ?   960.683  ns/op
ThreadSleep.millisNanos          10  avgt    5     1058364.414 ?   197.700  ns/op
ThreadSleep.millisNanos         100  avgt    5     1058451.889 ?   561.979  ns/op
ThreadSleep.millisNanos        1000  avgt    5     1058372.010 ?    96.867  ns/op
ThreadSleep.millisNanos       10000  avgt    5     1058354.100 ?   297.148  ns/op
ThreadSleep.millisNanos      100000  avgt    5     1058485.092 ?  1093.340  ns/op
ThreadSleep.millisNanos     1000000  avgt    5     1059004.036 ?  1899.950  ns/op
ThreadSleep.millisNanos    10000000  avgt    5    10059733.302 ?  1725.908  ns/op
ThreadSleep.millisNanos   100000000  avgt    5   100063327.840 ?  6244.805  ns/op
ThreadSleep.millisNanos  1000000000  avgt    5  1000074542.300 ? 17898.173  ns/op

# Patched
ThreadSleep.millisNanos           0  avgt    5         467.968 ?     9.202  ns/op
ThreadSleep.millisNanos           1  avgt    5         579.448 ?     1.363  ns/op
ThreadSleep.millisNanos          10  avgt    5         577.656 ?     0.278  ns/op
ThreadSleep.millisNanos         100  avgt    5       58092.815 ?  2410.401  ns/op
ThreadSleep.millisNanos        1000  avgt    5       58592.249 ?   189.232  ns/op
ThreadSleep.millisNanos       10000  avgt    5       67668.688 ?   591.365  ns/op
ThreadSleep.millisNanos      100000  avgt    5      158143.164 ?  2281.540  ns/op
ThreadSleep.millisNanos     1000000  avgt    5     1058508.682 ?   155.767  ns/op
ThreadSleep.millisNanos    10000000  avgt    5    10059979.272 ?  1095.207  ns/op
ThreadSleep.millisNanos   100000000  avgt    5   100066844.180 ?  4287.440  ns/op
ThreadSleep.millisNanos  1000000000  avgt    5  1000075313.100 ?  9665.656  ns/op


m6g.4xlarge (Linux, Graviton, AArch64):


# ========= no regressions for Thread.sleep(millis)

# Baseline
ThreadSleep.millis             0  avgt    5         429.403 ?    24.947  ns/op
ThreadSleep.millis             1  avgt    5         427.533 ?     7.969  ns/op
ThreadSleep.millis            10  avgt    5         438.464 ?    10.277  ns/op
ThreadSleep.millis           100  avgt    5         425.626 ?     3.371  ns/op
ThreadSleep.millis          1000  avgt    5         426.465 ?     4.501  ns/op
ThreadSleep.millis         10000  avgt    5         427.235 ?     6.916  ns/op
ThreadSleep.millis        100000  avgt    5         430.311 ?     4.073  ns/op
ThreadSleep.millis       1000000  avgt    5     1054808.881 ?   469.409  ns/op
ThreadSleep.millis      10000000  avgt    5    10055497.206 ?  2123.591  ns/op
ThreadSleep.millis     100000000  avgt    5   100059355.520 ? 11597.426  ns/op
ThreadSleep.millis    1000000000  avgt    5  1000073145.400 ?  7659.244  ns/op

# Patched
ThreadSleep.millis             0  avgt    5         429.535 ?     2.597  ns/op
ThreadSleep.millis             1  avgt    5         425.209 ?     3.620  ns/op
ThreadSleep.millis            10  avgt    5         432.416 ?     9.350  ns/op
ThreadSleep.millis           100  avgt    5         432.867 ?     3.978  ns/op
ThreadSleep.millis          1000  avgt    5         426.627 ?     1.064  ns/op
ThreadSleep.millis         10000  avgt    5         427.180 ?     4.691  ns/op
ThreadSleep.millis        100000  avgt    5         438.554 ?     4.271  ns/op
ThreadSleep.millis       1000000  avgt    5     1054693.226 ?   323.240  ns/op
ThreadSleep.millis      10000000  avgt    5    10056408.240 ?  1759.211  ns/op
ThreadSleep.millis     100000000  avgt    5   100062449.780 ? 15133.808  ns/op
ThreadSleep.millis    1000000000  avgt    5  1000066918.500 ? 15817.822  ns/op

# ========= Significant improvements for Thread.sleep(millis, nanos)

# Baseline
ThreadSleep.millisNanos           0  avgt    5         439.163 ?     5.559  ns/op
ThreadSleep.millisNanos           1  avgt    5     1054751.231 ?   431.842  ns/op
ThreadSleep.millisNanos          10  avgt    5     1054640.725 ?   525.901  ns/op
ThreadSleep.millisNanos         100  avgt    5     1054807.619 ?  1009.104  ns/op
ThreadSleep.millisNanos        1000  avgt    5     1054894.829 ?  1946.551  ns/op
ThreadSleep.millisNanos       10000  avgt    5     1054765.444 ?   701.873  ns/op
ThreadSleep.millisNanos      100000  avgt    5     1054707.758 ?   619.054  ns/op
ThreadSleep.millisNanos     1000000  avgt    5     1054802.230 ?  1294.035  ns/op
ThreadSleep.millisNanos    10000000  avgt    5    10055265.430 ?  1184.281  ns/op
ThreadSleep.millisNanos   100000000  avgt    5   100057484.300 ?  7960.939  ns/op
ThreadSleep.millisNanos  1000000000  avgt    5  1000062244.700 ? 20244.067  ns/op

# Patched
ThreadSleep.millisNanos           0  avgt    5         426.482 ?    10.284  ns/op
ThreadSleep.millisNanos           1  avgt    5         565.819 ?     1.098  ns/op
ThreadSleep.millisNanos          10  avgt    5         564.108 ?     3.493  ns/op
ThreadSleep.millisNanos         100  avgt    5       53698.839 ?   942.506  ns/op
ThreadSleep.millisNanos        1000  avgt    5       55205.929 ?   416.951  ns/op
ThreadSleep.millisNanos       10000  avgt    5       64206.709 ?   382.213  ns/op
ThreadSleep.millisNanos      100000  avgt    5      154477.045 ?   125.316  ns/op
ThreadSleep.millisNanos     1000000  avgt    5     1054889.472 ?  2152.765  ns/op
ThreadSleep.millisNanos    10000000  avgt    5    10055273.582 ?   691.628  ns/op
ThreadSleep.millisNanos   100000000  avgt    5   100058261.300 ?  5222.946  ns/op
ThreadSleep.millisNanos  1000000000  avgt    5  1000065434.000 ? 30213.137  ns/op


MacBook 2021 (MacOS X, M1, AArch64):


# ========= no regressions for Thread.sleep(millis)

# Baseline
Benchmark                 (sleep)  Mode  Cnt           Score          Error  Units
ThreadSleep.millis             0  avgt    5         555,871 ?      525,544  ns/op
ThreadSleep.millis             1  avgt    5         405,761 ?      153,981  ns/op
ThreadSleep.millis            10  avgt    5         403,906 ?      279,245  ns/op
ThreadSleep.millis           100  avgt    5         402,787 ?      223,658  ns/op
ThreadSleep.millis          1000  avgt    5         439,250 ?      374,150  ns/op
ThreadSleep.millis         10000  avgt    5         435,769 ?      352,067  ns/op
ThreadSleep.millis        100000  avgt    5        1853,664 ?     7254,716  ns/op
ThreadSleep.millis       1000000  avgt    5     1364788,214 ?    66446,869  ns/op
ThreadSleep.millis      10000000  avgt    5    11819681,019 ?   473810,685  ns/op
ThreadSleep.millis     100000000  avgt    5   103536901,660 ?  1423282,032  ns/op
ThreadSleep.millis    1000000000  avgt    5  1002995262,600 ?  6576388,880  ns/op

# Patched
ThreadSleep.millis             0  avgt    5         662,597 ?     459,888  ns/op
ThreadSleep.millis             1  avgt    5         433,561 ?     214,850  ns/op
ThreadSleep.millis            10  avgt    5         388,614 ?      65,199  ns/op
ThreadSleep.millis           100  avgt    5         436,823 ?     636,901  ns/op
ThreadSleep.millis          1000  avgt    5         337,046 ?     129,440  ns/op
ThreadSleep.millis         10000  avgt    5         366,557 ?     510,494  ns/op
ThreadSleep.millis        100000  avgt    5         278,339 ?     102,443  ns/op
ThreadSleep.millis       1000000  avgt    5     1520092,133 ?   26217,972  ns/op
ThreadSleep.millis      10000000  avgt    5    13116509,001 ?  855508,621  ns/op
ThreadSleep.millis     100000000  avgt    5   107010708,340 ? 1667080,292  ns/op
ThreadSleep.millis    1000000000  avgt    5  1005412095,700 ? 6141267,753  ns/op

# ========= Significant improvements for Thread.sleep(millis, nanos)

# Baseline
ThreadSleep.millisNanos           0  avgt    5         245,942 ?       44,338  ns/op
ThreadSleep.millisNanos           1  avgt    5     1313354,886 ?    71820,989  ns/op
ThreadSleep.millisNanos          10  avgt    5     1310358,568 ?    42731,583  ns/op
ThreadSleep.millisNanos         100  avgt    5     1335221,078 ?   122031,471  ns/op
ThreadSleep.millisNanos        1000  avgt    5     1313977,625 ?    30683,810  ns/op
ThreadSleep.millisNanos       10000  avgt    5     1553321,472 ?    75181,324  ns/op
ThreadSleep.millisNanos      100000  avgt    5     1553317,573 ?   132998,558  ns/op
ThreadSleep.millisNanos     1000000  avgt    5     1544944,015 ?    41587,129  ns/op
ThreadSleep.millisNanos    10000000  avgt    5    13228565,376 ?   902384,381  ns/op
ThreadSleep.millisNanos   100000000  avgt    5   106866740,840 ?  2518606,524  ns/op
ThreadSleep.millisNanos  1000000000  avgt    5  1006669020,800 ? 10961093,568  ns/op

# Patched
ThreadSleep.millisNanos           0  avgt    5         394,716 ?     310,886  ns/op
ThreadSleep.millisNanos           1  avgt    5        9945,543 ?     905,136  ns/op
ThreadSleep.millisNanos          10  avgt    5        9863,605 ?     557,909  ns/op
ThreadSleep.millisNanos         100  avgt    5        2454,862 ?     323,279  ns/op
ThreadSleep.millisNanos        1000  avgt    5        3834,507 ?    2427,033  ns/op
ThreadSleep.millisNanos       10000  avgt    5       16667,415 ?     508,814  ns/op
ThreadSleep.millisNanos      100000  avgt    5      154202,589 ?     258,406  ns/op
ThreadSleep.millisNanos     1000000  avgt    5     1557886,136 ?  192080,832  ns/op
ThreadSleep.millisNanos    10000000  avgt    5    13077385,237 ?  887650,194  ns/op
ThreadSleep.millisNanos   100000000  avgt    5   106225257,480 ? 3288589,410  ns/op
ThreadSleep.millisNanos  1000000000  avgt    5  1006589558,200 ? 3677828,811  ns/op

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13225#issuecomment-1488989224

From shade at openjdk.org  Wed Mar 29 17:20:32 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 29 Mar 2023 17:20:32 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity
In-Reply-To: 
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
 
Message-ID: <4pbTAzlahWgsX0rZFLkvHBspPsH3f5sywPAw_J910xc=.459db480-16d3-47d0-a455-5c4eec0c0639@github.com>

On Wed, 29 Mar 2023 16:48:41 GMT, David M. Lloyd  wrote:

> Are there specific factors which would make it unreasonable to implement `sleep` in terms of `parkNanos`?

After reading the Javadoc for `LockSupport`, I don't believe implementing `Thread.sleep` with `LockSupport.parkNanos` is a proper thing to do. `LockSupport` implicitly deals with permits, acting like a single-permit semaphore. So the behavior for `parkNanos` when there is a prior `LockSupport.unpark` (which adds the permit) is to consume the permit and return immediately.

In other words:


% cat LockSupportIsNotSleep.java 
import java.util.concurrent.locks.LockSupport;
import java.util.concurrent.TimeUnit;

public class LockSupportIsNotSleep {
   public static void main(String... args) {
      LockSupport.unpark(Thread.currentThread());

      long time1 = System.nanoTime();
      LockSupport.parkNanos(TimeUnit.SECONDS.toNanos(1000));
      long time2 = System.nanoTime();

      System.out.println("Slept for " + (time2 - time1) + " ns");
   }
}

% java LockSupportIsNotSleep.java                   
Slept for 6583 ns

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13225#issuecomment-1489000794

From duke at openjdk.org  Wed Mar 29 17:28:29 2023
From: duke at openjdk.org (David M. Lloyd)
Date: Wed, 29 Mar 2023 17:28:29 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity
In-Reply-To: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
Message-ID: 

On Wed, 29 Mar 2023 11:28:53 GMT, Aleksey Shipilev  wrote:

> Java API has the `Thread.sleep(millis, nanos)` method exposed to users. The documentation for that method clearly says the precision and accuracy are dependent on the underlying system behavior. However, it always rounds up `nanos` to 1ms when doing the actual sleep. This means users cannot do the micro-second precision sleeps, even when the underlying platform allows it. Sub-millisecond sleeps are useful to build interesting primitives, like the rate limiters that run with >1000 RPS.
> 
> When faced with this, some users reach for more awkward APIs like `java.util.concurrent.locks.LockSupport.parkNanos`. The use of that API for sleeps is not in line with its intent, and while it "seems to work", it might have interesting interactions with other uses of `LockSupport`. Additionally, these "sleeps" are no longer visible to monitoring tools as "normal sleeps", e.g. as `Thread.sleep` events. Therefore, it would be prudent to improve current `Thread.sleep(millis, nanos)` for sub-millisecond granularity. 
> 
> Fortunately, the underlying code is almost ready for this, at least on POSIX side. I skipped Windows paths, because its timers are still no good. Note that on both Linux and MacOS timers oversleep by about 50us. I have a few ideas how to improve the accuracy for them, which would be a topic for a separate PR.
> 
> Additional testing:
>   - [x] New regression test
>   - [x] New benchmark
>   - [x] Linux x86_64 `tier1`
>   - [x] Linux AArch64 `tier1`

Right, I was assuming that such an implementation would be conformant to the existing specification of the `sleep` method, thus it would have to loop by consuming the unpark (if any), checking for interruption, parking for the remaining time, and reinstating the unpark at the end (if any was consumed). The main risk that I could see of such an approach is that if the sleep was interrupted, then the loop would necessarily unpark itself again (as interruption also interrupts park but this is indistinguishable from an explicit unpark), which might cause a spurious unpark down the line. But it should be pretty consistent with how it is used in interruptible locks AFAIK. I was mostly curious about other factors like JVMTI and thread status though.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13225#issuecomment-1489010885

From rriggs at openjdk.org  Wed Mar 29 17:35:48 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 29 Mar 2023 17:35:48 GMT
Subject: Integrated: 8303392: Runtime.exec and ProcessBuilder.start should use
 System logger
In-Reply-To: <-1i11ZrHHgzUbCSa_RXAcGKNfgtpdui--bltZ4Ujs2A=.f5f1a7e2-d3ec-4f64-9b1e-317ef2f24ef1@github.com>
References: <-1i11ZrHHgzUbCSa_RXAcGKNfgtpdui--bltZ4Ujs2A=.f5f1a7e2-d3ec-4f64-9b1e-317ef2f24ef1@github.com>
Message-ID: 

On Fri, 3 Mar 2023 19:26:52 GMT, Roger Riggs  wrote:

> Runtime.exec and ProcessBuilder.start methods create a new operating system process with the program and arguments. Many applications configure a logging subsystem to monitor application events. Logging a process start message with the program, arguments, and stack trace can identify the caller and purpose.
> Logging the process start event is complementary to the process start event generated for JFR (Java Flight Recorder).

This pull request has now been integrated.

Changeset: d063b896
Author:    Roger Riggs 
URL:       https://git.openjdk.org/jdk/commit/d063b8964fbdd6ca1d9527dabb40fed59bbc8ad7
Stats:     272 lines in 6 files changed: 272 ins; 0 del; 0 mod

8303392: Runtime.exec and ProcessBuilder.start should use System logger

Reviewed-by: stuefe, alanb, mullan

-------------

PR: https://git.openjdk.org/jdk/pull/12862

From bpb at openjdk.org  Wed Mar 29 18:05:46 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 29 Mar 2023 18:05:46 GMT
Subject: RFR: 8298619: java/io/File/GetXSpace.java is failing [v4]
In-Reply-To: <6LnAAIclo5mZZgba4XUSTSc72vyNrBinzUlO9-kJXbU=.fe0c5e94-9e36-4484-b8e7-0f19cb10cb05@github.com>
References: <6LnAAIclo5mZZgba4XUSTSc72vyNrBinzUlO9-kJXbU=.fe0c5e94-9e36-4484-b8e7-0f19cb10cb05@github.com>
Message-ID: 

> Modify the `Space` instances used for size comparison to be created with total number of bytes derived from the Windows `diskFree` utility instead of Cygwin?s `df`.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8305157: Clean up

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12397/files
  - new: https://git.openjdk.org/jdk/pull/12397/files/114857c1..9ae317e7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12397&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12397&range=02-03

  Stats: 14 lines in 2 files changed: 7 ins; 6 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12397.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12397/head:pull/12397

PR: https://git.openjdk.org/jdk/pull/12397

From alanb at openjdk.org  Wed Mar 29 18:13:00 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 29 Mar 2023 18:13:00 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity
In-Reply-To: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
Message-ID: 

On Wed, 29 Mar 2023 11:28:53 GMT, Aleksey Shipilev  wrote:

> Java API has the `Thread.sleep(millis, nanos)` method exposed to users. The documentation for that method clearly says the precision and accuracy are dependent on the underlying system behavior. However, it always rounds up `nanos` to 1ms when doing the actual sleep. This means users cannot do the micro-second precision sleeps, even when the underlying platform allows it. Sub-millisecond sleeps are useful to build interesting primitives, like the rate limiters that run with >1000 RPS.
> 
> When faced with this, some users reach for more awkward APIs like `java.util.concurrent.locks.LockSupport.parkNanos`. The use of that API for sleeps is not in line with its intent, and while it "seems to work", it might have interesting interactions with other uses of `LockSupport`. Additionally, these "sleeps" are no longer visible to monitoring tools as "normal sleeps", e.g. as `Thread.sleep` events. Therefore, it would be prudent to improve current `Thread.sleep(millis, nanos)` for sub-millisecond granularity. 
> 
> Fortunately, the underlying code is almost ready for this, at least on POSIX side. I skipped Windows paths, because its timers are still no good. Note that on both Linux and MacOS timers oversleep by about 50us. I have a few ideas how to improve the accuracy for them, which would be a topic for a separate PR.
> 
> Additional testing:
>   - [x] New regression test
>   - [x] New benchmark
>   - [x] Linux x86_64 `tier1`
>   - [x] Linux AArch64 `tier1`

src/java.base/share/classes/java/lang/Thread.java line 509:

> 507:             ThreadSleepEvent event = new ThreadSleepEvent();
> 508:             try {
> 509:                 event.time = MILLISECONDS.toNanos(millis) + nanos;

This can overflow when millis is at or close to Long.MAX_VALUE.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13225#discussion_r1152318322

From duke at openjdk.org  Wed Mar 29 18:15:42 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 29 Mar 2023 18:15:42 GMT
Subject: RFR: 8304014: Convert
 test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java to junit [v3]
In-Reply-To: 
References: 
Message-ID: 

> CorruptedZipFiles could benefit from some spring cleaning and a conversion to testNG:
> 
> - The actual tests are moved into their own `@Test` methods, given more meaningful names and a Javadoc comment explaining the constraint being verified
> - The setup code is moved to a `@Before` method, slightly modernized and rewritten to take advantage of `assertEquals` 
> - `checkZipExceptionImpl` is updated to take advantage of `expectThrows`
> - A bunch of constants copied over from `ZipFile` can be deleted since JDK-6225935 has long been fixed

Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:

  Junit version

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12563/files
  - new: https://git.openjdk.org/jdk/pull/12563/files/e46fc5b3..892e166a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12563&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12563&range=01-02

  Stats: 24 lines in 1 file changed: 3 ins; 0 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/12563.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12563/head:pull/12563

PR: https://git.openjdk.org/jdk/pull/12563

From duke at openjdk.org  Wed Mar 29 18:15:44 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 29 Mar 2023 18:15:44 GMT
Subject: RFR: 8304014: Convert
 test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java to junit [v2]
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: 

On Wed, 29 Mar 2023 15:24:41 GMT, Lance Andersen  wrote:

> Let's go with reviewing this version, Thank you for the update Eirik

Good, I pushed the junit version to the PR. Also updated the JBS and PR titles.

Big thanks to @dfuch for suggesting, your lower-level comments are also welcome!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12563#issuecomment-1489072396

From rgiulietti at openjdk.org  Wed Mar 29 18:18:09 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 29 Mar 2023 18:18:09 GMT
Subject: RFR: 8132995: Matcher$ImmutableMatchResult should be optimized to
 reduce space usage
Message-ID: 

When appropriate and useful, copies only the relevant portion of the `CharSequence` to the match result.

-------------

Commit messages:
 - 8132995: Matcher should be optimized to reduce space usage

Changes: https://git.openjdk.org/jdk/pull/13231/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13231&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8132995
  Stats: 111 lines in 2 files changed: 97 ins; 2 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/13231.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13231/head:pull/13231

PR: https://git.openjdk.org/jdk/pull/13231

From stsypanov at openjdk.org  Wed Mar 29 18:21:06 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Wed, 29 Mar 2023 18:21:06 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity
In-Reply-To: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
Message-ID: 

On Wed, 29 Mar 2023 11:28:53 GMT, Aleksey Shipilev  wrote:

> Java API has the `Thread.sleep(millis, nanos)` method exposed to users. The documentation for that method clearly says the precision and accuracy are dependent on the underlying system behavior. However, it always rounds up `nanos` to 1ms when doing the actual sleep. This means users cannot do the micro-second precision sleeps, even when the underlying platform allows it. Sub-millisecond sleeps are useful to build interesting primitives, like the rate limiters that run with >1000 RPS.
> 
> When faced with this, some users reach for more awkward APIs like `java.util.concurrent.locks.LockSupport.parkNanos`. The use of that API for sleeps is not in line with its intent, and while it "seems to work", it might have interesting interactions with other uses of `LockSupport`. Additionally, these "sleeps" are no longer visible to monitoring tools as "normal sleeps", e.g. as `Thread.sleep` events. Therefore, it would be prudent to improve current `Thread.sleep(millis, nanos)` for sub-millisecond granularity. 
> 
> Fortunately, the underlying code is almost ready for this, at least on POSIX side. I skipped Windows paths, because its timers are still no good. Note that on both Linux and MacOS timers oversleep by about 50us. I have a few ideas how to improve the accuracy for them, which would be a topic for a separate PR.
> 
> Additional testing:
>   - [x] New regression test
>   - [x] New benchmark
>   - [x] Linux x86_64 `tier1`
>   - [x] Linux AArch64 `tier1`

Should we manifest this change in JavaDoc somehow? Just to let people know that starting from the next Java release they can use sub-millisecond intervals in their code.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13225#issuecomment-1489084409

From dfuchs at openjdk.org  Wed Mar 29 18:31:25 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 29 Mar 2023 18:31:25 GMT
Subject: RFR: 8304014: Convert
 test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java to junit [v3]
In-Reply-To: 
References: 
 
Message-ID: <-6G0Q5biUYh_pmlqUrR0AGdmVxPFgSLSe1U9qeUa8fs=.29b1df6c-f272-49c7-9a58-6cf2123c0c4a@github.com>

On Wed, 29 Mar 2023 18:15:42 GMT, Eirik Bjorsnos  wrote:

>> CorruptedZipFiles could benefit from some spring cleaning and a conversion to testNG:
>> 
>> - The actual tests are moved into their own `@Test` methods, given more meaningful names and a Javadoc comment explaining the constraint being verified
>> - The setup code is moved to a `@Before` method, slightly modernized and rewritten to take advantage of `assertEquals` 
>> - `checkZipExceptionImpl` is updated to take advantage of `expectThrows`
>> - A bunch of constants copied over from `ZipFile` can be deleted since JDK-6225935 has long been fixed
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Junit version

Hi Eirik, thanks for following up on my suggestion :-)

test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java line 36:

> 34: import org.junit.BeforeClass;
> 35: import org.junit.Test;
> 36: 

I believe you should be using corresponding annotations from `org.junit.jupiter.api` instead.
>From https://junit.org/junit5/docs/current/user-guide/index.html#migrating-from-junit4
> `@Before` and `@After` no longer exist; use `@BeforeEach` and `@AfterEach` instead.
> `@BeforeClass` and `@AfterClass` no longer exist; use `@BeforeAll` and `@AfterAll` instead.

Similarly the `@Test` annotation should be imported from `org.junit.jupiter.api`

-------------

Changes requested by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/12563#pullrequestreview-1363720139
PR Review Comment: https://git.openjdk.org/jdk/pull/12563#discussion_r1152333259

From shade at openjdk.org  Wed Mar 29 18:35:25 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 29 Mar 2023 18:35:25 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity
In-Reply-To: 
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
 
Message-ID: 

On Wed, 29 Mar 2023 18:10:30 GMT, Alan Bateman  wrote:

>> Java API has the `Thread.sleep(millis, nanos)` method exposed to users. The documentation for that method clearly says the precision and accuracy are dependent on the underlying system behavior. However, it always rounds up `nanos` to 1ms when doing the actual sleep. This means users cannot do the micro-second precision sleeps, even when the underlying platform allows it. Sub-millisecond sleeps are useful to build interesting primitives, like the rate limiters that run with >1000 RPS.
>> 
>> When faced with this, some users reach for more awkward APIs like `java.util.concurrent.locks.LockSupport.parkNanos`. The use of that API for sleeps is not in line with its intent, and while it "seems to work", it might have interesting interactions with other uses of `LockSupport`. Additionally, these "sleeps" are no longer visible to monitoring tools as "normal sleeps", e.g. as `Thread.sleep` events. Therefore, it would be prudent to improve current `Thread.sleep(millis, nanos)` for sub-millisecond granularity. 
>> 
>> Fortunately, the underlying code is almost ready for this, at least on POSIX side. I skipped Windows paths, because its timers are still no good. Note that on both Linux and MacOS timers oversleep by about 50us. I have a few ideas how to improve the accuracy for them, which would be a topic for a separate PR.
>> 
>> Additional testing:
>>   - [x] New regression test
>>   - [x] New benchmark
>>   - [x] Linux x86_64 `tier1`
>>   - [x] Linux AArch64 `tier1`
>
> src/java.base/share/classes/java/lang/Thread.java line 509:
> 
>> 507:             ThreadSleepEvent event = new ThreadSleepEvent();
>> 508:             try {
>> 509:                 event.time = MILLISECONDS.toNanos(millis) + nanos;
> 
> This can overflow when millis is at or close to Long.MAX_VALUE.

Yes, let me fix that. `TimeUnit.toNanos` handles it well itself, it seems.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13225#discussion_r1152336826

From stsypanov at openjdk.org  Wed Mar 29 18:35:36 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Wed, 29 Mar 2023 18:35:36 GMT
Subject: Integrated: 8304976: Optimize
 DateTimeFormatterBuilder.ZoneTextPrinterParser.getTree()
In-Reply-To: 
References: 
Message-ID: 

On Fri, 17 Feb 2023 09:50:16 GMT, Sergey Tsypanov  wrote:

> 1) When `DateTimeFormatter` is reused we don't need to copy `availableZoneIds` and allocate `nonRegionIds` as PrefixTree can be taken from cache. In the related benchmark allocation of `HashSet` takes ~93% of all time, so avoiding it should bring some improvement for cases when we reuse `DateTimeFormatter` to parse a string into `ZoneDateTime`
> ![image](https://user-images.githubusercontent.com/10835776/219609028-af48eae4-d326-4719-8366-c215baa85835.png)
> 
> 2) `DateTimeFormatter` is mostly used with one locale, so `cachedTree` and `cachedTreeCI` can have predefined size.
> 
> 
> @State(Scope.Thread)
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> public class DateTimeFormatterBenchmark {
> 
>     private static final DateTimeFormatter df = new DateTimeFormatterBuilder().appendPattern("yyyy:MM:dd:HH:mm:v").toFormatter();
>     private static final String TEXT = "2015:03:10:12:13:ECT";
> 
>     @Setup
>     public void setUp() {
>         ZonedDateTime.parse(TEXT, df);
>     }
> 
>     @Benchmark
>     public ZonedDateTime parse() {
>         return ZonedDateTime.parse(TEXT, df);
>     }
> }

This pull request has now been integrated.

Changeset: 438c969b
Author:    Sergey Tsypanov 
Committer: Naoto Sato 
URL:       https://git.openjdk.org/jdk/commit/438c969b7b07eeef0158b089e5a168849e04bf56
Stats:     62 lines in 2 files changed: 57 ins; 1 del; 4 mod

8304976: Optimize DateTimeFormatterBuilder.ZoneTextPrinterParser.getTree()

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/12612

From duke at openjdk.org  Wed Mar 29 18:37:27 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 29 Mar 2023 18:37:27 GMT
Subject: RFR: 8304014: Convert
 test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java to junit [v3]
In-Reply-To: <-6G0Q5biUYh_pmlqUrR0AGdmVxPFgSLSe1U9qeUa8fs=.29b1df6c-f272-49c7-9a58-6cf2123c0c4a@github.com>
References: 
 
 <-6G0Q5biUYh_pmlqUrR0AGdmVxPFgSLSe1U9qeUa8fs=.29b1df6c-f272-49c7-9a58-6cf2123c0c4a@github.com>
Message-ID: <7K_GR1plnaUeGqP8zbWVSUc6dZSKoHor6Z79iP4iVhY=.24b54fd1-c056-44b2-8419-74ac33240734@github.com>

On Wed, 29 Mar 2023 18:25:34 GMT, Daniel Fuchs  wrote:

>> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Junit version
>
> test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java line 36:
> 
>> 34: import org.junit.BeforeClass;
>> 35: import org.junit.Test;
>> 36: 
> 
> I believe you should be using corresponding annotations from `org.junit.jupiter.api` instead.
> From https://junit.org/junit5/docs/current/user-guide/index.html#migrating-from-junit4
>> `@Before` and `@After` no longer exist; use `@BeforeEach` and `@AfterEach` instead.
>> `@BeforeClass` and `@AfterClass` no longer exist; use `@BeforeAll` and `@AfterAll` instead.
> 
> Similarly the `@Test` annotation should be imported from `org.junit.jupiter.api`

Noob question: Do you know where I find the jars for setting up junit5 in my IDE? jtreg's `junit-platform-console-standalone-1.9.2` does not seem to include these annotations.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12563#discussion_r1152342103

From duke at openjdk.org  Wed Mar 29 18:40:42 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 29 Mar 2023 18:40:42 GMT
Subject: RFR: 8304014: Convert
 test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java to junit [v3]
In-Reply-To: <7K_GR1plnaUeGqP8zbWVSUc6dZSKoHor6Z79iP4iVhY=.24b54fd1-c056-44b2-8419-74ac33240734@github.com>
References: 
 
 <-6G0Q5biUYh_pmlqUrR0AGdmVxPFgSLSe1U9qeUa8fs=.29b1df6c-f272-49c7-9a58-6cf2123c0c4a@github.com>
 <7K_GR1plnaUeGqP8zbWVSUc6dZSKoHor6Z79iP4iVhY=.24b54fd1-c056-44b2-8419-74ac33240734@github.com>
Message-ID: 

On Wed, 29 Mar 2023 18:35:04 GMT, Eirik Bjorsnos  wrote:

>> test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java line 36:
>> 
>>> 34: import org.junit.BeforeClass;
>>> 35: import org.junit.Test;
>>> 36: 
>> 
>> I believe you should be using corresponding annotations from `org.junit.jupiter.api` instead.
>> From https://junit.org/junit5/docs/current/user-guide/index.html#migrating-from-junit4
>>> `@Before` and `@After` no longer exist; use `@BeforeEach` and `@AfterEach` instead.
>>> `@BeforeClass` and `@AfterClass` no longer exist; use `@BeforeAll` and `@AfterAll` instead.
>> 
>> Similarly the `@Test` annotation should be imported from `org.junit.jupiter.api`
>
> Noob question: Do you know where I find the jars for setting up junit5 in my IDE? jtreg's `junit-platform-console-standalone-1.9.2` does not seem to include these annotations.

Seems my dev environment has `jtreg` < 7. Maybe that's a problem?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12563#discussion_r1152344743

From duke at openjdk.org  Wed Mar 29 18:53:17 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 29 Mar 2023 18:53:17 GMT
Subject: RFR: 8304014: Convert
 test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java to junit [v3]
In-Reply-To: 
References: 
 
 <-6G0Q5biUYh_pmlqUrR0AGdmVxPFgSLSe1U9qeUa8fs=.29b1df6c-f272-49c7-9a58-6cf2123c0c4a@github.com>
 <7K_GR1plnaUeGqP8zbWVSUc6dZSKoHor6Z79iP4iVhY=.24b54fd1-c056-44b2-8419-74ac33240734@github.com>
 
Message-ID: 

On Wed, 29 Mar 2023 18:38:00 GMT, Eirik Bjorsnos  wrote:

>> Noob question: Do you know where I find the jars for setting up junit5 in my IDE? jtreg's `junit-platform-console-standalone-1.9.2` does not seem to include these annotations.
>
> Seems my dev environment has `jtreg` < 7. Maybe that's a problem?

Seems junit 5 support is a recent effort? 

https://mail.openjdk.org/pipermail/jdk-dev/2022-August/006869.html

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12563#discussion_r1152356869

From cjplummer at openjdk.org  Wed Mar 29 18:58:25 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 29 Mar 2023 18:58:25 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v4]
In-Reply-To: 
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 
Message-ID: 

On Wed, 29 Mar 2023 08:00:36 GMT, Alan Bateman  wrote:

>> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The APIs that were preview APIs in Java 19/20 are changed to permanent and their `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The JNI and JVMTI versions are bumped as this is the first change in 21 to need the new version number. A lot of tests are updated to drop `@enablePreview` and --enable-preview.
>> 
>> There is one API change from Java 19/20, the preview API Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an update to the JVMTI GetThreadInfo implementation to read the TCCL consistently.
>> 
>> In addition, there are a small number of implementation changes to sync up from the loom fibers branch:
>> 
>> - A number of stack frames are `@Hidden` to reduce noise in the stack traces. This exposed a few issues with the stack walker code. More specifically, the cases where  end of a continuation falls precisely at the end of the batch, or where the remaining frames are hidden, weren't handled correctly.
>> - The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in Thread rather than in two classes.
>> - A few robustness improvements for OOME and SOE. There is more to do here, for future PRs.
>> - New system property to print a stack trace when a virtual thread sets its own value of a TL.
>> - ThreadPerTaskExecutor is changed to use FutureTask.
>> 
>> Testing: tier1-6.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix ThreadSleepEvent again

test/hotspot/jtreg/serviceability/jvmti/thread/GetFrameCount/framecnt01/framecnt01.java line 82:

> 80: 
> 81:         // this is too fragile, implementation can change at any time.
> 82:         checkFrames(vThread1, false, 14);

Is this due to the `@hidden` being added to `Continuation.enter()` and `enter0()`? If so, since both methods are now hidden, why are there not 2 fewer frames? Was there also an additional frame added somewhere?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1152337485

From cjplummer at openjdk.org  Wed Mar 29 18:58:29 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 29 Mar 2023 18:58:29 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v2]
In-Reply-To: 
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 <9RJ4unb3FjazYLi0BbWs1NGN9h50Z1fvAz1ZNds5mO4=.cb02f148-66bd-4429-9c30-ea4a6dcbe4d7@github.com>
 
 
Message-ID: 

On Wed, 29 Mar 2023 07:27:50 GMT, Alan Bateman  wrote:

>> test/jdk/com/sun/management/ThreadMXBean/VirtualThreads.java line 143:
>> 
>>> 141:             long[] tids = new long[] { tid0, tid1 };
>>> 142:             long[] cpuTimes = bean.getThreadCpuTime(tids);
>>> 143:             if (Thread.currentThread().isVirtual()) {
>> 
>> How it worked before?
>
> tid0 is the thread ID of a platform therad. tid1 is the threadID of a virtual thread. The only change here is allow this test run with the main wrapper plugin ([CODETOOLS-7903373](https://bugs.openjdk.org/browse/CODETOOLS-7903373)), it would otherwise have to be excluded for those runs.

I don't see any problemlist changes. Was this test failing when using the wrapper because of the lack of problemlisting?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1152353646

From duke at openjdk.org  Wed Mar 29 19:08:12 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 29 Mar 2023 19:08:12 GMT
Subject: RFR: 8304014: Convert
 test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java to junit [v4]
In-Reply-To: 
References: 
Message-ID: 

> CorruptedZipFiles could benefit from some spring cleaning and a conversion to testNG:
> 
> - The actual tests are moved into their own `@Test` methods, given more meaningful names and a Javadoc comment explaining the constraint being verified
> - The setup code is moved to a `@Before` method, slightly modernized and rewritten to take advantage of `assertEquals` 
> - `checkZipExceptionImpl` is updated to take advantage of `expectThrows`
> - A bunch of constants copied over from `ZipFile` can be deleted since JDK-6225935 has long been fixed

Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:

  Update annotations to junit 5

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12563/files
  - new: https://git.openjdk.org/jdk/pull/12563/files/892e166a..01c25e84

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12563&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12563&range=02-03

  Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/12563.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12563/head:pull/12563

PR: https://git.openjdk.org/jdk/pull/12563

From duke at openjdk.org  Wed Mar 29 19:08:14 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 29 Mar 2023 19:08:14 GMT
Subject: RFR: 8304014: Convert
 test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java to junit [v3]
In-Reply-To: 
References: 
 
 <-6G0Q5biUYh_pmlqUrR0AGdmVxPFgSLSe1U9qeUa8fs=.29b1df6c-f272-49c7-9a58-6cf2123c0c4a@github.com>
 <7K_GR1plnaUeGqP8zbWVSUc6dZSKoHor6Z79iP4iVhY=.24b54fd1-c056-44b2-8419-74ac33240734@github.com>
 
 
Message-ID: 

On Wed, 29 Mar 2023 18:50:27 GMT, Eirik Bjorsnos  wrote:

>> Seems my dev environment has `jtreg` < 7. Maybe that's a problem?
>
> Seems junit 5 support is a recent effort? 
> 
> https://mail.openjdk.org/pipermail/jdk-dev/2022-August/006869.html

Scratch that. It seems my IDE was just not being very cooperative in suggesting or finding JUnit 5 API. When I wrote the imports myself it seems to have improved its behaviour.

Do you think it looks better now, @dfuch ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12563#discussion_r1152369091

From dfuchs at openjdk.org  Wed Mar 29 19:08:15 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 29 Mar 2023 19:08:15 GMT
Subject: RFR: 8304014: Convert
 test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java to junit [v3]
In-Reply-To: 
References: 
 
 <-6G0Q5biUYh_pmlqUrR0AGdmVxPFgSLSe1U9qeUa8fs=.29b1df6c-f272-49c7-9a58-6cf2123c0c4a@github.com>
 <7K_GR1plnaUeGqP8zbWVSUc6dZSKoHor6Z79iP4iVhY=.24b54fd1-c056-44b2-8419-74ac33240734@github.com>
 
 
 
Message-ID: 

On Wed, 29 Mar 2023 19:02:56 GMT, Eirik Bjorsnos  wrote:

>> Seems junit 5 support is a recent effort? 
>> 
>> https://mail.openjdk.org/pipermail/jdk-dev/2022-August/006869.html
>
> Scratch that. It seems my IDE was just not being very cooperative in suggesting or finding JUnit 5 API. When I wrote the imports myself it seems to have improved its behaviour.
> 
> Do you think it looks better now, @dfuch ?

Yes - this a recent effort. I believe you will need at least jtreg 7, and JUnit 5.8.2

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12563#discussion_r1152369274

From liach at openjdk.org  Wed Mar 29 19:10:03 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 29 Mar 2023 19:10:03 GMT
Subject: RFR: 8266571: Sequenced Collections [v4]
In-Reply-To: <-BNnKi-AQ6XTBe-GxXIn9Zq7WdROvR9mX73H_gr2rs8=.4c034fa8-781f-4739-ade8-e24f507f55be@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <-BNnKi-AQ6XTBe-GxXIn9Zq7WdROvR9mX73H_gr2rs8=.4c034fa8-781f-4739-ade8-e24f507f55be@github.com>
Message-ID: 

On Tue, 28 Mar 2023 02:37:22 GMT, Stuart Marks  wrote:

>> PR for Sequenced Collections implementation.
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify handling of cached keySet, values, and entrySet views.

src/java.base/share/classes/java/util/SequencedCollection.java line 107:

> 105:      */
> 106:     default void addFirst(E e) {
> 107:         throw new UnsupportedOperationException();

Can this be defaulted to `this.reversed().addLast()` instead? If this throws uoe, the reversed should throw uoe as well; and the new default can simplify implementations by much as well.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1152372181

From duke at openjdk.org  Wed Mar 29 19:22:50 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 29 Mar 2023 19:22:50 GMT
Subject: RFR: 8304014: Convert
 test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java to junit [v3]
In-Reply-To: 
References: 
 
 <-6G0Q5biUYh_pmlqUrR0AGdmVxPFgSLSe1U9qeUa8fs=.29b1df6c-f272-49c7-9a58-6cf2123c0c4a@github.com>
 <7K_GR1plnaUeGqP8zbWVSUc6dZSKoHor6Z79iP4iVhY=.24b54fd1-c056-44b2-8419-74ac33240734@github.com>
 
 
 
 
Message-ID: <58bsBPumb36bEhXSTjBYagsgBujMEIs4DFUCTQ_OiEk=.6235c414-6cb5-4e89-873a-41d660158329@github.com>

On Wed, 29 Mar 2023 19:03:08 GMT, Daniel Fuchs  wrote:

>> Scratch that. It seems my IDE was just not being very cooperative in suggesting or finding JUnit 5 API. When I wrote the imports myself it seems to have improved its behaviour.
>> 
>> Do you think it looks better now, @dfuch ?
>
> Yes - this a recent effort. I believe you will need at least jtreg 7, and JUnit 5.8.2

It is worth noting that I did a new local build of jtreg and that may have updated the junit API jar. 

I would find that weird because the file name or version of the JAR file was not updated `jtreg/build/deps/junit/junit-platform-console-standalone-1.9.2.jar`. But maybe the content of the file changed?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12563#discussion_r1152384929

From forax at openjdk.org  Wed Mar 29 19:23:06 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 29 Mar 2023 19:23:06 GMT
Subject: RFR: 8266571: Sequenced Collections [v4]
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <-BNnKi-AQ6XTBe-GxXIn9Zq7WdROvR9mX73H_gr2rs8=.4c034fa8-781f-4739-ade8-e24f507f55be@github.com>
 
Message-ID: 

On Wed, 29 Mar 2023 19:06:20 GMT, Chen Liang  wrote:

>> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplify handling of cached keySet, values, and entrySet views.
>
> src/java.base/share/classes/java/util/SequencedCollection.java line 107:
> 
>> 105:      */
>> 106:     default void addFirst(E e) {
>> 107:         throw new UnsupportedOperationException();
> 
> Can this be defaulted to `this.reversed().addLast()` instead? If this throws uoe, the reversed should throw uoe as well; and the new default can simplify implementations by much as well.

In the same spirit, `reversed()` should also have a default implementation equivalent to

  Collections.unmodifiableSequenceCollection(Arrays.asList(this.toArray())).reversed()

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1152384938

From alanb at openjdk.org  Wed Mar 29 19:33:15 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 29 Mar 2023 19:33:15 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v2]
In-Reply-To: 
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 <9RJ4unb3FjazYLi0BbWs1NGN9h50Z1fvAz1ZNds5mO4=.cb02f148-66bd-4429-9c30-ea4a6dcbe4d7@github.com>
 
 
 
Message-ID: <1bIwzQpS67LQhRTy1ZlTEaASKmr0YAVxhMIKohuEydc=.d911ce7a-1f2e-4320-8c8c-66dc00174b9f@github.com>

On Wed, 29 Mar 2023 18:47:03 GMT, Chris Plummer  wrote:

>> tid0 is the thread ID of a platform therad. tid1 is the threadID of a virtual thread. The only change here is allow this test run with the main wrapper plugin ([CODETOOLS-7903373](https://bugs.openjdk.org/browse/CODETOOLS-7903373)), it would otherwise have to be excluded for those runs.
>
> I don't see any problemlist changes. Was this test failing when using the wrapper because of the lack of problemlisting?

I added this test recently via JDK-8303242. It failed when we sync'ed up the loom repo as the test configuration there runs the tests with the jtreg main wrapper. It was trivial to fix and this avoid needing to exclude it via ProblemList-Virtual.txt. Once jtreg is promoted and there is config added to run the tests with the virtual ThreadFactory then this test will be able to run in this mode.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1152393905

From alanb at openjdk.org  Wed Mar 29 19:42:35 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 29 Mar 2023 19:42:35 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v4]
In-Reply-To: 
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 
 
Message-ID: <4_Xz1S2uFPVW_ySuYjEtJFmmEKIWgw1DD9hLlTGyESs=.383d569f-1e08-48be-9af0-c39d4c5ee7c1@github.com>

On Wed, 29 Mar 2023 18:30:01 GMT, Chris Plummer  wrote:

>> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix ThreadSleepEvent again
>
> test/hotspot/jtreg/serviceability/jvmti/thread/GetFrameCount/framecnt01/framecnt01.java line 82:
> 
>> 80: 
>> 81:         // this is too fragile, implementation can change at any time.
>> 82:         checkFrames(vThread1, false, 14);
> 
> Is this due to the `@hidden` being added to `Continuation.enter()` and `enter0()`? If so, since both methods are now hidden, why are there not 2 fewer frames? Was there also an additional frame added somewhere?

No, it's that a lambda expression is replaced in the implementation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1152402303

From duke at openjdk.org  Wed Mar 29 19:55:37 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 29 Mar 2023 19:55:37 GMT
Subject: RFR: 8302819: Remove JAR Index [v2]
In-Reply-To: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
Message-ID: 

> This PR removes the JAR index feature from the runtime:
> 
> - `URLClassPath` is  updated to remove the `enableJarIndex` system property and any code which would be called when this property was `true`
> - The `JarIndex` implementation class is moved into `jdk.jartool` module.
> - The `InvalidJarIndexError` exception class is removed because it falls out of use
> - The test `test/jdk/sun/misc/JarIndex/metaInfFileNames/Basic.java` is removed because it depends on the JarIndex feature being present
> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeForClassLoaderTest.java` is removed because it depends on the JarIndex feature being present
> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeTest.java` is removed because it end up being the only caller of the  JarIndex.merge feature
> - All `JarIndex` methods/constructors which are not used by the `jar -i` implementation are removed. 
> - `JarIndex` is given package-private access.
> 
> Outstanding code work:
> 
> - Create tests for `JarFile` and `JarInputStream` accepting dusty INDEX jars.
> 
> Outstanding work:
> 
> - CSR for the removal
> - Release notes for the removal
> - Coordination of the update of the Jar File Specification

Eirik Bjorsnos 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 11 additional commits since the last revision:

 - Remove blank line 93 as per suggestion by Mandy
 - Merge branch 'master' into remove-jar-index
 - Remove JarIndex default constructor
 - Make JarIndex.INDEX_NAME package private
 - Remove outdated reference to URLClassLoader using JarIndex
 - Make JarIndex package private
 - The JarIndex.merge method ended up being used only by the JarIndexMergeTest test. Removing this test, the JarIndex.merge methods and a number of other JarIndex methods not used by the 'jar' tool
 - Revert the export of sun.security.action to jdk.jartool. JarIndex can use System.property instead since the 'jar' tool does not run with a SecurityManager
 - Revert noisy whitespace changes
 - Revert noisy whitespace changes
 - ... and 1 more: https://git.openjdk.org/jdk/compare/599939df...2b5d8a4a

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13158/files
  - new: https://git.openjdk.org/jdk/pull/13158/files/fee0da27..2b5d8a4a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13158&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13158&range=00-01

  Stats: 12002 lines in 289 files changed: 4769 ins; 5962 del; 1271 mod
  Patch: https://git.openjdk.org/jdk/pull/13158.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13158/head:pull/13158

PR: https://git.openjdk.org/jdk/pull/13158

From duke at openjdk.org  Wed Mar 29 19:55:40 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 29 Mar 2023 19:55:40 GMT
Subject: RFR: 8302819: Remove JAR Index [v2]
In-Reply-To: 
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 
Message-ID: <4MdPoBeCqEuqUw0f5bJ9Rb6yFl_nN0nhcb6CvOTnrvI=.d5b580d5-c8c3-4acc-8422-8b1ecd9d8b85@github.com>

On Tue, 28 Mar 2023 20:06:03 GMT, Mandy Chung  wrote:

>> Eirik Bjorsnos 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 11 additional commits since the last revision:
>> 
>>  - Remove blank line 93 as per suggestion by Mandy
>>  - Merge branch 'master' into remove-jar-index
>>  - Remove JarIndex default constructor
>>  - Make JarIndex.INDEX_NAME package private
>>  - Remove outdated reference to URLClassLoader using JarIndex
>>  - Make JarIndex package private
>>  - The JarIndex.merge method ended up being used only by the JarIndexMergeTest test. Removing this test, the JarIndex.merge methods and a number of other JarIndex methods not used by the 'jar' tool
>>  - Revert the export of sun.security.action to jdk.jartool. JarIndex can use System.property instead since the 'jar' tool does not run with a SecurityManager
>>  - Revert noisy whitespace changes
>>  - Revert noisy whitespace changes
>>  - ... and 1 more: https://git.openjdk.org/jdk/compare/599939df...2b5d8a4a
>
> src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 936:
> 
>> 934:         @Override
>> 935:         URL[] getClassPath() throws IOException {
>> 936: 
> 
> Nit: extra line 936 can be removed.

Thank to @mlchung,  line 936 is now history!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13158#discussion_r1152412960

From tvaleev at openjdk.org  Wed Mar 29 19:58:17 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Wed, 29 Mar 2023 19:58:17 GMT
Subject: RFR: 8266571: Sequenced Collections [v4]
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <-BNnKi-AQ6XTBe-GxXIn9Zq7WdROvR9mX73H_gr2rs8=.4c034fa8-781f-4739-ade8-e24f507f55be@github.com>
 
 
Message-ID: 

On Wed, 29 Mar 2023 19:20:16 GMT, R?mi Forax  wrote:

>> src/java.base/share/classes/java/util/SequencedCollection.java line 107:
>> 
>>> 105:      */
>>> 106:     default void addFirst(E e) {
>>> 107:         throw new UnsupportedOperationException();
>> 
>> Can this be defaulted to `this.reversed().addLast()` instead? If this throws uoe, the reversed should throw uoe as well; and the new default can simplify implementations by much as well.
>
> In the same spirit, `reversed()` should also have a default implementation equivalent to
> 
>   Collections.unmodifiableSequenceCollection(Arrays.asList(this.toArray())).reversed()

@forax but this would not be a view: changes in the underlying collection won't be reflected

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1152416692

From alanb at openjdk.org  Wed Mar 29 20:01:09 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 29 Mar 2023 20:01:09 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity
In-Reply-To: 
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
 
 
Message-ID: 

On Wed, 29 Mar 2023 18:29:18 GMT, Aleksey Shipilev  wrote:

> Yes, let me fix that. `TimeUnit.toNanos` handles it well itself, it seems.

This code is refactored in PR 13203 so we'll have to merge at some point.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13225#discussion_r1152419710

From forax at openjdk.org  Wed Mar 29 20:08:31 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 29 Mar 2023 20:08:31 GMT
Subject: RFR: 8266571: Sequenced Collections [v4]
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <-BNnKi-AQ6XTBe-GxXIn9Zq7WdROvR9mX73H_gr2rs8=.4c034fa8-781f-4739-ade8-e24f507f55be@github.com>
 
 
 
Message-ID: 

On Wed, 29 Mar 2023 19:54:48 GMT, Tagir F. Valeev  wrote:

>> In the same spirit, `reversed()` should also have a default implementation equivalent to
>> 
>>   Collections.unmodifiableSequenceCollection(Arrays.asList(this.toArray())).reversed()
>
> @forax but this would not be a view: changes in the underlying collection won't be reflected

Yes,
The spec says :"Changes to the underlying collection might or might not be visible in this reversed view, depending upon the implementation." so i believe the default implementation i proposed is a valid implementation

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1152426988

From cjplummer at openjdk.org  Wed Mar 29 20:37:37 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 29 Mar 2023 20:37:37 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v4]
In-Reply-To: 
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 
Message-ID: 

On Wed, 29 Mar 2023 08:00:36 GMT, Alan Bateman  wrote:

>> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The APIs that were preview APIs in Java 19/20 are changed to permanent and their `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The JNI and JVMTI versions are bumped as this is the first change in 21 to need the new version number. A lot of tests are updated to drop `@enablePreview` and --enable-preview.
>> 
>> There is one API change from Java 19/20, the preview API Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an update to the JVMTI GetThreadInfo implementation to read the TCCL consistently.
>> 
>> In addition, there are a small number of implementation changes to sync up from the loom fibers branch:
>> 
>> - A number of stack frames are `@Hidden` to reduce noise in the stack traces. This exposed a few issues with the stack walker code. More specifically, the cases where  end of a continuation falls precisely at the end of the batch, or where the remaining frames are hidden, weren't handled correctly.
>> - The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in Thread rather than in two classes.
>> - A few robustness improvements for OOME and SOE. There is more to do here, for future PRs.
>> - New system property to print a stack trace when a virtual thread sets its own value of a TL.
>> - ThreadPerTaskExecutor is changed to use FutureTask.
>> 
>> Testing: tier1-6.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix ThreadSleepEvent again

Serviceability changes look good.

-------------

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13203#pullrequestreview-1363917524

From joehw at openjdk.org  Wed Mar 29 20:37:51 2023
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 29 Mar 2023 20:37:51 GMT
Subject: RFR: 8303530: Add system property for custom JAXP configuration
 file [v4]
In-Reply-To: 
References: 
Message-ID: 

> Add a system property, jdk.xml.config.file, to return the path to a custom JAXP configuration file. The current configuration file, jaxp.properties, that the JDK supports will become the default configuration file.
> 
> CSR: https://bugs.openjdk.org/browse/JDK-8303531
> 
> Tests: XML SQE and JCK tests passed.

Joe Wang has updated the pull request incrementally with one additional commit since the last revision:

  change prefix from jdk to java; rm zip file that accidentally checked in

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12985/files
  - new: https://git.openjdk.org/jdk/pull/12985/files/43407bdc..b9dff937

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12985&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12985&range=02-03

  Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12985.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12985/head:pull/12985

PR: https://git.openjdk.org/jdk/pull/12985

From joehw at openjdk.org  Wed Mar 29 20:42:51 2023
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 29 Mar 2023 20:42:51 GMT
Subject: RFR: 8303530: Add system property for custom JAXP configuration
 file [v5]
In-Reply-To: 
References: 
Message-ID: 

> Add a system property, jdk.xml.config.file, to return the path to a custom JAXP configuration file. The current configuration file, jaxp.properties, that the JDK supports will become the default configuration file.
> 
> CSR: https://bugs.openjdk.org/browse/JDK-8303531
> 
> Tests: XML SQE and JCK tests passed.

Joe Wang has updated the pull request incrementally with one additional commit since the last revision:

  change prefix from jdk to java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12985/files
  - new: https://git.openjdk.org/jdk/pull/12985/files/b9dff937..aa7db3ae

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12985&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12985&range=03-04

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12985.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12985/head:pull/12985

PR: https://git.openjdk.org/jdk/pull/12985

From lmesnik at openjdk.org  Wed Mar 29 21:49:21 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 29 Mar 2023 21:49:21 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v4]
In-Reply-To: 
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 
Message-ID: <96yRAvTFAMp431o3TzORkDS73JONn6D4UwdLwSbUqv4=.1a128faa-78e5-427b-98f4-c5624295e396@github.com>

On Wed, 29 Mar 2023 08:00:36 GMT, Alan Bateman  wrote:

>> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The APIs that were preview APIs in Java 19/20 are changed to permanent and their `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The JNI and JVMTI versions are bumped as this is the first change in 21 to need the new version number. A lot of tests are updated to drop `@enablePreview` and --enable-preview.
>> 
>> There is one API change from Java 19/20, the preview API Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an update to the JVMTI GetThreadInfo implementation to read the TCCL consistently.
>> 
>> In addition, there are a small number of implementation changes to sync up from the loom fibers branch:
>> 
>> - A number of stack frames are `@Hidden` to reduce noise in the stack traces. This exposed a few issues with the stack walker code. More specifically, the cases where  end of a continuation falls precisely at the end of the batch, or where the remaining frames are hidden, weren't handled correctly.
>> - The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in Thread rather than in two classes.
>> - A few robustness improvements for OOME and SOE. There is more to do here, for future PRs.
>> - New system property to print a stack trace when a virtual thread sets its own value of a TL.
>> - ThreadPerTaskExecutor is changed to use FutureTask.
>> 
>> Testing: tier1-6.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix ThreadSleepEvent again

Test changes looks good.

-------------

Marked as reviewed by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13203#pullrequestreview-1363976888

From psandoz at openjdk.org  Wed Mar 29 21:49:32 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 29 Mar 2023 21:49:32 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v4]
In-Reply-To: 
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 
Message-ID: 

On Wed, 29 Mar 2023 08:00:36 GMT, Alan Bateman  wrote:

>> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The APIs that were preview APIs in Java 19/20 are changed to permanent and their `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The JNI and JVMTI versions are bumped as this is the first change in 21 to need the new version number. A lot of tests are updated to drop `@enablePreview` and --enable-preview.
>> 
>> There is one API change from Java 19/20, the preview API Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an update to the JVMTI GetThreadInfo implementation to read the TCCL consistently.
>> 
>> In addition, there are a small number of implementation changes to sync up from the loom fibers branch:
>> 
>> - A number of stack frames are `@Hidden` to reduce noise in the stack traces. This exposed a few issues with the stack walker code. More specifically, the cases where  end of a continuation falls precisely at the end of the batch, or where the remaining frames are hidden, weren't handled correctly.
>> - The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in Thread rather than in two classes.
>> - A few robustness improvements for OOME and SOE. There is more to do here, for future PRs.
>> - New system property to print a stack trace when a virtual thread sets its own value of a TL.
>> - ThreadPerTaskExecutor is changed to use FutureTask.
>> 
>> Testing: tier1-6.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix ThreadSleepEvent again

src/java.base/share/classes/java/lang/Thread.java line 1546:

> 1544:             // bind thread to container
> 1545:             if (this.container != null)
> 1546:                 throw new IllegalThreadStateException();

This check is not replicated in `VirtualThread::start`, i think the CAS protects against that. Maybe assert instead in the virtual thread implementation, thereby the comment in `setThreadContainer` can be changed to something like "`this.container` checked/asserted to be != null before call to Virtual/Thread::start(ThreadContainer)" ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1152514040

From mchung at openjdk.org  Wed Mar 29 21:50:16 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 29 Mar 2023 21:50:16 GMT
Subject: RFR: 8304585: Method::invoke rewraps InvocationTargetException if a
 caller-sensitive method throws IAE
Message-ID: 

A simple fix to `Method::invoke` which wraps IAE with `InvocationTargetException` twice if it's thrown by a caller-sensitive method which has no adapter.

-------------

Commit messages:
 - 8304585: Method::invoke rewraps InvocationTargetException if a caller-sensitive method throws IAE

Changes: https://git.openjdk.org/jdk/pull/13233/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13233&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304585
  Stats: 87 lines in 2 files changed: 81 ins; 4 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13233.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13233/head:pull/13233

PR: https://git.openjdk.org/jdk/pull/13233

From jpai at openjdk.org  Wed Mar 29 21:56:39 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 29 Mar 2023 21:56:39 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v16]
In-Reply-To: <_X148gAz795J-ExMjOAyvrykzc7a9vLdqg9pY2EaHKo=.40e38e68-013b-436e-bab0-933208fe4242@github.com>
References: 
 
 <_X148gAz795J-ExMjOAyvrykzc7a9vLdqg9pY2EaHKo=.40e38e68-013b-436e-bab0-933208fe4242@github.com>
Message-ID: 

On Tue, 28 Mar 2023 11:02:46 GMT, Alan Bateman  wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use test.jdk system property in test
>
> test/jdk/tools/jlink/plugins/CDSPluginTest.java line 97:
> 
>> 95:            // separate --module-path will force the JLink task to read the ModuleTarget from
>> 96:            // the java.base module-info.class to identify the target platform for the image
>> 97:            // being generated.
> 
> I'm a bit uncomfortable with change the test for the CDS plugin as part of this change but can live with it.

Early on during this PR, we decided and implemented to read the `ModuleTarget` only if the java.base module's file path doesn't match that of the current platform's file path. If we remove that check and instead always read the ModuleTarget of java.base, in the JLinkTask, we won't need any changes to this test, since the JLinkTask will rightly find the correct target platform from the module-info.class. Furthermore, rest of the cross platform image generation would work fine too.

Do you think we should remove that file path check? I am guessing the reason why the file path checks were suggested was to reduce any chances of regression with these current changes?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/11943#discussion_r1151311196

From liach at openjdk.org  Wed Mar 29 21:58:50 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 29 Mar 2023 21:58:50 GMT
Subject: RFR: 8266571: Sequenced Collections [v4]
In-Reply-To: <-BNnKi-AQ6XTBe-GxXIn9Zq7WdROvR9mX73H_gr2rs8=.4c034fa8-781f-4739-ade8-e24f507f55be@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <-BNnKi-AQ6XTBe-GxXIn9Zq7WdROvR9mX73H_gr2rs8=.4c034fa8-781f-4739-ade8-e24f507f55be@github.com>
Message-ID: 

On Tue, 28 Mar 2023 02:37:22 GMT, Stuart Marks  wrote:

>> PR for Sequenced Collections implementation.
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify handling of cached keySet, values, and entrySet views.

In the JEP:
> A sequenced collection supports common operations at either end, and it supports processing the elements from first to last and from last to first (i.e., forward and reverse).

> The reverse-ordered view enables all the different sequenced types to process elements in both directions, using all the usual iteration mechanisms: Enhanced for loops, explicit iterator() loops, forEach(), stream(), parallelStream(), and toArray().

This implies that for the reversed view, collection operations are not only supported, but can potentially be optimized. Our design should anticipate implementations of `SequencedCollection` to provide specific reversed implementations, like what we are already doing with `addAll` in ArrayList and ArrayDeque. If a collection cannot have efficient reverse-sequenced operations, it shouldn't be retrofitted into `SequencedCollection`, just like how we don't fit Deques into Lists.

Hence, I recommend:
1. Declare `reversed()` and one of the (First/Last) operation sets (add|get|remove) `abstract`, and delegae the other set to default call the operation on the reversed instead. 
   - Since we tend to work with the end of collections, I'd declare the `Last` methods to be abstract and delegate the `First` default implementations to `this.reversed().xxxLast()`
2. I don't think leaving `addLast()` implemented by default is a good idea, for modifiable implementations cannot discover that they missed the `addLast()` at compile time and can only discover when the implementation is actually used.
3. In the default `reversed()` implementation of `List` and `Deque`, add API notes to indicate to implementations opportunities to optimize the implementation, especially batch operations like `addAll` when the base implementation offers such an optimization.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1489338414

From liach at openjdk.org  Wed Mar 29 21:59:08 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 29 Mar 2023 21:59:08 GMT
Subject: RFR: 8266571: Sequenced Collections [v4]
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <-BNnKi-AQ6XTBe-GxXIn9Zq7WdROvR9mX73H_gr2rs8=.4c034fa8-781f-4739-ade8-e24f507f55be@github.com>
 
 
 
 
Message-ID: 

On Wed, 29 Mar 2023 20:05:10 GMT, R?mi Forax  wrote:

>> @forax but this would not be a view: changes in the underlying collection won't be reflected
>
> Yes,
> The spec says :"Changes to the underlying collection might or might not be visible in this reversed view, depending upon the implementation." so i believe the default implementation i proposed is a valid implementation

In the JEP, it says:
> Any modifications to the original collection are visible in the view.

If we don't have an efficient reversed view, I don't see a point of declaring a collection sequenced; same reason for declaring a sequenced/deque vs. a full-on list with inefficient list random access operations.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1152474419

From forax at openjdk.org  Wed Mar 29 21:59:08 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 29 Mar 2023 21:59:08 GMT
Subject: RFR: 8266571: Sequenced Collections [v4]
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <-BNnKi-AQ6XTBe-GxXIn9Zq7WdROvR9mX73H_gr2rs8=.4c034fa8-781f-4739-ade8-e24f507f55be@github.com>
 
 
 
 
 
Message-ID: 

On Wed, 29 Mar 2023 20:54:15 GMT, Chen Liang  wrote:

>> Yes,
>> The spec says :"Changes to the underlying collection might or might not be visible in this reversed view, depending upon the implementation." so i believe the default implementation i proposed is a valid implementation
>
> In the JEP, it says:
>> Any modifications to the original collection are visible in the view.
> 
> If we don't have an efficient reversed view, I don't see a point of declaring a collection sequenced; same reason for declaring a sequenced/deque vs. a full-on list with inefficient list random access operations.

The quote is from the javadoc of reversed (see above), it seems the JEP and the javadoc disagree :(

> If we don't have an efficient reversed view, I don't see a point of declaring a collection sequenced

Collections in the JDK provides more efficient implementations, this is what the code this PR does.
Providing a default implementation matters more for external libraries.

And that's why i think we do not need the interface SequencedCollection, because all these methods can be declared on Collection instead. Adding them on Collection has also the added benefit that as a user, all Clojure collections or any other implementations not in the JDK also get a good enough implementation of the method reversed().

My fear is that if we introduce all these methods on SequencedCollection instead of Collection, library implementations will never be updated to use SequencedCollection instead of Collection (because implementing SequencedCollection requires the library to work only on JDK 21+) while if reversed is declared on Collection, library maintainers will have more pressure to write an efficient implementation of reversed for their implementations (and will be able to do that without requiring the JDK 21).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1152494872

From darcy at openjdk.org  Wed Mar 29 22:08:58 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 29 Mar 2023 22:08:58 GMT
Subject: RFR: 8304585: Method::invoke rewraps InvocationTargetException if
 a caller-sensitive method throws IAE
In-Reply-To: 
References: 
Message-ID: <0ObiiFSlRNG4wD2rVn_VSbYdoi4F8z_nIDsoirtlsOA=.6ba437f8-eeab-45a3-b789-29a152cb4ede@github.com>

On Wed, 29 Mar 2023 21:26:24 GMT, Mandy Chung  wrote:

> A simple fix to `Method::invoke` which wraps IAE with `InvocationTargetException` twice if it's thrown by a caller-sensitive method which has no adapter.

Looks fine.

-------------

Marked as reviewed by darcy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13233#pullrequestreview-1364018900

From psandoz at openjdk.org  Wed Mar 29 22:11:09 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 29 Mar 2023 22:11:09 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v4]
In-Reply-To: 
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 
Message-ID: 

On Wed, 29 Mar 2023 08:00:36 GMT, Alan Bateman  wrote:

>> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The APIs that were preview APIs in Java 19/20 are changed to permanent and their `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The JNI and JVMTI versions are bumped as this is the first change in 21 to need the new version number. A lot of tests are updated to drop `@enablePreview` and --enable-preview.
>> 
>> There is one API change from Java 19/20, the preview API Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an update to the JVMTI GetThreadInfo implementation to read the TCCL consistently.
>> 
>> In addition, there are a small number of implementation changes to sync up from the loom fibers branch:
>> 
>> - A number of stack frames are `@Hidden` to reduce noise in the stack traces. This exposed a few issues with the stack walker code. More specifically, the cases where  end of a continuation falls precisely at the end of the batch, or where the remaining frames are hidden, weren't handled correctly.
>> - The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in Thread rather than in two classes.
>> - A few robustness improvements for OOME and SOE. There is more to do here, for future PRs.
>> - New system property to print a stack trace when a virtual thread sets its own value of a TL.
>> - ThreadPerTaskExecutor is changed to use FutureTask.
>> 
>> Testing: tier1-6.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix ThreadSleepEvent again

Looks good.

test/jdk/java/lang/Thread/virtual/TraceVirtualThreadLocals.java line 65:

> 63: 
> 64:     /**
> 65:      * Runs a task in a virutal thread, returning a String with any output printed

Suggestion:

     * Runs a task in a virtual thread, returning a String with any output printed

-------------

Marked as reviewed by psandoz (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13203#pullrequestreview-1364039280
PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1152529524

From psandoz at openjdk.org  Wed Mar 29 22:35:31 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 29 Mar 2023 22:35:31 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v15]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Wed, 22 Mar 2023 14:07:14 GMT, Per Minborg  wrote:

>> Back to @PaulSandoz  question - "how does the caller know what the structure contains?". The caller typically doesn't care too much about what the returned struct is. But it might care about which "values" can be captured. That said, the set of such interesting values, is not too surprising. As demonstrated in the example in the `Linker.capturedCallState` method, once the client knows the name (and "errno" is likely to be 90% case), everything else follows from there - as the layout can be used to obtain var handles for the required values.
>> 
>> But, perhaps, now that I write this, I realize that what @PaulSandoz might _really_ be asking is: how do I know that e.g. the returned struct will not contain e.g. nested structs, sequences, or other non-sense. So we might specify (in a normative way) that the returned layout is a struct layout, whose member layouts are one or more value layouts (possibly with some added padding layouts). The names of the value layouts reflect the names of the values that can be captured.
>> 
>> And _then_ we show an example of the layout we return for Windows/x64 (as that's more interesting).
>
> I've updated the specs as per how I interpret the comments above. Let me know your thoughts on this.

This is much clearer. Are the names of the struct members guaranteed to be symbols that can be found up via the linker's default lookup? i.e. a small set of important global variables.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1152550849

From dholmes at openjdk.org  Wed Mar 29 22:50:56 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 29 Mar 2023 22:50:56 GMT
Subject: RFR: 8304871: Use default visibility for static library builds
 [v2]
In-Reply-To: 
References: 
 
Message-ID: <9OGfeJB6kwGA0R4av49-bFWKQsUq9wk8wdrLtgovRXg=.ba246907-b74a-44a5-b4dd-b2a7d08fbf20@github.com>

On Mon, 27 Mar 2023 09:40:22 GMT, Severin Gehwolf  wrote:

>> Please review this change for symbol visibility of static library artefacts. This fixes an issue when
>> OpenJDK is being used as a base for generating native images preventing the symbols from being
>> exported and looked up from the executable. Note that symbol visibity is now controlled by a
>> linker version script downstream. This changes nothing for the regularly shipped dynamic libraries.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Explicitly set the JNI_EXPORT define for static libs

Marked as reviewed by dholmes (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13177#pullrequestreview-1364077182

From jlu at openjdk.org  Wed Mar 29 22:58:51 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 29 Mar 2023 22:58:51 GMT
Subject: RFR: 8305111: Locale.lookupTag has typo in parameter
Message-ID: <0RAdK8ZfiSUn1UZKzX44LAvjE0i8l_0LKEoC-63bY24=.12f961ee-ac5b-41cf-9697-62e3f6b8812f@github.com>

Small typo fix in Locale.lookupTag

_tangs_ should be _tags_

-------------

Commit messages:
 - Fix typo

Changes: https://git.openjdk.org/jdk/pull/13235/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13235&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305111
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13235.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13235/head:pull/13235

PR: https://git.openjdk.org/jdk/pull/13235

From lbrtchx at gmail.com  Wed Mar 29 23:03:02 2023
From: lbrtchx at gmail.com (Albretch Mueller)
Date: Wed, 29 Mar 2023 23:03:02 +0000
Subject: Is there such a thing as a customizable SAX Contenthandler which
 works as a XPath observer of sorts?
Message-ID: 

SAX Content handlers do parse data in one go with very little to no
overhead whatsoever, but for each XML file with a differently layout
or if you need something different out of the same XML file, you will
need to code a corresponding content handler. There is also the
problem that not all XML-ish data is nicely written with the data
types in a serial order.
I think there should be something like what I need even if partially
(if I am making sense ;-)). Which libraries implement such a thing? Or
how would you suggest such a library should be implemented?
lbrtchx

From mchung at openjdk.org  Wed Mar 29 23:03:42 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 29 Mar 2023 23:03:42 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v4]
In-Reply-To: 
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 
Message-ID: 

On Wed, 29 Mar 2023 08:00:36 GMT, Alan Bateman  wrote:

>> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The APIs that were preview APIs in Java 19/20 are changed to permanent and their `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The JNI and JVMTI versions are bumped as this is the first change in 21 to need the new version number. A lot of tests are updated to drop `@enablePreview` and --enable-preview.
>> 
>> There is one API change from Java 19/20, the preview API Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an update to the JVMTI GetThreadInfo implementation to read the TCCL consistently.
>> 
>> In addition, there are a small number of implementation changes to sync up from the loom fibers branch:
>> 
>> - A number of stack frames are `@Hidden` to reduce noise in the stack traces. This exposed a few issues with the stack walker code. More specifically, the cases where  end of a continuation falls precisely at the end of the batch, or where the remaining frames are hidden, weren't handled correctly.
>> - The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in Thread rather than in two classes.
>> - A few robustness improvements for OOME and SOE. There is more to do here, for future PRs.
>> - New system property to print a stack trace when a virtual thread sets its own value of a TL.
>> - ThreadPerTaskExecutor is changed to use FutureTask.
>> 
>> Testing: tier1-6.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix ThreadSleepEvent again

The stack walker change looks good.  I also reviewed other changes which look fine to me.

-------------

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13203#pullrequestreview-1364091585

From lancea at openjdk.org  Wed Mar 29 23:15:39 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 29 Mar 2023 23:15:39 GMT
Subject: RFR: 8305111: Locale.lookupTag has typo in parameter
In-Reply-To: <0RAdK8ZfiSUn1UZKzX44LAvjE0i8l_0LKEoC-63bY24=.12f961ee-ac5b-41cf-9697-62e3f6b8812f@github.com>
References: <0RAdK8ZfiSUn1UZKzX44LAvjE0i8l_0LKEoC-63bY24=.12f961ee-ac5b-41cf-9697-62e3f6b8812f@github.com>
Message-ID: <0GMrdSomYb9w3PxvFQlPgf6_q2CrkbgTHQMbr4068q8=.b261b996-dd96-4c71-bbf2-466c88374a5a@github.com>

On Wed, 29 Mar 2023 22:51:12 GMT, Justin Lu  wrote:

> Small typo fix in Locale.lookupTag
> 
> _tangs_ should be _tags_

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13235#pullrequestreview-1364100110

From naoto at openjdk.org  Wed Mar 29 23:21:45 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 29 Mar 2023 23:21:45 GMT
Subject: RFR: 8225641: Calendar.roll(int field) does not work correctly for
 WEEK_OF_YEAR [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 28 Mar 2023 21:06:34 GMT, Justin Lu  wrote:

>> This PR fixes the bug which occurred when `Calendar.roll(WEEK_OF_YEAR)` rolled into a minimal first week with an invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo.
>> 
>> For example, Rolling _Monday, 30 December 2019_ by 1 week produced _Monday, 31 December 2018_, which is incorrect. This is because `WEEK_OF_YEAR` is rolled from 52 to 1, and the original `DAY_OF_WEEK` is 1. However, there is no Monday in week 1 of 2019. This is exposed when a future method calls `Calendar.complete()`, which eventually calculates a `fixedDate` with the invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo.
>> 
>> To prevent this, a check is added for rolls into week 1, which determines if the first week is minimal. If it is indeed minimal, then it is checked if  `DAY_OF_WEEK` exists in that week, if not, `WEEK_OF_YEAR` must be incremented by one.
>> 
>> After the fix, Rolling _Monday, 30 December 2019_ by 1 week produces _Monday, 7 January 2019_
>
> Justin Lu has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - Impl cleanup, add Saturday end day conditional
>  - Rename test, clarify test documentation
>  - Add type to static declaration of Cal.Builder, since only concerned with Gregorian for this test
>  - Pass in amount as 1 directly
>  - Reuse Calendar.Builder

src/java.base/share/classes/java/util/GregorianCalendar.java line 3014:

> 3012:      */
> 3013:     private boolean dayInMinWeek (int day, int startDay, int endDay) {
> 3014:         endDay = endDay == 0

Why `endDay` can be `0`? If the arguments are `Calendar.XXXDAY`, should they be between 1 to 7? In other words, why is the above calling site doing `getFirstDayOfWeek() - 1`?
I'd add some range checks for the input values.

test/jdk/java/util/Calendar/RollFromLastToFirstWeek.java line 52:

> 50:  */
> 51: public class RollFromLastToFirstWeek {
> 52:     static Calendar.Builder GREGORIAN_BUILDER = new Builder()

Nit: `Calendar.` can be omitted (and can be `private static final`)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13031#discussion_r1152579044
PR Review Comment: https://git.openjdk.org/jdk/pull/13031#discussion_r1152579338

From iris at openjdk.org  Wed Mar 29 23:25:01 2023
From: iris at openjdk.org (Iris Clark)
Date: Wed, 29 Mar 2023 23:25:01 GMT
Subject: RFR: 8305111: Locale.lookupTag has typo in parameter
In-Reply-To: <0RAdK8ZfiSUn1UZKzX44LAvjE0i8l_0LKEoC-63bY24=.12f961ee-ac5b-41cf-9697-62e3f6b8812f@github.com>
References: <0RAdK8ZfiSUn1UZKzX44LAvjE0i8l_0LKEoC-63bY24=.12f961ee-ac5b-41cf-9697-62e3f6b8812f@github.com>
Message-ID: 

On Wed, 29 Mar 2023 22:51:12 GMT, Justin Lu  wrote:

> Small typo fix in Locale.lookupTag
> 
> _tangs_ should be _tags_

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13235#pullrequestreview-1364106018

From mcimadamore at openjdk.org  Wed Mar 29 23:52:04 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 29 Mar 2023 23:52:04 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v15]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 29 Mar 2023 08:55:08 GMT, Per Minborg  wrote:

>> API changes for the FFM API (third preview)
>> 
>> Specdiff:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
>> 
>> Javadoc:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup finality

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 410:

> 408:  * wrapping a native pointer. For instance, if such pointer points to a C struct, the client might prefer to resize the
> 409:  * segment unsafely, to match the size of the struct (so that out-of-bounds access will be detected by the API). If the
> 410:  * size is known statically, using an address layout with the correct target layout might be preferable.

Suggestion:

 * true size of the zero-length memory segment is known statically, using an address layout with the correct target layout might be preferable.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1152595828

From mcimadamore at openjdk.org  Wed Mar 29 23:58:24 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 29 Mar 2023 23:58:24 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v15]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Wed, 29 Mar 2023 22:32:20 GMT, Paul Sandoz  wrote:

>> I've updated the specs as per how I interpret the comments above. Let me know your thoughts on this.
>
> This is much clearer. Are the names of the struct members guaranteed to be symbols that can be found up via the linker's default lookup? i.e. a small set of important global variables.

While they might be defined as global variable, I wouldn't read too much into this. Even `errno` is not really a global variable, but some thread local value that the native compiler knows about (e.g. setting the global variable doesn't really do much). Quoting from Linux man page:


errno  is  defined  by  the ISO C standard to be a modifiable lvalue of
       type int, and must not be explicitly declared; errno may  be  a  macro.
       errno  is  thread-local;  setting  it in one thread does not affect its
       value in any other thread.


This seems to imply that errno might even be something else. Given how the story goes for errno, I don't think we'd want to restrict the spec to state that these names should be discoverable via the lookup.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1152598834

From liach at openjdk.org  Thu Mar 30 00:03:12 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 30 Mar 2023 00:03:12 GMT
Subject: RFR: 8304585: Method::invoke rewraps InvocationTargetException if
 a caller-sensitive method throws IAE
In-Reply-To: 
References: 
Message-ID: 

On Wed, 29 Mar 2023 21:26:24 GMT, Mandy Chung  wrote:

> A simple fix to `Method::invoke` which wraps IAE with `InvocationTargetException` twice if it's thrown by a caller-sensitive method which has no adapter.

test/jdk/java/lang/reflect/Method/CallerSensitiveMethodInvoke.java line 56:

> 54:             Method m = Field.class.getDeclaredMethod("get", Object.class);
> 55:             m.invoke(f, new Object());
> 56:         } catch (InvocationTargetException e) {

The test should fail if invoke executes without throwing, same for below

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13233#discussion_r1152600270

From mcimadamore at openjdk.org  Thu Mar 30 00:05:55 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 30 Mar 2023 00:05:55 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v15]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 29 Mar 2023 08:55:08 GMT, Per Minborg  wrote:

>> API changes for the FFM API (third preview)
>> 
>> Specdiff:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
>> 
>> Javadoc:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup finality

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 396:

> 394:  *}
> 395:  *
> 396:  * Alternatively, if the size of the foreign segment is known statically, clients can associate a

Suggestion:

 * Alternatively, if the true size of the zero-length memory segment is known statically, clients can associate a

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1152602321

From mchung at openjdk.org  Thu Mar 30 00:43:29 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 30 Mar 2023 00:43:29 GMT
Subject: RFR: 8304585: Method::invoke rewraps InvocationTargetException if
 a caller-sensitive method throws IAE
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 29 Mar 2023 23:58:59 GMT, Chen Liang  wrote:

>> A simple fix to `Method::invoke` which wraps IAE with `InvocationTargetException` twice if it's thrown by a caller-sensitive method which has no adapter.
>
> test/jdk/java/lang/reflect/Method/CallerSensitiveMethodInvoke.java line 56:
> 
>> 54:             Method m = Field.class.getDeclaredMethod("get", Object.class);
>> 55:             m.invoke(f, new Object());
>> 56:         } catch (InvocationTargetException e) {
> 
> The test should fail if invoke executes without throwing, same for below

not following what you mean.  Can you elaborate?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13233#discussion_r1152621017

From naoto at openjdk.org  Thu Mar 30 00:44:22 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 30 Mar 2023 00:44:22 GMT
Subject: RFR: 8305111: Locale.lookupTag has typo in parameter
In-Reply-To: <0RAdK8ZfiSUn1UZKzX44LAvjE0i8l_0LKEoC-63bY24=.12f961ee-ac5b-41cf-9697-62e3f6b8812f@github.com>
References: <0RAdK8ZfiSUn1UZKzX44LAvjE0i8l_0LKEoC-63bY24=.12f961ee-ac5b-41cf-9697-62e3f6b8812f@github.com>
Message-ID: 

On Wed, 29 Mar 2023 22:51:12 GMT, Justin Lu  wrote:

> Small typo fix in Locale.lookupTag
> 
> _tangs_ should be _tags_

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13235#pullrequestreview-1364170271

From liach at openjdk.org  Thu Mar 30 00:49:34 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 30 Mar 2023 00:49:34 GMT
Subject: RFR: 8266571: Sequenced Collections [v4]
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <-BNnKi-AQ6XTBe-GxXIn9Zq7WdROvR9mX73H_gr2rs8=.4c034fa8-781f-4739-ade8-e24f507f55be@github.com>
 
 
 
 
 
 
Message-ID: <9pJ43hfjRd9PuedB__Q7ziY-_8PzPIlfHwUUQEZN4vo=.1d3edbca-0bde-4e11-a223-c31f2a556a94@github.com>

On Wed, 29 Mar 2023 21:18:04 GMT, R?mi Forax  wrote:

>> In the JEP, it says:
>>> Any modifications to the original collection are visible in the view.
>> 
>> If we don't have an efficient reversed view, I don't see a point of declaring a collection sequenced; same reason for declaring a sequenced/deque vs. a full-on list with inefficient list random access operations.
>
> The quote is from the javadoc of reversed (see above), it seems the JEP and the javadoc disagree :(
> 
>> If we don't have an efficient reversed view, I don't see a point of declaring a collection sequenced
> 
> Collections in the JDK provides more efficient implementations, this is what the code this PR does.
> Providing a default implementation matters more for external libraries.
> 
> And that's why i think we do not need the interface SequencedCollection, because all these methods can be declared on Collection instead. Adding them on Collection has also the added benefit that as a user, all Clojure collections or any other implementations not in the JDK also get a good enough implementation of the method reversed().
> 
> My fear is that if we introduce all these methods on SequencedCollection instead of Collection, library implementations will never be updated to use SequencedCollection instead of Collection (because implementing SequencedCollection requires the library to work only on JDK 21+) while if reversed is declared on Collection, library maintainers will have more pressure to write an efficient implementation of reversed for their implementations (and will be able to do that without requiring the JDK 21).

So your model would be like:

public interface Collection ... {
    ...
    default Collection reversed() {...} // - can dump to array
    default void addLast() {...} // or addFirst - no reliable impl
    default boolean removeLast() {...} // or removeFirst - no reliable impl
    default T getLast() {...} // or getFirst - can dump to array
}

I don't think `reversed()` is the problem here; `addLast` `removeLast` cannot be implemented from the existing Collection methods without risking contract violations, so I don't recommend leaving them as default methods. I still think SequencedCollection should exist for its specification of add/removeLast and improved performance of getLast.

That said, it is true that SequencedCollection as an interface itself has less merit as unmodifiable/immutable collections. It will only work as a marker indicating the contract that an encounter sequence is defined.

For libraries, they can use version-specific class files in META-INF; to un-sequence a collection implementation should be quite simple, as nuking the bridge `reversed` returning `SequencedCollection` and the `SequencedCollection` symbol from interface lists. This can be done with a simple classfile transformer.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1152623381

From liach at openjdk.org  Thu Mar 30 00:53:15 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 30 Mar 2023 00:53:15 GMT
Subject: RFR: 8304585: Method::invoke rewraps InvocationTargetException if
 a caller-sensitive method throws IAE
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 30 Mar 2023 00:40:46 GMT, Mandy Chung  wrote:

>> test/jdk/java/lang/reflect/Method/CallerSensitiveMethodInvoke.java line 56:
>> 
>>> 54:             Method m = Field.class.getDeclaredMethod("get", Object.class);
>>> 55:             m.invoke(f, new Object());
>>> 56:         } catch (InvocationTargetException e) {
>> 
>> The test should fail if invoke executes without throwing, same for below
>
> not following what you mean.  Can you elaborate?

Though very unlikely, I recommend adding a line of `Assertions.fail("Should not reach here");` after the `m.invoke` and before the catch to ensure the invocation always throw `InvocationTargetException`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13233#discussion_r1152624889

From mchung at openjdk.org  Thu Mar 30 01:07:17 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 30 Mar 2023 01:07:17 GMT
Subject: RFR: 8304585: Method::invoke rewraps InvocationTargetException if
 a caller-sensitive method throws IAE
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Thu, 30 Mar 2023 00:50:11 GMT, Chen Liang  wrote:

>> not following what you mean.  Can you elaborate?
>
> Though very unlikely, I recommend adding a line of `Assertions.fail("Should not reach here");` after the `m.invoke` and before the catch to ensure the invocation always throw `InvocationTargetException`.

I see what you mean.  They should always throw.  I could add assert.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13233#discussion_r1152630640

From mchung at openjdk.org  Thu Mar 30 01:15:33 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 30 Mar 2023 01:15:33 GMT
Subject: RFR: 8304585: Method::invoke rewraps InvocationTargetException if
 a caller-sensitive method throws IAE [v2]
In-Reply-To: 
References: 
Message-ID: <5hd5W9BolJM8MwB5RPnSXPkr046uX5e5r2JG17sT1EY=.11558298-6ab8-47f1-bc99-548ed98c7250@github.com>

> A simple fix to `Method::invoke` which wraps IAE with `InvocationTargetException` twice if it's thrown by a caller-sensitive method which has no adapter.

Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:

  the test should fail if Method::invoke doesn't throw

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13233/files
  - new: https://git.openjdk.org/jdk/pull/13233/files/45c7daf0..9af2d663

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13233&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13233&range=00-01

  Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13233.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13233/head:pull/13233

PR: https://git.openjdk.org/jdk/pull/13233

From jpai at openjdk.org  Thu Mar 30 01:22:18 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 30 Mar 2023 01:22:18 GMT
Subject: RFR: 8304585: Method::invoke rewraps InvocationTargetException if
 a caller-sensitive method throws IAE [v2]
In-Reply-To: <5hd5W9BolJM8MwB5RPnSXPkr046uX5e5r2JG17sT1EY=.11558298-6ab8-47f1-bc99-548ed98c7250@github.com>
References: 
 <5hd5W9BolJM8MwB5RPnSXPkr046uX5e5r2JG17sT1EY=.11558298-6ab8-47f1-bc99-548ed98c7250@github.com>
Message-ID: 

On Thu, 30 Mar 2023 01:15:33 GMT, Mandy Chung  wrote:

>> A simple fix to `Method::invoke` which wraps IAE with `InvocationTargetException` twice if it's thrown by a caller-sensitive method which has no adapter.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   the test should fail if Method::invoke doesn't throw

Looks fine to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13233#pullrequestreview-1364192193

From dholmes at openjdk.org  Thu Mar 30 01:31:18 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 30 Mar 2023 01:31:18 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity
In-Reply-To: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
Message-ID: 

On Wed, 29 Mar 2023 11:28:53 GMT, Aleksey Shipilev  wrote:

> Java API has the `Thread.sleep(millis, nanos)` method exposed to users. The documentation for that method clearly says the precision and accuracy are dependent on the underlying system behavior. However, it always rounds up `nanos` to 1ms when doing the actual sleep. This means users cannot do the micro-second precision sleeps, even when the underlying platform allows it. Sub-millisecond sleeps are useful to build interesting primitives, like the rate limiters that run with >1000 RPS.
> 
> When faced with this, some users reach for more awkward APIs like `java.util.concurrent.locks.LockSupport.parkNanos`. The use of that API for sleeps is not in line with its intent, and while it "seems to work", it might have interesting interactions with other uses of `LockSupport`. Additionally, these "sleeps" are no longer visible to monitoring tools as "normal sleeps", e.g. as `Thread.sleep` events. Therefore, it would be prudent to improve current `Thread.sleep(millis, nanos)` for sub-millisecond granularity. 
> 
> Fortunately, the underlying code is almost ready for this, at least on POSIX side. I skipped Windows paths, because its timers are still no good. Note that on both Linux and MacOS timers oversleep by about 50us. I have a few ideas how to improve the accuracy for them, which would be a topic for a separate PR.
> 
> Additional testing:
>   - [x] New regression test
>   - [x] New benchmark
>   - [x] Linux x86_64 `tier1`
>   - [x] Linux AArch64 `tier1`

src/hotspot/share/runtime/javaThread.cpp line 1981:

> 1979: }
> 1980: 
> 1981: bool JavaThread::sleep(jlong millis, jint nanos) {

You don't need the overloads at this level - the incoming call should always have millis and nanos, even if nanos is zero.

src/hotspot/share/utilities/globalDefinitions.hpp line 351:

> 349:     millis = max_secs * MILLIUNITS;
> 350:   }
> 351:   return millis_to_nanos(millis) + nanos;

This can now exceed the max_secs bound though.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13225#discussion_r1152639527
PR Review Comment: https://git.openjdk.org/jdk/pull/13225#discussion_r1152640056

From dholmes at openjdk.org  Thu Mar 30 01:26:18 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 30 Mar 2023 01:26:18 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity
In-Reply-To: <4pbTAzlahWgsX0rZFLkvHBspPsH3f5sywPAw_J910xc=.459db480-16d3-47d0-a455-5c4eec0c0639@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
 
 <4pbTAzlahWgsX0rZFLkvHBspPsH3f5sywPAw_J910xc=.459db480-16d3-47d0-a455-5c4eec0c0639@github.com>
Message-ID: 

On Wed, 29 Mar 2023 17:17:29 GMT, Aleksey Shipilev  wrote:

> Are there specific factors which would make it unreasonable to implement `sleep` in terms of `parkNanos`?

You would need to reissue any unparks received whilst sleeping.

Sleeping and parking are distinct thread states so it would be a lot of work in the Java code and in the VM to make such a change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13225#issuecomment-1489551942

From amitkumar at openjdk.org  Thu Mar 30 03:06:51 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Thu, 30 Mar 2023 03:06:51 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x [v3]
In-Reply-To: 
References: 
Message-ID: <1VOiJqfV7MR0h3qtLDOK6JjmSAiWP8cTOcXP9ZW0nTY=.79b86cdb-ad4f-4c0b-9010-43d385427a28@github.com>

> DeInflate.java test fails on s390x platform because size for out1 array which is responsible for storing the compressed data is insufficient. And being unable to write whole compressed data on array, on s390 whole data can't be recovered after compression. So this fix increase Array size (for s390).

Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:

  removes out1,out2 parameters

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12283/files
  - new: https://git.openjdk.org/jdk/pull/12283/files/5a7fa279..bce89892

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12283&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12283&range=01-02

  Stats: 12 lines in 1 file changed: 0 ins; 3 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/12283.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12283/head:pull/12283

PR: https://git.openjdk.org/jdk/pull/12283

From amitkumar at openjdk.org  Thu Mar 30 03:06:51 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Thu, 30 Mar 2023 03:06:51 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x [v2]
In-Reply-To: 
References: 
 <3z7u66KVgFfL7S7S4uxDtOA6gD-WkNU7R-zon0trIVg=.d27446ca-c11d-49cc-bb85-b162e5ac58f2@github.com>
 
Message-ID: 

On Mon, 6 Mar 2023 11:07:26 GMT, Jaikiran Pai  wrote:

>Now coming to this proposed patch, now that you are using local ByteArrayOutputStream(s) for the deflate/inflate part in this check() method, I think the out1 and out2 should no longer be needed in this method and thus the method signature can be changed to remove these params. I see that this is the only place where this method is used, so changing the method signature of check() should be OK and shouldn't impact other parts of the test.

@jaikiran I've removed these parameters, not sure this is the correct way of doing this. But please let me know if you've different idea in mind. 

Thanks for your patience

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12283#issuecomment-1489616583

From smarks at openjdk.org  Thu Mar 30 06:34:44 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 30 Mar 2023 06:34:44 GMT
Subject: RFR: 8266571: Sequenced Collections [v4]
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <-BNnKi-AQ6XTBe-GxXIn9Zq7WdROvR9mX73H_gr2rs8=.4c034fa8-781f-4739-ade8-e24f507f55be@github.com>
 
Message-ID: 

On Wed, 29 Mar 2023 13:09:52 GMT, R?mi Forax  wrote:

>> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplify handling of cached keySet, values, and entrySet views.
>
> This is taking a personal turn and I do not see the point of discussing that matter here, so please send me an email at forax at univ-mlv.fr

@forax 
>  i read your message as not too not far from the sunken cost fallacy.

No, not at all. I'm saying that after two years, the PR is only about 7,000 lines of changes. That's quite a bit smaller than several other PRs, contrary to your statement that it is "massive." It's not.

I'm not going to relitigate the design issues.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1489768106

From smarks at openjdk.org  Thu Mar 30 06:44:31 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 30 Mar 2023 06:44:31 GMT
Subject: RFR: 8266571: Sequenced Collections [v4]
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <-BNnKi-AQ6XTBe-GxXIn9Zq7WdROvR9mX73H_gr2rs8=.4c034fa8-781f-4739-ade8-e24f507f55be@github.com>
 
Message-ID: 

On Wed, 29 Mar 2023 21:18:02 GMT, Chen Liang  wrote:

>> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplify handling of cached keySet, values, and entrySet views.
>
> In the JEP:
>> A sequenced collection supports common operations at either end, and it supports processing the elements from first to last and from last to first (i.e., forward and reverse).
> 
>> The reverse-ordered view enables all the different sequenced types to process elements in both directions, using all the usual iteration mechanisms: Enhanced for loops, explicit iterator() loops, forEach(), stream(), parallelStream(), and toArray().
> 
> This implies that for the reversed view, collection operations are not only supported, but can potentially be optimized. Our design should anticipate implementations of `SequencedCollection` to provide specific reversed implementations, like what we are already doing with `addAll` in ArrayList and ArrayDeque. If a collection cannot have efficient reverse-sequenced operations, it shouldn't be retrofitted into `SequencedCollection`, just like how we don't fit Deques into Lists.
> 
> Hence, I recommend:
> 1. Declare `reversed()` and one of the (First/Last) operation sets (add|get|remove) `abstract`, and delegae the other set to default call the operation on the reversed instead. 
>    - Since we tend to work with the end of collections, I'd declare the `Last` methods to be abstract and delegate the `First` default implementations to `this.reversed().xxxLast()`
> 2. I don't think leaving `addLast()` implemented by default is a good idea, for modifiable implementations cannot discover that they missed the `addLast()` at compile time and can only discover when the implementation is actually used.
> 3. In the default `reversed()` implementation of `List` and `Deque`, add API notes to indicate to implementations opportunities to optimize the implementation, especially batch operations like `addAll` when the base implementation offers such an optimization.

@liach 

I understand that you're suggesting adding various default implementations in order to make it easier for people to bring up implementations of SequencedCollections. However, adding default implementations to SequencedCollection itself is unlikely to help. I expect that most implementations will override both addFirst and addLast. Requiring overriding of only one of them will hardly help anything, because the more difficult task is implementing the reverse-ordered view. I'd prefer to concentrate on some kind of implementation assistance for doing that. For example, there could be an "AbstractSequencedCollection" that would require overriding only a couple methods, rather like `AbstractCollection`. I'm a bit reluctant to introduce new abstract classes into the public API though. An alternative might be to have some kind of static factory method that takes something like a Collection and a reverse iterator and returns a SequencedCollection.

It's not clear to me that such support is necessary. It's pretty easy to bring up a List using AbstractList, and a List is a SequencedCollection. But if we do add something, it should be driven by use cases, and not speculation.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1489776815

From alanb at openjdk.org  Thu Mar 30 07:08:21 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 30 Mar 2023 07:08:21 GMT
Subject: RFR: 8302819: Remove JAR Index [v2]
In-Reply-To: 
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 
Message-ID: <83FoBH92lGs58VfmVV9QnYzKM0Qbiz75CgpVbR6TSTE=.d8d275fe-afba-41c3-b6e3-c89fa87d3ba8@github.com>

On Wed, 29 Mar 2023 19:55:37 GMT, Eirik Bjorsnos  wrote:

>> This PR removes the JAR index feature from the runtime:
>> 
>> - `URLClassPath` is  updated to remove the `enableJarIndex` system property and any code which would be called when this property was `true`
>> - The `JarIndex` implementation class is moved into `jdk.jartool` module.
>> - The `InvalidJarIndexError` exception class is removed because it falls out of use
>> - The test `test/jdk/sun/misc/JarIndex/metaInfFileNames/Basic.java` is removed because it depends on the JarIndex feature being present
>> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeForClassLoaderTest.java` is removed because it depends on the JarIndex feature being present
>> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeTest.java` is removed because it end up being the only caller of the  JarIndex.merge feature
>> - All `JarIndex` methods/constructors which are not used by the `jar -i` implementation are removed. 
>> - `JarIndex` is given package-private access.
>> 
>> Outstanding code work:
>> 
>> - Create tests for `JarFile` and `JarInputStream` accepting dusty INDEX jars.
>> 
>> Outstanding work:
>> 
>> - CSR for the removal
>> - Release notes for the removal
>> - Coordination of the update of the Jar File Specification
>
> Eirik Bjorsnos 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 11 additional commits since the last revision:
> 
>  - Remove blank line 93 as per suggestion by Mandy
>  - Merge branch 'master' into remove-jar-index
>  - Remove JarIndex default constructor
>  - Make JarIndex.INDEX_NAME package private
>  - Remove outdated reference to URLClassLoader using JarIndex
>  - Make JarIndex package private
>  - The JarIndex.merge method ended up being used only by the JarIndexMergeTest test. Removing this test, the JarIndex.merge methods and a number of other JarIndex methods not used by the 'jar' tool
>  - Revert the export of sun.security.action to jdk.jartool. JarIndex can use System.property instead since the 'jar' tool does not run with a SecurityManager
>  - Revert noisy whitespace changes
>  - Revert noisy whitespace changes
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/e90f7996...2b5d8a4a

This looks good. I've added the "csr" label to the PR.

For "jar -i", I think we are converging on the option to just add a warning, meaning it will generated/update the index as before, but emit a warning that JAR Index is ignored since JDK 18. It doesn't matter if we do this in this PR or a separate PR. For CSR and release note purposes it would be a bit easier if it was this PR, would that be okay?

src/java.base/share/classes/java/util/jar/JarFile.java line 212:

> 210:     /**
> 211:      * The 'JAR index' feature has been removed, but we still need to
> 212:      * process existing files which have this entry.

"but we still need ..."   Maybe better to say that that JarInputStream and the verification of signed JARs need to skip this attribute.

src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 73:

> 71: import jdk.internal.opt.CommandLine;
> 72: 
> 73: import java.time.LocalDateTime;

This can move up to the imports of the other java.* classes.

test/jdk/java/util/jar/JarFile/mrjar/TestVersionedStream.java line 29:

> 27:  * @summary basic tests for multi-release jar versioned streams
> 28:  * @library /test/lib
> 29:  * @modules jdk.jartool/sun.tools.jar

This test could be changed to use ToolProvider.findFirst("jar") and it would avoid needing to use sun.tools.jar.Main directly.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13158#pullrequestreview-1364446354
PR Review Comment: https://git.openjdk.org/jdk/pull/13158#discussion_r1152816329
PR Review Comment: https://git.openjdk.org/jdk/pull/13158#discussion_r1152817035
PR Review Comment: https://git.openjdk.org/jdk/pull/13158#discussion_r1152814946

From alanb at openjdk.org  Thu Mar 30 07:25:18 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 30 Mar 2023 07:25:18 GMT
Subject: RFR: 8304585: Method::invoke rewraps InvocationTargetException if
 a caller-sensitive method throws IAE [v2]
In-Reply-To: <5hd5W9BolJM8MwB5RPnSXPkr046uX5e5r2JG17sT1EY=.11558298-6ab8-47f1-bc99-548ed98c7250@github.com>
References: 
 <5hd5W9BolJM8MwB5RPnSXPkr046uX5e5r2JG17sT1EY=.11558298-6ab8-47f1-bc99-548ed98c7250@github.com>
Message-ID: 

On Thu, 30 Mar 2023 01:15:33 GMT, Mandy Chung  wrote:

>> A simple fix to `Method::invoke` which wraps IAE with `InvocationTargetException` twice if it's thrown by a caller-sensitive method which has no adapter.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   the test should fail if Method::invoke doesn't throw

The removal of the wrapping looks okay to me.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13233#pullrequestreview-1364480197

From sgehwolf at openjdk.org  Thu Mar 30 08:04:31 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 30 Mar 2023 08:04:31 GMT
Subject: RFR: 8304871: Use default visibility for static library builds
 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 27 Mar 2023 09:40:22 GMT, Severin Gehwolf  wrote:

>> Please review this change for symbol visibility of static library artefacts. This fixes an issue when
>> OpenJDK is being used as a base for generating native images preventing the symbols from being
>> exported and looked up from the executable. Note that symbol visibity is now controlled by a
>> linker version script downstream. This changes nothing for the regularly shipped dynamic libraries.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Explicitly set the JNI_EXPORT define for static libs

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13177#issuecomment-1489865152

From sgehwolf at openjdk.org  Thu Mar 30 08:04:33 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 30 Mar 2023 08:04:33 GMT
Subject: Integrated: 8304871: Use default visibility for static library builds
In-Reply-To: 
References: 
Message-ID: 

On Fri, 24 Mar 2023 15:31:32 GMT, Severin Gehwolf  wrote:

> Please review this change for symbol visibility of static library artefacts. This fixes an issue when
> OpenJDK is being used as a base for generating native images preventing the symbols from being
> exported and looked up from the executable. Note that symbol visibity is now controlled by a
> linker version script downstream. This changes nothing for the regularly shipped dynamic libraries.
> 
> Thoughts?

This pull request has now been integrated.

Changeset: f0dba218
Author:    Severin Gehwolf 
URL:       https://git.openjdk.org/jdk/commit/f0dba218ac00c0c577400b4d864ba79a9938aef7
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8304871: Use default visibility for static library builds

Reviewed-by: erikj, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/13177

From pminborg at openjdk.org  Thu Mar 30 09:27:44 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 30 Mar 2023 09:27:44 GMT
Subject: Integrated: 8305157: The java.util.Arrays class should be declared
 final
In-Reply-To: 
References: 
Message-ID: <7GKlcSXtDMpVJzFVJuNYulbyswAyejiVWWEscYBKsvg=.9c2b3146-2fb4-48c1-860a-6c6c58df00ab@github.com>

On Wed, 29 Mar 2023 08:13:06 GMT, Per Minborg  wrote:

> Non-instantiable utility classes should be declared `final` and have a private constructors. 
> 
> See Effective Java, Third Edition, Joshua Bloch (for example, Item 19 or Item 22).

This pull request has now been integrated.

Changeset: 9df20600
Author:    Per Minborg 
URL:       https://git.openjdk.org/jdk/commit/9df20600592427550998c6685f103737e3115a51
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8305157: The java.util.Arrays class should be declared final

Reviewed-by: alanb, rriggs, bpb

-------------

PR: https://git.openjdk.org/jdk/pull/13221

From tvaleev at openjdk.org  Thu Mar 30 09:56:40 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Thu, 30 Mar 2023 09:56:40 GMT
Subject: RFR: 8266571: Sequenced Collections [v4]
In-Reply-To: <-BNnKi-AQ6XTBe-GxXIn9Zq7WdROvR9mX73H_gr2rs8=.4c034fa8-781f-4739-ade8-e24f507f55be@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <-BNnKi-AQ6XTBe-GxXIn9Zq7WdROvR9mX73H_gr2rs8=.4c034fa8-781f-4739-ade8-e24f507f55be@github.com>
Message-ID: 

On Tue, 28 Mar 2023 02:37:22 GMT, Stuart Marks  wrote:

>> PR for Sequenced Collections implementation.
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify handling of cached keySet, values, and entrySet views.

src/java.base/share/classes/java/util/AbstractMap.java line 899:

> 897:      * @param  the view's element type
> 898:      */
> 899:     /* non-public */ static class ViewCollection implements Collection {

Should we declare it abstract to depict that this class is not intended to be instantiated directly?

src/java.base/share/classes/java/util/LinkedHashMap.java line 78:

> 76:  * on collection-views do not affect the order of iteration of the
> 77:  * backing map.
> 78:  *

I see above the list of methods that affect the encounter order in access-order mode:
> Invoking the put, putIfAbsent, get, getOrDefault, compute, computeIfAbsent, computeIfPresent, or merge methods results in an access...

Should we extend it to add new methods like putFirst and putLast? Also, it says that 'In particular, operations on collection-views do not affect the order of iteration of the backing map'. Now, we have a map-view (`reversed()`). We should specify whether operations on the reversed map change the encounter order of the original map, and if yes then how exactly they do this (moving entries to the end, like in the original map, or moving them to the beginning?)

src/java.base/share/classes/java/util/LinkedHashMap.java line 1189:

> 1187: 
> 1188:         public V putIfAbsent(K key, V value) {
> 1189:             return base.putIfAbsent(key, value);

`putIfAbsent` should also preserve insert at the beginning. The default implementation from the `Map` interface will actually work (though requires double lookup):


V v = get(key);
if (v == null) {
  v = put(key, value);
}
return v;

Or we can narrow it a little bit:

V v = base.get(key);
if (v == null) {
  v = base.putFirst(key, value);
}
return v;

src/java.base/share/classes/java/util/SequencedCollection.java line 45:

> 43:  * required to operate on elements in encounter order include the following:
> 44:  * {@link Iterable#forEach forEach}, {@link Collection#parallelStream parallelStream},
> 45:  * {@link Collection#spliterator spliterator}, {@link Collection#stream stream},

Should we require in specification that the implementations of `SequencedCollection::spliterator` must have the `ORDERED` charactersitic?

src/java.base/share/classes/java/util/SequencedCollection.java line 78:

> 76:  * @since 21
> 77:  */
> 78: public interface SequencedCollection extends Collection {

Should we narrow the specification for `Collection::add` here, saying that `add` is essentially `addLast`? Specification for deque mentions that `add` and `addLast` are equivalent. Otherwise, the implementation of `SequencedCollection::add` that adds the element to a random position will comply the spec.

Another thing is `remove(Object)`. Should we specify here that it will remove the first instance of Object inside the collection (like it's specified in the list)? Or is it allowed to return a random one?

src/java.base/share/classes/java/util/SequencedMap.java line 125:

> 123:  * @since 21
> 124:  */
> 125: public interface SequencedMap extends Map {

Again, it would be good to specify here the behavior of some old methods from `Map`. Methods `put`, `putIfAbsent`, `merge`, `compute`, and `computeIfAbsent` may add new mapping as well. Should we specify that for ordered map the mapping is added at the end of collection? Or is it at discretion of the implementation?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1153019190
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1153002016
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1153013781
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1152981740
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1152978206
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1152994927

From tvaleev at openjdk.org  Thu Mar 30 09:56:42 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Thu, 30 Mar 2023 09:56:42 GMT
Subject: RFR: 8266571: Sequenced Collections [v4]
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
Message-ID: 

On Fri, 24 Mar 2023 21:39:09 GMT, Tagir F. Valeev  wrote:

>> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplify handling of cached keySet, values, and entrySet views.
>
> src/java.base/share/classes/java/util/LinkedHashMap.java line 1197:
> 
>> 1195: 
>> 1196:         public V computeIfAbsent(K key, Function mappingFunction) {
>> 1197:             return base.computeIfAbsent(key, mappingFunction);
> 
> Again, it's somewhat worrysome that methods like `computeIfAbsent` will actually add new nodes to the end of original LinkedHashMap instead of to the beginning. Probably not very big deal but looks inconsistent...

Likely, for the first iteration it's possible to remove specializations for compute*/merge methods and use the default implementation from the `Map` interface, which will properly insert the new item to the beginning (if we properly implement reversed `put`). Later it could be optimized if necessary. What do you think?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1153015878

From tvaleev at openjdk.org  Thu Mar 30 09:59:34 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Thu, 30 Mar 2023 09:59:34 GMT
Subject: RFR: 8266571: Sequenced Collections [v4]
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <-BNnKi-AQ6XTBe-GxXIn9Zq7WdROvR9mX73H_gr2rs8=.4c034fa8-781f-4739-ade8-e24f507f55be@github.com>
 
 
Message-ID: 

On Thu, 30 Mar 2023 06:41:38 GMT, Stuart Marks  wrote:

>> In the JEP:
>>> A sequenced collection supports common operations at either end, and it supports processing the elements from first to last and from last to first (i.e., forward and reverse).
>> 
>>> The reverse-ordered view enables all the different sequenced types to process elements in both directions, using all the usual iteration mechanisms: Enhanced for loops, explicit iterator() loops, forEach(), stream(), parallelStream(), and toArray().
>> 
>> This implies that for the reversed view, collection operations are not only supported, but can potentially be optimized. Our design should anticipate implementations of `SequencedCollection` to provide specific reversed implementations, like what we are already doing with `addAll` in ArrayList and ArrayDeque. If a collection cannot have efficient reverse-sequenced operations, it shouldn't be retrofitted into `SequencedCollection`, just like how we don't fit Deques into Lists.
>> 
>> Hence, I recommend:
>> 1. Declare `reversed()` and one of the (First/Last) operation sets (add|get|remove) `abstract`, and delegae the other set to default call the operation on the reversed instead. 
>>    - Since we tend to work with the end of collections, I'd declare the `Last` methods to be abstract and delegate the `First` default implementations to `this.reversed().xxxLast()`
>> 2. I don't think leaving `addLast()` implemented by default is a good idea, for modifiable implementations cannot discover that they missed the `addLast()` at compile time and can only discover when the implementation is actually used.
>> 3. In the default `reversed()` implementation of `List` and `Deque`, add API notes to indicate to implementations opportunities to optimize the implementation, especially batch operations like `addAll` when the base implementation offers such an optimization.
>
> @liach 
> 
> I understand that you're suggesting adding various default implementations in order to make it easier for people to bring up implementations of SequencedCollections. However, adding default implementations to SequencedCollection itself is unlikely to help. I expect that most implementations will override both addFirst and addLast. Requiring overriding of only one of them will hardly help anything, because the more difficult task is implementing the reverse-ordered view. I'd prefer to concentrate on some kind of implementation assistance for doing that. For example, there could be an "AbstractSequencedCollection" that would require overriding only a couple methods, rather like `AbstractCollection`. I'm a bit reluctant to introduce new abstract classes into the public API though. An alternative might be to have some kind of static factory method that takes something like a Collection and a reverse iterator and returns a SequencedCollection.
> 
> It's not clear to me that such support is necessary. It's pretty easy to bring up a List using AbstractList, and a List is a SequencedCollection. But if we do add something, it should be driven by use cases, and not speculation.

@stuart-marks 

> Thanks for looking! I took a quick look through the comments and they seem reasonable. Right now I'm concentrating on the specification in order to get the CSR Finalized. Do you have any comments on the specifications? I'll take a look at the implementation comments afterward. Some I'll be able to address before integration, but some I might need to postpone until later.

The specification is mostly well-written, thanks! I've added a few comments on the spec and few more comments on the implementation. Please check.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1490024150

From duke at openjdk.org  Thu Mar 30 11:03:22 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 30 Mar 2023 11:03:22 GMT
Subject: RFR: 8302819: Remove JAR Index [v3]
In-Reply-To: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
Message-ID: 

> This PR removes the JAR index feature from the runtime:
> 
> - `URLClassPath` is  updated to remove the `enableJarIndex` system property and any code which would be called when this property was `true`
> - The `JarIndex` implementation class is moved into `jdk.jartool` module.
> - The `InvalidJarIndexError` exception class is removed because it falls out of use
> - The test `test/jdk/sun/misc/JarIndex/metaInfFileNames/Basic.java` is removed because it depends on the JarIndex feature being present
> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeForClassLoaderTest.java` is removed because it depends on the JarIndex feature being present
> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeTest.java` is removed because it end up being the only caller of the  JarIndex.merge feature
> - All `JarIndex` methods/constructors which are not used by the `jar -i` implementation are removed. 
> - `JarIndex` is given package-private access.
> 
> Outstanding code work:
> 
> - Create tests for `JarFile` and `JarInputStream` accepting dusty INDEX jars.
> 
> Outstanding work:
> 
> - CSR for the removal
> - Release notes for the removal
> - Coordination of the update of the Jar File Specification

Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:

  Use ToolProvider.findFirst("jar") instead of calling sun.tools.jar.Main directly

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13158/files
  - new: https://git.openjdk.org/jdk/pull/13158/files/2b5d8a4a..959af030

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13158&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13158&range=01-02

  Stats: 4 lines in 1 file changed: 1 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13158.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13158/head:pull/13158

PR: https://git.openjdk.org/jdk/pull/13158

From duke at openjdk.org  Thu Mar 30 11:17:05 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 30 Mar 2023 11:17:05 GMT
Subject: RFR: 8302819: Remove JAR Index [v4]
In-Reply-To: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
Message-ID: <0VNpuRIuvQZNjeKkVft2Ll2AoS4PNSiiNXVpTeALzHQ=.6460b10b-9cb9-4900-8569-045b7e24a9af@github.com>

> This PR removes the JAR index feature from the runtime:
> 
> - `URLClassPath` is  updated to remove the `enableJarIndex` system property and any code which would be called when this property was `true`
> - The `JarIndex` implementation class is moved into `jdk.jartool` module.
> - The `InvalidJarIndexError` exception class is removed because it falls out of use
> - The test `test/jdk/sun/misc/JarIndex/metaInfFileNames/Basic.java` is removed because it depends on the JarIndex feature being present
> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeForClassLoaderTest.java` is removed because it depends on the JarIndex feature being present
> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeTest.java` is removed because it end up being the only caller of the  JarIndex.merge feature
> - All `JarIndex` methods/constructors which are not used by the `jar -i` implementation are removed. 
> - `JarIndex` is given package-private access.
> 
> Outstanding code work:
> 
> - Create tests for `JarFile` and `JarInputStream` accepting dusty INDEX jars.
> 
> Outstanding work:
> 
> - CSR for the removal
> - Release notes for the removal
> - Coordination of the update of the Jar File Specification

Eirik Bjorsnos has updated the pull request incrementally with three additional commits since the last revision:

 - Add warning that the "jar -i" operation is deprecated and planned for removal:
   
   Warning: The -i option is deprecated, and is planned for removal in a future JDK release
 - Move the import of "java.time.LocalDateTime" into the other "import java.*" imports
 - Be more specific about which classes/code "still need to process" the META-INF/INDEX.LIST entry.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13158/files
  - new: https://git.openjdk.org/jdk/pull/13158/files/959af030..26c47b01

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13158&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13158&range=02-03

  Stats: 9 lines in 2 files changed: 5 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13158.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13158/head:pull/13158

PR: https://git.openjdk.org/jdk/pull/13158

From duke at openjdk.org  Thu Mar 30 11:17:12 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 30 Mar 2023 11:17:12 GMT
Subject: RFR: 8302819: Remove JAR Index [v2]
In-Reply-To: <83FoBH92lGs58VfmVV9QnYzKM0Qbiz75CgpVbR6TSTE=.d8d275fe-afba-41c3-b6e3-c89fa87d3ba8@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 
 <83FoBH92lGs58VfmVV9QnYzKM0Qbiz75CgpVbR6TSTE=.d8d275fe-afba-41c3-b6e3-c89fa87d3ba8@github.com>
Message-ID: 

On Thu, 30 Mar 2023 07:00:47 GMT, Alan Bateman  wrote:

>> Eirik Bjorsnos 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 11 additional commits since the last revision:
>> 
>>  - Remove blank line 93 as per suggestion by Mandy
>>  - Merge branch 'master' into remove-jar-index
>>  - Remove JarIndex default constructor
>>  - Make JarIndex.INDEX_NAME package private
>>  - Remove outdated reference to URLClassLoader using JarIndex
>>  - Make JarIndex package private
>>  - The JarIndex.merge method ended up being used only by the JarIndexMergeTest test. Removing this test, the JarIndex.merge methods and a number of other JarIndex methods not used by the 'jar' tool
>>  - Revert the export of sun.security.action to jdk.jartool. JarIndex can use System.property instead since the 'jar' tool does not run with a SecurityManager
>>  - Revert noisy whitespace changes
>>  - Revert noisy whitespace changes
>>  - ... and 1 more: https://git.openjdk.org/jdk/compare/85c16dfb...2b5d8a4a
>
> src/java.base/share/classes/java/util/jar/JarFile.java line 212:
> 
>> 210:     /**
>> 211:      * The 'JAR index' feature has been removed, but we still need to
>> 212:      * process existing files which have this entry.
> 
> "but we still need ..."   Maybe better to say that that JarInputStream and the verification of signed JARs need to skip this attribute.

I rephrased this to be more specific about which code still needs this. Agree "we" is not the best choice of subject here.

> src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 73:
> 
>> 71: import jdk.internal.opt.CommandLine;
>> 72: 
>> 73: import java.time.LocalDateTime;
> 
> This can move up to the imports of the other java.* classes.

Fixed.

> test/jdk/java/util/jar/JarFile/mrjar/TestVersionedStream.java line 29:
> 
>> 27:  * @summary basic tests for multi-release jar versioned streams
>> 28:  * @library /test/lib
>> 29:  * @modules jdk.jartool/sun.tools.jar
> 
> This test could be changed to use ToolProvider.findFirst("jar") and it would avoid needing to use sun.tools.jar.Main directly.

An improvement a bit unrelated to this PR, but it was a simple change so I have implemented it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13158#discussion_r1153102163
PR Review Comment: https://git.openjdk.org/jdk/pull/13158#discussion_r1153102298
PR Review Comment: https://git.openjdk.org/jdk/pull/13158#discussion_r1153101442

From duke at openjdk.org  Thu Mar 30 11:19:20 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 30 Mar 2023 11:19:20 GMT
Subject: RFR: 8302819: Remove JAR Index [v2]
In-Reply-To: <83FoBH92lGs58VfmVV9QnYzKM0Qbiz75CgpVbR6TSTE=.d8d275fe-afba-41c3-b6e3-c89fa87d3ba8@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 
 <83FoBH92lGs58VfmVV9QnYzKM0Qbiz75CgpVbR6TSTE=.d8d275fe-afba-41c3-b6e3-c89fa87d3ba8@github.com>
Message-ID: 

On Thu, 30 Mar 2023 07:05:37 GMT, Alan Bateman  wrote:

> For CSR and release note purposes it would be a bit easier if it was this PR, would that be okay?

We seem to have wiggled a bit on this issue, but I'm ok with including it.

I have implemented the -i warning using the existing warnings strings already in place in `jar`. This means the following warning will be output:


% build/macosx-x86_64-server-release/images/jdk/bin/jar --generate-index file.jar
Warning: The -i option is deprecated, and is planned for removal in a future JDK release


Which may be overridden by using `-XDsuppress-tool-removal-message`:


% build/macosx-x86_64-server-release/images/jdk/bin/jar --generate-index file.jar -XDsuppress-tool-removal-message



I'm not sure we are planning to remove it though, so perhaps the current message is somewhat misleading? On the other hand, this message will allow us to remove it in the future, which is perhaps good?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1490123577

From pminborg at openjdk.org  Thu Mar 30 11:28:25 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 30 Mar 2023 11:28:25 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v16]
In-Reply-To: 
References: 
Message-ID: 

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

Per Minborg has updated the pull request incrementally with two additional commits since the last revision:

 - Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java
   
   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
 - Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java
   
   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13079/files
  - new: https://git.openjdk.org/jdk/pull/13079/files/c787a282..928ad35e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=14-15

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13079.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13079/head:pull/13079

PR: https://git.openjdk.org/jdk/pull/13079

From liach at openjdk.org  Thu Mar 30 11:36:34 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 30 Mar 2023 11:36:34 GMT
Subject: RFR: 8266571: Sequenced Collections [v4]
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <-BNnKi-AQ6XTBe-GxXIn9Zq7WdROvR9mX73H_gr2rs8=.4c034fa8-781f-4739-ade8-e24f507f55be@github.com>
 
Message-ID: 

On Wed, 29 Mar 2023 21:18:02 GMT, Chen Liang  wrote:

>> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplify handling of cached keySet, values, and entrySet views.
>
> In the JEP:
>> A sequenced collection supports common operations at either end, and it supports processing the elements from first to last and from last to first (i.e., forward and reverse).
> 
>> The reverse-ordered view enables all the different sequenced types to process elements in both directions, using all the usual iteration mechanisms: Enhanced for loops, explicit iterator() loops, forEach(), stream(), parallelStream(), and toArray().
> 
> This implies that for the reversed view, collection operations are not only supported, but can potentially be optimized. Our design should anticipate implementations of `SequencedCollection` to provide specific reversed implementations, like what we are already doing with `addAll` in ArrayList and ArrayDeque. If a collection cannot have efficient reverse-sequenced operations, it shouldn't be retrofitted into `SequencedCollection`, just like how we don't fit Deques into Lists.
> 
> Hence, I recommend:
> 1. Declare `reversed()` and one of the (First/Last) operation sets (add|get|remove) `abstract`, and delegae the other set to default call the operation on the reversed instead. 
>    - Since we tend to work with the end of collections, I'd declare the `Last` methods to be abstract and delegate the `First` default implementations to `this.reversed().xxxLast()`
> 2. I don't think leaving `addLast()` implemented by default is a good idea, for modifiable implementations cannot discover that they missed the `addLast()` at compile time and can only discover when the implementation is actually used.
> 3. In the default `reversed()` implementation of `List` and `Deque`, add API notes to indicate to implementations opportunities to optimize the implementation, especially batch operations like `addAll` when the base implementation offers such an optimization.

> @liach
> 
> I understand that you're suggesting adding various default implementations in order to make it easier for people to bring up implementations of SequencedCollections. However, adding default implementations to SequencedCollection itself is unlikely to help. I expect that most implementations will override both addFirst and addLast. Requiring overriding of only one of them will hardly help anything, because the more difficult task is implementing the reverse-ordered view. I'd prefer to concentrate on some kind of implementation assistance for doing that. For example, there could be an "AbstractSequencedCollection" that would require overriding only a couple methods, rather like `AbstractCollection`. I'm a bit reluctant to introduce new abstract classes into the public API though. An alternative might be to have some kind of static factory method that takes something like a Collection and a reverse iterator and returns a SequencedCollection.
> 
> It's not clear to me that such support is necessary. It's pretty easy to bring up a List using AbstractList, and a List is a SequencedCollection. But if we do add something, it should be driven by use cases, and not speculation.

Then shouldn't we leave all methods in SewuencedCollection abstract as users almost always override them?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1490144021

From duke at openjdk.org  Thu Mar 30 13:10:52 2023
From: duke at openjdk.org (duke)
Date: Thu, 30 Mar 2023 13:10:52 GMT
Subject: Withdrawn: 8301569: list mode of jmod and jimage cannot be used
 normally in turkish locale
In-Reply-To: 
References: 
Message-ID: <4PEShyTVrQfbe-T3Ax6GI-q0AJMJe2qFNiqyxXRrbuc=.04cbcac2-c526-4f07-8e13-dbed426bb722@github.com>

On Sun, 29 Jan 2023 15:37:28 GMT, Glavo  wrote:

> When the default Locale is `tr`, the jmod and jimage commands have the following problems:
> 
> * The jmod command does not correctly recognize the `list` mode typed in lowercase;
> * The jimage command cannot obtain the help information of the `list` mode.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/12281

From alanb at openjdk.org  Thu Mar 30 13:43:29 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 30 Mar 2023 13:43:29 GMT
Subject: RFR: 8302819: Remove JAR Index [v2]
In-Reply-To: 
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 
 <83FoBH92lGs58VfmVV9QnYzKM0Qbiz75CgpVbR6TSTE=.d8d275fe-afba-41c3-b6e3-c89fa87d3ba8@github.com>
 
Message-ID: 

On Thu, 30 Mar 2023 11:16:14 GMT, Eirik Bjorsnos  wrote:

> We seem to have wiggled a bit on this issue, but I'm ok with including it.

I think we've converged on `jar -i` work as before but print a warning. For the purposes of the CSR and the release note then I think it would be better to have the complete story in one issue rather than some of the story in one issue the two issues needing to cross reference each other. So thanks for going with that.

> 
> I have implemented the -i warning using the existing warnings strings already in place in `jar`. This means the following warning will be output:
> 
> ```
> % build/macosx-x86_64-server-release/images/jdk/bin/jar --generate-index file.jar
> Warning: The -i option is deprecated, and is planned for removal in a future JDK release
> ```

I think the warning should also communicate that the JAR index is also ignored, maybe something like this:


The JAR index (META-INF/INDEX.LIST) is ignored at run-time since JDK 18.
The --generate-index/-i option is deprecated - it may be ignored or removed in a future release.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1490325051

From sspitsyn at openjdk.org  Thu Mar 30 14:09:04 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 30 Mar 2023 14:09:04 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v4]
In-Reply-To: 
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 
Message-ID: 

On Wed, 29 Mar 2023 08:00:36 GMT, Alan Bateman  wrote:

>> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The APIs that were preview APIs in Java 19/20 are changed to permanent and their `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The JNI and JVMTI versions are bumped as this is the first change in 21 to need the new version number. A lot of tests are updated to drop `@enablePreview` and --enable-preview.
>> 
>> There is one API change from Java 19/20, the preview API Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an update to the JVMTI GetThreadInfo implementation to read the TCCL consistently.
>> 
>> In addition, there are a small number of implementation changes to sync up from the loom fibers branch:
>> 
>> - A number of stack frames are `@Hidden` to reduce noise in the stack traces. This exposed a few issues with the stack walker code. More specifically, the cases where  end of a continuation falls precisely at the end of the batch, or where the remaining frames are hidden, weren't handled correctly.
>> - The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in Thread rather than in two classes.
>> - A few robustness improvements for OOME and SOE. There is more to do here, for future PRs.
>> - New system property to print a stack trace when a virtual thread sets its own value of a TL.
>> - ThreadPerTaskExecutor is changed to use FutureTask.
>> 
>> Testing: tier1-6.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix ThreadSleepEvent again

Just wanted to check if we want to bump `@since` version of `OpaqueFrameException` from 19 to 21.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13203#issuecomment-1490367599

From duke at openjdk.org  Thu Mar 30 14:21:29 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 30 Mar 2023 14:21:29 GMT
Subject: RFR: 8302819: Remove JAR Index [v5]
In-Reply-To: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
Message-ID: <2WlS9lx99k4xv1Mr4X-QFYzoiSWV2oMF6uk1pkuWjxs=.929d5c45-71b1-436b-ad52-e879afd12896@github.com>

> This PR removes the JAR index feature from the runtime:
> 
> - `URLClassPath` is  updated to remove the `enableJarIndex` system property and any code which would be called when this property was `true`
> - The `JarIndex` implementation class is moved into `jdk.jartool` module.
> - The `InvalidJarIndexError` exception class is removed because it falls out of use
> - The test `test/jdk/sun/misc/JarIndex/metaInfFileNames/Basic.java` is removed because it depends on the JarIndex feature being present
> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeForClassLoaderTest.java` is removed because it depends on the JarIndex feature being present
> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeTest.java` is removed because it end up being the only caller of the  JarIndex.merge feature
> - All `JarIndex` methods/constructors which are not used by the `jar -i` implementation are removed. 
> - `JarIndex` is given package-private access.
> 
> Outstanding code work:
> 
> - Create tests for `JarFile` and `JarInputStream` accepting dusty INDEX jars.
> 
> Outstanding work:
> 
> - CSR for the removal
> - Release notes for the removal
> - Coordination of the update of the Jar File Specification

Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:

  Include a warning saying that 'The JAR index (META-INF/INDEX.LIST) is ignored at run-time since JDK 18'

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13158/files
  - new: https://git.openjdk.org/jdk/pull/13158/files/26c47b01..79b19e94

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13158&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13158&range=03-04

  Stats: 6 lines in 2 files changed: 3 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/13158.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13158/head:pull/13158

PR: https://git.openjdk.org/jdk/pull/13158

From duke at openjdk.org  Thu Mar 30 14:22:38 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 30 Mar 2023 14:22:38 GMT
Subject: RFR: 8302819: Remove JAR Index [v2]
In-Reply-To: 
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 
 <83FoBH92lGs58VfmVV9QnYzKM0Qbiz75CgpVbR6TSTE=.d8d275fe-afba-41c3-b6e3-c89fa87d3ba8@github.com>
 
 
Message-ID: 

On Thu, 30 Mar 2023 13:40:09 GMT, Alan Bateman  wrote:

> I think the warning should also communicate that the JAR index is also ignored, maybe something like this:

I added the following property to `jar.properties`:


warn.index.is.ignored=\
        The JAR index (META-INF/INDEX.LIST) is ignored at run-time since JDK 18


Then I chose to update the existing property `warn.flag.is.deprecated` from the following:


warn.flag.is.deprecated=\
         Warning: The {0} option is deprecated, and is planned for removal in a future JDK release\n


to the following:


warn.flag.is.deprecated=\
        Warning: The {0} option is deprecated, and may be ignored or removed in a future release\n


This gives the following warning on use:


% build/macosx-x86_64-server-release/images/jdk/bin/jar -i hello.zip
The JAR index (META-INF/INDEX.LIST) is ignored at run-time since JDK 18
Warning: The --generate-index/-i option is deprecated, and may be ignored or removed in a future release

Is this repurposing of `warn.flag.is.deprecated` considered ok?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1490393173

From qamai at openjdk.org  Thu Mar 30 14:30:17 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 30 Mar 2023 14:30:17 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v5]
In-Reply-To: 
References: 
Message-ID: 

> Hi,
> 
> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, VectorShuffle is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
> 
> 1. Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
> 2. Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
> 3. Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
> 4. Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
> 
> Upon these changes, a `rearrange` can emit more efficient code:
> 
>     var species = IntVector.SPECIES_128;
>     var v1 = IntVector.fromArray(species, SRC1, 0);
>     var v2 = IntVector.fromArray(species, SRC2, 0);
>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
> 
>     Before:
>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>     vmovdqu 0x10(%r10),%xmm2
>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>     vmovdqu 0x10(%r10),%xmm1
>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>     vmovdqu 0x10(%r10),%xmm0
>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byte_mask
>                                                             ;   {external_word}
>     vpackusdw %xmm0,%xmm0,%xmm0
>     vpackuswb %xmm0,%xmm0,%xmm0
>     vpmovsxbd %xmm0,%xmm3
>     vpcmpgtd %xmm3,%xmm1,%xmm3
>     vtestps %xmm3,%xmm3
>     jne    0x00007fc2acb4e0d8
>     vpmovzxbd %xmm0,%xmm0
>     vpermd %ymm2,%ymm0,%ymm0
>     movabs $0x751588f98,%r10            ;   {oop([I{0x0000000751588f98})}
>     vmovdqu %xmm0,0x10(%r10)
> 
>     After:
>     movabs $0x751589c78,%r10            ;   {oop([I{0x0000000751589c78})}
>     vmovdqu 0x10(%r10),%xmm1
>     movabs $0x75158ac88,%r10            ;   {oop([I{0x000000075158ac88})}
>     vmovdqu 0x10(%r10),%xmm2
>     vpxor  %xmm0,%xmm0,%xmm0
>     vpcmpgtd %xmm2,%xmm0,%xmm3
>     vtestps %xmm3,%xmm3
>     jne    0x00007fa818b27cb1
>     vpermd %ymm1,%ymm2,%ymm0
>     movabs $0x751588c68,%r10            ;   {oop([I{0x0000000751588c68})}
>     vmovdqu %xmm0,0x10(%r10)
>     
> Please take a look and leave reviews. Thanks a lot.

Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:

 - move implementations up
 - Merge branch 'master' into shufflerefactor
 - Merge branch 'master' into shufflerefactor
 - reviews
 - missing casts
 - clean up
 - fix Matcher::vector_needs_load_shuffle
 - fix internal types, clean up
 - optimise laneIsValid
 - Merge branch 'master' into shufflerefactor
 - ... and 4 more: https://git.openjdk.org/jdk/compare/d063b896...a4835c00

-------------

Changes: https://git.openjdk.org/jdk/pull/13093/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13093&range=04
  Stats: 3683 lines in 64 files changed: 1610 ins; 1169 del; 904 mod
  Patch: https://git.openjdk.org/jdk/pull/13093.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13093/head:pull/13093

PR: https://git.openjdk.org/jdk/pull/13093

From qamai at openjdk.org  Thu Mar 30 14:34:34 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 30 Mar 2023 14:34:34 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v5]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 23 Mar 2023 07:13:55 GMT, Xiaohong Gong  wrote:

>> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
>> 
>>  - move implementations up
>>  - Merge branch 'master' into shufflerefactor
>>  - Merge branch 'master' into shufflerefactor
>>  - reviews
>>  - missing casts
>>  - clean up
>>  - fix Matcher::vector_needs_load_shuffle
>>  - fix internal types, clean up
>>  - optimise laneIsValid
>>  - Merge branch 'master' into shufflerefactor
>>  - ... and 4 more: https://git.openjdk.org/jdk/compare/d063b896...a4835c00
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte128Vector.java line 868:
> 
>> 866:             return (Byte128Vector) Byte128Vector.VSPECIES.dummyVector()
>> 867:                     .vectorFactory(s.indices());
>> 868:         }
> 
> Move the implementation details to the super class?

I have moved `toBitsVectorTemplate` to `AbstractShuffle`, also `toShuffle` has been refactored to be more versatile.

> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteMaxVector.java line 862:
> 
>> 860:             v.convertShape(VectorOperators.B2I, species, 3)
>> 861:                     .reinterpretAsInts()
>> 862:                     .intoArray(a, offset + species.length() * 3);
> 
> Can we add a method like `intoIntArray()` in `ByteVector` and move these common code there? The same to other vector types.

I don't think this and the below suggestion achieve much, reducing the generated code at the expense of moving the usage away from the definition does not seem worth it to me.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1153353267
PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1153354836

From alanb at openjdk.org  Thu Mar 30 14:34:22 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 30 Mar 2023 14:34:22 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v4]
In-Reply-To: 
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 
 
Message-ID: 

On Thu, 30 Mar 2023 14:05:36 GMT, Serguei Spitsyn  wrote:

> Just wanted to check if we want to bump `@since` version of `OpaqueFrameException` from 19 to 21.

OpaqueFrameException was added as a permanent API in JDK 19 so it doesn't change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13203#issuecomment-1490410758

From qamai at openjdk.org  Thu Mar 30 14:44:36 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 30 Mar 2023 14:44:36 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v5]
In-Reply-To: 
References: 
 <4Op0Z8whnyDXDC6zGyMbx4ugcZp5TEoAqW_myB5flxM=.1c7b59ba-efb2-4f68-90d7-2d6e33e39572@github.com>
 
 
 
Message-ID: 

On Thu, 23 Mar 2023 02:23:20 GMT, Xiaohong Gong  wrote:

>> I think not emitting `VectorLoadShuffleNode` is more common so it is better to emit them only when needed, as it will simplify the graph and may allow better inspections of the indices in the future. Additionally, a do-nothing node does not alias with its input and therefore kills the input, which leads to an additional spill if they both need to live.
>
> Yeah, I agree that saving a node have some benefits like what you said. My concern is there are more and more methods added into `Matcher::` and each platform has to do the different implementation. There is not too much meaning for those platforms that do not implement Vector API like` arm/ppc/...` for me. This makes code not so easy to maintain.

I agree, I am thinking of (ab)using template to have a common query function like this

    template 
    T vectorQuery(U... args) {
        return T();
    }

then each platform can have a specialisation that looks like this:

    template <>
    bool vectorQuery(BasicType bt, int vlen) {
    }

Unimplemented platform will return `false` for this, what do you think?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1153370540

From sspitsyn at openjdk.org  Thu Mar 30 15:32:16 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 30 Mar 2023 15:32:16 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v4]
In-Reply-To: 
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 
Message-ID: <60eMtJqr0OixK0Yv1WCgN-dvX8nkDVZ0suA6GfwN8tQ=.02972477-1bf0-41a6-a243-bea51d6c7413@github.com>

On Wed, 29 Mar 2023 08:00:36 GMT, Alan Bateman  wrote:

>> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The APIs that were preview APIs in Java 19/20 are changed to permanent and their `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The JNI and JVMTI versions are bumped as this is the first change in 21 to need the new version number. A lot of tests are updated to drop `@enablePreview` and --enable-preview.
>> 
>> There is one API change from Java 19/20, the preview API Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an update to the JVMTI GetThreadInfo implementation to read the TCCL consistently.
>> 
>> In addition, there are a small number of implementation changes to sync up from the loom fibers branch:
>> 
>> - A number of stack frames are `@Hidden` to reduce noise in the stack traces. This exposed a few issues with the stack walker code. More specifically, the cases where  end of a continuation falls precisely at the end of the batch, or where the remaining frames are hidden, weren't handled correctly.
>> - The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in Thread rather than in two classes.
>> - A few robustness improvements for OOME and SOE. There is more to do here, for future PRs.
>> - New system property to print a stack trace when a virtual thread sets its own value of a TL.
>> - ThreadPerTaskExecutor is changed to use FutureTask.
>> 
>> Testing: tier1-6.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix ThreadSleepEvent again

This becomes obsolete:
`src/hotspot/share/prims/jvmtiTagMap.cpp:  // disabled if vritual threads are enabled with --enable-preview`

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13203#issuecomment-1490507154

From sspitsyn at openjdk.org  Thu Mar 30 15:45:04 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 30 Mar 2023 15:45:04 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v4]
In-Reply-To: 
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 
Message-ID: 

On Wed, 29 Mar 2023 08:00:36 GMT, Alan Bateman  wrote:

>> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The APIs that were preview APIs in Java 19/20 are changed to permanent and their `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The JNI and JVMTI versions are bumped as this is the first change in 21 to need the new version number. A lot of tests are updated to drop `@enablePreview` and --enable-preview.
>> 
>> There is one API change from Java 19/20, the preview API Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an update to the JVMTI GetThreadInfo implementation to read the TCCL consistently.
>> 
>> In addition, there are a small number of implementation changes to sync up from the loom fibers branch:
>> 
>> - A number of stack frames are `@Hidden` to reduce noise in the stack traces. This exposed a few issues with the stack walker code. More specifically, the cases where  end of a continuation falls precisely at the end of the batch, or where the remaining frames are hidden, weren't handled correctly.
>> - The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in Thread rather than in two classes.
>> - A few robustness improvements for OOME and SOE. There is more to do here, for future PRs.
>> - New system property to print a stack trace when a virtual thread sets its own value of a TL.
>> - ThreadPerTaskExecutor is changed to use FutureTask.
>> 
>> Testing: tier1-6.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix ThreadSleepEvent again

Marked as reviewed by sspitsyn (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13203#pullrequestreview-1365421647

From mchung at openjdk.org  Thu Mar 30 16:11:21 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 30 Mar 2023 16:11:21 GMT
Subject: Integrated: 8304585: Method::invoke rewraps InvocationTargetException
 if a caller-sensitive method throws IAE
In-Reply-To: 
References: 
Message-ID: 

On Wed, 29 Mar 2023 21:26:24 GMT, Mandy Chung  wrote:

> A simple fix to `Method::invoke` which wraps IAE with `InvocationTargetException` twice if it's thrown by a caller-sensitive method which has no adapter.

This pull request has now been integrated.

Changeset: 1d7bb1ff
Author:    Mandy Chung 
URL:       https://git.openjdk.org/jdk/commit/1d7bb1ffa0b80d2ef1cd991aa33f13c9b7c47dcc
Stats:     90 lines in 2 files changed: 84 ins; 4 del; 2 mod

8304585: Method::invoke rewraps InvocationTargetException if a caller-sensitive method throws IAE

Reviewed-by: darcy, jpai, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/13233

From mchung at openjdk.org  Thu Mar 30 17:13:19 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 30 Mar 2023 17:13:19 GMT
Subject: RFR: 8302819: Remove JAR Index [v2]
In-Reply-To: 
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 
 <83FoBH92lGs58VfmVV9QnYzKM0Qbiz75CgpVbR6TSTE=.d8d275fe-afba-41c3-b6e3-c89fa87d3ba8@github.com>
 
 
 
Message-ID: 

On Thu, 30 Mar 2023 14:19:55 GMT, Eirik Bjorsnos  wrote:

> Is this repurposing of warn.flag.is.deprecated considered ok?

yes, that's not used.   It was a leftover from JDK-8204981 & JDK-8234596.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1490647633

From jjg at openjdk.org  Thu Mar 30 17:31:12 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 30 Mar 2023 17:31:12 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1)
Message-ID: 

Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.

This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.

While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.

It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]

[here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
[disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115

-------------

Commit messages:
 - JDK-8305206: Add @spec tags in java.base/java.* (part 1)

Changes: https://git.openjdk.org/jdk/pull/13248/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13248&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305206
  Stats: 281 lines in 60 files changed: 267 ins; 14 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13248.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13248/head:pull/13248

PR: https://git.openjdk.org/jdk/pull/13248

From duke at openjdk.org  Thu Mar 30 17:39:18 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 30 Mar 2023 17:39:18 GMT
Subject: RFR: 8302819: Remove JAR Index [v2]
In-Reply-To: 
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 
 <83FoBH92lGs58VfmVV9QnYzKM0Qbiz75CgpVbR6TSTE=.d8d275fe-afba-41c3-b6e3-c89fa87d3ba8@github.com>
 
 
 
 
Message-ID: 

On Thu, 30 Mar 2023 17:10:20 GMT, Mandy Chung  wrote:

> yes, that's not used. It was a leftover from JDK-8204981 & JDK-8234596.

Thanks a lot for this clarificaton, Mandy.

https://bugs.openjdk.org/browse/JDK-8204981
https://bugs.openjdk.org/browse/JDK-8234596

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1490678668

From jvernee at openjdk.org  Thu Mar 30 17:59:23 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 30 Mar 2023 17:59:23 GMT
Subject: RFR: 8301703: java.base jdk.internal.foreign.abi.BindingSpecializer
 uses ASM to generate classes
Message-ID: 

Rewrite BindingSpecializer to use the new class file API.

Note: There is a big try/catch/finally block generated in the `specialize` method that currently uses labels. I looked at replacing this with a call to `CodeBuilder::trying` but it would require threading the nested code builders through all the `emit*` methods, which currently access the 'global' CodeBuilder instance attached to the BindingSpecializer instance. Since there didn't really seem to be a big benefit to this, I've kept that try/catch/finally block as is, using labels.

The current implementation could also use `CheckClassAdapter` to do additional verification on the generated bytecode (ahead of the VM's verifier). I'm not sure if the new API has a replacement for that?

-------------

Depends on: https://git.openjdk.org/jdk/pull/13079

Commit messages:
 - use ifThen to release scopes
 - use TypeKind.from
 - Translate BindingSpecializer to new classfile API

Changes: https://git.openjdk.org/jdk/pull/13247/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13247&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301703
  Stats: 411 lines in 1 file changed: 22 ins; 154 del; 235 mod
  Patch: https://git.openjdk.org/jdk/pull/13247.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13247/head:pull/13247

PR: https://git.openjdk.org/jdk/pull/13247

From sspitsyn at openjdk.org  Thu Mar 30 18:08:18 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 30 Mar 2023 18:08:18 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v4]
In-Reply-To: 
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 
Message-ID: 

On Wed, 29 Mar 2023 08:00:36 GMT, Alan Bateman  wrote:

>> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The APIs that were preview APIs in Java 19/20 are changed to permanent and their `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The JNI and JVMTI versions are bumped as this is the first change in 21 to need the new version number. A lot of tests are updated to drop `@enablePreview` and --enable-preview.
>> 
>> There is one API change from Java 19/20, the preview API Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an update to the JVMTI GetThreadInfo implementation to read the TCCL consistently.
>> 
>> In addition, there are a small number of implementation changes to sync up from the loom fibers branch:
>> 
>> - A number of stack frames are `@Hidden` to reduce noise in the stack traces. This exposed a few issues with the stack walker code. More specifically, the cases where  end of a continuation falls precisely at the end of the batch, or where the remaining frames are hidden, weren't handled correctly.
>> - The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in Thread rather than in two classes.
>> - A few robustness improvements for OOME and SOE. There is more to do here, for future PRs.
>> - New system property to print a stack trace when a virtual thread sets its own value of a TL.
>> - ThreadPerTaskExecutor is changed to use FutureTask.
>> 
>> Testing: tier1-6.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix ThreadSleepEvent again

I looked at Serviceability changes and related tests. They are good.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13203#issuecomment-1490713160

From mchung at openjdk.org  Thu Mar 30 18:46:25 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 30 Mar 2023 18:46:25 GMT
Subject: RFR: 8304846: Provide a shared utility to dump generated classes
 defined via Lookup API [v5]
In-Reply-To: 
References: 
Message-ID: 

> This implements a shared utility to dump generated classes defined as normal/hidden classes via `Lookup` API.   This replaces the implementation in `LambdaMetaFactory` and method handle implementation that dumps the hidden class bytes on disk for debugging.   
> 
> For classes defined via `Lookup::defineClass`, `Lookup::defineHiddenClass` and `Lookup::defineHiddenClassWithClassData`, by default they will be dumped to the path specified in `-Djava.lang.invoke.Lookup.dumpClasses=` 
> 
> The hidden classes generated for lambdas, `LambdaForms` and method handle implementation use non-default dumper so that they can be controlled via a separate system property and path as in the current implementation.
> 
> To dump lambda proxy classes, set this system property:
>    -Djdk.internal.lambda.dumpProxyClasses=
> 
> To dump LambdaForms and method handle implementation, set this system property:
>    -Djava.lang.invoke.MethodHandle.DUMP_CLASS_FILES=true
>    
> P.S. `ProxyClassesDumper` is renamed to `ClassFileDumper` but for some reason, it's not shown as rename.

Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:

  set -D or -D=true will enable dumping

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13182/files
  - new: https://git.openjdk.org/jdk/pull/13182/files/2c305fae..351574a8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13182&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13182&range=03-04

  Stats: 9 lines in 3 files changed: 5 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/13182.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13182/head:pull/13182

PR: https://git.openjdk.org/jdk/pull/13182

From liach at openjdk.org  Thu Mar 30 18:50:17 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 30 Mar 2023 18:50:17 GMT
Subject: RFR: 8301703: java.base
 jdk.internal.foreign.abi.BindingSpecializer uses ASM to generate classes
In-Reply-To: 
References: 
Message-ID: 

On Thu, 30 Mar 2023 17:11:44 GMT, Jorn Vernee  wrote:

> Rewrite BindingSpecializer to use the new class file API.
> 
> Note: There is a big try/catch/finally block generated in the `specialize` method that currently uses labels. I looked at replacing this with a call to `CodeBuilder::trying` but it would require threading the nested code builders through all the `emit*` methods, which currently access the 'global' CodeBuilder instance attached to the BindingSpecializer instance. Since there didn't really seem to be a big benefit to this, I've kept that try/catch/finally block as is, using labels.
> 
> The current implementation could also use `CheckClassAdapter` to do additional verification on the generated bytecode (ahead of the VM's verifier). I'm not sure if the new API has a replacement for that?

src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 77:

> 75:     private static final int CLASSFILE_VERSION = ClassFileFormatVersion.latest().major();
> 76: 
> 77:     private static final MethodTypeDesc MTD_VOID = MethodTypeDesc.of(CD_void);

Now that there's a `MTD_void` in ConstantDescs, can switch to use that.

src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 216:

> 214:         if (PERFORM_VERIFICATION) {
> 215:             boolean printResults = false; // only print in case of exception
> 216:             CheckClassAdapter.verify(new ClassReader(bytes), null, printResults, new PrintWriter(System.err));

Classfile API provides verification functionality as well, as seen here:
https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/test/jdk/jdk/classfile/ClassHierarchyInfoTest.java#L105

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13247#discussion_r1153653198
PR Review Comment: https://git.openjdk.org/jdk/pull/13247#discussion_r1153654815

From alanb at openjdk.org  Thu Mar 30 19:51:22 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 30 Mar 2023 19:51:22 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1)
In-Reply-To: 
References: 
Message-ID: 

On Thu, 30 Mar 2023 17:24:11 GMT, Jonathan Gibbons  wrote:

> Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.
> 
> This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.
> 
> While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.
> 
> It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]
> 
> [here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
> [disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115

I skimmed through the changes and it looks quite good, much more workable than PR 11073.

Do you have a proposed ordering with other tags? I expected it would go with @see but I see several where @spec is before @author, and @see after @author. I know it doesn't really matter.

src/java.base/share/classes/java/lang/Thread.java line 1960:

> 1958:      *             thread.
> 1959:      *
> 1960:      * @spec jni/index.html Java Native Interface Specification

The link to the JNI spec in this method is from implNote so I'm wondering if the spec link is needed here.

src/java.base/share/classes/java/nio/file/Files.java line 1724:

> 1722:      *
> 1723:      * @spec https://www.rfc-editor.org/info/rfc2045
> 1724:      *      RFC 2045: RFC 2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies

Maybe this one can be put on two lines to avoid the wrapping when looking at is side-by-side.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13248#pullrequestreview-1365814487
PR Review Comment: https://git.openjdk.org/jdk/pull/13248#discussion_r1153715180
PR Review Comment: https://git.openjdk.org/jdk/pull/13248#discussion_r1153716361

From alanb at openjdk.org  Thu Mar 30 19:53:19 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 30 Mar 2023 19:53:19 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v4]
In-Reply-To: <60eMtJqr0OixK0Yv1WCgN-dvX8nkDVZ0suA6GfwN8tQ=.02972477-1bf0-41a6-a243-bea51d6c7413@github.com>
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 
 <60eMtJqr0OixK0Yv1WCgN-dvX8nkDVZ0suA6GfwN8tQ=.02972477-1bf0-41a6-a243-bea51d6c7413@github.com>
Message-ID: 

On Thu, 30 Mar 2023 15:29:43 GMT, Serguei Spitsyn  wrote:

> This becomes obsolete:
> `src/hotspot/share/prims/jvmtiTagMap.cpp: // disabled if vritual threads are enabled with --enable-preview`

A left-over from JDK-8285739, thanks, we can remove that comment.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13203#issuecomment-1490855154

From jvernee at openjdk.org  Thu Mar 30 19:55:15 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 30 Mar 2023 19:55:15 GMT
Subject: RFR: 8301703: java.base
 jdk.internal.foreign.abi.BindingSpecializer uses ASM to generate classes [v2]
In-Reply-To: 
References: 
Message-ID: <6Q49gLo9_qfeWbFCMhWo5PLq4KLyACea2QVw2sGh2vk=.3a63e22a-4243-4003-8cb1-58705a0695f3@github.com>

> Rewrite BindingSpecializer to use the new class file API.
> 
> Note: There is a big try/catch/finally block generated in the `specialize` method that currently uses labels. I looked at replacing this with a call to `CodeBuilder::trying` but it would require threading the nested code builders through all the `emit*` methods, which currently access the 'global' CodeBuilder instance attached to the BindingSpecializer instance. Since there didn't really seem to be a big benefit to this, I've kept that try/catch/finally block as is, using labels.
> 
> The current implementation could also use `CheckClassAdapter` to do additional verification on the generated bytecode (ahead of the VM's verifier). I'm not sure if the new API has a replacement for that?

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  use existing MTD_void constant

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13247/files
  - new: https://git.openjdk.org/jdk/pull/13247/files/598f288d..95c8d873

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13247&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13247&range=00-01

  Stats: 5 lines in 1 file changed: 0 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/13247.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13247/head:pull/13247

PR: https://git.openjdk.org/jdk/pull/13247

From jvernee at openjdk.org  Thu Mar 30 19:55:17 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 30 Mar 2023 19:55:17 GMT
Subject: RFR: 8301703: java.base
 jdk.internal.foreign.abi.BindingSpecializer uses ASM to generate classes [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 30 Mar 2023 18:43:42 GMT, Chen Liang  wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use existing MTD_void constant
>
> src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 216:
> 
>> 214:         if (PERFORM_VERIFICATION) {
>> 215:             boolean printResults = false; // only print in case of exception
>> 216:             CheckClassAdapter.verify(new ClassReader(bytes), null, printResults, new PrintWriter(System.err));
> 
> Classfile API provides verification functionality as well, as seen here:
> https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/test/jdk/jdk/classfile/ClassHierarchyInfoTest.java#L105

Does this provide additional verification over what is already done just by generating the class?

For instance, IIRC the ASM verifier could catch e.g. stack underflow, but that seems to be caught already by the new implementation without running the verifier.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13247#discussion_r1153722648

From alanb at openjdk.org  Thu Mar 30 19:58:24 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 30 Mar 2023 19:58:24 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v4]
In-Reply-To: 
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 
 
Message-ID: <1VSMgL-O6sBz4fZGONbHPF_lHILBy8R4bsRrJ0Rgtdg=.d0a651d9-03d1-4e71-9d4f-8778c26f86b1@github.com>

On Wed, 29 Mar 2023 21:43:38 GMT, Paul Sandoz  wrote:

>> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix ThreadSleepEvent again
>
> src/java.base/share/classes/java/lang/Thread.java line 1546:
> 
>> 1544:             // bind thread to container
>> 1545:             if (this.container != null)
>> 1546:                 throw new IllegalThreadStateException();
> 
> This check is not replicated in `VirtualThread::start`, i think the CAS protects against that. Maybe assert instead in the virtual thread implementation, thereby the comment in `setThreadContainer` can be changed to something like "`this.container` checked/asserted to be != null before call to Virtual/Thread::start(ThreadContainer)" ?

Yes, they are different. If adding platform thread to a container fails with OOME then it does so when its threadStatus is 0. This check just previous another attempt to start it. Virtual threads work differently but I can add an assert to make this clearer.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1153726790

From liach at openjdk.org  Thu Mar 30 20:05:23 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 30 Mar 2023 20:05:23 GMT
Subject: RFR: 8301703: java.base
 jdk.internal.foreign.abi.BindingSpecializer uses ASM to generate classes [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 30 Mar 2023 19:50:47 GMT, Jorn Vernee  wrote:

>> src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 216:
>> 
>>> 214:         if (PERFORM_VERIFICATION) {
>>> 215:             boolean printResults = false; // only print in case of exception
>>> 216:             CheckClassAdapter.verify(new ClassReader(bytes), null, printResults, new PrintWriter(System.err));
>> 
>> Classfile API provides verification functionality as well, as seen here:
>> https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/test/jdk/jdk/classfile/ClassHierarchyInfoTest.java#L105
>
> Does this provide additional verification over what is already done just by generating the class?
> 
> For instance, IIRC the ASM verifier could catch e.g. stack underflow, but that seems to be caught already by the new implementation without running the verifier.

Yes, for instance, the class generation doesn't check operand stack underflow, that you can generate code with invalid pops. The classfile verifier catches this: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/src/java.base/share/classes/jdk/internal/classfile/impl/verifier/VerificationFrame.java#L153

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13247#discussion_r1153732811

From liach at openjdk.org  Thu Mar 30 20:12:30 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 30 Mar 2023 20:12:30 GMT
Subject: RFR: 8304928: Optimize ClassDesc.resolveConstantDesc
Message-ID: 

This patch optimizes ClassDesc.resolveConstantDesc for array classes. Otherwise, the performance of reference class resolution remain unchanged. https://jmh.morethan.io/?gist=111095eecf7a735fe8c96e4b952b58c1 It also includes a benchmark for MethodTypeDesc resolution, which currently does not yet depend on class desc resolution but can be later optimized if it does switch.

-------------

Commit messages:
 - 8304928: Optimize ClassDesc.resolveConstantDesc

Changes: https://git.openjdk.org/jdk/pull/13252/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13252&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304928
  Stats: 269 lines in 4 files changed: 255 ins; 2 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/13252.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13252/head:pull/13252

PR: https://git.openjdk.org/jdk/pull/13252

From jvernee at openjdk.org  Thu Mar 30 20:14:21 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 30 Mar 2023 20:14:21 GMT
Subject: RFR: 8301703: java.base
 jdk.internal.foreign.abi.BindingSpecializer uses ASM to generate classes [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Thu, 30 Mar 2023 20:01:57 GMT, Chen Liang  wrote:

>> Does this provide additional verification over what is already done just by generating the class?
>> 
>> For instance, IIRC the ASM verifier could catch e.g. stack underflow, but that seems to be caught already by the new implementation without running the verifier.
>
> Yes, for instance, the class generation doesn't check operand stack underflow, that you can generate code with invalid pops. The classfile verifier catches this: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/src/java.base/share/classes/jdk/internal/classfile/impl/verifier/VerificationFrame.java#L153

This seems to be caught without running the verifier as well:


Caused by: java.lang.IllegalStateException: Operand stack underflow at bytecode offset 79 of method invoke(SegmentAllocator,MemorySegment,MemorySegment)
  ...
        at java.base/jdk.internal.classfile.impl.StackMapGenerator.generatorError(StackMapGenerator.java:876)
        at java.base/jdk.internal.classfile.impl.StackMapGenerator.generatorError(StackMapGenerator.java:832)
        at java.base/jdk.internal.classfile.impl.StackMapGenerator$Frame.decStack(StackMapGenerator.java:1024)
        at java.base/jdk.internal.classfile.impl.StackMapGenerator.processBlock(StackMapGenerator.java:600)
        at java.base/jdk.internal.classfile.impl.StackMapGenerator.processMethod(StackMapGenerator.java:420)
        at java.base/jdk.internal.classfile.impl.StackMapGenerator.generate(StackMapGenerator.java:293)
        at java.base/jdk.internal.classfile.impl.StackMapGenerator.(StackMapGenerator.java:232)
        at java.base/jdk.internal.classfile.impl.DirectCodeBuilder$4.writeBody(DirectCodeBuilder.java:333)
        at java.base/jdk.internal.classfile.impl.UnboundAttribute$AdHocAttribute.writeTo(UnboundAttribute.java:914)
        at java.base/jdk.internal.classfile.impl.AttributeHolder.writeTo(AttributeHolder.java:56)
        at java.base/jdk.internal.classfile.impl.DirectMethodBuilder.writeTo(DirectMethodBuilder.java:136)
        at java.base/jdk.internal.classfile.impl.BufWriterImpl.writeList(BufWriterImpl.java:194)
        at java.base/jdk.internal.classfile.impl.DirectClassBuilder.build(DirectClassBuilder.java:176)
        at java.base/jdk.internal.classfile.Classfile.build(Classfile.java:218)
        at java.base/jdk.internal.classfile.Classfile.build(Classfile.java:200)
        at java.base/jdk.internal.classfile.Classfile.build(Classfile.java:186)
        at java.base/jdk.internal.foreign.abi.BindingSpecializer.specializeHelper(BindingSpecializer.java:186)
        ...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13247#discussion_r1153740701

From jjg at openjdk.org  Thu Mar 30 20:33:17 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 30 Mar 2023 20:33:17 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1)
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 30 Mar 2023 19:42:33 GMT, Alan Bateman  wrote:

>> Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.
>> 
>> This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.
>> 
>> While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.
>> 
>> It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]
>> 
>> [here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
>> [disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115
>
> src/java.base/share/classes/java/lang/Thread.java line 1960:
> 
>> 1958:      *             thread.
>> 1959:      *
>> 1960:      * @spec jni/index.html Java Native Interface Specification
> 
> The link to the JNI spec in this method is from implNote so I'm wondering if the spec link is needed here.

Right now, the tag is added for any declaration whose comment contains a reference to an external spec (i.e. with ``. 

When we enable the "External Specifications" page, it will contain a link back to this page as part of the cross-reference info, which seems useful. That being said, if you feel strongly the tag should not be added here, I can remove it.

> src/java.base/share/classes/java/nio/file/Files.java line 1724:
> 
>> 1722:      *
>> 1723:      * @spec https://www.rfc-editor.org/info/rfc2045
>> 1724:      *      RFC 2045: RFC 2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies
> 
> Maybe this one can be put on two lines to avoid the wrapping when looking at is side-by-side.

Fixed. There was also a stutter-bug with a double "RFC 2045: RFC 2045:" which I have also fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13248#discussion_r1153755656
PR Review Comment: https://git.openjdk.org/jdk/pull/13248#discussion_r1153756945

From jjg at openjdk.org  Thu Mar 30 20:45:08 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 30 Mar 2023 20:45:08 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v2]
In-Reply-To: 
References: 
Message-ID: <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>

> Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.
> 
> This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.
> 
> While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.
> 
> It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]
> 
> [here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
> [disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  address review feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13248/files
  - new: https://git.openjdk.org/jdk/pull/13248/files/3e1102a9..096a4188

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13248&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13248&range=00-01

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13248.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13248/head:pull/13248

PR: https://git.openjdk.org/jdk/pull/13248

From jjg at openjdk.org  Thu Mar 30 20:45:10 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 30 Mar 2023 20:45:10 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1)
In-Reply-To: 
References: 
Message-ID: 

On Thu, 30 Mar 2023 17:24:11 GMT, Jonathan Gibbons  wrote:

> Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.
> 
> This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.
> 
> While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.
> 
> It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]
> 
> [here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
> [disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115

> I skimmed through the changes and it looks quite good, much more workable than PR 11073.
> 
> Do you have a proposed ordering with other tags? I expected it would go with @see but I see several where @SPEC is before @author, and @see after @author. I know it doesn't really matter.

The initial assumption was "after the @param/@return/@throws group". Overall, as I said in the description for this PR, the block tags are not very consistent about ordering. I was thinking we might want to recommend an overall ordering, but I'm worried it would be too intrusive a change to apply generally.  In the description, I suggested an ordering based on the
order in `Docs.gmk` which defines the order in which tags appear in the generated output.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13248#issuecomment-1490920050

From jlu at openjdk.org  Thu Mar 30 21:33:16 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 30 Mar 2023 21:33:16 GMT
Subject: RFR: 8225641: Calendar.roll(int field) does not work correctly for
 WEEK_OF_YEAR [v6]
In-Reply-To: 
References: 
Message-ID: 

> This PR fixes the bug which occurred when `Calendar.roll(WEEK_OF_YEAR)` rolled into a minimal first week with an invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo.
> 
> For example, Rolling _Monday, 30 December 2019_ by 1 week produced _Monday, 31 December 2018_, which is incorrect. This is because `WEEK_OF_YEAR` is rolled from 52 to 1, and the original `DAY_OF_WEEK` is 1. However, there is no Monday in week 1 of 2019. This is exposed when a future method calls `Calendar.complete()`, which eventually calculates a `fixedDate` with the invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo.
> 
> To prevent this, a check is added for rolls into week 1, which determines if the first week is minimal. If it is indeed minimal, then it is checked if  `DAY_OF_WEEK` exists in that week, if not, `WEEK_OF_YEAR` must be incremented by one.
> 
> After the fix, Rolling _Monday, 30 December 2019_ by 1 week produces _Monday, 7 January 2019_

Justin Lu has updated the pull request incrementally with two additional commits since the last revision:

 - dayInMinWeek should range check input and throw exception
 - Tweak static cal builder

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13031/files
  - new: https://git.openjdk.org/jdk/pull/13031/files/60d0621b..7c9291a3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13031&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13031&range=04-05

  Stats: 17 lines in 2 files changed: 11 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/13031.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13031/head:pull/13031

PR: https://git.openjdk.org/jdk/pull/13031

From jlu at openjdk.org  Thu Mar 30 21:33:19 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 30 Mar 2023 21:33:19 GMT
Subject: RFR: 8225641: Calendar.roll(int field) does not work correctly for
 WEEK_OF_YEAR [v5]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 29 Mar 2023 23:14:17 GMT, Naoto Sato  wrote:

>> Justin Lu has updated the pull request incrementally with five additional commits since the last revision:
>> 
>>  - Impl cleanup, add Saturday end day conditional
>>  - Rename test, clarify test documentation
>>  - Add type to static declaration of Cal.Builder, since only concerned with Gregorian for this test
>>  - Pass in amount as 1 directly
>>  - Reuse Calendar.Builder
>
> src/java.base/share/classes/java/util/GregorianCalendar.java line 3014:
> 
>> 3012:      */
>> 3013:     private boolean dayInMinWeek (int day, int startDay, int endDay) {
>> 3014:         endDay = endDay == 0
> 
> Why `endDay` can be `0`? If the arguments are `Calendar.XXXDAY`, should they be between 1 to 7? In other words, why is the above calling site doing `getFirstDayOfWeek() - 1`?
> I'd add some range checks for the input values.

Right. I have changed it so the method throws an exception if the start and end days are not valid `DAY_OF_WEEK `values.

And I have moved the ternary of switching 0 to 7 outside the method accordingly.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13031#discussion_r1153805524

From jvernee at openjdk.org  Thu Mar 30 22:12:18 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 30 Mar 2023 22:12:18 GMT
Subject: RFR: 8301703: java.base
 jdk.internal.foreign.abi.BindingSpecializer uses ASM to generate classes [v2]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Thu, 30 Mar 2023 20:11:30 GMT, Jorn Vernee  wrote:

>> Yes, for instance, the class generation doesn't check operand stack underflow, that you can generate code with invalid pops. The classfile verifier catches this: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/src/java.base/share/classes/jdk/internal/classfile/impl/verifier/VerificationFrame.java#L153
>
> This seems to be caught without running the verifier as well:
> 
> 
> Caused by: java.lang.IllegalStateException: Operand stack underflow at bytecode offset 79 of method invoke(SegmentAllocator,MemorySegment,MemorySegment)
>   ...
>         at java.base/jdk.internal.classfile.impl.StackMapGenerator.generatorError(StackMapGenerator.java:876)
>         at java.base/jdk.internal.classfile.impl.StackMapGenerator.generatorError(StackMapGenerator.java:832)
>         at java.base/jdk.internal.classfile.impl.StackMapGenerator$Frame.decStack(StackMapGenerator.java:1024)
>         at java.base/jdk.internal.classfile.impl.StackMapGenerator.processBlock(StackMapGenerator.java:600)
>         at java.base/jdk.internal.classfile.impl.StackMapGenerator.processMethod(StackMapGenerator.java:420)
>         at java.base/jdk.internal.classfile.impl.StackMapGenerator.generate(StackMapGenerator.java:293)
>         at java.base/jdk.internal.classfile.impl.StackMapGenerator.(StackMapGenerator.java:232)
>         at java.base/jdk.internal.classfile.impl.DirectCodeBuilder$4.writeBody(DirectCodeBuilder.java:333)
>         at java.base/jdk.internal.classfile.impl.UnboundAttribute$AdHocAttribute.writeTo(UnboundAttribute.java:914)
>         at java.base/jdk.internal.classfile.impl.AttributeHolder.writeTo(AttributeHolder.java:56)
>         at java.base/jdk.internal.classfile.impl.DirectMethodBuilder.writeTo(DirectMethodBuilder.java:136)
>         at java.base/jdk.internal.classfile.impl.BufWriterImpl.writeList(BufWriterImpl.java:194)
>         at java.base/jdk.internal.classfile.impl.DirectClassBuilder.build(DirectClassBuilder.java:176)
>         at java.base/jdk.internal.classfile.Classfile.build(Classfile.java:218)
>         at java.base/jdk.internal.classfile.Classfile.build(Classfile.java:200)
>         at java.base/jdk.internal.classfile.Classfile.build(Classfile.java:186)
>         at java.base/jdk.internal.foreign.abi.BindingSpecializer.specializeHelper(BindingSpecializer.java:186)
>         ...
> 
> 
> (I think ASM will just throw an array index OOB exception when processing a subsequent frame)

Just to clarify: I'm looking for the kind of errors that don't get caught by just generating the class, but are also more informative than the default VerifyError you would get from loading an invalid class.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13247#discussion_r1153837379

From jlu at openjdk.org  Thu Mar 30 22:37:29 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 30 Mar 2023 22:37:29 GMT
Subject: Integrated: 8305111: Locale.lookupTag has typo in parameter
In-Reply-To: <0RAdK8ZfiSUn1UZKzX44LAvjE0i8l_0LKEoC-63bY24=.12f961ee-ac5b-41cf-9697-62e3f6b8812f@github.com>
References: <0RAdK8ZfiSUn1UZKzX44LAvjE0i8l_0LKEoC-63bY24=.12f961ee-ac5b-41cf-9697-62e3f6b8812f@github.com>
Message-ID: <8jw6hyaw1bBqP7rPOzxKnAiOGcwYhrmcXJ9xxgc_1ww=.0205b2d9-1bb8-4af8-96c5-1232c91a0fbc@github.com>

On Wed, 29 Mar 2023 22:51:12 GMT, Justin Lu  wrote:

> Small typo fix in Locale.lookupTag
> 
> _tangs_ should be _tags_

This pull request has now been integrated.

Changeset: 5f7b4b8e
Author:    Justin Lu 
Committer: Naoto Sato 
URL:       https://git.openjdk.org/jdk/commit/5f7b4b8e75fdf4a22c108a0ad528147e924a3ee4
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8305111: Locale.lookupTag has typo in parameter

Reviewed-by: lancea, iris, naoto

-------------

PR: https://git.openjdk.org/jdk/pull/13235

From jlu at openjdk.org  Thu Mar 30 22:37:29 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 30 Mar 2023 22:37:29 GMT
Subject: Integrated: 8304993: bad sentence break in DateFormat
In-Reply-To: 
References: 
Message-ID: 

On Tue, 28 Mar 2023 21:01:45 GMT, Justin Lu  wrote:

> This PR fixes a bad sentence break in DateFormat.FIELD AM_PM that caused incomplete API
> 
> Before:
> Screen Shot 2023-03-27
> 
> After:
> 

This pull request has now been integrated.

Changeset: d8158897
Author:    Justin Lu 
Committer: Naoto Sato 
URL:       https://git.openjdk.org/jdk/commit/d8158897c3d0dbea46e4f55ad8b501252d88b7e1
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8304993: bad sentence break in DateFormat

Reviewed-by: rriggs, naoto, lancea, iris

-------------

PR: https://git.openjdk.org/jdk/pull/13216

From naoto at openjdk.org  Thu Mar 30 22:44:16 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 30 Mar 2023 22:44:16 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v2]
In-Reply-To: <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
References: 
 <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
Message-ID: <6a2ZYG8twjvIWSMNXjFdLra2lXGXoC3R9wyVFL8BAiY=.11396706-6da0-44fb-8e68-3965fd418edd@github.com>

On Thu, 30 Mar 2023 20:45:08 GMT, Jonathan Gibbons  wrote:

>> Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.
>> 
>> This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.
>> 
>> While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.
>> 
>> It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]
>> 
>> [here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
>> [disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review feedback

Changes in i18n-related classes look good to me.

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13248#pullrequestreview-1366032864

From mchung at openjdk.org  Thu Mar 30 23:24:20 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 30 Mar 2023 23:24:20 GMT
Subject: RFR: 8304928: Optimize ClassDesc.resolveConstantDesc
In-Reply-To: 
References: 
Message-ID: 

On Thu, 30 Mar 2023 20:06:02 GMT, Chen Liang  wrote:

> This patch optimizes ClassDesc.resolveConstantDesc for array classes. Otherwise, the performance of reference class resolution remain unchanged. https://jmh.morethan.io/?gist=111095eecf7a735fe8c96e4b952b58c1 It also includes a benchmark for MethodTypeDesc resolution, which currently does not yet depend on class desc resolution but can be later optimized if it does switch.

src/java.base/share/classes/java/lang/constant/ConstantUtils.java line 130:

> 128: 
> 129:     static boolean isPrimitiveArray(String referenceTypeDescriptorString) {
> 130:         return referenceTypeDescriptorString.charAt(referenceTypeDescriptorString.length() - 1) != ';';

it also needs to check if it starts with `[`


Suggestion:

        return referenceTypeDescriptorString.startsWith("[") &&  
                  referenceTypeDescriptorString.charAt(referenceTypeDescriptorString.length() - 1) != ';';

test/micro/org/openjdk/bench/java/lang/constant/MethodTypeDescResolve.java line 53:

> 51: @Fork(1)
> 52: @State(Scope.Benchmark)
> 53: public class MethodTypeDescResolve {

Better to separate this benchmark from this PR.   Probably the optimization done in [PR 10991](https://github.com/openjdk/jdk/pull/10991) should be a separate patch from JDK-8294961 and this benchmark could be included there.

test/micro/org/openjdk/bench/java/lang/constant/ReferenceClassDescResolve.java line 120:

> 118:                 return resolveReference(lookup, cd);
> 119:             }
> 120:         },

I think this benchmark doesn't need this case as that's the implementation of `resolveConstantDesc`.   Was it there when you developed this fix?   Same for MethodTypeDesc benchmark.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13252#discussion_r1153874210
PR Review Comment: https://git.openjdk.org/jdk/pull/13252#discussion_r1153877556
PR Review Comment: https://git.openjdk.org/jdk/pull/13252#discussion_r1153876110

From naoto at openjdk.org  Thu Mar 30 23:27:21 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 30 Mar 2023 23:27:21 GMT
Subject: RFR: 8225641: Calendar.roll(int field) does not work correctly for
 WEEK_OF_YEAR [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 30 Mar 2023 21:33:16 GMT, Justin Lu  wrote:

>> This PR fixes the bug which occurred when `Calendar.roll(WEEK_OF_YEAR)` rolled into a minimal first week with an invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo.
>> 
>> For example, Rolling _Monday, 30 December 2019_ by 1 week produced _Monday, 31 December 2018_, which is incorrect. This is because `WEEK_OF_YEAR` is rolled from 52 to 1, and the original `DAY_OF_WEEK` is 1. However, there is no Monday in week 1 of 2019. This is exposed when a future method calls `Calendar.complete()`, which eventually calculates a `fixedDate` with the invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo.
>> 
>> To prevent this, a check is added for rolls into week 1, which determines if the first week is minimal. If it is indeed minimal, then it is checked if  `DAY_OF_WEEK` exists in that week, if not, `WEEK_OF_YEAR` must be incremented by one.
>> 
>> After the fix, Rolling _Monday, 30 December 2019_ by 1 week produces _Monday, 7 January 2019_
>
> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - dayInMinWeek should range check input and throw exception
>  - Tweak static cal builder

src/java.base/share/classes/java/util/GregorianCalendar.java line 3025:

> 3023:         if (endDay > 7 || endDay < 1 || startDay > 7 || startDay < 1) {
> 3024:             throw new IllegalArgumentException("Start day or end day is not " +
> 3025:                     "a valid day of the week");

Sorry, I take my previous comment back. I think we can simply rely on the return value from `getFirstDayOfWeek()` as it is well-checked, so no need to check the input here. Otherwise the thrown IAE woudl have to end up in `add()/roll()` public methods, which cannot be spec'ed with these internal arguments.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13031#discussion_r1153877382

From mchung at openjdk.org  Thu Mar 30 23:51:18 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 30 Mar 2023 23:51:18 GMT
Subject: RFR: 8303930: Fix ConstantUtils.skipOverFieldSignature void case
 return value [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 21 Mar 2023 20:21:23 GMT, Chen Liang  wrote:

>> This typo doesn't allow creation of malformed ClassDesc or MethodTypeDesc, but it produces an erroneous exception on certain inputs. Running `java.lang.constant.MethodTypeDesc.ofDescriptor("(IIIII[[[V)I")` in Jshell 19.0.2 throws StringIndexOutOfBoundsException, and throws IllegalArgumentException in the Jshell for this patch.
>
> Chen Liang 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' of https://git.openjdk.java.net/jdk into 8303930
>  - Add test for skipOverFieldSignature bug
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into 8303930
>  - Copyright year
>  - 8303930: Fix ConstantUtils.skipOverFieldSignature void case return value

Otherwise, looks good.

test/jdk/java/lang/constant/boottest/java.base/java/lang/constant/ConstantUtilsTest.java line 73:

> 71:     public void testSkipOverFieldSignatureVoid() {
> 72:        int ret = ConstantUtils.skipOverFieldSignature("(V)V", 1, 4, false);
> 73:        assertEquals(ret, 0, "Descriptor Length of (V)V starting at index 1, void disallowed");

I think you mean:

Suggestion:

       assertEquals(ret, 0, "Descriptor of (V)V starting at index 1, void disallowed");

-------------

PR Review: https://git.openjdk.org/jdk/pull/12964#pullrequestreview-1366077560
PR Review Comment: https://git.openjdk.org/jdk/pull/12964#discussion_r1153889851

From psandoz at openjdk.org  Fri Mar 31 00:01:22 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 31 Mar 2023 00:01:22 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 30 Mar 2023 14:30:17 GMT, Quan Anh Mai  wrote:

>> Hi,
>> 
>> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, VectorShuffle is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
>> 
>> 1. Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
>> 2. Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
>> 3. Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
>> 4. Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
>> 
>> Upon these changes, a `rearrange` can emit more efficient code:
>> 
>>     var species = IntVector.SPECIES_128;
>>     var v1 = IntVector.fromArray(species, SRC1, 0);
>>     var v2 = IntVector.fromArray(species, SRC2, 0);
>>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
>> 
>>     Before:
>>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>>     vmovdqu 0x10(%r10),%xmm0
>>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byte_mask
>>                                                             ;   {external_word}
>>     vpackusdw %xmm0,%xmm0,%xmm0
>>     vpackuswb %xmm0,%xmm0,%xmm0
>>     vpmovsxbd %xmm0,%xmm3
>>     vpcmpgtd %xmm3,%xmm1,%xmm3
>>     vtestps %xmm3,%xmm3
>>     jne    0x00007fc2acb4e0d8
>>     vpmovzxbd %xmm0,%xmm0
>>     vpermd %ymm2,%ymm0,%ymm0
>>     movabs $0x751588f98,%r10            ;   {oop([I{0x0000000751588f98})}
>>     vmovdqu %xmm0,0x10(%r10)
>> 
>>     After:
>>     movabs $0x751589c78,%r10            ;   {oop([I{0x0000000751589c78})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158ac88,%r10            ;   {oop([I{0x000000075158ac88})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     vpxor  %xmm0,%xmm0,%xmm0
>>     vpcmpgtd %xmm2,%xmm0,%xmm3
>>     vtestps %xmm3,%xmm3
>>     jne    0x00007fa818b27cb1
>>     vpermd %ymm1,%ymm2,%ymm0
>>     movabs $0x751588c68,%r10            ;   {oop([I{0x0000000751588c68})}
>>     vmovdqu %xmm0,0x10(%r10)
>>     
>> Please take a look and leave reviews. Thanks a lot.
>
> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - move implementations up
>  - Merge branch 'master' into shufflerefactor
>  - Merge branch 'master' into shufflerefactor
>  - reviews
>  - missing casts
>  - clean up
>  - fix Matcher::vector_needs_load_shuffle
>  - fix internal types, clean up
>  - optimise laneIsValid
>  - Merge branch 'master' into shufflerefactor
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/d063b896...a4835c00

src/hotspot/cpu/x86/x86.ad line 2174:

> 2172: }
> 2173: 
> 2174: // Do Vector::rearrange needs preparation of the shuffle argument

Suggestion:

// Returns true if Vector::rearrange needs preparation of the shuffle argument

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1153894269

From psandoz at openjdk.org  Fri Mar 31 00:10:29 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 31 Mar 2023 00:10:29 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 30 Mar 2023 14:30:17 GMT, Quan Anh Mai  wrote:

>> Hi,
>> 
>> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, VectorShuffle is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
>> 
>> 1. Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
>> 2. Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
>> 3. Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
>> 4. Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
>> 
>> Upon these changes, a `rearrange` can emit more efficient code:
>> 
>>     var species = IntVector.SPECIES_128;
>>     var v1 = IntVector.fromArray(species, SRC1, 0);
>>     var v2 = IntVector.fromArray(species, SRC2, 0);
>>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
>> 
>>     Before:
>>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>>     vmovdqu 0x10(%r10),%xmm0
>>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byte_mask
>>                                                             ;   {external_word}
>>     vpackusdw %xmm0,%xmm0,%xmm0
>>     vpackuswb %xmm0,%xmm0,%xmm0
>>     vpmovsxbd %xmm0,%xmm3
>>     vpcmpgtd %xmm3,%xmm1,%xmm3
>>     vtestps %xmm3,%xmm3
>>     jne    0x00007fc2acb4e0d8
>>     vpmovzxbd %xmm0,%xmm0
>>     vpermd %ymm2,%ymm0,%ymm0
>>     movabs $0x751588f98,%r10            ;   {oop([I{0x0000000751588f98})}
>>     vmovdqu %xmm0,0x10(%r10)
>> 
>>     After:
>>     movabs $0x751589c78,%r10            ;   {oop([I{0x0000000751589c78})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158ac88,%r10            ;   {oop([I{0x000000075158ac88})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     vpxor  %xmm0,%xmm0,%xmm0
>>     vpcmpgtd %xmm2,%xmm0,%xmm3
>>     vtestps %xmm3,%xmm3
>>     jne    0x00007fa818b27cb1
>>     vpermd %ymm1,%ymm2,%ymm0
>>     movabs $0x751588c68,%r10            ;   {oop([I{0x0000000751588c68})}
>>     vmovdqu %xmm0,0x10(%r10)
>>     
>> Please take a look and leave reviews. Thanks a lot.
>
> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - move implementations up
>  - Merge branch 'master' into shufflerefactor
>  - Merge branch 'master' into shufflerefactor
>  - reviews
>  - missing casts
>  - clean up
>  - fix Matcher::vector_needs_load_shuffle
>  - fix internal types, clean up
>  - optimise laneIsValid
>  - Merge branch 'master' into shufflerefactor
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/d063b896...a4835c00

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractVector.java line 204:

> 202:                                      dvtype, dtype, dlength,
> 203:                                   this, dsp,
> 204:                                      AbstractVector::toShuffle0);

Suggestion:

        return VectorSupport.convert(VectorSupport.VECTOR_OP_CAST,
                                     getClass(), etype, length(),
                                     dvtype, dtype, dlength,
                                     this, dsp,
                                     AbstractVector::toShuffle0);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1153897796

From ysatowse at openjdk.org  Fri Mar 31 00:11:22 2023
From: ysatowse at openjdk.org (Yoshiki Sato)
Date: Fri, 31 Mar 2023 00:11:22 GMT
Subject: RFR: 8304763: (tz) Update Timezone Data to 2023a
In-Reply-To: 
References: 
Message-ID: 

On Fri, 31 Mar 2023 00:02:02 GMT, Yoshiki Sato  wrote:

> Pleases review this PR. 
> The PR includes the following changes.
> - tzdata 2023c
> - Hack code to deal with Cairo's DST end, which is same as done in 2014g([JDK-8049343](https://bugs.openjdk.org/browse/JDK-8049343)).  To work around the the limitation of JSR 310 compiler, where the time 24:00 is recognized as 0:00 in the previous day.

Please review this PR. @naotoj

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13255#issuecomment-1491114089

From ysatowse at openjdk.org  Fri Mar 31 00:11:22 2023
From: ysatowse at openjdk.org (Yoshiki Sato)
Date: Fri, 31 Mar 2023 00:11:22 GMT
Subject: RFR: 8304763: (tz) Update Timezone Data to 2023a
Message-ID: 

Pleases review this PR. 
The PR includes the following changes.
- tzdata 2023c
- Hack code to deal with Cairo's DST end, which is same as done in 2014g([JDK-8049343](https://bugs.openjdk.org/browse/JDK-8049343)).  To work around the the limitation of JSR 310 compiler, where the time 24:00 is recognized as 0:00 in the previous day.

-------------

Commit messages:
 - 1st commit for tz2023c

Changes: https://git.openjdk.org/jdk/pull/13255/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13255&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304763
  Stats: 333 lines in 18 files changed: 189 ins; 24 del; 120 mod
  Patch: https://git.openjdk.org/jdk/pull/13255.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13255/head:pull/13255

PR: https://git.openjdk.org/jdk/pull/13255

From psandoz at openjdk.org  Fri Mar 31 00:21:22 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 31 Mar 2023 00:21:22 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 30 Mar 2023 14:30:17 GMT, Quan Anh Mai  wrote:

>> Hi,
>> 
>> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, VectorShuffle is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
>> 
>> 1. Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
>> 2. Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
>> 3. Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
>> 4. Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
>> 
>> Upon these changes, a `rearrange` can emit more efficient code:
>> 
>>     var species = IntVector.SPECIES_128;
>>     var v1 = IntVector.fromArray(species, SRC1, 0);
>>     var v2 = IntVector.fromArray(species, SRC2, 0);
>>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
>> 
>>     Before:
>>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>>     vmovdqu 0x10(%r10),%xmm0
>>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byte_mask
>>                                                             ;   {external_word}
>>     vpackusdw %xmm0,%xmm0,%xmm0
>>     vpackuswb %xmm0,%xmm0,%xmm0
>>     vpmovsxbd %xmm0,%xmm3
>>     vpcmpgtd %xmm3,%xmm1,%xmm3
>>     vtestps %xmm3,%xmm3
>>     jne    0x00007fc2acb4e0d8
>>     vpmovzxbd %xmm0,%xmm0
>>     vpermd %ymm2,%ymm0,%ymm0
>>     movabs $0x751588f98,%r10            ;   {oop([I{0x0000000751588f98})}
>>     vmovdqu %xmm0,0x10(%r10)
>> 
>>     After:
>>     movabs $0x751589c78,%r10            ;   {oop([I{0x0000000751589c78})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158ac88,%r10            ;   {oop([I{0x000000075158ac88})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     vpxor  %xmm0,%xmm0,%xmm0
>>     vpcmpgtd %xmm2,%xmm0,%xmm3
>>     vtestps %xmm3,%xmm3
>>     jne    0x00007fa818b27cb1
>>     vpermd %ymm1,%ymm2,%ymm0
>>     movabs $0x751588c68,%r10            ;   {oop([I{0x0000000751588c68})}
>>     vmovdqu %xmm0,0x10(%r10)
>>     
>> Please take a look and leave reviews. Thanks a lot.
>
> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - move implementations up
>  - Merge branch 'master' into shufflerefactor
>  - Merge branch 'master' into shufflerefactor
>  - reviews
>  - missing casts
>  - clean up
>  - fix Matcher::vector_needs_load_shuffle
>  - fix internal types, clean up
>  - optimise laneIsValid
>  - Merge branch 'master' into shufflerefactor
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/d063b896...a4835c00

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-VectorBits.java.template line 1106:

> 1104:         @Override
> 1105:         @ForceInline
> 1106:         public int laneSource(int i) {

Can this method be moved to `AbstractShuffle`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1153902133

From psandoz at openjdk.org  Fri Mar 31 00:29:22 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 31 Mar 2023 00:29:22 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 30 Mar 2023 14:30:17 GMT, Quan Anh Mai  wrote:

>> Hi,
>> 
>> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, VectorShuffle is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
>> 
>> 1. Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
>> 2. Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
>> 3. Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
>> 4. Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
>> 
>> Upon these changes, a `rearrange` can emit more efficient code:
>> 
>>     var species = IntVector.SPECIES_128;
>>     var v1 = IntVector.fromArray(species, SRC1, 0);
>>     var v2 = IntVector.fromArray(species, SRC2, 0);
>>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
>> 
>>     Before:
>>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>>     vmovdqu 0x10(%r10),%xmm0
>>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byte_mask
>>                                                             ;   {external_word}
>>     vpackusdw %xmm0,%xmm0,%xmm0
>>     vpackuswb %xmm0,%xmm0,%xmm0
>>     vpmovsxbd %xmm0,%xmm3
>>     vpcmpgtd %xmm3,%xmm1,%xmm3
>>     vtestps %xmm3,%xmm3
>>     jne    0x00007fc2acb4e0d8
>>     vpmovzxbd %xmm0,%xmm0
>>     vpermd %ymm2,%ymm0,%ymm0
>>     movabs $0x751588f98,%r10            ;   {oop([I{0x0000000751588f98})}
>>     vmovdqu %xmm0,0x10(%r10)
>> 
>>     After:
>>     movabs $0x751589c78,%r10            ;   {oop([I{0x0000000751589c78})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158ac88,%r10            ;   {oop([I{0x000000075158ac88})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     vpxor  %xmm0,%xmm0,%xmm0
>>     vpcmpgtd %xmm2,%xmm0,%xmm3
>>     vtestps %xmm3,%xmm3
>>     jne    0x00007fa818b27cb1
>>     vpermd %ymm1,%ymm2,%ymm0
>>     movabs $0x751588c68,%r10            ;   {oop([I{0x0000000751588c68})}
>>     vmovdqu %xmm0,0x10(%r10)
>>     
>> Please take a look and leave reviews. Thanks a lot.
>
> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - move implementations up
>  - Merge branch 'master' into shufflerefactor
>  - Merge branch 'master' into shufflerefactor
>  - reviews
>  - missing casts
>  - clean up
>  - fix Matcher::vector_needs_load_shuffle
>  - fix internal types, clean up
>  - optimise laneIsValid
>  - Merge branch 'master' into shufflerefactor
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/d063b896...a4835c00

The changes look very good to me. It would be useful if @jatin-bhateja could also take a look.

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-VectorBits.java.template line 1158:

> 1156:         }
> 1157: 
> 1158:         private static $bitstype$[] prepare(int[] indices, int offset) {

If we want to reduce code duplication further I suspect we could move these static methods to IntVector etc. Up to you.

-------------

Marked as reviewed by psandoz (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13093#pullrequestreview-1366098245
PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1153904271

From liach at openjdk.org  Fri Mar 31 00:57:15 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 31 Mar 2023 00:57:15 GMT
Subject: RFR: 8304928: Optimize ClassDesc.resolveConstantDesc
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 30 Mar 2023 23:13:51 GMT, Mandy Chung  wrote:

>> This patch optimizes ClassDesc.resolveConstantDesc for array classes. Otherwise, the performance of reference class resolution remain unchanged. https://jmh.morethan.io/?gist=111095eecf7a735fe8c96e4b952b58c1 It also includes a benchmark for MethodTypeDesc resolution, which currently does not yet depend on class desc resolution but can be later optimized if it does switch.
>
> src/java.base/share/classes/java/lang/constant/ConstantUtils.java line 130:
> 
>> 128: 
>> 129:     static boolean isPrimitiveArray(String referenceTypeDescriptorString) {
>> 130:         return referenceTypeDescriptorString.charAt(referenceTypeDescriptorString.length() - 1) != ';';
> 
> it also needs to check if it starts with `[`
> 
> 
> Suggestion:
> 
>         return referenceTypeDescriptorString.startsWith("[") &&  
>                referenceTypeDescriptorString.charAt(referenceTypeDescriptorString.length() - 1) != ';';

I intend this to be a `ReferenceClassDesc`-specifc check. I think moving `isPrimitiveArray` as a private method in `ReferenceClassDesc` would be better, as the `startsWith("[")` is already implied (at least before valhalla, non-array, i.e. class or interface descriptors must end with a semicolon.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13252#discussion_r1153916176

From naoto at openjdk.org  Fri Mar 31 01:11:15 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 31 Mar 2023 01:11:15 GMT
Subject: RFR: 8304763: (tz) Update Timezone Data to 2023a
In-Reply-To: 
References: 
Message-ID: 

On Fri, 31 Mar 2023 00:02:02 GMT, Yoshiki Sato  wrote:

> Pleases review this PR. 
> The PR includes the following changes.
> - tzdata 2023c
> - Hack code to deal with Cairo's DST end, which is same as done in 2014g([JDK-8049343](https://bugs.openjdk.org/browse/JDK-8049343)).  To work around the the limitation of JSR 310 compiler, where the time 24:00 is recognized as 0:00 in the previous day.

IIUC, this PR is for `2023a` so this should be withdrawn. Instead, you may want to open a PR for https://bugs.openjdk.org/browse/JDK-8305113 which is for `2023c`?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13255#issuecomment-1491153257

From xgong at openjdk.org  Fri Mar 31 01:31:30 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Fri, 31 Mar 2023 01:31:30 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v5]
In-Reply-To: 
References: 
 <4Op0Z8whnyDXDC6zGyMbx4ugcZp5TEoAqW_myB5flxM=.1c7b59ba-efb2-4f68-90d7-2d6e33e39572@github.com>
 
 
 
 
Message-ID: <85ZXqzxAoKbsQrQdxENyOxLI_t5BXW5skPnWEHxcjd0=.7cb7e9f7-8049-4b23-938f-041c8e45b0ec@github.com>

On Thu, 30 Mar 2023 14:41:29 GMT, Quan Anh Mai  wrote:

>> Yeah, I agree that saving a node have some benefits like what you said. My concern is there are more and more methods added into `Matcher::` and each platform has to do the different implementation. There is not too much meaning for those platforms that do not implement Vector API like` arm/ppc/...` for me. This makes code not so easy to maintain.
>
> I agree, I am thinking of (ab)using template to have a common query function like this
> 
>     template 
>     T vectorQuery(U... args) {
>         return T();
>     }
> 
> then each platform can have a specialisation that looks like this:
> 
>     template <>
>     bool vectorQuery(BasicType bt, int vlen) {
>     }
> 
> Unimplemented platform will return `false` for this, what do you think?

Sounds good! Maybe we can have a folllowed patch to see what the final code looks like. Thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1153928312

From ysatowse at openjdk.org  Fri Mar 31 01:51:15 2023
From: ysatowse at openjdk.org (Yoshiki Sato)
Date: Fri, 31 Mar 2023 01:51:15 GMT
Subject: RFR: 8305113: (tz) Update Timezone Data to 2023c
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 31 Mar 2023 00:02:59 GMT, Yoshiki Sato  wrote:

>> Pleases review this PR. 
>> The PR includes the following changes.
>> - tzdata 2023c
>> - Hack code to deal with Cairo's DST end, which is same as done in 2014g([JDK-8049343](https://bugs.openjdk.org/browse/JDK-8049343)).  To work around the the limitation of JSR 310 compiler, where the time 24:00 is recognized as 0:00 in the previous day.
>
> Please review this PR. @naotoj

> @satoyoshiki The issue `8304763` was not found in the list of additional solved issues. The list currently contains these issues: `8305113`

@naotoj Thanks for the catch.  I mistakenly put the wrong JBS id into `/issue` command.  `8304763` is now removed then the bot has got the review link removed from `JDK-8304763`.  Is this ok for you?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13255#issuecomment-1491175416

From liach at openjdk.org  Fri Mar 31 02:27:05 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 31 Mar 2023 02:27:05 GMT
Subject: RFR: 8304928: Optimize ClassDesc.resolveConstantDesc [v2]
In-Reply-To: 
References: 
Message-ID: 

> This patch optimizes ClassDesc.resolveConstantDesc for array classes. Otherwise, the performance of reference class resolution remain unchanged.
> 
> A benchmark comparing resolution for reference arrays, primitive arrays, and class or interfaces is included in this patch, and the result comparison on my machine is available at https://jmh.morethan.io/?gists=21c462f4879f6166b3308a41c092d51e,1aeae6ff40a129f89dbfedcb874cfd37

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Update per review, will post new benchmark results

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13252/files
  - new: https://git.openjdk.org/jdk/pull/13252/files/960cbff9..c347939e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13252&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13252&range=00-01

  Stats: 221 lines in 4 files changed: 16 ins; 190 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/13252.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13252/head:pull/13252

PR: https://git.openjdk.org/jdk/pull/13252

From liach at openjdk.org  Fri Mar 31 02:27:06 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 31 Mar 2023 02:27:06 GMT
Subject: RFR: 8304928: Optimize ClassDesc.resolveConstantDesc
In-Reply-To: 
References: 
Message-ID: <_Bmnm22i03DzNombB2Ahl8ITc0n_83YGamGlaM-7190=.67a466f3-88ad-40a6-9e64-df8994af54a2@github.com>

On Thu, 30 Mar 2023 20:06:02 GMT, Chen Liang  wrote:

> This patch optimizes ClassDesc.resolveConstantDesc for array classes. Otherwise, the performance of reference class resolution remain unchanged.
> 
> A benchmark comparing resolution for reference arrays, primitive arrays, and class or interfaces is included in this patch, and the result comparison on my machine is available at https://jmh.morethan.io/?gists=21c462f4879f6166b3308a41c092d51e,1aeae6ff40a129f89dbfedcb874cfd37

Done. Now the benchmark explicitly measures the 3 reference types, with new result in line with previous observations here: https://jmh.morethan.io/?gists=21c462f4879f6166b3308a41c092d51e,1aeae6ff40a129f89dbfedcb874cfd37

The `isPrimitiveArray` check is converted to a private method in `ReferenceClassDesc` as it applies only to reference type descriptor strings. Also included the rationale for not checking initial `[` in a comment.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13252#issuecomment-1491196749

From liach at openjdk.org  Fri Mar 31 02:28:31 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 31 Mar 2023 02:28:31 GMT
Subject: RFR: 8303930: Fix ConstantUtils.skipOverFieldSignature void case
 return value [v4]
In-Reply-To: 
References: 
Message-ID: <2Rs6gOAbhpxgEr3NK0LeS9j6CMgDJn4zJ1cGEntyMUQ=.07658740-ec26-46d8-9c06-e1b081d536db@github.com>

> This typo doesn't allow creation of malformed ClassDesc or MethodTypeDesc, but it produces an erroneous exception on certain inputs. Running `java.lang.constant.MethodTypeDesc.ofDescriptor("(IIIII[[[V)I")` in Jshell 19.0.2 throws StringIndexOutOfBoundsException, and throws IllegalArgumentException in the Jshell for this patch.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Update test/jdk/java/lang/constant/boottest/java.base/java/lang/constant/ConstantUtilsTest.java
  
  Co-authored-by: Mandy Chung 

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12964/files
  - new: https://git.openjdk.org/jdk/pull/12964/files/f53269ca..a3f892a6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12964&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12964&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12964.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12964/head:pull/12964

PR: https://git.openjdk.org/jdk/pull/12964

From liach at openjdk.org  Fri Mar 31 02:37:19 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 31 Mar 2023 02:37:19 GMT
Subject: RFR: 8301703: java.base
 jdk.internal.foreign.abi.BindingSpecializer uses ASM to generate classes [v2]
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: 

On Thu, 30 Mar 2023 22:09:24 GMT, Jorn Vernee  wrote:

>> This seems to be caught without running the verifier as well:
>> 
>> 
>> Caused by: java.lang.IllegalStateException: Operand stack underflow at bytecode offset 79 of method invoke(SegmentAllocator,MemorySegment,MemorySegment)
>>   ...
>>         at java.base/jdk.internal.classfile.impl.StackMapGenerator.generatorError(StackMapGenerator.java:876)
>>         at java.base/jdk.internal.classfile.impl.StackMapGenerator.generatorError(StackMapGenerator.java:832)
>>         at java.base/jdk.internal.classfile.impl.StackMapGenerator$Frame.decStack(StackMapGenerator.java:1024)
>>         at java.base/jdk.internal.classfile.impl.StackMapGenerator.processBlock(StackMapGenerator.java:600)
>>         at java.base/jdk.internal.classfile.impl.StackMapGenerator.processMethod(StackMapGenerator.java:420)
>>         at java.base/jdk.internal.classfile.impl.StackMapGenerator.generate(StackMapGenerator.java:293)
>>         at java.base/jdk.internal.classfile.impl.StackMapGenerator.(StackMapGenerator.java:232)
>>         at java.base/jdk.internal.classfile.impl.DirectCodeBuilder$4.writeBody(DirectCodeBuilder.java:333)
>>         at java.base/jdk.internal.classfile.impl.UnboundAttribute$AdHocAttribute.writeTo(UnboundAttribute.java:914)
>>         at java.base/jdk.internal.classfile.impl.AttributeHolder.writeTo(AttributeHolder.java:56)
>>         at java.base/jdk.internal.classfile.impl.DirectMethodBuilder.writeTo(DirectMethodBuilder.java:136)
>>         at java.base/jdk.internal.classfile.impl.BufWriterImpl.writeList(BufWriterImpl.java:194)
>>         at java.base/jdk.internal.classfile.impl.DirectClassBuilder.build(DirectClassBuilder.java:176)
>>         at java.base/jdk.internal.classfile.Classfile.build(Classfile.java:218)
>>         at java.base/jdk.internal.classfile.Classfile.build(Classfile.java:200)
>>         at java.base/jdk.internal.classfile.Classfile.build(Classfile.java:186)
>>         at java.base/jdk.internal.foreign.abi.BindingSpecializer.specializeHelper(BindingSpecializer.java:186)
>>         ...
>> 
>> 
>> (I think ASM will just throw an array index OOB exception when processing a subsequent frame)
>
> Just to clarify: I'm looking for the kind of errors that don't get caught by just generating the class, but are also more informative than the default VerifyError you would get from loading an invalid class.

Classfile API does have some sort of error reporting mechanism in verification; at least it tracks the error context.
https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/src/java.base/share/classes/jdk/internal/classfile/impl/verifier/VerifierImpl.java#L1810-L1828
The method dumping is providing a yaml tree representation of the class file to the provided Consumer, and the VerifyError itself already includes the error context. What exact specific information are you looking for that's provided by ASM? We might be able to add it to Classfile API too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13247#discussion_r1153954352

From liach at openjdk.org  Fri Mar 31 02:48:15 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 31 Mar 2023 02:48:15 GMT
Subject: RFR: 8304928: Optimize ClassDesc.resolveConstantDesc [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 31 Mar 2023 02:27:05 GMT, Chen Liang  wrote:

>> This patch optimizes ClassDesc.resolveConstantDesc for array classes. Otherwise, the performance of reference class resolution remain unchanged.
>> 
>> A benchmark comparing resolution for reference arrays, primitive arrays, and class or interfaces is included in this patch, and the result comparison on my machine is available at https://jmh.morethan.io/?gists=21c462f4879f6166b3308a41c092d51e,1aeae6ff40a129f89dbfedcb874cfd37
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update per review, will post new benchmark results

If you don't mind, please also check out #12986, which avoids casting the result to `Class` after calling `ClassDesc::resolveConstantDesc`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13252#issuecomment-1491215447

From xgong at openjdk.org  Fri Mar 31 03:13:22 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Fri, 31 Mar 2023 03:13:22 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 30 Mar 2023 14:30:17 GMT, Quan Anh Mai  wrote:

>> Hi,
>> 
>> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, VectorShuffle is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
>> 
>> 1. Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
>> 2. Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
>> 3. Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
>> 4. Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
>> 
>> Upon these changes, a `rearrange` can emit more efficient code:
>> 
>>     var species = IntVector.SPECIES_128;
>>     var v1 = IntVector.fromArray(species, SRC1, 0);
>>     var v2 = IntVector.fromArray(species, SRC2, 0);
>>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
>> 
>>     Before:
>>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>>     vmovdqu 0x10(%r10),%xmm0
>>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byte_mask
>>                                                             ;   {external_word}
>>     vpackusdw %xmm0,%xmm0,%xmm0
>>     vpackuswb %xmm0,%xmm0,%xmm0
>>     vpmovsxbd %xmm0,%xmm3
>>     vpcmpgtd %xmm3,%xmm1,%xmm3
>>     vtestps %xmm3,%xmm3
>>     jne    0x00007fc2acb4e0d8
>>     vpmovzxbd %xmm0,%xmm0
>>     vpermd %ymm2,%ymm0,%ymm0
>>     movabs $0x751588f98,%r10            ;   {oop([I{0x0000000751588f98})}
>>     vmovdqu %xmm0,0x10(%r10)
>> 
>>     After:
>>     movabs $0x751589c78,%r10            ;   {oop([I{0x0000000751589c78})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158ac88,%r10            ;   {oop([I{0x000000075158ac88})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     vpxor  %xmm0,%xmm0,%xmm0
>>     vpcmpgtd %xmm2,%xmm0,%xmm3
>>     vtestps %xmm3,%xmm3
>>     jne    0x00007fa818b27cb1
>>     vpermd %ymm1,%ymm2,%ymm0
>>     movabs $0x751588c68,%r10            ;   {oop([I{0x0000000751588c68})}
>>     vmovdqu %xmm0,0x10(%r10)
>>     
>> Please take a look and leave reviews. Thanks a lot.
>
> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - move implementations up
>  - Merge branch 'master' into shufflerefactor
>  - Merge branch 'master' into shufflerefactor
>  - reviews
>  - missing casts
>  - clean up
>  - fix Matcher::vector_needs_load_shuffle
>  - fix internal types, clean up
>  - optimise laneIsValid
>  - Merge branch 'master' into shufflerefactor
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/d063b896...a4835c00

Vector API tests pass on AArch64 platforms (NEON & SVE). So looks good to me! Please do not forget to update the copyright for two additional touched files `AbstractSpecies.java` and `VectorSpecies.java`. Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13093#issuecomment-1491229216

From jvernee at openjdk.org  Fri Mar 31 03:27:18 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 31 Mar 2023 03:27:18 GMT
Subject: RFR: 8301703: java.base
 jdk.internal.foreign.abi.BindingSpecializer uses ASM to generate classes [v2]
In-Reply-To: 
References: 
 
 
 
 
 
 
Message-ID: 

On Fri, 31 Mar 2023 02:34:26 GMT, Chen Liang  wrote:

>> Just to clarify: I'm looking for the kind of errors that don't get caught by just generating the class, but are also more informative than the default VerifyError you would get from loading an invalid class.
>
> Classfile API does have some sort of error reporting mechanism in verification; at least it tracks the error context.
> https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/src/java.base/share/classes/jdk/internal/classfile/impl/verifier/VerifierImpl.java#L1810-L1828
> The method dumping is providing a yaml tree representation of the class file to the provided Consumer, and the VerifyError itself already includes the error context. What exact specific information are you looking for that's provided by ASM? We might be able to add it to Classfile API too.

I'm not really looking for anything specific. I'm just trying to figure out if it's worth it to keep the `PERFORM_VERIFICATION` flag, and change it to call the verifier in the new impl. i.e. does it catch more errors than just generating and loading the class would (or does it output the errors in a better format).

I had a brief look at the implementation, and it seems that the consumer is for detailed logging of the verification process. I think in this case we're just interested in catching errors.

I already tried switching the code to call `Classfile.parse(newBytes).verify(null).forEach(System.err::println)`, but the error I artificially introduced was already being caught during class generation. So I'm wondering if having a separate verification pass will actually catch any additional errors.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13247#discussion_r1153974112

From mchung at openjdk.org  Fri Mar 31 04:11:15 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 31 Mar 2023 04:11:15 GMT
Subject: RFR: 8304928: Optimize ClassDesc.resolveConstantDesc
In-Reply-To: <_Bmnm22i03DzNombB2Ahl8ITc0n_83YGamGlaM-7190=.67a466f3-88ad-40a6-9e64-df8994af54a2@github.com>
References: 
 <_Bmnm22i03DzNombB2Ahl8ITc0n_83YGamGlaM-7190=.67a466f3-88ad-40a6-9e64-df8994af54a2@github.com>
Message-ID: <_La1OqzDi7ESy59VNdXP8vjt4jIdbPTYYqxYM4bUAA4=.dc2ce888-3fa1-47d8-9449-c58d323444ee@github.com>

On Fri, 31 Mar 2023 02:22:55 GMT, Chen Liang  wrote:

> The `isPrimitiveArray` check is converted to a private method in `ReferenceClassDesc` as it applies only to reference type descriptor strings. Also included the rationale for not checking initial `[` in a comment.

This would work.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13252#issuecomment-1491258547

From mchung at openjdk.org  Fri Mar 31 04:11:14 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 31 Mar 2023 04:11:14 GMT
Subject: RFR: 8304928: Optimize ClassDesc.resolveConstantDesc [v2]
In-Reply-To: 
References: 
 
Message-ID: <4wqVczYT8O-PAqtd9j2Wl5dnZGQQiw41pEjjCk8q8II=.81ed9af9-81a9-4030-a1eb-6a03bb36531d@github.com>

On Fri, 31 Mar 2023 02:27:05 GMT, Chen Liang  wrote:

>> This patch optimizes ClassDesc.resolveConstantDesc for array classes. Otherwise, the performance of reference class resolution remain unchanged.
>> 
>> A benchmark comparing resolution for reference arrays, primitive arrays, and class or interfaces is included in this patch, and the result comparison on my machine is available at https://jmh.morethan.io/?gists=21c462f4879f6166b3308a41c092d51e,1aeae6ff40a129f89dbfedcb874cfd37
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update per review, will post new benchmark results

Looks good.  The new benchmark is cleaner.

-------------

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13252#pullrequestreview-1366221429

From mchung at openjdk.org  Fri Mar 31 04:18:14 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 31 Mar 2023 04:18:14 GMT
Subject: RFR: 8303930: Fix ConstantUtils.skipOverFieldSignature void case
 return value [v4]
In-Reply-To: <2Rs6gOAbhpxgEr3NK0LeS9j6CMgDJn4zJ1cGEntyMUQ=.07658740-ec26-46d8-9c06-e1b081d536db@github.com>
References: 
 <2Rs6gOAbhpxgEr3NK0LeS9j6CMgDJn4zJ1cGEntyMUQ=.07658740-ec26-46d8-9c06-e1b081d536db@github.com>
Message-ID: 

On Fri, 31 Mar 2023 02:28:31 GMT, Chen Liang  wrote:

>> This typo doesn't allow creation of malformed ClassDesc or MethodTypeDesc, but it produces an erroneous exception on certain inputs. Running `java.lang.constant.MethodTypeDesc.ofDescriptor("(IIIII[[[V)I")` in Jshell 19.0.2 throws StringIndexOutOfBoundsException, and throws IllegalArgumentException in the Jshell for this patch.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/java/lang/constant/boottest/java.base/java/lang/constant/ConstantUtilsTest.java
>   
>   Co-authored-by: Mandy Chung 

Marked as reviewed by mchung (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/12964#pullrequestreview-1366225073

From darcy at openjdk.org  Fri Mar 31 04:35:15 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 31 Mar 2023 04:35:15 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v2]
In-Reply-To: <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
References: 
 <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
Message-ID: 

On Thu, 30 Mar 2023 20:45:08 GMT, Jonathan Gibbons  wrote:

>> Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.
>> 
>> This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.
>> 
>> While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.
>> 
>> It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]
>> 
>> [here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
>> [disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review feedback

Good to see these changes.

-------------

Marked as reviewed by darcy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13248#pullrequestreview-1366237224

From jwaters at openjdk.org  Fri Mar 31 05:57:01 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 31 Mar 2023 05:57:01 GMT
Subject: RFR: 8304717: Declaration aliasing between boolean and jboolean is
 wrong [v3]
In-Reply-To: <9Xij1FEbLnMYTPIZOOhGyaKnlplxP6Wp3ODS2bKP7u0=.146017ce-32ee-40f3-8496-49c014f7decb@github.com>
References: <9Xij1FEbLnMYTPIZOOhGyaKnlplxP6Wp3ODS2bKP7u0=.146017ce-32ee-40f3-8496-49c014f7decb@github.com>
Message-ID: 

> A couple of spots wrongly refer to boolean and jboolean as the same thing. While this does still compile thanks to a happy accident and implicit conversions, they are not the same at all, and should be fixed before a future compiler error happens if their declarations are touched

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Explicit conversion to jboolean

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13139/files
  - new: https://git.openjdk.org/jdk/pull/13139/files/3f9da8b6..362cf3ed

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13139&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13139&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13139.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13139/head:pull/13139

PR: https://git.openjdk.org/jdk/pull/13139

From jwaters at openjdk.org  Fri Mar 31 05:57:04 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 31 Mar 2023 05:57:04 GMT
Subject: RFR: 8304717: Declaration aliasing between boolean and jboolean is
 wrong [v3]
In-Reply-To: 
References: <9Xij1FEbLnMYTPIZOOhGyaKnlplxP6Wp3ODS2bKP7u0=.146017ce-32ee-40f3-8496-49c014f7decb@github.com>
 
 
Message-ID: 

On Fri, 24 Mar 2023 03:02:47 GMT, David Holmes  wrote:

>> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Explicit conversion to jboolean
>
> src/java.prefs/macosx/native/libprefs/MacOSXPreferencesFile.m line 685:
> 
>> 683:     CFStringRef topKey;
>> 684:     CFMutableDictionaryRef topValue;
>> 685:     Boolean beforeAdd = false;
> 
> The return value from `CFDictionaryContainsKey` is a Boolean and is assigned to this variable. So I think these changes are the wrong way round. Keep this as a Boolean but convert the return value to jboolean:
> 
> return beforeAdd ? JNI_TRUE : JNI_FALSE;

Argh, looks like Apple and Objective-C still use the ancient Boolean types from Carbon for the CoreFoundation APIs. Sigh...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13139#discussion_r1154042130

From jwaters at openjdk.org  Fri Mar 31 06:16:17 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 31 Mar 2023 06:16:17 GMT
Subject: RFR: 8305341: Alignment outside of HotSpot should be enforced by
 alignas instead of compiler specific attributes
Message-ID: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com>

C11 has been stable for a long time on all platforms, so native code can use the standard alignas operator for alignment requirements

-------------

Commit messages:
 - 
 - GSSLibStub.c
 - ArrayReferenceImpl.c
 - Alignment outside of HotSpot should be enforced by alignas instead of compiler specific attributes

Changes: https://git.openjdk.org/jdk/pull/13258/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13258&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305341
  Stats: 12 lines in 3 files changed: 3 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/13258.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13258/head:pull/13258

PR: https://git.openjdk.org/jdk/pull/13258

From dholmes at openjdk.org  Fri Mar 31 06:36:18 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 31 Mar 2023 06:36:18 GMT
Subject: RFR: 8304717: Declaration aliasing between boolean and jboolean is
 wrong [v3]
In-Reply-To: 
References: <9Xij1FEbLnMYTPIZOOhGyaKnlplxP6Wp3ODS2bKP7u0=.146017ce-32ee-40f3-8496-49c014f7decb@github.com>
 
Message-ID: 

On Fri, 31 Mar 2023 05:57:01 GMT, Julian Waters  wrote:

>> A couple of spots wrongly refer to boolean and jboolean as the same thing. While this does still compile thanks to a happy accident and implicit conversions, they are not the same at all, and should be fixed before a future compiler error happens if their declarations are touched
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Explicit conversion to jboolean

Changes requested by dholmes (Reviewer).

src/java.prefs/macosx/native/libprefs/MacOSXPreferencesFile.m line 698:

> 696:     CFDictionaryAddValue(parent, child, node);
> 697:     if (!beforeAdd)
> 698:         beforeAdd = CFDictionaryContainsKey(parent, child) ? JNI_TRUE : JNI_FALSE;

If you do this here you need something similar on line 695. Still say it is simpler to use Boolean internally and convert to jboolean on return expression.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13139#pullrequestreview-1366328929
PR Review Comment: https://git.openjdk.org/jdk/pull/13139#discussion_r1154068780

From alanb at openjdk.org  Fri Mar 31 10:26:17 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 31 Mar 2023 10:26:17 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v2]
In-Reply-To: <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
References: 
 <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
Message-ID: 

On Thu, 30 Mar 2023 20:45:08 GMT, Jonathan Gibbons  wrote:

>> Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.
>> 
>> This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.
>> 
>> While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.
>> 
>> It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]
>> 
>> [here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
>> [disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review feedback

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13248#pullrequestreview-1366677936

From alanb at openjdk.org  Fri Mar 31 10:26:19 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 31 Mar 2023 10:26:19 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 30 Mar 2023 20:28:52 GMT, Jonathan Gibbons  wrote:

>> src/java.base/share/classes/java/lang/Thread.java line 1960:
>> 
>>> 1958:      *             thread.
>>> 1959:      *
>>> 1960:      * @spec jni/index.html Java Native Interface Specification
>> 
>> The link to the JNI spec in this method is from implNote so I'm wondering if the spec link is needed here.
>
> Right now, the tag is added for any declaration whose comment contains a reference to an external spec (i.e. with ``. 
> 
> When we enable the "External Specifications" page, it will contain a link back to this page as part of the cross-reference info, which seems useful. That being said, if you feel strongly the tag should not be added here, I can remove it.

Leave it in for now and we can look at it again when the external spec page is in place. My comment is mostly that it will look a bit strange to link to this method because it's text in an implNote rather than spec.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13248#discussion_r1154302925

From alanb at openjdk.org  Fri Mar 31 10:29:18 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 31 Mar 2023 10:29:18 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1)
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 30 Mar 2023 20:38:13 GMT, Jonathan Gibbons  wrote:

> The initial assumption was "after the @param/@return/@throws group". Overall, as I said in the description for this PR, the block tags are not very consistent about ordering. I was thinking we might want to recommend an overall ordering, but I'm worried it would be too intrusive a change to apply generally. In the description, I suggested an ordering based on the order in `Docs.gmk` which defines the order in which tags appear in the generated output.

Okay, I think it's just a few of the usages that I sampled had author tags left over from early JDK releases and they end up between the spec and see tags. We can fix these things up at another time.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13248#issuecomment-1491696054

From alanb at openjdk.org  Fri Mar 31 10:31:31 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 31 Mar 2023 10:31:31 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v5]
In-Reply-To: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
Message-ID: 

> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The APIs that were preview APIs in Java 19/20 are changed to permanent and their `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The JNI and JVMTI versions are bumped as this is the first change in 21 to need the new version number. A lot of tests are updated to drop `@enablePreview` and --enable-preview.
> 
> There is one API change from Java 19/20, the preview API Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an update to the JVMTI GetThreadInfo implementation to read the TCCL consistently.
> 
> In addition, there are a small number of implementation changes to sync up from the loom fibers branch:
> 
> - A number of stack frames are `@Hidden` to reduce noise in the stack traces. This exposed a few issues with the stack walker code. More specifically, the cases where  end of a continuation falls precisely at the end of the batch, or where the remaining frames are hidden, weren't handled correctly.
> - The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in Thread rather than in two classes.
> - A few robustness improvements for OOME and SOE. There is more to do here, for future PRs.
> - New system property to print a stack trace when a virtual thread sets its own value of a TL.
> - ThreadPerTaskExecutor is changed to use FutureTask.
> 
> Testing: tier1-6.

Alan Bateman 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 ten additional commits since the last revision:

 - Expand tests for jdk.ThreadSleep event
 - Review feedback
 - Merge
 - Fix ThreadSleepEvent again
 - Test updates
 - ThreadSleepEvent refactoring
 - Merge
 - Merge
 - Initial sync from fibers branch

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13203/files
  - new: https://git.openjdk.org/jdk/pull/13203/files/bfd2c816..722d5afa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13203&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13203&range=03-04

  Stats: 4799 lines in 134 files changed: 3144 ins; 1060 del; 595 mod
  Patch: https://git.openjdk.org/jdk/pull/13203.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13203/head:pull/13203

PR: https://git.openjdk.org/jdk/pull/13203

From lancea at openjdk.org  Fri Mar 31 10:36:17 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 31 Mar 2023 10:36:17 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v2]
In-Reply-To: <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
References: 
 <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
Message-ID: 

On Thu, 30 Mar 2023 20:45:08 GMT, Jonathan Gibbons  wrote:

>> Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.
>> 
>> This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.
>> 
>> While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.
>> 
>> It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]
>> 
>> [here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
>> [disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review feedback

Hi Jon,

This looks fine.  I was wondering if we should do the same for java.util.zip and the PKWare Zip Spec or where java.sql references the JDBC Spec?

-------------

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13248#pullrequestreview-1366691673

From dfuchs at openjdk.org  Fri Mar 31 10:44:17 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 31 Mar 2023 10:44:17 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v2]
In-Reply-To: <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
References: 
 <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
Message-ID: 

On Thu, 30 Mar 2023 20:45:08 GMT, Jonathan Gibbons  wrote:

>> Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.
>> 
>> This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.
>> 
>> While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.
>> 
>> It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]
>> 
>> [here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
>> [disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review feedback

I had a look at the java.net part and it looks reasonable.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13248#pullrequestreview-1366700592

From lancea at openjdk.org  Fri Mar 31 10:48:13 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 31 Mar 2023 10:48:13 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v2]
In-Reply-To: 
References: 
 <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
 
Message-ID: <3S5M70O-gBAryoEdeYdsJPREC-ZAikAMhmhlqdMtrhE=.2b23e947-2137-43d8-b493-ff3837b1025a@github.com>

On Fri, 31 Mar 2023 10:33:50 GMT, Lance Andersen  wrote:

> Hi Jon,
> 
> This looks fine. I was wondering if we should do the same for java.util.zip and the PKWare Zip Spec or where java.sql references the JDBC Spec?

Well, I must need coffee this morning as obviously JDBC is in the java.sql module, not java.base.... So scratch that comment ;-)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13248#issuecomment-1491723581

From mcimadamore at openjdk.org  Fri Mar 31 11:27:29 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 31 Mar 2023 11:27:29 GMT
Subject: RFR: 8301703: java.base
 jdk.internal.foreign.abi.BindingSpecializer uses ASM to generate classes [v2]
In-Reply-To: <6Q49gLo9_qfeWbFCMhWo5PLq4KLyACea2QVw2sGh2vk=.3a63e22a-4243-4003-8cb1-58705a0695f3@github.com>
References: 
 <6Q49gLo9_qfeWbFCMhWo5PLq4KLyACea2QVw2sGh2vk=.3a63e22a-4243-4003-8cb1-58705a0695f3@github.com>
Message-ID: 

On Thu, 30 Mar 2023 19:55:15 GMT, Jorn Vernee  wrote:

>> Rewrite BindingSpecializer to use the new class file API.
>> 
>> Note: There is a big try/catch/finally block generated in the `specialize` method that currently uses labels. I looked at replacing this with a call to `CodeBuilder::trying` but it would require threading the nested code builders through all the `emit*` methods, which currently access the 'global' CodeBuilder instance attached to the BindingSpecializer instance. Since there didn't really seem to be a big benefit to this, I've kept that try/catch/finally block as is, using labels.
>> 
>> The current implementation could also use `CheckClassAdapter` to do additional verification on the generated bytecode (ahead of the VM's verifier). I'm not sure if the new API has a replacement for that?
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use existing MTD_void constant

src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 77:

> 75:     private static final int CLASSFILE_VERSION = ClassFileFormatVersion.latest().major();
> 76: 
> 77:     private static final ClassDesc CD_Arena = desc(Arena.class);

I love that we're able to describe what we need to use at a higher-level of abstraction than just strings.

src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 940:

> 938:     }
> 939: 
> 940:     private void emitInvokeStatic(Class owner, String methodName, String descriptor) {

It is great to see these ad-hoc routines (most of which exist in one form or another in all our JDK code generators) go away!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13247#discussion_r1154357570
PR Review Comment: https://git.openjdk.org/jdk/pull/13247#discussion_r1154357053

From mcimadamore at openjdk.org  Fri Mar 31 11:27:29 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 31 Mar 2023 11:27:29 GMT
Subject: RFR: 8301703: java.base
 jdk.internal.foreign.abi.BindingSpecializer uses ASM to generate classes [v2]
In-Reply-To: 
References: 
 
 
 
 
 
 
 
Message-ID: 

On Fri, 31 Mar 2023 03:24:22 GMT, Jorn Vernee  wrote:

>> Classfile API does have some sort of error reporting mechanism in verification; at least it tracks the error context.
>> https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/src/java.base/share/classes/jdk/internal/classfile/impl/verifier/VerifierImpl.java#L1810-L1828
>> The method dumping is providing a yaml tree representation of the class file to the provided Consumer, and the VerifyError itself already includes the error context. What exact specific information are you looking for that's provided by ASM? We might be able to add it to Classfile API too.
>
> I'm not really looking for anything specific. I'm just trying to figure out if it's worth it to keep the `PERFORM_VERIFICATION` flag, and change it to call the verifier in the new impl. i.e. does it catch more errors than just generating and loading the class would (or does it output the errors in a better format).
> 
> I had a brief look at the implementation, and it seems that the consumer is for detailed logging of the verification process. I think in this case we're just interested in catching errors.
> 
> I already tried switching the code to call `Classfile.parse(newBytes).verify(null).forEach(System.err::println)`, but the error I artificially introduced was already being caught during class generation. So I'm wondering if having a separate verification pass will actually catch any additional errors.

I believe that, in order to generate the actual bytecodes, the classfile API does a full verification pass (as it needs to infer the stackmap information). This leads me to believe that, yes, most (but probably all) errors would be detected simply by generating code. Maybe @asotona can clarify.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13247#discussion_r1154355885

From mcimadamore at openjdk.org  Fri Mar 31 11:52:23 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 31 Mar 2023 11:52:23 GMT
Subject: RFR: 8301703: java.base
 jdk.internal.foreign.abi.BindingSpecializer uses ASM to generate classes [v2]
In-Reply-To: <6Q49gLo9_qfeWbFCMhWo5PLq4KLyACea2QVw2sGh2vk=.3a63e22a-4243-4003-8cb1-58705a0695f3@github.com>
References: 
 <6Q49gLo9_qfeWbFCMhWo5PLq4KLyACea2QVw2sGh2vk=.3a63e22a-4243-4003-8cb1-58705a0695f3@github.com>
Message-ID: 

On Thu, 30 Mar 2023 19:55:15 GMT, Jorn Vernee  wrote:

>> Rewrite BindingSpecializer to use the new class file API.
>> 
>> Note: There is a big try/catch/finally block generated in the `specialize` method that currently uses labels. I looked at replacing this with a call to `CodeBuilder::trying` but it would require threading the nested code builders through all the `emit*` methods, which currently access the 'global' CodeBuilder instance attached to the BindingSpecializer instance. Since there didn't really seem to be a big benefit to this, I've kept that try/catch/finally block as is, using labels.
>> 
>> The current implementation could also use `CheckClassAdapter` to do additional verification on the generated bytecode (ahead of the VM's verifier). I'm not sure if the new API has a replacement for that?
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use existing MTD_void constant

Looks great!

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13247#pullrequestreview-1366791011

From mcimadamore at openjdk.org  Fri Mar 31 12:16:22 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 31 Mar 2023 12:16:22 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v16]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 30 Mar 2023 11:28:25 GMT, Per Minborg  wrote:

>> API changes for the FFM API (third preview)
>> 
>> Specdiff:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
>> 
>> Javadoc:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html
>
> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java
>    
>    Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
>  - Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java
>    
>    Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

The class `jdk/internal/javac/PreviewFeature.java` needs to be updated. It is currently referring JEP 434:


public enum Feature {
        @JEP(number=433, title="Pattern Matching for switch", status="Fourth Preview")
        SWITCH_PATTERN_MATCHING(),
        @JEP(number=432, title="Record Patterns", status="Second Preview")
        RECORD_PATTERNS,
        @JEP(number=436, title="Virtual Threads", status="Second Preview")
        VIRTUAL_THREADS,
        @JEP(number=434, title="Foreign Function & Memory API", status="Second Preview")
        FOREIGN, // <-----------------------------------
        ...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13079#issuecomment-1491836954

From raffaello.giulietti at oracle.com  Fri Mar 31 12:18:06 2023
From: raffaello.giulietti at oracle.com (Raffaello Giulietti)
Date: Fri, 31 Mar 2023 14:18:06 +0200
Subject: Small survey about JDK-8280101: in String.split grouped regex should
 keep the delimiter
Message-ID: 

HI,

JBS issue JDK-8280101 [0] proposes to add functionality to 
String.split() to behave more like the perl equivalent. Rather than 
returning only the substrings resulting from the split, the perl 
implementation can return an alternation of the substrings and the 
matched delimiters when the delimiter pattern is grouped. Because of the 
non-negligible behavioral change this would imply in the JDK 
implementation and the impact on existing client code, it cannot be done 
as proposed by the issue reporter.

However, since implementing the requested behavior outside the JDK is 
rather tricky, it would make sense to add an overload of String.split() 
that returns the result described in the JBS issue, that is, an 
alternation of substrings and delimiters. As a consequence, a similar 
overload would be needed in java.util.regex.Pattern as well, where the 
bulk of the implementation underlying String.split() is located. 
Further, an overload of Pattern.splitStream() is probably needed as 
well. Note that both String and Pattern are final classes, so the 
overloads are safe to add.

As mentioned, the reason to add these overloads to the JDK is because it 
is somehow complicated to implement that behavior outside class Pattern. 
The implementation of the extensions in the JDK, on the contrary, looks 
rather simple. But before preparing a PR and a CSR, I'd like to gather 
more opinions.

WDYT?


Greetings
Raffaello

----

[0] https://bugs.openjdk.org/browse/JDK-8280101

From asotona at openjdk.org  Fri Mar 31 12:23:30 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 31 Mar 2023 12:23:30 GMT
Subject: RFR: 8301703: java.base
 jdk.internal.foreign.abi.BindingSpecializer uses ASM to generate classes [v2]
In-Reply-To: 
References: 
 
 
 
 
 
 
 
 
Message-ID: 

On Fri, 31 Mar 2023 11:22:46 GMT, Maurizio Cimadamore  wrote:

>> I'm not really looking for anything specific. I'm just trying to figure out if it's worth it to keep the `PERFORM_VERIFICATION` flag, and change it to call the verifier in the new impl. i.e. does it catch more errors than just generating and loading the class would (or does it output the errors in a better format).
>> 
>> I had a brief look at the implementation, and it seems that the consumer is for detailed logging of the verification process. I think in this case we're just interested in catching errors.
>> 
>> I already tried switching the code to call `Classfile.parse(newBytes).verify(null).forEach(System.err::println)`, but the error I artificially introduced was already being caught during class generation. So I'm wondering if having a separate verification pass will actually catch any additional errors.
>
> I believe that, in order to generate the actual bytecodes, the classfile API does a full verification pass (as it needs to infer the stackmap information). This leads me to believe that, yes, most (but probably all) errors would be detected simply by generating code. Maybe @asotona can clarify.

Stackmap generator does not perform full verification, it only performs fast pass through the code and hits only errors preventing to construct valid stack maps (as for example stack underflow).
Verifyier on the other hand does full verification similar to when the class is loaded.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13247#discussion_r1154408706

From qamai at openjdk.org  Fri Mar 31 12:25:16 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 31 Mar 2023 12:25:16 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v6]
In-Reply-To: 
References: 
Message-ID: 

> Hi,
> 
> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, VectorShuffle is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
> 
> 1. Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
> 2. Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
> 3. Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
> 4. Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
> 
> Upon these changes, a `rearrange` can emit more efficient code:
> 
>     var species = IntVector.SPECIES_128;
>     var v1 = IntVector.fromArray(species, SRC1, 0);
>     var v2 = IntVector.fromArray(species, SRC2, 0);
>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
> 
>     Before:
>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>     vmovdqu 0x10(%r10),%xmm2
>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>     vmovdqu 0x10(%r10),%xmm1
>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>     vmovdqu 0x10(%r10),%xmm0
>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byte_mask
>                                                             ;   {external_word}
>     vpackusdw %xmm0,%xmm0,%xmm0
>     vpackuswb %xmm0,%xmm0,%xmm0
>     vpmovsxbd %xmm0,%xmm3
>     vpcmpgtd %xmm3,%xmm1,%xmm3
>     vtestps %xmm3,%xmm3
>     jne    0x00007fc2acb4e0d8
>     vpmovzxbd %xmm0,%xmm0
>     vpermd %ymm2,%ymm0,%ymm0
>     movabs $0x751588f98,%r10            ;   {oop([I{0x0000000751588f98})}
>     vmovdqu %xmm0,0x10(%r10)
> 
>     After:
>     movabs $0x751589c78,%r10            ;   {oop([I{0x0000000751589c78})}
>     vmovdqu 0x10(%r10),%xmm1
>     movabs $0x75158ac88,%r10            ;   {oop([I{0x000000075158ac88})}
>     vmovdqu 0x10(%r10),%xmm2
>     vpxor  %xmm0,%xmm0,%xmm0
>     vpcmpgtd %xmm2,%xmm0,%xmm3
>     vtestps %xmm3,%xmm3
>     jne    0x00007fa818b27cb1
>     vpermd %ymm1,%ymm2,%ymm0
>     movabs $0x751588c68,%r10            ;   {oop([I{0x0000000751588c68})}
>     vmovdqu %xmm0,0x10(%r10)
>     
> Please take a look and leave reviews. Thanks a lot.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  small cosmetics

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13093/files
  - new: https://git.openjdk.org/jdk/pull/13093/files/a4835c00..97c8fabf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13093&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13093&range=04-05

  Stats: 6 lines in 4 files changed: 1 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/13093.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13093/head:pull/13093

PR: https://git.openjdk.org/jdk/pull/13093

From qamai at openjdk.org  Fri Mar 31 12:25:18 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 31 Mar 2023 12:25:18 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Tue, 21 Mar 2023 16:29:44 GMT, Paul Sandoz  wrote:

>> I have moved most of the methods to `AbstractVector` and `AbstractShuffle`, I have to resort to raw types, though, since there seems to be no way to do the same with wild cards, and the generics mechanism is not powerful enough for things like `Vector`. The remaining failure seems to be related to [JDK-8304676](https://bugs.openjdk.org/projects/JDK/issues/JDK-8304676), so I think this patch is ready for review now.
>> 
>>> The mask implementation is specialized by the species of vectors it operates on, but does it have to be
>> 
>> Apart from the mask implementation, shuffle implementation definitely has to take into consideration the element type. However, this information does not have to be visible to the API, similar to how we currently handle the vector length, we can have `class AbstractMask implements VectorMask`. As a result, the cast method would be useless and can be removed in the API, but our implementation details would still use it, for example
>> 
>>     Vector blend(Vector v, VectorMask w) {
>>         AbstractMask aw = (AbstractMask) w;
>>         AbstractMask tw = aw.cast(vspecies());
>>         return VectorSupport.blend(...);
>>     }
>> 
>>     Vector rearrange(VectorShuffle s) {
>>         AbstractShuffle as = (AbstractShuffle) s;
>>         AbstractShuffle ts = s.cast(vspecies());
>>         return VectorSupport.rearrangeOp(...);
>>     }
>> 
>> What do you think?
>
>> Apart from the mask implementation, shuffle implementation definitely has to take into consideration the element type.
> 
> Yes, the way you have implemented shuffle is tightly connected, that looks ok.
> 
> I am wondering if we can make the mask implementation more loosely coupled and modified such that it does not have to take into consideration the element type (or species) of the vector it operates on, and instead compatibility is based solely on the lane count.
> 
> Ideally it would be good to change the `VectorMask::check` method to just compare the lanes counts and not require a cast in the implementation, which i presume requires some deeper changes in C2?
> 
> What you propose seems a possible a interim step towards a more preferable API, if the performance is good.

Thanks @PaulSandoz and @XiaohongGong for the reviews and testings.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13093#issuecomment-1491844652

From qamai at openjdk.org  Fri Mar 31 12:25:24 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 31 Mar 2023 12:25:24 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v5]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 31 Mar 2023 00:18:21 GMT, Paul Sandoz  wrote:

>> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
>> 
>>  - move implementations up
>>  - Merge branch 'master' into shufflerefactor
>>  - Merge branch 'master' into shufflerefactor
>>  - reviews
>>  - missing casts
>>  - clean up
>>  - fix Matcher::vector_needs_load_shuffle
>>  - fix internal types, clean up
>>  - optimise laneIsValid
>>  - Merge branch 'master' into shufflerefactor
>>  - ... and 4 more: https://git.openjdk.org/jdk/compare/d063b896...a4835c00
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-VectorBits.java.template line 1106:
> 
>> 1104:         @Override
>> 1105:         @ForceInline
>> 1106:         public int laneSource(int i) {
> 
> Can this method be moved to `AbstractShuffle`?

No because `T lane(int)` is a method of the typed vector classes which is not available in `AbstractVector`

> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-VectorBits.java.template line 1158:
> 
>> 1156:         }
>> 1157: 
>> 1158:         private static $bitstype$[] prepare(int[] indices, int offset) {
> 
> If we want to reduce code duplication further I suspect we could move these static methods to IntVector etc. Up to you.

I think duplication of generated code is less of a concern so it may be more desirable to keep them in the shuffle classes and near their usages.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1154405710
PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1154407372

From james.laskey at oracle.com  Fri Mar 31 12:47:43 2023
From: james.laskey at oracle.com (Jim Laskey)
Date: Fri, 31 Mar 2023 12:47:43 +0000
Subject: Small survey about JDK-8280101: in String.split grouped regex
 should keep the delimiter
In-Reply-To: 
References: 
Message-ID: <04E0F19F-C491-4F4B-ADAF-743FA9472AF2@oracle.com>

[IMHO] I think you?ll find that split isn?t everyone?s favourite method for lots of reasons. For example, more often than not I would like to have split guarantee N + 1 elements in the result, where N is the number delimiters found. Case 1: text blocks split on newlines. Case 2: string templates split on embedded expressions. The problem with split (as I see it) is that when the last delimiter is at the end of the string, then the result contains N elements. There are use cases where this is useful, just not my cases.

What you are describing is beyond split and best done by something else, more in the parsing domain, maybe even a new method ?cleave?.

Cheers,

? Jim


> On Mar 31, 2023, at 9:18 AM, Raffaello Giulietti  wrote:
> 
> HI,
> 
> JBS issue JDK-8280101 [0] proposes to add functionality to String.split() to behave more like the perl equivalent. Rather than returning only the substrings resulting from the split, the perl implementation can return an alternation of the substrings and the matched delimiters when the delimiter pattern is grouped. Because of the non-negligible behavioral change this would imply in the JDK implementation and the impact on existing client code, it cannot be done as proposed by the issue reporter.
> 
> However, since implementing the requested behavior outside the JDK is rather tricky, it would make sense to add an overload of String.split() that returns the result described in the JBS issue, that is, an alternation of substrings and delimiters. As a consequence, a similar overload would be needed in java.util.regex.Pattern as well, where the bulk of the implementation underlying String.split() is located. Further, an overload of Pattern.splitStream() is probably needed as well. Note that both String and Pattern are final classes, so the overloads are safe to add.
> 
> As mentioned, the reason to add these overloads to the JDK is because it is somehow complicated to implement that behavior outside class Pattern. The implementation of the extensions in the JDK, on the contrary, looks rather simple. But before preparing a PR and a CSR, I'd like to gather more opinions.
> 
> WDYT?
> 
> 
> Greetings
> Raffaello
> 
> ----
> 
> [0] https://bugs.openjdk.org/browse/JDK-8280101


From asotona at openjdk.org  Fri Mar 31 13:12:25 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 31 Mar 2023 13:12:25 GMT
Subject: RFR: 8301703: java.base
 jdk.internal.foreign.abi.BindingSpecializer uses ASM to generate classes [v2]
In-Reply-To: 
References: 
 
 
 
 
 
 
 
 
 
Message-ID: 

On Fri, 31 Mar 2023 12:20:49 GMT, Adam Sotona  wrote:

>> I believe that, in order to generate the actual bytecodes, the classfile API does a full verification pass (as it needs to infer the stackmap information). This leads me to believe that, yes, most (but probably all) errors would be detected simply by generating code. Maybe @asotona can clarify.
>
> Stackmap generator does not perform full verification, it only performs fast pass through the code and hits only errors preventing to construct valid stack maps (as for example stack underflow).
> Verifyier on the other hand does full verification similar to when the class is loaded.

Classfile API allows to pass-through complete class members or attributes, so resulting class might be invalid even the particular code and stack maps have been generated. 

This is brief list of verifications performed when `verify` is explicitly called:
- class version
- signatures
- instruction opcodes
- CP entries matching instructions (matching types, array dimensions limits, etc...)
- stack map frames and assignability between reference types
- flow control (branches, exception handlers, falling through code end, falling through initialised, etc..)
- exception tables (offsets, throwing Throwables, etc...)
- local variable tables 
- switches (low/high, number of keys, etc...)
- method calls (arguments, operands, constructor call target, constructors returning void, etc...)
- return values

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13247#discussion_r1154456627

From raffaello.giulietti at oracle.com  Fri Mar 31 13:20:44 2023
From: raffaello.giulietti at oracle.com (Raffaello Giulietti)
Date: Fri, 31 Mar 2023 15:20:44 +0200
Subject: Small survey about JDK-8280101: in String.split grouped regex
 should keep the delimiter
In-Reply-To: <04E0F19F-C491-4F4B-ADAF-743FA9472AF2@oracle.com>
References: 
 <04E0F19F-C491-4F4B-ADAF-743FA9472AF2@oracle.com>
Message-ID: <9e79ef9a-192b-bc1d-fefd-e7600c32d6db@oracle.com>

IIUC, Case 1 could be covered already today with split("\\n", -1). That 
returns N+1 substrings when the delimiter occurs N times.

The proposed overload in String would be
     String[] split(String regex, int limit, boolean withDelimiters)
with the existing split(regex, limit) simply invoking split(regex, 
limit, false)



On 2023-03-31 14:47, Jim Laskey wrote:
> [IMHO] I think you?ll find that split isn?t everyone?s favourite method for lots of reasons. For example, more often than not I would like to have split guarantee N + 1 elements in the result, where N is the number delimiters found. Case 1: text blocks split on newlines. Case 2: string templates split on embedded expressions. The problem with split (as I see it) is that when the last delimiter is at the end of the string, then the result contains N elements. There are use cases where this is useful, just not my cases.
> 
> What you are describing is beyond split and best done by something else, more in the parsing domain, maybe even a new method ?cleave?.
> 
> Cheers,
> 
> ? Jim
> 
> 
>> On Mar 31, 2023, at 9:18 AM, Raffaello Giulietti  wrote:
>>
>> HI,
>>
>> JBS issue JDK-8280101 [0] proposes to add functionality to String.split() to behave more like the perl equivalent. Rather than returning only the substrings resulting from the split, the perl implementation can return an alternation of the substrings and the matched delimiters when the delimiter pattern is grouped. Because of the non-negligible behavioral change this would imply in the JDK implementation and the impact on existing client code, it cannot be done as proposed by the issue reporter.
>>
>> However, since implementing the requested behavior outside the JDK is rather tricky, it would make sense to add an overload of String.split() that returns the result described in the JBS issue, that is, an alternation of substrings and delimiters. As a consequence, a similar overload would be needed in java.util.regex.Pattern as well, where the bulk of the implementation underlying String.split() is located. Further, an overload of Pattern.splitStream() is probably needed as well. Note that both String and Pattern are final classes, so the overloads are safe to add.
>>
>> As mentioned, the reason to add these overloads to the JDK is because it is somehow complicated to implement that behavior outside class Pattern. The implementation of the extensions in the JDK, on the contrary, looks rather simple. But before preparing a PR and a CSR, I'd like to gather more opinions.
>>
>> WDYT?
>>
>>
>> Greetings
>> Raffaello
>>
>> ----
>>
>> [0] https://bugs.openjdk.org/browse/JDK-8280101
> 

From james.laskey at oracle.com  Fri Mar 31 13:25:34 2023
From: james.laskey at oracle.com (Jim Laskey)
Date: Fri, 31 Mar 2023 13:25:34 +0000
Subject: Small survey about JDK-8280101: in String.split grouped regex
 should keep the delimiter
In-Reply-To: <9e79ef9a-192b-bc1d-fefd-e7600c32d6db@oracle.com>
References: 
 <04E0F19F-C491-4F4B-ADAF-743FA9472AF2@oracle.com>
 <9e79ef9a-192b-bc1d-fefd-e7600c32d6db@oracle.com>
Message-ID: <3991E3A2-79DF-4763-A6BA-C7EB467710AA@oracle.com>

D?oh - I did not know that. Good idiom to have in your pocket.

> On Mar 31, 2023, at 10:20 AM, Raffaello Giulietti  wrote:
> 
> IIUC, Case 1 could be covered already today with split("\\n", -1). That returns N+1 substrings when the delimiter occurs N times.
> 
> The proposed overload in String would be
>    String[] split(String regex, int limit, boolean withDelimiters)
> with the existing split(regex, limit) simply invoking split(regex, limit, false)
> 
> 
> 
> On 2023-03-31 14:47, Jim Laskey wrote:
>> [IMHO] I think you?ll find that split isn?t everyone?s favourite method for lots of reasons. For example, more often than not I would like to have split guarantee N + 1 elements in the result, where N is the number delimiters found. Case 1: text blocks split on newlines. Case 2: string templates split on embedded expressions. The problem with split (as I see it) is that when the last delimiter is at the end of the string, then the result contains N elements. There are use cases where this is useful, just not my cases.
>> What you are describing is beyond split and best done by something else, more in the parsing domain, maybe even a new method ?cleave?.
>> Cheers,
>> ? Jim
>>> On Mar 31, 2023, at 9:18 AM, Raffaello Giulietti  wrote:
>>> 
>>> HI,
>>> 
>>> JBS issue JDK-8280101 [0] proposes to add functionality to String.split() to behave more like the perl equivalent. Rather than returning only the substrings resulting from the split, the perl implementation can return an alternation of the substrings and the matched delimiters when the delimiter pattern is grouped. Because of the non-negligible behavioral change this would imply in the JDK implementation and the impact on existing client code, it cannot be done as proposed by the issue reporter.
>>> 
>>> However, since implementing the requested behavior outside the JDK is rather tricky, it would make sense to add an overload of String.split() that returns the result described in the JBS issue, that is, an alternation of substrings and delimiters. As a consequence, a similar overload would be needed in java.util.regex.Pattern as well, where the bulk of the implementation underlying String.split() is located. Further, an overload of Pattern.splitStream() is probably needed as well. Note that both String and Pattern are final classes, so the overloads are safe to add.
>>> 
>>> As mentioned, the reason to add these overloads to the JDK is because it is somehow complicated to implement that behavior outside class Pattern. The implementation of the extensions in the JDK, on the contrary, looks rather simple. But before preparing a PR and a CSR, I'd like to gather more opinions.
>>> 
>>> WDYT?
>>> 
>>> 
>>> Greetings
>>> Raffaello
>>> 
>>> ----
>>> 
>>> [0] https://bugs.openjdk.org/browse/JDK-8280101


From asotona at openjdk.org  Fri Mar 31 13:26:25 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 31 Mar 2023 13:26:25 GMT
Subject: RFR: 8301703: java.base
 jdk.internal.foreign.abi.BindingSpecializer uses ASM to generate classes [v2]
In-Reply-To: <6Q49gLo9_qfeWbFCMhWo5PLq4KLyACea2QVw2sGh2vk=.3a63e22a-4243-4003-8cb1-58705a0695f3@github.com>
References: 
 <6Q49gLo9_qfeWbFCMhWo5PLq4KLyACea2QVw2sGh2vk=.3a63e22a-4243-4003-8cb1-58705a0695f3@github.com>
Message-ID: 

On Thu, 30 Mar 2023 19:55:15 GMT, Jorn Vernee  wrote:

>> Rewrite BindingSpecializer to use the new class file API.
>> 
>> Note: There is a big try/catch/finally block generated in the `specialize` method that currently uses labels. I looked at replacing this with a call to `CodeBuilder::trying` but it would require threading the nested code builders through all the `emit*` methods, which currently access the 'global' CodeBuilder instance attached to the BindingSpecializer instance. Since there didn't really seem to be a big benefit to this, I've kept that try/catch/finally block as is, using labels.
>> 
>> The current implementation could also use `CheckClassAdapter` to do additional verification on the generated bytecode (ahead of the VM's verifier). I'm not sure if the new API has a replacement for that?
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use existing MTD_void constant

It looks good. I would only consider keeping the PERFORM_VERIFICATION option.

-------------

Marked as reviewed by asotona (Committer).

PR Review: https://git.openjdk.org/jdk/pull/13247#pullrequestreview-1366935438

From duke at openjdk.org  Fri Mar 31 13:51:22 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 31 Mar 2023 13:51:22 GMT
Subject: RFR: 8304014: Convert
 test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java to junit [v5]
In-Reply-To: 
References: 
Message-ID: 

> CorruptedZipFiles could benefit from some spring cleaning and a conversion to testNG:
> 
> - The actual tests are moved into their own `@Test` methods, given more meaningful names and a Javadoc comment explaining the constraint being verified
> - The setup code is moved to a `@Before` method, slightly modernized and rewritten to take advantage of `assertEquals` 
> - `checkZipExceptionImpl` is updated to take advantage of `expectThrows`
> - A bunch of constants copied over from `ZipFile` can be deleted since JDK-6225935 has long been fixed

Eirik Bjorsnos has updated the pull request incrementally with four additional commits since the last revision:

 - Document the structure of the 'good' ZIP
 - Use the "Validate that.." comment style
 - Document the ByteBuffer with a comment
 - Use ByteBuffer when manipulating multi-byte fields

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12563/files
  - new: https://git.openjdk.org/jdk/pull/12563/files/01c25e84..e32052f1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12563&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12563&range=03-04

  Stats: 113 lines in 1 file changed: 74 ins; 5 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/12563.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12563/head:pull/12563

PR: https://git.openjdk.org/jdk/pull/12563

From roger.riggs at oracle.com  Fri Mar 31 13:53:37 2023
From: roger.riggs at oracle.com (Roger Riggs)
Date: Fri, 31 Mar 2023 09:53:37 -0400
Subject: Small survey about JDK-8280101: in String.split grouped regex
 should keep the delimiter
In-Reply-To: 
References: 
Message-ID: 

Hi Raffaello,

It sounds useful to return the delimiters in a new API.
It might be interesting to guarantee the array returns n strings and n-1 
delimiters; filling with an empty string at the beginning and end if the 
input starts with or ends with a delimiter.
Similar to the construction of TemplatedStrings (JDP 430) that has a 
predictable number of strings (n+1) and expression values (n).

An overload of Pattern.splitStream() that alternates would be hard to 
use since in the stream, it would be hard to distinguish between the 
delimiters and the strings. Someday, there might be support in streams 
for grouping.

Regards, Roger




On 3/31/23 8:18 AM, Raffaello Giulietti wrote:
> HI,
>
> JBS issue JDK-8280101 [0] proposes to add functionality to 
> String.split() to behave more like the perl equivalent. Rather than 
> returning only the substrings resulting from the split, the perl 
> implementation can return an alternation of the substrings and the 
> matched delimiters when the delimiter pattern is grouped. Because of 
> the non-negligible behavioral change this would imply in the JDK 
> implementation and the impact on existing client code, it cannot be 
> done as proposed by the issue reporter.
>
> However, since implementing the requested behavior outside the JDK is 
> rather tricky, it would make sense to add an overload of 
> String.split() that returns the result described in the JBS issue, 
> that is, an alternation of substrings and delimiters. As a 
> consequence, a similar overload would be needed in 
> java.util.regex.Pattern as well, where the bulk of the implementation 
> underlying String.split() is located. Further, an overload of 
> Pattern.splitStream() is probably needed as well. Note that both 
> String and Pattern are final classes, so the overloads are safe to add.
>
> As mentioned, the reason to add these overloads to the JDK is because 
> it is somehow complicated to implement that behavior outside class 
> Pattern. The implementation of the extensions in the JDK, on the 
> contrary, looks rather simple. But before preparing a PR and a CSR, 
> I'd like to gather more opinions.
>
> WDYT?
>
>
> Greetings
> Raffaello
>
> ----
>
> [0] https://bugs.openjdk.org/browse/JDK-8280101


From duke at openjdk.org  Fri Mar 31 13:54:19 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 31 Mar 2023 13:54:19 GMT
Subject: RFR: 8304014: Convert
 test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java to junit [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 31 Mar 2023 13:51:22 GMT, Eirik Bjorsnos  wrote:

>> CorruptedZipFiles could benefit from some spring cleaning and a conversion to testNG:
>> 
>> - The actual tests are moved into their own `@Test` methods, given more meaningful names and a Javadoc comment explaining the constraint being verified
>> - The setup code is moved to a `@Before` method, slightly modernized and rewritten to take advantage of `assertEquals` 
>> - `checkZipExceptionImpl` is updated to take advantage of `expectThrows`
>> - A bunch of constants copied over from `ZipFile` can be deleted since JDK-6225935 has long been fixed
>
> Eirik Bjorsnos has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Document the structure of the 'good' ZIP
>  - Use the "Validate that.." comment style
>  - Document the ByteBuffer with a comment
>  - Use ByteBuffer when manipulating multi-byte fields

Following an offline discussion with Lance, I added the following improvements:

- Use a little-endian ByteBuffer to manipulate multi-byte fields (Manipulating single bytes seemed too 'magic')
- Document the structure of the 'good' ZIP by including the `zipdetails`. (Maintainers should not be expected to know every detail of the ZIP format)
- Use the 'Validate that a ZipException is thrown..' comment style consistently (Easier to read)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12563#issuecomment-1491958480

From duke at openjdk.org  Fri Mar 31 14:01:21 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 31 Mar 2023 14:01:21 GMT
Subject: RFR: 8304014: Convert
 test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java to junit [v5]
In-Reply-To: 
References: 
 
Message-ID: <9IFBGSNH3xvMSJChQkl0yU0n7IllyBUXaB22vkFN4NA=.01f020a0-2d59-4dcf-a357-e83db0b53e13@github.com>

On Fri, 31 Mar 2023 13:51:22 GMT, Eirik Bjorsnos  wrote:

>> CorruptedZipFiles could benefit from some spring cleaning and a conversion to junit:
>> 
>> - The actual tests are moved into their own `@Test` methods, given more meaningful names and a Javadoc comment explaining the constraint being verified
>> - The setup code is moved to a `@Before` method, slightly modernized and rewritten to take advantage of `assertEquals` 
>> - `checkZipExceptionImpl` is updated to take advantage of `assertThrows`
>> - A bunch of constants copied over from `ZipFile` can be deleted since JDK-6225935 has long been fixed
>
> Eirik Bjorsnos has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Document the structure of the 'good' ZIP
>  - Use the "Validate that.." comment style
>  - Document the ByteBuffer with a comment
>  - Use ByteBuffer when manipulating multi-byte fields

@Martin-Buchholz this PR suggests we can improve the `CorruptedZipFiles` test.

Would be interested in hearing if you agree this is an improvement? If not, why?

Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12563#issuecomment-1491967200

From raffaello.giulietti at oracle.com  Fri Mar 31 14:20:27 2023
From: raffaello.giulietti at oracle.com (Raffaello Giulietti)
Date: Fri, 31 Mar 2023 16:20:27 +0200
Subject: Small survey about JDK-8280101: in String.split grouped regex
 should keep the delimiter
In-Reply-To: 
References: 
 
Message-ID: <45960928-c210-893b-7f12-374c4ea5c1e3@oracle.com>

Hi Roger,

I agree that Pattern.splitStream() would be hard use without contextual 
information, so let's drop it from the (still to be written) CSR.

As for the guarantee that the array contains an alternation of n 
substrings and n-1 delimiters, this is what the overload

     String[] split(String regex, int limit, boolean withDelimiters)

is planned to do when passing a negative value as limit.
This is similar to what split(regex,limit) already does today:

"abc".split("\\n", -1) -> String[1] { "abc" }
"\nabc".split("\\n", -1) -> String[2] { "", "abc" }
"abc\n".split("\\n", -1) -> String[2] { "abc", "" }
"\nabc\n".split("\\n", -1) -> String[3] { "", "abc", "" }




On 2023-03-31 15:53, Roger Riggs wrote:
> Hi Raffaello,
> 
> It sounds useful to return the delimiters in a new API.
> It might be interesting to guarantee the array returns n strings and n-1 
> delimiters; filling with an empty string at the beginning and end if the 
> input starts with or ends with a delimiter.
> Similar to the construction of TemplatedStrings (JDP 430) that has a 
> predictable number of strings (n+1) and expression values (n).
> 
> An overload of Pattern.splitStream() that alternates would be hard to 
> use since in the stream, it would be hard to distinguish between the 
> delimiters and the strings. Someday, there might be support in streams 
> for grouping.
> 
> Regards, Roger
> 
> 
> 
> 
> On 3/31/23 8:18 AM, Raffaello Giulietti wrote:
>> HI,
>>
>> JBS issue JDK-8280101 [0] proposes to add functionality to 
>> String.split() to behave more like the perl equivalent. Rather than 
>> returning only the substrings resulting from the split, the perl 
>> implementation can return an alternation of the substrings and the 
>> matched delimiters when the delimiter pattern is grouped. Because of 
>> the non-negligible behavioral change this would imply in the JDK 
>> implementation and the impact on existing client code, it cannot be 
>> done as proposed by the issue reporter.
>>
>> However, since implementing the requested behavior outside the JDK is 
>> rather tricky, it would make sense to add an overload of 
>> String.split() that returns the result described in the JBS issue, 
>> that is, an alternation of substrings and delimiters. As a 
>> consequence, a similar overload would be needed in 
>> java.util.regex.Pattern as well, where the bulk of the implementation 
>> underlying String.split() is located. Further, an overload of 
>> Pattern.splitStream() is probably needed as well. Note that both 
>> String and Pattern are final classes, so the overloads are safe to add.
>>
>> As mentioned, the reason to add these overloads to the JDK is because 
>> it is somehow complicated to implement that behavior outside class 
>> Pattern. The implementation of the extensions in the JDK, on the 
>> contrary, looks rather simple. But before preparing a PR and a CSR, 
>> I'd like to gather more opinions.
>>
>> WDYT?
>>
>>
>> Greetings
>> Raffaello
>>
>> ----
>>
>> [0] https://bugs.openjdk.org/browse/JDK-8280101
> 

From duke at openjdk.org  Fri Mar 31 15:17:16 2023
From: duke at openjdk.org (ExE Boss)
Date: Fri, 31 Mar 2023 15:17:16 GMT
Subject: RFR: 8284871: Use covariant overrides for the
 resolveConstantDesc(Lookup) method in =?UTF-8?B?c3Vi4oCRaW50ZXJmYWNlcw==?= of
 java.lang.constant.ConstantDesc
In-Reply-To: <6elA1YOQCqZutbsRVG89Q0C_5-3zu-OHco8_h2z5mKg=.a313ea66-e58d-401b-88a8-c843dcecf218@github.com>
References: <6elA1YOQCqZutbsRVG89Q0C_5-3zu-OHco8_h2z5mKg=.a313ea66-e58d-401b-88a8-c843dcecf218@github.com>
Message-ID: 

On Sat, 11 Mar 2023 04:59:07 GMT, Chen Liang  wrote:

> Also remove redundant casts to avoid javac warnings.

src/java.base/share/classes/java/lang/constant/MethodTypeDesc.java line 197:

> 195:      * @apiNote {@linkplain MethodTypeDesc} can represent method type descriptors
> 196:      * that are not representable by {@linkplain MethodType}, such as methods with
> 197:      * more than 255 parameter slots, so attempts to resolve these may result in errors.

Should?this also?be?added to?`MethodHandleDesc::resolveConstantDesc(Lookup)`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12986#discussion_r1154601360

From joehw at openjdk.org  Fri Mar 31 15:21:01 2023
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 31 Mar 2023 15:21:01 GMT
Subject: RFR: 8303530: Add system property for custom JAXP configuration
 file [v6]
In-Reply-To: 
References: 
Message-ID: 

> Add a system property, jdk.xml.config.file, to return the path to a custom JAXP configuration file. The current configuration file, jaxp.properties, that the JDK supports will become the default configuration file.
> 
> CSR: https://bugs.openjdk.org/browse/JDK-8303531
> 
> Tests: XML SQE and JCK tests passed.

Joe Wang has updated the pull request incrementally with one additional commit since the last revision:

  continue support stax.properties at the impl level, though dropped from the spec

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12985/files
  - new: https://git.openjdk.org/jdk/pull/12985/files/aa7db3ae..d62f58fd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12985&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12985&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12985.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12985/head:pull/12985

PR: https://git.openjdk.org/jdk/pull/12985

From liach at openjdk.org  Fri Mar 31 15:25:20 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 31 Mar 2023 15:25:20 GMT
Subject: RFR: 8284871: Use covariant overrides for the
 resolveConstantDesc(Lookup) method in =?UTF-8?B?c3Vi4oCRaW50ZXJmYWNlcw==?= of
 java.lang.constant.ConstantDesc
In-Reply-To: 
References: <6elA1YOQCqZutbsRVG89Q0C_5-3zu-OHco8_h2z5mKg=.a313ea66-e58d-401b-88a8-c843dcecf218@github.com>
 
Message-ID: 

On Fri, 31 Mar 2023 15:14:42 GMT, ExE Boss  wrote:

>> Also remove redundant casts to avoid javac warnings.
>
> src/java.base/share/classes/java/lang/constant/MethodTypeDesc.java line 197:
> 
>> 195:      * @apiNote {@linkplain MethodTypeDesc} can represent method type descriptors
>> 196:      * that are not representable by {@linkplain MethodType}, such as methods with
>> 197:      * more than 255 parameter slots, so attempts to resolve these may result in errors.
> 
> Should?this also?be?added to?`MethodHandleDesc::resolveConstantDesc(Lookup)`?

Nah. Since such a MethodTypeDesc is never valid, such a MethodHandleDesc or DynamicConstantDesc should always fail to resolve for such a method handle can never be found. The only problem we need to be concerned about is that the failure in those Descs should be ReflectiveOperationException instead of some sort of UncheckedException (which I think MethodTypeDesc.resolveConstantDesc currently throws), but that belongs to another issue, given currently, MethodTypeDesc even throws unchecked exceptions when it tries to resolve an nonexistent class.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12986#discussion_r1154609525

From rgiulietti at openjdk.org  Fri Mar 31 16:16:16 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 31 Mar 2023 16:16:16 GMT
Subject: RFR: JDK-8304028: Port fdlibm IEEEremainder to Java [v3]
In-Reply-To: <_4MDhzG22C7qUHR9ZXOAGrv52fkDTW0l-s1SaqPLz-U=.1b296196-9242-4438-9cd0-e8edf3bf135c@github.com>
References: 
 <_4MDhzG22C7qUHR9ZXOAGrv52fkDTW0l-s1SaqPLz-U=.1b296196-9242-4438-9cd0-e8edf3bf135c@github.com>
Message-ID: 

On Wed, 29 Mar 2023 04:21:10 GMT, Joe Darcy  wrote:

>> Last but not least, a port of fdlibm IEEEremainder from C to Java. I plan to write some more implementation-specific tests around decision points in the FDLIBM algorithm, but I wanted to get the bulk of the changes out for review first.
>> 
>> Note that since IEEEremainder was the last native method in StrictMath.java, the StrictMath.c file needed to be deleted (or modified) since StrictMath.h was no longer generated as part of the build. (StrictMath.c was one of the file deleted as part of JDK-8302801).
>> 
>> For testing, Mach 5 tier 1 through 3 were successful (other than an unrelated test failure that was problem listed) and the exhaustive test was locally run and passed with "16, 16" to increase the testing density.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Appease jcheck.

Last commit LGTM

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13113#issuecomment-1492211010

From psandoz at openjdk.org  Fri Mar 31 16:24:25 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 31 Mar 2023 16:24:25 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v5]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Fri, 31 Mar 2023 12:17:49 GMT, Quan Anh Mai  wrote:

>> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-VectorBits.java.template line 1106:
>> 
>>> 1104:         @Override
>>> 1105:         @ForceInline
>>> 1106:         public int laneSource(int i) {
>> 
>> Can this method be moved to `AbstractShuffle`?
>
> No because `T lane(int)` is a method of the typed vector classes which is not available in `AbstractVector`

Ah, doh!, yes of course, we would need to specialize the shuffle.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1154671839

From mullan at openjdk.org  Fri Mar 31 16:31:20 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 31 Mar 2023 16:31:20 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v2]
In-Reply-To: <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
References: 
 <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
Message-ID: 

On Thu, 30 Mar 2023 20:45:08 GMT, Jonathan Gibbons  wrote:

>> Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.
>> 
>> This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.
>> 
>> While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.
>> 
>> It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]
>> 
>> [here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
>> [disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review feedback

I didn't see any changes to security APIs - are they coming in a follow-on issue?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13248#issuecomment-1492236091

From jlu at openjdk.org  Fri Mar 31 16:39:17 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 31 Mar 2023 16:39:17 GMT
Subject: RFR: 8225641: Calendar.roll(int field) does not work correctly for
 WEEK_OF_YEAR [v7]
In-Reply-To: 
References: 
Message-ID: 

> This PR fixes the bug which occurred when `Calendar.roll(WEEK_OF_YEAR)` rolled into a minimal first week with an invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo.
> 
> For example, Rolling _Monday, 30 December 2019_ by 1 week produced _Monday, 31 December 2018_, which is incorrect. This is because `WEEK_OF_YEAR` is rolled from 52 to 1, and the original `DAY_OF_WEEK` is 1. However, there is no Monday in week 1 of 2019. This is exposed when a future method calls `Calendar.complete()`, which eventually calculates a `fixedDate` with the invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo.
> 
> To prevent this, a check is added for rolls into week 1, which determines if the first week is minimal. If it is indeed minimal, then it is checked if  `DAY_OF_WEEK` exists in that week, if not, `WEEK_OF_YEAR` must be incremented by one.
> 
> After the fix, Rolling _Monday, 30 December 2019_ by 1 week produces _Monday, 7 January 2019_

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  getFirstDayInWeek() is well checked, so need for exception in dayInMinWeek

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13031/files
  - new: https://git.openjdk.org/jdk/pull/13031/files/7c9291a3..06b90389

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13031&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13031&range=05-06

  Stats: 7 lines in 1 file changed: 0 ins; 7 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13031.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13031/head:pull/13031

PR: https://git.openjdk.org/jdk/pull/13031

From jlu at openjdk.org  Fri Mar 31 16:39:19 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 31 Mar 2023 16:39:19 GMT
Subject: RFR: 8225641: Calendar.roll(int field) does not work correctly for
 WEEK_OF_YEAR [v6]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 30 Mar 2023 23:20:52 GMT, Naoto Sato  wrote:

>> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - dayInMinWeek should range check input and throw exception
>>  - Tweak static cal builder
>
> src/java.base/share/classes/java/util/GregorianCalendar.java line 3025:
> 
>> 3023:         if (endDay > 7 || endDay < 1 || startDay > 7 || startDay < 1) {
>> 3024:             throw new IllegalArgumentException("Start day or end day is not " +
>> 3025:                     "a valid day of the week");
> 
> Sorry, I take my previous comment back. I think we can simply rely on the return value from `getFirstDayOfWeek()` as it is well-checked, so no need to check the input here. Otherwise the thrown IAE woudl have to end up in `add()/roll()` public methods, which cannot be spec'ed with these internal arguments.

No worries, that makes sense. Removed the exception.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13031#discussion_r1154683765

From naoto at openjdk.org  Fri Mar 31 16:48:21 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 31 Mar 2023 16:48:21 GMT
Subject: RFR: 8305113: (tz) Update Timezone Data to 2023c
In-Reply-To: 
References: 
Message-ID: <1VwO7D4lktZKW64DaX6vLHnmPcA9NjjS38Keru9HuC8=.6d236924-f398-4067-9e85-2c739fdd766c@github.com>

On Fri, 31 Mar 2023 00:02:02 GMT, Yoshiki Sato  wrote:

> Pleases review this PR. 
> The PR includes the following changes.
> - tzdata 2023c
> - Hack code to deal with Cairo's DST end, which is same as done in 2014g([JDK-8049343](https://bugs.openjdk.org/browse/JDK-8049343)).  To work around the the limitation of JSR 310 compiler, where the time 24:00 is recognized as 0:00 in the previous day.

Looks good overall. Please fix a couple of editorial errors.

Changes requested by naoto (Reviewer).

src/java.base/share/data/tzdata/antarctica line 1:

> 1:  #

Extra space

src/java.base/share/data/tzdata/northamerica line 1:

> 1: src/java.base/share/data/tzdata/northamerica #

??? copy/paste error?

-------------

Changes requested by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13255#pullrequestreview-1367269723
PR Review: https://git.openjdk.org/jdk/pull/13255#pullrequestreview-1367273595
PR Review Comment: https://git.openjdk.org/jdk/pull/13255#discussion_r1154692139
PR Review Comment: https://git.openjdk.org/jdk/pull/13255#discussion_r1154689466

From psandoz at openjdk.org  Fri Mar 31 17:07:20 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 31 Mar 2023 17:07:20 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Tue, 21 Mar 2023 16:29:44 GMT, Paul Sandoz  wrote:

>> I have moved most of the methods to `AbstractVector` and `AbstractShuffle`, I have to resort to raw types, though, since there seems to be no way to do the same with wild cards, and the generics mechanism is not powerful enough for things like `Vector`. The remaining failure seems to be related to [JDK-8304676](https://bugs.openjdk.org/projects/JDK/issues/JDK-8304676), so I think this patch is ready for review now.
>> 
>>> The mask implementation is specialized by the species of vectors it operates on, but does it have to be
>> 
>> Apart from the mask implementation, shuffle implementation definitely has to take into consideration the element type. However, this information does not have to be visible to the API, similar to how we currently handle the vector length, we can have `class AbstractMask implements VectorMask`. As a result, the cast method would be useless and can be removed in the API, but our implementation details would still use it, for example
>> 
>>     Vector blend(Vector v, VectorMask w) {
>>         AbstractMask aw = (AbstractMask) w;
>>         AbstractMask tw = aw.cast(vspecies());
>>         return VectorSupport.blend(...);
>>     }
>> 
>>     Vector rearrange(VectorShuffle s) {
>>         AbstractShuffle as = (AbstractShuffle) s;
>>         AbstractShuffle ts = s.cast(vspecies());
>>         return VectorSupport.rearrangeOp(...);
>>     }
>> 
>> What do you think?
>
>> Apart from the mask implementation, shuffle implementation definitely has to take into consideration the element type.
> 
> Yes, the way you have implemented shuffle is tightly connected, that looks ok.
> 
> I am wondering if we can make the mask implementation more loosely coupled and modified such that it does not have to take into consideration the element type (or species) of the vector it operates on, and instead compatibility is based solely on the lane count.
> 
> Ideally it would be good to change the `VectorMask::check` method to just compare the lanes counts and not require a cast in the implementation, which i presume requires some deeper changes in C2?
> 
> What you propose seems a possible a interim step towards a more preferable API, if the performance is good.

> Thanks @PaulSandoz and @XiaohongGong for the reviews and testings.

Running tier2/3 tests.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13093#issuecomment-1492274813

From liach at openjdk.org  Fri Mar 31 17:18:25 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 31 Mar 2023 17:18:25 GMT
Subject: Integrated: 8303930: Fix ConstantUtils.skipOverFieldSignature void
 case return value
In-Reply-To: 
References: 
Message-ID: 

On Thu, 9 Mar 2023 23:04:57 GMT, Chen Liang  wrote:

> This typo doesn't allow creation of malformed ClassDesc or MethodTypeDesc, but it produces an erroneous exception on certain inputs. Running `java.lang.constant.MethodTypeDesc.ofDescriptor("(IIIII[[[V)I")` in Jshell 19.0.2 throws StringIndexOutOfBoundsException, and throws IllegalArgumentException in the Jshell for this patch.

This pull request has now been integrated.

Changeset: bdbf8fc6
Author:    Chen Liang 
Committer: Mandy Chung 
URL:       https://git.openjdk.org/jdk/commit/bdbf8fc61d9876ad4aad8f9606384c67005cae78
Stats:     9 lines in 2 files changed: 6 ins; 0 del; 3 mod

8303930: Fix ConstantUtils.skipOverFieldSignature void case return value

Reviewed-by: mchung

-------------

PR: https://git.openjdk.org/jdk/pull/12964

From iris at openjdk.org  Fri Mar 31 17:22:18 2023
From: iris at openjdk.org (Iris Clark)
Date: Fri, 31 Mar 2023 17:22:18 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v2]
In-Reply-To: <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
References: 
 <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
Message-ID: 

On Thu, 30 Mar 2023 20:45:08 GMT, Jonathan Gibbons  wrote:

>> Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.
>> 
>> This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.
>> 
>> While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.
>> 
>> It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]
>> 
>> [here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
>> [disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review feedback

Marked as reviewed by iris (Reviewer).

src/java.base/share/classes/java/io/ObjectOutputStream.java line 165:

> 163:  * @see java.io.Serializable
> 164:  * @see java.io.Externalizable
> 165:  * @since       1.1

Just confirming... The changes to the java.io classes for the Serialization Spec now all point to the index rather than particular chapters/sections. I'm assuming that's intentional so that when the top-level Spec page appears, there is a single entry for that specification.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13248#pullrequestreview-1367309978
PR Review Comment: https://git.openjdk.org/jdk/pull/13248#discussion_r1154716150

From jvernee at openjdk.org  Fri Mar 31 17:23:10 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 31 Mar 2023 17:23:10 GMT
Subject: RFR: 8301703: java.base
 jdk.internal.foreign.abi.BindingSpecializer uses ASM to generate classes [v2]
In-Reply-To: <6Q49gLo9_qfeWbFCMhWo5PLq4KLyACea2QVw2sGh2vk=.3a63e22a-4243-4003-8cb1-58705a0695f3@github.com>
References: 
 <6Q49gLo9_qfeWbFCMhWo5PLq4KLyACea2QVw2sGh2vk=.3a63e22a-4243-4003-8cb1-58705a0695f3@github.com>
Message-ID: <2iQJB5HsSsFaO2x68h8HU8X1sMwF2g4YL-JGXKfhMn0=.7e31ab11-af1a-4ea3-b059-bdf806d18558@github.com>

On Thu, 30 Mar 2023 19:55:15 GMT, Jorn Vernee  wrote:

>> Rewrite BindingSpecializer to use the new class file API.
>> 
>> Note: There is a big try/catch/finally block generated in the `specialize` method that currently uses labels. I looked at replacing this with a call to `CodeBuilder::trying` but it would require threading the nested code builders through all the `emit*` methods, which currently access the 'global' CodeBuilder instance attached to the BindingSpecializer instance. Since there didn't really seem to be a big benefit to this, I've kept that try/catch/finally block as is, using labels.
>> 
>> The current implementation could also use `CheckClassAdapter` to do additional verification on the generated bytecode (ahead of the VM's verifier). I'm not sure if the new API has a replacement for that?
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use existing MTD_void constant

Thanks for the reviews. I've now re-implemented the `PERFORM_VERIFICATION` flag as well, using `ClassModel::verify`. I tested this out by changing around some of the parameter types for certain calls, and it works as expected:

    java.lang.VerifyError: Bad type on operand stack at jdk/internal/foreign/abi/DowncallStub.invoke(Ljava/lang/foreign/SegmentAllocator;Ljava/lang/foreign/MemorySegment;Ljava/lang/foreign/MemorySegment;)V @66 (java/lang/System is not assignable from long2_type)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13247#issuecomment-1492299163

From jvernee at openjdk.org  Fri Mar 31 17:23:07 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 31 Mar 2023 17:23:07 GMT
Subject: RFR: 8301703: java.base
 jdk.internal.foreign.abi.BindingSpecializer uses ASM to generate classes [v3]
In-Reply-To: 
References: 
Message-ID: 

> Rewrite BindingSpecializer to use the new class file API.
> 
> Note: There is a big try/catch/finally block generated in the `specialize` method that currently uses labels. I looked at replacing this with a call to `CodeBuilder::trying` but it would require threading the nested code builders through all the `emit*` methods, which currently access the 'global' CodeBuilder instance attached to the BindingSpecializer instance. Since there didn't really seem to be a big benefit to this, I've kept that try/catch/finally block as is, using labels.
> 
> The current implementation could also use `CheckClassAdapter` to do additional verification on the generated bytecode (ahead of the VM's verifier). I'm not sure if the new API has a replacement for that?

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Re-add PERFORM_VERIFICATION flag

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13247/files
  - new: https://git.openjdk.org/jdk/pull/13247/files/95c8d873..f7fdd2ce

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13247&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13247&range=01-02

  Stats: 11 lines in 1 file changed: 11 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13247.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13247/head:pull/13247

PR: https://git.openjdk.org/jdk/pull/13247

From mchung at openjdk.org  Fri Mar 31 17:25:16 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 31 Mar 2023 17:25:16 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v2]
In-Reply-To: <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
References: 
 <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
Message-ID: 

On Thu, 30 Mar 2023 20:45:08 GMT, Jonathan Gibbons  wrote:

>> Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.
>> 
>> This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.
>> 
>> While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.
>> 
>> It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]
>> 
>> [here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
>> [disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review feedback

LGTM

-------------

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13248#pullrequestreview-1367320601

From naoto at openjdk.org  Fri Mar 31 17:26:19 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 31 Mar 2023 17:26:19 GMT
Subject: RFR: 8225641: Calendar.roll(int field) does not work correctly for
 WEEK_OF_YEAR [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 31 Mar 2023 16:39:17 GMT, Justin Lu  wrote:

>> This PR fixes the bug which occurred when `Calendar.roll(WEEK_OF_YEAR)` rolled into a minimal first week with an invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo.
>> 
>> For example, Rolling _Monday, 30 December 2019_ by 1 week produced _Monday, 31 December 2018_, which is incorrect. This is because `WEEK_OF_YEAR` is rolled from 52 to 1, and the original `DAY_OF_WEEK` is 1. However, there is no Monday in week 1 of 2019. This is exposed when a future method calls `Calendar.complete()`, which eventually calculates a `fixedDate` with the invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo.
>> 
>> To prevent this, a check is added for rolls into week 1, which determines if the first week is minimal. If it is indeed minimal, then it is checked if  `DAY_OF_WEEK` exists in that week, if not, `WEEK_OF_YEAR` must be incremented by one.
>> 
>> After the fix, Rolling _Monday, 30 December 2019_ by 1 week produces _Monday, 7 January 2019_
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   getFirstDayInWeek() is well checked, so need for exception in dayInMinWeek

LGTM

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13031#pullrequestreview-1367321853

From lancea at openjdk.org  Fri Mar 31 17:47:19 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 31 Mar 2023 17:47:19 GMT
Subject: RFR: 8304014: Convert
 test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java to junit [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 31 Mar 2023 13:51:22 GMT, Eirik Bjorsnos  wrote:

>> CorruptedZipFiles could benefit from some spring cleaning and a conversion to junit:
>> 
>> - The actual tests are moved into their own `@Test` methods, given more meaningful names and a Javadoc comment explaining the constraint being verified
>> - The setup code is moved to a `@Before` method, slightly modernized and rewritten to take advantage of `assertEquals` 
>> - `checkZipExceptionImpl` is updated to take advantage of `assertThrows`
>> - A bunch of constants copied over from `ZipFile` can be deleted since JDK-6225935 has long been fixed
>
> Eirik Bjorsnos has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Document the structure of the 'good' ZIP
>  - Use the "Validate that.." comment style
>  - Document the ByteBuffer with a comment
>  - Use ByteBuffer when manipulating multi-byte fields

Thanks for your recent updates Eirik, I think this looks good.

A few minor comment suggestions

I will get a  Mach 5 run done as a sanity check

test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java line 56:

> 54:      * Byte array holding a valid template ZIP.
> 55:      *
> 56:      * This 'good' ZIP file has the following structure:

Change this -> the

test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java line 192:

> 190:     /*
> 191:      * Validate that a ZipException is thrown when the 'End of Central Directory'
> 192:      * (END) header has a CEN offset incoherent with the position calculated

Not sure _incoherent_ is the best term.

      perhaps something along the lines:

header  contains an invalid CEN Directory  starting offset.....

test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java line 203:

> 201:     /*
> 202:      * Validate that a ZipException is thrown when a A CEN header has an unexpected signature
> 203:      */

change  "a A" to "a"

-------------

PR Review: https://git.openjdk.org/jdk/pull/12563#pullrequestreview-1367326652
PR Review Comment: https://git.openjdk.org/jdk/pull/12563#discussion_r1154726957
PR Review Comment: https://git.openjdk.org/jdk/pull/12563#discussion_r1154735421
PR Review Comment: https://git.openjdk.org/jdk/pull/12563#discussion_r1154735787

From liach at openjdk.org  Fri Mar 31 17:49:27 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 31 Mar 2023 17:49:27 GMT
Subject: Integrated: 8304928: Optimize ClassDesc.resolveConstantDesc
In-Reply-To: 
References: 
Message-ID: 

On Thu, 30 Mar 2023 20:06:02 GMT, Chen Liang  wrote:

> This patch optimizes ClassDesc.resolveConstantDesc for array classes. Otherwise, the performance of reference class resolution remain unchanged.
> 
> A benchmark comparing resolution for reference arrays, primitive arrays, and class or interfaces is included in this patch, and the result comparison on my machine is available at https://jmh.morethan.io/?gists=21c462f4879f6166b3308a41c092d51e,1aeae6ff40a129f89dbfedcb874cfd37

This pull request has now been integrated.

Changeset: cccb0191
Author:    Chen Liang 
Committer: Mandy Chung 
URL:       https://git.openjdk.org/jdk/commit/cccb0191a3b18e2155e9202e5b5a694dc100121a
Stats:     95 lines in 2 files changed: 82 ins; 3 del; 10 mod

8304928: Optimize ClassDesc.resolveConstantDesc

Reviewed-by: mchung

-------------

PR: https://git.openjdk.org/jdk/pull/13252

From martin at openjdk.org  Fri Mar 31 18:15:28 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Fri, 31 Mar 2023 18:15:28 GMT
Subject: Integrated: 8297605: improve DelayQueue removal method javadoc
In-Reply-To: 
References: 
Message-ID: 

On Thu, 2 Mar 2023 20:00:56 GMT, Martin Buchholz  wrote:

> Inviting @DougLea and @viktorklang-ora to review.
> 
> As usual, I couldn't resist more fiddling.  
> - Added missing tests for take, remove(), remove(Object).
> - Improved DelayQueueTest's testing infrastructure
> - added more test assertions
> - linkified new javadoc definitions

This pull request has now been integrated.

Changeset: a565be4d
Author:    Martin Buchholz 
URL:       https://git.openjdk.org/jdk/commit/a565be4dc5fa6bbaa92553763caf6f2cc5c2c2a1
Stats:     170 lines in 2 files changed: 114 ins; 9 del; 47 mod

8297605: improve DelayQueue removal method javadoc

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/12838

From jjg at openjdk.org  Fri Mar 31 18:29:17 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 31 Mar 2023 18:29:17 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v2]
In-Reply-To: <3S5M70O-gBAryoEdeYdsJPREC-ZAikAMhmhlqdMtrhE=.2b23e947-2137-43d8-b493-ff3837b1025a@github.com>
References: 
 <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
 
 <3S5M70O-gBAryoEdeYdsJPREC-ZAikAMhmhlqdMtrhE=.2b23e947-2137-43d8-b493-ff3837b1025a@github.com>
Message-ID: 

On Fri, 31 Mar 2023 10:45:39 GMT, Lance Andersen  wrote:

> > Hi Jon,
> > This looks fine. I was wondering if we should do the same for java.util.zip and the PKWare Zip Spec or where java.sql references the JDBC Spec?
> 
> Well, I must need coffee this morning as obviously JDBC is in the java.sql module, not java.base.... So scratch that comment ;-)

The other modules will be done in due course.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13248#issuecomment-1492417414

From jjg at openjdk.org  Fri Mar 31 18:29:20 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 31 Mar 2023 18:29:20 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v2]
In-Reply-To: 
References: 
 <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
 
Message-ID: <8CaBH8YGWfkV6NnZtXfTyDI90ZwzCWFF631EnE6sU0A=.7a4acefb-6b85-4f41-a642-e266ab24363f@github.com>

On Fri, 31 Mar 2023 17:14:01 GMT, Iris Clark  wrote:

>> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   address review feedback
>
> src/java.base/share/classes/java/io/ObjectOutputStream.java line 165:
> 
>> 163:  * @see java.io.Serializable
>> 164:  * @see java.io.Externalizable
>> 165:  * @since       1.1
> 
> Just confirming... The changes to the java.io classes for the Serialization Spec now all point to the index rather than particular chapters/sections. I'm assuming that's intentional so that when the top-level Spec page appears, there is a single entry for that specification.

The `@spec` tag should point to the root, but we should not remove more specific references to within the spec. I will review places where `@see` has been removed/replaced.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13248#discussion_r1154774688

From mchung at openjdk.org  Fri Mar 31 18:39:22 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 31 Mar 2023 18:39:22 GMT
Subject: RFR: 8284871: Use covariant overrides for the
 resolveConstantDesc(Lookup) method in =?UTF-8?B?c3Vi4oCRaW50ZXJmYWNlcw==?= of
 java.lang.constant.ConstantDesc
In-Reply-To: <6elA1YOQCqZutbsRVG89Q0C_5-3zu-OHco8_h2z5mKg=.a313ea66-e58d-401b-88a8-c843dcecf218@github.com>
References: <6elA1YOQCqZutbsRVG89Q0C_5-3zu-OHco8_h2z5mKg=.a313ea66-e58d-401b-88a8-c843dcecf218@github.com>
Message-ID: 

On Sat, 11 Mar 2023 04:59:07 GMT, Chen Liang  wrote:

> Also remove redundant casts to avoid javac warnings.

Looks fine.  This is a good change.

It'd be good to update the `java.lang.constant` tests

-------------

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/12986#pullrequestreview-1367413958
PR Comment: https://git.openjdk.org/jdk/pull/12986#issuecomment-1492427957

From mchung at openjdk.org  Fri Mar 31 18:39:24 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 31 Mar 2023 18:39:24 GMT
Subject: RFR: 8284871: Use covariant overrides for the
 resolveConstantDesc(Lookup) method in =?UTF-8?B?c3Vi4oCRaW50ZXJmYWNlcw==?= of
 java.lang.constant.ConstantDesc
In-Reply-To: 
References: <6elA1YOQCqZutbsRVG89Q0C_5-3zu-OHco8_h2z5mKg=.a313ea66-e58d-401b-88a8-c843dcecf218@github.com>
 
 
Message-ID: 

On Fri, 31 Mar 2023 15:22:05 GMT, Chen Liang  wrote:

>> src/java.base/share/classes/java/lang/constant/MethodTypeDesc.java line 197:
>> 
>>> 195:      * @apiNote {@linkplain MethodTypeDesc} can represent method type descriptors
>>> 196:      * that are not representable by {@linkplain MethodType}, such as methods with
>>> 197:      * more than 255 parameter slots, so attempts to resolve these may result in errors.
>> 
>> Should?this also?be?added to?`MethodHandleDesc::resolveConstantDesc(Lookup)`?
>
> Nah. Since such a MethodTypeDesc is never valid, such a MethodHandleDesc or DynamicConstantDesc should always fail to resolve for such a method handle can never be found. The only problem we need to be concerned about is that the failure in those Descs should be ReflectiveOperationException instead of some sort of UncheckedException (which I think MethodTypeDesc.resolveConstantDesc currently throws), but that belongs to another issue, given currently, MethodTypeDesc even throws unchecked exceptions when it tries to resolve an nonexistent class.

agree, this `@apiNote` is specific for `MethodTypeDesc` only.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12986#discussion_r1154780518

From martin at openjdk.org  Fri Mar 31 18:41:24 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Fri, 31 Mar 2023 18:41:24 GMT
Subject: RFR: 8304014: Convert
 test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java to junit [v5]
In-Reply-To: 
References: 
 
Message-ID: <4k_A3wLxlfbonP-w9g7-YlHZ4025KGey9VXPqqjwCNw=.4929cee0-3d8c-42cf-bb56-dbec3f627978@github.com>

On Fri, 31 Mar 2023 13:51:22 GMT, Eirik Bjorsnos  wrote:

>> CorruptedZipFiles could benefit from some spring cleaning and a conversion to junit:
>> 
>> - The actual tests are moved into their own `@Test` methods, given more meaningful names and a Javadoc comment explaining the constraint being verified
>> - The setup code is moved to a `@Before` method, slightly modernized and rewritten to take advantage of `assertEquals` 
>> - `checkZipExceptionImpl` is updated to take advantage of `assertThrows`
>> - A bunch of constants copied over from `ZipFile` can be deleted since JDK-6225935 has long been fixed
>
> Eirik Bjorsnos has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Document the structure of the 'good' ZIP
>  - Use the "Validate that.." comment style
>  - Document the ByteBuffer with a comment
>  - Use ByteBuffer when manipulating multi-byte fields

I support rewriting tests like this into junit 5.

I wrote many jdk tests (like this) before a standard high quality test framework like junit 5 was available.

Zip file implementations are 90% corner cases, so expanding testing and improving testability of jdk classes would be valuable.  For example, it would be nice to explicitly request use of ZIP64 extensions even when they are not needed, to avoid having to create multi-gigabyte test files.

test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java line 246:

> 244:     /*
> 245:      * Validate that a ZipException is thrown if the last CEN header is
> 246:      * not immediatly followed by the start of the 'End of central directory' record

typo: immediatly

test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java line 300:

> 298: 
> 299:     /*
> 300:      * Validate that a ZipException is thrown when a LOC header has an unexpected signature

I would leave off "Validate that"

-------------

PR Review: https://git.openjdk.org/jdk/pull/12563#pullrequestreview-1367398354
PR Review Comment: https://git.openjdk.org/jdk/pull/12563#discussion_r1154773604
PR Review Comment: https://git.openjdk.org/jdk/pull/12563#discussion_r1154779308

From bpb at openjdk.org  Fri Mar 31 19:01:19 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 31 Mar 2023 19:01:19 GMT
Subject: RFR: JDK-8304028: Port fdlibm IEEEremainder to Java [v3]
In-Reply-To: <_4MDhzG22C7qUHR9ZXOAGrv52fkDTW0l-s1SaqPLz-U=.1b296196-9242-4438-9cd0-e8edf3bf135c@github.com>
References: 
 <_4MDhzG22C7qUHR9ZXOAGrv52fkDTW0l-s1SaqPLz-U=.1b296196-9242-4438-9cd0-e8edf3bf135c@github.com>
Message-ID: 

On Wed, 29 Mar 2023 04:21:10 GMT, Joe Darcy  wrote:

>> Last but not least, a port of fdlibm IEEEremainder from C to Java. I plan to write some more implementation-specific tests around decision points in the FDLIBM algorithm, but I wanted to get the bulk of the changes out for review first.
>> 
>> Note that since IEEEremainder was the last native method in StrictMath.java, the StrictMath.c file needed to be deleted (or modified) since StrictMath.h was no longer generated as part of the build. (StrictMath.c was one of the file deleted as part of JDK-8302801).
>> 
>> For testing, Mach 5 tier 1 through 3 were successful (other than an unrelated test failure that was problem listed) and the exhaustive test was locally run and passed with "16, 16" to increase the testing density.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Appease jcheck.

LGTM2

-------------

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13113#pullrequestreview-1367445754

From darcy at openjdk.org  Fri Mar 31 19:23:10 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 31 Mar 2023 19:23:10 GMT
Subject: RFR: JDK-8304028: Port fdlibm IEEEremainder to Java [v4]
In-Reply-To: 
References: 
Message-ID: <5WdS3DTKwtFhiPxU4UA1ByUeeTIbYb2Zxc9bqY5IVnE=.4d1462fa-b583-412e-b8b7-c8a20a4b0985@github.com>

> Last but not least, a port of fdlibm IEEEremainder from C to Java. I plan to write some more implementation-specific tests around decision points in the FDLIBM algorithm, but I wanted to get the bulk of the changes out for review first.
> 
> Note that since IEEEremainder was the last native method in StrictMath.java, the StrictMath.c file needed to be deleted (or modified) since StrictMath.h was no longer generated as part of the build. (StrictMath.c was one of the file deleted as part of JDK-8302801).
> 
> For testing, Mach 5 tier 1 through 3 were successful (other than an unrelated test failure that was problem listed) and the exhaustive test was locally run and passed with "16, 16" to increase the testing density.

Joe Darcy 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-8304028
 - Appease jcheck.
 - Respond to review feedback, expand tests.
 - Merge branch 'master' into JDK-8304028
 - JDK-8304028: Port fdlibm IEEEremainder to Java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13113/files
  - new: https://git.openjdk.org/jdk/pull/13113/files/cce01395..58a4e720

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13113&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13113&range=02-03

  Stats: 10180 lines in 300 files changed: 6132 ins; 2589 del; 1459 mod
  Patch: https://git.openjdk.org/jdk/pull/13113.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13113/head:pull/13113

PR: https://git.openjdk.org/jdk/pull/13113

From bpb at openjdk.org  Fri Mar 31 19:27:14 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 31 Mar 2023 19:27:14 GMT
Subject: RFR: JDK-8304028: Port fdlibm IEEEremainder to Java [v4]
In-Reply-To: <5WdS3DTKwtFhiPxU4UA1ByUeeTIbYb2Zxc9bqY5IVnE=.4d1462fa-b583-412e-b8b7-c8a20a4b0985@github.com>
References: 
 <5WdS3DTKwtFhiPxU4UA1ByUeeTIbYb2Zxc9bqY5IVnE=.4d1462fa-b583-412e-b8b7-c8a20a4b0985@github.com>
Message-ID: 

On Fri, 31 Mar 2023 19:23:10 GMT, Joe Darcy  wrote:

>> Last but not least, a port of fdlibm IEEEremainder from C to Java. I plan to write some more implementation-specific tests around decision points in the FDLIBM algorithm, but I wanted to get the bulk of the changes out for review first.
>> 
>> Note that since IEEEremainder was the last native method in StrictMath.java, the StrictMath.c file needed to be deleted (or modified) since StrictMath.h was no longer generated as part of the build. (StrictMath.c was one of the file deleted as part of JDK-8302801).
>> 
>> For testing, Mach 5 tier 1 through 3 were successful (other than an unrelated test failure that was problem listed) and the exhaustive test was locally run and passed with "16, 16" to increase the testing density.
>
> Joe Darcy 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-8304028
>  - Appease jcheck.
>  - Respond to review feedback, expand tests.
>  - Merge branch 'master' into JDK-8304028
>  - JDK-8304028: Port fdlibm IEEEremainder to Java

Marked as reviewed by bpb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13113#pullrequestreview-1367475092

From darcy at openjdk.org  Fri Mar 31 19:51:28 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 31 Mar 2023 19:51:28 GMT
Subject: Integrated: JDK-8304028: Port fdlibm IEEEremainder to Java
In-Reply-To: 
References: 
Message-ID: 

On Tue, 21 Mar 2023 06:11:57 GMT, Joe Darcy  wrote:

> Last but not least, a port of fdlibm IEEEremainder from C to Java. I plan to write some more implementation-specific tests around decision points in the FDLIBM algorithm, but I wanted to get the bulk of the changes out for review first.
> 
> Note that since IEEEremainder was the last native method in StrictMath.java, the StrictMath.c file needed to be deleted (or modified) since StrictMath.h was no longer generated as part of the build. (StrictMath.c was one of the file deleted as part of JDK-8302801).
> 
> For testing, Mach 5 tier 1 through 3 were successful (other than an unrelated test failure that was problem listed) and the exhaustive test was locally run and passed with "16, 16" to increase the testing density.

This pull request has now been integrated.

Changeset: abfb9008
Author:    Joe Darcy 
URL:       https://git.openjdk.org/jdk/commit/abfb9008291a65dc76fa8cc740265d43a0d8aa4b
Stats:     843 lines in 7 files changed: 714 ins; 127 del; 2 mod

8304028: Port fdlibm IEEEremainder to Java

Reviewed-by: bpb

-------------

PR: https://git.openjdk.org/jdk/pull/13113

From cjplummer at openjdk.org  Fri Mar 31 19:57:18 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 31 Mar 2023 19:57:18 GMT
Subject: RFR: 8305341: Alignment outside of HotSpot should be enforced by
 alignas instead of compiler specific attributes
In-Reply-To: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com>
References: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com>
Message-ID: 

On Fri, 31 Mar 2023 06:07:39 GMT, Julian Waters  wrote:

> C11 has been stable for a long time on all platforms, so native code can use the standard alignas operator for alignment requirements

I don't have any comments on this change in general (it's not something I've dealt with in the past), but I did notice that there are a couple of places you missed:


src/hotspot/share/utilities/globalDefinitions_visCPP.hpp:119:#define ATTRIBUTE_ALIGNED(x) __declspec(align(x))
src/java.desktop/share/native/libfreetype/include/freetype/internal/ftvalid.h:82:  /* __declspec(align())' in order to compile cleanly with */
src/java.desktop/share/native/libfreetype/src/smooth/ftgrays.c:484:  /* __declspec(align())' in order to compile cleanly with */


For the 2nd and 3rd ones you would want to remove all of the following:


#if defined( _MSC_VER )      /* Visual C++ (and Intel C++) */
  /* We disable the warning `structure was padded due to   */
  /* __declspec(align())' in order to compile cleanly with */
  /* the maximum level of warnings.                        */
#pragma warning( push )
#pragma warning( disable : 4324 )
#endif /* _MSC_VER */
...
#if defined( _MSC_VER )
#pragma warning( pop )
#endif

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13258#issuecomment-1492522828

From duke at openjdk.org  Fri Mar 31 19:59:10 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 31 Mar 2023 19:59:10 GMT
Subject: RFR: 8304014: Convert
 test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java to junit [v6]
In-Reply-To: 
References: 
Message-ID: 

> CorruptedZipFiles could benefit from some spring cleaning and a conversion to junit:
> 
> - The actual tests are moved into their own `@Test` methods, given more meaningful names and a Javadoc comment explaining the constraint being verified
> - The setup code is moved to a `@Before` method, slightly modernized and rewritten to take advantage of `assertEquals` 
> - `checkZipExceptionImpl` is updated to take advantage of `assertThrows`
> - A bunch of constants copied over from `ZipFile` can be deleted since JDK-6225935 has long been fixed

Eirik Bjorsnos has updated the pull request incrementally with four additional commits since the last revision:

 - Remove the "Validate that " comment prefix
 - Spell immediately correctly
 - a A -> a
 - this -> the

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12563/files
  - new: https://git.openjdk.org/jdk/pull/12563/files/e32052f1..3b6d8577

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12563&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12563&range=04-05

  Stats: 16 lines in 1 file changed: 0 ins; 0 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/12563.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12563/head:pull/12563

PR: https://git.openjdk.org/jdk/pull/12563

From duke at openjdk.org  Fri Mar 31 19:59:14 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 31 Mar 2023 19:59:14 GMT
Subject: RFR: 8304014: Convert
 test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java to junit [v5]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 31 Mar 2023 17:27:25 GMT, Lance Andersen  wrote:

>> Eirik Bjorsnos has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Document the structure of the 'good' ZIP
>>  - Use the "Validate that.." comment style
>>  - Document the ByteBuffer with a comment
>>  - Use ByteBuffer when manipulating multi-byte fields
>
> test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java line 56:
> 
>> 54:      * Byte array holding a valid template ZIP.
>> 55:      *
>> 56:      * This 'good' ZIP file has the following structure:
> 
> Change this -> the

Fixed.

> test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java line 203:
> 
>> 201:     /*
>> 202:      * Validate that a ZipException is thrown when a A CEN header has an unexpected signature
>> 203:      */
> 
> change  "a A" to "a"

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12563#discussion_r1154840888
PR Review Comment: https://git.openjdk.org/jdk/pull/12563#discussion_r1154841007

From duke at openjdk.org  Fri Mar 31 20:10:17 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 31 Mar 2023 20:10:17 GMT
Subject: RFR: 8304014: Convert
 test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java to junit [v5]
In-Reply-To: <4k_A3wLxlfbonP-w9g7-YlHZ4025KGey9VXPqqjwCNw=.4929cee0-3d8c-42cf-bb56-dbec3f627978@github.com>
References: 
 
 <4k_A3wLxlfbonP-w9g7-YlHZ4025KGey9VXPqqjwCNw=.4929cee0-3d8c-42cf-bb56-dbec3f627978@github.com>
Message-ID: 

On Fri, 31 Mar 2023 18:37:58 GMT, Martin Buchholz  wrote:

> I support rewriting tests like this into junit 5.

Glad to hear! I would be a bit sad to hear you were against this.
 
> I wrote many jdk tests (like this) before a standard high quality test framework like junit 5 was available.

And thank you for that!

> Zip file implementations are 90% corner cases, so expanding testing and improving testability of jdk classes would be valuable. For example, it would be nice to explicitly request use of ZIP64 extensions even when they are not needed, to avoid having to create multi-gigabyte test files.

Indeed. I would also just love to be able  to transform existing ZIP files into Zip64 format, regardless of their current format. And along the way transform any ZIP record or field in a type-safe manner. Stay tuned for suggestions in this area..

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12563#issuecomment-1492552840

From liach at openjdk.org  Fri Mar 31 20:32:13 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 31 Mar 2023 20:32:13 GMT
Subject: RFR: 8284871: Use covariant overrides for the
 resolveConstantDesc(Lookup) method in =?UTF-8?B?c3Vi4oCRaW50ZXJmYWNlcw==?= of
 java.lang.constant.ConstantDesc [v2]
In-Reply-To: <6elA1YOQCqZutbsRVG89Q0C_5-3zu-OHco8_h2z5mKg=.a313ea66-e58d-401b-88a8-c843dcecf218@github.com>
References: <6elA1YOQCqZutbsRVG89Q0C_5-3zu-OHco8_h2z5mKg=.a313ea66-e58d-401b-88a8-c843dcecf218@github.com>
Message-ID: <7TTSe4LEKQLHJ140w98Th2zJetTJtGWNtDU08x6Utyg=.eb44653c-24f9-40c2-a9ac-728e840c8b78@github.com>

> Also remove redundant casts to avoid javac warnings.

Chen Liang 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:

 - Update tests to remove useless casts and update copyright year
 - Merge branch 'master' into constdesc-override
 - Move MethodTypeDesc api notes to MethodTypeDesc
 - Merge branch 'master' of https://git.openjdk.java.net/jdk into constdesc-override
 - Remove redundant casts
 - Covariant override of resolveConstantDesc for Class/MethodType/MethodHandleDesc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12986/files
  - new: https://git.openjdk.org/jdk/pull/12986/files/67720a2a..5b26556d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12986&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12986&range=00-01

  Stats: 103037 lines in 1482 files changed: 60525 ins; 29259 del; 13253 mod
  Patch: https://git.openjdk.org/jdk/pull/12986.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12986/head:pull/12986

PR: https://git.openjdk.org/jdk/pull/12986

From liach at openjdk.org  Fri Mar 31 20:32:15 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 31 Mar 2023 20:32:15 GMT
Subject: RFR: 8284871: Use covariant overrides for the
 resolveConstantDesc(Lookup) method in =?UTF-8?B?c3Vi4oCRaW50ZXJmYWNlcw==?= of
 java.lang.constant.ConstantDesc
In-Reply-To: <6elA1YOQCqZutbsRVG89Q0C_5-3zu-OHco8_h2z5mKg=.a313ea66-e58d-401b-88a8-c843dcecf218@github.com>
References: <6elA1YOQCqZutbsRVG89Q0C_5-3zu-OHco8_h2z5mKg=.a313ea66-e58d-401b-88a8-c843dcecf218@github.com>
Message-ID: 

On Sat, 11 Mar 2023 04:59:07 GMT, Chen Liang  wrote:

> Also remove redundant casts to avoid javac warnings.

Done. Updated the tests and copyright year of changed files. Would you mind review the associated CSR as well?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12986#issuecomment-1492573116

From duke at openjdk.org  Fri Mar 31 20:55:27 2023
From: duke at openjdk.org (Chris Hennick)
Date: Fri, 31 Mar 2023 20:55:27 GMT
Subject: RFR: 8284493: Improve computeNextExponential tail performance and
 accuracy [v18]
In-Reply-To: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
References: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
Message-ID: 

> This PR improves both the worst-case performance of `nextExponential` and `nextGaussian` and the distribution of output at the tails. It fixes the following imperfections:
> 
> * Repeatedly adding DoubleZigguratTables.exponentialX0 to extra causes a rounding error to accumulate at the tail of the distribution (probably starting around `2*exponentialX0 == 0x1.e46eff20739afp3 ~ 15.1`); this PR fixes that by tracking the multiple of exponentialX0 as a long. (This distortion is worst when `x > 0x1.0p56` since in that case, a rounding error means `extra + x == extra`.
> * Reduces several equations using `Math.fma`. (This will almost certainly improve performance, and may or may not improve output distribution.)
> * Uses the newly-extracted `computeWinsorizedNextExponential` function to prevent `nextGaussian` from going into the `nextExponential` tail twice.

Chris Hennick 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' of https://git.openjdk.org/jdk into patch-1
 - Merge branch 'master' into patch-1
 - Update copyright date in RandomNext.java
 - Update copyright date in RandomGeneratorNext.java
 - Update copyright date in RandomGeneratorExponentialGaussian.java
 - Update copyright date in RandomSupport.java
 - Add parameter to enable/disable fixed PRNG seed
 - Rewrite Javadoc
 - Simplify Javadoc description
 - Weaken contract of computeWinsorizedNextExponential to save max/min calls
 - ... and 6 more: https://git.openjdk.org/jdk/compare/abfb9008...63706c8b

-------------

Changes: https://git.openjdk.org/jdk/pull/8131/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=8131&range=17
  Stats: 144 lines in 4 files changed: 129 ins; 1 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/8131.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/8131/head:pull/8131

PR: https://git.openjdk.org/jdk/pull/8131

From mchung at openjdk.org  Fri Mar 31 21:33:18 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 31 Mar 2023 21:33:18 GMT
Subject: RFR: 8284871: Use covariant overrides for the
 resolveConstantDesc(Lookup) method in =?UTF-8?B?c3Vi4oCRaW50ZXJmYWNlcw==?= of
 java.lang.constant.ConstantDesc [v2]
In-Reply-To: <7TTSe4LEKQLHJ140w98Th2zJetTJtGWNtDU08x6Utyg=.eb44653c-24f9-40c2-a9ac-728e840c8b78@github.com>
References: <6elA1YOQCqZutbsRVG89Q0C_5-3zu-OHco8_h2z5mKg=.a313ea66-e58d-401b-88a8-c843dcecf218@github.com>
 <7TTSe4LEKQLHJ140w98Th2zJetTJtGWNtDU08x6Utyg=.eb44653c-24f9-40c2-a9ac-728e840c8b78@github.com>
Message-ID: 

On Fri, 31 Mar 2023 20:32:13 GMT, Chen Liang  wrote:

>> Also remove redundant casts to avoid javac warnings.
>
> Chen Liang 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:
> 
>  - Update tests to remove useless casts and update copyright year
>  - Merge branch 'master' into constdesc-override
>  - Move MethodTypeDesc api notes to MethodTypeDesc
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into constdesc-override
>  - Remove redundant casts
>  - Covariant override of resolveConstantDesc for Class/MethodType/MethodHandleDesc

Marked as reviewed by mchung (Reviewer).

Reviewed.  @vicente-romero-oracle may want to review this.

-------------

PR Review: https://git.openjdk.org/jdk/pull/12986#pullrequestreview-1367645966
PR Comment: https://git.openjdk.org/jdk/pull/12986#issuecomment-1492633095

From jlu at openjdk.org  Fri Mar 31 21:41:17 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 31 Mar 2023 21:41:17 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v5]
In-Reply-To: 
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 
Message-ID: 

On Fri, 17 Mar 2023 22:27:48 GMT, Justin Lu  wrote:

>> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
>> 
>> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Close streams when finished loading into props

Something thing to consider is that Intellj defaults .properties files to ISO 8859-1. 

https://www.jetbrains.com/help/idea/properties-files.html#encoding

So users of Intellj / (other IDEs that default to ISO 8859-1 for .properties files) will need to change the default encoding to utf-8 for such files. Or ideally, the respective IDEs can change their default encoding for .properties files if this change is integrated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12726#issuecomment-1492640306

From jlu at openjdk.org  Fri Mar 31 21:45:21 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 31 Mar 2023 21:45:21 GMT
Subject: RFR: 8305400: ISO 4217 Amendment 175 Update
Message-ID: 

Please review the ISO 4217 amendment 175 update.

There are no meaningful code changes, but the version number should be updated accordingly to be in sync.

-------------

Commit messages:
 - Update to 175

Changes: https://git.openjdk.org/jdk/pull/13275/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13275&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305400
  Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/13275.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13275/head:pull/13275

PR: https://git.openjdk.org/jdk/pull/13275

From duke at openjdk.org  Fri Mar 31 21:50:14 2023
From: duke at openjdk.org (Steven R. Loomis)
Date: Fri, 31 Mar 2023 21:50:14 GMT
Subject: RFR: 8305400: ISO 4217 Amendment 175 Update
In-Reply-To: 
References: 
Message-ID: 

On Fri, 31 Mar 2023 21:38:31 GMT, Justin Lu  wrote:

> Please review the ISO 4217 amendment 175 update.
> 
> There are no meaningful code changes, but the version number should be updated accordingly to be in sync.

Do you track the legal tender date? Because that did change, for CLDR https://github.com/unicode-org/cldr/pull/2825

-------------

PR Review: https://git.openjdk.org/jdk/pull/13275#pullrequestreview-1367657807

From jjg at openjdk.org  Fri Mar 31 22:07:26 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 31 Mar 2023 22:07:26 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v3]
In-Reply-To: 
References: 
Message-ID: 

> Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.
> 
> This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.
> 
> While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.
> 
> It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]
> 
> [here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
> [disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  revert removing @see tags where the URL was not the same as the @spec URL

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13248/files
  - new: https://git.openjdk.org/jdk/pull/13248/files/096a4188..7f64cc32

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13248&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13248&range=01-02

  Stats: 12 lines in 4 files changed: 12 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13248.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13248/head:pull/13248

PR: https://git.openjdk.org/jdk/pull/13248

From serb at openjdk.org  Fri Mar 31 22:09:16 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 31 Mar 2023 22:09:16 GMT
Subject: RFR: 8305113: (tz) Update Timezone Data to 2023c
In-Reply-To: 
References: 
Message-ID: 

On Fri, 31 Mar 2023 00:02:02 GMT, Yoshiki Sato  wrote:

> Pleases review this PR. 
> The PR includes the following changes.
> - tzdata 2023c
> - Hack code to deal with Cairo's DST end, which is same as done in 2014g([JDK-8049343](https://bugs.openjdk.org/browse/JDK-8049343)).  To work around the the limitation of JSR 310 compiler, where the time 24:00 is recognized as 0:00 in the previous day.

src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java line 742:

> 740: 
> 741:         return new ZoneInfo(zoneId, rawOffset, dstSavings, checksum, transitions,
> 742:                 offsets, params, willGMTOffsetChange);

do we need to change it here?

src/java.base/share/classes/sun/util/resources/TimeZoneNames.java line 2:

> 1: /*
> 2:  * Copyright (c) 1996, 2033, Oracle and/or its affiliates. All rights reserved.

Wrong year.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13255#discussion_r1154945016
PR Review Comment: https://git.openjdk.org/jdk/pull/13255#discussion_r1154944389

From naoto at openjdk.org  Fri Mar 31 22:13:14 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 31 Mar 2023 22:13:14 GMT
Subject: RFR: 8305400: ISO 4217 Amendment 175 Update
In-Reply-To: 
References: 
Message-ID: <1FFB2yFyGduBvO4MmuQ2tE0_E8bq0fInuoZKzt4mGg8=.d2c901ad-1e49-4770-ade9-14b47deb2b75@github.com>

On Fri, 31 Mar 2023 21:38:31 GMT, Justin Lu  wrote:

> Please review the ISO 4217 amendment 175 update.
> 
> There are no meaningful code changes, but the version number should be updated accordingly to be in sync.

Marked as reviewed by naoto (Reviewer).

> Do you track the legal tender date? Because that did change, for CLDR [unicode-org/cldr#2825](https://github.com/unicode-org/cldr/pull/2825)

Hi Steven,
No, JDK does not provide either historical currency information or dates. `Currency.getInstance(Locale)` always returns the new currency during the transition period by default. (Can be manipulated by modifying the `currency.properties` file)

-------------

PR Review: https://git.openjdk.org/jdk/pull/13275#pullrequestreview-1367677172
PR Comment: https://git.openjdk.org/jdk/pull/13275#issuecomment-1492667558

From duke at openjdk.org  Fri Mar 31 22:17:15 2023
From: duke at openjdk.org (Steven R. Loomis)
Date: Fri, 31 Mar 2023 22:17:15 GMT
Subject: RFR: 8305400: ISO 4217 Amendment 175 Update
In-Reply-To: 
References: 
Message-ID: 

On Fri, 31 Mar 2023 21:38:31 GMT, Justin Lu  wrote:

> Please review the ISO 4217 amendment 175 update.
> 
> There are no meaningful code changes, but the version number should be updated accordingly to be in sync.

Marked as reviewed by srl295 at github.com (no known OpenJDK username).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13275#pullrequestreview-1367679317

From jjg at openjdk.org  Fri Mar 31 22:18:15 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 31 Mar 2023 22:18:15 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v2]
In-Reply-To: 
References: 
 <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
 
Message-ID: 

On Fri, 31 Mar 2023 16:28:14 GMT, Sean Mullan  wrote:

> I didn't see any changes to security APIs - are they coming in a follow-on issue?

Yes, this is _Add `@spec` tags in java.base/java.* (part 1)_
The rest of `java.base` will be in part 2.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13248#issuecomment-1492670942

From duke at openjdk.org  Fri Mar 31 22:37:00 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 31 Mar 2023 22:37:00 GMT
Subject: RFR: 8304014: Convert
 test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java to junit [v5]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 31 Mar 2023 17:38:02 GMT, Lance Andersen  wrote:

>> Eirik Bjorsnos has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Document the structure of the 'good' ZIP
>>  - Use the "Validate that.." comment style
>>  - Document the ByteBuffer with a comment
>>  - Use ByteBuffer when manipulating multi-byte fields
>
> test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java line 192:
> 
>> 190:     /*
>> 191:      * Validate that a ZipException is thrown when the 'End of Central Directory'
>> 192:      * (END) header has a CEN offset incoherent with the position calculated
> 
> Not sure _incoherent_ is the best term.
> 
>       perhaps something along the lines:
> 
> header  contains an invalid CEN Directory  starting offset.....

I remember my struggles trying to write this one in the first place. The code says:


long cenpos = end.endpos - end.cenlen;     // position of CEN table
// Get position of first local file (LOC) header, taking into
// account that there may be a stub prefixed to the zip file.
locpos = cenpos - end.cenoff;
if (locpos < 0) {
        zerror("invalid END header (bad central directory offset)");
}
``` 

so I ended up trying to express this equation in words, which is maybe not so successful. I don't see _incoherent_ as the main problem, if it was we could just use _inconsistent_.

Do you have a better concrete suggestion?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12563#discussion_r1154844552

From duke at openjdk.org  Fri Mar 31 22:37:24 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 31 Mar 2023 22:37:24 GMT
Subject: RFR: 8304014: Convert
 test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java to junit [v5]
In-Reply-To: <4k_A3wLxlfbonP-w9g7-YlHZ4025KGey9VXPqqjwCNw=.4929cee0-3d8c-42cf-bb56-dbec3f627978@github.com>
References: 
 
 <4k_A3wLxlfbonP-w9g7-YlHZ4025KGey9VXPqqjwCNw=.4929cee0-3d8c-42cf-bb56-dbec3f627978@github.com>
Message-ID: 

On Fri, 31 Mar 2023 18:24:26 GMT, Martin Buchholz  wrote:

>> Eirik Bjorsnos has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Document the structure of the 'good' ZIP
>>  - Use the "Validate that.." comment style
>>  - Document the ByteBuffer with a comment
>>  - Use ByteBuffer when manipulating multi-byte fields
>
> test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java line 246:
> 
>> 244:     /*
>> 245:      * Validate that a ZipException is thrown if the last CEN header is
>> 246:      * not immediatly followed by the start of the 'End of central directory' record
> 
> typo: immediatly

Thanks, fixed.

> test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java line 300:
> 
>> 298: 
>> 299:     /*
>> 300:      * Validate that a ZipException is thrown when a LOC header has an unexpected signature
> 
> I would leave off "Validate that"

Thanks, updated all test comments to strip this shared prefix.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12563#discussion_r1154844736
PR Review Comment: https://git.openjdk.org/jdk/pull/12563#discussion_r1154844995

From naoto at openjdk.org  Fri Mar 31 22:48:29 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 31 Mar 2023 22:48:29 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v5]
In-Reply-To: 
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 
Message-ID: 

On Fri, 17 Mar 2023 22:27:48 GMT, Justin Lu  wrote:

>> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
>> 
>> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Close streams when finished loading into props

Hmm, I just wonder why they are sticking to ISO-8859-1 as the default. I know j.u.Properties defaults to 8859-1, but PropertyResourceBundle, which is their primary use defaults to UTF-8 since JDK9 (https://openjdk.org/jeps/226)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12726#issuecomment-1492682703