From dholmes at openjdk.java.net Fri Oct 1 00:41:22 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 1 Oct 2021 00:41:22 GMT Subject: RFR: 8274349: ForkJoinPool.commonPool() does not work with 1 CPU Message-ID: A regression introduced in Java 17 will give the default FJ pool a parallelism of zero in a uniprocessor environment. The fix restores this to a value of 1. See bug report for details. Testing: - new regression test - tiers 1-3 Thanks, David ------------- Commit messages: - 8274349: ForkJoinPool.commonPool() does not work with 1 CPU Changes: https://git.openjdk.java.net/jdk/pull/5784/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5784&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274349 Stats: 47 lines in 2 files changed: 46 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5784.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5784/head:pull/5784 PR: https://git.openjdk.java.net/jdk/pull/5784 From itakiguchi at openjdk.java.net Fri Oct 1 02:07:41 2021 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Fri, 1 Oct 2021 02:07:41 GMT Subject: RFR: 8274544: Langtools command's usage were grabled on Japanese Windows In-Reply-To: References: Message-ID: On Thu, 30 Sep 2021 21:45:15 GMT, Naoto Sato wrote: >> Screenshot >> ![javac-screenshot](https://user-images.githubusercontent.com/33543753/135429041-0ed22b36-0b1e-4626-92ca-8b58acf8872d.png) >> >> javac does not use PrintStream for standard out/err, it uses PrintWriter. >> I put some codes on src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java >> * Using native.encoding system property. But test/langtools/tools/javac/diags/CheckResourceKeys.java was failed. >> * Use java.io.Console, like Console cons = System.console() and cons.charset(), but "javac 2>&1 | more" does not work as expected because System.console() returns null. >> >> So I added -Dfile.encoding=COMPAT expect java and javaw commands on launcher. >> >> jshell does not work as expected on b12 >> >>>jdk-18-b12\bin\jshell.exe >> | JShell????? -- ?????18-ea >> | ??????????????????: /help intro >> >> jshell> "\u3042".getBytes() >> $1 ==> byte[2] { -126, -96 } >> >> on b13 >> >>>jdk-18-b13\bin\jshell.exe >> | JShell????? -- ?????18-ea >> | ??????????????????: /help intro >> >> jshell> "\u3042".getBytes() >> $1 ==> byte[3] { -29, -127, -126 } >> >> It's UTF-8, not native encoding. >> I think backend java process should use same fine.encoding system property setting. >> >> I don't think it's good fix, so please give me some advices. > >> * Using native.encoding system property. But test/langtools/tools/javac/diags/CheckResourceKeys.java was failed. > > What was the cause of the failure? > >> * Use java.io.Console, like Console cons = System.console() and cons.charset(), but "javac 2>&1 | more" does not work as expected because System.console() returns null. >> >> So I added -Dfile.encoding=COMPAT expect java and javaw commands on launcher. > > I think we should fix the root cause of this, instead of specifying `file.encoding=COMPAT` > >> >> jshell does not work as expected on b12 > > Do you mean `b13`? > >> >> ``` >> >jdk-18-b12\bin\jshell.exe >> | JShell????? -- ?????18-ea >> | ??????????????????: /help intro >> >> jshell> "\u3042".getBytes() >> $1 ==> byte[2] { -126, -96 } >> ``` >> >> on b13 >> >> ``` >> >jdk-18-b13\bin\jshell.exe >> | JShell????? -- ?????18-ea >> | ??????????????????: /help intro >> >> jshell> "\u3042".getBytes() >> $1 ==> byte[3] { -29, -127, -126 } >> ``` >> >> It's UTF-8, not native encoding. I think backend java process should use same fine.encoding system property setting. > > No it should not. `file.encoding` should not be inherited. > > Naoto @naotoj I applied following change on src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java @@ -26,6 +26,7 @@ package com.sun.tools.javac.util; import java.io.*; +import java.nio.charset.Charset; import java.util.Arrays; import java.util.EnumMap; import java.util.EnumSet; @@ -261,12 +262,22 @@ public class Log extends AbstractLog { * @param context the context in which to find writers to use * @return a map of writers */ + private final static Charset nativeCharset; + static { + Charset cs = Charset.defaultCharset(); + try { + cs = Charset.forName(System.getProperty("native.encoding")); + } catch (Exception e) { + } + nativeCharset = cs; + } + private static Map initWriters(Context context) { PrintWriter out = context.get(outKey); PrintWriter err = context.get(errKey); if (out == null && err == null) { - out = new PrintWriter(System.out, true); - err = new PrintWriter(System.err, true); + out = new PrintWriter(System.out, true, nativeCharset); + err = new PrintWriter(System.err, true, nativeCharset); return initWriters(out, err); } else if (out == null || err == null) { PrintWriter pw = (out != null) ? out : err; I got following exception via tools/javac/diags/CheckResourceKeys.java Error: no match for "native.encoding" java.lang.Exception: 1 errors occurred at CheckResourceKeys.main(CheckResourceKeys.java:59) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:568) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:833) About jshell, my sample was not good, See this one. By b12 >jdk-18-b12\bin\jshell | JShell????? -- ?????18-ea | ??????????????????: /help intro jshell> System.out.println("\u3042") ? By b13 >jdk-18-b13\bin\jshell | JShell????? -- ?????18-ea | ??????????????????: /help intro jshell> System.out.println("\u3042") ?? By b13 with file.encoding=COMPAT >jdk-18-b13\bin\jshell -J-Dfile.encoding=COMPAT | JShell????? -- ?????18-ea | ??????????????????: /help intro jshell> System.out.println("\u3042") ?? If I need to create another issue, please let me know. ------------- PR: https://git.openjdk.java.net/jdk/pull/5771 From dholmes at openjdk.java.net Fri Oct 1 05:10:17 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 1 Oct 2021 05:10:17 GMT Subject: RFR: 8274349: ForkJoinPool.commonPool() does not work with 1 CPU [v2] In-Reply-To: References: Message-ID: > A regression introduced in Java 17 will give the default FJ pool a parallelism of zero in a uniprocessor environment. The fix restores this to a value of 1. See bug report for details. > > Testing: > - new regression test > - tiers 1-3 > > Thanks, > David David Holmes has updated the pull request incrementally with one additional commit since the last revision: Updated TCK test component from @martin ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5784/files - new: https://git.openjdk.java.net/jdk/pull/5784/files/7199b2b6..666f36f4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5784&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5784&range=00-01 Stats: 37 lines in 1 file changed: 34 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5784.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5784/head:pull/5784 PR: https://git.openjdk.java.net/jdk/pull/5784 From shade at openjdk.java.net Fri Oct 1 06:24:32 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 1 Oct 2021 06:24:32 GMT Subject: RFR: 8274349: ForkJoinPool.commonPool() does not work with 1 CPU [v2] In-Reply-To: References: Message-ID: On Fri, 1 Oct 2021 05:10:17 GMT, David Holmes wrote: >> A regression introduced in Java 17 will give the default FJ pool a parallelism of zero in a uniprocessor environment. The fix restores this to a value of 1. See bug report for details. >> >> Testing: >> - new regression test >> - tiers 1-3 >> >> Thanks, >> David > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Updated TCK test component from @martin Oh wow. Looks good! ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5784 From akasko at openjdk.java.net Fri Oct 1 08:46:29 2021 From: akasko at openjdk.java.net (Alex Kasko) Date: Fri, 1 Oct 2021 08:46:29 GMT Subject: RFR: 8274606: Fix jaxp/javax/xml/jaxp/unittest/transform/SurrogateTest.java test In-Reply-To: References: Message-ID: <4uwVOH0_SR_WrF_OY6siEeiLBvaZD1OmfzyETymeol4=.3f32ac58-9b92-435e-a9aa-30c84142c62a@github.com> On Thu, 30 Sep 2021 18:32:17 GMT, Alex Kasko wrote: > I was working on backporting JDK-8268457 and found minor problems with the test introduced there: > > 1. `compareWith*` helper methods are used without `Assert.assertTrue()` wrapping, so they are effectively ignored > > 2. `this.getClass().getResourceAsStream()` is used to load test input data, it actually returns null in test run, so transformation is done without input data > > Note, that SurrogateTest.zip reproducer attached to JDK-8268457 is valid and fully functional, problems likely were introduced when it was adapted into test. > > The change is to the test only, it wraps `compareWith*` helpers and loads data the same way as XSL is loaded. Additionally `compareStringWithGold` was changed to `compareLinesWithGold` to exclude possible line endings problems. > > Testing: checked that the test fails when JDK-8268457 code fix is reverted, checked that is passes on master. Thanks for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/5779 From dfuchs at openjdk.java.net Fri Oct 1 09:05:33 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 1 Oct 2021 09:05:33 GMT Subject: RFR: 8274525: Replace uses of StringBuffer with StringBuilder in java.xml In-Reply-To: References: Message-ID: <7fUdkSYe0ADp-jHROfsB-BTbVOUsT8p-s3L0sRDtM6M=.d6e15a31-32f6-43df-8d2c-1d54d55d5a8c@github.com> On Wed, 29 Sep 2021 17:56:49 GMT, Andrey Turbanov wrote: > StringBuffer is a legacy synchronized class. There are more modern alternatives which perform better: > 1. Plain String concatenation should be preferred > 2. StringBuilder is a direct replacement to StringBuffer which generally have better performance > > Similar cleanups: > 1. [JDK-8264029](https://bugs.openjdk.java.net/browse/JDK-8264029) java.base > 2. [JDK-8264428](https://bugs.openjdk.java.net/browse/JDK-8264428) java.desktop > 3. [JDK-8264484](https://bugs.openjdk.java.net/browse/JDK-8264484) jdk.hotspot.agent Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5759 From shade at openjdk.java.net Fri Oct 1 09:32:31 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 1 Oct 2021 09:32:31 GMT Subject: RFR: 8274606: Fix jaxp/javax/xml/jaxp/unittest/transform/SurrogateTest.java test In-Reply-To: References: Message-ID: <-8UFvtprb7bEjv0nMl_irJNUnyR5wmOEvhQiBLmA9xI=.adf1eb9e-d5e8-4264-8c44-cce799d59f68@github.com> On Thu, 30 Sep 2021 18:32:17 GMT, Alex Kasko wrote: > I was working on backporting JDK-8268457 and found minor problems with the test introduced there: > > 1. `compareWith*` helper methods are used without `Assert.assertTrue()` wrapping, so they are effectively ignored > > 2. `this.getClass().getResourceAsStream()` is used to load test input data, it actually returns null in test run, so transformation is done without input data > > Note, that SurrogateTest.zip reproducer attached to JDK-8268457 is valid and fully functional, problems likely were introduced when it was adapted into test. > > The change is to the test only, it wraps `compareWith*` helpers and loads data the same way as XSL is loaded. Additionally `compareStringWithGold` was changed to `compareLinesWithGold` to exclude possible line endings problems. > > Testing: checked that the test fails when JDK-8268457 code fix is reverted, checked that is passes on master. Looks fine to me. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5779 From jlahoda at openjdk.java.net Fri Oct 1 11:59:32 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 1 Oct 2021 11:59:32 GMT Subject: RFR: 8274544: Langtools command's usage were grabled on Japanese Windows In-Reply-To: References: Message-ID: On Thu, 30 Sep 2021 09:36:34 GMT, Ichiroh Takiguchi wrote: > JEP-400 (UTF-8 by Default) was eabled on JDK18-b13. > After JDK18-b13, javac and some other langtool command's usage were garbled on Japanese Windows. > These commands use PrintWriter instead of standard out/err with PrintStream. Regarding javac, the patch to `Log.java` seems to be in a reasonable direction: the write is to the physical `System.out/err` which should be done(?) using the native encoding. The order of the changed lines should be fixed, so that the javadoc is kept above the `initWriters` method. (As a secondary comment, it maybe a matter of discussion on whether keeping the native encoding in a static field is warranted here, but I don't mind it much.) Regarding JShell, I guess I need to try to find a way to reproduce for me, so that I can debug. AFAIK the main process does not read/write from/to the console using `System.in`/`System.out`, so encoding plays no real role for the console, but it plays role in the communication between the agent and the main process. ------------- PR: https://git.openjdk.java.net/jdk/pull/5771 From prappo at openjdk.java.net Fri Oct 1 12:16:27 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Fri, 1 Oct 2021 12:16:27 GMT Subject: RFR: 8274544: Langtools command's usage were grabled on Japanese Windows In-Reply-To: References: Message-ID: On Thu, 30 Sep 2021 09:36:34 GMT, Ichiroh Takiguchi wrote: > JEP-400 (UTF-8 by Default) was eabled on JDK18-b13. > After JDK18-b13, javac and some other langtool command's usage were garbled on Japanese Windows. > These commands use PrintWriter instead of standard out/err with PrintStream. For searchability, you could fix the typo in the PR title and JBS summary: grABled -> gARbled. A nit, really. ------------- PR: https://git.openjdk.java.net/jdk/pull/5771 From jlahoda at openjdk.java.net Fri Oct 1 12:24:27 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 1 Oct 2021 12:24:27 GMT Subject: RFR: 8274544: Langtools command's usage were garbled on Japanese Windows In-Reply-To: References: Message-ID: On Fri, 1 Oct 2021 11:56:03 GMT, Jan Lahoda wrote: > Regarding javac, the patch to `Log.java` seems to be in a reasonable direction: the write is to the physical `System.out/err` which should be done(?) using the native encoding. The order of the changed lines should be fixed, so that the javadoc is kept above the `initWriters` method. (As a secondary comment, it maybe a matter of discussion on whether keeping the native encoding in a static field is warranted here, but I don't mind it much.) I've forgot to write a note on the test, sorry: simply add `native.encoding` into `noResourceRequired` set in the test. The test checks that there are not hardcoded string that should be part of the resource bundle (and the resource bundle does not have unused keys), but names of system properties should be excluded, which is what the `noResourceRequired` set does. ------------- PR: https://git.openjdk.java.net/jdk/pull/5771 From itakiguchi at openjdk.java.net Fri Oct 1 12:33:30 2021 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Fri, 1 Oct 2021 12:33:30 GMT Subject: RFR: 8274544: Langtools command's usage were garbled on Japanese Windows In-Reply-To: References: Message-ID: <1IiimjjvBmQMekEbl91o0xEHlqxd8TYIPKuWf3phIUI=.6c630a04-050a-48f0-955e-823f6bd84417@github.com> On Fri, 1 Oct 2021 12:13:03 GMT, Pavel Rappo wrote: >> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13. >> After JDK18-b13, javac and some other langtool command's usage were garbled on Japanese Windows. >> These commands use PrintWriter instead of standard out/err with PrintStream. > > For searchability, you could fix the typo in the PR title and JBS summary: grABled -> gARbled. A nit, really. @pavelrappo Many thanks. I changed PR and JBS. ------------- PR: https://git.openjdk.java.net/jdk/pull/5771 From brett.okken.os at gmail.com Fri Oct 1 12:57:48 2021 From: brett.okken.os at gmail.com (Brett Okken) Date: Fri, 1 Oct 2021 07:57:48 -0500 Subject: StringCoding.hasNegatives Message-ID: I know java.lang.StringCoding.hasNegatives has a HotSpotIntrinsicCandidate annotation/implementation, but is there interest/value in a faster pure java implementation? Using Unsafe to read and compare 8 bytes at a time as a long is faster than the current simple implementation both in interpreter only mode and default hotspot compiler mode. I can provide jmh bencmark and results if this is worthwhile to pursue. Thanks, Brett private static final long NEGATIVE_MASK = 0x8080808080808080L; public static boolean hasNegatives(byte[] ba, int off, int len) { int i = off; final int endIdx = off + len; // align to 8 byte reads while ((i & 7) != 0 && i < endIdx) { if (ba[i++] < 0) { return true; } } // read 8 bytes at a time as a long (platform endian-ness does not matter) // to check if any have negative bit set final Unsafe unsafe = Unsafe.getUnsafe(); for (int j = endIdx - 7; i < j; i += 8) { final long val = unsafe.getLong(ba, Unsafe.ARRAY_BYTE_BASE_OFFSET + i); if ((val & NEGATIVE_MASK) != 0) { return true; } } // process trailing bytes 1 by 1 for ( ; i < endIdx; i++) { if (ba[i] < 0) { return true; } } return false; } From aph-open at littlepinkcloud.com Fri Oct 1 13:59:03 2021 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Fri, 1 Oct 2021 14:59:03 +0100 Subject: StringCoding.hasNegatives In-Reply-To: References: Message-ID: On 10/1/21 1:57 PM, Brett Okken wrote: > I know java.lang.StringCoding.hasNegatives has a > HotSpotIntrinsicCandidate annotation/implementation, but is there > interest/value in a faster pure java implementation? > > Using Unsafe to read and compare 8 bytes at a time as a long is faster > than the current simple implementation both in interpreter only mode > and default hotspot compiler mode. I can provide jmh bencmark and > results if this is worthwhile to pursue. The current pure Java implementation does two things: it provides a fallback for pure-interpreter JVMs and it provides the reader with a simple implementation. I'm not at all sure we'd want a complex implementation. Having said that, if I were looking at a faster pure Java version of this logic, I'd look at MethodHandles.byteArrayViewVarHandle(). -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From brett.okken.os at gmail.com Fri Oct 1 14:46:43 2021 From: brett.okken.os at gmail.com (Brett Okken) Date: Fri, 1 Oct 2021 09:46:43 -0500 Subject: StringCoding.hasNegatives In-Reply-To: References: Message-ID: > The current pure Java implementation does two things: it provides a fallback > for pure-interpreter JVMs and it provides the reader with a simple implementation. > I'm not at all sure we'd want a complex implementation. I thought this might be the case. > Having said that, if I were looking at a faster pure Java version of > this logic, I'd look at MethodHandles.byteArrayViewVarHandle(). I considered that, but had 2 concerns: 1. creating potential dependency/initialization order issues 2. creating/managing a constant VarHandle that would never be used with normal compiler behavior Overall it sounds like this is not worthwhile. Thanks for taking a look. Brett From shade at redhat.com Fri Oct 1 14:53:00 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 1 Oct 2021 16:53:00 +0200 Subject: StringCoding.hasNegatives In-Reply-To: References: Message-ID: On 10/1/21 4:46 PM, Brett Okken wrote: >> The current pure Java implementation does two things: it provides a fallback >> for pure-interpreter JVMs and it provides the reader with a simple implementation. >> I'm not at all sure we'd want a complex implementation. > > I thought this might be the case. > >> Having said that, if I were looking at a faster pure Java version of >> this logic, I'd look at MethodHandles.byteArrayViewVarHandle(). > > I considered that, but had 2 concerns: > 1. creating potential dependency/initialization order issues > 2. creating/managing a constant VarHandle that would never be used > with normal compiler behavior Also, interpreter-only VMs are likely to be pessimized by Var/MethodHandles, as they would not be able to fold a lot of code (e.g. checks) on the hotpaths. I have seen this after SHA-2 was rewritten to use byteViews (that one was done for simplicity, rather than directly for performance, I think). Optimizing this does not seem worth it, in my opinion. The only reason to do this would be showing that it improves the interpreter performance so much it improves startup until compilers are coming up with the optimized code. -- Thanks, -Aleksey From claes.redestad at oracle.com Fri Oct 1 16:02:46 2021 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 1 Oct 2021 18:02:46 +0200 Subject: StringCoding.hasNegatives In-Reply-To: References: Message-ID: <6ed81fa4-489e-a99e-5de0-4077ec6653c1@oracle.com> On 2021-10-01 16:53, Aleksey Shipilev wrote: > On 10/1/21 4:46 PM, Brett Okken wrote: >>> The current pure Java implementation does two things: it provides a >>> fallback >>> for pure-interpreter JVMs and it provides the reader with a simple >>> implementation. >>> I'm not at all sure we'd want a complex implementation. >> >> I thought this might be the case. >> >>> Having said that, if I were looking at a faster pure Java version of >>> this logic, I'd look at MethodHandles.byteArrayViewVarHandle(). >> >> I considered that, but had 2 concerns: >> 1. creating potential dependency/initialization order issues >> 2. creating/managing a constant VarHandle that would never be used >> with normal compiler behavior > > Also, interpreter-only VMs are likely to be pessimized by > Var/MethodHandles, as they would not be able to fold a lot of code (e.g. > checks) on the hotpaths. I have seen this after SHA-2 was rewritten to > use byteViews (that one was done for simplicity, rather than directly > for performance, I think). Guilty as charged! I did experiment with some slightly wonky ways to soften the blow to interpreter performance[1], but ultimately opted to maximize simplicity. > > Optimizing this does not seem worth it, in my opinion. The only reason > to do this would be showing that it improves the interpreter performance > so much it improves startup until compilers are coming up with the > optimized code. > I agree with this assessment. Thanks! /Claes [1] https://github.com/openjdk/jdk/pull/1855/commits/4b4fb2dd078eb71bd41ad3cf61b87a93575171a0 From martin at openjdk.java.net Fri Oct 1 17:00:35 2021 From: martin at openjdk.java.net (Martin Buchholz) Date: Fri, 1 Oct 2021 17:00:35 GMT Subject: RFR: 8274349: ForkJoinPool.commonPool() does not work with 1 CPU [v2] In-Reply-To: References: Message-ID: On Fri, 1 Oct 2021 05:10:17 GMT, David Holmes wrote: >> A regression introduced in Java 17 will give the default FJ pool a parallelism of zero in a uniprocessor environment. The fix restores this to a value of 1. See bug report for details. >> >> Testing: >> - new regression test >> - tiers 1-3 >> >> Thanks, >> David > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Updated TCK test component from @martin Marked as reviewed by martin (Reviewer). I always try to avoid Thread.sleep or polling in tests, so I would write the test like this: import java.util.concurrent.CountDownLatch; import java.util.concurrent.ForkJoinPool; public class ForkJoinUniProcessor { public static void main(String[] args) throws InterruptedException { // If the default parallelism were zero then this task would not // complete and the test will timeout. CountDownLatch ran = new CountDownLatch(1); ForkJoinPool.commonPool().submit(() -> ran.countDown()); ran.await(); } } ------------- PR: https://git.openjdk.java.net/jdk/pull/5784 From naoto at openjdk.java.net Fri Oct 1 18:17:27 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 1 Oct 2021 18:17:27 GMT Subject: RFR: 8274544: Langtools command's usage were garbled on Japanese Windows In-Reply-To: References: Message-ID: On Thu, 30 Sep 2021 09:36:34 GMT, Ichiroh Takiguchi wrote: > JEP-400 (UTF-8 by Default) was eabled on JDK18-b13. > After JDK18-b13, javac and some other langtool command's usage were garbled on Japanese Windows. > These commands use PrintWriter instead of standard out/err with PrintStream. The encoding used in `Log.java` should first check whether it is run within console or not. If `System.console()` returns the console, its `.charset()` should be used instead of `native.encoding` value. As to the jshell issue, it is a different issue than javac, so I would expect it to be handled with a different issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/5771 From naoto at openjdk.java.net Fri Oct 1 19:04:47 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 1 Oct 2021 19:04:47 GMT Subject: RFR: 8274658: ISO 4217 Amendment #170 Update Message-ID: <7zuKEb7vzszIUU9VGj6c_VZRqsDhtyTSwvjDXL6b3TY=.e792b2b2-73cf-4c38-8d7c-88dc6405f9ea@github.com> This is to incorporate the ISO 4217 amendment #170, which has been released today, effective immediately. ------------- Commit messages: - 8274658: ISO 4217 Amendment #170 Update Changes: https://git.openjdk.java.net/jdk/pull/5790/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5790&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274658 Stats: 15 lines in 6 files changed: 3 ins; 0 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/5790.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5790/head:pull/5790 PR: https://git.openjdk.java.net/jdk/pull/5790 From lancea at openjdk.java.net Fri Oct 1 20:06:27 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Fri, 1 Oct 2021 20:06:27 GMT Subject: RFR: 8274658: ISO 4217 Amendment #170 Update In-Reply-To: <7zuKEb7vzszIUU9VGj6c_VZRqsDhtyTSwvjDXL6b3TY=.e792b2b2-73cf-4c38-8d7c-88dc6405f9ea@github.com> References: <7zuKEb7vzszIUU9VGj6c_VZRqsDhtyTSwvjDXL6b3TY=.e792b2b2-73cf-4c38-8d7c-88dc6405f9ea@github.com> Message-ID: On Fri, 1 Oct 2021 18:57:28 GMT, Naoto Sato wrote: > This is to incorporate the ISO 4217 amendment #170, which has been released today, effective immediately. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5790 From prr at openjdk.java.net Fri Oct 1 21:10:27 2021 From: prr at openjdk.java.net (Phil Race) Date: Fri, 1 Oct 2021 21:10:27 GMT Subject: RFR: 8274397: [macOS] Stop setting env. var JAVA_MAIN_CLASS_ in launcher code [v4] In-Reply-To: <8j-vMsDYbF5100Dpc1DP_JGNV5V0W0D7i2fP7QnXCpU=.9169a246-f866-49c5-99fb-04f9fb946b9e@github.com> References: <8j-vMsDYbF5100Dpc1DP_JGNV5V0W0D7i2fP7QnXCpU=.9169a246-f866-49c5-99fb-04f9fb946b9e@github.com> Message-ID: <6g0EhtvtHXXr80qFDYESUQ-PhKf97oikta-MnPf2QSY=.4e52ca70-f604-4bbd-b340-9229d6edb118@github.com> > macOS launcher code sets JAVA_MAIN_CLASS_ which is read by AWT to set the name of the application in the system menu bar. > > Because this set shortly after the VM is running, it causes a thread safety issue described in https://bugs.openjdk.java.net/browse/JDK-8270549 > > Since the AWT already looks for the system property "apple.awt.application.name" for this same purpose, > we can set that instead of the env. var and avoid the threading issue. > > This trades the JAVA_MAIN_CLASS_ pollution of the environment for setting a system property which is visible to apps as well but it seems a reasonable trade-off since we already (implicitly) support this variable anyway in preference to the env. var. Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8274397: Stop setting env. var JAVA_MAIN_CLASS_ in launcher code ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5724/files - new: https://git.openjdk.java.net/jdk/pull/5724/files/96a5590c..4c8fb9af Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5724&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5724&range=02-03 Stats: 112 lines in 2 files changed: 112 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5724.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5724/head:pull/5724 PR: https://git.openjdk.java.net/jdk/pull/5724 From prr at openjdk.java.net Fri Oct 1 21:12:34 2021 From: prr at openjdk.java.net (Phil Race) Date: Fri, 1 Oct 2021 21:12:34 GMT Subject: RFR: 8274397: [macOS] Stop setting env. var JAVA_MAIN_CLASS_ in launcher code [v3] In-Reply-To: References: <8j-vMsDYbF5100Dpc1DP_JGNV5V0W0D7i2fP7QnXCpU=.9169a246-f866-49c5-99fb-04f9fb946b9e@github.com> Message-ID: On Wed, 29 Sep 2021 03:39:09 GMT, Phil Race wrote: >> macOS launcher code sets JAVA_MAIN_CLASS_ which is read by AWT to set the name of the application in the system menu bar. >> >> Because this set shortly after the VM is running, it causes a thread safety issue described in https://bugs.openjdk.java.net/browse/JDK-8270549 >> >> Since the AWT already looks for the system property "apple.awt.application.name" for this same purpose, >> we can set that instead of the env. var and avoid the threading issue. >> >> This trades the JAVA_MAIN_CLASS_ pollution of the environment for setting a system property which is visible to apps as well but it seems a reasonable trade-off since we already (implicitly) support this variable anyway in preference to the env. var. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8274397: Stop setting env. var JAVA_MAIN_CLASS_ in launcher code I've now pushed the new test to verify the system property. I've verified the test passes on my local machine but can't (until Monday) be sure it passes in the CI test framework because of power maintenance that has just started. ------------- PR: https://git.openjdk.java.net/jdk/pull/5724 From iris at openjdk.java.net Sat Oct 2 02:44:30 2021 From: iris at openjdk.java.net (Iris Clark) Date: Sat, 2 Oct 2021 02:44:30 GMT Subject: RFR: 8274658: ISO 4217 Amendment 170 Update In-Reply-To: <7zuKEb7vzszIUU9VGj6c_VZRqsDhtyTSwvjDXL6b3TY=.e792b2b2-73cf-4c38-8d7c-88dc6405f9ea@github.com> References: <7zuKEb7vzszIUU9VGj6c_VZRqsDhtyTSwvjDXL6b3TY=.e792b2b2-73cf-4c38-8d7c-88dc6405f9ea@github.com> Message-ID: On Fri, 1 Oct 2021 18:57:28 GMT, Naoto Sato wrote: > This is to incorporate the ISO 4217 amendment #170, which has been released today, effective immediately. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5790 From forax at univ-mlv.fr Sat Oct 2 11:59:24 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 2 Oct 2021 13:59:24 +0200 (CEST) Subject: Discussion: easier Stream closing In-Reply-To: <2606ed74-927c-3c57-aa40-a8811f20883f@oracle.com> References: <2606ed74-927c-3c57-aa40-a8811f20883f@oracle.com> Message-ID: <1015915776.3188031.1633175964853.JavaMail.zimbra@u-pem.fr> At that point, the real question is why not call close() at the end of all terminal operations by wrapping each implementation in a try-with-resources ? R?mi ----- Original Message ----- > From: "Brian Goetz" > To: "Tagir Valeev" , "core-libs-dev" > Sent: Lundi 27 Septembre 2021 22:41:00 > Subject: Re: Discussion: easier Stream closing > In Java 8, I think we were reluctant to lean on the idiom of "pass me a > lambda and I'll pass it the confined data"), because Java developers > were already struggling to understand lambdas.? But now that we're > mostly over that hurdle, API points that accept Consumer are > a powerful way to gain confinement (as we've seen in StackWalker, and > also in the explorations of ScopeLocal in Loom.)? So I have no objection > to this idiom. > > I have some concern that putting these side-by-side with existing > Files.walk(...) methods will be a source of confusion, creating two > different ways to do the same thing. > > I would rather not add anything new to BaseStream; it was a mistake to > expose at all, and I'd rather see it deprecated than add more to it. > However, adding it individually to the Stream implementations is > equivalent, and doesn't have this problem. > > The consumeAndClose approach is clever, in that it adds one API point > that works for all streams, rather than having to add a new API point > for every factory of a closeable stream; on the other hand, it is > dramatically less discoverable, and so requires more education to get > people to use it (and, as you say, has the exception problem.) > > On 9/26/2021 5:27 AM, Tagir Valeev wrote: >> Hello! >> >> With current NIO file API, a very simple problem to get the list of >> all files in the directory requires some ceremony: >> >> List paths; >> try (Stream stream = Files.list(Path.of("/etc"))) { >> paths = stream.toList(); >> } >> >> If we skip try-with-resources, we may experience OS file handles leak, >> so it's desired to keep it. Yet, it requires doing boring stuff. In >> this sense, classic new File("/etc").list() was somewhat more >> convenient (despite its awful error handling). >> >> I like how this problem is solved in StackWalker API [1]: it limits >> the lifetime of the Stream by requiring a user-specified function to >> consume it. After the function is applied, the stream is closed >> automatically. We could add a similar overload to the Files API. As an >> additional feature, we could also translate all UncheckedIOException's >> back to IOException for more uniform exception processing: >> >> /** >> * @param dir The path to the directory >> * @param function function to apply to the stream of directory files >> * @param type of the result >> * @return result of the function >> * @throws IOException if an I/O error occurs when opening the directory, or >> * UncheckedIOException is thrown by the supplied function. >> */ >> public static T list(Path dir, Function, ? >> extends T> function) throws IOException { >> try (Stream stream = Files.list(dir)) { >> return function.apply(stream); >> } >> catch (UncheckedIOException exception) { >> throw exception.getCause(); >> } >> } >> >> In this case, getting the List of all files in the directory will be >> as simple as >> >> List paths = Files.list(Path.of("/etc"), Stream::toList); >> This doesn't limit the flexibility. For example, if we need only file >> names instead of full paths, we can do this: >> List paths = Files.list(Path.of("/etc"), s -> >> s.map(Path::getFileName).toList()); >> >> Alternatively, we could enhance the BaseStream interface in a similar >> way. It won't allow us to translate exceptions, but could be useful >> for every stream that must be closed after consumption: >> >> // in BaseStream: >> >> /** >> * Apply a given function to this stream, then close the stream. >> * No further operation on the stream will be possible after that. >> * >> * @param function function to apply >> * @param type of the function result >> * @return result of the function >> * @see #close() >> */ >> default R consumeAndClose(Function function) { >> try(@SuppressWarnings("unchecked") S s = (S) this) { >> return function.apply(s); >> } >> } >> >> The usage would be a little bit longer but still more pleasant than >> explicit try-with-resources: >> >> List list = Files.list(Path.of("/etc")).consumeAndClose(Stream::toList); >> >> On the other hand, in this case, we are free to put intermediate >> operations outside of consumeAndClose, so we won't need to nest >> everything inside the function. Only terminal operation should be >> placed inside the consumeAndClose. E.g., if we need file names only, >> like above, we can do this: >> >> List list = >> Files.list(Path.of("/etc")).map(Path::getFileName).consumeAndClose(Stream::toList); >> >> What do you think? >> >> >> [1] > > https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/StackWalker.html#walk(java.util.function.Function) From amaembo at gmail.com Sun Oct 3 09:05:51 2021 From: amaembo at gmail.com (Tagir Valeev) Date: Sun, 3 Oct 2021 16:05:51 +0700 Subject: Discussion: easier Stream closing In-Reply-To: <1015915776.3188031.1633175964853.JavaMail.zimbra@u-pem.fr> References: <2606ed74-927c-3c57-aa40-a8811f20883f@oracle.com> <1015915776.3188031.1633175964853.JavaMail.zimbra@u-pem.fr> Message-ID: > At that point, the real question is why not call close() at the end of all terminal operations by wrapping each implementation in a try-with-resources ? Now, it will be incompatible change. Also, this won't work with iterator() and spliterator() terminal operations. I believe it's best described by Brian in this SO answer: https://stackoverflow.com/a/34073306/4856258 Quoted here, for convenience: > Yes, this was a deliberate decision. We considered both alternatives. > > The operating design principle here is "whoever acquires the resource should release the resource". Files don't auto-close when you read to EOF; we expect files to be closed explicitly by whoever opened them. Streams that are backed by IO resources are the same. > > Fortunately, the language provides a mechanism for automating this for you: try-with-resources. Because Stream implements AutoCloseable, you can do: > > try (Stream s = Files.lines(...)) { > s.forEach(...); > } > > The argument that "it would be really convenient to auto-close so I could write it as a one-liner" is nice, but would mostly be the tail wagging the dog. If you opened a file or other resource, you should also be prepared to close it. Effective and consistent resource management trumps "I want to write this in one line", and we chose not to distort the design just to preserve the one-line-ness. With best regards, Tagir Valeev. > > R?mi > > ----- Original Message ----- > > From: "Brian Goetz" > > To: "Tagir Valeev" , "core-libs-dev" > > Sent: Lundi 27 Septembre 2021 22:41:00 > > Subject: Re: Discussion: easier Stream closing > > > In Java 8, I think we were reluctant to lean on the idiom of "pass me a > > lambda and I'll pass it the confined data"), because Java developers > > were already struggling to understand lambdas. But now that we're > > mostly over that hurdle, API points that accept Consumer are > > a powerful way to gain confinement (as we've seen in StackWalker, and > > also in the explorations of ScopeLocal in Loom.) So I have no objection > > to this idiom. > > > > I have some concern that putting these side-by-side with existing > > Files.walk(...) methods will be a source of confusion, creating two > > different ways to do the same thing. > > > > I would rather not add anything new to BaseStream; it was a mistake to > > expose at all, and I'd rather see it deprecated than add more to it. > > However, adding it individually to the Stream implementations is > > equivalent, and doesn't have this problem. > > > > The consumeAndClose approach is clever, in that it adds one API point > > that works for all streams, rather than having to add a new API point > > for every factory of a closeable stream; on the other hand, it is > > dramatically less discoverable, and so requires more education to get > > people to use it (and, as you say, has the exception problem.) > > > > On 9/26/2021 5:27 AM, Tagir Valeev wrote: > >> Hello! > >> > >> With current NIO file API, a very simple problem to get the list of > >> all files in the directory requires some ceremony: > >> > >> List paths; > >> try (Stream stream = Files.list(Path.of("/etc"))) { > >> paths = stream.toList(); > >> } > >> > >> If we skip try-with-resources, we may experience OS file handles leak, > >> so it's desired to keep it. Yet, it requires doing boring stuff. In > >> this sense, classic new File("/etc").list() was somewhat more > >> convenient (despite its awful error handling). > >> > >> I like how this problem is solved in StackWalker API [1]: it limits > >> the lifetime of the Stream by requiring a user-specified function to > >> consume it. After the function is applied, the stream is closed > >> automatically. We could add a similar overload to the Files API. As an > >> additional feature, we could also translate all UncheckedIOException's > >> back to IOException for more uniform exception processing: > >> > >> /** > >> * @param dir The path to the directory > >> * @param function function to apply to the stream of directory files > >> * @param type of the result > >> * @return result of the function > >> * @throws IOException if an I/O error occurs when opening the directory, or > >> * UncheckedIOException is thrown by the supplied function. > >> */ > >> public static T list(Path dir, Function, ? > >> extends T> function) throws IOException { > >> try (Stream stream = Files.list(dir)) { > >> return function.apply(stream); > >> } > >> catch (UncheckedIOException exception) { > >> throw exception.getCause(); > >> } > >> } > >> > >> In this case, getting the List of all files in the directory will be > >> as simple as > >> > >> List paths = Files.list(Path.of("/etc"), Stream::toList); > >> This doesn't limit the flexibility. For example, if we need only file > >> names instead of full paths, we can do this: > >> List paths = Files.list(Path.of("/etc"), s -> > >> s.map(Path::getFileName).toList()); > >> > >> Alternatively, we could enhance the BaseStream interface in a similar > >> way. It won't allow us to translate exceptions, but could be useful > >> for every stream that must be closed after consumption: > >> > >> // in BaseStream: > >> > >> /** > >> * Apply a given function to this stream, then close the stream. > >> * No further operation on the stream will be possible after that. > >> * > >> * @param function function to apply > >> * @param type of the function result > >> * @return result of the function > >> * @see #close() > >> */ > >> default R consumeAndClose(Function function) { > >> try(@SuppressWarnings("unchecked") S s = (S) this) { > >> return function.apply(s); > >> } > >> } > >> > >> The usage would be a little bit longer but still more pleasant than > >> explicit try-with-resources: > >> > >> List list = Files.list(Path.of("/etc")).consumeAndClose(Stream::toList); > >> > >> On the other hand, in this case, we are free to put intermediate > >> operations outside of consumeAndClose, so we won't need to nest > >> everything inside the function. Only terminal operation should be > >> placed inside the consumeAndClose. E.g., if we need file names only, > >> like above, we can do this: > >> > >> List list = > >> Files.list(Path.of("/etc")).map(Path::getFileName).consumeAndClose(Stream::toList); > >> > >> What do you think? > >> > >> > >> [1] > > > https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/StackWalker.html#walk(java.util.function.Function) From plevart at openjdk.java.net Mon Oct 4 06:39:19 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Mon, 4 Oct 2021 06:39:19 GMT Subject: RFR: 8274299: Make Method/Constructor/Field accessors @Stable [v3] In-Reply-To: References: Message-ID: > This patch improves reflective access speed as shown by the included benchmarks: > > https://jmh.morethan.io/?gists=902f4b43519c4f96c7abcd14cdc2d27d,ac490481e3001c710d75d6071c10b23a > > ... and is also a prerequisite to make JEP 416 (Reimplement Core Reflection with Method Handle) perform better in some circumstances. Peter Levart has 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. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5694/files - new: https://git.openjdk.java.net/jdk/pull/5694/files/1f273e9a..0298253e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5694&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5694&range=01-02 Stats: 28 lines in 3 files changed: 0 ins; 0 del; 28 mod Patch: https://git.openjdk.java.net/jdk/pull/5694.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5694/head:pull/5694 PR: https://git.openjdk.java.net/jdk/pull/5694 From plevart at openjdk.java.net Mon Oct 4 06:39:29 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Mon, 4 Oct 2021 06:39:29 GMT Subject: RFR: 8274299: Make Method/Constructor/Field accessors @Stable [v2] In-Reply-To: References: Message-ID: On Tue, 28 Sep 2021 22:41:23 GMT, Claes Redestad wrote: > I'm fine with going back to the previous iteration. I'd add `@Stable` to the same fields in `Constructor`, too, though. Good catch. I'll add @stable to select Constructor fields. They are important for optimizing `Const` use cases. I'll also extend benchmarks to include Constructor accesses. ------------- PR: https://git.openjdk.java.net/jdk/pull/5694 From tvaleev at openjdk.java.net Mon Oct 4 06:51:55 2021 From: tvaleev at openjdk.java.net (Tagir F.Valeev) Date: Mon, 4 Oct 2021 06:51:55 GMT Subject: RFR: 8274412: Add a method to Stream API to consume and close the stream without using try-with-resources Message-ID: Currently, when the stream holds a resource, it's necessary to wrap it with try-with-resources. This undermines the compact and fluent style of stream API calls. For example, if we want to get the `List` of files inside the directory and timely close the underlying filehandle, we should use something like this: List paths; try (Stream stream = Files.list(Path.of("/etc"))) { paths = stream.toList(); } // use paths I suggest to add a new default method to Stream interface named `consumeAndClose`, which allows performing terminal stream operation and closing the stream at the same time. It may look like this: default R consumeAndClose(Function, ? extends R> function) { Objects.requireNonNull(function); try(this) { return function.apply(this); } } Now, it will be possible to get the list of the files in the fluent manner: List list = Files.list(Path.of("/etc")).consumeAndClose(Stream::toList); ------------- Commit messages: - Fix tests - 8274412: Add a method to Stream API to consume and close the stream without using try-with-resources Changes: https://git.openjdk.java.net/jdk/pull/5796/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5796&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274412 Stats: 140 lines in 5 files changed: 135 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/5796.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5796/head:pull/5796 PR: https://git.openjdk.java.net/jdk/pull/5796 From itakiguchi at openjdk.java.net Mon Oct 4 07:13:37 2021 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Mon, 4 Oct 2021 07:13:37 GMT Subject: RFR: 8274544: Langtools command's usage were garbled on Japanese Windows [v2] In-Reply-To: References: Message-ID: > JEP-400 (UTF-8 by Default) was eabled on JDK18-b13. > After JDK18-b13, javac and some other langtool command's usage were garbled on Japanese Windows. > These commands use PrintWriter instead of standard out/err with PrintStream. Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision: 8274544: Langtools command's usage were garbled on Japanese Windows ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5771/files - new: https://git.openjdk.java.net/jdk/pull/5771/files/f348c26e..bfe90241 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5771&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5771&range=00-01 Stats: 194 lines in 11 files changed: 141 ins; 34 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/5771.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5771/head:pull/5771 PR: https://git.openjdk.java.net/jdk/pull/5771 From itakiguchi at openjdk.java.net Mon Oct 4 08:50:12 2021 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Mon, 4 Oct 2021 08:50:12 GMT Subject: RFR: 8274544: Langtools command's usage were garbled on Japanese Windows In-Reply-To: References: Message-ID: On Fri, 1 Oct 2021 18:14:11 GMT, Naoto Sato wrote: >> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13. >> After JDK18-b13, javac and some other langtool command's usage were garbled on Japanese Windows. >> These commands use PrintWriter instead of standard out/err with PrintStream. > > The encoding used in `Log.java` should first check whether it is run within console or not. If `System.console()` returns the console, its `.charset()` should be used instead of `native.encoding` value. > As to the jshell issue, it is a different issue than javac, so I would expect it to be handled with a different issue. Helllo @naotoj . I used `System.console()` and `Console.charset()`. The following executables had same issue, I fixed them. > jar.exe, javac.exe, javadoc.exe, javap.exe, jdeps.exe, jlink.exe, jmod.exe, jpackage.exe I could not find out the following executables had same issue or not > jabswitch.exe, jcmd.exe, jfr.exe, jhsdb.exe, jimage.exe, jinfo.exe, jmap.exe, jps.exe, jrunscript.exe, jstack.exe, jstat.exe, jstatd.exe, kinit.exe, klist.exe, ktab.exe The following executables worked fine. > jarsigner.exe, java.exe, javaw.exe, jdb.exe, jdeprscan.exe, jshell.exe, keytool.exe, rmiregistry.exe, serialver.exe The following executables were GUI apps > jaccessinspector.exe, jaccesswalker.exe, jconsole.exe These fixes don't have testcases. Do you have any idea about testcase for this issue ? ------------- PR: https://git.openjdk.java.net/jdk/pull/5771 From jlahoda at openjdk.java.net Mon Oct 4 10:27:08 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 4 Oct 2021 10:27:08 GMT Subject: RFR: 8274544: Langtools command's usage were garbled on Japanese Windows In-Reply-To: References: Message-ID: On Mon, 4 Oct 2021 08:47:26 GMT, Ichiroh Takiguchi wrote: >> The encoding used in `Log.java` should first check whether it is run within console or not. If `System.console()` returns the console, its `.charset()` should be used instead of `native.encoding` value. >> As to the jshell issue, it is a different issue than javac, so I would expect it to be handled with a different issue. > > Helllo @naotoj . > I used `System.console()` and `Console.charset()`. > > The following executables had same issue, I fixed them. >> jar.exe, javac.exe, javadoc.exe, javap.exe, jdeps.exe, jlink.exe, jmod.exe, jpackage.exe > > I could not find out the following executables had same issue or not >> jabswitch.exe, jcmd.exe, jfr.exe, jhsdb.exe, jimage.exe, jinfo.exe, jmap.exe, jps.exe, jrunscript.exe, jstack.exe, jstat.exe, jstatd.exe, kinit.exe, klist.exe, ktab.exe > > The following executables worked fine. >> jarsigner.exe, java.exe, javaw.exe, jdb.exe, jdeprscan.exe, jshell.exe, keytool.exe, rmiregistry.exe, serialver.exe > > The following executables were GUI apps >> jaccessinspector.exe, jaccesswalker.exe, jconsole.exe > > These fixes don't have testcases. > Do you have any idea about testcase for this issue ? @takiguc - if JShell is still an issue, is there a chance you could try this: https://github.com/lahodaj/jdk/commit/cfa6b3eebbc22c5a48d31cfd692ff98690653686 Not sure if it will help, but it might (this won't change the default charset, but could send the output in a sensible encoding for the console. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/5771 From sergei.tsypanov at yandex.ru Mon Oct 4 11:57:17 2021 From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=) Date: Mon, 04 Oct 2021 13:57:17 +0200 Subject: Optimization (?) of HashSet(Collection) Message-ID: <909441633346463@mail.yandex.ru> Hello, in the code of HashSet(Collection) we have an optimization opportunity: public HashSet(Collection c) { map = new HashMap<>(Math.max((int) (c.size()/.75f) + 1, 16)); addAll(c); } instead of using addAll() inherited from j.u.Collection we can use c.forEach(this::add): public HashSet(Collection c) { map = new HashMap<>(Math.max((int) (c.size()/.75f) + 1, 16)); c.forEach(this::add); } This allows to rid Iterator and use counting loops for e.g. ArrayList instead of hasNext()/next(). To me the most common use cases of HashSet(Collection) are those: - ArrayList/Arrays.asList() is passed to convert List->Set or/and excluded duplicates - HashSet is passed to have a copy of original Set We are also likely to benefit from this change in case the argument collection is synchronized as it's going to be locked only once. I've used the benchmark [1] to analyze the impact and it demonstrates measurable improvement [2]. What puzzles we a bit is the result for j.u.ArrayList. At warm-up time it demonstrates better results than at measurement time: length = 10 # Run progress: 4,44% complete, ETA 00:21:41 # Fork: 3 of 5 # Warmup Iteration 1: 134,699 ns/op # Warmup Iteration 2: 115,391 ns/op # Warmup Iteration 3: 130,110 ns/op # Warmup Iteration 4: 114,465 ns/op <---- # Warmup Iteration 5: 114,849 ns/op # Warmup Iteration 6: 115,073 ns/op # Warmup Iteration 7: 113,988 ns/op # Warmup Iteration 8: 115,301 ns/op # Warmup Iteration 9: 115,452 ns/op # Warmup Iteration 10: 124,493 ns/op <---- Iteration 1: 123,776 ns/op Iteration 2: 123,719 ns/op Iteration 3: 123,725 ns/op Iteration 4: 126,892 ns/op Iteration 5: 125,493 ns/op Iteration 6: 124,661 ns/op Iteration 7: 123,783 ns/op Iteration 8: 123,975 ns/op Iteration 9: 124,047 ns/op Iteration 10: 123,899 ns/op length = 100 # Run progress: 11,11% complete, ETA 00:20:10 # Fork: 1 of 5 # Warmup Iteration 1: 1236,695 ns/op # Warmup Iteration 2: 1069,909 ns/op # Warmup Iteration 3: 1243,852 ns/op # Warmup Iteration 4: 1059,038 ns/op <---- # Warmup Iteration 5: 1057,670 ns/op # Warmup Iteration 6: 1057,117 ns/op # Warmup Iteration 7: 1056,932 ns/op # Warmup Iteration 8: 1054,909 ns/op # Warmup Iteration 9: 1058,106 ns/op # Warmup Iteration 10: 1145,699 ns/op <---- Iteration 1: 1139,155 ns/op Iteration 2: 1141,662 ns/op Iteration 3: 1139,061 ns/op Iteration 4: 1139,306 ns/op Iteration 5: 1138,475 ns/op Iteration 6: 1140,491 ns/op Iteration 7: 1144,017 ns/op Iteration 8: 1139,411 ns/op Iteration 9: 1142,729 ns/op Iteration 10: 1144,042 ns/op Here I use 1 s warm-up iteration on 2s measurement iteration. It looks like at iteration 4 the code is top-optimized, and later at the end of warm-up a kind of deoptimization happens. There's still visible improvement however. The benchmark is run with 5 forks, and this deoptimization is visible for length = {10, 100}. So my two question are: - What is the reason of the deoptimization and can we do something about it? - Whether suggested changes is worth implementations? Regards, Sergey Tsypanov 1. @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) public class HashSetBenchmark { @Benchmark public HashSet fromArrayList(Data data) { return new HashSet<>(data.arrayList); } @Benchmark public HashSet fromHashSet(Data data) { return new HashSet<>(data.hashSet); } @Benchmark public HashSet fromArraysAsList(Data data) { return new HashSet<>(data.arraysAsList); } @State(Scope.Thread) public static class Data { private ArrayList arrayList; private HashSet hashSet; private List arraysAsList; @Param({"10", "100", "1000"}) private int length; @Setup public void setup() throws IOException { var array = new Integer[length]; for (int i = 0; i < length; i++) { array[i] = i; } arraysAsList = Arrays.asList(array); arrayList = new ArrayList<>(arraysAsList); hashSet = new HashSet<>(arraysAsList); } } } 2. baseline Benchmark (length) Mode Cnt Score Error Units HashSetBenchmark.fromArrayList 10 avgt 50 127,838 ? 1,822 ns/op HashSetBenchmark.fromArrayList 100 avgt 50 1209,543 ? 8,435 ns/op HashSetBenchmark.fromArrayList 1000 avgt 50 11915,334 ? 155,908 ns/op HashSetBenchmark.fromArraysAsList 10 avgt 50 130,049 ? 1,661 ns/op HashSetBenchmark.fromArraysAsList 100 avgt 50 1138,407 ? 19,998 ns/op HashSetBenchmark.fromArraysAsList 1000 avgt 50 11345,099 ? 83,086 ns/op HashSetBenchmark.fromHashSet 10 avgt 50 184,559 ? 1,387 ns/op HashSetBenchmark.fromHashSet 100 avgt 50 2001,577 ? 42,321 ns/op HashSetBenchmark.fromHashSet 1000 avgt 50 17535,017 ? 199,892 ns/op patched Benchmark (length) Mode Cnt Score Error Units HashSetBenchmark.fromArrayList 10 avgt 50 125,075 ? 0,907 ns/op HashSetBenchmark.fromArrayList 100 avgt 50 1127,378 ? 19,368 ns/op HashSetBenchmark.fromArrayList 1000 avgt 50 11455,172 ? 61,543 ns/op HashSetBenchmark.fromArraysAsList 10 avgt 50 117,634 ? 3,641 ns/op HashSetBenchmark.fromArraysAsList 100 avgt 50 1034,538 ? 11,958 ns/op HashSetBenchmark.fromArraysAsList 1000 avgt 50 10786,914 ? 137,330 ns/op HashSetBenchmark.fromHashSet 10 avgt 50 173,727 ? 2,177 ns/op HashSetBenchmark.fromHashSet 100 avgt 50 1748,858 ? 12,535 ns/op HashSetBenchmark.fromHashSet 1000 avgt 50 16474,208 ? 97,578 ns/op From akasko at openjdk.java.net Mon Oct 4 12:42:11 2021 From: akasko at openjdk.java.net (Alex Kasko) Date: Mon, 4 Oct 2021 12:42:11 GMT Subject: Integrated: 8274606: Fix jaxp/javax/xml/jaxp/unittest/transform/SurrogateTest.java test In-Reply-To: References: Message-ID: On Thu, 30 Sep 2021 18:32:17 GMT, Alex Kasko wrote: > I was working on backporting JDK-8268457 and found minor problems with the test introduced there: > > 1. `compareWith*` helper methods are used without `Assert.assertTrue()` wrapping, so they are effectively ignored > > 2. `this.getClass().getResourceAsStream()` is used to load test input data, it actually returns null in test run, so transformation is done without input data > > Note, that SurrogateTest.zip reproducer attached to JDK-8268457 is valid and fully functional, problems likely were introduced when it was adapted into test. > > The change is to the test only, it wraps `compareWith*` helpers and loads data the same way as XSL is loaded. Additionally `compareStringWithGold` was changed to `compareLinesWithGold` to exclude possible line endings problems. > > Testing: checked that the test fails when JDK-8268457 code fix is reverted, checked that is passes on master. This pull request has now been integrated. Changeset: 7eb0372e Author: Alex Kasko Committer: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/7eb0372e55f23275b12470593adc97f1b79bc965 Stats: 10 lines in 1 file changed: 3 ins; 1 del; 6 mod 8274606: Fix jaxp/javax/xml/jaxp/unittest/transform/SurrogateTest.java test Reviewed-by: joehw, shade ------------- PR: https://git.openjdk.java.net/jdk/pull/5779 From github.com+10835776+stsypanov at openjdk.java.net Mon Oct 4 13:04:23 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 4 Oct 2021 13:04:23 GMT Subject: RFR: 8274715: Implement forEach in Collections.CopiesList Message-ID: Originally was proposed by Zheka Kozlov here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-December/057192.html Just a tiny optimization: we can use for-i loop instead of `Iterable.forEach()` which is relying on iterator. Simple benchmark demonstrates slight improvement: @State(Scope.Thread) @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) public class NCopiesBenchmarks { @Param({"10", "50", "100"}) int size; private List list; @Setup public void prepare() { list = Collections.nCopies(size, new Object()); } @Benchmark public void forEach(Blackhole bh) { list.forEach(bh::consume); } } before Benchmark (size) Mode Cnt Score Error Units NCopiesBenchmarks.forEach 10 avgt 50 40.737 ? 1.854 ns/op NCopiesBenchmarks.forEach:?gc.alloc.rate 10 avgt 50 0.001 ? 0.001 MB/sec NCopiesBenchmarks.forEach:?gc.alloc.rate.norm 10 avgt 50 ? 10?? B/op NCopiesBenchmarks.forEach:?gc.count 10 avgt 50 ? 0 counts NCopiesBenchmarks.forEach 50 avgt 50 213.324 ? 3.784 ns/op NCopiesBenchmarks.forEach:?gc.alloc.rate 50 avgt 50 0.001 ? 0.001 MB/sec NCopiesBenchmarks.forEach:?gc.alloc.rate.norm 50 avgt 50 ? 10?? B/op NCopiesBenchmarks.forEach:?gc.count 50 avgt 50 ? 0 counts NCopiesBenchmarks.forEach 100 avgt 50 443.171 ? 17.919 ns/op NCopiesBenchmarks.forEach:?gc.alloc.rate 100 avgt 50 0.001 ? 0.001 MB/sec NCopiesBenchmarks.forEach:?gc.alloc.rate.norm 100 avgt 50 0.001 ? 0.001 B/op NCopiesBenchmarks.forEach:?gc.count 100 avgt 50 ? 0 counts after Benchmark (size) Mode Cnt Score Error Units NCopiesBenchmarks.forEach 10 avgt 50 36.838 ? 0.065 ns/op NCopiesBenchmarks.forEach:?gc.alloc.rate 10 avgt 50 0.001 ? 0.001 MB/sec NCopiesBenchmarks.forEach:?gc.alloc.rate.norm 10 avgt 50 ? 10?? B/op NCopiesBenchmarks.forEach:?gc.count 10 avgt 50 ? 0 counts NCopiesBenchmarks.forEach 50 avgt 50 191.173 ? 0.570 ns/op NCopiesBenchmarks.forEach:?gc.alloc.rate 50 avgt 50 0.001 ? 0.001 MB/sec NCopiesBenchmarks.forEach:?gc.alloc.rate.norm 50 avgt 50 ? 10?? B/op NCopiesBenchmarks.forEach:?gc.count 50 avgt 50 ? 0 counts NCopiesBenchmarks.forEach 100 avgt 50 376.675 ? 2.476 ns/op NCopiesBenchmarks.forEach:?gc.alloc.rate 100 avgt 50 0.001 ? 0.001 MB/sec NCopiesBenchmarks.forEach:?gc.alloc.rate.norm 100 avgt 50 0.001 ? 0.001 B/op NCopiesBenchmarks.forEach:?gc.count 100 avgt 50 ? 0 counts ------------- Commit messages: - Implement forEach in Collections.CopiesList Changes: https://git.openjdk.java.net/jdk/pull/2524/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2524&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274715 Stats: 15 lines in 1 file changed: 10 ins; 2 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2524.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2524/head:pull/2524 PR: https://git.openjdk.java.net/jdk/pull/2524 From github.com+7806504+liach at openjdk.java.net Mon Oct 4 13:04:23 2021 From: github.com+7806504+liach at openjdk.java.net (liach) Date: Mon, 4 Oct 2021 13:04:23 GMT Subject: RFR: 8274715: Implement forEach in Collections.CopiesList In-Reply-To: References: Message-ID: On Thu, 11 Feb 2021 13:28:49 GMT, ?????? ??????? wrote: > Originally was proposed by Zheka Kozlov here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-December/057192.html > > Just a tiny optimization: we can use for-i loop instead of `Iterable.forEach()` which is relying on iterator. > > Simple benchmark demonstrates slight improvement: > > @State(Scope.Thread) > @BenchmarkMode(Mode.AverageTime) > @OutputTimeUnit(TimeUnit.NANOSECONDS) > public class NCopiesBenchmarks { > @Param({"10", "50", "100"}) > int size; > > private List list; > > @Setup > public void prepare() { > list = Collections.nCopies(size, new Object()); > } > > @Benchmark > public void forEach(Blackhole bh) { > list.forEach(bh::consume); > } > } > > > > before > > Benchmark (size) Mode Cnt Score Error Units > NCopiesBenchmarks.forEach 10 avgt 50 40.737 ? 1.854 ns/op > NCopiesBenchmarks.forEach:?gc.alloc.rate 10 avgt 50 0.001 ? 0.001 MB/sec > NCopiesBenchmarks.forEach:?gc.alloc.rate.norm 10 avgt 50 ? 10?? B/op > NCopiesBenchmarks.forEach:?gc.count 10 avgt 50 ? 0 counts > NCopiesBenchmarks.forEach 50 avgt 50 213.324 ? 3.784 ns/op > NCopiesBenchmarks.forEach:?gc.alloc.rate 50 avgt 50 0.001 ? 0.001 MB/sec > NCopiesBenchmarks.forEach:?gc.alloc.rate.norm 50 avgt 50 ? 10?? B/op > NCopiesBenchmarks.forEach:?gc.count 50 avgt 50 ? 0 counts > NCopiesBenchmarks.forEach 100 avgt 50 443.171 ? 17.919 ns/op > NCopiesBenchmarks.forEach:?gc.alloc.rate 100 avgt 50 0.001 ? 0.001 MB/sec > NCopiesBenchmarks.forEach:?gc.alloc.rate.norm 100 avgt 50 0.001 ? 0.001 B/op > NCopiesBenchmarks.forEach:?gc.count 100 avgt 50 ? 0 counts > > after > > Benchmark (size) Mode Cnt Score Error Units > NCopiesBenchmarks.forEach 10 avgt 50 36.838 ? 0.065 ns/op > NCopiesBenchmarks.forEach:?gc.alloc.rate 10 avgt 50 0.001 ? 0.001 MB/sec > NCopiesBenchmarks.forEach:?gc.alloc.rate.norm 10 avgt 50 ? 10?? B/op > NCopiesBenchmarks.forEach:?gc.count 10 avgt 50 ? 0 counts > NCopiesBenchmarks.forEach 50 avgt 50 191.173 ? 0.570 ns/op > NCopiesBenchmarks.forEach:?gc.alloc.rate 50 avgt 50 0.001 ? 0.001 MB/sec > NCopiesBenchmarks.forEach:?gc.alloc.rate.norm 50 avgt 50 ? 10?? B/op > NCopiesBenchmarks.forEach:?gc.count 50 avgt 50 ? 0 counts > NCopiesBenchmarks.forEach 100 avgt 50 376.675 ? 2.476 ns/op > NCopiesBenchmarks.forEach:?gc.alloc.rate 100 avgt 50 0.001 ? 0.001 MB/sec > NCopiesBenchmarks.forEach:?gc.alloc.rate.norm 100 avgt 50 0.001 ? 0.001 B/op > NCopiesBenchmarks.forEach:?gc.count 100 avgt 50 ? 0 counts Marked as reviewed by liach at github.com (no known OpenJDK username). ------------- PR: https://git.openjdk.java.net/jdk/pull/2524 From rrich at openjdk.java.net Mon Oct 4 13:59:23 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Mon, 4 Oct 2021 13:59:23 GMT Subject: RFR: 8274716: JDWP Spec: the description for the Dispose command confuses suspend with resume. Message-ID: The following sentence in the JDWP Specification describing the Dispose command confuses resume with suspend [1]: All threads suspended by the thread-level **resume** command or the VM-level **resume** command are resumed as many times as necessary for them to run. It should be changed to All threads suspended by the thread-level **suspend** command or the VM-level **suspend** command are resumed as many times as necessary for them to run. [1] [JDWP Spec, Dispose Command (JDK17).](https://docs.oracle.com/en/java/javase/17/docs/specs/jdwp/jdwp-protocol.html#JDWP_VirtualMachine_Dispose) ------------- Commit messages: - Correct JDWP spec, Dispose command. Changes: https://git.openjdk.java.net/jdk/pull/5804/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5804&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274716 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5804.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5804/head:pull/5804 PR: https://git.openjdk.java.net/jdk/pull/5804 From weijun at openjdk.java.net Mon Oct 4 14:25:14 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 4 Oct 2021 14:25:14 GMT Subject: RFR: 8274333: Redundant null comparison after Pattern.split In-Reply-To: References: Message-ID: On Sun, 26 Sep 2021 15:10:52 GMT, Andrey Turbanov wrote: > In couple of classes, result part of arrays of Pattern.split is compared with `null`. Pattern.split (and hence String.split) never returns `null` in array elements. Such comparisons are redundant. Marked as reviewed by weijun (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5708 From naoto at openjdk.java.net Mon Oct 4 15:10:13 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 4 Oct 2021 15:10:13 GMT Subject: Integrated: 8274658: ISO 4217 Amendment 170 Update In-Reply-To: <7zuKEb7vzszIUU9VGj6c_VZRqsDhtyTSwvjDXL6b3TY=.e792b2b2-73cf-4c38-8d7c-88dc6405f9ea@github.com> References: <7zuKEb7vzszIUU9VGj6c_VZRqsDhtyTSwvjDXL6b3TY=.e792b2b2-73cf-4c38-8d7c-88dc6405f9ea@github.com> Message-ID: On Fri, 1 Oct 2021 18:57:28 GMT, Naoto Sato wrote: > This is to incorporate the ISO 4217 amendment #170, which has been released today, effective immediately. This pull request has now been integrated. Changeset: f2404d60 Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/f2404d60de2b58c590bf885f5cce50c289073673 Stats: 15 lines in 6 files changed: 3 ins; 0 del; 12 mod 8274658: ISO 4217 Amendment 170 Update Reviewed-by: lancea, iris ------------- PR: https://git.openjdk.java.net/jdk/pull/5790 From john_platts at hotmail.com Mon Oct 4 15:47:48 2021 From: john_platts at hotmail.com (John Platts) Date: Mon, 4 Oct 2021 15:47:48 +0000 Subject: Windows 10 (since Windows 10 version 1903) and Windows 11 support UTF-8 as the default codepage through an executable manifest option Message-ID: Windows 10 (since Windows 10 version 1903) and Windows 11 support UTF-8 as the default codepage by setting an option in the application manifest. To enable UTF-8 as the default codepage for JDK executables on Windows 10 (starting with the May 2019 update) and Windows 11, the following modifications can be made to the src/java.base/windows/native/launcher/java.manifest file (or the jdk/src/windows/resource/java.manifest in JDK 8): ... true/PM PerMonitorV2, PerMonitor, system UTF-8 ... The GetACP() and GetOEMCP() API's will both return 65001 on Windows 10 Version 1903 or later if UTF-8 element is added to the executable manifest. GetLocaleInfo(lcid, LOCALE_IDEFAULTANSICODEPAGE, ret+2, 14) will return different results from GetACP() if UTF-8 is present in the executable manifest, and java.nio.charset.Charset.defaultCharset() should return StandardCharsets.UTF_8 on Windows platforms if GetACP() returns 65001. From plevart at openjdk.java.net Mon Oct 4 15:49:43 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Mon, 4 Oct 2021 15:49:43 GMT Subject: RFR: 8274299: Make Method/Constructor/Field accessors @Stable [v4] In-Reply-To: References: Message-ID: > This patch improves reflective access speed as shown by the included benchmarks: > > https://jmh.morethan.io/?gists=902f4b43519c4f96c7abcd14cdc2d27d,ac490481e3001c710d75d6071c10b23a > > ... and is also a prerequisite to make JEP 416 (Reimplement Core Reflection with Method Handle) perform better in some circumstances. Peter Levart has updated the pull request incrementally with one additional commit since the last revision: More @stable fields in Constructor/Field to align them with Method fields ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5694/files - new: https://git.openjdk.java.net/jdk/pull/5694/files/0298253e..0d8ccc87 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5694&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5694&range=02-03 Stats: 3 lines in 2 files changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5694.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5694/head:pull/5694 PR: https://git.openjdk.java.net/jdk/pull/5694 From plevart at openjdk.java.net Mon Oct 4 15:54:07 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Mon, 4 Oct 2021 15:54:07 GMT Subject: RFR: 8274299: Make Method/Constructor/Field accessors @Stable [v2] In-Reply-To: References: Message-ID: On Sat, 2 Oct 2021 15:31:35 GMT, Peter Levart wrote: > > I'm fine with going back to the previous iteration. I'd add `@Stable` to the same fields in `Constructor`, too, though. > > Good catch. I'll add @stable to select Constructor fields. They are important for optimizing `Const` use cases. I checked the git history. `@Stable` annotation was added to `Method::clazz` and `Method::modifiers` fields as part of "JDK-8159746: (proxy) Support for default methods" to speed-up checks since Method instances in Proxy class are assigned to static final fields so this is an example of "Const" use case. But reflective access uses those two fields to perform access checks too, so it makes sense to add @stable to those fields in Field and Constructor classes too. ------------- PR: https://git.openjdk.java.net/jdk/pull/5694 From naoto at openjdk.java.net Mon Oct 4 16:44:09 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 4 Oct 2021 16:44:09 GMT Subject: RFR: 8274544: Langtools command's usage were garbled on Japanese Windows [v2] In-Reply-To: References: Message-ID: On Mon, 4 Oct 2021 07:13:37 GMT, Ichiroh Takiguchi wrote: >> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13. >> After JDK18-b13, javac and some other langtool command's usage were garbled on Japanese Windows. >> These commands use PrintWriter instead of standard out/err with PrintStream. > > Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision: > > 8274544: Langtools command's usage were garbled on Japanese Windows src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java line 265: > 263: * @return a map of writers > 264: */ > 265: private final static Charset nativeCharset; Inserting this static initializer in the middle of a method, between its javadoc and impl, is odd. src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java line 267: > 265: private final static Charset nativeCharset; > 266: static { > 267: Charset cs = Charset.defaultCharset(); This could move into the `catch` section as a last resort. src/jdk.jdeps/share/classes/com/sun/tools/javap/JavapTask.java line 419: > 417: return new PrintWriter(System.err, true, nativeCharset); > 418: } else { > 419: if (s.equals((OutputStream)System.err) || s.equals((OutputStream)System.out)) { Can we use `==` here? src/jdk.jpackage/share/classes/jdk/jpackage/main/Main.java line 50: > 48: * @param args command line arguments > 49: */ > 50: private final static Charset nativeCharset; Static initializer dissecting main method (javadoc/impl) ------------- PR: https://git.openjdk.java.net/jdk/pull/5771 From martin at openjdk.java.net Mon Oct 4 16:54:10 2021 From: martin at openjdk.java.net (Martin Buchholz) Date: Mon, 4 Oct 2021 16:54:10 GMT Subject: RFR: 8274715: Implement forEach in Collections.CopiesList In-Reply-To: References: Message-ID: On Thu, 11 Feb 2021 13:28:49 GMT, ?????? ??????? wrote: > Originally was proposed by Zheka Kozlov here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-December/057192.html > > Just a tiny optimization: we can use for-i loop instead of `Iterable.forEach()` which is relying on iterator. > > Simple benchmark demonstrates slight improvement: > > @State(Scope.Thread) > @BenchmarkMode(Mode.AverageTime) > @OutputTimeUnit(TimeUnit.NANOSECONDS) > public class NCopiesBenchmarks { > @Param({"10", "50", "100"}) > int size; > > private List list; > > @Setup > public void prepare() { > list = Collections.nCopies(size, new Object()); > } > > @Benchmark > public void forEach(Blackhole bh) { > list.forEach(bh::consume); > } > } > > > > before > > Benchmark (size) Mode Cnt Score Error Units > NCopiesBenchmarks.forEach 10 avgt 50 40.737 ? 1.854 ns/op > NCopiesBenchmarks.forEach:?gc.alloc.rate 10 avgt 50 0.001 ? 0.001 MB/sec > NCopiesBenchmarks.forEach:?gc.alloc.rate.norm 10 avgt 50 ? 10?? B/op > NCopiesBenchmarks.forEach:?gc.count 10 avgt 50 ? 0 counts > NCopiesBenchmarks.forEach 50 avgt 50 213.324 ? 3.784 ns/op > NCopiesBenchmarks.forEach:?gc.alloc.rate 50 avgt 50 0.001 ? 0.001 MB/sec > NCopiesBenchmarks.forEach:?gc.alloc.rate.norm 50 avgt 50 ? 10?? B/op > NCopiesBenchmarks.forEach:?gc.count 50 avgt 50 ? 0 counts > NCopiesBenchmarks.forEach 100 avgt 50 443.171 ? 17.919 ns/op > NCopiesBenchmarks.forEach:?gc.alloc.rate 100 avgt 50 0.001 ? 0.001 MB/sec > NCopiesBenchmarks.forEach:?gc.alloc.rate.norm 100 avgt 50 0.001 ? 0.001 B/op > NCopiesBenchmarks.forEach:?gc.count 100 avgt 50 ? 0 counts > > after > > Benchmark (size) Mode Cnt Score Error Units > NCopiesBenchmarks.forEach 10 avgt 50 36.838 ? 0.065 ns/op > NCopiesBenchmarks.forEach:?gc.alloc.rate 10 avgt 50 0.001 ? 0.001 MB/sec > NCopiesBenchmarks.forEach:?gc.alloc.rate.norm 10 avgt 50 ? 10?? B/op > NCopiesBenchmarks.forEach:?gc.count 10 avgt 50 ? 0 counts > NCopiesBenchmarks.forEach 50 avgt 50 191.173 ? 0.570 ns/op > NCopiesBenchmarks.forEach:?gc.alloc.rate 50 avgt 50 0.001 ? 0.001 MB/sec > NCopiesBenchmarks.forEach:?gc.alloc.rate.norm 50 avgt 50 ? 10?? B/op > NCopiesBenchmarks.forEach:?gc.count 50 avgt 50 ? 0 counts > NCopiesBenchmarks.forEach 100 avgt 50 376.675 ? 2.476 ns/op > NCopiesBenchmarks.forEach:?gc.alloc.rate 100 avgt 50 0.001 ? 0.001 MB/sec > NCopiesBenchmarks.forEach:?gc.alloc.rate.norm 100 avgt 50 0.001 ? 0.001 B/op > NCopiesBenchmarks.forEach:?gc.count 100 avgt 50 ? 0 counts Core collection classes should have optimized versions of forEach, so this is a good change in principle. Although CopiesList.forEach is unlikely to be performance critical. I implemented many similar optimizations for core collection classes in past years. Many of them are benchmarked in test/jdk/java/util/Collection/IteratorMicroBenchmark.java That was written pre-JMH. I see a JMH benchmark was written, but it is not part of the commit. There are a number of unrelated changes in this commit that look like they were suggested by a lint-like tool. Such changes are good, but they belong in a separate cleanup commit applied across large portions of the jdk sources. I would not use "var" here - more readable with concrete types. Similarly, I prefer not using diamond for return new Enumeration() { ------------- Changes requested by martin (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2524 From herrick at openjdk.java.net Mon Oct 4 19:15:21 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Mon, 4 Oct 2021 19:15:21 GMT Subject: RFR: 8274346: Support for additional content in an app-image. Message-ID: 8274346: Support for additional content in an app-image. ------------- Commit messages: - JDK-8274346: Support for additional content in an app-image. - JDK-8274346: Support for additional content in an app-image. - JDK-8274346: Support for additional content in an app-image. Changes: https://git.openjdk.java.net/jdk/pull/5780/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5780&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274346 Stats: 168 lines in 10 files changed: 158 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/5780.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5780/head:pull/5780 PR: https://git.openjdk.java.net/jdk/pull/5780 From herrick at openjdk.java.net Mon Oct 4 19:15:21 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Mon, 4 Oct 2021 19:15:21 GMT Subject: RFR: 8274346: Support for additional content in an app-image. In-Reply-To: References: Message-ID: On Thu, 30 Sep 2021 18:51:49 GMT, Andy Herrick wrote: > 8274346: Support for additional content in an app-image. CSR is at: https://bugs.openjdk.java.net/browse/JDK-8274717 ------------- PR: https://git.openjdk.java.net/jdk/pull/5780 From mchung at openjdk.java.net Mon Oct 4 20:20:07 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 4 Oct 2021 20:20:07 GMT Subject: RFR: 8274299: Make Method/Constructor/Field accessors @Stable [v2] In-Reply-To: References: Message-ID: On Mon, 4 Oct 2021 15:51:18 GMT, Peter Levart wrote: > One way this could be improved is to "stamp" the modifiers field with an additional bit (say 0x8000_0000) to always hold a non-zero value. Method::getModifiers() would then clear that bit in a returned value to stay compatible. Native Method/Field/Constructor construction would have to be modified too. Alternatively, it'd become a non-issue when `java.lang.reflect` and `jdk.internal.reflect` are added to the trusted final-field packages. ------------- PR: https://git.openjdk.java.net/jdk/pull/5694 From naoto.sato at oracle.com Mon Oct 4 20:23:47 2021 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 4 Oct 2021 13:23:47 -0700 Subject: Windows 10 (since Windows 10 version 1903) and Windows 11 support UTF-8 as the default codepage through an executable manifest option In-Reply-To: References: Message-ID: <22b45e3e-09f2-290b-aa28-ed564c31563b@oracle.com> Hi John, Please see the JEP 400, which changes the default charset to UTF-8 across platforms: https://openjdk.java.net/jeps/400 HTH, Naoto On 10/4/21 8:47 AM, John Platts wrote: > Windows 10 (since Windows 10 version 1903) and Windows 11 support UTF-8 as the default codepage by setting an option in the application manifest. > > To enable UTF-8 as the default codepage for JDK executables on Windows 10 (starting with the May 2019 update) and Windows 11, the following modifications can be made to the src/java.base/windows/native/launcher/java.manifest file (or the jdk/src/windows/resource/java.manifest in JDK 8): > ... > > > xmlns:dpi2="http://schemas.microsoft.com/SMI/2016/WindowsSettings" > xmlns:utf8="http://schemas.microsoft.com/SMI/2019/WindowsSettings"> > true/PM > PerMonitorV2, PerMonitor, system > UTF-8 > > > ... > > The GetACP() and GetOEMCP() API's will both return 65001 on Windows 10 Version 1903 or later if UTF-8 element is added to the executable manifest. > > GetLocaleInfo(lcid, LOCALE_IDEFAULTANSICODEPAGE, ret+2, 14) will return different results from GetACP() if UTF-8 is present in the executable manifest, and java.nio.charset.Charset.defaultCharset() should return StandardCharsets.UTF_8 on Windows platforms if GetACP() returns 65001. > From forax at openjdk.java.net Mon Oct 4 20:42:16 2021 From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Mon, 4 Oct 2021 20:42:16 GMT Subject: RFR: 8274299: Make Method/Constructor/Field accessors @Stable [v4] In-Reply-To: References: Message-ID: <22w_AkthCfBbiosYMrt98wVWdcgG-qrO9U8c1nVVhh8=.9b822480-5596-464e-a1a9-821e24924ce1@github.com> On Mon, 4 Oct 2021 15:49:43 GMT, Peter Levart wrote: >> This patch improves reflective access speed as shown by the included benchmarks: >> >> https://jmh.morethan.io/?gists=902f4b43519c4f96c7abcd14cdc2d27d,ac490481e3001c710d75d6071c10b23a >> >> ... and is also a prerequisite to make JEP 416 (Reimplement Core Reflection with Method Handle) perform better in some circumstances. > > Peter Levart has updated the pull request incrementally with one additional commit since the last revision: > > More @stable fields in Constructor/Field to align them with Method fields Can you surreptitiously add "java.lang" too (asking for a friend) ------------- PR: https://git.openjdk.java.net/jdk/pull/5694 From mchung at openjdk.java.net Mon Oct 4 20:55:06 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 4 Oct 2021 20:55:06 GMT Subject: RFR: 8274299: Make Method/Constructor/Field accessors @Stable [v4] In-Reply-To: References: Message-ID: <4TZqhpT5iYo5b3JaWPozYMnjV0cqWjh7agz65Z9Tiyo=.786d4914-c6d8-46a9-87cc-d35e7deb3ff5@github.com> On Mon, 4 Oct 2021 15:49:43 GMT, Peter Levart wrote: >> This patch improves reflective access speed as shown by the included benchmarks: >> >> https://jmh.morethan.io/?gists=902f4b43519c4f96c7abcd14cdc2d27d,ac490481e3001c710d75d6071c10b23a >> >> ... and is also a prerequisite to make JEP 416 (Reimplement Core Reflection with Method Handle) perform better in some circumstances. > > Peter Levart has updated the pull request incrementally with one additional commit since the last revision: > > More @stable fields in Constructor/Field to align them with Method fields `java.lang` is already trusted [1]. [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/ci/ciField.cpp#L219 ------------- PR: https://git.openjdk.java.net/jdk/pull/5694 From forax at openjdk.java.net Mon Oct 4 20:58:06 2021 From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Mon, 4 Oct 2021 20:58:06 GMT Subject: RFR: 8274299: Make Method/Constructor/Field accessors @Stable [v4] In-Reply-To: References: Message-ID: On Mon, 4 Oct 2021 15:49:43 GMT, Peter Levart wrote: >> This patch improves reflective access speed as shown by the included benchmarks: >> >> https://jmh.morethan.io/?gists=902f4b43519c4f96c7abcd14cdc2d27d,ac490481e3001c710d75d6071c10b23a >> >> ... and is also a prerequisite to make JEP 416 (Reimplement Core Reflection with Method Handle) perform better in some circumstances. > > Peter Levart has updated the pull request incrementally with one additional commit since the last revision: > > More @stable fields in Constructor/Field to align them with Method fields I miss that, that very cool. ------------- PR: https://git.openjdk.java.net/jdk/pull/5694 From ecki at zusammenkunft.net Mon Oct 4 20:58:36 2021 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Mon, 4 Oct 2021 20:58:36 +0000 Subject: Windows 10 (since Windows 10 version 1903) and Windows 11 support UTF-8 as the default codepage through an executable manifest option In-Reply-To: <22b45e3e-09f2-290b-aa28-ed564c31563b@oracle.com> References: <22b45e3e-09f2-290b-aa28-ed564c31563b@oracle.com> Message-ID: John do you know if this also switches a console window into utf8 for such a launcher? (And if so, also for a already open console?) The problem will be similar to initial jep400 that some still might need to know the legacy ansi codepage for the OS, and I guess the new method won?t give us that if the manifest is changed? -- https://Bernd.eckenfels.net ________________________________ From: core-libs-dev on behalf of Naoto Sato Sent: Monday, October 4, 2021 10:23:47 PM To: core-libs-dev at openjdk.java.net Subject: Re: Windows 10 (since Windows 10 version 1903) and Windows 11 support UTF-8 as the default codepage through an executable manifest option Hi John, Please see the JEP 400, which changes the default charset to UTF-8 across platforms: https://openjdk.java.net/jeps/400 HTH, Naoto On 10/4/21 8:47 AM, John Platts wrote: > Windows 10 (since Windows 10 version 1903) and Windows 11 support UTF-8 as the default codepage by setting an option in the application manifest. > > To enable UTF-8 as the default codepage for JDK executables on Windows 10 (starting with the May 2019 update) and Windows 11, the following modifications can be made to the src/java.base/windows/native/launcher/java.manifest file (or the jdk/src/windows/resource/java.manifest in JDK 8): > ... > > > xmlns:dpi2="http://schemas.microsoft.com/SMI/2016/WindowsSettings" > xmlns:utf8="http://schemas.microsoft.com/SMI/2019/WindowsSettings"> > true/PM > PerMonitorV2, PerMonitor, system > UTF-8 > > > ... > > The GetACP() and GetOEMCP() API's will both return 65001 on Windows 10 Version 1903 or later if UTF-8 element is added to the executable manifest. > > GetLocaleInfo(lcid, LOCALE_IDEFAULTANSICODEPAGE, ret+2, 14) will return different results from GetACP() if UTF-8 is present in the executable manifest, and java.nio.charset.Charset.defaultCharset() should return StandardCharsets.UTF_8 on Windows platforms if GetACP() returns 65001. > From github.com+7693005+jarviscraft at openjdk.java.net Mon Oct 4 21:20:25 2021 From: github.com+7693005+jarviscraft at openjdk.java.net (PROgrm_JARvis) Date: Mon, 4 Oct 2021 21:20:25 GMT Subject: RFR: JDK-8274686 : java.util.UUID#hashCode() should use Long.hashCode() Message-ID: This is trivial fix of [JDK-8274686](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8274686) which replaces manually-computed `int`-based `long` hash-code. Because `Long#hashCode(long)` uses other hashing function than the one currently used here: https://github.com/openjdk/jdk/blob/75d6688df9845ecb8f370b4cd2d5a36f13d3cdc0/src/java.base/share/classes/java/lang/Long.java#L1440-L1442 the value of `hashCode()` will produce different result, however this does not seem to be a breaking change as `UUID#hashCode()` is not specified. --- Note: the comment to the bug states: > Moved to JDK for further discussions of the proposed enhancement. But as I there seemed to be no corresponding discussion in core-libs-dev and the change looks trivial, I considered that it is appropriate to open a PR which (if needed) may be used for discussion (especially, considering the fact that its comments get mirrored to the ML). ------------- Commit messages: - fix: use `Long#hashCode(long)` for `UUID#hashCode()` Changes: https://git.openjdk.java.net/jdk/pull/5811/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5811&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274686 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5811.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5811/head:pull/5811 PR: https://git.openjdk.java.net/jdk/pull/5811 From serb at openjdk.java.net Mon Oct 4 21:40:09 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 4 Oct 2021 21:40:09 GMT Subject: RFR: 8274397: [macOS] Stop setting env. var JAVA_MAIN_CLASS_ in launcher code [v4] In-Reply-To: <6g0EhtvtHXXr80qFDYESUQ-PhKf97oikta-MnPf2QSY=.4e52ca70-f604-4bbd-b340-9229d6edb118@github.com> References: <8j-vMsDYbF5100Dpc1DP_JGNV5V0W0D7i2fP7QnXCpU=.9169a246-f866-49c5-99fb-04f9fb946b9e@github.com> <6g0EhtvtHXXr80qFDYESUQ-PhKf97oikta-MnPf2QSY=.4e52ca70-f604-4bbd-b340-9229d6edb118@github.com> Message-ID: On Fri, 1 Oct 2021 21:10:27 GMT, Phil Race wrote: >> macOS launcher code sets JAVA_MAIN_CLASS_ which is read by AWT to set the name of the application in the system menu bar. >> >> Because this set shortly after the VM is running, it causes a thread safety issue described in https://bugs.openjdk.java.net/browse/JDK-8270549 >> >> Since the AWT already looks for the system property "apple.awt.application.name" for this same purpose, >> we can set that instead of the env. var and avoid the threading issue. >> >> This trades the JAVA_MAIN_CLASS_ pollution of the environment for setting a system property which is visible to apps as well but it seems a reasonable trade-off since we already (implicitly) support this variable anyway in preference to the env. var. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8274397: Stop setting env. var JAVA_MAIN_CLASS_ in launcher code Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5724 From plevart at openjdk.java.net Mon Oct 4 22:24:39 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Mon, 4 Oct 2021 22:24:39 GMT Subject: RFR: 8274299: Make Method/Constructor/Field accessors @Stable [v5] In-Reply-To: References: Message-ID: > This patch improves reflective access speed as shown by the included benchmarks: > > https://jmh.morethan.io/?gists=902f4b43519c4f96c7abcd14cdc2d27d,ac490481e3001c710d75d6071c10b23a > > ... and is also a prerequisite to make JEP 416 (Reimplement Core Reflection with Method Handle) perform better in some circumstances. Peter Levart has updated the pull request incrementally with one additional commit since the last revision: Add Constructor benchmarks ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5694/files - new: https://git.openjdk.java.net/jdk/pull/5694/files/0d8ccc87..87d1b762 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5694&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5694&range=03-04 Stats: 70 lines in 1 file changed: 62 ins; 2 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/5694.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5694/head:pull/5694 PR: https://git.openjdk.java.net/jdk/pull/5694 From plevart at openjdk.java.net Mon Oct 4 22:24:44 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Mon, 4 Oct 2021 22:24:44 GMT Subject: RFR: 8274299: Make Method/Constructor/Field accessors @Stable [v4] In-Reply-To: References: Message-ID: <53kTrKtZsZKx6IBnZ4LFnr4x7HrDCbb1oaHTpbe061k=.9a0d441d-65b8-4c4b-8c5d-8777381b781b@github.com> On Mon, 4 Oct 2021 15:49:43 GMT, Peter Levart wrote: >> This patch improves reflective access speed as shown by the included benchmarks: >> >> https://jmh.morethan.io/?gists=902f4b43519c4f96c7abcd14cdc2d27d,ac490481e3001c710d75d6071c10b23a >> >> ... and is also a prerequisite to make JEP 416 (Reimplement Core Reflection with Method Handle) perform better in some circumstances. > > Peter Levart has updated the pull request incrementally with one additional commit since the last revision: > > More @stable fields in Constructor/Field to align them with Method fields I added Constructor benchmarks in latest commit. Here are the results: https://jmh.morethan.io/?gists=f57a49ce833d5a53a01ce996570c11d2,de4a8a4b7ddc4bec1090d2113d9c50e6 I rest now, waiting for comments. ------------- PR: https://git.openjdk.java.net/jdk/pull/5694 From mchung at openjdk.java.net Mon Oct 4 23:10:10 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 4 Oct 2021 23:10:10 GMT Subject: RFR: 8274299: Make Method/Constructor/Field accessors @Stable [v5] In-Reply-To: References: Message-ID: On Mon, 4 Oct 2021 22:24:39 GMT, Peter Levart wrote: >> This patch improves reflective access speed as shown by the included benchmarks: >> >> https://jmh.morethan.io/?gists=902f4b43519c4f96c7abcd14cdc2d27d,ac490481e3001c710d75d6071c10b23a >> >> ... and is also a prerequisite to make JEP 416 (Reimplement Core Reflection with Method Handle) perform better in some circumstances. > > Peter Levart has updated the pull request incrementally with one additional commit since the last revision: > > Add Constructor benchmarks Looks good. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5694 From asemenyuk at openjdk.java.net Mon Oct 4 23:18:07 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Mon, 4 Oct 2021 23:18:07 GMT Subject: RFR: 8274346: Support for additional content in an app-image. In-Reply-To: References: Message-ID: On Thu, 30 Sep 2021 18:51:49 GMT, Andy Herrick wrote: > 8274346: Support for additional content in an app-image. Changes requested by asemenyuk (Reviewer). test/jdk/tools/jpackage/share/AppContentTest.java line 97: > 95: for (String p : paths) { > 96: Path name = Path.of(p).getFileName(); > 97: TKit.assertTrue(Files.exists(contentDir.resolve(name)), I'd suggest to use `TKit.assertPathExists()` instead of `TKit.assertTrue(Files.exists(...))` ------------- PR: https://git.openjdk.java.net/jdk/pull/5780 From dholmes at openjdk.java.net Mon Oct 4 23:18:34 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 4 Oct 2021 23:18:34 GMT Subject: RFR: 8274349: ForkJoinPool.commonPool() does not work with 1 CPU [v3] In-Reply-To: References: Message-ID: > A regression introduced in Java 17 will give the default FJ pool a parallelism of zero in a uniprocessor environment. The fix restores this to a value of 1. See bug report for details. > > Testing: > - new regression test > - tiers 1-3 > > Thanks, > David David Holmes has updated the pull request incrementally with one additional commit since the last revision: Improved test logic per @martin's comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5784/files - new: https://git.openjdk.java.net/jdk/pull/5784/files/666f36f4..1344903a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5784&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5784&range=01-02 Stats: 5 lines in 1 file changed: 1 ins; 1 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5784.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5784/head:pull/5784 PR: https://git.openjdk.java.net/jdk/pull/5784 From dholmes at openjdk.java.net Mon Oct 4 23:18:34 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 4 Oct 2021 23:18:34 GMT Subject: RFR: 8274349: ForkJoinPool.commonPool() does not work with 1 CPU [v2] In-Reply-To: References: Message-ID: <0VuBQ1wFTmD1H86FRsazznMHoqyLemZ98F8a5i9mqH8=.52d85f1c-ec8c-4ff0-82b9-40cc53a235d7@github.com> On Fri, 1 Oct 2021 06:21:51 GMT, Aleksey Shipilev wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated TCK test component from @martin > > Oh wow. Looks good! Thanks for the reviews @shipilev and @Martin-Buchholz ! Test updated per Martin's suggestion. ------------- PR: https://git.openjdk.java.net/jdk/pull/5784 From dholmes at openjdk.java.net Mon Oct 4 23:18:36 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 4 Oct 2021 23:18:36 GMT Subject: Integrated: 8274349: ForkJoinPool.commonPool() does not work with 1 CPU In-Reply-To: References: Message-ID: <4niDHQNZ45RfRWMFRGn5CySr-_vAZyt7vqTi_eLLkSQ=.00a5cf6f-0f64-4ff7-999a-e7254aa6f2e0@github.com> On Fri, 1 Oct 2021 00:28:55 GMT, David Holmes wrote: > A regression introduced in Java 17 will give the default FJ pool a parallelism of zero in a uniprocessor environment. The fix restores this to a value of 1. See bug report for details. > > Testing: > - new regression test > - tiers 1-3 > > Thanks, > David This pull request has now been integrated. Changeset: 2e542e33 Author: David Holmes URL: https://git.openjdk.java.net/jdk/commit/2e542e33b81a53652956bb5e9636e7f4af5540f7 Stats: 84 lines in 3 files changed: 80 ins; 0 del; 4 mod 8274349: ForkJoinPool.commonPool() does not work with 1 CPU Co-authored-by: Doug Lea
Reviewed-by: shade, martin ------------- PR: https://git.openjdk.java.net/jdk/pull/5784 From prr at openjdk.java.net Tue Oct 5 00:25:41 2021 From: prr at openjdk.java.net (Phil Race) Date: Tue, 5 Oct 2021 00:25:41 GMT Subject: RFR: 8274397: [macOS] Stop setting env. var JAVA_MAIN_CLASS_ in launcher code [v5] In-Reply-To: <8j-vMsDYbF5100Dpc1DP_JGNV5V0W0D7i2fP7QnXCpU=.9169a246-f866-49c5-99fb-04f9fb946b9e@github.com> References: <8j-vMsDYbF5100Dpc1DP_JGNV5V0W0D7i2fP7QnXCpU=.9169a246-f866-49c5-99fb-04f9fb946b9e@github.com> Message-ID: > macOS launcher code sets JAVA_MAIN_CLASS_ which is read by AWT to set the name of the application in the system menu bar. > > Because this set shortly after the VM is running, it causes a thread safety issue described in https://bugs.openjdk.java.net/browse/JDK-8270549 > > Since the AWT already looks for the system property "apple.awt.application.name" for this same purpose, > we can set that instead of the env. var and avoid the threading issue. > > This trades the JAVA_MAIN_CLASS_ pollution of the environment for setting a system property which is visible to apps as well but it seems a reasonable trade-off since we already (implicitly) support this variable anyway in preference to the env. var. Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8274397: Stop setting env. var JAVA_MAIN_CLASS_ in launcher code ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5724/files - new: https://git.openjdk.java.net/jdk/pull/5724/files/4c8fb9af..ffd77dd9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5724&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5724&range=03-04 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5724.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5724/head:pull/5724 PR: https://git.openjdk.java.net/jdk/pull/5724 From prr at openjdk.java.net Tue Oct 5 00:25:44 2021 From: prr at openjdk.java.net (Phil Race) Date: Tue, 5 Oct 2021 00:25:44 GMT Subject: RFR: 8274397: [macOS] Stop setting env. var JAVA_MAIN_CLASS_ in launcher code [v4] In-Reply-To: <6g0EhtvtHXXr80qFDYESUQ-PhKf97oikta-MnPf2QSY=.4e52ca70-f604-4bbd-b340-9229d6edb118@github.com> References: <8j-vMsDYbF5100Dpc1DP_JGNV5V0W0D7i2fP7QnXCpU=.9169a246-f866-49c5-99fb-04f9fb946b9e@github.com> <6g0EhtvtHXXr80qFDYESUQ-PhKf97oikta-MnPf2QSY=.4e52ca70-f604-4bbd-b340-9229d6edb118@github.com> Message-ID: On Fri, 1 Oct 2021 21:10:27 GMT, Phil Race wrote: >> macOS launcher code sets JAVA_MAIN_CLASS_ which is read by AWT to set the name of the application in the system menu bar. >> >> Because this set shortly after the VM is running, it causes a thread safety issue described in https://bugs.openjdk.java.net/browse/JDK-8270549 >> >> Since the AWT already looks for the system property "apple.awt.application.name" for this same purpose, >> we can set that instead of the env. var and avoid the threading issue. >> >> This trades the JAVA_MAIN_CLASS_ pollution of the environment for setting a system property which is visible to apps as well but it seems a reasonable trade-off since we already (implicitly) support this variable anyway in preference to the env. var. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8274397: Stop setting env. var JAVA_MAIN_CLASS_ in launcher code I just pushed a small update to the new test. The compiled class file of the child process was not found when I ran it in our test framework even though jtreg run locally found it. I just had to explicitly add the location of the compiled classes to the classpath. So it is just about getting the test to run in that env. rather than any problem with the fix, or the test logic. This update HAS passed in that framework - as well as locally ------------- PR: https://git.openjdk.java.net/jdk/pull/5724 From john_platts at hotmail.com Tue Oct 5 01:22:12 2021 From: john_platts at hotmail.com (John Platts) Date: Tue, 5 Oct 2021 01:22:12 +0000 Subject: Implementing JEP 400 on Windows 10 and Windows 11 Message-ID: I wrote a test program (in C++) to detect the codepages that would be returned by the?GetACP(), GetOEMCP(), and GetConsoleCP() functions when the UTF-8 setting is added to the manifest. The manifest element (supported on Windows 10 Version 1903 or later) is in the http://schemas.microsoft.com/SMI/2019/WindowsSettings namespace and is added to the asmv3:WindowsSettings element as shown below: true/PM PerMonitorV2, PerMonitor, system UTF-8 Here is the output of the test program without the UTF-8 setting present in the executable manifest: GetACP() result: 1252 GetOEMCP() result: 437 GetConsoleCP() result: 437 System default LCID: 1033 User default LCID: 1033 User default UI LCID: 1033 Codepage from system default LCID: 1252 Codepage from user default LCID: 1252 Codepage from user default UI LCID: 1252 Here is the output of the same test program with an executable manifest that includes the UTF-8 setting: GetACP() result: 65001 GetOEMCP() result: 65001 GetConsoleCP() result: 437 System default LCID: 1033 User default LCID: 1033 User default UI LCID: 1033 Codepage from system default LCID: 1252 Codepage from user default LCID: 1252 Codepage from user default UI LCID: 1252 Note that the UTF-8 setting in the application manifest changes the results of the GetACP() and GetOEMCP() calls but not the GetConsoleCP() call. I wrote another test program, and the argument strings passed into the main(int argc, char** argv) function are converted to UTF-8 if the UTF-8 setting is there in the application manifest whereas the argument strings passed into the main (int argc, char** argv) function are converted to the ANSI codepage (which is usually code page 1252 on US English systems) if the UTF-8 setting is there in the UTF-8 manifest. From serb at openjdk.java.net Tue Oct 5 07:49:08 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 5 Oct 2021 07:49:08 GMT Subject: RFR: 8274397: [macOS] Stop setting env. var JAVA_MAIN_CLASS_ in launcher code [v5] In-Reply-To: References: <8j-vMsDYbF5100Dpc1DP_JGNV5V0W0D7i2fP7QnXCpU=.9169a246-f866-49c5-99fb-04f9fb946b9e@github.com> Message-ID: On Tue, 5 Oct 2021 00:25:41 GMT, Phil Race wrote: >> macOS launcher code sets JAVA_MAIN_CLASS_ which is read by AWT to set the name of the application in the system menu bar. >> >> Because this set shortly after the VM is running, it causes a thread safety issue described in https://bugs.openjdk.java.net/browse/JDK-8270549 >> >> Since the AWT already looks for the system property "apple.awt.application.name" for this same purpose, >> we can set that instead of the env. var and avoid the threading issue. >> >> This trades the JAVA_MAIN_CLASS_ pollution of the environment for setting a system property which is visible to apps as well but it seems a reasonable trade-off since we already (implicitly) support this variable anyway in preference to the env. var. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8274397: Stop setting env. var JAVA_MAIN_CLASS_ in launcher code Looks fine ------------- Marked as reviewed by serb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5724 From sverre.moe at gmail.com Tue Oct 5 07:54:38 2021 From: sverre.moe at gmail.com (Sverre Moe) Date: Tue, 5 Oct 2021 09:54:38 +0200 Subject: JDK-17: Wndows jpackage destination directory not writable Message-ID: With JDK 17, jpackage fails to write to the destination directory on Windows. It worked fine with JDK 11 (with jpackage from JDK14) and Docker. Only happens on Windows docker. Running directly on WIndows it works with JDK 17. What has changed with jpackage that it no longer can write to the destination directory when running in Docker? Is it a regression/bug with jpackage? > Task :jpackageImage Caching disabled for task ':jpackageImage' because: Build cache is disabled Task ':jpackageImage' is not up-to-date because: Task has failed previously. input subdir: my-javafx-application Starting process 'command 'C:\Program Files\Java\jdk-17/bin/jpackage.exe''. Working directory: C:\Temp\my-javafx-application Command: C:\Program Files\Java\jdk-17/bin/jpackage.exe --type app-image --input C:\Temp\my-javafx-application\build\install\my-javafx-application\lib --main-jar my-javafx-application-1.8.0-SNAPSHOT.jar --main-class no.spacetec.dashboard.core.MeosDashboardLauncher --dest C:\Temp\my-javafx-application\build\native --name my-javafx-application --app-version 1.8.0 --runtime-image C:\Temp\my-javafx-application\build\runtime --resource-dir C:\Temp\my-javafx-application\build\package --java-options -Dfile.encoding=UTF-8 --java-options -DLog4jContextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector --java-options -Dlog4j.configurationFactory=no.spacetec.dashboard.core.LoggingConfigurationFactory --verbose --description MEOS Dashboard Monitor and Control System GUI --vendor Kongsberg Space Ground Systems --icon C:\Temp\my-javafx-application\build/package/my-javafx-application.png Successfully started process 'command 'C:\Program Files\Java\jdk-17/bin/jpackage.exe'' [03:15:28.286] jdk.jpackage.internal.PackagerException: Destination directory C:\Temp\my-javafx-application\build\native is not writable at jdk.jpackage/jdk.jpackage.internal.IOUtils.writableOutputDir(IOUtils.java:266) at jdk.jpackage/jdk.jpackage.internal.AppImageBundler.createRoot(AppImageBundler.java:134) at jdk.jpackage/jdk.jpackage.internal.AppImageBundler.createAppBundle(AppImageBundler.java:163) at jdk.jpackage/jdk.jpackage.internal.AppImageBundler.execute(AppImageBundler.java:91) at jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:676) at jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments.java:550) at jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:91) at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:52) From redestad at openjdk.java.net Tue Oct 5 08:30:08 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 5 Oct 2021 08:30:08 GMT Subject: RFR: 8274299: Make Method/Constructor/Field accessors @Stable [v5] In-Reply-To: References: Message-ID: On Mon, 4 Oct 2021 22:24:39 GMT, Peter Levart wrote: >> This patch improves reflective access speed as shown by the included benchmarks: >> >> https://jmh.morethan.io/?gists=902f4b43519c4f96c7abcd14cdc2d27d,ac490481e3001c710d75d6071c10b23a >> >> ... and is also a prerequisite to make JEP 416 (Reimplement Core Reflection with Method Handle) perform better in some circumstances. > > Peter Levart has updated the pull request incrementally with one additional commit since the last revision: > > Add Constructor benchmarks Excellent, thanks! ------------- Marked as reviewed by redestad (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5694 From magnus.ihse.bursie at oracle.com Tue Oct 5 08:34:26 2021 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 5 Oct 2021 10:34:26 +0200 Subject: Implementing JEP 400 on Windows 10 and Windows 11 In-Reply-To: References: Message-ID: <0a06028a-f5c1-a710-a097-8c88e32cd58d@oracle.com> On 2021-10-05 03:22, John Platts wrote: > I wrote a test program (in C++) to detect the codepages that would be returned by the?GetACP(), GetOEMCP(), and GetConsoleCP() functions when the UTF-8 setting is added to the manifest. > > The manifest element (supported on Windows 10 Version 1903 or later) is in the http://schemas.microsoft.com/SMI/2019/WindowsSettings namespace and is added to the asmv3:WindowsSettings element as shown below: > xmlns:dpi2="http://schemas.microsoft.com/SMI/2016/WindowsSettings" > xmlns:utf8="http://schemas.microsoft.com/SMI/2019/WindowsSettings"> > true/PM > PerMonitorV2, PerMonitor, system > UTF-8 > > > Here is the output of the test program without the UTF-8 setting present in the executable manifest: > GetACP() result: 1252 > GetOEMCP() result: 437 > GetConsoleCP() result: 437 > System default LCID: 1033 > User default LCID: 1033 > User default UI LCID: 1033 > Codepage from system default LCID: 1252 > Codepage from user default LCID: 1252 > Codepage from user default UI LCID: 1252 > > Here is the output of the same test program with an executable manifest that includes the UTF-8 setting: > GetACP() result: 65001 > GetOEMCP() result: 65001 > GetConsoleCP() result: 437 > System default LCID: 1033 > User default LCID: 1033 > User default UI LCID: 1033 > Codepage from system default LCID: 1252 > Codepage from user default LCID: 1252 > Codepage from user default UI LCID: 1252 > > Note that the UTF-8 setting in the application manifest changes the results of the GetACP() and GetOEMCP() calls but not the GetConsoleCP() call. This is really confusing. I'm glad you are gathering empirical evidence of how it works. :-) > I wrote another test program, and the argument strings passed into the main(int argc, char** argv) function are converted to UTF-8 if the UTF-8 setting is there in the application manifest whereas the argument strings passed into the main (int argc, char** argv) function are converted to the ANSI codepage (which is usually code page 1252 on US English systems) if the UTF-8 setting is there in the UTF-8 manifest. I'm not sure I understand this. What is the difference between "the application manifest" and "the UTF-8 manifest"? /Magnus From Alan.Bateman at oracle.com Tue Oct 5 08:40:53 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 5 Oct 2021 09:40:53 +0100 Subject: JDK-17: Wndows jpackage destination directory not writable In-Reply-To: References: Message-ID: <6e1e209f-1919-c98a-0b86-0a6453ce5bba@oracle.com> On 05/10/2021 08:54, Sverre Moe wrote: > With JDK 17, jpackage fails to write to the destination directory on > Windows. > > It worked fine with JDK 11 (with jpackage from JDK14) and Docker. > > Only happens on Windows docker. Running directly on WIndows it works with > JDK 17. > > What has changed with jpackage that it no longer can write to the > destination directory when running in Docker? > Is it a regression/bug with jpackage? > I don't know what has changed in jpackage, maybe it didn't check for write access previously. However, the error you are seeing suggests there may be a lower-level issue, maybe a driver issue. It would be useful if you could print out the DACL (using cacls is okay) and the DOS attributes. -Alan From github.com+10835776+stsypanov at openjdk.java.net Tue Oct 5 09:18:57 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Tue, 5 Oct 2021 09:18:57 GMT Subject: RFR: 8274715: Implement forEach in Collections.CopiesList [v2] In-Reply-To: References: Message-ID: > Originally was proposed by Zheka Kozlov here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-December/057192.html > > Just a tiny optimization: we can use for-i loop instead of `Iterable.forEach()` which is relying on iterator. > > Simple benchmark demonstrates slight improvement: > > @State(Scope.Thread) > @BenchmarkMode(Mode.AverageTime) > @OutputTimeUnit(TimeUnit.NANOSECONDS) > public class NCopiesBenchmarks { > @Param({"10", "50", "100"}) > int size; > > private List list; > > @Setup > public void prepare() { > list = Collections.nCopies(size, new Object()); > } > > @Benchmark > public void forEach(Blackhole bh) { > list.forEach(bh::consume); > } > } > > > > before > > Benchmark (size) Mode Cnt Score Error Units > NCopiesBenchmarks.forEach 10 avgt 50 40.737 ? 1.854 ns/op > NCopiesBenchmarks.forEach:?gc.alloc.rate 10 avgt 50 0.001 ? 0.001 MB/sec > NCopiesBenchmarks.forEach:?gc.alloc.rate.norm 10 avgt 50 ? 10?? B/op > NCopiesBenchmarks.forEach:?gc.count 10 avgt 50 ? 0 counts > NCopiesBenchmarks.forEach 50 avgt 50 213.324 ? 3.784 ns/op > NCopiesBenchmarks.forEach:?gc.alloc.rate 50 avgt 50 0.001 ? 0.001 MB/sec > NCopiesBenchmarks.forEach:?gc.alloc.rate.norm 50 avgt 50 ? 10?? B/op > NCopiesBenchmarks.forEach:?gc.count 50 avgt 50 ? 0 counts > NCopiesBenchmarks.forEach 100 avgt 50 443.171 ? 17.919 ns/op > NCopiesBenchmarks.forEach:?gc.alloc.rate 100 avgt 50 0.001 ? 0.001 MB/sec > NCopiesBenchmarks.forEach:?gc.alloc.rate.norm 100 avgt 50 0.001 ? 0.001 B/op > NCopiesBenchmarks.forEach:?gc.count 100 avgt 50 ? 0 counts > > after > > Benchmark (size) Mode Cnt Score Error Units > NCopiesBenchmarks.forEach 10 avgt 50 36.838 ? 0.065 ns/op > NCopiesBenchmarks.forEach:?gc.alloc.rate 10 avgt 50 0.001 ? 0.001 MB/sec > NCopiesBenchmarks.forEach:?gc.alloc.rate.norm 10 avgt 50 ? 10?? B/op > NCopiesBenchmarks.forEach:?gc.count 10 avgt 50 ? 0 counts > NCopiesBenchmarks.forEach 50 avgt 50 191.173 ? 0.570 ns/op > NCopiesBenchmarks.forEach:?gc.alloc.rate 50 avgt 50 0.001 ? 0.001 MB/sec > NCopiesBenchmarks.forEach:?gc.alloc.rate.norm 50 avgt 50 ? 10?? B/op > NCopiesBenchmarks.forEach:?gc.count 50 avgt 50 ? 0 counts > NCopiesBenchmarks.forEach 100 avgt 50 376.675 ? 2.476 ns/op > NCopiesBenchmarks.forEach:?gc.alloc.rate 100 avgt 50 0.001 ? 0.001 MB/sec > NCopiesBenchmarks.forEach:?gc.alloc.rate.norm 100 avgt 50 0.001 ? 0.001 B/op > NCopiesBenchmarks.forEach:?gc.count 100 avgt 50 ? 0 counts ?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Merge branch 'master' into ncopies - 8274715: Add NCopiesBenchmarks.java - 8274715: Revert some irrelevant changes - 8274715: Implement forEach in Collections.CopiesList ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2524/files - new: https://git.openjdk.java.net/jdk/pull/2524/files/2303aa72..18f5d589 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2524&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2524&range=00-01 Stats: 1563723 lines in 16632 files changed: 815442 ins; 677273 del; 71008 mod Patch: https://git.openjdk.java.net/jdk/pull/2524.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2524/head:pull/2524 PR: https://git.openjdk.java.net/jdk/pull/2524 From github.com+10835776+stsypanov at openjdk.java.net Tue Oct 5 09:19:05 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Tue, 5 Oct 2021 09:19:05 GMT Subject: RFR: 8274715: Implement forEach in Collections.CopiesList [v2] In-Reply-To: References: Message-ID: On Mon, 4 Oct 2021 16:51:27 GMT, Martin Buchholz wrote: >> ?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: >> >> - Merge branch 'master' into ncopies >> - 8274715: Add NCopiesBenchmarks.java >> - 8274715: Revert some irrelevant changes >> - 8274715: Implement forEach in Collections.CopiesList > > Core collection classes should have optimized versions of forEach, so this is a good change in principle. Although CopiesList.forEach is unlikely to be performance critical. > > I implemented many similar optimizations for core collection classes in past years. > Many of them are benchmarked in test/jdk/java/util/Collection/IteratorMicroBenchmark.java > That was written pre-JMH. > I see a JMH benchmark was written, but it is not part of the commit. > > There are a number of unrelated changes in this commit that look like they were suggested by a lint-like tool. Such changes are good, but they belong in a separate cleanup commit applied across large portions of the jdk sources. > > I would not use "var" here - more readable with concrete types. > > Similarly, I prefer not using diamond for > return new Enumeration() { @Martin-Buchholz thanks for review! I've reverted irrelevant changes and added the benchmark. ------------- PR: https://git.openjdk.java.net/jdk/pull/2524 From sverre.moe at gmail.com Tue Oct 5 09:55:38 2021 From: sverre.moe at gmail.com (Sverre Moe) Date: Tue, 5 Oct 2021 11:55:38 +0200 Subject: JDK-17: Wndows jpackage destination directory not writable In-Reply-To: <6e1e209f-1919-c98a-0b86-0a6453ce5bba@oracle.com> References: <6e1e209f-1919-c98a-0b86-0a6453ce5bba@oracle.com> Message-ID: I ran cacls after the failed jpackage. C:\temp\my-javafx-application>cacls build C:\temp\my-javafx-application\build F CREATOR OWNER:(OI)(CI)(IO)F R CREATOR GROUP:(OI)(CI)(IO)R Everyone:(OI)(CI)R C:\temp\my-javafx-application>cacls build\native C:\temp\my-javafx-application\build\native F CREATOR OWNER:(OI)(CI)(IO)F R CREATOR GROUP:(OI)(CI)(IO)R Everyone:(OI)(CI)R As cacls was deprecated it suggested to use icacls instead: C:\temp\my-javafx-application>icacls build build S-1-5-21-406077803-2019195645-689573112-1003:(I)(F) CREATOR OWNER:(I)(OI)(CI)(IO)(F) S-1-5-21-406077803-2019195645-689573112-513:(I)(RX) CREATOR GROUP:(I)(OI)(CI)(IO)(RX) Everyone:(I)(OI)(CI)(RX) Successfully processed 1 files; Failed processing 0 files C:\temp\my-javafx-application>icacls build\native build\native S-1-5-83-1-1537791174-1084404783-2478187907-2577323605:(I)(F) CREATOR OWNER:(I)(OI)(CI)(IO)(F) S-1-5-83-0:(I)(RX) CREATOR GROUP:(I)(OI)(CI)(IO)(RX) Everyone:(I)(OI)(CI)(RX) Successfully processed 1 files; Failed processing 0 files Running attrib on the workspace, and build dirs: C:\Temp\my-javafx-application>attrib A C:\Temp\my-javafx-application\.description A C:\Temp\my-javafx-application\.gitignore A C:\Temp\my-javafx-application\build.gradle A C:\Temp\my-javafx-application\gradle.properties A C:\Temp\my-javafx-application\gradlew A C:\Temp\my-javafx-application\gradlew.bat A C:\Temp\my-javafx-application\Jenkinsfile A C:\Temp\my-javafx-application\packager.gradle A C:\Temp\my-javafx-application\README.adoc A C:\Temp\my-javafx-application\settings.gradle A C:\Temp\my-javafx-application\spotless.gradle C:\Temp\my-javafx-application>attrib build C:\Temp\my-javafx-application\build C:\Temp\meos-dashboard>attrib build\native C:\Temp\my-javafx-application\build\native /Sverre tir. 5. okt. 2021 kl. 10:41 skrev Alan Bateman : > On 05/10/2021 08:54, Sverre Moe wrote: > > With JDK 17, jpackage fails to write to the destination directory on > > Windows. > > > > It worked fine with JDK 11 (with jpackage from JDK14) and Docker. > > > > Only happens on Windows docker. Running directly on WIndows it works with > > JDK 17. > > > > What has changed with jpackage that it no longer can write to the > > destination directory when running in Docker? > > Is it a regression/bug with jpackage? > > > I don't know what has changed in jpackage, maybe it didn't check for > write access previously. However, the error you are seeing suggests > there may be a lower-level issue, maybe a driver issue. It would be > useful if you could print out the DACL (using cacls is okay) and the DOS > attributes. > > -Alan > From ecki at zusammenkunft.net Tue Oct 5 10:02:47 2021 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Tue, 5 Oct 2021 10:02:47 +0000 Subject: Implementing JEP 400 on Windows 10 and Windows 11 In-Reply-To: <0a06028a-f5c1-a710-a097-8c88e32cd58d@oracle.com> References: <0a06028a-f5c1-a710-a097-8c88e32cd58d@oracle.com> Message-ID: I think the last sentence was missing a ?not? and referring to the same manifest? However the results are a bit of a mess, but utf-8 handling for argv would be great plus (if converted correctly), right? -- http://bernd.eckenfels.net ________________________________ Von: core-libs-dev im Auftrag von Magnus Ihse Bursie Gesendet: Tuesday, October 5, 2021 10:34:26 AM An: John Platts ; core-libs-dev Betreff: Re: Implementing JEP 400 on Windows 10 and Windows 11 On 2021-10-05 03:22, John Platts wrote: > I wrote a test program (in C++) to detect the codepages that would be returned by the GetACP(), GetOEMCP(), and GetConsoleCP() functions when the UTF-8 setting is added to the manifest. > > The manifest element (supported on Windows 10 Version 1903 or later) is in the http://schemas.microsoft.com/SMI/2019/WindowsSettings namespace and is added to the asmv3:WindowsSettings element as shown below: > xmlns:dpi2="http://schemas.microsoft.com/SMI/2016/WindowsSettings" > xmlns:utf8="http://schemas.microsoft.com/SMI/2019/WindowsSettings"> > true/PM > PerMonitorV2, PerMonitor, system > UTF-8 > > > Here is the output of the test program without the UTF-8 setting present in the executable manifest: > GetACP() result: 1252 > GetOEMCP() result: 437 > GetConsoleCP() result: 437 > System default LCID: 1033 > User default LCID: 1033 > User default UI LCID: 1033 > Codepage from system default LCID: 1252 > Codepage from user default LCID: 1252 > Codepage from user default UI LCID: 1252 > > Here is the output of the same test program with an executable manifest that includes the UTF-8 setting: > GetACP() result: 65001 > GetOEMCP() result: 65001 > GetConsoleCP() result: 437 > System default LCID: 1033 > User default LCID: 1033 > User default UI LCID: 1033 > Codepage from system default LCID: 1252 > Codepage from user default LCID: 1252 > Codepage from user default UI LCID: 1252 > > Note that the UTF-8 setting in the application manifest changes the results of the GetACP() and GetOEMCP() calls but not the GetConsoleCP() call. This is really confusing. I'm glad you are gathering empirical evidence of how it works. :-) > I wrote another test program, and the argument strings passed into the main(int argc, char** argv) function are converted to UTF-8 if the UTF-8 setting is there in the application manifest whereas the argument strings passed into the main (int argc, char** argv) function are converted to the ANSI codepage (which is usually code page 1252 on US English systems) if the UTF-8 setting is there in the UTF-8 manifest. I'm not sure I understand this. What is the difference between "the application manifest" and "the UTF-8 manifest"? /Magnus From aefimov at openjdk.java.net Tue Oct 5 12:10:28 2021 From: aefimov at openjdk.java.net (Aleksei Efimov) Date: Tue, 5 Oct 2021 12:10:28 GMT Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI Message-ID: This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver. The following API classes are added to `java.net.spi` package to facilitate this: - `InetAddressResolverProvider` - abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers. - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations. - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations. - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation. More details in [JEP-418](https://openjdk.java.net/jeps/418). Testing: new and existing `tier1:tier3` tests ------------- Commit messages: - 8244202: Implementation of JEP 418: Internet-Address Resolution SPI Changes: https://git.openjdk.java.net/jdk/pull/5822/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5822&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8244202 Stats: 2779 lines in 50 files changed: 2524 ins; 134 del; 121 mod Patch: https://git.openjdk.java.net/jdk/pull/5822.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5822/head:pull/5822 PR: https://git.openjdk.java.net/jdk/pull/5822 From github.com+10835776+stsypanov at openjdk.java.net Tue Oct 5 12:30:11 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Tue, 5 Oct 2021 12:30:11 GMT Subject: RFR: JDK-8274686 : java.util.UUID#hashCode() should use Long.hashCode() In-Reply-To: References: Message-ID: <1DkkXct04Yg4qNEPJu-YN0WrcIHrco3V4mWayUrkpy0=.2cc62cbd-7779-4caa-8976-a089b73b3b36@github.com> On Mon, 4 Oct 2021 21:13:02 GMT, PROgrm_JARvis wrote: > This is trivial fix of [JDK-8274686](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8274686) which replaces manually-computed `int`-based `long` hash-code. > > Because `Long#hashCode(long)` uses other hashing function than the one currently used here: > > https://github.com/openjdk/jdk/blob/75d6688df9845ecb8f370b4cd2d5a36f13d3cdc0/src/java.base/share/classes/java/lang/Long.java#L1440-L1442 > > the value of `hashCode()` will produce different result, however this does not seem to be a breaking change as `UUID#hashCode()` is not specified. > > --- > > Note: the comment to the bug states: > >> Moved to JDK for further discussions of the proposed enhancement. > > But as there seemed to be no corresponding discussion in core-libs-dev and the change looks trivial, I considered that it is appropriate to open a PR which (if needed) may be used for discussion (especially, considering the fact that its comments get mirrored to the ML). Good catch, this is what I've missed in https://github.com/openjdk/jdk/pull/4309 ------------- PR: https://git.openjdk.java.net/jdk/pull/5811 From github.com+10835776+stsypanov at openjdk.java.net Tue Oct 5 12:48:06 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Tue, 5 Oct 2021 12:48:06 GMT Subject: RFR: JDK-8274686 : java.util.UUID#hashCode() should use Long.hashCode() In-Reply-To: References: Message-ID: On Mon, 4 Oct 2021 21:13:02 GMT, PROgrm_JARvis wrote: > This is trivial fix of [JDK-8274686](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8274686) which replaces manually-computed `int`-based `long` hash-code. > > Because `Long#hashCode(long)` uses other hashing function than the one currently used here: > > https://github.com/openjdk/jdk/blob/75d6688df9845ecb8f370b4cd2d5a36f13d3cdc0/src/java.base/share/classes/java/lang/Long.java#L1440-L1442 > > the value of `hashCode()` will produce different result, however this does not seem to be a breaking change as `UUID#hashCode()` is not specified. > > --- > > Note: the comment to the bug states: > >> Moved to JDK for further discussions of the proposed enhancement. > > But as there seemed to be no corresponding discussion in core-libs-dev and the change looks trivial, I considered that it is appropriate to open a PR which (if needed) may be used for discussion (especially, considering the fact that its comments get mirrored to the ML). Marked as reviewed by stsypanov at github.com (no known OpenJDK username). ------------- PR: https://git.openjdk.java.net/jdk/pull/5811 From github.com+43264149+iaroslavski at openjdk.java.net Tue Oct 5 13:20:34 2021 From: github.com+43264149+iaroslavski at openjdk.java.net (iaroslavski) Date: Tue, 5 Oct 2021 13:20:34 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v5] 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) Better naming of methods ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3938/files - new: https://git.openjdk.java.net/jdk/pull/3938/files/adcc6942..90c08aed Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3938&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3938&range=03-04 Stats: 147 lines in 1 file changed: 0 ins; 0 del; 147 mod Patch: https://git.openjdk.java.net/jdk/pull/3938.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3938/head:pull/3938 PR: https://git.openjdk.java.net/jdk/pull/3938 From rriggs at openjdk.java.net Tue Oct 5 13:39:07 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 5 Oct 2021 13:39:07 GMT Subject: RFR: JDK-8274686 : java.util.UUID#hashCode() should use Long.hashCode() In-Reply-To: References: Message-ID: <6mRwvtsWN0oBNY1nNkSzb26rmvD2TLJQSGg9uui3Afk=.6eccd8a2-5770-4d8a-938f-27c4b7060ef2@github.com> On Mon, 4 Oct 2021 21:13:02 GMT, PROgrm_JARvis wrote: > This is trivial fix of [JDK-8274686](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8274686) which replaces manually-computed `int`-based `long` hash-code. > > Because `Long#hashCode(long)` uses other hashing function than the one currently used here: > > https://github.com/openjdk/jdk/blob/75d6688df9845ecb8f370b4cd2d5a36f13d3cdc0/src/java.base/share/classes/java/lang/Long.java#L1440-L1442 > > the value of `hashCode()` will produce different result, however this does not seem to be a breaking change as `UUID#hashCode()` is not specified. > > --- > > Note: the comment to the bug states: > >> Moved to JDK for further discussions of the proposed enhancement. > > But as there seemed to be no corresponding discussion in core-libs-dev and the change looks trivial, I considered that it is appropriate to open a PR which (if needed) may be used for discussion (especially, considering the fact that its comments get mirrored to the ML). Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5811 From github.com+741251+turbanoff at openjdk.java.net Tue Oct 5 13:40:12 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Tue, 5 Oct 2021 13:40:12 GMT Subject: Integrated: 8274079: Cleanup unnecessary calls to Throwable.initCause() in java.base module In-Reply-To: References: Message-ID: On Thu, 16 Sep 2021 19:03:26 GMT, Andrey Turbanov wrote: > Pass "cause" exception as constructor parameter is shorter and easier to read. This pull request has now been integrated. Changeset: 1459180f Author: Andrey Turbanov Committer: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/1459180f352a5632c0afca2ed55abf31e4b0bfb0 Stats: 132 lines in 22 files changed: 0 ins; 77 del; 55 mod 8274079: Cleanup unnecessary calls to Throwable.initCause() in java.base module Reviewed-by: weijun ------------- PR: https://git.openjdk.java.net/jdk/pull/5551 From aph-open at littlepinkcloud.com Tue Oct 5 13:58:25 2021 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Tue, 5 Oct 2021 14:58:25 +0100 Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v2] In-Reply-To: References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com> Message-ID: On 9/28/21 10:30, Raffaello Giulietti wrote: > I was pondering whether to propose adding a launch-time option on the command line to choose between the current and the proposed implementation for some time, so to help the community gaining confidence in the new algorithm and still have the current one as a fallback, just in case. (AFAIU, a launch-time option can be constant folded by the JIT compiler to help it eliminate dead code, right?) > > On the one hand, this adds complexity. On the other hand, it could help revive this dormant PR. > > What do you think? Would this be a viable option? It's a good-enough idea in theory, but I don't think it'd be accepted. Pinging Joe Darcy: do you (or any of your friends) have a good way to contact Guy Steele? -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From plevart at openjdk.java.net Tue Oct 5 14:21:16 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Tue, 5 Oct 2021 14:21:16 GMT Subject: Integrated: 8274299: Make Method/Constructor/Field accessors @Stable In-Reply-To: References: Message-ID: On Sat, 25 Sep 2021 10:15:11 GMT, Peter Levart wrote: > This patch improves reflective access speed as shown by the included benchmarks: > > https://jmh.morethan.io/?gists=902f4b43519c4f96c7abcd14cdc2d27d,ac490481e3001c710d75d6071c10b23a > > ... and is also a prerequisite to make JEP 416 (Reimplement Core Reflection with Method Handle) perform better in some circumstances. This pull request has now been integrated. Changeset: 7ad74d82 Author: Peter Levart URL: https://git.openjdk.java.net/jdk/commit/7ad74d82d7117113dd73966a0dd96168adfd6463 Stats: 784 lines in 13 files changed: 700 ins; 37 del; 47 mod 8274299: Make Method/Constructor/Field accessors @Stable Reviewed-by: redestad, mchung ------------- PR: https://git.openjdk.java.net/jdk/pull/5694 From james.laskey at oracle.com Tue Oct 5 14:41:07 2021 From: james.laskey at oracle.com (Jim Laskey) Date: Tue, 5 Oct 2021 14:41:07 +0000 Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v2] In-Reply-To: References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com> Message-ID: <83E126C1-3BFF-4870-A243-973E428BD2BC@oracle.com> I forwarded the issue to Guy again recently. No reply as yet. He?s a busy dude. Do we have any alternates? ?? > On Oct 5, 2021, at 10:58 AM, Andrew Haley wrote: > > ?On 9/28/21 10:30, Raffaello Giulietti wrote: >> I was pondering whether to propose adding a launch-time option on the command line to choose between the current and the proposed implementation for some time, so to help the community gaining confidence in the new algorithm and still have the current one as a fallback, just in case. (AFAIU, a launch-time option can be constant folded by the JIT compiler to help it eliminate dead code, right?) >> >> On the one hand, this adds complexity. On the other hand, it could help revive this dormant PR. >> >> What do you think? Would this be a viable option? > > It's a good-enough idea in theory, but I don't think it'd be accepted. > > Pinging Joe Darcy: do you (or any of your friends) have a good way > to contact Guy Steele? > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From itakiguchi at openjdk.java.net Tue Oct 5 16:04:11 2021 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Tue, 5 Oct 2021 16:04:11 GMT Subject: RFR: 8274544: Langtools command's usage were garbled on Japanese Windows In-Reply-To: References: Message-ID: <7Z2FjetdPfBfn1huJa-d1ZteNfOVjYmO5RSLFVrhJmA=.d22a8320-0337-4c25-959a-0e99ac8667ff@github.com> On Mon, 4 Oct 2021 10:24:01 GMT, Jan Lahoda wrote: >> Helllo @naotoj . >> I used `System.console()` and `Console.charset()`. >> >> The following executables had same issue, I fixed them. >>> jar.exe, javac.exe, javadoc.exe, javap.exe, jdeps.exe, jlink.exe, jmod.exe, jpackage.exe >> >> I could not find out the following executables had same issue or not >>> jabswitch.exe, jcmd.exe, jfr.exe, jhsdb.exe, jimage.exe, jinfo.exe, jmap.exe, jps.exe, jrunscript.exe, jstack.exe, jstat.exe, jstatd.exe, kinit.exe, klist.exe, ktab.exe >> >> The following executables worked fine. >>> jarsigner.exe, java.exe, javaw.exe, jdb.exe, jdeprscan.exe, jshell.exe, keytool.exe, rmiregistry.exe, serialver.exe >> >> The following executables were GUI apps >>> jaccessinspector.exe, jaccesswalker.exe, jconsole.exe >> >> These fixes don't have testcases. >> Do you have any idea about testcase for this issue ? > > @takiguc - if JShell is still an issue, is there a chance you could try this: > https://github.com/lahodaj/jdk/commit/cfa6b3eebbc22c5a48d31cfd692ff98690653686 > > Not sure if it will help, but it might (this won't change the default charset, but could send the output in a sensible encoding for the console. > > Thanks! Thanks, @lahodaj . I opened [JDK-8274784](https://bugs.openjdk.java.net/browse/JDK-8274784). I tested your code, it worked fine on standard case ! Many thanks. But, to execute previous saved command list, user needs to specify -J-Dfile.encoding=COMPAT and -R-Dfile.encoding=COMPAT options. Do you have any idea about this kind of case ? I'd like to discuss jshell things by [JDK-8274784](https://bugs.openjdk.java.net/browse/JDK-8274784). ------------- PR: https://git.openjdk.java.net/jdk/pull/5771 From martin at openjdk.java.net Tue Oct 5 17:19:09 2021 From: martin at openjdk.java.net (Martin Buchholz) Date: Tue, 5 Oct 2021 17:19:09 GMT Subject: RFR: 8274715: Implement forEach in Collections.CopiesList [v2] In-Reply-To: References: Message-ID: On Tue, 5 Oct 2021 09:18:57 GMT, ?????? ??????? wrote: >> Originally was proposed by Zheka Kozlov here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-December/057192.html >> >> Just a tiny optimization: we can use for-i loop instead of `Iterable.forEach()` which is relying on iterator. >> >> Simple benchmark demonstrates slight improvement: >> >> @State(Scope.Thread) >> @BenchmarkMode(Mode.AverageTime) >> @OutputTimeUnit(TimeUnit.NANOSECONDS) >> public class NCopiesBenchmarks { >> @Param({"10", "50", "100"}) >> int size; >> >> private List list; >> >> @Setup >> public void prepare() { >> list = Collections.nCopies(size, new Object()); >> } >> >> @Benchmark >> public void forEach(Blackhole bh) { >> list.forEach(bh::consume); >> } >> } >> >> >> >> before >> >> Benchmark (size) Mode Cnt Score Error Units >> NCopiesBenchmarks.forEach 10 avgt 50 40.737 ? 1.854 ns/op >> NCopiesBenchmarks.forEach:?gc.alloc.rate 10 avgt 50 0.001 ? 0.001 MB/sec >> NCopiesBenchmarks.forEach:?gc.alloc.rate.norm 10 avgt 50 ? 10?? B/op >> NCopiesBenchmarks.forEach:?gc.count 10 avgt 50 ? 0 counts >> NCopiesBenchmarks.forEach 50 avgt 50 213.324 ? 3.784 ns/op >> NCopiesBenchmarks.forEach:?gc.alloc.rate 50 avgt 50 0.001 ? 0.001 MB/sec >> NCopiesBenchmarks.forEach:?gc.alloc.rate.norm 50 avgt 50 ? 10?? B/op >> NCopiesBenchmarks.forEach:?gc.count 50 avgt 50 ? 0 counts >> NCopiesBenchmarks.forEach 100 avgt 50 443.171 ? 17.919 ns/op >> NCopiesBenchmarks.forEach:?gc.alloc.rate 100 avgt 50 0.001 ? 0.001 MB/sec >> NCopiesBenchmarks.forEach:?gc.alloc.rate.norm 100 avgt 50 0.001 ? 0.001 B/op >> NCopiesBenchmarks.forEach:?gc.count 100 avgt 50 ? 0 counts >> >> after >> >> Benchmark (size) Mode Cnt Score Error Units >> NCopiesBenchmarks.forEach 10 avgt 50 36.838 ? 0.065 ns/op >> NCopiesBenchmarks.forEach:?gc.alloc.rate 10 avgt 50 0.001 ? 0.001 MB/sec >> NCopiesBenchmarks.forEach:?gc.alloc.rate.norm 10 avgt 50 ? 10?? B/op >> NCopiesBenchmarks.forEach:?gc.count 10 avgt 50 ? 0 counts >> NCopiesBenchmarks.forEach 50 avgt 50 191.173 ? 0.570 ns/op >> NCopiesBenchmarks.forEach:?gc.alloc.rate 50 avgt 50 0.001 ? 0.001 MB/sec >> NCopiesBenchmarks.forEach:?gc.alloc.rate.norm 50 avgt 50 ? 10?? B/op >> NCopiesBenchmarks.forEach:?gc.count 50 avgt 50 ? 0 counts >> NCopiesBenchmarks.forEach 100 avgt 50 376.675 ? 2.476 ns/op >> NCopiesBenchmarks.forEach:?gc.alloc.rate 100 avgt 50 0.001 ? 0.001 MB/sec >> NCopiesBenchmarks.forEach:?gc.alloc.rate.norm 100 avgt 50 0.001 ? 0.001 B/op >> NCopiesBenchmarks.forEach:?gc.count 100 avgt 50 ? 0 counts > > ?????? ??????? 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 ncopies > - 8274715: Add NCopiesBenchmarks.java > - 8274715: Revert some irrelevant changes > - 8274715: Implement forEach in Collections.CopiesList Thanks - TIL about Blackhole::consume . All Java source files should end with exactly one newline. Configure your editor to make it so. ------------- Changes requested by martin (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2524 From prr at openjdk.java.net Tue Oct 5 17:34:24 2021 From: prr at openjdk.java.net (Phil Race) Date: Tue, 5 Oct 2021 17:34:24 GMT Subject: Integrated: 8274397: [macOS] Stop setting env. var JAVA_MAIN_CLASS_ in launcher code In-Reply-To: <8j-vMsDYbF5100Dpc1DP_JGNV5V0W0D7i2fP7QnXCpU=.9169a246-f866-49c5-99fb-04f9fb946b9e@github.com> References: <8j-vMsDYbF5100Dpc1DP_JGNV5V0W0D7i2fP7QnXCpU=.9169a246-f866-49c5-99fb-04f9fb946b9e@github.com> Message-ID: On Mon, 27 Sep 2021 20:56:28 GMT, Phil Race wrote: > macOS launcher code sets JAVA_MAIN_CLASS_ which is read by AWT to set the name of the application in the system menu bar. > > Because this set shortly after the VM is running, it causes a thread safety issue described in https://bugs.openjdk.java.net/browse/JDK-8270549 > > Since the AWT already looks for the system property "apple.awt.application.name" for this same purpose, > we can set that instead of the env. var and avoid the threading issue. > > This trades the JAVA_MAIN_CLASS_ pollution of the environment for setting a system property which is visible to apps as well but it seems a reasonable trade-off since we already (implicitly) support this variable anyway in preference to the env. var. This pull request has now been integrated. Changeset: 37890650 Author: Phil Race URL: https://git.openjdk.java.net/jdk/commit/37890650a7c97d484b6b520d909f677dac4e46e1 Stats: 205 lines in 5 files changed: 159 ins; 26 del; 20 mod 8274397: [macOS] Stop setting env. var JAVA_MAIN_CLASS_ in launcher code Reviewed-by: rriggs, serb ------------- PR: https://git.openjdk.java.net/jdk/pull/5724 From github.com+10835776+stsypanov at openjdk.java.net Tue Oct 5 17:51:31 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Tue, 5 Oct 2021 17:51:31 GMT Subject: RFR: 8274715: Implement forEach in Collections.CopiesList [v3] In-Reply-To: References: Message-ID: <6czUf6Lb_AWoPke0bpkOmIpp76EX6BlGYTG_c7FmpfI=.c7892a55-ce92-46b6-859f-afa59d31daee@github.com> > Originally was proposed by Zheka Kozlov here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-December/057192.html > > Just a tiny optimization: we can use for-i loop instead of `Iterable.forEach()` which is relying on iterator. > > Simple benchmark demonstrates slight improvement: > > @State(Scope.Thread) > @BenchmarkMode(Mode.AverageTime) > @OutputTimeUnit(TimeUnit.NANOSECONDS) > public class NCopiesBenchmarks { > @Param({"10", "50", "100"}) > int size; > > private List list; > > @Setup > public void prepare() { > list = Collections.nCopies(size, new Object()); > } > > @Benchmark > public void forEach(Blackhole bh) { > list.forEach(bh::consume); > } > } > > > > before > > Benchmark (size) Mode Cnt Score Error Units > NCopiesBenchmarks.forEach 10 avgt 50 40.737 ? 1.854 ns/op > NCopiesBenchmarks.forEach:?gc.alloc.rate 10 avgt 50 0.001 ? 0.001 MB/sec > NCopiesBenchmarks.forEach:?gc.alloc.rate.norm 10 avgt 50 ? 10?? B/op > NCopiesBenchmarks.forEach:?gc.count 10 avgt 50 ? 0 counts > NCopiesBenchmarks.forEach 50 avgt 50 213.324 ? 3.784 ns/op > NCopiesBenchmarks.forEach:?gc.alloc.rate 50 avgt 50 0.001 ? 0.001 MB/sec > NCopiesBenchmarks.forEach:?gc.alloc.rate.norm 50 avgt 50 ? 10?? B/op > NCopiesBenchmarks.forEach:?gc.count 50 avgt 50 ? 0 counts > NCopiesBenchmarks.forEach 100 avgt 50 443.171 ? 17.919 ns/op > NCopiesBenchmarks.forEach:?gc.alloc.rate 100 avgt 50 0.001 ? 0.001 MB/sec > NCopiesBenchmarks.forEach:?gc.alloc.rate.norm 100 avgt 50 0.001 ? 0.001 B/op > NCopiesBenchmarks.forEach:?gc.count 100 avgt 50 ? 0 counts > > after > > Benchmark (size) Mode Cnt Score Error Units > NCopiesBenchmarks.forEach 10 avgt 50 36.838 ? 0.065 ns/op > NCopiesBenchmarks.forEach:?gc.alloc.rate 10 avgt 50 0.001 ? 0.001 MB/sec > NCopiesBenchmarks.forEach:?gc.alloc.rate.norm 10 avgt 50 ? 10?? B/op > NCopiesBenchmarks.forEach:?gc.count 10 avgt 50 ? 0 counts > NCopiesBenchmarks.forEach 50 avgt 50 191.173 ? 0.570 ns/op > NCopiesBenchmarks.forEach:?gc.alloc.rate 50 avgt 50 0.001 ? 0.001 MB/sec > NCopiesBenchmarks.forEach:?gc.alloc.rate.norm 50 avgt 50 ? 10?? B/op > NCopiesBenchmarks.forEach:?gc.count 50 avgt 50 ? 0 counts > NCopiesBenchmarks.forEach 100 avgt 50 376.675 ? 2.476 ns/op > NCopiesBenchmarks.forEach:?gc.alloc.rate 100 avgt 50 0.001 ? 0.001 MB/sec > NCopiesBenchmarks.forEach:?gc.alloc.rate.norm 100 avgt 50 0.001 ? 0.001 B/op > NCopiesBenchmarks.forEach:?gc.count 100 avgt 50 ? 0 counts ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: 8274715: Properly format NCopiesBenchmarks.java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2524/files - new: https://git.openjdk.java.net/jdk/pull/2524/files/18f5d589..7655be8f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2524&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2524&range=01-02 Stats: 13 lines in 1 file changed: 1 ins; 0 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/2524.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2524/head:pull/2524 PR: https://git.openjdk.java.net/jdk/pull/2524 From github.com+10835776+stsypanov at openjdk.java.net Tue Oct 5 17:51:47 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Tue, 5 Oct 2021 17:51:47 GMT Subject: RFR: 8274715: Implement forEach in Collections.CopiesList [v2] In-Reply-To: References: Message-ID: On Tue, 5 Oct 2021 09:18:57 GMT, ?????? ??????? wrote: >> Originally was proposed by Zheka Kozlov here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-December/057192.html >> >> Just a tiny optimization: we can use for-i loop instead of `Iterable.forEach()` which is relying on iterator. >> >> Simple benchmark demonstrates slight improvement: >> >> @State(Scope.Thread) >> @BenchmarkMode(Mode.AverageTime) >> @OutputTimeUnit(TimeUnit.NANOSECONDS) >> public class NCopiesBenchmarks { >> @Param({"10", "50", "100"}) >> int size; >> >> private List list; >> >> @Setup >> public void prepare() { >> list = Collections.nCopies(size, new Object()); >> } >> >> @Benchmark >> public void forEach(Blackhole bh) { >> list.forEach(bh::consume); >> } >> } >> >> >> >> before >> >> Benchmark (size) Mode Cnt Score Error Units >> NCopiesBenchmarks.forEach 10 avgt 50 40.737 ? 1.854 ns/op >> NCopiesBenchmarks.forEach:?gc.alloc.rate 10 avgt 50 0.001 ? 0.001 MB/sec >> NCopiesBenchmarks.forEach:?gc.alloc.rate.norm 10 avgt 50 ? 10?? B/op >> NCopiesBenchmarks.forEach:?gc.count 10 avgt 50 ? 0 counts >> NCopiesBenchmarks.forEach 50 avgt 50 213.324 ? 3.784 ns/op >> NCopiesBenchmarks.forEach:?gc.alloc.rate 50 avgt 50 0.001 ? 0.001 MB/sec >> NCopiesBenchmarks.forEach:?gc.alloc.rate.norm 50 avgt 50 ? 10?? B/op >> NCopiesBenchmarks.forEach:?gc.count 50 avgt 50 ? 0 counts >> NCopiesBenchmarks.forEach 100 avgt 50 443.171 ? 17.919 ns/op >> NCopiesBenchmarks.forEach:?gc.alloc.rate 100 avgt 50 0.001 ? 0.001 MB/sec >> NCopiesBenchmarks.forEach:?gc.alloc.rate.norm 100 avgt 50 0.001 ? 0.001 B/op >> NCopiesBenchmarks.forEach:?gc.count 100 avgt 50 ? 0 counts >> >> after >> >> Benchmark (size) Mode Cnt Score Error Units >> NCopiesBenchmarks.forEach 10 avgt 50 36.838 ? 0.065 ns/op >> NCopiesBenchmarks.forEach:?gc.alloc.rate 10 avgt 50 0.001 ? 0.001 MB/sec >> NCopiesBenchmarks.forEach:?gc.alloc.rate.norm 10 avgt 50 ? 10?? B/op >> NCopiesBenchmarks.forEach:?gc.count 10 avgt 50 ? 0 counts >> NCopiesBenchmarks.forEach 50 avgt 50 191.173 ? 0.570 ns/op >> NCopiesBenchmarks.forEach:?gc.alloc.rate 50 avgt 50 0.001 ? 0.001 MB/sec >> NCopiesBenchmarks.forEach:?gc.alloc.rate.norm 50 avgt 50 ? 10?? B/op >> NCopiesBenchmarks.forEach:?gc.count 50 avgt 50 ? 0 counts >> NCopiesBenchmarks.forEach 100 avgt 50 376.675 ? 2.476 ns/op >> NCopiesBenchmarks.forEach:?gc.alloc.rate 100 avgt 50 0.001 ? 0.001 MB/sec >> NCopiesBenchmarks.forEach:?gc.alloc.rate.norm 100 avgt 50 0.001 ? 0.001 B/op >> NCopiesBenchmarks.forEach:?gc.count 100 avgt 50 ? 0 counts > > ?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge branch 'master' into ncopies > - 8274715: Add NCopiesBenchmarks.java > - 8274715: Revert some irrelevant changes > - 8274715: Implement forEach in Collections.CopiesList Done ------------- PR: https://git.openjdk.java.net/jdk/pull/2524 From martin at openjdk.java.net Tue Oct 5 17:56:09 2021 From: martin at openjdk.java.net (Martin Buchholz) Date: Tue, 5 Oct 2021 17:56:09 GMT Subject: RFR: 8274715: Implement forEach in Collections.CopiesList [v3] In-Reply-To: <6czUf6Lb_AWoPke0bpkOmIpp76EX6BlGYTG_c7FmpfI=.c7892a55-ce92-46b6-859f-afa59d31daee@github.com> References: <6czUf6Lb_AWoPke0bpkOmIpp76EX6BlGYTG_c7FmpfI=.c7892a55-ce92-46b6-859f-afa59d31daee@github.com> Message-ID: On Tue, 5 Oct 2021 17:51:31 GMT, ?????? ??????? wrote: >> Originally was proposed by Zheka Kozlov here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-December/057192.html >> >> Just a tiny optimization: we can use for-i loop instead of `Iterable.forEach()` which is relying on iterator. >> >> Simple benchmark demonstrates slight improvement: >> >> @State(Scope.Thread) >> @BenchmarkMode(Mode.AverageTime) >> @OutputTimeUnit(TimeUnit.NANOSECONDS) >> public class NCopiesBenchmarks { >> @Param({"10", "50", "100"}) >> int size; >> >> private List list; >> >> @Setup >> public void prepare() { >> list = Collections.nCopies(size, new Object()); >> } >> >> @Benchmark >> public void forEach(Blackhole bh) { >> list.forEach(bh::consume); >> } >> } >> >> >> >> before >> >> Benchmark (size) Mode Cnt Score Error Units >> NCopiesBenchmarks.forEach 10 avgt 50 40.737 ? 1.854 ns/op >> NCopiesBenchmarks.forEach:?gc.alloc.rate 10 avgt 50 0.001 ? 0.001 MB/sec >> NCopiesBenchmarks.forEach:?gc.alloc.rate.norm 10 avgt 50 ? 10?? B/op >> NCopiesBenchmarks.forEach:?gc.count 10 avgt 50 ? 0 counts >> NCopiesBenchmarks.forEach 50 avgt 50 213.324 ? 3.784 ns/op >> NCopiesBenchmarks.forEach:?gc.alloc.rate 50 avgt 50 0.001 ? 0.001 MB/sec >> NCopiesBenchmarks.forEach:?gc.alloc.rate.norm 50 avgt 50 ? 10?? B/op >> NCopiesBenchmarks.forEach:?gc.count 50 avgt 50 ? 0 counts >> NCopiesBenchmarks.forEach 100 avgt 50 443.171 ? 17.919 ns/op >> NCopiesBenchmarks.forEach:?gc.alloc.rate 100 avgt 50 0.001 ? 0.001 MB/sec >> NCopiesBenchmarks.forEach:?gc.alloc.rate.norm 100 avgt 50 0.001 ? 0.001 B/op >> NCopiesBenchmarks.forEach:?gc.count 100 avgt 50 ? 0 counts >> >> after >> >> Benchmark (size) Mode Cnt Score Error Units >> NCopiesBenchmarks.forEach 10 avgt 50 36.838 ? 0.065 ns/op >> NCopiesBenchmarks.forEach:?gc.alloc.rate 10 avgt 50 0.001 ? 0.001 MB/sec >> NCopiesBenchmarks.forEach:?gc.alloc.rate.norm 10 avgt 50 ? 10?? B/op >> NCopiesBenchmarks.forEach:?gc.count 10 avgt 50 ? 0 counts >> NCopiesBenchmarks.forEach 50 avgt 50 191.173 ? 0.570 ns/op >> NCopiesBenchmarks.forEach:?gc.alloc.rate 50 avgt 50 0.001 ? 0.001 MB/sec >> NCopiesBenchmarks.forEach:?gc.alloc.rate.norm 50 avgt 50 ? 10?? B/op >> NCopiesBenchmarks.forEach:?gc.count 50 avgt 50 ? 0 counts >> NCopiesBenchmarks.forEach 100 avgt 50 376.675 ? 2.476 ns/op >> NCopiesBenchmarks.forEach:?gc.alloc.rate 100 avgt 50 0.001 ? 0.001 MB/sec >> NCopiesBenchmarks.forEach:?gc.alloc.rate.norm 100 avgt 50 0.001 ? 0.001 B/op >> NCopiesBenchmarks.forEach:?gc.count 100 avgt 50 ? 0 counts > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8274715: Properly format NCopiesBenchmarks.java Looks good! ------------- Marked as reviewed by martin (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2524 From igraves at openjdk.java.net Tue Oct 5 19:20:20 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Tue, 5 Oct 2021 19:20:20 GMT Subject: RFR: 8217496: Matcher.group() can return null after usePattern Message-ID: <5VUg9AMdKK73UL-f9S6MFD17Hsmhi5IxQi4bib6gF3g=.8066f78b-fb15-4d6a-a3d0-f5e863fe3e6a@github.com> Specification update to clarify Matcher behavior to include a null return value. ------------- Commit messages: - 8217496 Matcher.group() can return null after usePattern Changes: https://git.openjdk.java.net/jdk/pull/5827/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5827&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8217496 Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5827.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5827/head:pull/5827 PR: https://git.openjdk.java.net/jdk/pull/5827 From martin at openjdk.java.net Tue Oct 5 22:24:12 2021 From: martin at openjdk.java.net (Martin Buchholz) Date: Tue, 5 Oct 2021 22:24:12 GMT Subject: RFR: 8274715: Implement forEach in Collections.CopiesList [v3] In-Reply-To: <6czUf6Lb_AWoPke0bpkOmIpp76EX6BlGYTG_c7FmpfI=.c7892a55-ce92-46b6-859f-afa59d31daee@github.com> References: <6czUf6Lb_AWoPke0bpkOmIpp76EX6BlGYTG_c7FmpfI=.c7892a55-ce92-46b6-859f-afa59d31daee@github.com> Message-ID: On Tue, 5 Oct 2021 17:51:31 GMT, ?????? ??????? wrote: >> Originally was proposed by Zheka Kozlov here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-December/057192.html >> >> Just a tiny optimization: we can use for-i loop instead of `Iterable.forEach()` which is relying on iterator. >> >> Simple benchmark demonstrates slight improvement: >> >> @State(Scope.Thread) >> @BenchmarkMode(Mode.AverageTime) >> @OutputTimeUnit(TimeUnit.NANOSECONDS) >> public class NCopiesBenchmarks { >> @Param({"10", "50", "100"}) >> int size; >> >> private List list; >> >> @Setup >> public void prepare() { >> list = Collections.nCopies(size, new Object()); >> } >> >> @Benchmark >> public void forEach(Blackhole bh) { >> list.forEach(bh::consume); >> } >> } >> >> >> >> before >> >> Benchmark (size) Mode Cnt Score Error Units >> NCopiesBenchmarks.forEach 10 avgt 50 40.737 ? 1.854 ns/op >> NCopiesBenchmarks.forEach:?gc.alloc.rate 10 avgt 50 0.001 ? 0.001 MB/sec >> NCopiesBenchmarks.forEach:?gc.alloc.rate.norm 10 avgt 50 ? 10?? B/op >> NCopiesBenchmarks.forEach:?gc.count 10 avgt 50 ? 0 counts >> NCopiesBenchmarks.forEach 50 avgt 50 213.324 ? 3.784 ns/op >> NCopiesBenchmarks.forEach:?gc.alloc.rate 50 avgt 50 0.001 ? 0.001 MB/sec >> NCopiesBenchmarks.forEach:?gc.alloc.rate.norm 50 avgt 50 ? 10?? B/op >> NCopiesBenchmarks.forEach:?gc.count 50 avgt 50 ? 0 counts >> NCopiesBenchmarks.forEach 100 avgt 50 443.171 ? 17.919 ns/op >> NCopiesBenchmarks.forEach:?gc.alloc.rate 100 avgt 50 0.001 ? 0.001 MB/sec >> NCopiesBenchmarks.forEach:?gc.alloc.rate.norm 100 avgt 50 0.001 ? 0.001 B/op >> NCopiesBenchmarks.forEach:?gc.count 100 avgt 50 ? 0 counts >> >> after >> >> Benchmark (size) Mode Cnt Score Error Units >> NCopiesBenchmarks.forEach 10 avgt 50 36.838 ? 0.065 ns/op >> NCopiesBenchmarks.forEach:?gc.alloc.rate 10 avgt 50 0.001 ? 0.001 MB/sec >> NCopiesBenchmarks.forEach:?gc.alloc.rate.norm 10 avgt 50 ? 10?? B/op >> NCopiesBenchmarks.forEach:?gc.count 10 avgt 50 ? 0 counts >> NCopiesBenchmarks.forEach 50 avgt 50 191.173 ? 0.570 ns/op >> NCopiesBenchmarks.forEach:?gc.alloc.rate 50 avgt 50 0.001 ? 0.001 MB/sec >> NCopiesBenchmarks.forEach:?gc.alloc.rate.norm 50 avgt 50 ? 10?? B/op >> NCopiesBenchmarks.forEach:?gc.count 50 avgt 50 ? 0 counts >> NCopiesBenchmarks.forEach 100 avgt 50 376.675 ? 2.476 ns/op >> NCopiesBenchmarks.forEach:?gc.alloc.rate 100 avgt 50 0.001 ? 0.001 MB/sec >> NCopiesBenchmarks.forEach:?gc.alloc.rate.norm 100 avgt 50 0.001 ? 0.001 B/op >> NCopiesBenchmarks.forEach:?gc.count 100 avgt 50 ? 0 counts > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8274715: Properly format NCopiesBenchmarks.java I've never sponsored a github change and https://openjdk.java.net/sponsor/ is unhelpfully stale. Oh wait ... I now see https://wiki.openjdk.java.net/display/SKARA/Pull+Request+Commands#PullRequestCommands-/sponsor ------------- PR: https://git.openjdk.java.net/jdk/pull/2524 From github.com+10835776+stsypanov at openjdk.java.net Tue Oct 5 22:24:13 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Tue, 5 Oct 2021 22:24:13 GMT Subject: Integrated: 8274715: Implement forEach in Collections.CopiesList In-Reply-To: References: Message-ID: On Thu, 11 Feb 2021 13:28:49 GMT, ?????? ??????? wrote: > Originally was proposed by Zheka Kozlov here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-December/057192.html > > Just a tiny optimization: we can use for-i loop instead of `Iterable.forEach()` which is relying on iterator. > > Simple benchmark demonstrates slight improvement: > > @State(Scope.Thread) > @BenchmarkMode(Mode.AverageTime) > @OutputTimeUnit(TimeUnit.NANOSECONDS) > public class NCopiesBenchmarks { > @Param({"10", "50", "100"}) > int size; > > private List list; > > @Setup > public void prepare() { > list = Collections.nCopies(size, new Object()); > } > > @Benchmark > public void forEach(Blackhole bh) { > list.forEach(bh::consume); > } > } > > > > before > > Benchmark (size) Mode Cnt Score Error Units > NCopiesBenchmarks.forEach 10 avgt 50 40.737 ? 1.854 ns/op > NCopiesBenchmarks.forEach:?gc.alloc.rate 10 avgt 50 0.001 ? 0.001 MB/sec > NCopiesBenchmarks.forEach:?gc.alloc.rate.norm 10 avgt 50 ? 10?? B/op > NCopiesBenchmarks.forEach:?gc.count 10 avgt 50 ? 0 counts > NCopiesBenchmarks.forEach 50 avgt 50 213.324 ? 3.784 ns/op > NCopiesBenchmarks.forEach:?gc.alloc.rate 50 avgt 50 0.001 ? 0.001 MB/sec > NCopiesBenchmarks.forEach:?gc.alloc.rate.norm 50 avgt 50 ? 10?? B/op > NCopiesBenchmarks.forEach:?gc.count 50 avgt 50 ? 0 counts > NCopiesBenchmarks.forEach 100 avgt 50 443.171 ? 17.919 ns/op > NCopiesBenchmarks.forEach:?gc.alloc.rate 100 avgt 50 0.001 ? 0.001 MB/sec > NCopiesBenchmarks.forEach:?gc.alloc.rate.norm 100 avgt 50 0.001 ? 0.001 B/op > NCopiesBenchmarks.forEach:?gc.count 100 avgt 50 ? 0 counts > > after > > Benchmark (size) Mode Cnt Score Error Units > NCopiesBenchmarks.forEach 10 avgt 50 36.838 ? 0.065 ns/op > NCopiesBenchmarks.forEach:?gc.alloc.rate 10 avgt 50 0.001 ? 0.001 MB/sec > NCopiesBenchmarks.forEach:?gc.alloc.rate.norm 10 avgt 50 ? 10?? B/op > NCopiesBenchmarks.forEach:?gc.count 10 avgt 50 ? 0 counts > NCopiesBenchmarks.forEach 50 avgt 50 191.173 ? 0.570 ns/op > NCopiesBenchmarks.forEach:?gc.alloc.rate 50 avgt 50 0.001 ? 0.001 MB/sec > NCopiesBenchmarks.forEach:?gc.alloc.rate.norm 50 avgt 50 ? 10?? B/op > NCopiesBenchmarks.forEach:?gc.count 50 avgt 50 ? 0 counts > NCopiesBenchmarks.forEach 100 avgt 50 376.675 ? 2.476 ns/op > NCopiesBenchmarks.forEach:?gc.alloc.rate 100 avgt 50 0.001 ? 0.001 MB/sec > NCopiesBenchmarks.forEach:?gc.alloc.rate.norm 100 avgt 50 0.001 ? 0.001 B/op > NCopiesBenchmarks.forEach:?gc.count 100 avgt 50 ? 0 counts This pull request has now been integrated. Changeset: df7b0c70 Author: Sergey Tsypanov Committer: Martin Buchholz URL: https://git.openjdk.java.net/jdk/commit/df7b0c707713195c93ff4e745c89155ee8e4c571 Stats: 44 lines in 2 files changed: 44 ins; 0 del; 0 mod 8274715: Implement forEach in Collections.CopiesList Reviewed-by: martin ------------- PR: https://git.openjdk.java.net/jdk/pull/2524 From github.com+70726043+rgiulietti at openjdk.java.net Tue Oct 5 23:20:17 2021 From: github.com+70726043+rgiulietti at openjdk.java.net (Raffaello Giulietti) Date: Tue, 5 Oct 2021 23:20:17 GMT Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v2] In-Reply-To: References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com> Message-ID: On Fri, 16 Apr 2021 11:30:32 GMT, Raffaello Giulietti wrote: >> Hello, >> >> here's a PR for a patch submitted on March 2020 [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a thing. >> >> The patch has been edited to adhere to OpenJDK code conventions about multi-line (block) comments. Nothing in the code proper has changed, except for the addition of redundant but clarifying parentheses in some expressions. >> >> >> Greetings >> Raffaello > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > 4511638: Double.toString(double) sometimes produces incorrect results Hello, thanks for reading my writing. In some way, Ryu and Schubfach are similar in the sense that both are based on the observation that good, fixed size approximations of powers of 10 lead to extremely efficient algorithms. Both algorithms end up with a lookup table of 617 approximations. The proof of the central theorem of Schubfach is based on continued fractions. It was prepared on ACL2 by the late Dmitry Nadezhin, who was a member of Oracle's formal verification group. Dmitry also knew my writing inside-out: not a formal peer review but perhaps even more insightful. Schubfach has been exhaustively tested on all 2^32 floats, with approximations of powers of 10 of 63 bits each, rather than the full 126 bits used for doubles (the minimum size for doubles is 123 bits). It has also been tested for months on doubles, accumulating several trillions of witnesses and no failure. The exhaustive test on floats is an optionally executed part of the contributed code. After more than 25 years the current JDK implementation still contains anomalies, so I guess it isn't tested as well as Schubfach. A complete Schubfach conversion only depends on some dozens of primitive operations (it doesn't even need any sort of hardware division at all) and on a lookup table (fully tested for correctness in the contributed code). The current implementation in the JDK relies on the correctness of BigInteger and related classes, which are way more complex to thoroughly test and to be confident upon. Checking whether the 617 tabulated powers of 10 are very close to powers of 2 would be very easy, so I'm not sure I understand your point. Identifying the hard cases would require even more theory and would be an endeavor in itself. This theory could, in turn, contain small errors and would probably require identifying its hard cases... According to its author, DragonBox combines Schubfach and Grisu. AFAIK, there's no new fundamental underlying theory. During development of Schubfach, I experimented with a similar mix: on the JVM of the time (2018) performance was worse than pure Schubfach and the code more complex, so I gave up and switched back to the simpler design, which C2 likes better. Greetings Raffaello ------------- PR: https://git.openjdk.java.net/jdk/pull/3402 From github.com+70726043+rgiulietti at openjdk.java.net Wed Oct 6 00:05:09 2021 From: github.com+70726043+rgiulietti at openjdk.java.net (Raffaello Giulietti) Date: Wed, 6 Oct 2021 00:05:09 GMT Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v2] In-Reply-To: References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com> Message-ID: On Fri, 16 Apr 2021 11:30:32 GMT, Raffaello Giulietti wrote: >> Hello, >> >> here's a PR for a patch submitted on March 2020 [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a thing. >> >> The patch has been edited to adhere to OpenJDK code conventions about multi-line (block) comments. Nothing in the code proper has changed, except for the addition of redundant but clarifying parentheses in some expressions. >> >> >> Greetings >> Raffaello > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > 4511638: Double.toString(double) sometimes produces incorrect results Hi, here's Guy's original email which I got intact in my mailbox but which appears completely garbled on this PR page (if you are reading it) or does not appear at all in this mailing list (if you are reading that). I repeat my comment as well HTH ---- Hi, sorry for the silence. Back in April 2021 I did read the entire Schubfach paper as well as two papers about Ryu by Adams. Schubfach looks intriguing, but it depends (as so many of these algorithms do) on a subtle proof. I am glad to see that the proof, or parts of it, are machine-checked in some way. I would be a lot more confident if this proof were also subjected to peer review. These algorithms are very much like the buggy Pentium FDIV: nearly all the cases are easy, but the cases that are hard (and therefore may potentially fail if you get that part of the algorithm wrong) are very rare, so doing good testing is tricky and deserves attention. If we can identify those hard cases (typically related to edge cases in the table entries) perhaps we can develop a good testing methodology. I would suspect that these hard cases relate to situations where a power of (1/5) is very close to a power of (1/2) (and therefore the corresponding power of 5 is very close to a power of 2), but t he details matter. Now that I have finished addressing bug https://bugs.openjdk.java.net/browse/JDK-8273792 (JumpableGenerator.rngs() documentation refers to wrong method) and bug https://bugs.openjdk.java.net/browse/JDK-8273056 (java.util.random does not correctly sample exponential or Gaussian distributions), I am now re-reading the Schubfach paper and am also investigating mentions of an implementation of that algorithm called DragonBox. I will have more to say by Friday (I have a Thursday deadline for something else). ?Guy ---- Hello, thanks for reading my writing. In some way, Ryu and Schubfach are similar in the sense that both are based on the observation that good, fixed size approximations of powers of 10 lead to extremely efficient algorithms. Both algorithms end up with a lookup table of 617 approximations. The proof of the central theorem of Schubfach is based on continued fractions. It was prepared on ACL2 by the late Dmitry Nadezhin, who was a member of Oracle's formal verification group. Dmitry also knew my writing inside-out: not a formal peer review but perhaps even more insightful. Schubfach has been exhaustively tested on all 2^32 floats, with approximations of powers of 10 of 63 bits each, rather than the full 126 bits used for doubles (the minimum size for doubles is 123 bits). It has also been tested for months on doubles, accumulating several trillions of witnesses and no failure. The exhaustive test on floats is an optionally executed part of the contributed code. After more than 25 years the current JDK implementation still contains anomalies, so I guess it isn't tested as well as Schubfach. A complete Schubfach conversion only depends on some dozens of primitive operations (it doesn't even need any sort of hardware division at all) and on a lookup table (fully tested for correctness in the contributed code). The current implementation in the JDK relies on the correctness of BigInteger and related classes, which are way more complex to thoroughly test and to be confident upon. Checking whether the 617 tabulated powers of 10 are very close to powers of 2 would be very easy, so I'm not sure I understand your point. Identifying the hard cases would require even more theory and would be an endeavor in itself. This theory could, in turn, contain small errors and would probably require identifying its hard cases... According to its author, DragonBox combines Schubfach and Grisu. AFAIK, there's no new fundamental underlying theory. During development of Schubfach, I experimented with a similar mix: on the JVM of the time (2018) performance was worse than pure Schubfach and the code more complex, so I gave up and switched back to the simpler design, which C2 likes better. Greetings Raffaello ------------- PR: https://git.openjdk.java.net/jdk/pull/3402 From naoto at openjdk.java.net Wed Oct 6 00:06:06 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 6 Oct 2021 00:06:06 GMT Subject: RFR: 8274544: Langtools command's usage were garbled on Japanese Windows [v2] In-Reply-To: References: Message-ID: On Mon, 4 Oct 2021 07:13:37 GMT, Ichiroh Takiguchi wrote: >> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13. >> After JDK18-b13, javac and some other langtool command's usage were garbled on Japanese Windows. >> These commands use PrintWriter instead of standard out/err with PrintStream. > > Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision: > > 8274544: Langtools command's usage were garbled on Japanese Windows I just grepped `System.out/err` in jshell source directory, and found another location in `tool/JShellToolProvider.java` that uses bare stdout/err. Would you also apply the fix and see the result? ------------- PR: https://git.openjdk.java.net/jdk/pull/5771 From naoto at openjdk.java.net Wed Oct 6 03:17:27 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 6 Oct 2021 03:17:27 GMT Subject: RFR: 8274407: (tz) Update Timezone Data to 2021c Message-ID: This PR is to upgrade the time zone data in the JDK to IANA's tzdata2021c level. Note that the tz data is "as is", as released by IANA. No `merged links` are retracted. The PR also fixes two issues along with the 2021c upgrade. ------------- Commit messages: - Fix for Asia/Amman test case error - Test fix for Samoa not observing DST - tzdata2021c - 8274407: (tz) Update Timezone Data to 2021b Changes: https://git.openjdk.java.net/jdk/pull/5832/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5832&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274407 Stats: 635 lines in 13 files changed: 228 ins; 329 del; 78 mod Patch: https://git.openjdk.java.net/jdk/pull/5832.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5832/head:pull/5832 PR: https://git.openjdk.java.net/jdk/pull/5832 From itakiguchi at openjdk.java.net Wed Oct 6 05:04:28 2021 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Wed, 6 Oct 2021 05:04:28 GMT Subject: RFR: 8274544: Langtools command's usage were garbled on Japanese Windows [v3] In-Reply-To: References: Message-ID: > JEP-400 (UTF-8 by Default) was eabled on JDK18-b13. > After JDK18-b13, javac and some other langtool command's usage were garbled on Japanese Windows. > These commands use PrintWriter instead of standard out/err with PrintStream. Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision: 8274544: Langtools command's usage were garbled on Japanese Windows ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5771/files - new: https://git.openjdk.java.net/jdk/pull/5771/files/bfe90241..4427d87c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5771&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5771&range=01-02 Stats: 61 lines in 8 files changed: 32 ins; 21 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/5771.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5771/head:pull/5771 PR: https://git.openjdk.java.net/jdk/pull/5771 From itakiguchi at openjdk.java.net Wed Oct 6 05:09:08 2021 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Wed, 6 Oct 2021 05:09:08 GMT Subject: RFR: 8274544: Langtools command's usage were garbled on Japanese Windows [v2] In-Reply-To: References: Message-ID: On Mon, 4 Oct 2021 16:24:18 GMT, Naoto Sato wrote: >> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision: >> >> 8274544: Langtools command's usage were garbled on Japanese Windows > > src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java line 265: > >> 263: * @return a map of writers >> 264: */ >> 265: private final static Charset nativeCharset; > > Inserting this static initializer in the middle of a method, between its javadoc and impl, is odd. Moved to another place > src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java line 267: > >> 265: private final static Charset nativeCharset; >> 266: static { >> 267: Charset cs = Charset.defaultCharset(); > > This could move into the `catch` section as a last resort. Move `cs = Charset.defaultCharset()` into `catch` section > src/jdk.jdeps/share/classes/com/sun/tools/javap/JavapTask.java line 419: > >> 417: return new PrintWriter(System.err, true, nativeCharset); >> 418: } else { >> 419: if (s.equals((OutputStream)System.err) || s.equals((OutputStream)System.out)) { > > Can we use `==` here? Used `==` > src/jdk.jpackage/share/classes/jdk/jpackage/main/Main.java line 50: > >> 48: * @param args command line arguments >> 49: */ >> 50: private final static Charset nativeCharset; > > Static initializer dissecting main method (javadoc/impl) Moved to another place ------------- PR: https://git.openjdk.java.net/jdk/pull/5771 From alanb at openjdk.java.net Wed Oct 6 06:19:06 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 6 Oct 2021 06:19:06 GMT Subject: RFR: 8274544: Langtools command's usage were garbled on Japanese Windows [v3] In-Reply-To: References: Message-ID: <7jj8-5dFFwzwOh5Un59vvBrL512C179k9Veai48U0GI=.3d58bf5c-dfee-46c7-bd44-5bfc76ed1805@github.com> On Wed, 6 Oct 2021 05:04:28 GMT, Ichiroh Takiguchi wrote: >> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13. >> After JDK18-b13, javac and some other langtool command's usage were garbled on Japanese Windows. >> These commands use PrintWriter instead of standard out/err with PrintStream. > > Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision: > > 8274544: Langtools command's usage were garbled on Japanese Windows The changes in 4427d87c look okay. I assume most of these tools will never run with a SM enabled and don't need to be granted permission to reading native.encoding. ------------- PR: https://git.openjdk.java.net/jdk/pull/5771 From github.com+741251+turbanoff at openjdk.java.net Wed Oct 6 07:23:20 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Wed, 6 Oct 2021 07:23:20 GMT Subject: RFR: 8274811: Remove superfluous use of boxing in java.base Message-ID: Usages of primitive types should be preferred and makes code easier to read. Similar cleanups: 1. [JDK-8273168](https://bugs.openjdk.java.net/browse/JDK-8273168) java.desktop 2. [JDK-8274234](https://bugs.openjdk.java.net/browse/JDK-8274234) java.sql.rowset ------------- Commit messages: - [PATCH] Remove superfluous use of boxing in java.base - [PATCH] Remove superfluous use of boxing in java.* modules - [PATCH] Remove superfluous use of boxing in java.* modules Changes: https://git.openjdk.java.net/jdk/pull/5481/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5481&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274811 Stats: 11 lines in 4 files changed: 0 ins; 0 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/5481.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5481/head:pull/5481 PR: https://git.openjdk.java.net/jdk/pull/5481 From github.com+10835776+stsypanov at openjdk.java.net Wed Oct 6 07:23:21 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Wed, 6 Oct 2021 07:23:21 GMT Subject: RFR: 8274811: Remove superfluous use of boxing in java.base In-Reply-To: References: Message-ID: On Sat, 11 Sep 2021 12:11:50 GMT, Andrey Turbanov wrote: > Usages of primitive types should be preferred and makes code easier to read. > Similar cleanups: > 1. [JDK-8273168](https://bugs.openjdk.java.net/browse/JDK-8273168) java.desktop > 2. [JDK-8274234](https://bugs.openjdk.java.net/browse/JDK-8274234) java.sql.rowset src/java.base/share/classes/java/util/ResourceBundle.java line 3732: > 3730: } > 3731: > 3732: private static final boolean TRACE_ON = Boolean.parseBoolean( I think for `Boolean` it doesn't make significant difference, as both `Boolean.TRUE` and `Boolean.FALSE` are cached and initialized immediately along with the class itself: public static Boolean valueOf(String s) { return parseBoolean(s) ? TRUE : FALSE; } ------------- PR: https://git.openjdk.java.net/jdk/pull/5481 From github.com+741251+turbanoff at openjdk.java.net Wed Oct 6 07:23:22 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Wed, 6 Oct 2021 07:23:22 GMT Subject: RFR: 8274811: Remove superfluous use of boxing in java.base In-Reply-To: References: Message-ID: On Sat, 11 Sep 2021 17:22:01 GMT, ?????? ??????? wrote: >> Usages of primitive types should be preferred and makes code easier to read. >> Similar cleanups: >> 1. [JDK-8273168](https://bugs.openjdk.java.net/browse/JDK-8273168) java.desktop >> 2. [JDK-8274234](https://bugs.openjdk.java.net/browse/JDK-8274234) java.sql.rowset > > src/java.base/share/classes/java/util/ResourceBundle.java line 3732: > >> 3730: } >> 3731: >> 3732: private static final boolean TRACE_ON = Boolean.parseBoolean( > > I think for `Boolean` it doesn't make significant difference, as both `Boolean.TRUE` and `Boolean.FALSE` are cached and initialized immediately along with the class itself: > > public static Boolean valueOf(String s) { > return parseBoolean(s) ? TRUE : FALSE; > } Yes, there is no allocation for booleans. But still 2 redundant method calls in interpreter mode (valueOf+booleanValue) ------------- PR: https://git.openjdk.java.net/jdk/pull/5481 From plevart at openjdk.java.net Wed Oct 6 08:36:07 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Wed, 6 Oct 2021 08:36:07 GMT Subject: RFR: JDK-8274686 : java.util.UUID#hashCode() should use Long.hashCode() In-Reply-To: References: Message-ID: On Mon, 4 Oct 2021 21:13:02 GMT, PROgrm_JARvis wrote: > This is trivial fix of [JDK-8274686](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8274686) which replaces manually-computed `int`-based `long` hash-code. > > Because `Long#hashCode(long)` uses other hashing function than the one currently used here: > > https://github.com/openjdk/jdk/blob/75d6688df9845ecb8f370b4cd2d5a36f13d3cdc0/src/java.base/share/classes/java/lang/Long.java#L1440-L1442 > > the value of `hashCode()` will produce different result, however this does not seem to be a breaking change as `UUID#hashCode()` is not specified. > > --- > > Note: the comment to the bug states: > >> Moved to JDK for further discussions of the proposed enhancement. > > But as there seemed to be no corresponding discussion in core-libs-dev and the change looks trivial, I considered that it is appropriate to open a PR which (if needed) may be used for discussion (especially, considering the fact that its comments get mirrored to the ML). You do know that this might break things? If there are multiple versions of JDK present in some distributed system where participants do not agree on the hash code of an UUID value, it can behave erratically. For example using UUID as a key in a distributed cache like Infinispan is known to be troublesome if the hashCode of some key is not the same across the cluster. Usually there will not be a problem since all nodes in a cluster would use the same JDK version, but what about a rolling upgrade then? It would not be possible. I think at least this change needs to be documented in release notes. ------------- PR: https://git.openjdk.java.net/jdk/pull/5811 From alanb at openjdk.java.net Wed Oct 6 08:58:06 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 6 Oct 2021 08:58:06 GMT Subject: RFR: JDK-8274686 : java.util.UUID#hashCode() should use Long.hashCode() In-Reply-To: References: Message-ID: <6MJpRhyKgyt3h4z119LHeVb38c6whKEk_KU0Uzr3q_E=.026eef4c-2bb2-4a33-8acd-86b332fc6d14@github.com> On Wed, 6 Oct 2021 08:33:21 GMT, Peter Levart wrote: >> This is trivial fix of [JDK-8274686](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8274686) which replaces manually-computed `int`-based `long` hash-code. >> >> Because `Long#hashCode(long)` uses other hashing function than the one currently used here: >> >> https://github.com/openjdk/jdk/blob/75d6688df9845ecb8f370b4cd2d5a36f13d3cdc0/src/java.base/share/classes/java/lang/Long.java#L1440-L1442 >> >> the value of `hashCode()` will produce different result, however this does not seem to be a breaking change as `UUID#hashCode()` is not specified. >> >> --- >> >> Note: the comment to the bug states: >> >>> Moved to JDK for further discussions of the proposed enhancement. >> >> But as there seemed to be no corresponding discussion in core-libs-dev and the change looks trivial, I considered that it is appropriate to open a PR which (if needed) may be used for discussion (especially, considering the fact that its comments get mirrored to the ML). > > You do know that this might break things? If there are multiple versions of JDK present in some distributed system where participants do not agree on the hash code of an UUID value, it can behave erratically. For example using UUID as a key in a distributed cache like Infinispan is known to be troublesome if the hashCode of some key is not the same across the cluster. Usually there will not be a problem since all nodes in a cluster would use the same JDK version, but what about a rolling upgrade then? It would not be possible. I think at least this change needs to be documented in release notes. @plevart may have a point and since this patch doesn't really have any benefits then maybe this PR/issue can be closed. ------------- PR: https://git.openjdk.java.net/jdk/pull/5811 From plevart at openjdk.java.net Wed Oct 6 09:10:06 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Wed, 6 Oct 2021 09:10:06 GMT Subject: RFR: JDK-8274686 : java.util.UUID#hashCode() should use Long.hashCode() In-Reply-To: References: Message-ID: On Mon, 4 Oct 2021 21:13:02 GMT, PROgrm_JARvis wrote: > This is trivial fix of [JDK-8274686](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8274686) which replaces manually-computed `int`-based `long` hash-code. > > Because `Long#hashCode(long)` uses other hashing function than the one currently used here: > > https://github.com/openjdk/jdk/blob/75d6688df9845ecb8f370b4cd2d5a36f13d3cdc0/src/java.base/share/classes/java/lang/Long.java#L1440-L1442 > > the value of `hashCode()` will produce different result, however this does not seem to be a breaking change as `UUID#hashCode()` is not specified. > > --- > > Note: the comment to the bug states: > >> Moved to JDK for further discussions of the proposed enhancement. > > But as there seemed to be no corresponding discussion in core-libs-dev and the change looks trivial, I considered that it is appropriate to open a PR which (if needed) may be used for discussion (especially, considering the fact that its comments get mirrored to the ML). Sorry, I was mislead by the comment above that because the original hashCode function is different, the hashCode will be different too. But I think this is not the case here. Original function is this: long hilo = mostSigBits ^ leastSigBits; return ((int)(hilo >> 32)) ^ (int) hilo; new function (with inlined Long.hashCode(long)) looks like this: long hilo = mostSigBits ^ leastSigBits; return (int)(hilo ^ hilo >>> 32); The difference is two-fold: 1. original function uses arithmetic shift right (division by 2^32 preserving the sign) while new function uses logical shift right (shifting in zeros from the left to the right) 2. original function casts individual arguments to int before doing XOR between them while new function XORs long arguments and applies cast to int at the end. But those two differences do not affect the lower 32 bits of any of the intermediate results and therefore the end result is the same (unless I missed something). So I think no release notes is needed for this change. I think that https://github.com/openjdk/jdk/pull/4309 also dealt with similar change which was then reverted as a consequence (I'll have to check to be sure). ------------- PR: https://git.openjdk.java.net/jdk/pull/5811 From plevart at openjdk.java.net Wed Oct 6 09:29:09 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Wed, 6 Oct 2021 09:29:09 GMT Subject: RFR: JDK-8274686 : java.util.UUID#hashCode() should use Long.hashCode() In-Reply-To: References: Message-ID: On Mon, 4 Oct 2021 21:13:02 GMT, PROgrm_JARvis wrote: > This is trivial fix of [JDK-8274686](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8274686) which replaces manually-computed `int`-based `long` hash-code. > > Because `Long#hashCode(long)` uses other hashing function than the one currently used here: > > https://github.com/openjdk/jdk/blob/75d6688df9845ecb8f370b4cd2d5a36f13d3cdc0/src/java.base/share/classes/java/lang/Long.java#L1440-L1442 > > the value of `hashCode()` will produce different result, however this does not seem to be a breaking change as `UUID#hashCode()` is not specified. > > --- > > Note: the comment to the bug states: > >> Moved to JDK for further discussions of the proposed enhancement. > > But as there seemed to be no corresponding discussion in core-libs-dev and the change looks trivial, I considered that it is appropriate to open a PR which (if needed) may be used for discussion (especially, considering the fact that its comments get mirrored to the ML). Yes, the reverted change to BitSet.hashCode in https://github.com/openjdk/jdk/pull/4309 has the same property. It could be applied without any visible effect. ------------- PR: https://git.openjdk.java.net/jdk/pull/5811 From myano at openjdk.java.net Wed Oct 6 10:13:07 2021 From: myano at openjdk.java.net (Masanori Yano) Date: Wed, 6 Oct 2021 10:13:07 GMT Subject: RFR: 8250678: ModuleDescriptor.Version parsing treats empty segments inconsistently In-Reply-To: <-RdwCCyA_gS04j8OgqlqsTAnTzGoQduJXjciYuwvh0w=.eb4ae2a2-63c0-4b5e-aca5-513cc3862790@github.com> References: <5FwhmsS85upnfXAKPCBCQTsWorJN17vOBFZXCN6iP8M=.377740a1-6f1e-4e37-9344-25a60ffdd891@github.com> <-RdwCCyA_gS04j8OgqlqsTAnTzGoQduJXjciYuwvh0w=.eb4ae2a2-63c0-4b5e-aca5-513cc3862790@github.com> Message-ID: <6lfw2-xAIaGBRh0UrT4sZqdZ2are-8UnwZgA01sygqc=.4ff4ca48-e27e-4d60-a62d-452cc1aebbb6@github.com> On Mon, 27 Sep 2021 08:22:02 GMT, Alan Bateman wrote: >> Could you please review the 8250678 bug fixes? >> >> The `parse` method of ModuleDescriptor.Version class behaves incorrectly when the input string contains consecutive delimiters. >> >> The `parse` method treats strings as three sections, but the parsing method differs between the method for the version sections and the ones for others. In version sections, the `parse` method takes a single character in a loop and determines whether it is a delimiter. In pre and build sections, the parse method takes two characters in a loop and determines whether the second character is the delimiter. Therefore, if the string contains a sequence of delimiters in pre or build section, the `parse` method treats character at the odd-numbered position as a token and the one at even-numbered as a delimiter. >> >> A string containing consecutive delimiters is an incorrect version string, but this behavior does not follow the API specification. >> https://download.java.net/java/early_access/jdk18/docs/api/java.base/java/lang/module/ModuleDescriptor.Version.html >> >> Therefore, I propose to fix the parsing method of pre and build section in the same way as the version. > > I think this is okay, just maybe unusual to have repeated punctuation creating the case where a component is empty. @mbreinhold may wish to comment on this PR. @AlanBateman I can't seem to get a comment on this PR from @mbreinhold , so could you please review it? ------------- PR: https://git.openjdk.java.net/jdk/pull/5679 From github.com+70726043+rgiulietti at openjdk.java.net Wed Oct 6 10:38:12 2021 From: github.com+70726043+rgiulietti at openjdk.java.net (Raffaello Giulietti) Date: Wed, 6 Oct 2021 10:38:12 GMT Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v2] In-Reply-To: References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com> Message-ID: On Fri, 16 Apr 2021 11:30:32 GMT, Raffaello Giulietti wrote: >> Hello, >> >> here's a PR for a patch submitted on March 2020 [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a thing. >> >> The patch has been edited to adhere to OpenJDK code conventions about multi-line (block) comments. Nothing in the code proper has changed, except for the addition of redundant but clarifying parentheses in some expressions. >> >> >> Greetings >> Raffaello > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > 4511638: Double.toString(double) sometimes produces incorrect results (ungarbled comment from Guy Steele) Hi, thanks for writing to me! I am glad to ?meet? you. Schubfach looks like an excellent idea; I have simply been trying to assess just how confident we can be about the correctness of the final code. The explanations you have just provided to me about the proof process and testing are very reassuring. I will keep those in mind as I finish re-reading your paper, and will have more to say on Friday. And if you happen to have a list of a few examples where the current Java implementation of FP print fails but Schubfach succeeds, I would be very interested to study them. Thanks! ?Guy ---- (my answer) Hi, it's my pleasure to virtually meet the mythical Guy Steele! For some reason, your comments end up garbled on this PR GitHub page and don't appear at all on the core-libs-dev mailing list. You may perhaps try to post them in plain ASCII? You can find some of the anomalies in the bug report from exactly 20 years ago! [1] A tiny collection of the anomalies are coded in the tests [2], [3]. Here's the relevant excerpt for doubles: /* * There are tons of doubles that are rendered incorrectly by older JDK. * While the renderings correctly round back to the original value, * they are longer than needed or are not the closest decimal to the double. * Here are just a very few examples. */ private static final String[] Anomalies = { /* JDK renders these, and others, with 18 digits! */ "2.82879384806159E17", "1.387364135037754E18", "1.45800632428665E17", /* JDK renders these longer than needed */ "1.6E-322", "6.3E-322", "7.3879E20", "2.0E23", "7.0E22", "9.2E22", "9.5E21", "3.1E22", "5.63E21", "8.41E21", /* JDK does not render these, and many others, as the closest */ "9.9E-324", "9.9E-323", "1.9400994884341945E25", "3.6131332396758635E25", "2.5138990223946153E25", }; To be clear and as emphasized in the comment, the outputs of the current JDK implementation are all information preserving. I could never find a real error in this regard. However, typing 2e23 and getting back 1.9999999999999998E23 as a response is surprising and unnecessary if one knows David Matula's results from the late '60-ies. Also, many powers of 2 are output with way too many digits on current JDK. Schubfach's outputs pass the stringent tests. Greetings Raffaello ---- [1] https://bugs.openjdk.java.net/browse/JDK-4511638 [2] https://github.com/openjdk/jdk/pull/3402/files#diff-ee9b0bcfb171cb200f6aa1e3de972b61ca363f95bb8079255af912ae30026937 [3] https://github.com/openjdk/jdk/pull/3402/files#diff-c4a866bc9e7d1beb5342823f9f6cff1fe4f69c96b61620b96cc26d739f9c999f ------------- PR: https://git.openjdk.java.net/jdk/pull/3402 From myano at openjdk.java.net Wed Oct 6 11:27:14 2021 From: myano at openjdk.java.net (Masanori Yano) Date: Wed, 6 Oct 2021 11:27:14 GMT Subject: RFR: 8233674: JarURLConnection.getJarFile throws Exception if some process is holding the file In-Reply-To: References: Message-ID: On Fri, 10 Sep 2021 09:23:52 GMT, Masanori Yano wrote: > Could you please review the 8233674 bug fixes? > This problem is caused by the antivirus software opening the file for a short time, so CreateFile() should be retried. I inquired of the Microsoft Technical Support about this problem. They said that using a simple retry mechanism is the effective workaround for this problem as in the article. But, they are not sure which is wrong the application or the virus checker because it depends on the situation. Which method do you think is better, to fix the JDK or to change the configuration of the virus checker? ------------- PR: https://git.openjdk.java.net/jdk/pull/5460 From github.com+741251+turbanoff at openjdk.java.net Wed Oct 6 12:29:23 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Wed, 6 Oct 2021 12:29:23 GMT Subject: RFR: 8274835: Remove unnecessary castings in java.base Message-ID: Redundant castings make code harder to read. Found them by IntelliJ IDEA. I tried to select only casts which are definitely safe to remove. Also didn't touch primitive types casts. ------------- Commit messages: - [PATCH] Remove unnecessary castings in java.base - [PATCH] Remove unnecessary castings in java.base Changes: https://git.openjdk.java.net/jdk/pull/5454/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5454&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274835 Stats: 38 lines in 15 files changed: 1 ins; 4 del; 33 mod Patch: https://git.openjdk.java.net/jdk/pull/5454.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5454/head:pull/5454 PR: https://git.openjdk.java.net/jdk/pull/5454 From john_platts at hotmail.com Wed Oct 6 12:31:59 2021 From: john_platts at hotmail.com (John Platts) Date: Wed, 6 Oct 2021 12:31:59 +0000 Subject: Implementing JEP 400 on Windows 10 and Windows 11 In-Reply-To: References: <0a06028a-f5c1-a710-a097-8c88e32cd58d@oracle.com> Message-ID: When I ran the test programs to determine the behavior changes that occur with the UTF-8 setting in the manifest, I actually copied the executables of the compiled test programs and modified the manifest resource of the copied executables to include the UTF-8 setting. I agree that UTF-8 handling for argv would be a great plus as the JNI_CreateJavaVM function currently expects the arguments to be encoded in the character set returned by the GetACP() function. Adding the UTF-8 setting to the java.manifest file would allow Unicode characters that aren't in the system default codepage to be passed as command line arguments to Java programs on Windows 10 (starting with version 1903) and Windows 11. The JVM still needs to support the case where GetACP() returns a charset other than 65001 (UTF-8) as (a) the JVM can still be loaded by executables that don't have the UTF-8 setting present in their manifest by loading jvm.dll through LoadLibrary and calling the JNI_CreateJavaVM function of jvm.dll and (b) the JVM can still be loaded on earlier versions on Windows that don't support the UTF-8 setting. ________________________________ From: core-libs-dev on behalf of Bernd Eckenfels Sent: Tuesday, October 5, 2021 5:02 AM To: core-libs-dev Subject: Re: Implementing JEP 400 on Windows 10 and Windows 11 I think the last sentence was missing a ?not? and referring to the same manifest? However the results are a bit of a mess, but utf-8 handling for argv would be great plus (if converted correctly), right? -- http://bernd.eckenfels.net ________________________________ Von: core-libs-dev im Auftrag von Magnus Ihse Bursie Gesendet: Tuesday, October 5, 2021 10:34:26 AM An: John Platts ; core-libs-dev Betreff: Re: Implementing JEP 400 on Windows 10 and Windows 11 On 2021-10-05 03:22, John Platts wrote: > I wrote a test program (in C++) to detect the codepages that would be returned by the GetACP(), GetOEMCP(), and GetConsoleCP() functions when the UTF-8 setting is added to the manifest. > > The manifest element (supported on Windows 10 Version 1903 or later) is in the http://schemas.microsoft.com/SMI/2019/WindowsSettings namespace and is added to the asmv3:WindowsSettings element as shown below: > xmlns:dpi2="http://schemas.microsoft.com/SMI/2016/WindowsSettings" > xmlns:utf8="http://schemas.microsoft.com/SMI/2019/WindowsSettings"> > true/PM > PerMonitorV2, PerMonitor, system > UTF-8 > > > Here is the output of the test program without the UTF-8 setting present in the executable manifest: > GetACP() result: 1252 > GetOEMCP() result: 437 > GetConsoleCP() result: 437 > System default LCID: 1033 > User default LCID: 1033 > User default UI LCID: 1033 > Codepage from system default LCID: 1252 > Codepage from user default LCID: 1252 > Codepage from user default UI LCID: 1252 > > Here is the output of the same test program with an executable manifest that includes the UTF-8 setting: > GetACP() result: 65001 > GetOEMCP() result: 65001 > GetConsoleCP() result: 437 > System default LCID: 1033 > User default LCID: 1033 > User default UI LCID: 1033 > Codepage from system default LCID: 1252 > Codepage from user default LCID: 1252 > Codepage from user default UI LCID: 1252 > > Note that the UTF-8 setting in the application manifest changes the results of the GetACP() and GetOEMCP() calls but not the GetConsoleCP() call. This is really confusing. I'm glad you are gathering empirical evidence of how it works. :-) > I wrote another test program, and the argument strings passed into the main(int argc, char** argv) function are converted to UTF-8 if the UTF-8 setting is there in the application manifest whereas the argument strings passed into the main (int argc, char** argv) function are converted to the ANSI codepage (which is usually code page 1252 on US English systems) if the UTF-8 setting is there in the UTF-8 manifest. I'm not sure I understand this. What is the difference between "the application manifest" and "the UTF-8 manifest"? /Magnus From john_platts at hotmail.com Wed Oct 6 12:33:26 2021 From: john_platts at hotmail.com (John Platts) Date: Wed, 6 Oct 2021 12:33:26 +0000 Subject: Implementing JEP 400 on Windows 10 and Windows 11 In-Reply-To: <0a06028a-f5c1-a710-a097-8c88e32cd58d@oracle.com> References: <0a06028a-f5c1-a710-a097-8c88e32cd58d@oracle.com> Message-ID: I was actually referring to the src/java.base/windows/native/launcher/java.manifest file (or the jdk/src/windows/resource/java.manifest file on JDK 8) that gets embedded as a manifest in the JDK executables. When I was mentioning "UTF-8 manifest", I was referring to the java.manifest file (embedded as a resource in JDK executables) that had the UTF-8 setting added. Here is what the java.manifest file would look like with the UTF-8 setting enabled: Java(TM) SE process true/PM PerMonitorV2, PerMonitor, system UTF-8 ________________________________ From: Magnus Ihse Bursie Sent: Tuesday, October 5, 2021 3:34 AM To: John Platts ; core-libs-dev Subject: Re: Implementing JEP 400 on Windows 10 and Windows 11 On 2021-10-05 03:22, John Platts wrote: > I wrote a test program (in C++) to detect the codepages that would be returned by the GetACP(), GetOEMCP(), and GetConsoleCP() functions when the UTF-8 setting is added to the manifest. > > The manifest element (supported on Windows 10 Version 1903 or later) is in the http://schemas.microsoft.com/SMI/2019/WindowsSettings namespace and is added to the asmv3:WindowsSettings element as shown below: > xmlns:dpi2="http://schemas.microsoft.com/SMI/2016/WindowsSettings" > xmlns:utf8="http://schemas.microsoft.com/SMI/2019/WindowsSettings"> > true/PM > PerMonitorV2, PerMonitor, system > UTF-8 > > > Here is the output of the test program without the UTF-8 setting present in the executable manifest: > GetACP() result: 1252 > GetOEMCP() result: 437 > GetConsoleCP() result: 437 > System default LCID: 1033 > User default LCID: 1033 > User default UI LCID: 1033 > Codepage from system default LCID: 1252 > Codepage from user default LCID: 1252 > Codepage from user default UI LCID: 1252 > > Here is the output of the same test program with an executable manifest that includes the UTF-8 setting: > GetACP() result: 65001 > GetOEMCP() result: 65001 > GetConsoleCP() result: 437 > System default LCID: 1033 > User default LCID: 1033 > User default UI LCID: 1033 > Codepage from system default LCID: 1252 > Codepage from user default LCID: 1252 > Codepage from user default UI LCID: 1252 > > Note that the UTF-8 setting in the application manifest changes the results of the GetACP() and GetOEMCP() calls but not the GetConsoleCP() call. This is really confusing. I'm glad you are gathering empirical evidence of how it works. :-) > I wrote another test program, and the argument strings passed into the main(int argc, char** argv) function are converted to UTF-8 if the UTF-8 setting is there in the application manifest whereas the argument strings passed into the main (int argc, char** argv) function are converted to the ANSI codepage (which is usually code page 1252 on US English systems) if the UTF-8 setting is there in the UTF-8 manifest. I'm not sure I understand this. What is the difference between "the application manifest" and "the UTF-8 manifest"? /Magnus From mullan at openjdk.java.net Wed Oct 6 13:05:07 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Wed, 6 Oct 2021 13:05:07 GMT Subject: RFR: 8274835: Remove unnecessary castings in java.base In-Reply-To: References: Message-ID: <2g6lp6Qoc6CkGSZxYcxU6J9lyufzUB_nM-JtXOt7Yng=.66528e37-4512-47d6-9818-7acc6a99a42d@github.com> On Thu, 9 Sep 2021 20:12:47 GMT, Andrey Turbanov wrote: > Redundant castings make code harder to read. > Found them by IntelliJ IDEA. > I tried to select only casts which are definitely safe to remove. Also didn't touch primitive types casts. The security related files look fine. ------------- Marked as reviewed by mullan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5454 From cstein at openjdk.java.net Wed Oct 6 15:15:16 2021 From: cstein at openjdk.java.net (Christian Stein) Date: Wed, 6 Oct 2021 15:15:16 GMT Subject: Integrated: JDK-8262944: Improve exception message when automatic module lists provider class not in JAR file In-Reply-To: References: Message-ID: <-CEV0Qx8_jHJ7mqENEv9orSRRJLJ2F_HbO2KqpRS9xw=.de680f68-13c3-403f-8ce7-175dde5135c3@github.com> On Thu, 16 Sep 2021 09:06:20 GMT, Christian Stein wrote: > This commit appends the name of the JAR file to the exception message for when automatic module lists a non-existing provider class. This pull request has now been integrated. Changeset: c10de353 Author: Christian Stein Committer: Alan Bateman URL: https://git.openjdk.java.net/jdk/commit/c10de3538b47c182d7bfeb02f348fac9b2ad0641 Stats: 26 lines in 2 files changed: 19 ins; 0 del; 7 mod 8262944: Improve exception message when automatic module lists provider class not in JAR file Reviewed-by: dfuchs, jvernee, alanb, lancea, mchung ------------- PR: https://git.openjdk.java.net/jdk/pull/5543 From itakiguchi at openjdk.java.net Wed Oct 6 15:58:07 2021 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Wed, 6 Oct 2021 15:58:07 GMT Subject: RFR: 8274544: Langtools command's usage were garbled on Japanese Windows [v2] In-Reply-To: References: Message-ID: On Wed, 6 Oct 2021 00:02:55 GMT, Naoto Sato wrote: >> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision: >> >> 8274544: Langtools command's usage were garbled on Japanese Windows > > I just grepped `System.out/err` in jshell source directory, and found another location in `tool/JShellToolProvider.java` that uses bare stdout/err. Would you also apply the fix and see the result? Hello @naotoj . Sorry I'm late. > I just grepped `System.out/err` in jshell source directory, and found another location in `tool/JShellToolProvider.java` that uses bare stdout/err. Would you also apply the fix and see the result? I applied following changes and lahodaj's code (I'm not sure, it's expected one...) : in; PrintStream xout = (out == null) - ? System.out + ? new PrintStream(System.out, true, nativeCharset) : (out instanceof PrintStream) ? (PrintStream) out - : new PrintStream(out); + : new PrintStream(out, true, nativeCharset); PrintStream xerr = (err == null) - ? System.err + ? new PrintStream(System.err, true, nativeCharset) : (err instanceof PrintStream) ? (PrintStream) err - : new PrintStream(err); + : new PrintStream(err, true, nativeCharset); try { return JavaShellToolBuilder .builder() But it did not work for previously saved encoded command list. (lahodaj's code worked fine for standard case.) I think you may be confused because of my bad explanation. User can create Jshell's command list by `/save`. Native encoding was used before JDK18. Now UTF-8 is used by JDK18. To read saved command list (`/open`) which was encoded by native encoding, Charset.defaultCharset() should be same as native.encoding... I think we need to provide workaround for it. ------------- PR: https://git.openjdk.java.net/jdk/pull/5771 From naoto at openjdk.java.net Wed Oct 6 16:28:06 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 6 Oct 2021 16:28:06 GMT Subject: RFR: 8274835: Remove unnecessary castings in java.base In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 20:12:47 GMT, Andrey Turbanov wrote: > Redundant castings make code harder to read. > Found them by IntelliJ IDEA. > I tried to select only casts which are definitely safe to remove. Also didn't touch primitive types casts. Calendar-related changes look good to me. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5454 From lancea at openjdk.java.net Wed Oct 6 16:33:09 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 6 Oct 2021 16:33:09 GMT Subject: RFR: 8274835: Remove unnecessary castings in java.base In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 20:12:47 GMT, Andrey Turbanov wrote: > Redundant castings make code harder to read. > Found them by IntelliJ IDEA. > I tried to select only casts which are definitely safe to remove. Also didn't touch primitive types casts. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5454 From coffeys at openjdk.java.net Wed Oct 6 17:07:25 2021 From: coffeys at openjdk.java.net (Sean Coffey) Date: Wed, 6 Oct 2021 17:07:25 GMT Subject: RFR: 8273826: Correct Manifest file name and NPE checks Message-ID: Use correct manifest file name in the Manifest verifier checks. Also - extra null check The test doesn't reproduce the exact issue reported but should prevent future regressions in this area. ------------- Commit messages: - 8273826: Correct Manifest file name and NPE checks Changes: https://git.openjdk.java.net/jdk/pull/5841/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5841&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273826 Stats: 137 lines in 5 files changed: 127 ins; 2 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/5841.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5841/head:pull/5841 PR: https://git.openjdk.java.net/jdk/pull/5841 From darcy at openjdk.java.net Wed Oct 6 17:15:08 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 6 Oct 2021 17:15:08 GMT Subject: RFR: 8274835: Remove unnecessary castings in java.base In-Reply-To: References: Message-ID: <5cblPwQq4ebGNXXrtO9EoHnSZ_tcsn-EVxfMQMVEjOI=.9936fe80-1b9a-468c-8d3e-80eaad0977be@github.com> On Thu, 9 Sep 2021 20:12:47 GMT, Andrey Turbanov wrote: > Redundant castings make code harder to read. > Found them by IntelliJ IDEA. > I tried to select only casts which are definitely safe to remove. Also didn't touch primitive types casts. Curious. The JDK build is done with javac -Xlint:cast warning enabled (JDK-8032734) which is intended to catch issues like this. Perhaps IntelliJ is using a different (or sharper) analysis. ------------- PR: https://git.openjdk.java.net/jdk/pull/5454 From rriggs at openjdk.java.net Wed Oct 6 17:26:09 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 6 Oct 2021 17:26:09 GMT Subject: RFR: 8274407: (tz) Update Timezone Data to 2021c In-Reply-To: References: Message-ID: On Wed, 6 Oct 2021 01:24:49 GMT, Naoto Sato wrote: > This PR is to upgrade the time zone data in the JDK to IANA's tzdata2021c level. Note that the tz data is "as is", as released by IANA. No `merged links` are retracted. > The PR also fixes two issues along with the 2021c upgrade. Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5832 From naoto at openjdk.java.net Wed Oct 6 18:11:10 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 6 Oct 2021 18:11:10 GMT Subject: RFR: 8274544: Langtools command's usage were garbled on Japanese Windows [v3] In-Reply-To: References: Message-ID: On Wed, 6 Oct 2021 05:04:28 GMT, Ichiroh Takiguchi wrote: >> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13. >> After JDK18-b13, javac and some other langtool command's usage were garbled on Japanese Windows. >> These commands use PrintWriter instead of standard out/err with PrintStream. > > Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision: > > 8274544: Langtools command's usage were garbled on Japanese Windows I got your issue now. Since the current code issues `FileReader()` without specifying the explicit charset, this is the prime example that is affected by the JEP. The question is, in which encoding the jshell save file should be? I think it belongs to the spec of jshell, and it should be specified somewhere in the document. BTW, the suggestion I made in `JShellToolProvider` still holds regardless of the save file issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/5771 From iris at openjdk.java.net Wed Oct 6 18:11:12 2021 From: iris at openjdk.java.net (Iris Clark) Date: Wed, 6 Oct 2021 18:11:12 GMT Subject: RFR: 8274407: (tz) Update Timezone Data to 2021c In-Reply-To: References: Message-ID: On Wed, 6 Oct 2021 01:24:49 GMT, Naoto Sato wrote: > This PR is to upgrade the time zone data in the JDK to IANA's tzdata2021c level. Note that the tz data is "as is", as released by IANA. No `merged links` are retracted. > The PR also fixes two issues along with the 2021c upgrade. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5832 From github.com+741251+turbanoff at openjdk.java.net Wed Oct 6 18:15:15 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Wed, 6 Oct 2021 18:15:15 GMT Subject: Integrated: 8274464: Remove redundant stream() call before forEach in java.* modules In-Reply-To: References: Message-ID: On Wed, 15 Sep 2021 07:12:25 GMT, Andrey Turbanov wrote: > 8274464: Remove redundant stream() call before forEach in java.* modules This pull request has now been integrated. Changeset: f3cedbe9 Author: Andrey Turbanov Committer: Daniel Fuchs URL: https://git.openjdk.java.net/jdk/commit/f3cedbe9288e7aea8d5603a2dc9bdc2661c391a6 Stats: 8 lines in 4 files changed: 0 ins; 3 del; 5 mod 8274464: Remove redundant stream() call before forEach in java.* modules Reviewed-by: dfuchs, amenkov, vtewari ------------- PR: https://git.openjdk.java.net/jdk/pull/5520 From dfuchs at openjdk.java.net Wed Oct 6 18:21:14 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 6 Oct 2021 18:21:14 GMT Subject: RFR: 8273711: Remove redundant stream() call before forEach in jdk.jlink [v2] In-Reply-To: References: <3ABdvBiCu8znAgbmq2XW3wsWVEPqwIGbPJnmEdW-1jc=.2148d9d8-f14f-49ad-a58f-6f843bba27d3@github.com> Message-ID: On Wed, 15 Sep 2021 07:08:09 GMT, Andrey Turbanov wrote: >> 8273711: Remove redundant stream() call before forEach in jdk.jlink > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8273711: Remove redundant stream() call before forEach in jdk.jlink > use method references where applicable Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5500 From github.com+741251+turbanoff at openjdk.java.net Wed Oct 6 18:21:15 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Wed, 6 Oct 2021 18:21:15 GMT Subject: Integrated: 8273711: Remove redundant stream() call before forEach in jdk.jlink In-Reply-To: <3ABdvBiCu8znAgbmq2XW3wsWVEPqwIGbPJnmEdW-1jc=.2148d9d8-f14f-49ad-a58f-6f843bba27d3@github.com> References: <3ABdvBiCu8znAgbmq2XW3wsWVEPqwIGbPJnmEdW-1jc=.2148d9d8-f14f-49ad-a58f-6f843bba27d3@github.com> Message-ID: On Mon, 13 Sep 2021 20:06:08 GMT, Andrey Turbanov wrote: > 8273711: Remove redundant stream() call before forEach in jdk.jlink This pull request has now been integrated. Changeset: 4e7d7caa Author: Andrey Turbanov Committer: Daniel Fuchs URL: https://git.openjdk.java.net/jdk/commit/4e7d7caa0ce1a3c9fc45ca6a85b1a7ec209775b2 Stats: 21 lines in 9 files changed: 0 ins; 3 del; 18 mod 8273711: Remove redundant stream() call before forEach in jdk.jlink Reviewed-by: alanb, psandoz, dfuchs ------------- PR: https://git.openjdk.java.net/jdk/pull/5500 From github.com+741251+turbanoff at openjdk.java.net Wed Oct 6 18:23:12 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Wed, 6 Oct 2021 18:23:12 GMT Subject: Integrated: 8274525: Replace uses of StringBuffer with StringBuilder in java.xml In-Reply-To: References: Message-ID: On Wed, 29 Sep 2021 17:56:49 GMT, Andrey Turbanov wrote: > StringBuffer is a legacy synchronized class. There are more modern alternatives which perform better: > 1. Plain String concatenation should be preferred > 2. StringBuilder is a direct replacement to StringBuffer which generally have better performance > > Similar cleanups: > 1. [JDK-8264029](https://bugs.openjdk.java.net/browse/JDK-8264029) java.base > 2. [JDK-8264428](https://bugs.openjdk.java.net/browse/JDK-8264428) java.desktop > 3. [JDK-8264484](https://bugs.openjdk.java.net/browse/JDK-8264484) jdk.hotspot.agent This pull request has now been integrated. Changeset: 754bc82c Author: Andrey Turbanov Committer: Daniel Fuchs URL: https://git.openjdk.java.net/jdk/commit/754bc82c4c03e1bedb4b36b5c52873b0a78a6ceb Stats: 32 lines in 5 files changed: 0 ins; 11 del; 21 mod 8274525: Replace uses of StringBuffer with StringBuilder in java.xml Reviewed-by: joehw, iris, naoto, dfuchs ------------- PR: https://git.openjdk.java.net/jdk/pull/5759 From mr at openjdk.java.net Wed Oct 6 18:43:06 2021 From: mr at openjdk.java.net (Mark Reinhold) Date: Wed, 6 Oct 2021 18:43:06 GMT Subject: RFR: 8250678: ModuleDescriptor.Version parsing treats empty segments inconsistently In-Reply-To: References: <5FwhmsS85upnfXAKPCBCQTsWorJN17vOBFZXCN6iP8M=.377740a1-6f1e-4e37-9344-25a60ffdd891@github.com> Message-ID: On Thu, 30 Sep 2021 11:26:12 GMT, Masanori Yano wrote: > @mbreinhold Could you comment on this pull request? This is somewhat tricky code. I?ll take a look, but give me a few days. ------------- PR: https://git.openjdk.java.net/jdk/pull/5679 From herrick at openjdk.java.net Wed Oct 6 18:53:39 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Wed, 6 Oct 2021 18:53:39 GMT Subject: RFR: 8274346: Support for additional content in an app-image. [v2] In-Reply-To: References: Message-ID: > 8274346: Support for additional content in an app-image. Andy Herrick has updated the pull request incrementally with one additional commit since the last revision: JDK-8274346: Support for additional content in an app-image. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5780/files - new: https://git.openjdk.java.net/jdk/pull/5780/files/d53b8647..bf2dd5e8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5780&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5780&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5780.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5780/head:pull/5780 PR: https://git.openjdk.java.net/jdk/pull/5780 From turbanoff at gmail.com Wed Oct 6 19:07:43 2021 From: turbanoff at gmail.com (Andrey Turbanov) Date: Wed, 6 Oct 2021 22:07:43 +0300 Subject: Strange colon in CollationElementIterator javadoc Message-ID: Hello. While reading the javadoc of CollationElementIterator I found a strange colon in the example. https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/text/CollationElementIterator.java#L87 String testString = "This is a test"; Collator col = Collator.getInstance(); if (col instanceof RuleBasedCollator) { RuleBasedCollator ruleBasedCollator = (RuleBasedCollator)col; CollationElementIterator collationElementIterator = ruleBasedCollator.getCollationElementIterator(testString); int primaryOrder = CollationElementIterator.primaryOrder(collationElementIterator.next()); : } Does it mean something? It was added under https://bugs.openjdk.java.net/browse/JDK-6486695 Andrey Turbanov From asemenyuk at openjdk.java.net Wed Oct 6 19:09:08 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Wed, 6 Oct 2021 19:09:08 GMT Subject: RFR: 8274346: Support for additional content in an app-image. [v2] In-Reply-To: References: Message-ID: <3Hy9MHkNbM1GEZHb80DCFFER07MFIcqm-cL-FNv2A5I=.22a31177-25dd-477c-b388-abaa1595f408@github.com> On Wed, 6 Oct 2021 18:53:39 GMT, Andy Herrick wrote: >> 8274346: Support for additional content in an app-image. > > Andy Herrick has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8274346: Support for additional content in an app-image. Marked as reviewed by asemenyuk (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5780 From mchung at openjdk.java.net Wed Oct 6 19:14:26 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 6 Oct 2021 19:14:26 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v10] In-Reply-To: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> Message-ID: > This reimplements core reflection with method handles. > > For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. > > The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. > > The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. > > Ran tier1-tier8 tests. > > [1] https://bugs.openjdk.java.net/browse/JDK-8013527 > [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 Mandy Chung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 30 commits: - Add java.lang.reflect and jdk.internal.reflect to trusted non-static final fields packages - Merge - ensure class initialized before field acces - Make MethodAccessor non-volatile. Remove MHInvoker/VHInvoker. - Merge - minor cleanup and more test case. - Rename InvokerBuilder to ReflectionInvokerBuilder - Fix NativeAccessor.c build issue for the renamed classes - Shorten the class name - Rename the accessor classes to make it explicit for method handles - ... and 20 more: https://git.openjdk.java.net/jdk/compare/83b22192...9c28df4c ------------- Changes: https://git.openjdk.java.net/jdk/pull/5027/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5027&range=09 Stats: 6411 lines in 78 files changed: 5896 ins; 317 del; 198 mod Patch: https://git.openjdk.java.net/jdk/pull/5027.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5027/head:pull/5027 PR: https://git.openjdk.java.net/jdk/pull/5027 From coffeys at openjdk.java.net Wed Oct 6 19:47:05 2021 From: coffeys at openjdk.java.net (Sean Coffey) Date: Wed, 6 Oct 2021 19:47:05 GMT Subject: RFR: 8274407: (tz) Update Timezone Data to 2021c In-Reply-To: References: Message-ID: On Wed, 6 Oct 2021 01:24:49 GMT, Naoto Sato wrote: > This PR is to upgrade the time zone data in the JDK to IANA's tzdata2021c level. Note that the tz data is "as is", as released by IANA. No `merged links` are retracted. > The PR also fixes two issues along with the 2021c upgrade. Marked as reviewed by coffeys (Reviewer). pre-1970 data for some time zones is lost or becomes inaccurate with this tzdata release. Do we plan to release-note that point ? ------------- PR: https://git.openjdk.java.net/jdk/pull/5832 From naoto at openjdk.java.net Wed Oct 6 19:55:05 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 6 Oct 2021 19:55:05 GMT Subject: RFR: 8274407: (tz) Update Timezone Data to 2021c In-Reply-To: References: Message-ID: On Wed, 6 Oct 2021 19:43:06 GMT, Sean Coffey wrote: >> This PR is to upgrade the time zone data in the JDK to IANA's tzdata2021c level. Note that the tz data is "as is", as released by IANA. No `merged links` are retracted. >> The PR also fixes two issues along with the 2021c upgrade. > > pre-1970 data for some time zones is lost or becomes inaccurate with this tzdata release. Do we plan to release-note that point ? Good point, @coffeys. I'll make sure they are described in the release note. ------------- PR: https://git.openjdk.java.net/jdk/pull/5832 From naoto.sato at oracle.com Wed Oct 6 20:07:30 2021 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 6 Oct 2021 13:07:30 -0700 Subject: Strange colon in CollationElementIterator javadoc In-Reply-To: References: Message-ID: <9d22c9da-bb18-5113-49f1-8280e27bc34b@oracle.com> It was meant to be a vertical ellipsis. In hindsight, we could use the explicit character for that purpose. ('?' U+22EE) Naoto On 10/6/21 12:07 PM, Andrey Turbanov wrote: > Hello. > While reading the javadoc of CollationElementIterator I found a > strange colon in the example. > > https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/text/CollationElementIterator.java#L87 > > String testString = "This is a test"; > Collator col = Collator.getInstance(); > if (col instanceof RuleBasedCollator) { > RuleBasedCollator ruleBasedCollator = (RuleBasedCollator)col; > CollationElementIterator collationElementIterator = > ruleBasedCollator.getCollationElementIterator(testString); > int primaryOrder = > CollationElementIterator.primaryOrder(collationElementIterator.next()); > : > } > > Does it mean something? > It was added under https://bugs.openjdk.java.net/browse/JDK-6486695 > > > Andrey Turbanov > From bpb at openjdk.java.net Wed Oct 6 21:08:12 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 6 Oct 2021 21:08:12 GMT Subject: RFR: 8274835: Remove unnecessary castings in java.base In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 20:12:47 GMT, Andrey Turbanov wrote: > Redundant castings make code harder to read. > Found them by IntelliJ IDEA. > I tried to select only casts which are definitely safe to remove. Also didn't touch primitive types casts. `java.io` change looks all right. ------------- Marked as reviewed by bpb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5454 From github.com+43264149+iaroslavski at openjdk.java.net Wed Oct 6 21:21:29 2021 From: github.com+43264149+iaroslavski at openjdk.java.net (iaroslavski) Date: Wed, 6 Oct 2021 21:21:29 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v6] 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) Added more comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3938/files - new: https://git.openjdk.java.net/jdk/pull/3938/files/90c08aed..9989de5b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3938&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3938&range=04-05 Stats: 615 lines in 1 file changed: 295 ins; 173 del; 147 mod Patch: https://git.openjdk.java.net/jdk/pull/3938.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3938/head:pull/3938 PR: https://git.openjdk.java.net/jdk/pull/3938 From brian.burkhalter at oracle.com Wed Oct 6 21:52:51 2021 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 6 Oct 2021 21:52:51 +0000 Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v2] In-Reply-To: References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com> Message-ID: On Oct 5, 2021, at 5:05 PM, Raffaello Giulietti > wrote: The proof of the central theorem of Schubfach is based on continued fractions. It was prepared on ACL2 by the late Dmitry Nadezhin, who was a member of Oracle's formal verification group. Dmitry also knew my writing inside-out: not a formal peer review but perhaps even more insightful. Dmitry (Dima) was excellent and made a number of fine contributions to Java core-libs math. Here is something he posted a few years back about formal checking of the contribution here under discussion: https://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055768.html Schubfach has been exhaustively tested on all 2^32 floats, with approximations of powers of 10 of 63 bits each, rather than the full 126 bits used for doubles (the minimum size for doubles is 123 bits). It has also been tested for months on doubles, accumulating several trillions of witnesses and no failure. The exhaustive test on floats is an optionally executed part of the contributed code. I have run the exhaustive 32-bit test myself without seeing any errors. I also ran a 64-bit round trip test for probably at least a week without seeing any failures. I don?t know whether it has been mentioned in this recent thread as yet, but the performance of Schubfach is also much better then the JDK implementation, although I can?t recall with certainty the improvement. I think however that it was something like 14X? Brian From almatvee at openjdk.java.net Wed Oct 6 22:11:07 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Wed, 6 Oct 2021 22:11:07 GMT Subject: RFR: 8274346: Support for additional content in an app-image. [v2] In-Reply-To: References: Message-ID: On Wed, 6 Oct 2021 18:53:39 GMT, Andy Herrick wrote: >> 8274346: Support for additional content in an app-image. > > Andy Herrick has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8274346: Support for additional content in an app-image. Marked as reviewed by almatvee (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5780 From github.com+70726043+rgiulietti at openjdk.java.net Wed Oct 6 22:38:10 2021 From: github.com+70726043+rgiulietti at openjdk.java.net (Raffaello Giulietti) Date: Wed, 6 Oct 2021 22:38:10 GMT Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v2] In-Reply-To: References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com> Message-ID: <4_HNzSkYhCqrPEjhht2TIkiVamVLWXX0aedz-_GI0Ag=.fcae3ec0-4cc9-4cf6-97b6-33892cac7aea@github.com> On Fri, 16 Apr 2021 11:30:32 GMT, Raffaello Giulietti wrote: >> Hello, >> >> here's a PR for a patch submitted on March 2020 [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a thing. >> >> The patch has been edited to adhere to OpenJDK code conventions about multi-line (block) comments. Nothing in the code proper has changed, except for the addition of redundant but clarifying parentheses in some expressions. >> >> >> Greetings >> Raffaello > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > 4511638: Double.toString(double) sometimes produces incorrect results The last time I ran JMH over the whole range of bitwise uniformly distributed random doubles, I measured a speedup of about 17.7x https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-April/065921.html This is about 70 ns/conversion on a 2013 consumer-grade laptop. ------------- PR: https://git.openjdk.java.net/jdk/pull/3402 From amaembo at gmail.com Thu Oct 7 03:29:58 2021 From: amaembo at gmail.com (Tagir Valeev) Date: Thu, 7 Oct 2021 10:29:58 +0700 Subject: RFR: 8274835: Remove unnecessary castings in java.base In-Reply-To: <5cblPwQq4ebGNXXrtO9EoHnSZ_tcsn-EVxfMQMVEjOI=.9936fe80-1b9a-468c-8d3e-80eaad0977be@github.com> References: <5cblPwQq4ebGNXXrtO9EoHnSZ_tcsn-EVxfMQMVEjOI=.9936fe80-1b9a-468c-8d3e-80eaad0977be@github.com> Message-ID: On Thu, Oct 7, 2021 at 12:15 AM Joe Darcy wrote: > Curious. The JDK build is done with javac -Xlint:cast warning enabled (JDK-8032734) which is intended to catch issues like this. Perhaps IntelliJ is using a different (or sharper) analysis. Yes, our analysis is written independently of Javac (mostly by Anna Kozlova) and we had a long history of false-positives/false-negatives in this inspection, so it was tuned many times. It's not nearly simple. For now, it's turned on for the whole IntelliJ IDEA Ultimate repository (a warning causes the CI build to fail). I've found only five explicit suppressions in our codebase. Not sure if all of them are still necessary. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/5454 From github.com+741251+turbanoff at openjdk.java.net Thu Oct 7 07:35:21 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Thu, 7 Oct 2021 07:35:21 GMT Subject: RFR: 8274879: Replace uses of StringBuffer with StringBuilder within java.base classes Message-ID: StringBuffer is a legacy synchronized class. There are more modern alternatives which perform better: 1. Plain String concatenation should be preferred 2. StringBuilder is a direct replacement to StringBuffer which generally have better performance In [JDK-8264029](https://bugs.openjdk.java.net/browse/JDK-8264029) I migrated only usages which were automatically detected by IDEA. It turns out there are more usages which can be migrated. ------------- Commit messages: - [PATCH] Cleanup usages of StringBuffer in java.base module - [PATCH] Cleanup usages of StringBuffer in java.base module Changes: https://git.openjdk.java.net/jdk/pull/5432/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5432&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274879 Stats: 32 lines in 12 files changed: 0 ins; 0 del; 32 mod Patch: https://git.openjdk.java.net/jdk/pull/5432.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5432/head:pull/5432 PR: https://git.openjdk.java.net/jdk/pull/5432 From mbaesken at openjdk.java.net Thu Oct 7 11:27:22 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Thu, 7 Oct 2021 11:27:22 GMT Subject: RFR: JDK-8274840: Update OS detection code to recognize Windows 11 Message-ID: The OS detection code of the JDK/JVM should recognize the new Windows 11. For details see : https://docs.microsoft.com/en-us/windows/release-health/windows11-release-information OS build number is : 22000.194 for 21H2 (original release) Please review the following small patch ! (patch comes originally from azeller (Arno Zeller) , I just added a comment and did some testing) Thanks, Matthias ------------- Commit messages: - JDK-8274840 Changes: https://git.openjdk.java.net/jdk/pull/5846/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5846&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274840 Stats: 15 lines in 2 files changed: 13 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5846.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5846/head:pull/5846 PR: https://git.openjdk.java.net/jdk/pull/5846 From clanger at openjdk.java.net Thu Oct 7 11:43:08 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Thu, 7 Oct 2021 11:43:08 GMT Subject: RFR: JDK-8274840: Update OS detection code to recognize Windows 11 In-Reply-To: References: Message-ID: On Thu, 7 Oct 2021 11:20:57 GMT, Matthias Baesken wrote: > The OS detection code of the JDK/JVM should recognize the new Windows 11. For details see : > > https://docs.microsoft.com/en-us/windows/release-health/windows11-release-information > OS build number is : 22000.194 for 21H2 (original release) > > Please review the following small patch ! > (patch comes originally from azeller (Arno Zeller) , I just added a comment and did some testing) > > Thanks, Matthias Looks good to me. ------------- Marked as reviewed by clanger (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5846 From aefimov at openjdk.java.net Thu Oct 7 12:11:36 2021 From: aefimov at openjdk.java.net (Aleksei Efimov) Date: Thu, 7 Oct 2021 12:11:36 GMT Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v2] In-Reply-To: References: Message-ID: > This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver. > > The following API classes are added to `java.net.spi` package to facilitate this: > - `InetAddressResolverProvider` - abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers. > - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations. > - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations. > - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation. > > More details in [JEP-418](https://openjdk.java.net/jeps/418). > > Testing: new and existing `tier1:tier3` tests Aleksei Efimov 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 JDK-8244202_JEP418_impl - 8244202: Implementation of JEP 418: Internet-Address Resolution SPI ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5822/files - new: https://git.openjdk.java.net/jdk/pull/5822/files/77551538..41717fc7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5822&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5822&range=00-01 Stats: 4216 lines in 179 files changed: 1929 ins; 1744 del; 543 mod Patch: https://git.openjdk.java.net/jdk/pull/5822.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5822/head:pull/5822 PR: https://git.openjdk.java.net/jdk/pull/5822 From dholmes at openjdk.java.net Thu Oct 7 13:27:10 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 7 Oct 2021 13:27:10 GMT Subject: RFR: JDK-8274840: Update OS detection code to recognize Windows 11 In-Reply-To: References: Message-ID: On Thu, 7 Oct 2021 11:20:57 GMT, Matthias Baesken wrote: > The OS detection code of the JDK/JVM should recognize the new Windows 11. For details see : > > https://docs.microsoft.com/en-us/windows/release-health/windows11-release-information > OS build number is : 22000.194 for 21H2 (original release) > > Please review the following small patch ! > (patch comes originally from azeller (Arno Zeller) , I just added a comment and did some testing) > > Thanks, Matthias Functionally seems fine. One nit about comments. Thanks, David src/java.base/windows/native/libjava/java_props_md.c line 550: > 548: switch (minorVersion) { > 549: case 0: > 550: /* Windows 11 21H2 (original release) build number is 22000 */ Given the big comment block before the switch I don't see the need to repeat the information here. Same goes for the existing comments below for the server versions. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5846 From github.com+42899633+eastig at openjdk.java.net Thu Oct 7 14:15:22 2021 From: github.com+42899633+eastig at openjdk.java.net (Evgeny Astigeevich) Date: Thu, 7 Oct 2021 14:15:22 GMT Subject: RFR: 8271737: Only normalize the cached user.dir property once Message-ID: The change completes the fix of [JDK-8198997](https://bugs.openjdk.java.net/browse/JDK-8198997) which has added normalisation in a constructor but not removed it from the get method. ------------- Commit messages: - 8271737: Only normalize the cached user.dir property once Changes: https://git.openjdk.java.net/jdk/pull/5850/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5850&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271737 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5850.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5850/head:pull/5850 PR: https://git.openjdk.java.net/jdk/pull/5850 From naoto at openjdk.java.net Thu Oct 7 15:35:15 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 7 Oct 2021 15:35:15 GMT Subject: Integrated: 8274407: (tz) Update Timezone Data to 2021c In-Reply-To: References: Message-ID: <_NX0H0er1wkmnT5nKFEBD8ChF26s46LrDsEgIn0A5VU=.bd4ba204-8052-4545-8e97-1b1e6fd8881b@github.com> On Wed, 6 Oct 2021 01:24:49 GMT, Naoto Sato wrote: > This PR is to upgrade the time zone data in the JDK to IANA's tzdata2021c level. Note that the tz data is "as is", as released by IANA. No `merged links` are retracted. > The PR also fixes two issues along with the 2021c upgrade. This pull request has now been integrated. Changeset: 8ca08461 Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/8ca084617f331b6af934179f3f776c8158da5bba Stats: 635 lines in 13 files changed: 228 ins; 329 del; 78 mod 8274407: (tz) Update Timezone Data to 2021c 8274467: TestZoneInfo310.java fails with tzdata2021b 8274468: TimeZoneTest.java fails with tzdata2021b Reviewed-by: rriggs, iris, coffeys ------------- PR: https://git.openjdk.java.net/jdk/pull/5832 From naoto at openjdk.java.net Thu Oct 7 16:52:13 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 7 Oct 2021 16:52:13 GMT Subject: RFR: 8274879: Replace uses of StringBuffer with StringBuilder within java.base classes In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 06:50:21 GMT, Andrey Turbanov wrote: > StringBuffer is a legacy synchronized class. There are more modern alternatives which perform better: > 1. Plain String concatenation should be preferred > 2. StringBuilder is a direct replacement to StringBuffer which generally have better performance > > In [JDK-8264029](https://bugs.openjdk.java.net/browse/JDK-8264029) I migrated only usages which were automatically detected by IDEA. It turns out there are more usages which can be migrated. src/java.base/share/classes/java/lang/Character.java line 123: > 121: * than U+FFFF are called supplementary characters. The Java > 122: * platform uses the UTF-16 representation in {@code char} arrays and > 123: * in the {@code String} and {@code StringBuilder} classes. In Not sure simple replacement applies here, as `StringBuffer` still uses `UTF-16` representation. You may add `StringBuilder` as well here, but I think you might want to file a CSR to clarify. ------------- PR: https://git.openjdk.java.net/jdk/pull/5432 From github.com+43264149+iaroslavski at openjdk.java.net Thu Oct 7 20:08:10 2021 From: github.com+43264149+iaroslavski at openjdk.java.net (iaroslavski) Date: Thu, 7 Oct 2021 20:08:10 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v6] In-Reply-To: References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> Message-ID: <5BAr5gn8dpL25aSxc-w3bbRVo3bjkqWJwIkizCPwHps=.ba50b5b2-43fd-447b-bd04-aa26ee5140a4@github.com> On Wed, 6 Oct 2021 21:21:29 GMT, iaroslavski wrote: >> Sorting: >> >> - adopt radix sort for sequential and parallel sorts on int/long/float/double arrays (almost random and length > 6K) >> - fix tryMergeRuns() to better handle case when the last run is a single element >> - minor javadoc and comment changes >> >> Testing: >> - add new data inputs in tests for sorting >> - add min/max/infinity values to float/double testing >> - add tests for radix sort > > iaroslavski has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) > > Added more comments LSD (Least Significant Digit) Radix sort is introduced to improve sorting. Th?s algorithm requires additional buffer, but has O(n) complexity. At the same time Quicksort performs at O(n*ln(n)). Radix sort shows extremely better performance on large random data, whereas Quicksort or merging sort win on other inputs. We reuse additional buffer, if it is created during merge sort (in case of parallel sorting on computer with many processors). The same approach is used during allocation of buffer in merging sort. So, additional buffer is not created twice. We also check if we have enough memory for the buffer. Otherwise, sorting is continued with in-place algorithms only. Summary: introduced Radix sort requires the same amount memory as merge or merging sorts, reuses it if necessary, but works much faster than Quicksort. ------------- PR: https://git.openjdk.java.net/jdk/pull/3938 From turbanoff at gmail.com Thu Oct 7 20:10:13 2021 From: turbanoff at gmail.com (Andrey Turbanov) Date: Thu, 7 Oct 2021 23:10:13 +0300 Subject: Throwable not thrown. In sun.reflect.generics.parser.SignatureParser#parseBounds Message-ID: Hello. I found suspicious code in the method sun.reflect.generics.parser.SignatureParser#parseBounds https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/reflect/generics/parser/SignatureParser.java#L532 Method 'error' called without 'throw'. And the returned value is just ignored. error("Bound expected"); Current method implementation creates and returns GenericSignatureFormatError. private Error error(String errorMsg) { return new GenericSignatureFormatError("Signature Parse error: " + errorMsg + "\n\tRemaining input: " + remainder()); } I believe it's supposed to be thrown: throw error("Bound expected"); Andrey Turbanov From naoto at openjdk.java.net Thu Oct 7 21:36:21 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 7 Oct 2021 21:36:21 GMT Subject: RFR: 8274864: Remove Amman/Cairo hacks in ZoneInfoFile Message-ID: While working on tzdata2021c update, I noticed there is a dead code in `sun.util.calendar.ZoneInfoFile`, which was used to tweak the rules for `endOfDay` for certain cases. These are no longer needed as JDK's code is already capable of dealing with transitions beyond the end of the day. ------------- Commit messages: - 8274864: Remove Amman/Cairo hacks in ZoneInfoFile Changes: https://git.openjdk.java.net/jdk/pull/5857/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5857&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274864 Stats: 29 lines in 1 file changed: 0 ins; 29 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5857.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5857/head:pull/5857 PR: https://git.openjdk.java.net/jdk/pull/5857 From brian.burkhalter at oracle.com Thu Oct 7 21:37:48 2021 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 7 Oct 2021 21:37:48 +0000 Subject: ideas about making static shared pool for skip buffers for InputStream and Reader In-Reply-To: References: Message-ID: Re-directing to the appropriate mailing list, core-libs-dev; please exclude jdk-dev from any reply. How can they be shared when they are different data types, viz., byte vs. char? On Oct 7, 2021, at 2:26 PM, Xeno Amess > wrote: I just wonder, if it worthy to create static shared pools for skip buffers for InputStream and Reader, instead of create one for each instance. I do think it worthy a try. pr at https://github.com/openjdk/jdk/pull/5855 What the next step should I do? From amenkov at openjdk.java.net Thu Oct 7 21:53:27 2021 From: amenkov at openjdk.java.net (Alex Menkov) Date: Thu, 7 Oct 2021 21:53:27 GMT Subject: RFR: JDK-8274930: sun/tools/jps/TestJps.java can fail with long VM arguments string Message-ID: The fix adds "-XX:PerfMaxStringConstLength" argument running target app (default is 1024, 8K should be enough for any environments) ------------- Commit messages: - JDK-8274930 Changes: https://git.openjdk.java.net/jdk/pull/5858/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5858&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274930 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5858.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5858/head:pull/5858 PR: https://git.openjdk.java.net/jdk/pull/5858 From sspitsyn at openjdk.java.net Thu Oct 7 22:43:08 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Thu, 7 Oct 2021 22:43:08 GMT Subject: RFR: JDK-8274930: sun/tools/jps/TestJps.java can fail with long VM arguments string In-Reply-To: References: Message-ID: On Thu, 7 Oct 2021 21:46:47 GMT, Alex Menkov wrote: > The fix adds "-XX:PerfMaxStringConstLength" argument running target app (default is 1024, 8K should be enough for any environments) LGTM. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5858 From xenoamess at gmail.com Thu Oct 7 22:51:27 2021 From: xenoamess at gmail.com (Xeno Amess) Date: Fri, 8 Oct 2021 06:51:27 +0800 Subject: ideas about making static shared pool for skip buffers for InputStream and Reader In-Reply-To: References: Message-ID: each for each class... byte[] and char[] of course cannot mix...at least, cannt mix from java side. I'm not that sure if such black magic can do on jvm side. I don't think it can. It is not safe to open the containing pool to another class either... java have no friend-class system like cpp Xeno Amess ? 2021?10?8??? ??5:45??? > each for each class... > > byte[] and char[] of course cannot mix...at least, cannt mix from java > side. I'm not that sure if such black magic can do on jvm side. I don't > think it can. > > It is not safe to open the containing pool to another class either... java > have no friend-class system like cpp > > > Brian Burkhalter ?2021?10?8??? ??5:37??? > >> Re-directing to the appropriate mailing list, core-libs-dev; please >> exclude jdk-dev from any reply. >> >> How can they be shared when they are different data types, viz., byte vs. >> char? >> >> On Oct 7, 2021, at 2:26 PM, Xeno Amess wrote: >> >> I just wonder, if it worthy to create static shared pools for skip buffers >> for InputStream and Reader, instead of create one for each instance. >> >> I do think it worthy a try. >> >> pr at https://github.com/openjdk/jdk/pull/5855 >> >> What the next step should I do? >> >> >> From iris at openjdk.java.net Thu Oct 7 23:13:06 2021 From: iris at openjdk.java.net (Iris Clark) Date: Thu, 7 Oct 2021 23:13:06 GMT Subject: RFR: 8274864: Remove Amman/Cairo hacks in ZoneInfoFile In-Reply-To: References: Message-ID: On Thu, 7 Oct 2021 21:30:22 GMT, Naoto Sato wrote: > While working on tzdata2021c update, I noticed there is a dead code in `sun.util.calendar.ZoneInfoFile`, which was used to tweak the rules for `endOfDay` for certain cases. These are no longer needed as JDK's code is already capable of dealing with transitions beyond the end of the day. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5857 From xenoamess at gmail.com Thu Oct 7 21:45:58 2021 From: xenoamess at gmail.com (Xeno Amess) Date: Fri, 8 Oct 2021 05:45:58 +0800 Subject: ideas about making static shared pool for skip buffers for InputStream and Reader In-Reply-To: References: Message-ID: each for each class... byte[] and char[] of course cannot mix...at least, cannt mix from java side. I'm not that sure if such black magic can do on jvm side. I don't think it can. It is not safe to open the containing pool to another class either... java have no friend-class system like cpp Brian Burkhalter ?2021?10?8??? ??5:37??? > Re-directing to the appropriate mailing list, core-libs-dev; please > exclude jdk-dev from any reply. > > How can they be shared when they are different data types, viz., byte vs. > char? > > On Oct 7, 2021, at 2:26 PM, Xeno Amess wrote: > > I just wonder, if it worthy to create static shared pools for skip buffers > for InputStream and Reader, instead of create one for each instance. > > I do think it worthy a try. > > pr at https://github.com/openjdk/jdk/pull/5855 > > What the next step should I do? > > > From david.holmes at oracle.com Fri Oct 8 01:07:13 2021 From: david.holmes at oracle.com (David Holmes) Date: Fri, 8 Oct 2021 11:07:13 +1000 Subject: Throwable not thrown. In sun.reflect.generics.parser.SignatureParser#parseBounds In-Reply-To: References: Message-ID: <5c76905b-de19-978d-c03c-a9651b3fc5f8@oracle.com> On 8/10/2021 6:10 am, Andrey Turbanov wrote: > Hello. > > I found suspicious code in the method > sun.reflect.generics.parser.SignatureParser#parseBounds > https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/reflect/generics/parser/SignatureParser.java#L532 > > Method 'error' called without 'throw'. And the returned value is just ignored. > > error("Bound expected"); > > Current method implementation creates and returns GenericSignatureFormatError. > > private Error error(String errorMsg) { > return new GenericSignatureFormatError("Signature Parse error: " + > errorMsg + > "\n\tRemaining input: " + > remainder()); > } > > I believe it's supposed to be thrown: > > throw error("Bound expected"); Or given the comment on error(): // Currently throws a GenericSignatureFormatError. perhaps the intent was for error() to actually do the throwing. Obviously missing test coverage here too. Cheers, David > > > Andrey Turbanov > From github.com+18036229+chengjin01 at openjdk.java.net Fri Oct 8 04:53:10 2021 From: github.com+18036229+chengjin01 at openjdk.java.net (Cheng Jin) Date: Fri, 8 Oct 2021 04:53:10 GMT Subject: RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded libraries In-Reply-To: <1RwBnwfTi0XsUzPYQHKHTZ7jxgkhgsJfEG28Q33RahA=.6a992ad3-b289-4c93-9dc9-72a948f67581@github.com> References: <1RwBnwfTi0XsUzPYQHKHTZ7jxgkhgsJfEG28Q33RahA=.6a992ad3-b289-4c93-9dc9-72a948f67581@github.com> Message-ID: <-Sgl3wbFP-k2nDAbFsX3fZ9vs_7-Fno-FeyThJ_VBDY=.a6da9845-64ab-4bdf-bd0e-fd8c4ba77da7@github.com> On Wed, 2 Jun 2021 20:13:34 GMT, Maurizio Cimadamore wrote: >> This patch overhauls the library loading mechanism used by the Foreign Linker API. We realized that, while handy, the *default* lookup abstraction (`LibraryLookup::ofDefault`) was behaving inconsistentlt across platforms. >> >> This patch replaces `LibraryLookup` with a simpler `SymbolLookup` abstraction, a functional interface. Crucially, `SymbolLookup` does not concern with library loading, only symbol lookup. For this reason, two factories are added: >> >> * `SymbolLookup::loaderLookup` - which obtains a lookup that can be used to lookup symbols in libraries loaded by current loader >> * `CLinker::systemLookup` - a more stable replacement for the *default* lookup, which looks for symbols in libc.so (or its equivalent in other platforms). The contents of this lookup are unspecified. >> >> Both factories are *restricted*, so they can only be called when `--enable-native-access` is set. > >> _Mailing list message from [Chapman Flack](mailto:chap at anastigmatix.net) on [security-dev](mailto:security-dev at mail.openjdk.java.net):_ >> >> On 06/02/21 13:30, Maurizio Cimadamore wrote: >> >> > This patch replaces `LibraryLookup` with a simpler `SymbolLookup` >> > abstraction, a functional interface. Crucially, `SymbolLookup` does not >> > concern with library loading, only symbol lookup. For this reason, two >> > factories are added: >> >> Hi, >> >> While I am thinking about this, what will be the behavior when the JVM >> itself has been dynamically loaded into an embedding application, and >> launched with the JNI invocation API? >> >> Will there be a *Lookup flavor that is able to find any exported symbol >> known in the embedding environment the JVM was loaded into? (This is the >> sort of condition the Mac OS linker checks when given the -bundle_loader >> option.) >> >> Regards, >> Chapman Flack (maintainer of a project that happens to work that way) > > Hi, > at the moment we don't have plans to add such a lookup, but I believe it should be possible to build such a lookup using `dlopen` and the linker API. I have provided an example elsewhere of how easy it easy to build a wrapper lookup around dlopen/dlsym: > > https://gist.github.com/mcimadamore/0883ea6f4836ae0c1d2a31c48197da1a > > Perhaps something like that could be useful in the use case you mention? Hi @mcimadamore, As you mentioned at https://github.com/openjdk/jdk/pull/4316#issuecomment-853238872, the system lookup is supported by the underlying `NativeLibraries` which also works on OpenJDK16 to support `LibraryLookup::ofDefault`. But my finding is that it `LibraryLookup::ofDefault` works good on AIX (with `libc.a`) in OpenJDK16 but `CLinker.systemLookup()` ended up with `NoSuchElementException` after changing the code in `SystemLookup.java` and `CABI.java` as follows: private static final SymbolLookup syslookup = switch (CABI.current()) { case SysV, LinuxAArch64, MacOsAArch64, AIX -> libLookup(libs -> libs.loadLibrary("syslookup")); case Win64 -> makeWindowsLookup(); // out of line to workaround javac crash }; with a simple test & output: import jdk.incubator.foreign.CLinker; import static jdk.incubator.foreign.CLinker.*; import jdk.incubator.foreign.SymbolLookup; import jdk.incubator.foreign.Addressable; public class Test { private static CLinker clinker = CLinker.getInstance(); private static final SymbolLookup defaultLibLookup = CLinker.systemLookup(); public static void main(String args[]) throws Throwable { Addressable strlenSymbol = defaultLibLookup.lookup("strlen").get(); } } bin/java --enable-native-access=ALL-UNNAMED --add-modules jdk.incubator.foreign -Dforeign.restricted=permit Test WARNING: Using incubator modules: jdk.incubator.foreign Exception in thread "main" java.util.NoSuchElementException: No value present <----- at java.base/java.util.Optional.get(Optional.java:143) at Test.main(Test.java:11) So I am wondering what happened to the system lookup in such case given there should be no fundamental difference in leveraging `NativeLibraries` (I assume the library loading in OpenJDK16 & 17 is the same at this point) unless there is something else new in OpenJDK17 I am unaware of (e.g. the changes in `Lib.gmk` or `lib-std.m4`, or a custom system lookup is required on AIX, etc). Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/4316 From mbaesken at openjdk.java.net Fri Oct 8 06:43:08 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Fri, 8 Oct 2021 06:43:08 GMT Subject: Integrated: JDK-8274840: Update OS detection code to recognize Windows 11 In-Reply-To: References: Message-ID: On Thu, 7 Oct 2021 11:20:57 GMT, Matthias Baesken wrote: > The OS detection code of the JDK/JVM should recognize the new Windows 11. For details see : > > https://docs.microsoft.com/en-us/windows/release-health/windows11-release-information > OS build number is : 22000.194 for 21H2 (original release) > > Please review the following small patch ! > (patch comes originally from azeller (Arno Zeller) , I just added a comment and did some testing) > > Thanks, Matthias This pull request has now been integrated. Changeset: 97ea9dd2 Author: Matthias Baesken URL: https://git.openjdk.java.net/jdk/commit/97ea9dd2f24f9f1fb9b9345a4202a825ee28e014 Stats: 15 lines in 2 files changed: 13 ins; 0 del; 2 mod 8274840: Update OS detection code to recognize Windows 11 Co-authored-by: Arno Zeller Reviewed-by: clanger, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/5846 From mbaesken at openjdk.java.net Fri Oct 8 06:46:12 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Fri, 8 Oct 2021 06:46:12 GMT Subject: RFR: JDK-8274840: Update OS detection code to recognize Windows 11 In-Reply-To: References: Message-ID: On Thu, 7 Oct 2021 11:20:57 GMT, Matthias Baesken wrote: > The OS detection code of the JDK/JVM should recognize the new Windows 11. For details see : > > https://docs.microsoft.com/en-us/windows/release-health/windows11-release-information > OS build number is : 22000.194 for 21H2 (original release) > > Please review the following small patch ! > (patch comes originally from azeller (Arno Zeller) , I just added a comment and did some testing) > > Thanks, Matthias Hi Christoph and David, thanks for the reviews ! Best regards, Matthias ------------- PR: https://git.openjdk.java.net/jdk/pull/5846 From joehw at openjdk.java.net Fri Oct 8 07:12:07 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Fri, 8 Oct 2021 07:12:07 GMT Subject: RFR: 8274864: Remove Amman/Cairo hacks in ZoneInfoFile In-Reply-To: References: Message-ID: On Thu, 7 Oct 2021 21:30:22 GMT, Naoto Sato wrote: > While working on tzdata2021c update, I noticed there is a dead code in `sun.util.calendar.ZoneInfoFile`, which was used to tweak the rules for `endOfDay` for certain cases. These are no longer needed as JDK's code is already capable of dealing with transitions beyond the end of the day. Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5857 From lbourges at openjdk.java.net Fri Oct 8 07:16:12 2021 From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Fri, 8 Oct 2021 07:16:12 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v6] In-Reply-To: References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> Message-ID: On Wed, 6 Oct 2021 21:21:29 GMT, iaroslavski wrote: >> Sorting: >> >> - adopt radix sort for sequential and parallel sorts on int/long/float/double arrays (almost random and length > 6K) >> - fix tryMergeRuns() to better handle case when the last run is a single element >> - minor javadoc and comment changes >> >> Testing: >> - add new data inputs in tests for sorting >> - add min/max/infinity values to float/double testing >> - add tests for radix sort > > iaroslavski has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) > > Added more comments I want to give my point of view on the new memory requirements: - as radix sort is used for length > 4k, more often a temporary buffer will be needed (size = array length), so more often young gen GC passes will happen and maybe full gc if this buffer is really big (half heap?) - if OOME is encountered when the buffer is allocated, then dpqs is used (in-place no-alloc) so new sorting is more robust than dpqs in jdk17 Sorting tests could be made with verbose gc to ascertain the increased gc work, latency... ------------- PR: https://git.openjdk.java.net/jdk/pull/3938 From lbourges at openjdk.java.net Fri Oct 8 07:20:11 2021 From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Fri, 8 Oct 2021 07:20:11 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v6] In-Reply-To: References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> Message-ID: On Wed, 6 Oct 2021 21:21:29 GMT, iaroslavski wrote: >> Sorting: >> >> - adopt radix sort for sequential and parallel sorts on int/long/float/double arrays (almost random and length > 6K) >> - fix tryMergeRuns() to better handle case when the last run is a single element >> - minor javadoc and comment changes >> >> Testing: >> - add new data inputs in tests for sorting >> - add min/max/infinity values to float/double testing >> - add tests for radix sort > > iaroslavski has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) > > Added more comments It is possible to use an upper limit on the array size to disable radix sort and reduce memory footprint and gc overhead... ------------- PR: https://git.openjdk.java.net/jdk/pull/3938 From github.com+741251+turbanoff at openjdk.java.net Fri Oct 8 07:23:25 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Fri, 8 Oct 2021 07:23:25 GMT Subject: RFR: 8274946: Cleanup unnecessary calls to Throwable.initCause() in java.rmi Message-ID: Pass cause exception as constructor parameter is shorter and easier to read. ------------- Commit messages: - [PATCH] Cleanup unnecessary calls to Throwable.initCause() in java.rmi module Changes: https://git.openjdk.java.net/jdk/pull/5854/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5854&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274946 Stats: 20 lines in 5 files changed: 0 ins; 10 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/5854.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5854/head:pull/5854 PR: https://git.openjdk.java.net/jdk/pull/5854 From weijun at openjdk.java.net Fri Oct 8 07:29:27 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 8 Oct 2021 07:29:27 GMT Subject: RFR: 8274949: Use String.contains() instead of String.indexOf() in java.base In-Reply-To: References: Message-ID: <2wrfMoUmLw_xar7QqdTGlx3lRRn5ezXWZI3F6MIJoVo=.9e0d608d-6cf2-47ad-ae11-134f5d77bffe@github.com> On Fri, 17 Sep 2021 08:56:47 GMT, Andrey Turbanov wrote: > String.contains was introduced in Java 5. > Some code in java.base still uses old approach with `String.indexOf` to check if String contains specified substring. > I propose to migrate such usages. Makes code shorter and easier to read. security-related change looks fine. ------------- Marked as reviewed by weijun (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5559 From github.com+741251+turbanoff at openjdk.java.net Fri Oct 8 07:29:27 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Fri, 8 Oct 2021 07:29:27 GMT Subject: RFR: 8274949: Use String.contains() instead of String.indexOf() in java.base Message-ID: String.contains was introduced in Java 5. Some code in java.base still uses old approach with `String.indexOf` to check if String contains specified substring. I propose to migrate such usages. Makes code shorter and easier to read. ------------- Commit messages: - [PATCH] Use String.contains() instead of String.indexOf() in java.base - [PATCH] Use String.contains() instead of String.indexOf() in java.base Changes: https://git.openjdk.java.net/jdk/pull/5559/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5559&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274949 Stats: 40 lines in 17 files changed: 0 ins; 3 del; 37 mod Patch: https://git.openjdk.java.net/jdk/pull/5559.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5559/head:pull/5559 PR: https://git.openjdk.java.net/jdk/pull/5559 From dfuchs at openjdk.java.net Fri Oct 8 09:38:04 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 8 Oct 2021 09:38:04 GMT Subject: RFR: 8274949: Use String.contains() instead of String.indexOf() in java.base In-Reply-To: References: Message-ID: <2MqVsvFTfYzzjenWPASS0ZB0lzHlnwF3GJ7K8lOqpP0=.db5edd8a-b93e-46b4-a33d-4fe63a96caef@github.com> On Fri, 17 Sep 2021 08:56:47 GMT, Andrey Turbanov wrote: > String.contains was introduced in Java 5. > Some code in java.base still uses old approach with `String.indexOf` to check if String contains specified substring. > I propose to migrate such usages. Makes code shorter and easier to read. Changes to java.net look OK. Did you run tier1, tier2? ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5559 From vtewari at openjdk.java.net Fri Oct 8 10:15:07 2021 From: vtewari at openjdk.java.net (Vyom Tewari) Date: Fri, 8 Oct 2021 10:15:07 GMT Subject: RFR: 8274949: Use String.contains() instead of String.indexOf() in java.base In-Reply-To: References: Message-ID: On Fri, 17 Sep 2021 08:56:47 GMT, Andrey Turbanov wrote: > String.contains was introduced in Java 5. > Some code in java.base still uses old approach with `String.indexOf` to check if String contains specified substring. > I propose to migrate such usages. Makes code shorter and easier to read. java.net changes look OK to me. ------------- Marked as reviewed by vtewari (Committer). PR: https://git.openjdk.java.net/jdk/pull/5559 From lancea at openjdk.java.net Fri Oct 8 10:20:09 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Fri, 8 Oct 2021 10:20:09 GMT Subject: RFR: 8274949: Use String.contains() instead of String.indexOf() in java.base In-Reply-To: References: Message-ID: On Fri, 17 Sep 2021 08:56:47 GMT, Andrey Turbanov wrote: > String.contains was introduced in Java 5. > Some code in java.base still uses old approach with `String.indexOf` to check if String contains specified substring. > I propose to migrate such usages. Makes code shorter and easier to read. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5559 From github.com+741251+turbanoff at openjdk.java.net Fri Oct 8 14:01:10 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Fri, 8 Oct 2021 14:01:10 GMT Subject: RFR: 8274949: Use String.contains() instead of String.indexOf() in java.base In-Reply-To: <2MqVsvFTfYzzjenWPASS0ZB0lzHlnwF3GJ7K8lOqpP0=.db5edd8a-b93e-46b4-a33d-4fe63a96caef@github.com> References: <2MqVsvFTfYzzjenWPASS0ZB0lzHlnwF3GJ7K8lOqpP0=.db5edd8a-b93e-46b4-a33d-4fe63a96caef@github.com> Message-ID: On Fri, 8 Oct 2021 09:35:25 GMT, Daniel Fuchs wrote: >Did you run tier1, tier2? I did run tier2. (tier1 is automatically checked by GithubActions). No new tests failed. Only _usual_ tests, which always fail on my machine, were failed. ------------- PR: https://git.openjdk.java.net/jdk/pull/5559 From naoto at openjdk.java.net Fri Oct 8 16:14:15 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 8 Oct 2021 16:14:15 GMT Subject: Integrated: 8274864: Remove Amman/Cairo hacks in ZoneInfoFile In-Reply-To: References: Message-ID: On Thu, 7 Oct 2021 21:30:22 GMT, Naoto Sato wrote: > While working on tzdata2021c update, I noticed there is a dead code in `sun.util.calendar.ZoneInfoFile`, which was used to tweak the rules for `endOfDay` for certain cases. These are no longer needed as JDK's code is already capable of dealing with transitions beyond the end of the day. This pull request has now been integrated. Changeset: ec199072 Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/ec199072c5867624d66840238cc8828e16ae8da7 Stats: 29 lines in 1 file changed: 0 ins; 29 del; 0 mod 8274864: Remove Amman/Cairo hacks in ZoneInfoFile Reviewed-by: iris, joehw ------------- PR: https://git.openjdk.java.net/jdk/pull/5857 From iris at openjdk.java.net Fri Oct 8 17:08:07 2021 From: iris at openjdk.java.net (Iris Clark) Date: Fri, 8 Oct 2021 17:08:07 GMT Subject: RFR: 8274946: Cleanup unnecessary calls to Throwable.initCause() in java.rmi In-Reply-To: References: Message-ID: On Thu, 7 Oct 2021 18:00:33 GMT, Andrey Turbanov wrote: > Pass cause exception as constructor parameter is shorter and easier to read. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5854 From itakiguchi at openjdk.java.net Fri Oct 8 17:44:12 2021 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Fri, 8 Oct 2021 17:44:12 GMT Subject: RFR: 8274544: Langtools command's usage were garbled on Japanese Windows [v3] In-Reply-To: References: Message-ID: On Wed, 6 Oct 2021 18:08:04 GMT, Naoto Sato wrote: >> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision: >> >> 8274544: Langtools command's usage were garbled on Japanese Windows > > I got your issue now. Since the current code issues `FileReader()` without specifying the explicit charset, this is the prime example that is affected by the JEP. The question is, in which encoding the jshell save file should be? I think it belongs to the spec of jshell, and it should be specified somewhere in the document. > > BTW, the suggestion I made in `JShellToolProvider` still holds regardless of the save file issue. Hello @naotoj . Do you think I need to fix jshell issue by this PR ? ------------- PR: https://git.openjdk.java.net/jdk/pull/5771 From naoto at openjdk.java.net Fri Oct 8 18:17:10 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 8 Oct 2021 18:17:10 GMT Subject: RFR: 8274544: Langtools command's usage were garbled on Japanese Windows [v3] In-Reply-To: References: Message-ID: On Wed, 6 Oct 2021 18:08:04 GMT, Naoto Sato wrote: >> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision: >> >> 8274544: Langtools command's usage were garbled on Japanese Windows > > I got your issue now. Since the current code issues `FileReader()` without specifying the explicit charset, this is the prime example that is affected by the JEP. The question is, in which encoding the jshell save file should be? I think it belongs to the spec of jshell, and it should be specified somewhere in the document. > > BTW, the suggestion I made in `JShellToolProvider` still holds regardless of the save file issue. > Hello @naotoj . Do you think I need to fix jshell issue by this PR ? I'd appreciate it, as I don't have a Japanese Windows environment at hand. ------------- PR: https://git.openjdk.java.net/jdk/pull/5771 From naoto at openjdk.java.net Fri Oct 8 21:10:10 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 8 Oct 2021 21:10:10 GMT Subject: RFR: 8274544: Langtools command's usage were garbled on Japanese Windows [v3] In-Reply-To: References: Message-ID: On Wed, 6 Oct 2021 05:04:28 GMT, Ichiroh Takiguchi wrote: >> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13. >> After JDK18-b13, javac and some other langtool command's usage were garbled on Japanese Windows. >> These commands use PrintWriter instead of standard out/err with PrintStream. > > Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision: > > 8274544: Langtools command's usage were garbled on Japanese Windows BTW, does the PoC in the jshell bug report really causing the issue? System.out.println("\u3042") This is ASCII, so save/resotre does not seem to cause any issues across JDKs with and without JEP400. Did you mean `Systemout.println("?")` instead? ------------- PR: https://git.openjdk.java.net/jdk/pull/5771 From mcimadamore at openjdk.java.net Fri Oct 8 21:32:12 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 8 Oct 2021 21:32:12 GMT Subject: RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded libraries In-Reply-To: <-Sgl3wbFP-k2nDAbFsX3fZ9vs_7-Fno-FeyThJ_VBDY=.a6da9845-64ab-4bdf-bd0e-fd8c4ba77da7@github.com> References: <1RwBnwfTi0XsUzPYQHKHTZ7jxgkhgsJfEG28Q33RahA=.6a992ad3-b289-4c93-9dc9-72a948f67581@github.com> <-Sgl3wbFP-k2nDAbFsX3fZ9vs_7-Fno-FeyThJ_VBDY=.a6da9845-64ab-4bdf-bd0e-fd8c4ba77da7@github.com> Message-ID: On Fri, 8 Oct 2021 04:43:08 GMT, Cheng Jin wrote: > So I am wondering what happened to the system lookup in such case given there should be no fundamental difference in leveraging `NativeLibraries` (I assume the library loading in OpenJDK16 & 17 is the same at this point) unless there is something else new in OpenJDK17 I am unaware of (e.g. the changes in `Lib.gmk` or `lib-std.m4`, or a custom system lookup is required on AIX, etc). Thanks. In 17, SystemLookup loads a specific library that is generated at build time - which contains all the c stdlib symbols. That's what the Lib.gmk changes are for. What I suspect is that the library is not generated at all, or not correctly on AIX, which then causes the system lookup to misbehave. I would start by double checking that you have a file like this: /lib/libsyslookup.so And then, if the library exists, check that it has the right dependency; on my linux it's an empty library, but which depends on libc, libm and libdl: ldd lib/libsyslookup.so linux-vdso.so.1 (0x00007fff2bdf7000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f35f1def000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f35f1ca0000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f35f1c9a000) ------------- PR: https://git.openjdk.java.net/jdk/pull/4316 From github.com+18036229+chengjin01 at openjdk.java.net Fri Oct 8 21:49:10 2021 From: github.com+18036229+chengjin01 at openjdk.java.net (Cheng Jin) Date: Fri, 8 Oct 2021 21:49:10 GMT Subject: RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded libraries In-Reply-To: References: <1RwBnwfTi0XsUzPYQHKHTZ7jxgkhgsJfEG28Q33RahA=.6a992ad3-b289-4c93-9dc9-72a948f67581@github.com> <-Sgl3wbFP-k2nDAbFsX3fZ9vs_7-Fno-FeyThJ_VBDY=.a6da9845-64ab-4bdf-bd0e-fd8c4ba77da7@github.com> Message-ID: On Fri, 8 Oct 2021 21:29:19 GMT, Maurizio Cimadamore wrote: >> Hi @mcimadamore, >> >> As you mentioned at https://github.com/openjdk/jdk/pull/4316#issuecomment-853238872, the system lookup is supported by the underlying `NativeLibraries` which also works on OpenJDK16 to support `LibraryLookup::ofDefault`. >> >> But my finding is that it `LibraryLookup::ofDefault` works good on AIX (with `libc.a`) in OpenJDK16 but `CLinker.systemLookup()` ended up with `NoSuchElementException` after changing the code in `SystemLookup.java` and `CABI.java` as follows: >> >> private static final SymbolLookup syslookup = switch (CABI.current()) { >> case SysV, LinuxAArch64, MacOsAArch64, AIX -> libLookup(libs -> libs.loadLibrary("syslookup")); >> case Win64 -> makeWindowsLookup(); // out of line to workaround javac crash >> }; >> >> with a simple test & output: >> >> import jdk.incubator.foreign.CLinker; >> import static jdk.incubator.foreign.CLinker.*; >> import jdk.incubator.foreign.SymbolLookup; >> import jdk.incubator.foreign.Addressable; >> >> public class Test { >> private static CLinker clinker = CLinker.getInstance(); >> private static final SymbolLookup defaultLibLookup = CLinker.systemLookup(); >> >> public static void main(String args[]) throws Throwable { >> Addressable strlenSymbol = defaultLibLookup.lookup("strlen").get(); >> } >> } >> >> bin/java --enable-native-access=ALL-UNNAMED --add-modules jdk.incubator.foreign -Dforeign.restricted=permit Test >> WARNING: Using incubator modules: jdk.incubator.foreign >> Exception in thread "main" java.util.NoSuchElementException: No value present <----- >> at java.base/java.util.Optional.get(Optional.java:143) >> at Test.main(Test.java:11) >> >> >> So I am wondering what happened to the system lookup in such case given there should be no fundamental difference in leveraging `NativeLibraries` (I assume the library loading in OpenJDK16 & 17 is the same at this point) unless there is something else new in OpenJDK17 I am unaware of (e.g. the changes in `Lib.gmk` or `lib-std.m4`, or a custom system lookup is required on AIX, etc). Thanks. > >> So I am wondering what happened to the system lookup in such case given there should be no fundamental difference in leveraging `NativeLibraries` (I assume the library loading in OpenJDK16 & 17 is the same at this point) unless there is something else new in OpenJDK17 I am unaware of (e.g. the changes in `Lib.gmk` or `lib-std.m4`, or a custom system lookup is required on AIX, etc). Thanks. > > In 17, SystemLookup loads a specific library that is generated at build time - which contains all the c stdlib symbols. That's what the Lib.gmk changes are for. What I suspect is that the library is not generated at all, or not correctly on AIX, which then causes the system lookup to misbehave. > > I would start by double checking that you have a file like this: > > /lib/libsyslookup.so > > And then, if the library exists, check that it has the right dependency; on my linux it's an empty library, but which depends on libc, libm and libdl: > > > ldd lib/libsyslookup.so > linux-vdso.so.1 (0x00007fff2bdf7000) > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f35f1def000) > libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f35f1ca0000) > libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f35f1c9a000) Hi @mcimadamore, Here's output of `libsyslookup.so` on AIX: $ ldd ./lib/libsyslookup.so ./lib/libsyslookup.so needs: <--- nothing here $ whereis libc libc: /usr/lib/libc.a /usr/lib/libc128.a /usr/ccs/lib/libc.a So it is high likely that there were no dependencies in this generated library. > perhaps on AIX something similar to what we did for Windows [1] would be better. That's what I thought to be the only way around but might need to figure out the specifics on AIX. ------------- PR: https://git.openjdk.java.net/jdk/pull/4316 From mchung at openjdk.java.net Fri Oct 8 23:20:37 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 8 Oct 2021 23:20:37 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v11] In-Reply-To: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> Message-ID: > This reimplements core reflection with method handles. > > For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. > > The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. > > The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. > > Ran tier1-tier8 tests. > > [1] https://bugs.openjdk.java.net/browse/JDK-8013527 > [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 Mandy Chung has updated the pull request incrementally with two additional commits since the last revision: - Remove duplicated microbenchmarks - Avoid pitfall with unwanted inlining in some cases. Also remove boxing/unboxing to focus on the invocation cost ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5027/files - new: https://git.openjdk.java.net/jdk/pull/5027/files/9c28df4c..49029aa9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5027&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5027&range=09-10 Stats: 407 lines in 3 files changed: 71 ins; 309 del; 27 mod Patch: https://git.openjdk.java.net/jdk/pull/5027.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5027/head:pull/5027 PR: https://git.openjdk.java.net/jdk/pull/5027 From mchung at openjdk.java.net Fri Oct 8 23:31:32 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 8 Oct 2021 23:31:32 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v12] In-Reply-To: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> Message-ID: > This reimplements core reflection with method handles. > > For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. > > The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. > > The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. > > Ran tier1-tier8 tests. > > [1] https://bugs.openjdk.java.net/browse/JDK-8013527 > [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: Fix left-over assignment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5027/files - new: https://git.openjdk.java.net/jdk/pull/5027/files/49029aa9..86d34f48 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5027&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5027&range=10-11 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5027.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5027/head:pull/5027 PR: https://git.openjdk.java.net/jdk/pull/5027 From mchung at openjdk.java.net Sat Oct 9 00:08:08 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Sat, 9 Oct 2021 00:08:08 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v12] In-Reply-To: References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> Message-ID: On Fri, 8 Oct 2021 23:31:32 GMT, Mandy Chung wrote: >> This reimplements core reflection with method handles. >> >> For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. >> >> The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. >> >> The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. >> >> Ran tier1-tier8 tests. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8013527 >> [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > Fix left-over assignment [8cb8071](https://github.com/openjdk/jdk/pull/5027/commits/8cb8071d9a085349139215c8472730193650b247) adds the setup code to pollute the profile to avoid unwanted inlining in some cases. The benchmark numbers are now sensible where the `Var` cases should not perform better than `Const` cases. I observed that if `polluteProfile` is false, some `Var` cases perform better than `Const` cases. Updated performance result: Baseline (jdk-18+17) Benchmark Mode Cnt Score Error Units ReflectionSpeedBenchmark.constructorConst avgt 10 68.049 ? 0.872 ns/op ReflectionSpeedBenchmark.constructorPoly avgt 10 94.132 ? 1.805 ns/op ReflectionSpeedBenchmark.constructorVar avgt 10 64.543 ? 0.799 ns/op ReflectionSpeedBenchmark.instanceFieldConst avgt 10 35.361 ? 0.492 ns/op ReflectionSpeedBenchmark.instanceFieldPoly avgt 10 67.089 ? 3.288 ns/op ReflectionSpeedBenchmark.instanceFieldVar avgt 10 35.745 ? 0.554 ns/op ReflectionSpeedBenchmark.instanceMethodConst avgt 10 77.925 ? 2.026 ns/op ReflectionSpeedBenchmark.instanceMethodPoly avgt 10 96.094 ? 2.269 ns/op ReflectionSpeedBenchmark.instanceMethodVar avgt 10 80.002 ? 4.267 ns/op ReflectionSpeedBenchmark.staticFieldConst avgt 10 33.442 ? 2.659 ns/op ReflectionSpeedBenchmark.staticFieldPoly avgt 10 51.918 ? 1.522 ns/op ReflectionSpeedBenchmark.staticFieldVar avgt 10 33.967 ? 0.451 ns/op ReflectionSpeedBenchmark.staticMethodConst avgt 10 75.380 ? 1.660 ns/op ReflectionSpeedBenchmark.staticMethodPoly avgt 10 93.553 ? 1.037 ns/op ReflectionSpeedBenchmark.staticMethodVar avgt 10 76.728 ? 1.614 ns/op JEP 417 Benchmark Mode Cnt Score Error Units ReflectionSpeedBenchmark.constructorConst avgt 10 32.392 ? 0.473 ns/op ReflectionSpeedBenchmark.constructorPoly avgt 10 113.947 ? 1.205 ns/op ReflectionSpeedBenchmark.constructorVar avgt 10 76.885 ? 1.128 ns/op ReflectionSpeedBenchmark.instanceFieldConst avgt 10 18.569 ? 0.161 ns/op ReflectionSpeedBenchmark.instanceFieldPoly avgt 10 98.671 ? 2.015 ns/op ReflectionSpeedBenchmark.instanceFieldVar avgt 10 54.193 ? 3.510 ns/op ReflectionSpeedBenchmark.instanceMethodConst avgt 10 33.421 ? 0.406 ns/op ReflectionSpeedBenchmark.instanceMethodPoly avgt 10 109.129 ? 1.959 ns/op ReflectionSpeedBenchmark.instanceMethodVar avgt 10 90.420 ? 2.187 ns/op ReflectionSpeedBenchmark.staticFieldConst avgt 10 19.080 ? 0.179 ns/op ReflectionSpeedBenchmark.staticFieldPoly avgt 10 92.130 ? 2.729 ns/op ReflectionSpeedBenchmark.staticFieldVar avgt 10 53.899 ? 1.051 ns/op ReflectionSpeedBenchmark.staticMethodConst avgt 10 35.907 ? 0.456 ns/op ReflectionSpeedBenchmark.staticMethodPoly avgt 10 102.895 ? 1.604 ns/op ReflectionSpeedBenchmark.staticMethodVar avgt 10 82.123 ? 0.629 ns/op I also ran the following benchmarks which show no performance degradation: - Peter's custom JSON serialization and deserialization benchmark with Jackson - XStream converter type benchmark - Kryo field serializer benchmark Microbenchmarks show that the performance of the new implementation is significantly faster than the old implementation (43-57% faster). When `Field`, `Method`, and `Constructor` instances are held in non-constant fields (e.g. non-final field or an array element), microbenchmarks show some performance degradation. While the performance degradation is signifcant (51-77%) for field access when `Field` instances cannot be constant folded, it might not impact real-world applications. We will need the developers to test with early-access builds to help identify any behavior and performance regressions. We will also explore a post-JEP integration performance improvements such as refining bytecode shapes for field access to enable concrete `MethodHandle` or `VarHandle` be reliably optimized by JIT irrespective of whether receiver is constant or not. @plevart @cl4es if you agree, can you please do the (hopefully) final review. ------------- PR: https://git.openjdk.java.net/jdk/pull/5027 From github.com+6776231+talden at openjdk.java.net Sat Oct 9 03:19:09 2021 From: github.com+6776231+talden at openjdk.java.net (Talden) Date: Sat, 9 Oct 2021 03:19:09 GMT Subject: RFR: 8274811: Remove superfluous use of boxing in java.base In-Reply-To: References: Message-ID: On Sat, 11 Sep 2021 12:11:50 GMT, Andrey Turbanov wrote: > Usages of primitive types should be preferred and makes code easier to read. > Similar cleanups: > 1. [JDK-8273168](https://bugs.openjdk.java.net/browse/JDK-8273168) java.desktop > 2. [JDK-8274234](https://bugs.openjdk.java.net/browse/JDK-8274234) java.sql.rowset src/java.base/share/classes/sun/security/tools/keytool/Main.java line 4135: > 4133: if (date != null) { > 4134: if (date.matches("\\d\\d\\d\\d\\/\\d\\d\\/\\d\\d")) { > 4135: c.set(Integer.parseInt(date.substring(0, 4)), Could this, and several of the other cases identified in this PR, be replaced with a call to the `Integer.parseInt(CharSequence, int, int, int)` method to also avoid the String allocation? Though there are enough other places in the JDK where this opportunity seems valuable that maybe it warrants a tracking issue of its own. ------------- PR: https://git.openjdk.java.net/jdk/pull/5481 From alanb at openjdk.java.net Sat Oct 9 07:40:07 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 9 Oct 2021 07:40:07 GMT Subject: RFR: 8271598: CDS classlist file should support uber JARs In-Reply-To: References: Message-ID: On Sat, 9 Oct 2021 00:15:43 GMT, Calvin Cheung wrote: > Currently, for archive classes for custom loaders, CDS supports the following source locations in the classlist: I've added the core-libs label to this issue as this will require wider discussion, detailed review of the classes that are being added to jdk.internal.misc, and a discussion as to whether this is the right place. ------------- PR: https://git.openjdk.java.net/jdk/pull/5876 From whuang at openjdk.java.net Sat Oct 9 08:22:19 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Sat, 9 Oct 2021 08:22:19 GMT Subject: Integrated: 8268231: Aarch64: Use ldp in intrinsics for String.compareTo In-Reply-To: References: Message-ID: <2xHfCPldLbGsYQFPvnLK89Y_DQ0urt0VfroqrbJcTP0=.bf116946-e40a-4616-8ca6-aefac6493a47@github.com> On Thu, 8 Jul 2021 11:50:36 GMT, Wang Huang wrote: > Dear all, > Can you do me a favor to review this patch. This patch use `ldp` to implement String.compareTo. > > * We add a JMH test case > * Here is the result of this test case > > Benchmark |(size)| Mode| Cnt|Score | Error |Units > ---------------------------------|------|-----|----|------|--------|----- > StringCompare.compareLL | 64 | avgt| 5 |7.992 | ? 0.005|us/op > StringCompare.compareLL | 72 | avgt| 5 |15.029| ? 0.006|us/op > StringCompare.compareLL | 80 | avgt| 5 |14.655| ? 0.011|us/op > StringCompare.compareLL | 91 | avgt| 5 |16.363| ? 0.12 |us/op > StringCompare.compareLL | 101 | avgt| 5 |16.966| ? 0.007|us/op > StringCompare.compareLL | 121 | avgt| 5 |19.276| ? 0.006|us/op > StringCompare.compareLL | 181 | avgt| 5 |19.002| ? 0.417|us/op > StringCompare.compareLL | 256 | avgt| 5 |24.707| ? 0.041|us/op > StringCompare.compareLLWithLdp| 64 | avgt| 5 |8.001 | ? 0.121|us/op > StringCompare.compareLLWithLdp| 72 | avgt| 5 |11.573| ? 0.003|us/op > StringCompare.compareLLWithLdp| 80 | avgt| 5 |6.861 | ? 0.004|us/op > StringCompare.compareLLWithLdp| 91 | avgt| 5 |12.774| ? 0.201|us/op > StringCompare.compareLLWithLdp| 101 | avgt| 5 |8.691 | ? 0.004|us/op > StringCompare.compareLLWithLdp| 121 | avgt| 5 |11.091| ? 1.342|us/op > StringCompare.compareLLWithLdp| 181 | avgt| 5 |14.64 | ? 0.581|us/op > StringCompare.compareLLWithLdp| 256 | avgt| 5 |25.879| ? 1.775|us/op > StringCompare.compareUU | 64 | avgt| 5 |13.476| ? 0.01 |us/op > StringCompare.compareUU | 72 | avgt| 5 |15.078| ? 0.006|us/op > StringCompare.compareUU | 80 | avgt| 5 |23.512| ? 0.011|us/op > StringCompare.compareUU | 91 | avgt| 5 |24.284| ? 0.008|us/op > StringCompare.compareUU | 101 | avgt| 5 |20.707| ? 0.017|us/op > StringCompare.compareUU | 121 | avgt| 5 |29.302| ? 0.011|us/op > StringCompare.compareUU | 181 | avgt| 5 |39.31 | ? 0.016|us/op > StringCompare.compareUU | 256 | avgt| 5 |54.592| ? 0.392|us/op > StringCompare.compareUUWithLdp| 64 | avgt| 5 |16.389| ? 0.008|us/op > StringCompare.compareUUWithLdp| 72 | avgt| 5 |10.71 | ? 0.158|us/op > StringCompare.compareUUWithLdp| 80 | avgt| 5 |11.488| ? 0.024|us/op > StringCompare.compareUUWithLdp| 91 | avgt| 5 |13.412| ? 0.006|us/op > StringCompare.compareUUWithLdp| 101 | avgt| 5 |16.245| ? 0.434|us/op > StringCompare.compareUUWithLdp| 121 | avgt| 5 |16.597| ? 0.016|us/op > StringCompare.compareUUWithLdp| 181 | avgt| 5 |27.373| ? 0.017|us/op > StringCompare.compareUUWithLdp| 256 | avgt| 5 |41.74 | ? 3.5 |us/op > > From this table, we can see that in most cases, our patch is better than old one. > > Thank you for your review. Any suggestions are welcome. This pull request has now been integrated. Changeset: 6d1d4d52 Author: Wang Huang Committer: Hamlin Li URL: https://git.openjdk.java.net/jdk/commit/6d1d4d52928ed38bbc73ddcbede5389995a8e65f Stats: 106 lines in 1 file changed: 39 ins; 40 del; 27 mod 8268231: Aarch64: Use ldp in intrinsics for String.compareTo Co-authored-by: Wang Huang Co-authored-by: Sun Jianye Co-authored-by: Wu Yan Reviewed-by: ngasson, aph ------------- PR: https://git.openjdk.java.net/jdk/pull/4722 From wuyan at openjdk.java.net Sat Oct 9 09:09:10 2021 From: wuyan at openjdk.java.net (Wu Yan) Date: Sat, 9 Oct 2021 09:09:10 GMT Subject: RFR: 8273111: Default timezone should return zone ID if /etc/localtime is valid but not canonicalization on linux In-Reply-To: References: <6gmVj3r1hjhG5jvo_dSly3ShNnZZSCn-NIjtnvSySrk=.a88def27-7b80-425b-9ab8-2f94f5004b47@github.com> Message-ID: <9ve0dyB1yKCM7BZAF5kUtK2hY2qlLXtdY5AxsSPLzEc=.14a7411a-6408-41f7-aee3-dabe776c247a@github.com> On Wed, 1 Sep 2021 13:39:46 GMT, Naoto Sato wrote: >> Hi, >> Please help me review the change to enhance getting time zone ID from /etc/localtime on linux. >> >> We use `realpath` instead of `readlink` to obtain the link name of /etc/localtime, because `readlink` can only read the value of a symbolic of link, not the canonicalized absolute pathname. >> >> For example, the value of /etc/localtime is "../usr/share/zoneinfo//Asia/Shanghai", then the linkbuf obtained by `readlink` is "../usr/share/zoneinfo//Asia/Shanghai", and then the call of `getZoneName(linkbuf)` will get "/Asia/Shanghai", not "Asia/Shanghai", which consider as invalid in `ZoneInfoFile.getZoneInfo()`. Using `realpath`, you can get ?/usr/share/zoneinfo/Asia/Shanghai? directly from ?/etc/localtime?. >> >> Thanks, >> wuyan > > The change looks reasonable. Please test your fix with macOS as well. Hi, @naotoj, Could you do me a favor to review the patch? ------------- PR: https://git.openjdk.java.net/jdk/pull/5327 From tvaleev at openjdk.java.net Sat Oct 9 09:41:10 2021 From: tvaleev at openjdk.java.net (Tagir F.Valeev) Date: Sat, 9 Oct 2021 09:41:10 GMT Subject: RFR: 8274412: Add a method to Stream API to consume and close the stream without using try-with-resources In-Reply-To: References: Message-ID: On Sun, 3 Oct 2021 11:00:25 GMT, Tagir F. Valeev wrote: > Currently, when the stream holds a resource, it's necessary to wrap it with try-with-resources. This undermines the compact and fluent style of stream API calls. For example, if we want to get the `List` of files inside the directory and timely close the underlying filehandle, we should use something like this: > > > List paths; > try (Stream stream = Files.list(Path.of("/etc"))) { > paths = stream.toList(); > } > // use paths > > > I suggest to add a new default method to Stream interface named `consumeAndClose`, which allows performing terminal stream operation and closing the stream at the same time. It may look like this: > > > default R consumeAndClose(Function, ? extends R> function) { > Objects.requireNonNull(function); > try(this) { > return function.apply(this); > } > } > > > Now, it will be possible to get the list of the files in the fluent manner: > > > List list = Files.list(Path.of("/etc")).consumeAndClose(Stream::toList); CSR is [posted](https://bugs.openjdk.java.net/browse/JDK-8274994), please review! ------------- PR: https://git.openjdk.java.net/jdk/pull/5796 From forax at univ-mlv.fr Sat Oct 9 10:29:34 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 9 Oct 2021 12:29:34 +0200 (CEST) Subject: RFR: 8274412: Add a method to Stream API to consume and close the stream without using try-with-resources In-Reply-To: References: Message-ID: <412634929.2905766.1633775374522.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "Tagir F.Valeev" > To: "core-libs-dev" > Sent: Lundi 4 Octobre 2021 08:51:55 > Subject: RFR: 8274412: Add a method to Stream API to consume and close the stream without using try-with-resources > Currently, when the stream holds a resource, it's necessary to wrap it with > try-with-resources. This undermines the compact and fluent style of stream API > calls. For example, if we want to get the `List` of files inside the directory > and timely close the underlying filehandle, we should use something like this: > > > List paths; > try (Stream stream = Files.list(Path.of("/etc"))) { > paths = stream.toList(); > } > // use paths > > > I suggest to add a new default method to Stream interface named > `consumeAndClose`, which allows performing terminal stream operation and > closing the stream at the same time. It may look like this: > > > default R consumeAndClose(Function, ? extends R> function) > { > Objects.requireNonNull(function); > try(this) { > return function.apply(this); > } > } > > > Now, it will be possible to get the list of the files in the fluent manner: > > > List list = Files.list(Path.of("/etc")).applyAndClose(Stream::toList); I would prefer the method to be called applyAndClose() because it is what the method does, it applies the function and closes the stream. There are two missing information in the javadoc - the function taken as parameter should not return a stream, because the stream will be closed This is not okay List list = Files.list(Path.of("/etc")).applyAndClose(s -> s).toList(); - if there are intermediary operations, they have to be done in the function taken as parameter and not before calling applyAndClose() This is okay List list = Files.list(Path.of("/etc")).applyAndClose(s -> s.map(path -> Integer.parseInt(path.toString())).toList()); This is not okay List list = Files.list(Path.of("/etc")).map(path -> Integer.parseInt(path.toString())).applyAndClose(Stream::toList); In both case, IDEs can help, but i think it should be written explicitly in the javadoc. > > ------------- > > Commit messages: > - Fix tests > - 8274412: Add a method to Stream API to consume and close the stream without > using try-with-resources > > Changes: https://git.openjdk.java.net/jdk/pull/5796/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5796&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8274412 > Stats: 140 lines in 5 files changed: 135 ins; 0 del; 5 mod > Patch: https://git.openjdk.java.net/jdk/pull/5796.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/5796/head:pull/5796 > > PR: https://git.openjdk.java.net/jdk/pull/5796 From turbanoff at gmail.com Sat Oct 9 10:38:56 2021 From: turbanoff at gmail.com (Andrey Turbanov) Date: Sat, 9 Oct 2021 13:38:56 +0300 Subject: Unexepcted OutOfMemoryError from Arrays.deepToString Message-ID: Hello. I came across unexpected behaviour of Arrays.deepToString method. It throws OOM even on non-huge arrays. For example this code: int size = Integer.MAX_VALUE / 19; Integer[] integers = new Integer[size]; Arrays.fill(integers, 0); System.out.println(Arrays.deepToString(integers)); Fails with following stack trace: Exception in thread "main" java.lang.OutOfMemoryError: Requested array size exceeds VM limit at java.base/java.lang.AbstractStringBuilder.(AbstractStringBuilder.java:86) at java.base/java.lang.StringBuilder.(StringBuilder.java:112) at java.base/java.util.Arrays.deepToString(Arrays.java:5160) I believe it should be able to handle such arrays and not throw OOM Andrey Turbanov From github.com+70726043+rgiulietti at openjdk.java.net Sat Oct 9 11:18:08 2021 From: github.com+70726043+rgiulietti at openjdk.java.net (Raffaello Giulietti) Date: Sat, 9 Oct 2021 11:18:08 GMT Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v2] In-Reply-To: References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com> Message-ID: On Fri, 16 Apr 2021 11:30:32 GMT, Raffaello Giulietti wrote: >> Hello, >> >> here's a PR for a patch submitted on March 2020 [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a thing. >> >> The patch has been edited to adhere to OpenJDK code conventions about multi-line (block) comments. Nothing in the code proper has changed, except for the addition of redundant but clarifying parentheses in some expressions. >> >> >> Greetings >> Raffaello > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > 4511638: Double.toString(double) sometimes produces incorrect results (comment by Guy Steele) Hi, Raffaello, I will try to compose this message in plain ASCII and hope it does not get garbled. I have now re-read the Schubfach paper, and with the extra information in your previous email, I think I understood it a lot better this time. I am very enthusiastic about the approach. This is exactly what JonL White was trying to puzzle out some five decades ago: just how many digits do you need in your powers of ten to get accurate print-read round-trips? I am especially appreciative of the attention paid in the Schubfach paper to parameter M, which ensures that two-digit possibilities are considered in cases where it is required to print two significant digits anyway (scientific notation). I have also read the two papers I could find about Ryu. Schubfach is clearly an improvement over Ryu because it avoids the iteration, among other reasons. But the second paper, about Ryu for printf, addresses the specific difficulties of generating digits for printf format specifiers, and raises the interesting question of whether it would be worthwhile also to design a version of Schubfach that handles printf requirements. So I think it would be well worth incorporating the Schubfach algorithm into the JDK codebase. I am reassured that Schubfach has undergone extensive testing on trillions of randomly chosen values. But I would be further reassured by a statement that two important classes of values have been _exhaustively_ tested: (1) All positive powers of 2 representable in the double format, plus the maximum representable value. (These are the values that are surrounded by irregular spacing.) Furthermore, out of caution one should also test every fp value within Z ulps of such a value; perhaps Z should be 64 or even 1024. (2) All representable fp values that are the result of rounding-to-nearest some decimal value of the form y?10^n, where y is a member of, say, either D_1, D_2, D_3, or D_4. (These are values that may be especially susceptible to generation of too many digits by an insufficiently careful algorithm, and one reason might be insufficient precision or other algorithmic error in connection with a table of powers of ten.) Furthermore, out of caution one should also test every fp value within Y ulps of such a value; perhaps Y should be 64 or even 1024. In every case, the testing should include (a) ensuring round-trip print-read behavior; (b) comparing to what is produced by the current JDK algorithm, and investigating any cases that differ. And if other similar ?edge cases? can be identified from the structure of the code, those would be worth focusing on as well. If this testing has been or could be done, I would say, yes, certainly adopt Schubfach for Java. I would also recommend submitting the Schubfach paper to an appropriate conference or journal to get the benefit of further peer review of the algorithm and its write-up. ?Guy ---- (my reply) Hi Guy, for some reason your comments still appear garbled on the GitHub PR page and don't make it to the core-libs-dev mailing list at all. Luckily, they appear intelligible in my mailbox, so I'll keep going with prepending your comments in my replies: not ideal but good enough. Thanks so much for re-reading my "paper". printf() There are some issues to consider when trying to apply Schubfach to printf(), the main one being that printf() allows to specify an arbitrary length for the resulting decimal. This means, for example, that unlimited precision arithmetic is unavoidable. But it might be worthwhile to investigate using Schubfach for lengths up to H (9 and 17 for float and double, resp.) and fall back to unlimited precision beyond that. Before that, however, I would prefer to finally push Schubfach in the OpenJDK codebase for the toString() cases and close this PR. Tests Below, by "extensive test" I mean not only that the outcomes convert back without loss of information, but that they fully meet the spec about minimal number of digits, closeness, correct formatting (normal viz scientific), character set, etc. All currently available tests are in the contributed code of this PR and will be part of the OpenJDK once integrated. - All powers of 2 and the extreme values are already extensively tested. - All values closest to powers of 10 are extensively tested. - All values proposed by Paxson [1] are extensively tested. - A configurable number of random values are tested at each round (currently 4 * 1'000'000 random values). Should a value fail, there's enough diagnostic information for further investigation. I'll add extensive tests for the values you propose in point (1) and (2), setting Z = Y = 1024. As for comparison with the current JDK behavior, there are already a bunch of values for which extensive tests fail on the current JDK but pass with Schubfach. It would be cumbersome, if possible at all, to have both the current JDK and Schubfach implementations in the same OpenJDK codebase to be able to compare the outcomes. I performed comparisons in a different constellation, with Schubfach as an external library, but this is hardly a possibility in the core-libs. Needless to say, Schubfach outcomes are either the same as in JDK or better (shorter or closest to the fp value). Peer reviewed publication Shortening my 27 pages writing and re-formating it to meet a journal standards for publication would require investing yet another substantial amount of time. I'm not sure I'm prepared for that, given that I've no personal interest in a journal publication: I'm not an academic, I'm not pursuing a career... But I promise I'll think about reconsidering my position on this ;-) Greetings Raffaello ---- [1] Paxson V, "A Program for Testing IEEE Decimal-Binary Conversion" ------------- PR: https://git.openjdk.java.net/jdk/pull/3402 From pavel.rappo at oracle.com Sat Oct 9 12:07:10 2021 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Sat, 9 Oct 2021 12:07:10 +0000 Subject: Unexepcted OutOfMemoryError from Arrays.deepToString In-Reply-To: References: Message-ID: <4B45E453-7CE5-463B-A09E-906D168DDAD3@oracle.com> This error has two causes. The first cause is that the VM cannot allocate arrays whose length exceeds Integer.MAX_VALUE - 8 (MAX_ARRAY_SIZE). The second cause is that Arrays.deepToString tries to pre-allocate 20 chars per string representation for each array element and maxes out at Integer.MAX_VALUE, which is above MAX_ARRAY_SIZE. One solution would be to change Arrays.deepToString to max out at MAX_ARRAY_SIZE. Separately, java.lang.AbstractStringBuilder#MAX_ARRAY_SIZE seems unused; I wonder how that happened. -Pavel > On 9 Oct 2021, at 11:38, Andrey Turbanov wrote: > > Hello. > I came across unexpected behaviour of Arrays.deepToString method. > It throws OOM even on non-huge arrays. > For example this code: > > int size = Integer.MAX_VALUE / 19; > Integer[] integers = new Integer[size]; > Arrays.fill(integers, 0); > System.out.println(Arrays.deepToString(integers)); > > Fails with following stack trace: > > Exception in thread "main" java.lang.OutOfMemoryError: Requested array > size exceeds VM limit > at java.base/java.lang.AbstractStringBuilder.(AbstractStringBuilder.java:86) > at java.base/java.lang.StringBuilder.(StringBuilder.java:112) > at java.base/java.util.Arrays.deepToString(Arrays.java:5160) > > > I believe it should be able to handle such arrays and not throw OOM > > > Andrey Turbanov From pavel.rappo at oracle.com Sat Oct 9 17:08:54 2021 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Sat, 9 Oct 2021 17:08:54 +0000 Subject: Unexepcted OutOfMemoryError from Arrays.deepToString In-Reply-To: <4B45E453-7CE5-463B-A09E-906D168DDAD3@oracle.com> References: <4B45E453-7CE5-463B-A09E-906D168DDAD3@oracle.com> Message-ID: > On 9 Oct 2021, at 13:07, Pavel Rappo wrote: > > > > Separately, java.lang.AbstractStringBuilder#MAX_ARRAY_SIZE seems unused; I wonder how that happened. I found what happened: $ git log -S "MAX_ARRAY_SIZE" -- src/java.base/share/classes/java/lang/AbstractStringBuilder.java commit 03642a01af7123298d6524a98c99a3934d35c11b Author: Jim Laskey Date: Thu Jun 11 10:08:23 2020 -0300 8230744: Several classes throw OutOfMemoryError without message Reviewed-by: psandoz, martin, bchristi, rriggs, smarks Looking at the corresponding review thread, https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-June/066874.html, the question about "the local orphan" MAX_ARRAY_SIZE was raised by Martin and subsequently addressed by Jim. The problem is, there were two of these fields. The one in PriorityBlockingQueue was spotted and deleted, the one in AbstractStringBuilder was not. Andrey, regardless of the outcome of your main question (OOM from Arrays.deepToString), would be willing to publish a PR to delete that field in AbstractStringBuilder? -Pavel > > -Pavel > >> On 9 Oct 2021, at 11:38, Andrey Turbanov wrote: >> >> Hello. >> I came across unexpected behaviour of Arrays.deepToString method. >> It throws OOM even on non-huge arrays. >> For example this code: >> >> int size = Integer.MAX_VALUE / 19; >> Integer[] integers = new Integer[size]; >> Arrays.fill(integers, 0); >> System.out.println(Arrays.deepToString(integers)); >> >> Fails with following stack trace: >> >> Exception in thread "main" java.lang.OutOfMemoryError: Requested array >> size exceeds VM limit >> at java.base/java.lang.AbstractStringBuilder.(AbstractStringBuilder.java:86) >> at java.base/java.lang.StringBuilder.(StringBuilder.java:112) >> at java.base/java.util.Arrays.deepToString(Arrays.java:5160) >> >> >> I believe it should be able to handle such arrays and not throw OOM >> >> >> Andrey Turbanov > From xenoamess at gmail.com Sat Oct 9 17:19:02 2021 From: xenoamess at gmail.com (Xeno Amess) Date: Sun, 10 Oct 2021 01:19:02 +0800 Subject: Will it be worthy to add some public static final empty arrays for some most used types in some place in java.base, other than create them multi times in several places? Message-ID: I suggest putting them in Arrays btw. From pavel.rappo at oracle.com Sat Oct 9 17:53:56 2021 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Sat, 9 Oct 2021 17:53:56 +0000 Subject: Will it be worthy to add some public static final empty arrays for some most used types in some place in java.base, other than create them multi times in several places? In-Reply-To: References: Message-ID: Empty? As in arrays of length zero? There ought to be a much better solution. I'm neither an expert nor (sadly) an active follower of the Valhalla project [1]. Perhaps something there or in Frozen Arrays [2] will address the runtime cost of creating zero-length arrays much more elegantly. [1] https://openjdk.java.net/projects/valhalla/ [2] https://openjdk.java.net/jeps/8261007 -Pavel > On 9 Oct 2021, at 18:19, Xeno Amess wrote: > > I suggest putting them in Arrays btw. From mbien42 at gmail.com Sat Oct 9 18:58:20 2021 From: mbien42 at gmail.com (Michael Bien) Date: Sat, 9 Oct 2021 20:58:20 +0200 Subject: SourceVersion::feature Message-ID: <8dda85be-e55e-7d0f-0a6f-5db40691fed1@gmail.com> Hello, could javax.lang.model.SourceVersion receive a feature() method returning the version as an int, analog to java.lang.Runtime.Version? if (SourceVersion.latest().feature() >= 18) {} is simpler than comparing enums which may or may not exist dependent on the deployed java version and cleaner than ordinal() tricks. best regards, michael From turbanoff at gmail.com Sat Oct 9 19:39:41 2021 From: turbanoff at gmail.com (Andrey Turbanov) Date: Sat, 9 Oct 2021 22:39:41 +0300 Subject: Unexepcted OutOfMemoryError from Arrays.deepToString In-Reply-To: References: <4B45E453-7CE5-463B-A09E-906D168DDAD3@oracle.com> Message-ID: Created PR to remove AbstractStringBuilder.MAX_ARRAY_SIZE - https://github.com/openjdk/jdk/pull/5878 BTW, I found one more place where Integer.MAX_VALUE is used as maximum array length - java.util.concurrent.ScheduledThreadPoolExecutor.DelayedWorkQueue#grow I think this method could be reworked to take advantage of ArraysSupport.newLength method too. Andrey Turbanov ??, 9 ???. 2021 ?. ? 20:09, Pavel Rappo : > > > > > On 9 Oct 2021, at 13:07, Pavel Rappo wrote: > > > > > > > > Separately, java.lang.AbstractStringBuilder#MAX_ARRAY_SIZE seems unused; I wonder how that happened. > > I found what happened: > > $ git log -S "MAX_ARRAY_SIZE" -- src/java.base/share/classes/java/lang/AbstractStringBuilder.java > commit 03642a01af7123298d6524a98c99a3934d35c11b > Author: Jim Laskey > Date: Thu Jun 11 10:08:23 2020 -0300 > > 8230744: Several classes throw OutOfMemoryError without message > > Reviewed-by: psandoz, martin, bchristi, rriggs, smarks > > Looking at the corresponding review thread, https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-June/066874.html, the question about "the local orphan" MAX_ARRAY_SIZE was raised by Martin and subsequently addressed by Jim. The problem is, there were two of these fields. The one in PriorityBlockingQueue was spotted and deleted, the one in AbstractStringBuilder was not. > > Andrey, regardless of the outcome of your main question (OOM from Arrays.deepToString), would be willing to publish a PR to delete that field in AbstractStringBuilder? > > -Pavel > > > > > -Pavel > > > >> On 9 Oct 2021, at 11:38, Andrey Turbanov wrote: > >> > >> Hello. > >> I came across unexpected behaviour of Arrays.deepToString method. > >> It throws OOM even on non-huge arrays. > >> For example this code: > >> > >> int size = Integer.MAX_VALUE / 19; > >> Integer[] integers = new Integer[size]; > >> Arrays.fill(integers, 0); > >> System.out.println(Arrays.deepToString(integers)); > >> > >> Fails with following stack trace: > >> > >> Exception in thread "main" java.lang.OutOfMemoryError: Requested array > >> size exceeds VM limit > >> at java.base/java.lang.AbstractStringBuilder.(AbstractStringBuilder.java:86) > >> at java.base/java.lang.StringBuilder.(StringBuilder.java:112) > >> at java.base/java.util.Arrays.deepToString(Arrays.java:5160) > >> > >> > >> I believe it should be able to handle such arrays and not throw OOM > >> > >> > >> Andrey Turbanov > > > From github.com+741251+turbanoff at openjdk.java.net Sat Oct 9 19:40:18 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Sat, 9 Oct 2021 19:40:18 GMT Subject: RFR: 8275002: Remove unused AbstractStringBuilder.MAX_ARRAY_SIZE Message-ID: <-vjB1Be5ZpM1cLYpnHh0Z2jy5iZGogUv_FawEGdv68U=.3b4ee0cf-2792-4d9a-aa26-1b5dc6180307@github.com> 8275002: Remove unused AbstractStringBuilder.MAX_ARRAY_SIZE ------------- Commit messages: - [PATCH] Remove unused AbstractStringBuilder.MAX_ARRAY_SIZE Changes: https://git.openjdk.java.net/jdk/pull/5878/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5878&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275002 Stats: 8 lines in 1 file changed: 0 ins; 8 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5878.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5878/head:pull/5878 PR: https://git.openjdk.java.net/jdk/pull/5878 From xenoamess at gmail.com Sat Oct 9 20:00:53 2021 From: xenoamess at gmail.com (Xeno Amess) Date: Sun, 10 Oct 2021 04:00:53 +0800 Subject: Will it be worthy to add some public static final empty arrays for some most used types in some place in java.base, other than create them multi times in several places? In-Reply-To: References: Message-ID: sigh. quite some good things I always want are at valhalla , but I just don't think they will come stable soon. hope me be wrong. Pavel Rappo ?2021?10?10??? ??1:54??? > Empty? As in arrays of length zero? > > There ought to be a much better solution. I'm neither an expert nor > (sadly) an active follower of the Valhalla project [1]. Perhaps something > there or in Frozen Arrays [2] will address the runtime cost of creating > zero-length arrays much more elegantly. > > [1] https://openjdk.java.net/projects/valhalla/ > [2] https://openjdk.java.net/jeps/8261007 > > -Pavel > > > On 9 Oct 2021, at 18:19, Xeno Amess wrote: > > > > I suggest putting them in Arrays btw. > > From xenoamess at gmail.com Sat Oct 9 20:34:11 2021 From: xenoamess at gmail.com (Xeno Amess) Date: Sun, 10 Oct 2021 04:34:11 +0800 Subject: Will it be worthy to add some public static final empty arrays for some most used types in some place in java.base, other than create them multi times in several places? In-Reply-To: References: Message-ID: sample codes here https://github.com/openjdk/jdk/pull/5874 if anyone interested Xeno Amess ?2021?10?10??? ??4:00??? > sigh. > > quite some good things I always want are at valhalla > , but I just don't think > they will come stable soon. > > hope me be wrong. > > > Pavel Rappo ?2021?10?10??? ??1:54??? > >> Empty? As in arrays of length zero? >> >> There ought to be a much better solution. I'm neither an expert nor >> (sadly) an active follower of the Valhalla project [1]. Perhaps something >> there or in Frozen Arrays [2] will address the runtime cost of creating >> zero-length arrays much more elegantly. >> >> [1] https://openjdk.java.net/projects/valhalla/ >> [2] https://openjdk.java.net/jeps/8261007 >> >> -Pavel >> >> > On 9 Oct 2021, at 18:19, Xeno Amess wrote: >> > >> > I suggest putting them in Arrays btw. >> >> From github.com+1701815+mkarg at openjdk.java.net Sun Oct 10 08:58:12 2021 From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG) Date: Sun, 10 Oct 2021 08:58:12 GMT Subject: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream should override transferTo [v13] In-Reply-To: References: Message-ID: On Sun, 1 Aug 2021 22:01:33 GMT, Markus KARG wrote: >> This PR-*draft* is **work in progress** and an invitation to discuss a possible solution for issue [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not yet* intended for a final review. >> >> As proposed in JDK-8265891, this PR provides an implementation for `Channels.newInputStream().transferTo()` which provide superior performance compared to the current implementation. The changes are: >> * Prevents transfers through the JVM heap as much as possibly by offloading to deeper levels via NIO, hence allowing the operating system to optimize the transfer. >> * Using more JRE heap in the fallback case when no NIO is possible (still only KiBs, hence mostl ynegligible even on SBCs) to better perform on modern hardware / fast I/O devides. >> >> Using JMH I have benchmarked both, the original implementation and this implementation, and (depending on the used hardware and use case) performance change was approx. doubled performance. So this PoC proofs that it makes sense to finalize this work and turn it into an actual OpenJDK contribution. >> >> I encourage everybody to discuss this draft: >> * Are there valid arguments for *not* doing this change? >> * Is there a *better* way to improve performance of `Channels.newInputStream().transferTo()`? >> * How to go on from here: What is missing to get this ready for an actual review? > > Markus KARG has updated the pull request incrementally with two additional commits since the last revision: > > - Draft: Eliminated duplicate code using lambda expressions > - Draft: Use blocking mode also for target channel Work on this draft will be continued as soon as depenency PRs are resolved. Please keep this issue open. ------------- PR: https://git.openjdk.java.net/jdk/pull/4263 From github.com+10835776+stsypanov at openjdk.java.net Sun Oct 10 16:45:06 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Sun, 10 Oct 2021 16:45:06 GMT Subject: RFR: JDK-8274686 : java.util.UUID#hashCode() should use Long.hashCode() In-Reply-To: References: Message-ID: On Wed, 6 Oct 2021 09:26:06 GMT, Peter Levart wrote: >> This is trivial fix of [JDK-8274686](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8274686) which replaces manually-computed `int`-based `long` hash-code. >> >> Because `Long#hashCode(long)` uses other hashing function than the one currently used here: >> >> https://github.com/openjdk/jdk/blob/75d6688df9845ecb8f370b4cd2d5a36f13d3cdc0/src/java.base/share/classes/java/lang/Long.java#L1440-L1442 >> >> the value of `hashCode()` will produce different result, however this does not seem to be a breaking change as `UUID#hashCode()` is not specified. >> >> --- >> >> Note: the comment to the bug states: >> >>> Moved to JDK for further discussions of the proposed enhancement. >> >> But as there seemed to be no corresponding discussion in core-libs-dev and the change looks trivial, I considered that it is appropriate to open a PR which (if needed) may be used for discussion (especially, considering the fact that its comments get mirrored to the ML). > > Yes, the reverted change to BitSet.hashCode in https://github.com/openjdk/jdk/pull/4309 has the same property. It could be applied without any visible effect. @plevart should I then file a follow-up ticket for `BitSet`? And should we change the JavaDoc providing there we have computation formula explicitly specified? ------------- PR: https://git.openjdk.java.net/jdk/pull/5811 From prappo at openjdk.java.net Sun Oct 10 17:15:10 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Sun, 10 Oct 2021 17:15:10 GMT Subject: RFR: 8275002: Remove unused AbstractStringBuilder.MAX_ARRAY_SIZE In-Reply-To: <-vjB1Be5ZpM1cLYpnHh0Z2jy5iZGogUv_FawEGdv68U=.3b4ee0cf-2792-4d9a-aa26-1b5dc6180307@github.com> References: <-vjB1Be5ZpM1cLYpnHh0Z2jy5iZGogUv_FawEGdv68U=.3b4ee0cf-2792-4d9a-aa26-1b5dc6180307@github.com> Message-ID: On Sat, 9 Oct 2021 17:54:16 GMT, Andrey Turbanov wrote: > 8275002: Remove unused AbstractStringBuilder.MAX_ARRAY_SIZE Marked as reviewed by prappo (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5878 From jlaskey at openjdk.java.net Sun Oct 10 17:15:10 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Sun, 10 Oct 2021 17:15:10 GMT Subject: RFR: 8275002: Remove unused AbstractStringBuilder.MAX_ARRAY_SIZE In-Reply-To: <-vjB1Be5ZpM1cLYpnHh0Z2jy5iZGogUv_FawEGdv68U=.3b4ee0cf-2792-4d9a-aa26-1b5dc6180307@github.com> References: <-vjB1Be5ZpM1cLYpnHh0Z2jy5iZGogUv_FawEGdv68U=.3b4ee0cf-2792-4d9a-aa26-1b5dc6180307@github.com> Message-ID: On Sat, 9 Oct 2021 17:54:16 GMT, Andrey Turbanov wrote: > 8275002: Remove unused AbstractStringBuilder.MAX_ARRAY_SIZE Marked as reviewed by jlaskey (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5878 From brian.goetz at oracle.com Sun Oct 10 18:30:56 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Sun, 10 Oct 2021 18:30:56 +0000 Subject: RFR: 8274412: Add a method to Stream API to consume and close the stream without using try-with-resources In-Reply-To: References: Message-ID: I am not really sure we?ve gotten the right idiom here yet. I?d like to slow down a bit before making an API decision. What id suggest is capturing the proposed api and spec on list, and let?s let this sit and bake for a bit longer. My sense is that something better may well emerge if we do. Sent from my MacBook Wheel > On Oct 9, 2021, at 5:41 AM, Tagir F.Valeev wrote: > > ?On Sun, 3 Oct 2021 11:00:25 GMT, Tagir F. Valeev wrote: > >> Currently, when the stream holds a resource, it's necessary to wrap it with try-with-resources. This undermines the compact and fluent style of stream API calls. For example, if we want to get the `List` of files inside the directory and timely close the underlying filehandle, we should use something like this: >> >> >> List paths; >> try (Stream stream = Files.list(Path.of("/etc"))) { >> paths = stream.toList(); >> } >> // use paths >> >> >> I suggest to add a new default method to Stream interface named `consumeAndClose`, which allows performing terminal stream operation and closing the stream at the same time. It may look like this: >> >> >> default R consumeAndClose(Function, ? extends R> function) { >> Objects.requireNonNull(function); >> try(this) { >> return function.apply(this); >> } >> } >> >> >> Now, it will be possible to get the list of the files in the fluent manner: >> >> >> List list = Files.list(Path.of("/etc")).consumeAndClose(Stream::toList); > > CSR is [posted](https://bugs.openjdk.java.net/browse/JDK-8274994), please review! > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/5796 From prappo at openjdk.java.net Sun Oct 10 19:37:11 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Sun, 10 Oct 2021 19:37:11 GMT Subject: RFR: 8275002: Remove unused AbstractStringBuilder.MAX_ARRAY_SIZE In-Reply-To: <-vjB1Be5ZpM1cLYpnHh0Z2jy5iZGogUv_FawEGdv68U=.3b4ee0cf-2792-4d9a-aa26-1b5dc6180307@github.com> References: <-vjB1Be5ZpM1cLYpnHh0Z2jy5iZGogUv_FawEGdv68U=.3b4ee0cf-2792-4d9a-aa26-1b5dc6180307@github.com> Message-ID: On Sat, 9 Oct 2021 17:54:16 GMT, Andrey Turbanov wrote: > 8275002: Remove unused AbstractStringBuilder.MAX_ARRAY_SIZE Oops. I think we should also do something about this occurrence of MAX_ARRAY_SIZE: https://github.com/openjdk/jdk/blob/d679bd3ab8b41a14359d3bfb9763a1178d02ecb0/src/java.base/share/classes/java/lang/AbstractStringBuilder.java#L239 ------------- PR: https://git.openjdk.java.net/jdk/pull/5878 From darcy at openjdk.java.net Sun Oct 10 20:34:21 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Sun, 10 Oct 2021 20:34:21 GMT Subject: RFR: 8275013: Improve discussion of serialization method declarations in java.io.Object{Input, Output}Stream Message-ID: The java.io.ObjectInputStream and java.io.ObjectOuputStream classes are part of the serialization feature. These classes contain brief descriptions of some of the methods serializable classes can define to interact with the serialization mechanism, readObject, readObjectNoData, and writeObject. These descriptions are not entirely consistent with one another and at least one is arguably misleading. This PR makes the brief discussion the same in both classes and addresses the misleading point: the throws clauses of the methods will not effect whether or not the methods are found by serialization, but throwing unchecked exceptions not declared in the standard signatures is ill-advised. (The current implementation looks up the methods by name using core reflection; the method modifiers are checked to match but the throws information is not.) Please also review the corresponding CSR : https://bugs.openjdk.java.net/browse/JDK-8275014 ------------- Commit messages: - 8275013: Improve discussion of serialization method declarations in java.io.Object{Input, Output}Stream Changes: https://git.openjdk.java.net/jdk/pull/5883/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5883&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275013 Stats: 18 lines in 2 files changed: 13 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/5883.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5883/head:pull/5883 PR: https://git.openjdk.java.net/jdk/pull/5883 From serb at openjdk.java.net Sun Oct 10 22:16:15 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sun, 10 Oct 2021 22:16:15 GMT Subject: RFR: 8275002: Remove unused AbstractStringBuilder.MAX_ARRAY_SIZE In-Reply-To: <-vjB1Be5ZpM1cLYpnHh0Z2jy5iZGogUv_FawEGdv68U=.3b4ee0cf-2792-4d9a-aa26-1b5dc6180307@github.com> References: <-vjB1Be5ZpM1cLYpnHh0Z2jy5iZGogUv_FawEGdv68U=.3b4ee0cf-2792-4d9a-aa26-1b5dc6180307@github.com> Message-ID: On Sat, 9 Oct 2021 17:54:16 GMT, Andrey Turbanov wrote: > 8275002: Remove unused AbstractStringBuilder.MAX_ARRAY_SIZE src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 240: > 238: * OutOfMemoryError: Requested array size exceeds VM limit > 239: */ > 240: private static final int MAX_ARRAY_SIZE = Integer.MAX_VALUE - 8; Looks like the usage of this field was removed by the https://github.com/openjdk/lanai/commit/03642a01, note that the doc for the "newCapacity" is still mentioned this field. ------------- PR: https://git.openjdk.java.net/jdk/pull/5878 From liangchenblue at gmail.com Mon Oct 11 00:23:29 2021 From: liangchenblue at gmail.com (-) Date: Sun, 10 Oct 2021 19:23:29 -0500 Subject: Optimizing InputStream.skip(long) In-Reply-To: <66692be7-c0dd-48a5-0c4f-31cf625cdb5c@oracle.com> References: <66692be7-c0dd-48a5-0c4f-31cf625cdb5c@oracle.com> Message-ID: Thanks for the suggestion. Forwarding to the core libs list. On Sun, Oct 10, 2021 at 6:52 PM David Holmes wrote: > > Hi, > > This belongs on core-libs-dev at openjdk.java.net > > Thanks, > David > > On 11/10/2021 9:39 am, - wrote: > > On GitHub, xenoamess sent a pull request [1] that optimizes skipBuffer > > array used by InputStream.skip by caching one for each InputStream > > instance (static ones are unsafe per bug 7000600) like the > > java.io.Reader class does (the reader one is behind a lock, while this > > one is possibly concurrent). > > > > Pros: Input streams that inherit the default skip logic can reduce > > buffer array creation by reusing the compatible old array when the > > skip method is called multiple times. > > > > Cons: This adds a field to InputStream; the array cannot be GC'd until > > the InputStream is GC'd. (But it has a length limit and the impact is > > less) > > > > Additional Info: Most JDK InputStream implementations already > > overrides this method to offer a more efficient implementation as > > suggested in the Javadocs. Reader.skip(long) calls Reader.read(char[], > > int, int), and this change doesn't affect the Reader class. > > > > I wonder if this idea is worthy of a JDK issue so this patch may > > eventually be accepted. Feel free to post any feedback, too! > > > > [1]: https://git.openjdk.java.net/jdk/pull/5872 > > From github.com+70726043+rgiulietti at openjdk.java.net Mon Oct 11 08:19:18 2021 From: github.com+70726043+rgiulietti at openjdk.java.net (Raffaello Giulietti) Date: Mon, 11 Oct 2021 08:19:18 GMT Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v2] In-Reply-To: References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com> Message-ID: On Fri, 16 Apr 2021 11:30:32 GMT, Raffaello Giulietti wrote: >> Hello, >> >> here's a PR for a patch submitted on March 2020 [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a thing. >> >> The patch has been edited to adhere to OpenJDK code conventions about multi-line (block) comments. Nothing in the code proper has changed, except for the addition of redundant but clarifying parentheses in some expressions. >> >> >> Greetings >> Raffaello > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > 4511638: Double.toString(double) sometimes produces incorrect results Hi Guy, while implementing the additional test recommended in your point (2), it occurred to me that the numbers of the form y 10^n, y in D_k (k = 1, 2, 3, 4) end up being of the form y' 10^n', where y' = y / 10^k, n' = n + k, plus the 2 * Y values around these. Such numbers do not seem to show any special structure worth a dedicated test, so I'm wondering if you mean something else instead. Perhaps you mean y to have at most 4 digits, i.e., 0 <= y < 10^4? Greetings Raffaello P.S. The test recommended in point (1) pass successfully. ------------- PR: https://git.openjdk.java.net/jdk/pull/3402 From shade at openjdk.java.net Mon Oct 11 11:09:10 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 11 Oct 2021 11:09:10 GMT Subject: RFR: 8177814: jdk/editpad is not in jdk TEST.groups In-Reply-To: References: Message-ID: On Thu, 23 Sep 2021 08:54:48 GMT, Aleksey Shipilev wrote: > @prrace notices this here: https://github.com/openjdk/jdk/pull/5544#issuecomment-925396869. And I think it is the already open issue that this patch is fixing. While the original patch added the test in `jdk_other`, Phil suggests it to be added to `jdk_desktop`. > > Additional testing: > - [x] `jdk_editpad` is passing Anyhow, how do you want to proceed with this PR? ------------- PR: https://git.openjdk.java.net/jdk/pull/5648 From rreddy at openjdk.java.net Mon Oct 11 13:42:35 2021 From: rreddy at openjdk.java.net (Ravi Reddy) Date: Mon, 11 Oct 2021 13:42:35 GMT Subject: RFR: 8193682: Infinite loop in ZipOutputStream.close() [v2] In-Reply-To: References: Message-ID: > Hi all, > > Please review this fix for Infinite loop in ZipOutputStream.close(). > The main issue here is when ever there is an exception during close operations on GZip we are not setting the deflator to a finished state which is leading to an infinite loop when we try writing on the same GZip instance( since we use while(!def.finished()) inside the write operation). > > Thanks, > Ravi Ravi Reddy has updated the pull request incrementally with one additional commit since the last revision: 8193682 : Infinite loop in ZipOutputStream.close() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5522/files - new: https://git.openjdk.java.net/jdk/pull/5522/files/5072b6c1..f6a678ed Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5522&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5522&range=00-01 Stats: 96 lines in 2 files changed: 48 ins; 28 del; 20 mod Patch: https://git.openjdk.java.net/jdk/pull/5522.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5522/head:pull/5522 PR: https://git.openjdk.java.net/jdk/pull/5522 From rreddy at openjdk.java.net Mon Oct 11 13:46:11 2021 From: rreddy at openjdk.java.net (Ravi Reddy) Date: Mon, 11 Oct 2021 13:46:11 GMT Subject: RFR: 8193682: Infinite loop in ZipOutputStream.close() [v2] In-Reply-To: References: Message-ID: On Mon, 11 Oct 2021 13:42:35 GMT, Ravi Reddy wrote: >> Hi all, >> >> Please review this fix for Infinite loop in ZipOutputStream.close(). >> The main issue here is when ever there is an exception during close operations on GZip we are not setting the deflator to a finished state which is leading to an infinite loop when we try writing on the same GZip instance( since we use while(!def.finished()) inside the write operation). >> >> Thanks, >> Ravi > > Ravi Reddy has updated the pull request incrementally with one additional commit since the last revision: > > 8193682 : Infinite loop in ZipOutputStream.close() I have updated the review with the new fix. Instead of throwing an exception in close() method , Now when we get an exception during write inside deflate() , we will close the stream and throw the exception. Updated the test case in TestNG format. ------------- PR: https://git.openjdk.java.net/jdk/pull/5522 From paul.sandoz at oracle.com Mon Oct 11 16:20:55 2021 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 11 Oct 2021 16:20:55 +0000 Subject: RFR: 8274412: Add a method to Stream API to consume and close the stream without using try-with-resources In-Reply-To: References: Message-ID: Hi Tagir, Do you mind if we slow down on this and let the idea bake somewhat, captured in this thread/issue/PR(draft). I am always a little wary of compact-only or fluent-only methods, as I find them harder to justify. In this case I think there might be something more with regards to a pattern/idiom, and making it easier to not forgot to close. But, I am not sure we are there yet. - we have had this ?transform? idiom floating around for a while which is like your consumeAndClose, but without the try block. https://bugs.openjdk.java.net/browse/JDK-8140283 And such a method was added to String. There are likely other places where we could consider adding this idiom. - I think we should explore adding the method you propose on AutoCloseable, that likely has more leverage, but we would need to do some careful analysis of code to ensure the risk to incompatibly is low. The idioms ?transform? and ?transformAndClose? are I think related [*]. If we can nail down these I would feel much better about committing to them as methods on various classes. Paul. [*] If we ever get the notion of Haskell-like type classes in the platform I wonder if those would provide the hook, we could add later, that I am looking for so that we can corral these idioms. > On Oct 3, 2021, at 11:51 PM, Tagir F.Valeev wrote: > > Currently, when the stream holds a resource, it's necessary to wrap it with try-with-resources. This undermines the compact and fluent style of stream API calls. For example, if we want to get the `List` of files inside the directory and timely close the underlying filehandle, we should use something like this: > > > List paths; > try (Stream stream = Files.list(Path.of("/etc"))) { > paths = stream.toList(); > } > // use paths > > > I suggest to add a new default method to Stream interface named `consumeAndClose`, which allows performing terminal stream operation and closing the stream at the same time. It may look like this: > > > default R consumeAndClose(Function, ? extends R> function) { > Objects.requireNonNull(function); > try(this) { > return function.apply(this); > } > } > > > Now, it will be possible to get the list of the files in the fluent manner: > > > List list = Files.list(Path.of("/etc")).consumeAndClose(Stream::toList); > > ------------- > > Commit messages: > - Fix tests > - 8274412: Add a method to Stream API to consume and close the stream without using try-with-resources > > Changes: https://git.openjdk.java.net/jdk/pull/5796/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5796&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8274412 > Stats: 140 lines in 5 files changed: 135 ins; 0 del; 5 mod > Patch: https://git.openjdk.java.net/jdk/pull/5796.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/5796/head:pull/5796 > > PR: https://git.openjdk.java.net/jdk/pull/5796 From martin at openjdk.java.net Mon Oct 11 16:52:09 2021 From: martin at openjdk.java.net (Martin Buchholz) Date: Mon, 11 Oct 2021 16:52:09 GMT Subject: RFR: 8275002: Remove unused AbstractStringBuilder.MAX_ARRAY_SIZE In-Reply-To: <-vjB1Be5ZpM1cLYpnHh0Z2jy5iZGogUv_FawEGdv68U=.3b4ee0cf-2792-4d9a-aa26-1b5dc6180307@github.com> References: <-vjB1Be5ZpM1cLYpnHh0Z2jy5iZGogUv_FawEGdv68U=.3b4ee0cf-2792-4d9a-aa26-1b5dc6180307@github.com> Message-ID: On Sat, 9 Oct 2021 17:54:16 GMT, Andrey Turbanov wrote: > 8275002: Remove unused AbstractStringBuilder.MAX_ARRAY_SIZE JDK sources should not contain dead unused fields - thanks for fixing. The change to use newLength in this file should have adjusted the javadoc of newCapacity, perhaps simply to refer to ArraysSupport.SOFT_MAX_ARRAY_LENGTH instead. That sounds like a job for Jim Laskey as the author of commit 03642a01af7123298d6524a98c99a3934d35c11b Author: Jim Laskey Date: Thu Jun 11 10:08:23 2020 -0300 8230744: Several classes throw OutOfMemoryError without message Reviewed-by: psandoz, martin, bchristi, rriggs, smarks If that is fixed (perhaps in a different commit), then this commit is good. History has shown that capacity growth code is highly errorprone, so it's worth writing whitebox tests, as I did in e.g. ./java/util/concurrent/ConcurrentHashMap/WhiteBox.java ./java/util/ArrayDeque/WhiteBox.java ./java/util/HashMap/WhiteBoxResizeTest.java ------------- Marked as reviewed by martin (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5878 From naoto at openjdk.java.net Mon Oct 11 18:31:56 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 11 Oct 2021 18:31:56 GMT Subject: RFR: 8273111: Default timezone should return zone ID if /etc/localtime is valid but not canonicalization on linux [v2] In-Reply-To: References: <6gmVj3r1hjhG5jvo_dSly3ShNnZZSCn-NIjtnvSySrk=.a88def27-7b80-425b-9ab8-2f94f5004b47@github.com> Message-ID: On Thu, 9 Sep 2021 08:25:44 GMT, Wu Yan wrote: >> Hi, >> Please help me review the change to enhance getting time zone ID from /etc/localtime on linux. >> >> We use `realpath` instead of `readlink` to obtain the link name of /etc/localtime, because `readlink` can only read the value of a symbolic of link, not the canonicalized absolute pathname. >> >> For example, the value of /etc/localtime is "../usr/share/zoneinfo//Asia/Shanghai", then the linkbuf obtained by `readlink` is "../usr/share/zoneinfo//Asia/Shanghai", and then the call of `getZoneName(linkbuf)` will get "/Asia/Shanghai", not "Asia/Shanghai", which consider as invalid in `ZoneInfoFile.getZoneInfo()`. Using `realpath`, you can get ?/usr/share/zoneinfo/Asia/Shanghai? directly from ?/etc/localtime?. >> >> Thanks, >> wuyan > > Wu Yan has updated the pull request incrementally with one additional commit since the last revision: > > replace realpath src/java.base/unix/native/libjava/TimeZone_md.c line 113: > 111: } > 112: } > 113: There are a few `*(right + 1)` references in the loops. Is there any possibility that it would run over the buffer? src/java.base/unix/native/libjava/path_util.h line 31: > 29: int collapsible(char *names); > 30: void splitNames(char *names, char **ix); > 31: void joinNames(char *names, int nc, char **ix); Are these functions, `collapsible`, `splitNames` and `joinNames` have to be non-static? ------------- PR: https://git.openjdk.java.net/jdk/pull/5327 From john.r.rose at oracle.com Mon Oct 11 18:42:20 2021 From: john.r.rose at oracle.com (John Rose) Date: Mon, 11 Oct 2021 18:42:20 +0000 Subject: RFR: 8274412: Add a method to Stream API to consume and close the stream without using try-with-resources In-Reply-To: References: Message-ID: <3E9388AF-CADF-47C5-9DAD-479F44908129@oracle.com> So the purpose of TWR is to hold an object with a ?close-debt? (debt of a future call to close) and pay it at the end of a block, sort of like C++ RAII (but also sort of not). But fluent syntaxes (which I like very much and hope to see more of in the future!) don?t play well with blocks, so if a fluent chain (any part of that chain: It?s multiple objects) incurs a ?close-debt?, it?s hard to jam a TWR block into it. Hence the current proposal. I agree with Brian and Paul that we haven?t examined all the corners of this problem yet. And I?d like to poke at the concept of ?close-debt? to help with the examination. Just for brain storming, I think we could model ?close-debt? outside either fluent API structure or TWR block structure. Java O-O APIs are the pre-eminent way to model things in Java, and they work exceedingly well, when used with skill. AutoCloseable models close-debt of course. But it has two weaknesses: It doesn?t model anything *other* than the debt, and its (sole) method skates awkwardly around the issue of checked exceptions. (It requires an override with exception type narrowing to be used in polite company.) AC is more of an integration hook with TWR, rather than a general-purpose model for close-debt. Therefore it doesn?t teach us much about close-debt in a fluent setting. Surely we can model close-debt better. Let?s say that an operation (expression) with close-debt *also* has a return value and (for grins) *also* has an exception it might throw. This gets us to an API closer to Optional. (If you hear the noise of a monad snuffling around in the dark outside your tent, you are not wrong.) interface MustClose_1 { T get() throws X; //or could throw some Y or nothing at all void close() throws X; } (I wish we had an easier way to associate such an X with such a T, so that Stream could be more interoperable with simple Stream. It?s a pain to carry around those X arguments. So I?ll drop X now.) interface MustClose_2 { T get(); void close() throws Exception; } An expression of this type requires (in general) two operations to finish up: It must be closed, and the result (type T) must be gotten. There?s an issue of coupling between the two methods; I would say, decouple their order, so that the ?get? call, as with Optional, can be done any time, and the ?close? call can be done in any order relative to ?get?. Both calls should be idempotent, I think. But that?s all second-order detail. A first-order detail is the apparent but incorrect 1-1 relation between T values and close-debts. That?s very wrong; a closable stream on 1,000 values has one close-debt, not 1,000. So maybe we need: interface MustClose_3 { S map(Function value); void close() throws Exception; } That ?map? method looks a little like Remi?s apply method. Did I mention this design requires skill (as well as flexibility, with one hand already tied by checked exceptions)? I?m at the edge of my own skill here, but I think there?s good ground to explore here. In a fluent setting, a Stream that incurs a close-debt might be typed (after incurring the debt, perhaps in a transform) as Stream>, and somehow all consumers of the MustClose, such as map and collect operations on the Stream, would correctly unpack each T from the MC, and then repack the result into the MC<.> wrapper. var res = openAFileStream().map(?).collect(?); Here the first method call returns a Stream with close-debt mixed into its type. The map and collect calls would wire both parts: The T values flowing through, and the close-debt. Who takes responsibility for paying the close debt? Maybe an extra call at the end: ?map(?).collectAndClose(?). Or maybe the stream ?knows? internally that since its type has a close debt, all of its terminal operations have to pay off that debt as they collect the payloads. So it would be automatic, somehow, inside of collect, forEach, etc. To make the parts hook up right, you might need reified generics, or maybe an amended type MustCloseStream <: Stream>, like the LongStream <: Stream we dislike. I?m only proposing as a thought exercise for now. Maybe the MustCloseStream takes an explicit close method which produces a regular stream over the base type. The explicit close method would release resources and buffer anything necessary to produce an in-memory Stream. You?d want to call it late in the fluent chain, after filtering and flat-mapping is done, just before a collect for forEach. Here?s a streamlined version of MustClose that I like, which sidesteps the problem of mutual ordering of two methods: interface MustClose_4 { R getAndClose() throws Exception; default void close() throws Exception { getAndClose(); } } Here, R is not an element type of a stream, but rather the final result (maybe Void) of some terminal operation. Such an interface could interact with syntax, too. For example, it might help with TWR expressions (if we wanted to think about that): var res = try (expr); // sugar for: X res; try (MustClose_4 $t = expr) { res = $t.getAndClose(); }; It might help with other auto-close notations or APIs we could cook up. For example, suppose ?var x=y? were artificially restricted from inferring a MustClose type from y onto var x. Instead, the var type would be inferred as T, and a getAndClose call would be added to the initializer (y) to unwrap the value before binding to x. Perhaps that would stretch ?var? too far; maybe we would choose to mark such ?var?s specially, as ?try var x = y;?. My point here is that an O-O model of close-debt as a wrapper for other computations is helpful for evaluating our options. (Another kind of wrapper for try-var would be an exception wrapper, a direct-sum thingy which holds *either* a normal T result or an exceptional X result. That could model things we don?t have good models for today. In ?try var x = y;? if y is of type ValueOrException, then var would be inferred from T, and any X present would pop out when the initializer were executed. You could use such a type, and such a notation, to more easily wire exceptions through all sorts of combinators where exceptions are not welcome today.) To summarize: We can (and should) try to model ?close-debt? using interfaces. Doing so opens up the usual cans of worms with interoperability and exceptions, but still gives us a model we can contemplate. We can (and should) contemplate how such a model would give us leverage for further syntax sugar and/or combinatorial API points for handling close-debt at various points in the language and our APIs. From duke at openjdk.java.net Mon Oct 11 18:52:07 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Mon, 11 Oct 2021 18:52:07 GMT Subject: RFR: 8275002: Remove unused AbstractStringBuilder.MAX_ARRAY_SIZE [v2] In-Reply-To: <-vjB1Be5ZpM1cLYpnHh0Z2jy5iZGogUv_FawEGdv68U=.3b4ee0cf-2792-4d9a-aa26-1b5dc6180307@github.com> References: <-vjB1Be5ZpM1cLYpnHh0Z2jy5iZGogUv_FawEGdv68U=.3b4ee0cf-2792-4d9a-aa26-1b5dc6180307@github.com> Message-ID: > 8275002: Remove unused AbstractStringBuilder.MAX_ARRAY_SIZE Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 275002: Remove unused AbstractStringBuilder.MAX_ARRAY_SIZE update javadoc of 'newCapacity' method to refer ArraysSupport.SOFT_MAX_ARRAY_LENGTH instead ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5878/files - new: https://git.openjdk.java.net/jdk/pull/5878/files/d679bd3a..4ba785b3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5878&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5878&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5878.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5878/head:pull/5878 PR: https://git.openjdk.java.net/jdk/pull/5878 From duke at openjdk.java.net Mon Oct 11 18:52:17 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Mon, 11 Oct 2021 18:52:17 GMT Subject: RFR: 8275002: Remove unused AbstractStringBuilder.MAX_ARRAY_SIZE [v2] In-Reply-To: References: <-vjB1Be5ZpM1cLYpnHh0Z2jy5iZGogUv_FawEGdv68U=.3b4ee0cf-2792-4d9a-aa26-1b5dc6180307@github.com> Message-ID: On Sun, 10 Oct 2021 22:13:29 GMT, Sergey Bylokhov wrote: >> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: >> >> 275002: Remove unused AbstractStringBuilder.MAX_ARRAY_SIZE >> update javadoc of 'newCapacity' method to refer ArraysSupport.SOFT_MAX_ARRAY_LENGTH instead > > src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 240: > >> 238: * OutOfMemoryError: Requested array size exceeds VM limit >> 239: */ >> 240: private static final int MAX_ARRAY_SIZE = Integer.MAX_VALUE - 8; > > Looks like the usage of this field was removed by the https://github.com/openjdk/lanai/commit/03642a01, note that the doc for the "newCapacity" is still mentioned this field. doc updated ------------- PR: https://git.openjdk.java.net/jdk/pull/5878 From prappo at openjdk.java.net Mon Oct 11 19:02:21 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Mon, 11 Oct 2021 19:02:21 GMT Subject: RFR: 8275002: Remove unused AbstractStringBuilder.MAX_ARRAY_SIZE [v2] In-Reply-To: References: <-vjB1Be5ZpM1cLYpnHh0Z2jy5iZGogUv_FawEGdv68U=.3b4ee0cf-2792-4d9a-aa26-1b5dc6180307@github.com> Message-ID: On Mon, 11 Oct 2021 18:52:07 GMT, Andrey Turbanov wrote: >> 8275002: Remove unused AbstractStringBuilder.MAX_ARRAY_SIZE > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 275002: Remove unused AbstractStringBuilder.MAX_ARRAY_SIZE > update javadoc of 'newCapacity' method to refer ArraysSupport.SOFT_MAX_ARRAY_LENGTH instead I'll run tests; if they pass, I'll sponsor the change. ------------- PR: https://git.openjdk.java.net/jdk/pull/5878 From forax at univ-mlv.fr Mon Oct 11 19:35:49 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 11 Oct 2021 21:35:49 +0200 (CEST) Subject: RFR: 8274412: Add a method to Stream API to consume and close the stream without using try-with-resources In-Reply-To: <3E9388AF-CADF-47C5-9DAD-479F44908129@oracle.com> References: <3E9388AF-CADF-47C5-9DAD-479F44908129@oracle.com> Message-ID: <878938156.599857.1633980949563.JavaMail.zimbra@u-pem.fr> I agree with the idea of a try() syntax, but i don't think we need more interfaces. Yes, John is right about the fact that the TWR Aucloseable does not work well with checked exceptions, but the issue is more that there is nothing that works well with checked exceptions because Java has no way to compose them correctly (remainder: we should remove the idea of checked exceptions from the language given that it's a backward compatible change and Kotlin, C# are safer than Java because users of those languages are not used to write a try/catch/printStackTrace in those languages unlike in Java). So for me, AutoCloseable is enough. The problem is more than a fluent API are expression oriented and a try-with-resources is statement oriented, hence the mismatch. Like we have introduced the switch expression, here we need a try-with-resources expression. There are good reasons to have a try-with-resources expression 1) it can be used to track a fluent chain that should close() the resources 2) the compiler can guarantee that the stream/reader/etc around the resources does not leak outside. In term of syntax, i don't think that the arrow syntax (the one used for a case of a switch case or a lambda) should be used here, because using a block expression seems to be always a mistake. I like the proposal from John, a try(expression) or a try expression (without the parenthesis). regards, R?mi ----- Original Message ----- > From: "John Rose" > To: "Paul Sandoz" , "Brian Goetz" , "Tagir F.Valeev" > > Cc: "core-libs-dev" > Sent: Lundi 11 Octobre 2021 20:42:20 > Subject: Re: RFR: 8274412: Add a method to Stream API to consume and close the stream without using try-with-resources > So the purpose of TWR is to hold an object with a ?close-debt? > (debt of a future call to close) and pay it at the end of a block, > sort of like C++ RAII (but also sort of not). > > But fluent syntaxes (which I like very much and hope to see > more of in the future!) don?t play well with blocks, so if a > fluent chain (any part of that chain: It?s multiple objects) > incurs a ?close-debt?, it?s hard to jam a TWR block into it. > > Hence the current proposal. I agree with Brian and Paul > that we haven?t examined all the corners of this problem > yet. And I?d like to poke at the concept of ?close-debt? to > help with the examination. > > Just for brain storming, I think we could model ?close-debt? > outside either fluent API structure or TWR block structure. > Java O-O APIs are the pre-eminent way to model things in > Java, and they work exceedingly well, when used with skill. > > AutoCloseable models close-debt of course. But it has two > weaknesses: It doesn?t model anything *other* than the > debt, and its (sole) method skates awkwardly around the > issue of checked exceptions. (It requires an override with > exception type narrowing to be used in polite company.) > AC is more of an integration hook with TWR, rather than > a general-purpose model for close-debt. Therefore it doesn?t > teach us much about close-debt in a fluent setting. > > Surely we can model close-debt better. Let?s say that an > operation (expression) with close-debt *also* has a return > value and (for grins) *also* has an exception it might throw. > This gets us to an API closer to Optional. (If you hear the > noise of a monad snuffling around in the dark outside > your tent, you are not wrong.) > > interface MustClose_1 { > T get() throws X; //or could throw some Y or nothing at all > void close() throws X; > } > > (I wish we had an easier way to associate such an X > with such a T, so that Stream could be more > interoperable with simple Stream. It?s a pain to > carry around those X arguments. So I?ll drop X now.) > > interface MustClose_2 { > T get(); > void close() throws Exception; > } > > An expression of this type requires (in general) two > operations to finish up: It must be closed, and the result > (type T) must be gotten. There?s an issue of coupling between > the two methods; I would say, decouple their order, so that > the ?get? call, as with Optional, can be done any time, > and the ?close? call can be done in any order relative > to ?get?. Both calls should be idempotent, I think. > But that?s all second-order detail. > > A first-order detail is the apparent but incorrect 1-1 relation > between T values and close-debts. That?s very wrong; > a closable stream on 1,000 values has one close-debt, > not 1,000. So maybe we need: > > interface MustClose_3 { > S map(Function value); > void close() throws Exception; > } > > That ?map? method looks a little like Remi?s apply > method. Did I mention this design requires skill > (as well as flexibility, with one hand already tied > by checked exceptions)? I?m at the edge of my own > skill here, but I think there?s good ground to explore > here. > > In a fluent setting, a Stream that incurs a close-debt > might be typed (after incurring the debt, perhaps in a > transform) as Stream>, and somehow > all consumers of the MustClose, such as map and > collect operations on the Stream, would correctly > unpack each T from the MC, and then repack > the result into the MC<.> wrapper. > > var res = openAFileStream().map(?).collect(?); > > Here the first method call returns a Stream with > close-debt mixed into its type. The map and collect > calls would wire both parts: The T values flowing > through, and the close-debt. Who takes responsibility > for paying the close debt? Maybe an extra call > at the end: ?map(?).collectAndClose(?). > Or maybe the stream ?knows? internally that since > its type has a close debt, all of its terminal operations > have to pay off that debt as they collect the payloads. > So it would be automatic, somehow, inside of > collect, forEach, etc. > > To make the parts hook up right, you might need > reified generics, or maybe an amended type > MustCloseStream <: Stream>, > like the LongStream <: Stream we dislike. > I?m only proposing as a thought exercise for now. > > Maybe the MustCloseStream takes an explicit close > method which produces a regular stream over the > base type. The explicit close method would release > resources and buffer anything necessary to produce > an in-memory Stream. You?d want to call it > late in the fluent chain, after filtering and flat-mapping > is done, just before a collect for forEach. > > Here?s a streamlined version of MustClose that > I like, which sidesteps the problem of mutual ordering > of two methods: > > interface MustClose_4 { > R getAndClose() throws Exception; > default void close() throws Exception { getAndClose(); } > } > > Here, R is not an element type of a stream, but rather > the final result (maybe Void) of some terminal operation. > > Such an interface could interact with syntax, too. For > example, it might help with TWR expressions (if we > wanted to think about that): > > var res = try (expr); > // sugar for: > X res; try (MustClose_4 $t = expr) { res = $t.getAndClose(); }; > > It might help with other auto-close notations or APIs we could > cook up. For example, suppose ?var x=y? were artificially restricted > from inferring a MustClose type from y onto var x. Instead, > the var type would be inferred as T, and a getAndClose call would > be added to the initializer (y) to unwrap the value before binding > to x. Perhaps that would stretch ?var? too far; maybe we would > choose to mark such ?var?s specially, as ?try var x = y;?. My > point here is that an O-O model of close-debt as a wrapper for > other computations is helpful for evaluating our options. > > (Another kind of wrapper for try-var would be an exception > wrapper, a direct-sum thingy which holds *either* a normal > T result or an exceptional X result. That could model things > we don?t have good models for today. In ?try var x = y;? if > y is of type ValueOrException, then var would be inferred > from T, and any X present would pop out when the initializer > were executed. You could use such a type, and such a notation, > to more easily wire exceptions through all sorts of combinators > where exceptions are not welcome today.) > > To summarize: We can (and should) try to model ?close-debt? > using interfaces. Doing so opens up the usual cans of worms > with interoperability and exceptions, but still gives us a > model we can contemplate. We can (and should) contemplate > how such a model would give us leverage for further syntax > sugar and/or combinatorial API points for handling close-debt > at various points in the language and our APIs. From phh at openjdk.java.net Mon Oct 11 20:16:00 2021 From: phh at openjdk.java.net (Paul Hohensee) Date: Mon, 11 Oct 2021 20:16:00 GMT Subject: RFR: 8271737: Only normalize the cached user.dir property once In-Reply-To: References: Message-ID: On Thu, 7 Oct 2021 14:05:19 GMT, Evgeny Astigeevich wrote: > The change completes the fix of [JDK-8198997](https://bugs.openjdk.java.net/browse/JDK-8198997) which has added normalisation in a constructor but not removed it from the get method. Lgtm. ------------- Marked as reviewed by phh (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5850 From martin at openjdk.java.net Mon Oct 11 20:45:56 2021 From: martin at openjdk.java.net (Martin Buchholz) Date: Mon, 11 Oct 2021 20:45:56 GMT Subject: RFR: 8275002: Remove unused AbstractStringBuilder.MAX_ARRAY_SIZE [v2] In-Reply-To: References: <-vjB1Be5ZpM1cLYpnHh0Z2jy5iZGogUv_FawEGdv68U=.3b4ee0cf-2792-4d9a-aa26-1b5dc6180307@github.com> Message-ID: On Mon, 11 Oct 2021 18:52:07 GMT, Andrey Turbanov wrote: >> 8275002: Remove unused AbstractStringBuilder.MAX_ARRAY_SIZE > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 275002: Remove unused AbstractStringBuilder.MAX_ARRAY_SIZE > update javadoc of 'newCapacity' method to refer ArraysSupport.SOFT_MAX_ARRAY_LENGTH instead We generally avoid in javadoc. Especially in private javadoc. I would write this more simply/readably as * {@code SOFT_MAX_ARRAY_LENGTH >> coder} ------------- Marked as reviewed by martin (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5878 From mchung at openjdk.java.net Mon Oct 11 21:04:15 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 11 Oct 2021 21:04:15 GMT Subject: RFR: JDK-8274848: LambdaMetaFactory::metafactory on REF_invokeSpecial impl method has incorrect behavior Message-ID: Classes compiled prior to the nestmate support will generate `REF_invokeSpecial` if the implementation method is a private instance method. Since a lambda proxy class is a hidden class, a nestmate of the host class, it can invoke the private implementation method but it has to use `REF_invokeVirtual` or `REF_invokeInterface`. In order to support the old classes running on the new runtime, LMF implementation adjusts the reference kind from `REF_invokeSpecial` to `REF_invokeVirtual/REF_invokeInterface`. This PR fixes the check properly to ensure the adjustment is only made if the implementation method is private method in the host class. ------------- Commit messages: - JDK-8274848: LambdaMetaFactory::metafactory on REF_invokeSpecial impl method has incorrect behavior Changes: https://git.openjdk.java.net/jdk/pull/5901/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5901&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274848 Stats: 379 lines in 4 files changed: 378 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5901.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5901/head:pull/5901 PR: https://git.openjdk.java.net/jdk/pull/5901 From duke at openjdk.java.net Mon Oct 11 21:07:21 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Mon, 11 Oct 2021 21:07:21 GMT Subject: RFR: 8275002: Remove unused AbstractStringBuilder.MAX_ARRAY_SIZE [v3] In-Reply-To: <-vjB1Be5ZpM1cLYpnHh0Z2jy5iZGogUv_FawEGdv68U=.3b4ee0cf-2792-4d9a-aa26-1b5dc6180307@github.com> References: <-vjB1Be5ZpM1cLYpnHh0Z2jy5iZGogUv_FawEGdv68U=.3b4ee0cf-2792-4d9a-aa26-1b5dc6180307@github.com> Message-ID: > 8275002: Remove unused AbstractStringBuilder.MAX_ARRAY_SIZE Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8275002: Remove unused AbstractStringBuilder.MAX_ARRAY_SIZE avoid link in private javadoc ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5878/files - new: https://git.openjdk.java.net/jdk/pull/5878/files/4ba785b3..d35afde5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5878&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5878&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5878.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5878/head:pull/5878 PR: https://git.openjdk.java.net/jdk/pull/5878 From duke at openjdk.java.net Mon Oct 11 21:08:49 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Mon, 11 Oct 2021 21:08:49 GMT Subject: RFR: 8274879: Replace uses of StringBuffer with StringBuilder within java.base classes In-Reply-To: References: Message-ID: On Thu, 7 Oct 2021 16:48:06 GMT, Naoto Sato wrote: >> StringBuffer is a legacy synchronized class. There are more modern alternatives which perform better: >> 1. Plain String concatenation should be preferred >> 2. StringBuilder is a direct replacement to StringBuffer which generally have better performance >> >> In [JDK-8264029](https://bugs.openjdk.java.net/browse/JDK-8264029) I migrated only usages which were automatically detected by IDEA. It turns out there are more usages which can be migrated. > > src/java.base/share/classes/java/lang/Character.java line 123: > >> 121: * than U+FFFF are called supplementary characters. The Java >> 122: * platform uses the UTF-16 representation in {@code char} arrays and >> 123: * in the {@code String} and {@code StringBuilder} classes. In > > Not sure simple replacement applies here, as `StringBuffer` still uses `UTF-16` representation. You may add `StringBuilder` as well here, but I think you might want to file a CSR to clarify. reverted changes in this spec. ------------- PR: https://git.openjdk.java.net/jdk/pull/5432 From sundar at openjdk.java.net Tue Oct 12 02:38:48 2021 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Tue, 12 Oct 2021 02:38:48 GMT Subject: RFR: 8273682: Upgrade Jline to 3.20.0 In-Reply-To: References: Message-ID: On Thu, 23 Sep 2021 14:43:21 GMT, Jan Lahoda wrote: > I'd like to upgrade the internal JLine to 3.20.0, to support the rxvt terminal (see JDK-8270943), and to generally use a newer version of the library. This patch is basically a application of relevant parts of the diff between JLine 3.14.0 and 3.20.0, with merge fixes as needed. > > Thanks! LGTM src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/CompletionMatcher.java line 32: > 30: * > 31: * @param candidates list of candidates > 32: * @return a map of candidates that completion matcher matches a list of ..? src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/EndOfFileException.java line 2: > 1: /* > 2: * Copyright (c) 2002-2020, the original author or authors. 2021 ------------- Marked as reviewed by sundar (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5655 From serb at openjdk.java.net Tue Oct 12 07:08:52 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 12 Oct 2021 07:08:52 GMT Subject: RFR: 8177814: jdk/editpad is not in jdk TEST.groups In-Reply-To: References: Message-ID: On Thu, 23 Sep 2021 08:54:48 GMT, Aleksey Shipilev wrote: > @prrace notices this here: https://github.com/openjdk/jdk/pull/5544#issuecomment-925396869. And I think it is the already open issue that this patch is fixing. While the original patch added the test in `jdk_other`, Phil suggests it to be added to `jdk_desktop`. > > Additional testing: > - [x] `jdk_editpad` is passing Let's fix it this way ------------- Marked as reviewed by serb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5648 From serb at openjdk.java.net Tue Oct 12 07:10:48 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 12 Oct 2021 07:10:48 GMT Subject: RFR: 8268764: Use Long.hashCode() instead of int-cast where applicable [v4] In-Reply-To: References: Message-ID: On Thu, 1 Jul 2021 12:19:53 GMT, ?????? ??????? wrote: >> In some JDK classes there's still the following hashCode() implementation: >> >> long objNum; >> >> public int hashCode() { >> return (int) objNum; >> } >> >> This outdated expression should be replaced with Long.hashCode(long) as it >> >> - uses all bits of the original value, does not discard any information upfront. For example, depending on how you are generating the IDs, the upper bits could change more frequently (or the opposite). >> >> - does not introduce any bias towards values with more ones (zeros), as it would be the case if the two halves were combined with an OR (AND) operation. >> >> See https://stackoverflow.com/a/4045083 >> >> This is related to https://github.com/openjdk/jdk/pull/4309 > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8268764: Update copy-right year Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4491 From shade at openjdk.java.net Tue Oct 12 07:27:52 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 12 Oct 2021 07:27:52 GMT Subject: RFR: 8177814: jdk/editpad is not in jdk TEST.groups In-Reply-To: References: Message-ID: On Thu, 23 Sep 2021 08:54:48 GMT, Aleksey Shipilev wrote: > @prrace notices this here: https://github.com/openjdk/jdk/pull/5544#issuecomment-925396869. And I think it is the already open issue that this patch is fixing. While the original patch added the test in `jdk_other`, Phil suggests it to be added to `jdk_desktop`. > > Additional testing: > - [x] `jdk_editpad` is passing Ok, thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/5648 From shade at openjdk.java.net Tue Oct 12 07:27:52 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 12 Oct 2021 07:27:52 GMT Subject: Integrated: 8177814: jdk/editpad is not in jdk TEST.groups In-Reply-To: References: Message-ID: On Thu, 23 Sep 2021 08:54:48 GMT, Aleksey Shipilev wrote: > @prrace notices this here: https://github.com/openjdk/jdk/pull/5544#issuecomment-925396869. And I think it is the already open issue that this patch is fixing. While the original patch added the test in `jdk_other`, Phil suggests it to be added to `jdk_desktop`. > > Additional testing: > - [x] `jdk_editpad` is passing This pull request has now been integrated. Changeset: cfe7471f Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/cfe7471f1769eca2a4e623f5ba9cddceb005f0bf Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod 8177814: jdk/editpad is not in jdk TEST.groups Reviewed-by: serb ------------- PR: https://git.openjdk.java.net/jdk/pull/5648 From prappo at openjdk.java.net Tue Oct 12 09:41:54 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 12 Oct 2021 09:41:54 GMT Subject: RFR: 8275002: Remove unused AbstractStringBuilder.MAX_ARRAY_SIZE [v3] In-Reply-To: References: <-vjB1Be5ZpM1cLYpnHh0Z2jy5iZGogUv_FawEGdv68U=.3b4ee0cf-2792-4d9a-aa26-1b5dc6180307@github.com> Message-ID: On Mon, 11 Oct 2021 21:07:21 GMT, Andrey Turbanov wrote: >> 8275002: Remove unused AbstractStringBuilder.MAX_ARRAY_SIZE > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8275002: Remove unused AbstractStringBuilder.MAX_ARRAY_SIZE > avoid link in private javadoc Marked as reviewed by prappo (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5878 From duke at openjdk.java.net Tue Oct 12 09:41:55 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Tue, 12 Oct 2021 09:41:55 GMT Subject: Integrated: 8275002: Remove unused AbstractStringBuilder.MAX_ARRAY_SIZE In-Reply-To: <-vjB1Be5ZpM1cLYpnHh0Z2jy5iZGogUv_FawEGdv68U=.3b4ee0cf-2792-4d9a-aa26-1b5dc6180307@github.com> References: <-vjB1Be5ZpM1cLYpnHh0Z2jy5iZGogUv_FawEGdv68U=.3b4ee0cf-2792-4d9a-aa26-1b5dc6180307@github.com> Message-ID: <2WbdIqd-HNSxtYgI3ZCeoSCTFkocRd2HNfnTmsypGFo=.4c1ed8cc-3004-4449-bd33-b7464ad3a070@github.com> On Sat, 9 Oct 2021 17:54:16 GMT, Andrey Turbanov wrote: > 8275002: Remove unused AbstractStringBuilder.MAX_ARRAY_SIZE This pull request has now been integrated. Changeset: 7d2633f7 Author: Andrey Turbanov Committer: Pavel Rappo URL: https://git.openjdk.java.net/jdk/commit/7d2633f795c27edc2dfbbd7a9d9e44bdb23ec6a1 Stats: 10 lines in 1 file changed: 0 ins; 8 del; 2 mod 8275002: Remove unused AbstractStringBuilder.MAX_ARRAY_SIZE Reviewed-by: prappo, jlaskey, martin ------------- PR: https://git.openjdk.java.net/jdk/pull/5878 From takiguc at linux.vnet.ibm.com Tue Oct 12 09:44:53 2021 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Tue, 12 Oct 2021 18:44:53 +0900 Subject: Questions for JDK-4947890 Message-ID: <9a0af925508046149fca001c8912c2b5@imap.linux.ibm.com> I have some questions for JDK-4947890? One of app?s JVM was upgraded from JDK11 to JDK17. Then the working behavior was changed on Windows 10 Multilingual User Interface (MUI). (Base was Japanese Windows 10, display language setting was English (United States)) In my investigation, the working behavior was changed by JDK12+b23. JDK-4947890 Minimize JNI upcalls in system-properties initialization [1] Following change was applied on src/java.base/share/native/libjava/System.c, From (not for MacOS platform) [2] Put sprops->sun_jnu_encoding into file.encoding system property To [3] Put sprops->encoding into file.encoding system property I checked JDK-4947890?s CSR JDK-8213895 [4] Modify JVM interface functions for property initialization But it seems that above CSR does not mention such a significant specification change. I checked JDK17u, same code was still used [5]. Questions: I?d like to confirm * This change was intentional or not ? * We can revert tp JDK11?s spec ? Thanks, Ichiroh Takiguchi [1] https://bugs.openjdk.java.net/browse/JDK-4947890 [2] http://hg.openjdk.java.net/jdk/jdk/rev/0bdbf854472f#l12.466 [3] http://hg.openjdk.java.net/jdk/jdk/rev/0bdbf854472f#l12.276 [4] https://bugs.openjdk.java.net/browse/JDK-8213895 [5] https://github.com/openjdk/jdk17u/blob/master/src/java.base/share/native/libjava/System.c#L149 From alanb at openjdk.java.net Tue Oct 12 10:24:50 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 12 Oct 2021 10:24:50 GMT Subject: RFR: JDK-8274848: LambdaMetaFactory::metafactory on REF_invokeSpecial impl method has incorrect behavior In-Reply-To: References: Message-ID: <-sS70f6ea7-T3dwih_VYAaBVEpYeeEufiaKELuh7jsI=.0dc187e3-00f8-4152-a06d-8a7a33b75c50@github.com> On Mon, 11 Oct 2021 20:55:23 GMT, Mandy Chung wrote: > Classes compiled prior to the nestmate support will generate `REF_invokeSpecial` if the implementation method is a private instance method. Since a lambda proxy class is a hidden class, a nestmate of the host class, it can invoke the private implementation method but it has to use `REF_invokeVirtual` or `REF_invokeInterface`. In order to support the old classes running on the new runtime, LMF implementation adjusts the reference kind from `REF_invokeSpecial` to `REF_invokeVirtual/REF_invokeInterface`. > > This PR fixes the check properly to ensure the adjustment is only made if the implementation method is private method in the host class. filelist line 1: > 1: test/jdk/java/lang/invoke/lambda/invokeSpecial/InvokeSpecialMethodImpl.java I assume "filelist" is not meant to be in this match, I assume this is why the "jdk" label was added. ------------- PR: https://git.openjdk.java.net/jdk/pull/5901 From jboes at openjdk.java.net Tue Oct 12 10:40:15 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Tue, 12 Oct 2021 10:40:15 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v9] In-Reply-To: References: Message-ID: > This change implements a simple web server that can be run on the command-line with `java -m jdk.httpserver`. > > This is facilitated by adding an entry point for the `jdk.httpserver` module, an implementation class whose main method is run when the above command is executed. This is the first such module entry point in the JDK. > > The server is a minimal HTTP server that serves the static files of a given directory, similar to existing alternatives on other platforms and convenient for testing, development, and debugging. > > Additionally, a small API is introduced for programmatic creation and customization. > > Testing: tier1-3. Julia Boes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits: - Minor rewording of bind address output - Merge branch 'master' into simpleserver - Merge branch 'master' into simpleserver - update output for all interfaces - use ipv4/ipv6 specific loopback address and add add how-to output for all interfaces - Merge branch 'master' into simpleserver - change default bind address from anylocal to loopback - address PR comments - Merge branch 'master' into simpleserver - Merge remote-tracking branch 'origin/simpleserver' into simpleserver - ... and 14 more: https://git.openjdk.java.net/jdk/compare/b1b66965...e86609d0 ------------- Changes: https://git.openjdk.java.net/jdk/pull/5505/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5505&range=08 Stats: 7181 lines in 42 files changed: 7146 ins; 15 del; 20 mod Patch: https://git.openjdk.java.net/jdk/pull/5505.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5505/head:pull/5505 PR: https://git.openjdk.java.net/jdk/pull/5505 From rreddy at openjdk.java.net Tue Oct 12 13:28:21 2021 From: rreddy at openjdk.java.net (Ravi Reddy) Date: Tue, 12 Oct 2021 13:28:21 GMT Subject: RFR: 8193682: Infinite loop in ZipOutputStream.close() [v3] In-Reply-To: References: Message-ID: > Hi all, > > Please review this fix for Infinite loop in ZipOutputStream.close(). > The main issue here is when ever there is an exception during close operations on GZip we are not setting the deflator to a finished state which is leading to an infinite loop when we try writing on the same GZip instance( since we use while(!def.finished()) inside the write operation). > > Thanks, > Ravi Ravi Reddy has updated the pull request incrementally with one additional commit since the last revision: 8193682 : Infinite loop in ZipOutputStream.close() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5522/files - new: https://git.openjdk.java.net/jdk/pull/5522/files/f6a678ed..d18eb3c1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5522&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5522&range=01-02 Stats: 46 lines in 1 file changed: 44 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5522.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5522/head:pull/5522 PR: https://git.openjdk.java.net/jdk/pull/5522 From duke at openjdk.java.net Tue Oct 12 14:14:51 2021 From: duke at openjdk.java.net (jmehrens) Date: Tue, 12 Oct 2021 14:14:51 GMT Subject: RFR: 8193682: Infinite loop in ZipOutputStream.close() [v3] In-Reply-To: References: Message-ID: On Tue, 12 Oct 2021 13:28:21 GMT, Ravi Reddy wrote: >> Hi all, >> >> Please review this fix for Infinite loop in ZipOutputStream.close(). >> The main issue here is when ever there is an exception during close operations on GZip we are not setting the deflator to a finished state which is leading to an infinite loop when we try writing on the same GZip instance( since we use while(!def.finished()) inside the write operation). >> >> Thanks, >> Ravi > > Ravi Reddy has updated the pull request incrementally with one additional commit since the last revision: > > 8193682 : Infinite loop in ZipOutputStream.close() src/java.base/share/classes/java/util/zip/DeflaterOutputStream.java line 252: > 250: int len = def.deflate(buf, 0, buf.length); > 251: if (len > 0) { > 252: try { Shouldn't this use try with resources: try (out) { ... src/java.base/share/classes/java/util/zip/DeflaterOutputStream.java line 254: > 252: try { > 253: out.write(buf, 0, len); > 254: } catch (Exception e) { Shouldn't this be a finally block? src/java.base/share/classes/java/util/zip/DeflaterOutputStream.java line 256: > 254: } catch (Exception e) { > 255: def.end(); > 256: out.close(); out.close not needed with try with resources. ------------- PR: https://git.openjdk.java.net/jdk/pull/5522 From coffeys at openjdk.java.net Tue Oct 12 14:39:51 2021 From: coffeys at openjdk.java.net (Sean Coffey) Date: Tue, 12 Oct 2021 14:39:51 GMT Subject: RFR: 8193682: Infinite loop in ZipOutputStream.close() [v3] In-Reply-To: References: Message-ID: On Tue, 12 Oct 2021 14:10:53 GMT, jmehrens wrote: >> Ravi Reddy has updated the pull request incrementally with one additional commit since the last revision: >> >> 8193682 : Infinite loop in ZipOutputStream.close() > > src/java.base/share/classes/java/util/zip/DeflaterOutputStream.java line 252: > >> 250: int len = def.deflate(buf, 0, buf.length); >> 251: if (len > 0) { >> 252: try { > > Shouldn't this use try with resources: > try (out) { ... the output stream is only closed if an exception is raised though ? ------------- PR: https://git.openjdk.java.net/jdk/pull/5522 From coffeys at openjdk.java.net Tue Oct 12 14:39:52 2021 From: coffeys at openjdk.java.net (Sean Coffey) Date: Tue, 12 Oct 2021 14:39:52 GMT Subject: RFR: 8193682: Infinite loop in ZipOutputStream.close() [v3] In-Reply-To: References: Message-ID: On Tue, 12 Oct 2021 13:28:21 GMT, Ravi Reddy wrote: >> Hi all, >> >> Please review this fix for Infinite loop in ZipOutputStream.close(). >> The main issue here is when ever there is an exception during close operations on GZip we are not setting the deflator to a finished state which is leading to an infinite loop when we try writing on the same GZip instance( since we use while(!def.finished()) inside the write operation). >> >> Thanks, >> Ravi > > Ravi Reddy has updated the pull request incrementally with one additional commit since the last revision: > > 8193682 : Infinite loop in ZipOutputStream.close() test/jdk/java/util/zip/GZIP/GZipLoopTest.java line 55: > 53: private static Random rand = new Random(); > 54: > 55: @Test I think we can condense the test code to aid maintenance - please consider using DataProvider ------------- PR: https://git.openjdk.java.net/jdk/pull/5522 From alanb at openjdk.java.net Tue Oct 12 14:49:53 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 12 Oct 2021 14:49:53 GMT Subject: RFR: 8193682: Infinite loop in ZipOutputStream.close() [v3] In-Reply-To: References: Message-ID: On Tue, 12 Oct 2021 14:11:15 GMT, jmehrens wrote: >> Ravi Reddy has updated the pull request incrementally with one additional commit since the last revision: >> >> 8193682 : Infinite loop in ZipOutputStream.close() > > src/java.base/share/classes/java/util/zip/DeflaterOutputStream.java line 256: > >> 254: } catch (Exception e) { >> 255: def.end(); >> 256: out.close(); > > out.close not needed with try with resources. This changes deflate to close the compressor and the output stream when there is an I/O exception. I expect this will need a spec change or a re-examination of the issue to see if there are alternatives. ------------- PR: https://git.openjdk.java.net/jdk/pull/5522 From rreddy at openjdk.java.net Tue Oct 12 15:03:48 2021 From: rreddy at openjdk.java.net (Ravi Reddy) Date: Tue, 12 Oct 2021 15:03:48 GMT Subject: RFR: 8193682: Infinite loop in ZipOutputStream.close() [v3] In-Reply-To: References: Message-ID: On Tue, 12 Oct 2021 14:35:17 GMT, Sean Coffey wrote: >> src/java.base/share/classes/java/util/zip/DeflaterOutputStream.java line 252: >> >>> 250: int len = def.deflate(buf, 0, buf.length); >>> 251: if (len > 0) { >>> 252: try { >> >> Shouldn't this use try with resources: >> try (out) { ... > > the output stream is only closed if an exception is raised though ? Yes , we are closing the stream only when exception occurs during write operation ------------- PR: https://git.openjdk.java.net/jdk/pull/5522 From rreddy at openjdk.java.net Tue Oct 12 15:03:49 2021 From: rreddy at openjdk.java.net (Ravi Reddy) Date: Tue, 12 Oct 2021 15:03:49 GMT Subject: RFR: 8193682: Infinite loop in ZipOutputStream.close() [v3] In-Reply-To: References: Message-ID: On Tue, 12 Oct 2021 15:00:11 GMT, Ravi Reddy wrote: >> the output stream is only closed if an exception is raised though ? > > Yes , we are closing the stream only when exception occurs during write operation Yes, we are closing the stream only when an exception occurs during a write operation ------------- PR: https://git.openjdk.java.net/jdk/pull/5522 From mcimadamore at openjdk.java.net Tue Oct 12 15:07:55 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 12 Oct 2021 15:07:55 GMT Subject: RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded libraries In-Reply-To: References: <1RwBnwfTi0XsUzPYQHKHTZ7jxgkhgsJfEG28Q33RahA=.6a992ad3-b289-4c93-9dc9-72a948f67581@github.com> <-Sgl3wbFP-k2nDAbFsX3fZ9vs_7-Fno-FeyThJ_VBDY=.a6da9845-64ab-4bdf-bd0e-fd8c4ba77da7@github.com> Message-ID: On Fri, 8 Oct 2021 21:45:21 GMT, Cheng Jin wrote: > That's what I thought to be the only way around but might need to figure out the specifics on AIX. Is `libc.a` loadable on AIX (e.g. with System.loadLibrary) ? (Sorry I don't have a machine to test readily available). If so, we might just load `libc` and `libm` and drop the shim library generation on AIX. ------------- PR: https://git.openjdk.java.net/jdk/pull/4316 From alanb at openjdk.java.net Tue Oct 12 15:09:51 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 12 Oct 2021 15:09:51 GMT Subject: RFR: 8193682: Infinite loop in ZipOutputStream.close() [v3] In-Reply-To: References: Message-ID: On Tue, 12 Oct 2021 13:28:21 GMT, Ravi Reddy wrote: >> Hi all, >> >> Please review this fix for Infinite loop in ZipOutputStream.close(). >> The main issue here is when ever there is an exception during close operations on GZip we are not setting the deflator to a finished state which is leading to an infinite loop when we try writing on the same GZip instance( since we use while(!def.finished()) inside the write operation). >> >> Thanks, >> Ravi > > Ravi Reddy has updated the pull request incrementally with one additional commit since the last revision: > > 8193682 : Infinite loop in ZipOutputStream.close() Setting to "Request changes" until the spec impact is understood. ------------- Changes requested by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5522 From duke at openjdk.java.net Tue Oct 12 15:27:55 2021 From: duke at openjdk.java.net (Cheng Jin) Date: Tue, 12 Oct 2021 15:27:55 GMT Subject: RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded libraries In-Reply-To: References: <1RwBnwfTi0XsUzPYQHKHTZ7jxgkhgsJfEG28Q33RahA=.6a992ad3-b289-4c93-9dc9-72a948f67581@github.com> <-Sgl3wbFP-k2nDAbFsX3fZ9vs_7-Fno-FeyThJ_VBDY=.a6da9845-64ab-4bdf-bd0e-fd8c4ba77da7@github.com> Message-ID: On Tue, 12 Oct 2021 15:04:02 GMT, Maurizio Cimadamore wrote: > Is libc.a loadable on AIX (e.g. with System.loadLibrary) ? I tried to load `libc.a` and `libc` this way but neither of them works on AIX. e.g. public class StdLibTest { private static CLinker clinker = CLinker.getInstance(); static { System.loadLibrary("libc.a"); <----- } private static final SymbolLookup defaultLibLookup = SymbolLookup.loaderLookup(); public static void main(String args[]) throws Throwable { Addressable strlenSymbol = defaultLibLookup.lookup("strlen").get(); } } $ ./bin/java --enable-native-access=ALL-UNNAMED --add-modules jdk.incubator.foreign -Dforeign.restricted=permit --enable-native-access=ALL-UNNAMED StdLibTest WARNING: Using incubator modules: jdk.incubator.foreign Exception in thread "main" java.lang.UnsatisfiedLinkError: Can't load libc.a <------- at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:1822) at java.base/java.lang.System.loadLibrary(System.java:694) at StdLibTest.(StdLibTest.java:23) and public class StdLibTest { private static CLinker clinker = CLinker.getInstance(); static { System.loadLibrary("libc"); <------- } private static final SymbolLookup defaultLibLookup = SymbolLookup.loaderLookup(); public static void main(String args[]) throws Throwable { Addressable strlenSymbol = defaultLibLookup.lookup("strlen").get(); } } $ ./bin/java --enable-native-access=ALL-UNNAMED --add-modules jdk.incubator.foreign -Dforeign.restricted=permit --enable-native-access=ALL-UNNAMED StdLibTest WARNING: Using incubator modules: jdk.incubator.foreign Exception in thread "main" java.lang.UnsatisfiedLinkError: Can't load libc <------ at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:1822) at java.base/java.lang.System.loadLibrary(System.java:694) at StdLibTest.(StdLibTest.java:23) ------------- PR: https://git.openjdk.java.net/jdk/pull/4316 From coffeys at openjdk.java.net Tue Oct 12 15:42:52 2021 From: coffeys at openjdk.java.net (Sean Coffey) Date: Tue, 12 Oct 2021 15:42:52 GMT Subject: RFR: 8193682: Infinite loop in ZipOutputStream.close() [v3] In-Reply-To: References: Message-ID: <_m1tw0OPv3oyBFtTK34fGOu-GbzW0twPkbvQleI2FEg=.bcfe91da-7f4b-4691-a018-d27f5173a19a@github.com> On Tue, 12 Oct 2021 14:46:33 GMT, Alan Bateman wrote: >> src/java.base/share/classes/java/util/zip/DeflaterOutputStream.java line 256: >> >>> 254: } catch (Exception e) { >>> 255: def.end(); >>> 256: out.close(); >> >> out.close not needed with try with resources. > > This changes deflate to close the compressor and the output stream when there is an I/O exception. I expect this will need a spec change or a re-examination of the issue to see if there are alternatives. the out.close() call could be removed I guess. Leave it for user code to handle etc. Safer for spec also. Main goal is to break the looping of the deflate call. The usesDefaultDeflater boolean might be useful in helping determine if def.end() should be called or not. If that boolean is false, then maybe we could just alter the input buffer by setting it to a size 0 buffer (ZipUtils.defaultBuf) -- worth a look. ------------- PR: https://git.openjdk.java.net/jdk/pull/5522 From aefimov at openjdk.java.net Tue Oct 12 15:43:24 2021 From: aefimov at openjdk.java.net (Aleksei Efimov) Date: Tue, 12 Oct 2021 15:43:24 GMT Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v3] In-Reply-To: References: Message-ID: > This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver. > > The following API classes are added to `java.net.spi` package to facilitate this: > - `InetAddressResolverProvider` - abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers. > - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations. > - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations. > - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation. > > More details in [JEP-418](https://openjdk.java.net/jeps/418). > > Testing: new and existing `tier1:tier3` tests Aleksei Efimov has updated the pull request incrementally with two additional commits since the last revision: - Add @since tags to new API classes - Add checks and test for empty stream resolver results ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5822/files - new: https://git.openjdk.java.net/jdk/pull/5822/files/41717fc7..d302a49a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5822&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5822&range=01-02 Stats: 150 lines in 6 files changed: 146 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/5822.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5822/head:pull/5822 PR: https://git.openjdk.java.net/jdk/pull/5822 From mchung at openjdk.java.net Tue Oct 12 16:21:33 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 12 Oct 2021 16:21:33 GMT Subject: RFR: JDK-8274848: LambdaMetaFactory::metafactory on REF_invokeSpecial impl method has incorrect behavior [v2] In-Reply-To: References: Message-ID: > Classes compiled prior to the nestmate support will generate `REF_invokeSpecial` if the implementation method is a private instance method. Since a lambda proxy class is a hidden class, a nestmate of the host class, it can invoke the private implementation method but it has to use `REF_invokeVirtual` or `REF_invokeInterface`. In order to support the old classes running on the new runtime, LMF implementation adjusts the reference kind from `REF_invokeSpecial` to `REF_invokeVirtual/REF_invokeInterface`. > > This PR fixes the check properly to ensure the adjustment is only made if the implementation method is private method in the host class. Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: remove filelist which was added accidentally ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5901/files - new: https://git.openjdk.java.net/jdk/pull/5901/files/1358214d..cfdd036e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5901&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5901&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5901.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5901/head:pull/5901 PR: https://git.openjdk.java.net/jdk/pull/5901 From mchung at openjdk.java.net Tue Oct 12 16:21:37 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 12 Oct 2021 16:21:37 GMT Subject: RFR: JDK-8274848: LambdaMetaFactory::metafactory on REF_invokeSpecial impl method has incorrect behavior [v2] In-Reply-To: <-sS70f6ea7-T3dwih_VYAaBVEpYeeEufiaKELuh7jsI=.0dc187e3-00f8-4152-a06d-8a7a33b75c50@github.com> References: <-sS70f6ea7-T3dwih_VYAaBVEpYeeEufiaKELuh7jsI=.0dc187e3-00f8-4152-a06d-8a7a33b75c50@github.com> Message-ID: On Tue, 12 Oct 2021 10:22:07 GMT, Alan Bateman wrote: >> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> remove filelist which was added accidentally > > filelist line 1: > >> 1: test/jdk/java/lang/invoke/lambda/invokeSpecial/InvokeSpecialMethodImpl.java > > I assume "filelist" is not meant to be in this match, I assume this is why the "jdk" label was added. Fixed. It was accidentally added. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/5901 From mcimadamore at openjdk.java.net Tue Oct 12 16:37:57 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 12 Oct 2021 16:37:57 GMT Subject: RFR: 8275063: Implementation of Memory Access API (Second incubator) Message-ID: This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. [1] - https://openjdk.java.net/jeps/419 ------------- Commit messages: - Fix issues with Aarch64 VaList implementation - Drop argument type profiling for removed `MemoryAccess` class - Add missing files - Tweak javadoc for MemeorySegment/MemoryAddress::setUtf8String - Initial push from panama/foreign Changes: https://git.openjdk.java.net/jdk/pull/5907/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275063 Stats: 14262 lines in 186 files changed: 6583 ins; 5144 del; 2535 mod Patch: https://git.openjdk.java.net/jdk/pull/5907.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5907/head:pull/5907 PR: https://git.openjdk.java.net/jdk/pull/5907 From mcimadamore at openjdk.java.net Tue Oct 12 16:37:57 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 12 Oct 2021 16:37:57 GMT Subject: RFR: 8275063: Implementation of Memory Access API (Second incubator) In-Reply-To: References: Message-ID: <-PiXRcdXSgem16bbZeDqOiJpOJu7FT_FaB8nFYHoGig=.91ba78cb-66d9-4ed3-82e9-184ab4b2616c@github.com> On Tue, 12 Oct 2021 11:16:51 GMT, Maurizio Cimadamore wrote: > This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/419 This PR contains mainly API changes. We have tried to simplify the API, by removing redundant classes and moving functionalities where they belong. Below we list the main changes introduced in this PR. A big thanks to all who helped along the way: @briangoetz, @ChrisHegarty, @FrauBoes, @iwanowww, @JornVernee, @PaulSandoz, @sundararajana and @rose00. ### Value layouts and carriers This is perhaps the biggest change in the API, which has a knock-on effect in other areas as well. In the past, a value layout used to be a fairly *neutral* description of a piece of memory containing a scalar value. A value layout has a size, alignment and endianness. Since a value layout contains no information on *how* the value is to be dereferenced by Java clients, said clients have to specify a *carrier* when obtaining a var handle from a value layout. In this iteration, we have decided to attach carrier types to value layouts - so, in addition to size, alignment and endianness, all value layouts now have a `carrier` accessor, which returns a `j.l.Class`. You will find several hand-specialized version of `ValueLayout`, one for each main carrier type (e.g. `ValueLayout.OfInt` for the `int` carrier). Attaching carrier information to layouts simplifies the API in many ways: * When obtaining a var handle from a layout, it is no longer necessary to provide a carrier; the layout in fact contains all the necessary information for the dereference operation to occur. * Similarly, when linking downcall method handles, the `MethodType` parameter is no longer necessary, as now carrier information can be inferred from the provided `FunctionDescriptor`. * We can express dereference operations in a more general fashion - e.g. `get(ValueLayout.OfInt)` instead of `getInt(ByteOrder)`. Note how the new form is more *complete*. This iteration also adds support for `boolean` and `MemoryAddress` carriers in memory access var handles. ### Layout attributes To help the `CLinker` distinguish between a 32-bit layout modelling to a C `int` and a similar layout modelling a C `float` we have in the past resorted to *layout attributes* - that is, we injected custom classification information in layouts, and then required clients working with the `CLinker` API to only work with such augmented layouts. Because of the changes described above, this is no longer necessary: a layout is always associated with a Java carrier, so the `CLinker` can always disambiguate between `ValueLayout.OfInt` and `ValueLayout.OfFloat` even though they have the same size. For this reason, API support for custom layout attributes has been dropped in this iteration. Similarly, platform-dependent layout constants in `CLinker` have been removed; clients interacting with the foreign linker can simply use the basic layout constants defined in `ValueLayout` (e.g. `JAVA_INT`, `JAVA_FLOAT`, ...) - which is not too different from using the JNI types `jint` and `jfloat`. Of course tools (such as `jextract`) are free to define *custom* layouts which model C type for a specific platform. ### Memory dereference Previous iterations of the API provided ready-made dereference operations as static methods in the `MemoryAccess` class. This class is now removed, and all the dereference operations have been moved to `MemorySegment` and `MemoryAddress`. As mentioned before, the new dereference operations have a new form. Instead of: MemorySegment segment = ... MemoryAccess.getIntAtOffset(segment, /*offset */ 100, /* endianness */ ByteOrder.nativeOrder()); The new API works as follows: MemorySegment segment = ... int val = segment.get(JAVA_INT, /*offset */ 100); Note that the new dereference method is not static, and that parameters such as endianness are now omitted, since clients can just specify the value layout they want to work with. Also, since the new dereference methods are not static, we no longer need the workaround to enable VM argument type profiling (this was necessary to make static methods in `MemoryAccess` class perform reasonably well in the face of profile pollution). The same dereference operations are also available in `MemoryAddress`; when working with native code it might be necessary to dereference a raw pointer. In Java 17, to write a basic comparator function for qsort, the following code is needed: static int qsortCompare(MemoryAddress addr1, MemoryAddress addr2) { return MemoryAccess.getIntAtOffset(MemorySegment.globalNativeSegment(), addr1.toRawLongValue()) - MemoryAccess.getIntAtOffset(MemorySegment.globalNativeSegment(), addr2.toRawLongValue()); With the proposed changes, the above code simplifies to: static int qsortCompare(MemoryAddress addr1, MemoryAddress addr2) { return addr1.get(C_INT, 0) - addr2.get(C_INT, 0); } Which is far more readable. Note that dereferencing a memory address is still a potentially unsafe operation, as an address has no spatia/temporall bounds. For this reason, dereference operation on `MemoryAddress` are marked as *restricted*. ### Memory copy This iteration adds more support for copying Java arrays to and from memory segments. In Java 17, it is possible to copy a Java array into a memory segment, as follows: int[] array = .... MemorySegment segment = ... MemorySegment heapView = MemorySegment.ofArray(array); segment.asSlice(startSegmentOffset, nelems * 4) .copyFrom(heapView.asSlice(startArrayOffset * 4, nelems * 4)) This code snippet is suboptimal for several reasons: * three temporary segments have to be created: the heap view, plus the two slices * note how the code has to carefully slice the source/target segment to make sure that only the desired elements are copied, and at the desired target offset in the segment. * offset in arrays is expressed in elements, whereas offset in segments is expressed in bytes - which calls for potential mistakes. * it is not possible to specify custom endianness/alignment for the copy operation With the changes in this PR, the above code becomes: int[] array = .... MemorySegment segment = ... MemorySegment.copy(array, startArrayOffset, segment, JAVA_INT, startSegmentOffset, nelems); The above code is much simpler, with less potential for mistakes. Also, the extra value layout allows client to inject additional alignment constraints and endianness (if required). ### Role of `MemoryAddress` In Java 17, `MemoryAddress` has a scope accessor. This is useful when reasoning about an address obtained from a memory segment, but is far less useful when thinking about an address received from a native call. While it is possible to model the latter as an address associated with the *global scope*, `MemoryAddress` supports several operations which allow clients to attach spatial and temporal bounds to an address, turning it into a `MemorySegment`. If the address already has a scope, the semantics of some of these operation becomes confusing. For this reason, in this iteration `MemoryAddress` is only used to model raw native addresses. There is no scope associated with a memory address - dereferencing a raw address is always unsafe. This change brings more clarity to API, as `MemoryAddress` is nothing but a simple wrapper around a `long` value. This also means that obtaining a `MemoryAddress` from a heap segment is no longer a possibility; in other words, clients that don't care about native interop should probably just use `MemorySegment` and forget about `MemoryAddress`. ### Downcall method handle safety In Java 17, by-reference parameters to downcall method handles are passed as `MemoryAddress` arguments. This means that e.g. passing a segment by-reference requires a conversion (from segment to memory address, using `MemorySegment::address`). This conversion is lossy, as we lose information about the original memory segment (spatial and temporal bounds). As a result, passing parameter by-reference to downcall method handle is less safe. The changes described in this PR introduce stronger safety guarantees for by-reference parameters. The `CLinker` will now map any such parameter to the `Addressable` type - a common super interface of all things that can be passed by reference. This means clients can pass a memory segment *directly* to a downcall method handle, no conversion required. Because of that, the `CLinker` runtime can make sure that e.g. arguments passed by reference are kept alive for the entire duration of the native call. ### Native symbols In Java 17, looking up a symbol on a native library is done using the `SymbolLookup` interface. This interface used to return a plain `MemoryAddress` (the address of the native function). Given the changes described above, `MemoryAddress` is no longer a great choice: * a `MemoryAddress` now models a raw native memory address, and has no scope * a `MemoryAddress` can be easily dereferenced* For this reason, a new abstraction is added, namely `NativeSymbol`, which is used to model the entry point of a symbol (a function or a global variable) in a native library. A native symbol is `Addressable`, has a name and a resource scope. Since native symbols have a scope, the `CLinker` runtime can make sure that the scope of the native symbol corresponding to the native function being executed cannot be closed prematurely. This effectively allows clients to support safe library loading abstractions which support [deterministic library unloading](https://github.com/sundararajana/panama-jextract-samples/blob/master/dlopen/Dlopen.java). Additionally, we have tweaked the `CLinker::upcallStub` method to also return an *anonymous* `NativeSymbol`, rather than a raw `MemoryAddress`. ### Resource scope tweaks This PR removes the distinction between *implicit* and *explicit* scopes. Now all scopes (except for the *global scope*) are closeable, and can be associated with a `Cleaner`, if required. Another change in the resource scope API is in how temporal scope dependencies are handled. In Java 17 scopes could be acquired and released: MemorySegment segment = ... ResourceScope.Handle segmentHandle = segment.scope().acquire(); try { } finally { segment.scope().release(segmentHandle); } This PR removes the `ResourceScope::acquire` and `ResourceScope::release` methods, and allows instead to capture dependencies between scopes in a more explicit fashion: MemorySegment segment = ... try (ResourceScope criticalScope = ResourceScope.newConfinedScope()) { criticalScope.keepAlive(segment.scope()); } API javadoc: http://cr.openjdk.java.net/~mcimadamore/8275064/javadoc/jdk/incubator/foreign/package-summary.html Specdiff: http://cr.openjdk.java.net/~mcimadamore/8275064/specdiff_out/overview-summary.html ------------- PR: https://git.openjdk.java.net/jdk/pull/5907 From duke at openjdk.java.net Tue Oct 12 16:58:51 2021 From: duke at openjdk.java.net (Evgeny Astigeevich) Date: Tue, 12 Oct 2021 16:58:51 GMT Subject: Integrated: 8271737: Only normalize the cached user.dir property once In-Reply-To: References: Message-ID: On Thu, 7 Oct 2021 14:05:19 GMT, Evgeny Astigeevich wrote: > The change completes the fix of [JDK-8198997](https://bugs.openjdk.java.net/browse/JDK-8198997) which has added normalisation in a constructor but not removed it from the get method. This pull request has now been integrated. Changeset: b8bd259b Author: Evgeny Astigeevich Committer: Paul Hohensee URL: https://git.openjdk.java.net/jdk/commit/b8bd259bb83096f8727222a4e5cd84e80e096275 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8271737: Only normalize the cached user.dir property once Reviewed-by: phh ------------- PR: https://git.openjdk.java.net/jdk/pull/5850 From erikj at openjdk.java.net Tue Oct 12 17:03:52 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 12 Oct 2021 17:03:52 GMT Subject: RFR: 8275063: Implementation of Memory Access API (Second incubator) In-Reply-To: References: Message-ID: On Tue, 12 Oct 2021 11:16:51 GMT, Maurizio Cimadamore wrote: > This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/419 Build changes look good. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5907 From mandy.chung at oracle.com Tue Oct 12 17:05:43 2021 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 12 Oct 2021 10:05:43 -0700 Subject: Questions for JDK-4947890 In-Reply-To: <9a0af925508046149fca001c8912c2b5@imap.linux.ibm.com> References: <9a0af925508046149fca001c8912c2b5@imap.linux.ibm.com> Message-ID: Hi Ichiroh, This behavioral change is not intentional.? It's a bug introduced in JDK-4947890.? I create https://bugs.openjdk.java.net/browse/JDK-8275145 for this issue. Thanks for the investigation. Mandy On 10/12/21 2:44 AM, Ichiroh Takiguchi wrote: > I have some questions for JDK-4947890? > > One of app?s JVM was upgraded from JDK11 to JDK17. > Then the working behavior was changed on Windows 10 Multilingual User > Interface (MUI). > (Base was Japanese Windows 10, display language setting was English > (United States)) > > In my investigation, the working behavior was changed by JDK12+b23. > ? JDK-4947890 Minimize JNI upcalls in system-properties initialization > [1] > > Following change was applied on > src/java.base/share/native/libjava/System.c, > From (not for MacOS platform) [2] > ? Put sprops->sun_jnu_encoding into file.encoding system property > To [3] > ? Put sprops->encoding into file.encoding system property > > I checked JDK-4947890?s CSR JDK-8213895 [4] > ? Modify JVM interface functions for property initialization > > But it seems that above CSR does not mention such a significant > specification change. > > I checked JDK17u, same code was still used [5]. > > Questions: > I?d like to confirm > * This change was intentional or not ? > * We can revert tp JDK11?s spec ? > > Thanks, > Ichiroh Takiguchi > > [1] https://bugs.openjdk.java.net/browse/JDK-4947890 > [2] http://hg.openjdk.java.net/jdk/jdk/rev/0bdbf854472f#l12.466 > [3] http://hg.openjdk.java.net/jdk/jdk/rev/0bdbf854472f#l12.276 > [4] https://bugs.openjdk.java.net/browse/JDK-8213895 > [5] > https://github.com/openjdk/jdk17u/blob/master/src/java.base/share/native/libjava/System.c#L149 From mcimadamore at openjdk.java.net Tue Oct 12 17:30:53 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 12 Oct 2021 17:30:53 GMT Subject: RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded libraries In-Reply-To: References: <1RwBnwfTi0XsUzPYQHKHTZ7jxgkhgsJfEG28Q33RahA=.6a992ad3-b289-4c93-9dc9-72a948f67581@github.com> <-Sgl3wbFP-k2nDAbFsX3fZ9vs_7-Fno-FeyThJ_VBDY=.a6da9845-64ab-4bdf-bd0e-fd8c4ba77da7@github.com> Message-ID: On Tue, 12 Oct 2021 15:24:41 GMT, Cheng Jin wrote: > I tried to load `libc.a` and `libc` this way but neither of them works on AIX. Sorry - what I meant is - `System::load`, which accepts a full path and extension. E.g. System.load("/usr/lib/libc.a"); ------------- PR: https://git.openjdk.java.net/jdk/pull/4316 From jlahoda at openjdk.java.net Tue Oct 12 17:41:57 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 12 Oct 2021 17:41:57 GMT Subject: RFR: 8273682: Upgrade Jline to 3.20.0 In-Reply-To: References: Message-ID: On Thu, 23 Sep 2021 15:43:08 GMT, Athijegannathan Sundararajan wrote: >> I'd like to upgrade the internal JLine to 3.20.0, to support the rxvt terminal (see JDK-8270943), and to generally use a newer version of the library. This patch is basically a application of relevant parts of the diff between JLine 3.14.0 and 3.20.0, with merge fixes as needed. >> >> Thanks! > > src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/CompletionMatcher.java line 32: > >> 30: * >> 31: * @param candidates list of candidates >> 32: * @return a map of candidates that completion matcher matches > > a list of ..? Thanks, I've filled: https://github.com/jline/jline3/issues/711 ------------- PR: https://git.openjdk.java.net/jdk/pull/5655 From duke at openjdk.java.net Tue Oct 12 18:14:54 2021 From: duke at openjdk.java.net (Cheng Jin) Date: Tue, 12 Oct 2021 18:14:54 GMT Subject: RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded libraries [v7] In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 20:49:44 GMT, Maurizio Cimadamore wrote: >> This patch overhauls the library loading mechanism used by the Foreign Linker API. We realized that, while handy, the *default* lookup abstraction (`LibraryLookup::ofDefault`) was behaving inconsistentlt across platforms. >> >> This patch replaces `LibraryLookup` with a simpler `SymbolLookup` abstraction, a functional interface. Crucially, `SymbolLookup` does not concern with library loading, only symbol lookup. For this reason, two factories are added: >> >> * `SymbolLookup::loaderLookup` - which obtains a lookup that can be used to lookup symbols in libraries loaded by current loader >> * `CLinker::systemLookup` - a more stable replacement for the *default* lookup, which looks for symbols in libc.so (or its equivalent in other platforms). The contents of this lookup are unspecified. >> >> Both factories are *restricted*, so they can only be called when `--enable-native-access` is set. > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments on shim lib makefile Just tried with `System.load()` but still ended up with pretty much the same failure given both of them eventually invokes `ClassLoader.loadLibrary` to load the library in which case there is no big difference at this point. static { System.load("/usr/lib/libc.a"); } Exception in thread "main" java.lang.UnsatisfiedLinkError: Can't load /usr/lib/libc.a <---- at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:1793) at java.base/java.lang.System.load(System.java:672) at StdLibTest.(StdLibTest.java:24) ------------- PR: https://git.openjdk.java.net/jdk/pull/4316 From duke at openjdk.java.net Tue Oct 12 19:16:52 2021 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Tue, 12 Oct 2021 19:16:52 GMT Subject: Integrated: 8268764: Use Long.hashCode() instead of int-cast where applicable In-Reply-To: References: Message-ID: On Tue, 15 Jun 2021 12:15:11 GMT, ?????? ??????? wrote: > In some JDK classes there's still the following hashCode() implementation: > > long objNum; > > public int hashCode() { > return (int) objNum; > } > > This outdated expression should be replaced with Long.hashCode(long) as it > > - uses all bits of the original value, does not discard any information upfront. For example, depending on how you are generating the IDs, the upper bits could change more frequently (or the opposite). > > - does not introduce any bias towards values with more ones (zeros), as it would be the case if the two halves were combined with an OR (AND) operation. > > See https://stackoverflow.com/a/4045083 > > This is related to https://github.com/openjdk/jdk/pull/4309 This pull request has now been integrated. Changeset: 124f8237 Author: Sergey Tsypanov Committer: Sergey Bylokhov URL: https://git.openjdk.java.net/jdk/commit/124f82377ba93359bc59118ee315ba194080fa92 Stats: 21 lines in 9 files changed: 6 ins; 0 del; 15 mod 8268764: Use Long.hashCode() instead of int-cast where applicable Reviewed-by: kevinw, prr, kizune, serb ------------- PR: https://git.openjdk.java.net/jdk/pull/4491 From duke at openjdk.java.net Tue Oct 12 20:39:13 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Tue, 12 Oct 2021 20:39:13 GMT Subject: RFR: 8274879: Replace uses of StringBuffer with StringBuilder within java.base classes [v2] In-Reply-To: References: Message-ID: > StringBuffer is a legacy synchronized class. There are more modern alternatives which perform better: > 1. Plain String concatenation should be preferred > 2. StringBuilder is a direct replacement to StringBuffer which generally have better performance > > In [JDK-8264029](https://bugs.openjdk.java.net/browse/JDK-8264029) I migrated only usages which were automatically detected by IDEA. It turns out there are more usages which can be migrated. Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8274879: Replace uses of StringBuffer with StringBuilder within java.base classes revert changes in spec to avoid CSR ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5432/files - new: https://git.openjdk.java.net/jdk/pull/5432/files/14005d1d..c8d68c2a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5432&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5432&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5432.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5432/head:pull/5432 PR: https://git.openjdk.java.net/jdk/pull/5432 From naoto at openjdk.java.net Tue Oct 12 20:39:14 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 12 Oct 2021 20:39:14 GMT Subject: RFR: 8274879: Replace uses of StringBuffer with StringBuilder within java.base classes [v2] In-Reply-To: References: Message-ID: On Mon, 11 Oct 2021 21:05:46 GMT, Andrey Turbanov wrote: >> src/java.base/share/classes/java/lang/Character.java line 123: >> >>> 121: * than U+FFFF are called supplementary characters. The Java >>> 122: * platform uses the UTF-16 representation in {@code char} arrays and >>> 123: * in the {@code String} and {@code StringBuilder} classes. In >> >> Not sure simple replacement applies here, as `StringBuffer` still uses `UTF-16` representation. You may add `StringBuilder` as well here, but I think you might want to file a CSR to clarify. > > reverted changes in this spec. Did you modify the PR? I am unable to locate the revert. ------------- PR: https://git.openjdk.java.net/jdk/pull/5432 From duke at openjdk.java.net Tue Oct 12 20:39:14 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Tue, 12 Oct 2021 20:39:14 GMT Subject: RFR: 8274879: Replace uses of StringBuffer with StringBuilder within java.base classes [v2] In-Reply-To: References: Message-ID: On Tue, 12 Oct 2021 20:33:20 GMT, Naoto Sato wrote: >> reverted changes in this spec. > > Did you modify the PR? I am unable to locate the revert. Oops. Forgot to push ------------- PR: https://git.openjdk.java.net/jdk/pull/5432 From mcimadamore at openjdk.java.net Tue Oct 12 20:41:00 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 12 Oct 2021 20:41:00 GMT Subject: RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded libraries [v7] In-Reply-To: References: Message-ID: <7hT9Tr0x6g2JNV1_rqMhinm1FDaIiYtsVYtvR8__RkA=.45963198-0705-490e-86e1-486b6e140a12@github.com> On Tue, 12 Oct 2021 18:11:56 GMT, Cheng Jin wrote: > Just tried with `System.load()` but still ended up with pretty much the same failure given both of them eventually invokes `ClassLoader.loadLibrary` to load the library in which case there is no big difference at this point. Yes and no. System::loadLibrary wants a library name (no extension). It will add a library prefix (e.g. `lib` on linux) and a library suffix (e.g. `.so` on linux). So, if you do: System.loadLibrary("c") You will end up with `libc.so`. The `System::loadLibrary` logic will then try to find that file in any of the known library paths. `System.load` avoids this by accepting the full path of the library. So there's no guessing the path, nor guessing of prefix/suffix. But it seems like loading still fails, likely because we try to load this library with `dlopen` but this is a static library, so for `dlopen` it just doesn't make sense. ------------- PR: https://git.openjdk.java.net/jdk/pull/4316 From naoto at openjdk.java.net Tue Oct 12 20:46:50 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 12 Oct 2021 20:46:50 GMT Subject: RFR: 8274879: Replace uses of StringBuffer with StringBuilder within java.base classes [v2] In-Reply-To: References: Message-ID: On Tue, 12 Oct 2021 20:39:13 GMT, Andrey Turbanov wrote: >> StringBuffer is a legacy synchronized class. There are more modern alternatives which perform better: >> 1. Plain String concatenation should be preferred >> 2. StringBuilder is a direct replacement to StringBuffer which generally have better performance >> >> In [JDK-8264029](https://bugs.openjdk.java.net/browse/JDK-8264029) I migrated only usages which were automatically detected by IDEA. It turns out there are more usages which can be migrated. > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8274879: Replace uses of StringBuffer with StringBuilder within java.base classes > revert changes in spec to avoid CSR Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5432 From duke at openjdk.java.net Tue Oct 12 20:49:56 2021 From: duke at openjdk.java.net (Cheng Jin) Date: Tue, 12 Oct 2021 20:49:56 GMT Subject: RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded libraries [v7] In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 20:49:44 GMT, Maurizio Cimadamore wrote: >> This patch overhauls the library loading mechanism used by the Foreign Linker API. We realized that, while handy, the *default* lookup abstraction (`LibraryLookup::ofDefault`) was behaving inconsistentlt across platforms. >> >> This patch replaces `LibraryLookup` with a simpler `SymbolLookup` abstraction, a functional interface. Crucially, `SymbolLookup` does not concern with library loading, only symbol lookup. For this reason, two factories are added: >> >> * `SymbolLookup::loaderLookup` - which obtains a lookup that can be used to lookup symbols in libraries loaded by current loader >> * `CLinker::systemLookup` - a more stable replacement for the *default* lookup, which looks for symbols in libc.so (or its equivalent in other platforms). The contents of this lookup are unspecified. >> >> Both factories are *restricted*, so they can only be called when `--enable-native-access` is set. > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments on shim lib makefile If so, I am wondering whether there is anything else left (inherited from JDK16) in JDK17 we can leverage to support `libc.a` on AIX except the way similar to Windows. ------------- PR: https://git.openjdk.java.net/jdk/pull/4316 From mcimadamore at openjdk.java.net Tue Oct 12 20:51:02 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 12 Oct 2021 20:51:02 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v2] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/419 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Fix TestLinkToNativeRBP test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5907/files - new: https://git.openjdk.java.net/jdk/pull/5907/files/be0dd36e..23f69054 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=00-01 Stats: 7 lines in 1 file changed: 1 ins; 4 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5907.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5907/head:pull/5907 PR: https://git.openjdk.java.net/jdk/pull/5907 From jvernee at openjdk.java.net Tue Oct 12 21:30:53 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 12 Oct 2021 21:30:53 GMT Subject: RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded libraries [v7] In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 20:49:44 GMT, Maurizio Cimadamore wrote: >> This patch overhauls the library loading mechanism used by the Foreign Linker API. We realized that, while handy, the *default* lookup abstraction (`LibraryLookup::ofDefault`) was behaving inconsistentlt across platforms. >> >> This patch replaces `LibraryLookup` with a simpler `SymbolLookup` abstraction, a functional interface. Crucially, `SymbolLookup` does not concern with library loading, only symbol lookup. For this reason, two factories are added: >> >> * `SymbolLookup::loaderLookup` - which obtains a lookup that can be used to lookup symbols in libraries loaded by current loader >> * `CLinker::systemLookup` - a more stable replacement for the *default* lookup, which looks for symbols in libc.so (or its equivalent in other platforms). The contents of this lookup are unspecified. >> >> Both factories are *restricted*, so they can only be called when `--enable-native-access` is set. > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments on shim lib makefile I think the reason it worked in JDK 16 is because all the symbols in the JVM were visible through the system lookup, and the JVM statically links the standard library (AFAIU). So, just because the VM code depended on something, it could be loaded by the system lookup. But, that would mean that not all symbols in the standard library were visible... and also, being able to find _any_ symbol in the JVM was a bug. I think the only solution here - assuming that libc is not available as a dynamic library on typical AIX systems - is to figure out how to repackage these static libraries as a dynamic library, retaining all the symbols, and then bundle that dynamic library with the JDK. ------------- PR: https://git.openjdk.java.net/jdk/pull/4316 From plevart at openjdk.java.net Tue Oct 12 22:21:52 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Tue, 12 Oct 2021 22:21:52 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v12] In-Reply-To: References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> Message-ID: <75NKRRr2CGaDr4zsvxMpAXPWcK8ZMdtf8-Zyxh0Q_mY=.b77552bf-0919-46ef-a531-2dbe162e2165@github.com> On Fri, 8 Oct 2021 23:31:32 GMT, Mandy Chung wrote: >> This reimplements core reflection with method handles. >> >> For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. >> >> The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. >> >> The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. >> >> Ran tier1-tier8 tests. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8013527 >> [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > Fix left-over assignment Marked as reviewed by plevart (Reviewer). Hi Mandy, I think this is good as first slab. I don't have anything to add at this point. Some optimization ideas to try as followups. I ran benchmarks myself and the results are similar to yours. Some seem like a regression, but don't have big impact on real-world use case such as Jackson (de)serialization. "Const" class is pretty much the same as with recently improved variant with @Stable fields. I say Go! src/java.base/share/classes/jdk/internal/reflect/MethodHandleCharacterFieldAccessorImpl.java line 137: > 135: { > 136: if (isReadOnly()) { > 137: ensureObj(obj); // throw NPE if obj is null on instance field I think ensureObj(obj) must go before if statement in setChar ------------- PR: https://git.openjdk.java.net/jdk/pull/5027 From plevart at openjdk.java.net Tue Oct 12 22:21:53 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Tue, 12 Oct 2021 22:21:53 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v12] In-Reply-To: <75NKRRr2CGaDr4zsvxMpAXPWcK8ZMdtf8-Zyxh0Q_mY=.b77552bf-0919-46ef-a531-2dbe162e2165@github.com> References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> <75NKRRr2CGaDr4zsvxMpAXPWcK8ZMdtf8-Zyxh0Q_mY=.b77552bf-0919-46ef-a531-2dbe162e2165@github.com> Message-ID: On Tue, 12 Oct 2021 17:42:01 GMT, Peter Levart wrote: >> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix left-over assignment > > src/java.base/share/classes/jdk/internal/reflect/MethodHandleCharacterFieldAccessorImpl.java line 137: > >> 135: { >> 136: if (isReadOnly()) { >> 137: ensureObj(obj); // throw NPE if obj is null on instance field > > I think ensureObj(obj) must go before if statement in setChar No, it's OK. You are relying on `setter.invokeExact(obj, c)` to throw NPE later... ------------- PR: https://git.openjdk.java.net/jdk/pull/5027 From mchung at openjdk.java.net Tue Oct 12 22:48:47 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 12 Oct 2021 22:48:47 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v12] In-Reply-To: References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> <75NKRRr2CGaDr4zsvxMpAXPWcK8ZMdtf8-Zyxh0Q_mY=.b77552bf-0919-46ef-a531-2dbe162e2165@github.com> Message-ID: On Tue, 12 Oct 2021 17:44:08 GMT, Peter Levart wrote: >> src/java.base/share/classes/jdk/internal/reflect/MethodHandleCharacterFieldAccessorImpl.java line 137: >> >>> 135: { >>> 136: if (isReadOnly()) { >>> 137: ensureObj(obj); // throw NPE if obj is null on instance field >> >> I think ensureObj(obj) must go before if statement in setChar > > No, it's OK. You are relying on `setter.invokeExact(obj, c)` to throw NPE later... Yup. This `ensureObj(obj)` call on a Field with no-write access is to ensure NPE is thrown before IAE consistent with the current behavior. ------------- PR: https://git.openjdk.java.net/jdk/pull/5027 From mchung at openjdk.java.net Tue Oct 12 22:55:49 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 12 Oct 2021 22:55:49 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v12] In-Reply-To: References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> Message-ID: On Fri, 8 Oct 2021 23:31:32 GMT, Mandy Chung wrote: >> This reimplements core reflection with method handles. >> >> For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. >> >> The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. >> >> The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. >> >> Ran tier1-tier8 tests. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8013527 >> [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > Fix left-over assignment Thanks, Peter. JEP 417 is also updated to reflect this new implementation. ------------- PR: https://git.openjdk.java.net/jdk/pull/5027 From egahlin at openjdk.java.net Tue Oct 12 23:37:54 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Tue, 12 Oct 2021 23:37:54 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v12] In-Reply-To: References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> Message-ID: On Fri, 8 Oct 2021 23:31:32 GMT, Mandy Chung wrote: >> This reimplements core reflection with method handles. >> >> For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. >> >> The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. >> >> The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. >> >> Ran tier1-tier8 tests. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8013527 >> [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > Fix left-over assignment Change in test/jdk/jdk/jfr/api/consumer/TestHiddenMethod.java looks good. ------------- Marked as reviewed by egahlin (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5027 From psandoz at openjdk.java.net Wed Oct 13 00:06:03 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 13 Oct 2021 00:06:03 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v2] In-Reply-To: References: Message-ID: On Tue, 12 Oct 2021 20:51:02 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/419 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Fix TestLinkToNativeRBP test Like with previous reviews of code for Panama JEPs there are not many comments on this PR, since prior reviews occurred for PRs in the panama-foreign repo. src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 77: > 75: * Furthermore, if the function descriptor's return layout is a group layout, the resulting downcall method handle accepts > 76: * an extra parameter of type {@link SegmentAllocator}, which is used by the linker runtime to allocate the > 77: * memory region associated with the struct returned by the downcall method handle. Suggestion: * memory region associated with the struct returned by the downcall method handle. src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 88: > 86: * in which the specialized signature of a given variable arity callsite is described in full. Alternatively, > 87: * if the foreign library allows it, clients might also be able to interact with variable arity methods > 88: * using by passing a trailing parameter of type {@link VaList}. Suggestion: * by passing a trailing parameter of type {@link VaList}. src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 145: > 143: * Lookup a symbol in the standard libraries associated with this linker. > 144: * The set of symbols available for lookup is unspecified, as it depends on the platform and on the operating system. > 145: * @return a linker-specific library lookup which is suitable to find symbols in the standard libraries associated with this linker. Suggestion: * @return a symbol in the standard libraries associated with this linker. src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/FunctionDescriptor.java line 93: > 91: Objects.requireNonNull(argLayouts); > 92: Arrays.stream(argLayouts).forEach(Objects::requireNonNull); > 93: return new FunctionDescriptor(null, argLayouts); We need to clone `argLayouts`, otherwise the user can modify the contents. Internally, using `List.of` is useful, since it does the cloning and null checks, and that is the type that is returned. Also `argumentLayouts` uses `Arrays.asList` which supports modification of the contents. src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/SegmentAllocator.java line 394: > 392: *

> 393: * The returned allocator might throw an {@link OutOfMemoryError} if the total memory allocated with this allocator > 394: * exceeds the arena size, or the system capacity. Furthermore, the returned allocator is not thread safe, and all The "the returned allocator is not thread safe" contradicts the prior sentence "An allocator associated with a shared resource scope is thread-safe and allocation requests may be performed concurrently". Perhaps just say: "

The returned allocator is not thread safe if the given scope is a shared scope. Concurrent allocation needs to be guarded with synchronization primitives. " src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 260: > 258: > 259: @Override > 260: public final MemorySegment asOverlappingSlice(MemorySegment other) { Please ignore these comments if you wish. Adding `max() // exclusive` to complement `min()` might be useful. In these cases i find it easier to sort the segments e.g. `var a = this; var b = other; if (a.min() > b.min()) { // swap a and b }` then the subsequent logic tends to get simpler e.g. overlap test is `if (b.min() < a.max())`, `segmentOffset` is always +ve. src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/ConfinedScope.java line 100: > 98: do { > 99: value = (int)ASYNC_RELEASE_COUNT.getVolatile(this); > 100: } while (!ASYNC_RELEASE_COUNT.compareAndSet(this, value, value + 1)); Use `getAndAdd` (and ignore the return value). ------------- PR: https://git.openjdk.java.net/jdk/pull/5907 From darcy at openjdk.java.net Wed Oct 13 04:55:03 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 13 Oct 2021 04:55:03 GMT Subject: RFR: JDK-8275186: Suppress warnings on non-serializable array component types in xml Message-ID: <5ZSb4TlERdT02MVTAA--LKW1Es2lT1E0dwfZlDREoWQ=.2c38bbd2-4c1c-4705-b713-e444331762f5@github.com> After a refinement to the checks under development in https://github.com/openjdk/jdk/pull/5709, the new checks examine array types of serial fields and warn if the underlying component type is not serializable. Per the JLS, all array types are serializable, but if the base component is not serializable, the serialization process can throw an exception. >From "Java Object Serialization Specification: 2 - Object Output Classes": "If the object is an array, writeObject is called recursively to write the ObjectStreamClass of the array. The handle for the array is assigned. It is followed by the length of the array. Each element of the array is then written to the stream, after which writeObject returns." ------------- Commit messages: - JDK-8275186: Suppress warnings on non-serializable array component types in xml Changes: https://git.openjdk.java.net/jdk/pull/5924/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5924&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275186 Stats: 8 lines in 6 files changed: 6 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5924.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5924/head:pull/5924 PR: https://git.openjdk.java.net/jdk/pull/5924 From darcy at openjdk.java.net Wed Oct 13 05:10:10 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 13 Oct 2021 05:10:10 GMT Subject: RFR: JDK-8275187: Suppress warnings on non-serializable array component types in java.sql.rowset Message-ID: <3MUgVW5Nix-lu6MzgIAaXq0QwKlZ1EUOBMtcxzFEVKA=.de7a0af6-891a-406d-92c7-170060564771@github.com> After a refinement to the checks under development in #5709, the new checks examine array types of serial fields and warn if the underlying component type is not serializable. Per the JLS, all array types are serializable, but if the base component is not serializable, the serialization process can throw an exception. >From "Java Object Serialization Specification: 2 - Object Output Classes": "If the object is an array, writeObject is called recursively to write the ObjectStreamClass of the array. The handle for the array is assigned. It is followed by the length of the array. Each element of the array is then written to the stream, after which writeObject returns." The java.sql.rowset module has several instances of this coding pattern that need suppression to compile successfully under the future warning. ------------- Commit messages: - JDK-8275187: Suppress warnings on non-serializable array component types in java.sql.rowset Changes: https://git.openjdk.java.net/jdk/pull/5925/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5925&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275187 Stats: 5 lines in 3 files changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5925.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5925/head:pull/5925 PR: https://git.openjdk.java.net/jdk/pull/5925 From joehw at openjdk.java.net Wed Oct 13 05:20:57 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Wed, 13 Oct 2021 05:20:57 GMT Subject: RFR: JDK-8275186: Suppress warnings on non-serializable array component types in xml In-Reply-To: <5ZSb4TlERdT02MVTAA--LKW1Es2lT1E0dwfZlDREoWQ=.2c38bbd2-4c1c-4705-b713-e444331762f5@github.com> References: <5ZSb4TlERdT02MVTAA--LKW1Es2lT1E0dwfZlDREoWQ=.2c38bbd2-4c1c-4705-b713-e444331762f5@github.com> Message-ID: <8Puwbq8I_TgZxgU0d0bkxELFU1IqMUco-7nSXrqLFXA=.6a913112-0154-4130-a281-a5dcde6d20b8@github.com> On Wed, 13 Oct 2021 04:49:22 GMT, Joe Darcy wrote: > After a refinement to the checks under development in https://github.com/openjdk/jdk/pull/5709, the new checks examine array types of serial fields and warn if the underlying component type is not serializable. Per the JLS, all array types are serializable, but if the base component is not serializable, the serialization process can throw an exception. > > From "Java Object Serialization Specification: 2 - Object Output Classes": > > "If the object is an array, writeObject is called recursively to write the ObjectStreamClass of the array. The handle for the array is assigned. It is followed by the length of the array. Each element of the array is then written to the stream, after which writeObject returns." Marked as reviewed by joehw (Reviewer). I understand you'd update the header before push. Pls note that there's a "@LastModified" field that would need to be updated as well. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/5924 From darcy at openjdk.java.net Wed Oct 13 05:20:57 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 13 Oct 2021 05:20:57 GMT Subject: RFR: JDK-8275186: Suppress warnings on non-serializable array component types in xml In-Reply-To: <5ZSb4TlERdT02MVTAA--LKW1Es2lT1E0dwfZlDREoWQ=.2c38bbd2-4c1c-4705-b713-e444331762f5@github.com> References: <5ZSb4TlERdT02MVTAA--LKW1Es2lT1E0dwfZlDREoWQ=.2c38bbd2-4c1c-4705-b713-e444331762f5@github.com> Message-ID: <0J-TAIlz21hIHkxzpXSBMqGuVTHvsq9piRB66bQPNyg=.78764ed7-abce-4e1a-b8dc-442fc2f6df3b@github.com> On Wed, 13 Oct 2021 04:49:22 GMT, Joe Darcy wrote: > After a refinement to the checks under development in https://github.com/openjdk/jdk/pull/5709, the new checks examine array types of serial fields and warn if the underlying component type is not serializable. Per the JLS, all array types are serializable, but if the base component is not serializable, the serialization process can throw an exception. > > From "Java Object Serialization Specification: 2 - Object Output Classes": > > "If the object is an array, writeObject is called recursively to write the ObjectStreamClass of the array. The handle for the array is assigned. It is followed by the length of the array. Each element of the array is then written to the stream, after which writeObject returns." > > > I understand you'd update the header before push. Pls note that there's a "@lastmodified" field that would need to be updated as well. Thanks. Hi Joe, I ran my copyright update script this time before sending out the review; I'll check for the "@lastmodified" fields before pushing. Thanks, -Joe ------------- PR: https://git.openjdk.java.net/jdk/pull/5924 From darcy at openjdk.java.net Wed Oct 13 05:30:22 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 13 Oct 2021 05:30:22 GMT Subject: RFR: JDK-8275186: Suppress warnings on non-serializable array component types in xml [v2] In-Reply-To: <5ZSb4TlERdT02MVTAA--LKW1Es2lT1E0dwfZlDREoWQ=.2c38bbd2-4c1c-4705-b713-e444331762f5@github.com> References: <5ZSb4TlERdT02MVTAA--LKW1Es2lT1E0dwfZlDREoWQ=.2c38bbd2-4c1c-4705-b713-e444331762f5@github.com> Message-ID: > After a refinement to the checks under development in https://github.com/openjdk/jdk/pull/5709, the new checks examine array types of serial fields and warn if the underlying component type is not serializable. Per the JLS, all array types are serializable, but if the base component is not serializable, the serialization process can throw an exception. > > From "Java Object Serialization Specification: 2 - Object Output Classes": > > "If the object is an array, writeObject is called recursively to write the ObjectStreamClass of the array. The handle for the array is assigned. It is followed by the length of the array. Each element of the array is then written to the stream, after which writeObject returns." Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Update LastModified info. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5924/files - new: https://git.openjdk.java.net/jdk/pull/5924/files/c184ee63..41068620 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5924&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5924&range=00-01 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5924.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5924/head:pull/5924 PR: https://git.openjdk.java.net/jdk/pull/5924 From darcy at openjdk.java.net Wed Oct 13 05:30:25 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 13 Oct 2021 05:30:25 GMT Subject: Integrated: JDK-8275186: Suppress warnings on non-serializable array component types in xml In-Reply-To: <5ZSb4TlERdT02MVTAA--LKW1Es2lT1E0dwfZlDREoWQ=.2c38bbd2-4c1c-4705-b713-e444331762f5@github.com> References: <5ZSb4TlERdT02MVTAA--LKW1Es2lT1E0dwfZlDREoWQ=.2c38bbd2-4c1c-4705-b713-e444331762f5@github.com> Message-ID: On Wed, 13 Oct 2021 04:49:22 GMT, Joe Darcy wrote: > After a refinement to the checks under development in https://github.com/openjdk/jdk/pull/5709, the new checks examine array types of serial fields and warn if the underlying component type is not serializable. Per the JLS, all array types are serializable, but if the base component is not serializable, the serialization process can throw an exception. > > From "Java Object Serialization Specification: 2 - Object Output Classes": > > "If the object is an array, writeObject is called recursively to write the ObjectStreamClass of the array. The handle for the array is assigned. It is followed by the length of the array. Each element of the array is then written to the stream, after which writeObject returns." This pull request has now been integrated. Changeset: ab34cced Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/ab34cced3beae765fe9d6b6acfef7e6a7f3082cd Stats: 11 lines in 6 files changed: 6 ins; 0 del; 5 mod 8275186: Suppress warnings on non-serializable array component types in xml Reviewed-by: joehw ------------- PR: https://git.openjdk.java.net/jdk/pull/5924 From duke at openjdk.java.net Wed Oct 13 07:28:07 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Wed, 13 Oct 2021 07:28:07 GMT Subject: RFR: 8275197: Remove unused fields in ThaiBuddhistChronology Message-ID: Remove 3 unused HashMap's. Reported here https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-September/081866.html I did the similar PR to treetenbp and it was merged https://github.com/ThreeTen/threetenbp/pull/155 ------------- Commit messages: - [PATCH] Remove unused fields in ThaiBuddhistChronology Changes: https://git.openjdk.java.net/jdk/pull/5917/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5917&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275197 Stats: 37 lines in 1 file changed: 0 ins; 36 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5917.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5917/head:pull/5917 PR: https://git.openjdk.java.net/jdk/pull/5917 From duke at openjdk.java.net Wed Oct 13 08:29:53 2021 From: duke at openjdk.java.net (Raffaello Giulietti) Date: Wed, 13 Oct 2021 08:29:53 GMT Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v2] In-Reply-To: References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com> Message-ID: On Fri, 16 Apr 2021 11:30:32 GMT, Raffaello Giulietti wrote: >> Hello, >> >> here's a PR for a patch submitted on March 2020 [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a thing. >> >> The patch has been edited to adhere to OpenJDK code conventions about multi-line (block) comments. Nothing in the code proper has changed, except for the addition of redundant but clarifying parentheses in some expressions. >> >> >> Greetings >> Raffaello > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > 4511638: Double.toString(double) sometimes produces incorrect results (Guy Steele reply to a previous comment of mine) Yes, thank you, I stated my suggested criterion incorrectly. ?Guy On Oct 11, 2021, at 4:16 AM, Raffaello Giulietti ***@***.******@***.***>> wrote:> Hi Guy, > > while implementing the additional test recommended in your point (2), it occurred to me that the numbers of the form y 10^n, y in D_k (k = 1, 2, 3, 4) end up being of the form y' 10^n', where y' = y / 10^k, n' = n + k, plus the 2 * Y values around these. Such numbers do not seem to show any special structure worth a dedicated test, so I'm wondering if you mean something else instead. > > Perhaps you mean y to have at most 4 digits, i.e., 0 <= y < 10^4? > > Greetings > Raffaello > > P.S. The test recommended in point (1) pass successfully. > ------------- PR: https://git.openjdk.java.net/jdk/pull/3402 From duke at openjdk.java.net Wed Oct 13 08:37:54 2021 From: duke at openjdk.java.net (Raffaello Giulietti) Date: Wed, 13 Oct 2021 08:37:54 GMT Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v2] In-Reply-To: References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com> Message-ID: On Fri, 16 Apr 2021 11:30:32 GMT, Raffaello Giulietti wrote: >> Hello, >> >> here's a PR for a patch submitted on March 2020 [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a thing. >> >> The patch has been edited to adhere to OpenJDK code conventions about multi-line (block) comments. Nothing in the code proper has changed, except for the addition of redundant but clarifying parentheses in some expressions. >> >> >> Greetings >> Raffaello > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > 4511638: Double.toString(double) sometimes produces incorrect results (Replies from Guy Steele) > Hi Guy, > > for some reason your comments still appear garbled on the GitHub PR page and don't make it to the core-libs-dev mailing list at all. Luckily, they appear intelligible in my mailbox, so I'll keep going with prepending your comments in my replies: not ideal but good enough. > > Thanks so much for re-reading my "paper". > > printf() > > There are some issues to consider when trying to apply Schubfach to printf(), the main one being that printf() allows to specify an arbitrary length for the resulting decimal. This means, for example, that unlimited precision arithmetic is unavoidable. But it might be worthwhile to investigate using Schubfach for lengths up to H (9 and 17 for float and double, resp.) and fall back to unlimited precision beyond that. > Before that, however, I would prefer to finally push Schubfach in the OpenJDK codebase for the toString() cases and close this PR. I completely agree that using Schubfach to solve only the toString() problems would be a _major_ improvement in the situation, and this should not wait for exploration of the printf problem. But I suspect that using Schubfach for lengths up to H would cover a very large fraction of actual usage, and would improve both quality and speed, and therefore would be worth exploring later. > Tests > > Below, by "extensive test" I mean not only that the outcomes convert back without loss of information, but that they fully meet the spec about minimal number of digits, closeness, correct formatting (normal viz scientific), character set, etc. > > All currently available tests are in the contributed code of this PR and will be part of the OpenJDK once integrated. > > * All powers of 2 and the extreme values are already extensively tested. > * All values closest to powers of 10 are extensively tested. > * All values proposed by Paxson [1] are extensively tested. I have now read through the Paxson paper. Does this refer to the values listed in his Tables 3 and 4, or to other values instead or in addition? > * A configurable number of random values are tested at each round (currently 4 * 1'000'000 random values). Should a value fail, there's enough diagnostic information for further investigation. > > I'll add extensive tests for the values you propose in point (1) and (2), setting Z = Y = 1024. > I do think that would lend further confidence. > As for comparison with the current JDK behavior, there are already a bunch of values for which extensive tests fail on the current JDK but pass with Schubfach. Yes, thanks for supplying some of those. > It would be cumbersome, if possible at all, to have both the current JDK and Schubfach implementations in the same OpenJDK codebase to be able to compare the outcomes. I performed comparisons in a different constellation, with Schubfach as an external library, but this is hardly a possibility in the core-libs. Needless to say, Schubfach outcomes are either the same as in JDK or better (shorter or closest to the fp value). Okay. I will mention here, for the record, that there is one other sort of test that could be performed that I think I have not yet seen you mention: a monotonicity test of the kind used by David Hough?s Testbase (mentioned by Paxson). However, a little thought reveals that such a test made unnecessary by the round-trip test. So a monotonicity test would be a good idea when testing printf case, but is not needed for the toString case. Therefore, if you add the few tests I have suggested, I think that we can say with the best certainty we can have, short of separately testing every possible double value, that Schubfach is extremely well tested and ready for adoption into Java. > Peer reviewed publication > > Shortening my 27 pages writing and re-formating it to meet a journal standards for publication would require investing yet another substantial amount of time. I'm not sure I'm prepared for that, given that I've no personal interest in a journal publication: I'm not an academic, I'm not pursuing a career... > But I promise I'll think about reconsidering my position on this ;-) > Please do think about reconsidering. There are several reasons to publish an ?academic? paper: - Earning ?merit badges? that lead to academic tenure - Reputation more generally?which maybe you don?t care much about, but it?s one way to ensure that the contributions of Dmitry Nadezhin are not forgotten - Making sure that the technical ideas are not lost: an academic journal provides a ?permanent home? for documentation and a search engine - Provides a place for others who build on the work to cite - The publication process engages other minds and eyeballs that may improve the writeup, sometimes in surprisingly good ways (in particular, I am sure that good referees would insist that you include all the details about testing that I had to drag out of you over the course of several email exchanges?if this information had beennin the original writeup, I should simply have said, ?Great! All done! Go for it!?). There are many different archival venues with different tradeoffs. - Publishing at arxiv.org is free, takes very little time, imposes no special formatting restrictions, has no page limit (so you don?t have to shorten anything), and has no review process. I would recommend doing this much right away. - Some academic journals have no page limit, or have page limits up around 50 pages; this takes time but would give you rigorous peer review (multiple rounds if necessary). - Conferences do have page limits (anywhere from 5 to 30 pages, depending on the conference), but take less time and give you some peer review. If this code goes into the Java codebase, then first and foremost I want to make sure that some version of your complete writeup, expanded to describe the testing procedures, remains available to those who will have to maintain the code decades into the future. Second, I would like to make it easy for implementors of other programming languages to adopt this solution also. This is too important a problem and EVERY programming language that supports floating-point values must solve it. I want to help make sure that from now on it will be solved well, and right now Schubfach is the best solution I have seen. ?Guy ------------- PR: https://git.openjdk.java.net/jdk/pull/3402 From duke at openjdk.java.net Wed Oct 13 08:44:55 2021 From: duke at openjdk.java.net (Raffaello Giulietti) Date: Wed, 13 Oct 2021 08:44:55 GMT Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v2] In-Reply-To: References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com> Message-ID: On Fri, 16 Apr 2021 11:30:32 GMT, Raffaello Giulietti wrote: >> Hello, >> >> here's a PR for a patch submitted on March 2020 [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a thing. >> >> The patch has been edited to adhere to OpenJDK code conventions about multi-line (block) comments. Nothing in the code proper has changed, except for the addition of redundant but clarifying parentheses in some expressions. >> >> >> Greetings >> Raffaello > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > 4511638: Double.toString(double) sometimes produces incorrect results Hi Guy, > I have now read through the Paxson paper. Does this refer to the values listed in his Tables 3 and 4, or to other values instead or in addition? Right. >> Shortening my 27 pages writing and re-formating it to meet a journal standards for publication would require investing yet another substantial amount of time. I'm not sure I'm prepared for that, given that I've no personal interest in a journal publication: I'm not an academic, I'm not pursuing a career... >> But I promise I'll think about reconsidering my position on this ;-) > > Please do think about reconsidering. OK, thanks for the useful suggestions. Greetings Raffaello ------------- PR: https://git.openjdk.java.net/jdk/pull/3402 From aph at openjdk.java.net Wed Oct 13 08:54:56 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Wed, 13 Oct 2021 08:54:56 GMT Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v2] In-Reply-To: References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com> Message-ID: On Fri, 16 Apr 2021 11:30:32 GMT, Raffaello Giulietti wrote: >> Hello, >> >> here's a PR for a patch submitted on March 2020 [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a thing. >> >> The patch has been edited to adhere to OpenJDK code conventions about multi-line (block) comments. Nothing in the code proper has changed, except for the addition of redundant but clarifying parentheses in some expressions. >> >> >> Greetings >> Raffaello > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > 4511638: Double.toString(double) sometimes produces incorrect results Email from GuySteele follows: (my reply) Hi Guy, for some reason your comments still appear garbled on the GitHub PR page and don't make it to the core-libs-dev mailing list at all. Luckily, they appear intelligible in my mailbox, so I'll keep going with prepending your comments in my replies: not ideal but good enough. Thanks so much for re-reading my "paper". printf() There are some issues to consider when trying to apply Schubfach to printf(), the main one being that printf() allows to specify an arbitrary length for the resulting decimal. This means, for example, that unlimited precision arithmetic is unavoidable. But it might be worthwhile to investigate using Schubfach for lengths up to H (9 and 17 for float and double, resp.) and fall back to unlimited precision beyond that. Before that, however, I would prefer to finally push Schubfach in the OpenJDK codebase for the toString() cases and close this PR. I completely agree that using Schubfach to solve only the toString() problems would be a _major_ improvement in the situation, and this should not wait for exploration of the printf problem. But I suspect that using Schubfach for lengths up to H would cover a very large fraction of actual usage, and would improve both quality and speed, and therefore would be worth exploring later. Tests Below, by "extensive test" I mean not only that the outcomes convert back without loss of information, but that they fully meet the spec about minimal number of digits, closeness, correct formatting (normal viz scientific), character set, etc. All currently available tests are in the contributed code of this PR and will be part of the OpenJDK once integrated. * All powers of 2 and the extreme values are already extensively tested. * All values closest to powers of 10 are extensively tested. * All values proposed by Paxson [1] are extensively tested. I have now read through the Paxson paper. Does this refer to the values listed in his Tables 3 and 4, or to other values instead or in addition? * A configurable number of random values are tested at each round (currently 4 * 1'000'000 random values). Should a value fail, there's enough diagnostic information for further investigation. I'll add extensive tests for the values you propose in point (1) and (2), setting Z = Y = 1024. I do think that would lend further confidence. As for comparison with the current JDK behavior, there are already a bunch of values for which extensive tests fail on the current JDK but pass with Schubfach. Yes, thanks for supplying some of those. It would be cumbersome, if possible at all, to have both the current JDK and Schubfach implementations in the same OpenJDK codebase to be able to compare the outcomes. I performed comparisons in a different constellation, with Schubfach as an external library, but this is hardly a possibility in the core-libs. Needless to say, Schubfach outcomes are either the same as in JDK or better (shorter or closest to the fp value). Okay. I will mention here, for the record, that there is one other sort of test that could be performed that I think I have not yet seen you mention: a monotonicity test of the kind used by David Hough?s Testbase (mentioned by Paxson). However, a little thought reveals that such a test made unnecessary by the round-trip test. So a monotonicity test would be a good idea when testing printf case, but is not needed for the toString case. Therefore, if you add the few tests I have suggested, I think that we can say with the best certainty we can have, short of separately testing every possible double value, that Schubfach is extremely well tested and ready for adoption into Java. Peer reviewed publication Shortening my 27 pages writing and re-formating it to meet a journal standards for publication would require investing yet another substantial amount of time. I'm not sure I'm prepared for that, given that I've no personal interest in a journal publication: I'm not an academic, I'm not pursuing a career... But I promise I'll think about reconsidering my position on this ;-) Please do think about reconsidering. There are several reasons to publish an ?academic? paper: - Earning ?merit badges? that lead to academic tenure - Reputation more generally?which maybe you don?t care much about, but it?s one way to ensure that the contributions of Dmitry Nadezhin are not forgotten - Making sure that the technical ideas are not lost: an academic journal provides a ?permanent home? for documentation and a search engine - Provides a place for others who build on the work to cite - The publication process engages other minds and eyeballs that may improve the writeup, sometimes in surprisingly good ways (in particular, I am sure that good referees would insist that you include all the details about testing that I had to drag out of you over the course of several email exchanges?if this information had beennin the original writeup, I should simply have said, ?Great! All done! Go for it!?). There are many different archival venues with different tradeoffs. - Publishing at arxiv.org is free, takes very little time, imposes no special formatting restrictions, has no page limit (so you don?t have to shorten anything), and has no review process. I would recommend doing this much right away. - Some academic journals have no page limit, or have page limits up around 50 pages; this takes time but would give you rigorous peer review (multiple rounds if necessary). - Conferences do have page limits (anywhere from 5 to 30 pages, depending on the conference), but take less time and give you some peer review. If this code goes into the Java codebase, then first and foremost I want to make sure that some version of your complete writeup, expanded to describe the testing procedures, remains available to those who will have to maintain the code decades into the future. Second, I would like to make it easy for implementors of other programming languages to adopt this solution also. This is too important a problem and EVERY programming language that supports floating-point values must solve it. I want to help make sure that from now on it will be solved well, and right now Schubfach is the best solution I have seen. ?Guy -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/openjdk/jdk/pull/3402#issuecomment-941807665 ------------- PR: https://git.openjdk.java.net/jdk/pull/3402 From wuyan at openjdk.java.net Wed Oct 13 09:02:03 2021 From: wuyan at openjdk.java.net (Wu Yan) Date: Wed, 13 Oct 2021 09:02:03 GMT Subject: RFR: 8273111: Default timezone should return zone ID if /etc/localtime is valid but not canonicalization on linux [v2] In-Reply-To: References: <6gmVj3r1hjhG5jvo_dSly3ShNnZZSCn-NIjtnvSySrk=.a88def27-7b80-425b-9ab8-2f94f5004b47@github.com> Message-ID: On Mon, 11 Oct 2021 18:16:28 GMT, Naoto Sato wrote: >> Wu Yan has updated the pull request incrementally with one additional commit since the last revision: >> >> replace realpath > > src/java.base/unix/native/libjava/TimeZone_md.c line 113: > >> 111: } >> 112: } >> 113: > > There are a few `*(right + 1)` references in the loops. Is there any possibility that it would run over the buffer? It wouldn't run over the buffer. Here `end` points to `'\0'`. At line 94 and line 99, `right` is less than `end`, so `right + 1` is at most `end`. At line 103, if `right` equals `end`, `*right != '\0'` will be false and `!(*right == '/' && *(right + 1) == '/')` will not executed. ------------- PR: https://git.openjdk.java.net/jdk/pull/5327 From wuyan at openjdk.java.net Wed Oct 13 09:06:52 2021 From: wuyan at openjdk.java.net (Wu Yan) Date: Wed, 13 Oct 2021 09:06:52 GMT Subject: RFR: 8273111: Default timezone should return zone ID if /etc/localtime is valid but not canonicalization on linux [v2] In-Reply-To: References: <6gmVj3r1hjhG5jvo_dSly3ShNnZZSCn-NIjtnvSySrk=.a88def27-7b80-425b-9ab8-2f94f5004b47@github.com> Message-ID: On Mon, 11 Oct 2021 18:18:02 GMT, Naoto Sato wrote: >> Wu Yan has updated the pull request incrementally with one additional commit since the last revision: >> >> replace realpath > > src/java.base/unix/native/libjava/path_util.h line 31: > >> 29: int collapsible(char *names); >> 30: void splitNames(char *names, char **ix); >> 31: void joinNames(char *names, int nc, char **ix); > > Are these functions, `collapsible`, `splitNames` and `joinNames` have to be non-static? You are right, thanks for your suggestions, I'll change these functions to static in next commit. ------------- PR: https://git.openjdk.java.net/jdk/pull/5327 From myano at openjdk.java.net Wed Oct 13 09:08:48 2021 From: myano at openjdk.java.net (Masanori Yano) Date: Wed, 13 Oct 2021 09:08:48 GMT Subject: RFR: 8250678: ModuleDescriptor.Version parsing treats empty segments inconsistently In-Reply-To: References: <5FwhmsS85upnfXAKPCBCQTsWorJN17vOBFZXCN6iP8M=.377740a1-6f1e-4e37-9344-25a60ffdd891@github.com> Message-ID: <98NW1cw5PzcVEjoPK_W_9BcTZn58kkJHhwMxjN2y1d8=.699b7a13-2ca4-4bf4-b755-d9357d781187@github.com> On Wed, 6 Oct 2021 18:40:36 GMT, Mark Reinhold wrote: >> @mbreinhold Could you comment on this pull request? > >> @mbreinhold Could you comment on this pull request? > > This is somewhat tricky code. I?ll take a look, but give me a few days. @mbreinhold I waited for about a week, but I haven't received an answer yet. Could you comment on this? ------------- PR: https://git.openjdk.java.net/jdk/pull/5679 From wuyan at openjdk.java.net Wed Oct 13 09:15:25 2021 From: wuyan at openjdk.java.net (Wu Yan) Date: Wed, 13 Oct 2021 09:15:25 GMT Subject: RFR: 8273111: Default timezone should return zone ID if /etc/localtime is valid but not canonicalization on linux [v3] In-Reply-To: <6gmVj3r1hjhG5jvo_dSly3ShNnZZSCn-NIjtnvSySrk=.a88def27-7b80-425b-9ab8-2f94f5004b47@github.com> References: <6gmVj3r1hjhG5jvo_dSly3ShNnZZSCn-NIjtnvSySrk=.a88def27-7b80-425b-9ab8-2f94f5004b47@github.com> Message-ID: > Hi, > Please help me review the change to enhance getting time zone ID from /etc/localtime on linux. > > We use `realpath` instead of `readlink` to obtain the link name of /etc/localtime, because `readlink` can only read the value of a symbolic of link, not the canonicalized absolute pathname. > > For example, the value of /etc/localtime is "../usr/share/zoneinfo//Asia/Shanghai", then the linkbuf obtained by `readlink` is "../usr/share/zoneinfo//Asia/Shanghai", and then the call of `getZoneName(linkbuf)` will get "/Asia/Shanghai", not "Asia/Shanghai", which consider as invalid in `ZoneInfoFile.getZoneInfo()`. Using `realpath`, you can get ?/usr/share/zoneinfo/Asia/Shanghai? directly from ?/etc/localtime?. > > Thanks, > wuyan Wu Yan has updated the pull request incrementally with one additional commit since the last revision: change functions to be static ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5327/files - new: https://git.openjdk.java.net/jdk/pull/5327/files/19cc634d..38177cd0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5327&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5327&range=01-02 Stats: 6 lines in 2 files changed: 0 ins; 3 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5327.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5327/head:pull/5327 PR: https://git.openjdk.java.net/jdk/pull/5327 From jlahoda at openjdk.java.net Wed Oct 13 10:18:57 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 13 Oct 2021 10:18:57 GMT Subject: Integrated: 8273682: Upgrade Jline to 3.20.0 In-Reply-To: References: Message-ID: On Thu, 23 Sep 2021 14:43:21 GMT, Jan Lahoda wrote: > I'd like to upgrade the internal JLine to 3.20.0, to support the rxvt terminal (see JDK-8270943), and to generally use a newer version of the library. This patch is basically a application of relevant parts of the diff between JLine 3.14.0 and 3.20.0, with merge fixes as needed. > > Thanks! This pull request has now been integrated. Changeset: b8cb76ad Author: Jan Lahoda URL: https://git.openjdk.java.net/jdk/commit/b8cb76ad210cb3e7524c7f5b13cfe57746ac05d4 Stats: 2667 lines in 47 files changed: 1830 ins; 473 del; 364 mod 8273682: Upgrade Jline to 3.20.0 Reviewed-by: sundar ------------- PR: https://git.openjdk.java.net/jdk/pull/5655 From lancea at openjdk.java.net Wed Oct 13 11:07:52 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 13 Oct 2021 11:07:52 GMT Subject: RFR: JDK-8275187: Suppress warnings on non-serializable array component types in java.sql.rowset In-Reply-To: <3MUgVW5Nix-lu6MzgIAaXq0QwKlZ1EUOBMtcxzFEVKA=.de7a0af6-891a-406d-92c7-170060564771@github.com> References: <3MUgVW5Nix-lu6MzgIAaXq0QwKlZ1EUOBMtcxzFEVKA=.de7a0af6-891a-406d-92c7-170060564771@github.com> Message-ID: On Wed, 13 Oct 2021 05:02:15 GMT, Joe Darcy wrote: > After a refinement to the checks under development in #5709, the new checks examine array types of serial fields and warn if the underlying component type is not serializable. Per the JLS, all array types are serializable, but if the base component is not serializable, the serialization process can throw an exception. > > From "Java Object Serialization Specification: 2 - Object Output Classes": > > "If the object is an array, writeObject is called recursively to write the ObjectStreamClass of the array. The handle for the array is assigned. It is followed by the length of the array. Each element of the array is then written to the stream, after which writeObject returns." > > The java.sql.rowset module has several instances of this coding pattern that need suppression to compile successfully under the future warning. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5925 From mcimadamore at openjdk.java.net Wed Oct 13 12:07:58 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 13 Oct 2021 12:07:58 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v3] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/419 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Apply suggestions from code review Co-authored-by: Paul Sandoz ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5907/files - new: https://git.openjdk.java.net/jdk/pull/5907/files/23f69054..d6bf27ff Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5907.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5907/head:pull/5907 PR: https://git.openjdk.java.net/jdk/pull/5907 From mcimadamore at openjdk.java.net Wed Oct 13 12:48:06 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 13 Oct 2021 12:48:06 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v4] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/419 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5907/files - new: https://git.openjdk.java.net/jdk/pull/5907/files/d6bf27ff..27e71ee7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=02-03 Stats: 35 lines in 4 files changed: 8 ins; 11 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/5907.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5907/head:pull/5907 PR: https://git.openjdk.java.net/jdk/pull/5907 From redestad at openjdk.java.net Wed Oct 13 12:57:53 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 13 Oct 2021 12:57:53 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v12] In-Reply-To: References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> Message-ID: <9fhK44PmCm6WQc6iAdb6x-PENyxNJHaFIyrnAlgEpdI=.f597867b-b64d-4e32-a5c5-9c857b6cf7dd@github.com> On Fri, 8 Oct 2021 23:31:32 GMT, Mandy Chung wrote: >> This reimplements core reflection with method handles. >> >> For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. >> >> The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. >> >> The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. >> >> Ran tier1-tier8 tests. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8013527 >> [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > Fix left-over assignment I agree that this is in a good state for integration now, though it might be necessary to do some follow-up work to address different performance concerns: - While performance in the `*Const` micros are on the same level as after #5694 there is some added overhead in non-const cases - Cold start overheads leaves a few things to be desired, though the effects we can measure on targeted tests appear to be small in practice on larger apps. Some possible simplifications like using `asSpreader` always is currently unattractive due the added startup overheads. ------------- Marked as reviewed by redestad (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5027 From naoto at openjdk.java.net Wed Oct 13 16:25:49 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 13 Oct 2021 16:25:49 GMT Subject: RFR: 8273111: Default timezone should return zone ID if /etc/localtime is valid but not canonicalization on linux [v3] In-Reply-To: References: <6gmVj3r1hjhG5jvo_dSly3ShNnZZSCn-NIjtnvSySrk=.a88def27-7b80-425b-9ab8-2f94f5004b47@github.com> Message-ID: On Wed, 13 Oct 2021 09:15:25 GMT, Wu Yan wrote: >> Hi, >> Please help me review the change to enhance getting time zone ID from /etc/localtime on linux. >> >> We use `realpath` instead of `readlink` to obtain the link name of /etc/localtime, because `readlink` can only read the value of a symbolic of link, not the canonicalized absolute pathname. >> >> For example, the value of /etc/localtime is "../usr/share/zoneinfo//Asia/Shanghai", then the linkbuf obtained by `readlink` is "../usr/share/zoneinfo//Asia/Shanghai", and then the call of `getZoneName(linkbuf)` will get "/Asia/Shanghai", not "Asia/Shanghai", which consider as invalid in `ZoneInfoFile.getZoneInfo()`. Using `realpath`, you can get ?/usr/share/zoneinfo/Asia/Shanghai? directly from ?/etc/localtime?. >> >> Thanks, >> wuyan > > Wu Yan has updated the pull request incrementally with one additional commit since the last revision: > > change functions to be static Looks good. Thanks for the fix. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5327 From darcy at openjdk.java.net Wed Oct 13 16:56:52 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 13 Oct 2021 16:56:52 GMT Subject: Integrated: JDK-8275187: Suppress warnings on non-serializable array component types in java.sql.rowset In-Reply-To: <3MUgVW5Nix-lu6MzgIAaXq0QwKlZ1EUOBMtcxzFEVKA=.de7a0af6-891a-406d-92c7-170060564771@github.com> References: <3MUgVW5Nix-lu6MzgIAaXq0QwKlZ1EUOBMtcxzFEVKA=.de7a0af6-891a-406d-92c7-170060564771@github.com> Message-ID: On Wed, 13 Oct 2021 05:02:15 GMT, Joe Darcy wrote: > After a refinement to the checks under development in #5709, the new checks examine array types of serial fields and warn if the underlying component type is not serializable. Per the JLS, all array types are serializable, but if the base component is not serializable, the serialization process can throw an exception. > > From "Java Object Serialization Specification: 2 - Object Output Classes": > > "If the object is an array, writeObject is called recursively to write the ObjectStreamClass of the array. The handle for the array is assigned. It is followed by the length of the array. Each element of the array is then written to the stream, after which writeObject returns." > > The java.sql.rowset module has several instances of this coding pattern that need suppression to compile successfully under the future warning. This pull request has now been integrated. Changeset: d15fbc28 Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/d15fbc28afc3f2d509b4e46e70877a4650fafdc2 Stats: 5 lines in 3 files changed: 3 ins; 0 del; 2 mod 8275187: Suppress warnings on non-serializable array component types in java.sql.rowset Reviewed-by: lancea ------------- PR: https://git.openjdk.java.net/jdk/pull/5925 From mgronlun at openjdk.java.net Wed Oct 13 17:49:18 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 13 Oct 2021 17:49:18 GMT Subject: RFR: 8266936: Add a finalization JFR event [v15] In-Reply-To: References: Message-ID: > Greetings, > > Object.finalize() was deprecated in JDK9. There is an ongoing effort to replace and mitigate Object.finalize() uses in the JDK libraries; please see https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. > > We also like to assist users in replacing and mitigating uses in non-JDK code. > > Hence, this changeset adds a periodic JFR event to help identify which classes are overriding Object.finalize(). > > Thanks > Markus Markus Gr?nlund has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 44 commits: - Merge branch '8266936-alt' of github.com:mgronlun/jdk into 8266936-alt - symbols-unix - jvm.h and JVM_Entry - no precompiled headers and mtServiceability nmt classification - remove rehashing and rely on default grow_hint for table resize - mtStatistics - localize - cleanup - FinalizerStatistics - Model as finalizerService - ... and 34 more: https://git.openjdk.java.net/jdk/compare/124f8237...5359a793 ------------- Changes: https://git.openjdk.java.net/jdk/pull/4731/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=14 Stats: 1893 lines in 36 files changed: 1375 ins; 409 del; 109 mod Patch: https://git.openjdk.java.net/jdk/pull/4731.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4731/head:pull/4731 PR: https://git.openjdk.java.net/jdk/pull/4731 From lancea at openjdk.java.net Wed Oct 13 17:51:59 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 13 Oct 2021 17:51:59 GMT Subject: RFR: 8275163: Deflater::deflate methods omit javadoc for ReadOnlyBufferException Message-ID: <4urLy1RPeFcDkf62nUQf3ijw8FGxNJhjYD8pTvYK0Xc=.ec34d620-1240-4b01-9fae-44823f20c90d@github.com> Hi all, Please review the fix to address a javadoc issue for the Deflater::deflate methods that were added as part of JDK-6341887 that could throw a ReadOnlyBufferException. The` @throws ` clause for `ReadOnlyBufferException` was inadvertently omitted from the javadoc for these new methods. A CSR, JDK-8275164, has also been created for this issue. Best Lance ------------- Commit messages: - Add missing @throws for ReadOnlyBufferException Changes: https://git.openjdk.java.net/jdk/pull/5931/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5931&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275163 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5931.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5931/head:pull/5931 PR: https://git.openjdk.java.net/jdk/pull/5931 From mgronlun at openjdk.java.net Wed Oct 13 18:03:25 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 13 Oct 2021 18:03:25 GMT Subject: RFR: 8266936: Add a finalization JFR event [v16] In-Reply-To: References: Message-ID: > Greetings, > > Object.finalize() was deprecated in JDK9. There is an ongoing effort to replace and mitigate Object.finalize() uses in the JDK libraries; please see https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. > > We also like to assist users in replacing and mitigating uses in non-JDK code. > > Hence, this changeset adds a periodic JFR event to help identify which classes are overriding Object.finalize(). > > Thanks > Markus Markus Gr?nlund has 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 two new commits since the last revision: - cleanup - rebased and adjusted for new lock rankings ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4731/files - new: https://git.openjdk.java.net/jdk/pull/4731/files/5359a793..96a9d6bf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=15 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=14-15 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4731.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4731/head:pull/4731 PR: https://git.openjdk.java.net/jdk/pull/4731 From itakiguchi at openjdk.java.net Wed Oct 13 18:11:49 2021 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Wed, 13 Oct 2021 18:11:49 GMT Subject: RFR: 8274544: Langtools command's usage were garbled on Japanese Windows [v3] In-Reply-To: References: Message-ID: On Fri, 8 Oct 2021 21:07:32 GMT, Naoto Sato wrote: >> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision: >> >> 8274544: Langtools command's usage were garbled on Japanese Windows > > BTW, does the PoC in the jshell bug report really causing the issue? > > System.out.println("\u3042") > > This is ASCII, so save/restore does not seem to cause any issues across JDKs with and without JEP400. Did you mean `Systemout.println("?")` instead? Hello @naotoj . Sorry I'm late. I'd like to show you jshell issue step by step. 1. `System.out.println(...)` did not work if non-ASCII character was printed on JDK18-b13. Because jshell output encoding was MS932, jshell agent output encoding was UTF-8 ![jshell-932-01](https://user-images.githubusercontent.com/33543753/137185670-02bcec50-d5af-4515-b16b-2893094732d5.png) 2. Above fix was applied against `JShellToolProvider.java` only. The issue was not fixed. ![jshell-932-02](https://user-images.githubusercontent.com/33543753/137186394-2c8bab09-7889-42d4-bbb7-2fb7b8a86a80.png) 3. Just applied lahodaj's fix `JShellToolBuilder.java`. It worked fine as expected ![jshell-932-03](https://user-images.githubusercontent.com/33543753/137187148-d1eb0821-599a-4c27-a739-434ed21ff5b6.png) 4. I checked compatibility between JDK17 and this fix by using `/save` and `/open` It seemed saved a.jsh's encoding was MS932 ![jshell-932-04](https://user-images.githubusercontent.com/33543753/137187671-b271a772-790d-4925-aa84-dc003e904c34.png) 5. I think jshell and agent should use same `file.encoding` system property. I applied following fix. --- a/src/jdk.jshell/share/classes/jdk/jshell/execution/JdiInitiator.java +++ b/src/jdk.jshell/share/classes/jdk/jshell/execution/JdiInitiator.java @@ -27,6 +27,7 @@ package jdk.jshell.execution; import java.io.File; import java.io.IOException; import java.nio.charset.StandardCharsets; +import java.nio.charset.Charset; import java.nio.file.Files; import java.util.ArrayList; import java.util.HashMap; @@ -86,6 +87,17 @@ public class JdiInitiator { Map customConnectorArgs) { this.remoteAgent = remoteAgent; this.connectTimeout = (int) (timeout * CONNECT_TIMEOUT_FACTOR); + if (!StandardCharsets.UTF_8.equals(Charset.defaultCharset())) { + boolean encodingFlag = true; + for (String s : remoteVMOptions.toArray(new String[0])) { + if (s.startsWith("-Dfile.encoding=")) + encodingFlag = false; + } + if (encodingFlag) { + remoteVMOptions.add("-Dfile.encoding=" + +Charset.defaultCharset().name()); + } + } String connectorName = isLaunch ? "com.sun.jdi.CommandLineLaunch" ![image](https://user-images.githubusercontent.com/33543753/137186123-46ba46cb-e1ac-4a9f-ac77-05c2502cd368.png) I think `JShellToolBuilder.java` and `JdiInitiator.java`. Could you give me some suggestions ? ------------- PR: https://git.openjdk.java.net/jdk/pull/5771 From bpb at openjdk.java.net Wed Oct 13 18:22:51 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 13 Oct 2021 18:22:51 GMT Subject: RFR: 8275163: Deflater::deflate methods omit javadoc for ReadOnlyBufferException In-Reply-To: <4urLy1RPeFcDkf62nUQf3ijw8FGxNJhjYD8pTvYK0Xc=.ec34d620-1240-4b01-9fae-44823f20c90d@github.com> References: <4urLy1RPeFcDkf62nUQf3ijw8FGxNJhjYD8pTvYK0Xc=.ec34d620-1240-4b01-9fae-44823f20c90d@github.com> Message-ID: On Wed, 13 Oct 2021 17:43:29 GMT, Lance Andersen wrote: > Hi all, > > Please review the fix to address a javadoc issue for the Deflater::deflate methods that were added as part of JDK-6341887 that could throw a ReadOnlyBufferException. > > The` @throws ` clause for `ReadOnlyBufferException` was inadvertently omitted from the javadoc for these new methods. > > A CSR, JDK-8275164, has also been created for this issue. > > Best > Lance Marked as reviewed by bpb (Reviewer). src/java.base/share/classes/java/util/zip/Deflater.java line 498: > 496: * @return the actual number of bytes of compressed data written to the > 497: * output buffer > 498: * @throws ReadOnlyBufferException if the given output buffer is read-only It could equally well simply state if the buffer is read-only but this is fine. ------------- PR: https://git.openjdk.java.net/jdk/pull/5931 From iris at openjdk.java.net Wed Oct 13 18:28:54 2021 From: iris at openjdk.java.net (Iris Clark) Date: Wed, 13 Oct 2021 18:28:54 GMT Subject: RFR: 8275163: Deflater::deflate methods omit javadoc for ReadOnlyBufferException In-Reply-To: <4urLy1RPeFcDkf62nUQf3ijw8FGxNJhjYD8pTvYK0Xc=.ec34d620-1240-4b01-9fae-44823f20c90d@github.com> References: <4urLy1RPeFcDkf62nUQf3ijw8FGxNJhjYD8pTvYK0Xc=.ec34d620-1240-4b01-9fae-44823f20c90d@github.com> Message-ID: On Wed, 13 Oct 2021 17:43:29 GMT, Lance Andersen wrote: > Hi all, > > Please review the fix to address a javadoc issue for the Deflater::deflate methods that were added as part of JDK-6341887 that could throw a ReadOnlyBufferException. > > The` @throws ` clause for `ReadOnlyBufferException` was inadvertently omitted from the javadoc for these new methods. > > A CSR, JDK-8275164, has also been created for this issue. > > Best > Lance Associated CSR also Reviewed. ------------- Marked as reviewed by iris (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5931 From lancea at openjdk.java.net Wed Oct 13 18:28:56 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 13 Oct 2021 18:28:56 GMT Subject: RFR: 8275163: Deflater::deflate methods omit javadoc for ReadOnlyBufferException In-Reply-To: References: <4urLy1RPeFcDkf62nUQf3ijw8FGxNJhjYD8pTvYK0Xc=.ec34d620-1240-4b01-9fae-44823f20c90d@github.com> Message-ID: On Wed, 13 Oct 2021 18:20:03 GMT, Brian Burkhalter wrote: >> Hi all, >> >> Please review the fix to address a javadoc issue for the Deflater::deflate methods that were added as part of JDK-6341887 that could throw a ReadOnlyBufferException. >> >> The` @throws ` clause for `ReadOnlyBufferException` was inadvertently omitted from the javadoc for these new methods. >> >> A CSR, JDK-8275164, has also been created for this issue. >> >> Best >> Lance > > src/java.base/share/classes/java/util/zip/Deflater.java line 498: > >> 496: * @return the actual number of bytes of compressed data written to the >> 497: * output buffer >> 498: * @throws ReadOnlyBufferException if the given output buffer is read-only > > It could equally well simply state > > if the buffer is read-only > > but this is fine. I thought about that but I decided to go with the wording used for the change to Inflater::inflate that was added as part of JDK-6341887. If I were to change it, I would want to change Inflater::inflate as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/5931 From bpb at openjdk.java.net Wed Oct 13 18:28:56 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 13 Oct 2021 18:28:56 GMT Subject: RFR: 8275163: Deflater::deflate methods omit javadoc for ReadOnlyBufferException In-Reply-To: References: <4urLy1RPeFcDkf62nUQf3ijw8FGxNJhjYD8pTvYK0Xc=.ec34d620-1240-4b01-9fae-44823f20c90d@github.com> Message-ID: On Wed, 13 Oct 2021 18:24:39 GMT, Lance Andersen wrote: >> src/java.base/share/classes/java/util/zip/Deflater.java line 498: >> >>> 496: * @return the actual number of bytes of compressed data written to the >>> 497: * output buffer >>> 498: * @throws ReadOnlyBufferException if the given output buffer is read-only >> >> It could equally well simply state >> >> if the buffer is read-only >> >> but this is fine. > > I thought about that but I decided to go with the wording used for the change to Inflater::inflate that was added as part of JDK-6341887. If I were to change it, I would want to change Inflater::inflate as well. I retract my previous comment: I think you made the correct decision. ------------- PR: https://git.openjdk.java.net/jdk/pull/5931 From naoto at openjdk.java.net Wed Oct 13 18:36:50 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 13 Oct 2021 18:36:50 GMT Subject: RFR: 8275163: Deflater::deflate methods omit javadoc for ReadOnlyBufferException In-Reply-To: <4urLy1RPeFcDkf62nUQf3ijw8FGxNJhjYD8pTvYK0Xc=.ec34d620-1240-4b01-9fae-44823f20c90d@github.com> References: <4urLy1RPeFcDkf62nUQf3ijw8FGxNJhjYD8pTvYK0Xc=.ec34d620-1240-4b01-9fae-44823f20c90d@github.com> Message-ID: On Wed, 13 Oct 2021 17:43:29 GMT, Lance Andersen wrote: > Hi all, > > Please review the fix to address a javadoc issue for the Deflater::deflate methods that were added as part of JDK-6341887 that could throw a ReadOnlyBufferException. > > The` @throws ` clause for `ReadOnlyBufferException` was inadvertently omitted from the javadoc for these new methods. > > A CSR, JDK-8275164, has also been created for this issue. > > Best > Lance Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5931 From psandoz at openjdk.java.net Wed Oct 13 18:37:23 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 13 Oct 2021 18:37:23 GMT Subject: RFR: 8271515: Integration of JEP 417: Vector API (Third Incubator) Message-ID: <_QQ9ntdJJfzVcAGrbjev0ZM-xNfD4wNATphnXkb-Y00=.bbf46985-8776-4dda-ada5-b15ab50774aa@github.com> This PR improves the performance of vector operations that accept masks on architectures that support masking in hardware, specifically Intel AVX512 and ARM SVE. On architectures that do not support masking in hardware the same technique as before is applied to most operations, specifically composition using blend. Masked loads/stores are a special form of masked operation that require additional care to ensure out-of-bounds access throw exceptions. The range checking has not been fully optimized and will require further work. No API enhancements were required and only a few additional tests were needed. ------------- Commit messages: - Apply patch from https://github.com/openjdk/panama-vector/pull/142 - Apply patch from https://github.com/openjdk/panama-vector/pull/139 - Apply patch from https://github.com/openjdk/panama-vector/pull/151 - Add new files. - 8271515: Integration of JEP 417: Vector API (Third Incubator) Changes: https://git.openjdk.java.net/jdk/pull/5873/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5873&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271515 Stats: 21999 lines in 106 files changed: 16228 ins; 2077 del; 3694 mod Patch: https://git.openjdk.java.net/jdk/pull/5873.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5873/head:pull/5873 PR: https://git.openjdk.java.net/jdk/pull/5873 From naoto at openjdk.java.net Wed Oct 13 18:42:52 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 13 Oct 2021 18:42:52 GMT Subject: RFR: 8275197: Remove unused fields in ThaiBuddhistChronology In-Reply-To: References: Message-ID: On Tue, 12 Oct 2021 21:10:12 GMT, Andrey Turbanov wrote: > Remove 3 unused HashMap's. > Reported here https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-September/081866.html > I did the similar PR to treetenbp and it was merged https://github.com/ThreeTen/threetenbp/pull/155 Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5917 From mchung at openjdk.java.net Wed Oct 13 18:53:22 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 13 Oct 2021 18:53:22 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v13] In-Reply-To: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> Message-ID: > This reimplements core reflection with method handles. > > For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. > > The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. > > The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. > > Ran tier1-tier8 tests. > > [1] https://bugs.openjdk.java.net/browse/JDK-8013527 > [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: Minor cleanup. Improve javadoc in CallerSensitiveAdapter ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5027/files - new: https://git.openjdk.java.net/jdk/pull/5027/files/86d34f48..c25d651a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5027&range=12 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5027&range=11-12 Stats: 95 lines in 3 files changed: 83 ins; 0 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/5027.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5027/head:pull/5027 PR: https://git.openjdk.java.net/jdk/pull/5027 From cjplummer at openjdk.java.net Wed Oct 13 19:14:55 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 13 Oct 2021 19:14:55 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v13] In-Reply-To: References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> Message-ID: On Wed, 13 Oct 2021 18:53:22 GMT, Mandy Chung wrote: >> This reimplements core reflection with method handles. >> >> For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. >> >> The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. >> >> The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. >> >> Ran tier1-tier8 tests. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8013527 >> [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > Minor cleanup. Improve javadoc in CallerSensitiveAdapter The JDI problem list and EATest.java changes are approved. test/hotspot/jtreg/ProblemList.txt line 43: > 41: vmTestbase/nsk/jvmti/AttachOnDemand/attach002a/TestDescription.java 8265795 generic-all > 42: vmTestbase/nsk/jvmti/AttachOnDemand/attach022/TestDescription.java 8265795 generic-all > 43: vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java 8265796 generic-all Approved. test/jdk/com/sun/jdi/EATests.java line 2203: > 2201: // the method depth in debuggee is 11 as it includes all hidden frames > 2202: // the expected method depth is 6 excluding 5 hidden frames > 2203: testMethodDepth = 11-5; Approved. ------------- Marked as reviewed by cjplummer (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5027 From kvn at openjdk.java.net Wed Oct 13 19:35:52 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 13 Oct 2021 19:35:52 GMT Subject: RFR: 8271515: Integration of JEP 417: Vector API (Third Incubator) In-Reply-To: <_QQ9ntdJJfzVcAGrbjev0ZM-xNfD4wNATphnXkb-Y00=.bbf46985-8776-4dda-ada5-b15ab50774aa@github.com> References: <_QQ9ntdJJfzVcAGrbjev0ZM-xNfD4wNATphnXkb-Y00=.bbf46985-8776-4dda-ada5-b15ab50774aa@github.com> Message-ID: On Fri, 8 Oct 2021 21:25:26 GMT, Paul Sandoz wrote: > This PR improves the performance of vector operations that accept masks on architectures that support masking in hardware, specifically Intel AVX512 and ARM SVE. > > On architectures that do not support masking in hardware the same technique as before is applied to most operations, specifically composition using blend. > > Masked loads/stores are a special form of masked operation that require additional care to ensure out-of-bounds access throw exceptions. The range checking has not been fully optimized and will require further work. > > No API enhancements were required and only a few additional tests were needed. C2 and x86 changes seems fine. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5873 From darcy at openjdk.java.net Wed Oct 13 21:15:00 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 13 Oct 2021 21:15:00 GMT Subject: RFR: JDK-8275249: Suppress warnings on non-serializable array component types in jdk.jlink Message-ID: After a refinement to the checks under development in #5709, the new checks examine array types of serial fields and warn if the underlying component type is not serializable. Per the JLS, all array types are serializable, but if the base component is not serializable, the serialization process can throw an exception. >From "Java Object Serialization Specification: 2 - Object Output Classes": "If the object is an array, writeObject is called recursively to write the ObjectStreamClass of the array. The handle for the array is assigned. It is followed by the length of the array. Each element of the array is then written to the stream, after which writeObject returns." The jdk.jlink module has one instance of this coding pattern that needs suppression to compile successfully under the future warning. ------------- Commit messages: - JDK-8275249: Suppress warnings on non-serializable array component types in jdk.jlink Changes: https://git.openjdk.java.net/jdk/pull/5936/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5936&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275249 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5936.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5936/head:pull/5936 PR: https://git.openjdk.java.net/jdk/pull/5936 From iris at openjdk.java.net Wed Oct 13 22:00:48 2021 From: iris at openjdk.java.net (Iris Clark) Date: Wed, 13 Oct 2021 22:00:48 GMT Subject: RFR: JDK-8275249: Suppress warnings on non-serializable array component types in jdk.jlink In-Reply-To: References: Message-ID: <8rD0H676ztjJ1HK1ONB3zMFVJtF4hyyZlvYHX421JG4=.bbb77d9c-1d95-4713-97a8-482694d4fbd5@github.com> On Wed, 13 Oct 2021 21:08:41 GMT, Joe Darcy wrote: > After a refinement to the checks under development in #5709, the new checks examine array types of serial fields and warn if the underlying component type is not serializable. Per the JLS, all array types are serializable, but if the base component is not serializable, the serialization process can throw an exception. > > From "Java Object Serialization Specification: 2 - Object Output Classes": > > "If the object is an array, writeObject is called recursively to write the ObjectStreamClass of the array. The handle for the array is assigned. It is followed by the length of the array. Each element of the array is then written to the stream, after which writeObject returns." > > The jdk.jlink module has one instance of this coding pattern that needs suppression to compile successfully under the future warning. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5936 From duke at openjdk.java.net Wed Oct 13 22:30:07 2021 From: duke at openjdk.java.net (TatWai Chong) Date: Wed, 13 Oct 2021 22:30:07 GMT Subject: RFR: 8269559: AArch64: Implement string_compare intrinsic in SVE [v3] In-Reply-To: References: Message-ID: > This patch implements string_compare intrinsic in SVE. > It supports all LL, LU, UL and UU comparisons. > > As we haven't found an existing benchmark to measure performance impact, > we created a benchmark derived from the test [1] for this evaluation. > This benchmark is attached to this patch. > > Besides, remove the unused temporary register `vtmp3` from the existing > match rules for StrCmp. > > The result below shows all varients can be benefited largely. > Command: make exploded-test TEST="micro:StringCompareToDifferentLength" > > Benchmark (size) Mode Cnt Score Speedup Units > compareToLL 24 avgt 10 1.0x ms/op > compareToLL 36 avgt 10 1.0x ms/op > compareToLL 72 avgt 10 1.0x ms/op > compareToLL 128 avgt 10 1.4x ms/op > compareToLL 256 avgt 10 1.8x ms/op > compareToLL 512 avgt 10 2.7x ms/op > compareToLU 24 avgt 10 1.6x ms/op > compareToLU 36 avgt 10 1.8x ms/op > compareToLU 72 avgt 10 2.3x ms/op > compareToLU 128 avgt 10 3.8x ms/op > compareToLU 256 avgt 10 4.7x ms/op > compareToLU 512 avgt 10 6.3x ms/op > compareToUL 24 avgt 10 1.6x ms/op > compareToUL 36 avgt 10 1.7x ms/op > compareToUL 72 avgt 10 2.2x ms/op > compareToUL 128 avgt 10 3.3x ms/op > compareToUL 256 avgt 10 4.4x ms/op > compareToUL 512 avgt 10 6.1x ms/op > compareToUU 24 avgt 10 1.0x ms/op > compareToUU 36 avgt 10 1.0x ms/op > compareToUU 72 avgt 10 1.4x ms/op > compareToUU 128 avgt 10 2.2x ms/op > compareToUU 256 avgt 10 2.6x ms/op > compareToUU 512 avgt 10 3.7x ms/op > > [1] https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/compiler/intrinsics/string/TestStringCompareToDifferentLength.java TatWai Chong has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge master - Restore the removal of vtmp3 (=V2) as it is still used by the non-SVE compare-long-strings stub. And remove the assertion in `string_compare` since it won't help as the registers used in the stub are fixed. - 8269559: AArch64: Implement string_compare intrinsic in SVE This patch implements string_compare intrinsic in SVE. It supports all LL, LU, UL and UU comparisons. As we haven't found an existing benchmark to measure performance impact, we created a benchmark derived from the test [1] for this evaluation. This benchmark is attached to this patch. Besides, remove the unused temporary register `vtmp3` from the existing match rules for StrCmp. The result below shows all varients can be benefited largely. Command: make exploded-test TEST="micro:StringCompareToDifferentLength" Benchmark (size) Mode Cnt Score Speedup Units compareToLL 24 avgt 10 1.0x ms/op compareToLL 36 avgt 10 1.0x ms/op compareToLL 72 avgt 10 1.0x ms/op compareToLL 128 avgt 10 1.4x ms/op compareToLL 256 avgt 10 1.8x ms/op compareToLL 512 avgt 10 2.7x ms/op compareToLU 24 avgt 10 1.6x ms/op compareToLU 36 avgt 10 1.8x ms/op compareToLU 72 avgt 10 2.3x ms/op compareToLU 128 avgt 10 3.8x ms/op compareToLU 256 avgt 10 4.7x ms/op compareToLU 512 avgt 10 6.3x ms/op compareToUL 24 avgt 10 1.6x ms/op compareToUL 36 avgt 10 1.7x ms/op compareToUL 72 avgt 10 2.2x ms/op compareToUL 128 avgt 10 3.3x ms/op compareToUL 256 avgt 10 4.4x ms/op compareToUL 512 avgt 10 6.1x ms/op compareToUU 24 avgt 10 1.0x ms/op compareToUU 36 avgt 10 1.0x ms/op compareToUU 72 avgt 10 1.4x ms/op compareToUU 128 avgt 10 2.2x ms/op compareToUU 256 avgt 10 2.6x ms/op compareToUU 512 avgt 10 3.7x ms/op [1] https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/compiler/intrinsics/string/TestStringCompareToDifferentLength.java ------------- Changes: https://git.openjdk.java.net/jdk/pull/5129/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5129&range=02 Stats: 517 lines in 11 files changed: 421 ins; 1 del; 95 mod Patch: https://git.openjdk.java.net/jdk/pull/5129.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5129/head:pull/5129 PR: https://git.openjdk.java.net/jdk/pull/5129 From duke at openjdk.java.net Wed Oct 13 23:33:54 2021 From: duke at openjdk.java.net (duke) Date: Wed, 13 Oct 2021 23:33:54 GMT Subject: Withdrawn: 8153490: Cannot setBytes() if incoming buffer's length is bigger than number of elements we want to insert. In-Reply-To: References: Message-ID: On Wed, 12 May 2021 17:48:50 GMT, Mitsuru Kariya wrote: > Fix `SerialBlob.setBytes(long pos, byte[] bytes, int offset, int length)` in the following cases: > > 1. `pos - 1 + bytes.length - offset > this.length() && pos - 1 + length <= this.length()` > The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully. > (test31) > > 2. `pos - 1 + length > this.length()` > The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully. *1 > (test32) > > 3. `pos == this.length() + 1` > The original implementation throws `SerialException` but this case should end successfully. *2 > (test33) > > 4. `length < 0` > The original implementation throws `ArrayIndexOutOfBoundsException` but this case should throw `SerialException`. > (test34) > > 5. `offset + length > Integer.MAX_VALUE` > The original implementation throws `ArrayIndexOutOfBoundsException` (or `OutOfMemoryError` in most cases) but this case should throw `SerialException`. > (test35) > > Additionally, fix `SerialClob.setString(long pos, String str, int offset, int length)` in the following cases: > > 1. `offset > str.length()` > The original implementaion throws `StringIndexOutOfBoundsException` but this case should throw `SerialException`. > (test39) > > 2. `pos - 1 + str.length() - offset > this.length() && pos - 1 + length <= this.length()` > The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully. > (test32) > > 3. `pos - 1 + length > this.length()` > The original implementaion throws `SerialException` but this case should end successfully. *3 > (test40) > > 4. `pos == this.length() + 1` > The original implementaion throws `SerialException` but this case should end successfully. *4 > (test41) > > 5. `length < 0` > The original implementation throws `StringIndexOutOfBoundsException` but this case should throw `SerialException`. > (test42) > > 6. `offset + length > Integer.MAX_VALUE` > The original implementation throws `ArrayIndexOutOfBoundsException` (or `OutOfMemoryError` in most cases) but this case should throw `SerialException`. > (test43) > > > The javadoc has also been modified according to the above. > > *1 The documentation of `Blob.setBytes()` says, "If the end of the Blob value is reached while writing the array of bytes, then the length of the Blob value will be increased to accommodate the extra bytes." > > *2 The documentation of `Blob.setBytes()` says, "If the value specified for pos is greater than the length+1 of the BLOB value then the behavior is undefined." > So, it should work correctly when pos == length+1 of the BLOB value. > > *3 The documentation of `Clob.setString()` says, "If the end of the Clob value is eached while writing the given string, then the length of the Clob value will be increased to accommodate the extra characters." > > *4 The documentation of `Clob.setString()` says, "If the value specified for pos is greater than the length+1 of the CLOB value then the behavior is undefined." > So, it should work correctly when pos == length+1 of the CLOB value. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/4001 From mcimadamore at openjdk.java.net Thu Oct 14 00:26:55 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 14 Oct 2021 00:26:55 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v13] In-Reply-To: References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> Message-ID: On Wed, 13 Oct 2021 18:53:22 GMT, Mandy Chung wrote: >> This reimplements core reflection with method handles. >> >> For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. >> >> The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. >> >> The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. >> >> Ran tier1-tier8 tests. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8013527 >> [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > Minor cleanup. Improve javadoc in CallerSensitiveAdapter Looks a very good simplification. It's great that in the new `poly` benchmarks the regression is so contained (I was frankly expecting more), and I agree with the comments (super interesting discussion btw!) that Poly is probably the most relevant case out there. I noted that in the static case, Poly does regress for fields - do we know why instance Poly is better than static Poly? That seems surprising. src/java.base/share/classes/jdk/internal/reflect/DirectMethodHandleAccessor.java line 58: > 56: * Creates a MethodAccessorImpl for a caller-sensitive method. > 57: */ > 58: static MethodAccessorImpl callerSensitiveMethodAccessor(Method method, MethodHandle dmh) { This method and the one above are identical - they just call `new DirectMethodHandleAccessor` with same parameters. Is the distinction between these two factories still relevant? (besides the different asserts) src/java.base/share/classes/jdk/internal/reflect/DirectMethodHandleAccessor.java line 86: > 84: } > 85: > 86: private static final int PARAM_COUNT_MASK = 0x00FF; Is this packing logic required? I get it that it saves footprint - but then you have to always unmask bits to get the argument count (see invoke and other places). If you keep this, it might be worth documenting what the bit layout is supposed to be? src/java.base/share/classes/jdk/internal/reflect/MethodHandleAccessorFactory.java line 151: > 149: var setter = isReadOnly ? null : JLIA.unreflectField(field, true); > 150: Class type = field.getType(); > 151: if (type == Boolean.TYPE) { dumb question: any reason why `boolean.class` (which is compiled to a LDC) is not used? ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5027 From mchung at openjdk.java.net Thu Oct 14 00:54:53 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 14 Oct 2021 00:54:53 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v13] In-Reply-To: References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> Message-ID: On Wed, 13 Oct 2021 23:49:19 GMT, Maurizio Cimadamore wrote: >> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> Minor cleanup. Improve javadoc in CallerSensitiveAdapter > > src/java.base/share/classes/jdk/internal/reflect/DirectMethodHandleAccessor.java line 58: > >> 56: * Creates a MethodAccessorImpl for a caller-sensitive method. >> 57: */ >> 58: static MethodAccessorImpl callerSensitiveMethodAccessor(Method method, MethodHandle dmh) { > > This method and the one above are identical - they just call `new DirectMethodHandleAccessor` with same parameters. Is the distinction between these two factories still relevant? (besides the different asserts) Good catch! It no longer needs this distinction in this new version. Will remove it. ------------- PR: https://git.openjdk.java.net/jdk/pull/5027 From mchung at openjdk.java.net Thu Oct 14 00:57:50 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 14 Oct 2021 00:57:50 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v13] In-Reply-To: References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> Message-ID: <_XTZju-Itu7LJ6br_wNN5PQr1DWmCsFY7ehTpWEU3bo=.316e7a9c-d79b-4768-aca2-d1116244a7a8@github.com> On Thu, 14 Oct 2021 00:10:50 GMT, Maurizio Cimadamore wrote: >> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> Minor cleanup. Improve javadoc in CallerSensitiveAdapter > > src/java.base/share/classes/jdk/internal/reflect/MethodHandleAccessorFactory.java line 151: > >> 149: var setter = isReadOnly ? null : JLIA.unreflectField(field, true); >> 150: Class type = field.getType(); >> 151: if (type == Boolean.TYPE) { > > dumb question: any reason why `boolean.class` (which is compiled to a LDC) is not used? I only see `boolean.class` compiled to `getstatic Boolean.TYPE`. Is there a javac flag to compile it to a LDC? ------------- PR: https://git.openjdk.java.net/jdk/pull/5027 From duke at openjdk.java.net Thu Oct 14 01:17:17 2021 From: duke at openjdk.java.net (TatWai Chong) Date: Thu, 14 Oct 2021 01:17:17 GMT Subject: RFR: 8269559: AArch64: Implement string_compare intrinsic in SVE [v4] In-Reply-To: References: Message-ID: > This patch implements string_compare intrinsic in SVE. > It supports all LL, LU, UL and UU comparisons. > > As we haven't found an existing benchmark to measure performance impact, > we created a benchmark derived from the test [1] for this evaluation. > This benchmark is attached to this patch. > > Besides, remove the unused temporary register `vtmp3` from the existing > match rules for StrCmp. > > The result below shows all varients can be benefited largely. > Command: make exploded-test TEST="micro:StringCompareToDifferentLength" > > Benchmark (size) Mode Cnt Score Speedup Units > compareToLL 24 avgt 10 1.0x ms/op > compareToLL 36 avgt 10 1.0x ms/op > compareToLL 72 avgt 10 1.0x ms/op > compareToLL 128 avgt 10 1.4x ms/op > compareToLL 256 avgt 10 1.8x ms/op > compareToLL 512 avgt 10 2.7x ms/op > compareToLU 24 avgt 10 1.6x ms/op > compareToLU 36 avgt 10 1.8x ms/op > compareToLU 72 avgt 10 2.3x ms/op > compareToLU 128 avgt 10 3.8x ms/op > compareToLU 256 avgt 10 4.7x ms/op > compareToLU 512 avgt 10 6.3x ms/op > compareToUL 24 avgt 10 1.6x ms/op > compareToUL 36 avgt 10 1.7x ms/op > compareToUL 72 avgt 10 2.2x ms/op > compareToUL 128 avgt 10 3.3x ms/op > compareToUL 256 avgt 10 4.4x ms/op > compareToUL 512 avgt 10 6.1x ms/op > compareToUU 24 avgt 10 1.0x ms/op > compareToUU 36 avgt 10 1.0x ms/op > compareToUU 72 avgt 10 1.4x ms/op > compareToUU 128 avgt 10 2.2x ms/op > compareToUU 256 avgt 10 2.6x ms/op > compareToUU 512 avgt 10 3.7x ms/op > > [1] https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/compiler/intrinsics/string/TestStringCompareToDifferentLength.java TatWai Chong has updated the pull request incrementally with one additional commit since the last revision: Replace `sve_cmpne` with up-to-date `sve_cmp`. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5129/files - new: https://git.openjdk.java.net/jdk/pull/5129/files/4a584089..7799f934 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5129&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5129&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5129.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5129/head:pull/5129 PR: https://git.openjdk.java.net/jdk/pull/5129 From duke at openjdk.java.net Thu Oct 14 01:49:48 2021 From: duke at openjdk.java.net (Mitsuru Kariya) Date: Thu, 14 Oct 2021 01:49:48 GMT Subject: RFR: 8153490: Cannot setBytes() if incoming buffer's length is bigger than number of elements we want to insert. [v4] In-Reply-To: References: Message-ID: <_tHPXNasHvbTb633vjjGNy-D5xN92ypyHq_2MTNlVdc=.c815fc4e-f65d-4c23-97ee-91730a1c9891@github.com> On Wed, 15 Sep 2021 17:57:35 GMT, Lance Andersen wrote: >> Mitsuru Kariya has updated the pull request incrementally with one additional commit since the last revision: >> >> Modify javadoc for consistency > > src/java.sql.rowset/share/classes/javax/sql/rowset/serial/SerialBlob.java line 337: > >> 335: * @param bytes the array of bytes to be written to the {@code BLOB} >> 336: * value >> 337: * @param offset the offset into the array {@code bytes} at which > > Please change all occurrences of `{@code bytes}` to `{@code byte}s` as this was caught as part of the CSR review. Sorry for my very slow response. These `{@code bytes}` point to the `bytes` argument, but should I change it to `{@code byte}s`? ------------- PR: https://git.openjdk.java.net/jdk/pull/4001 From wuyan at openjdk.java.net Thu Oct 14 02:08:45 2021 From: wuyan at openjdk.java.net (Wu Yan) Date: Thu, 14 Oct 2021 02:08:45 GMT Subject: RFR: 8273111: Default timezone should return zone ID if /etc/localtime is valid but not canonicalization on linux [v4] In-Reply-To: <6gmVj3r1hjhG5jvo_dSly3ShNnZZSCn-NIjtnvSySrk=.a88def27-7b80-425b-9ab8-2f94f5004b47@github.com> References: <6gmVj3r1hjhG5jvo_dSly3ShNnZZSCn-NIjtnvSySrk=.a88def27-7b80-425b-9ab8-2f94f5004b47@github.com> Message-ID: > Hi, > Please help me review the change to enhance getting time zone ID from /etc/localtime on linux. > > We use `realpath` instead of `readlink` to obtain the link name of /etc/localtime, because `readlink` can only read the value of a symbolic of link, not the canonicalized absolute pathname. > > For example, the value of /etc/localtime is "../usr/share/zoneinfo//Asia/Shanghai", then the linkbuf obtained by `readlink` is "../usr/share/zoneinfo//Asia/Shanghai", and then the call of `getZoneName(linkbuf)` will get "/Asia/Shanghai", not "Asia/Shanghai", which consider as invalid in `ZoneInfoFile.getZoneInfo()`. Using `realpath`, you can get ?/usr/share/zoneinfo/Asia/Shanghai? directly from ?/etc/localtime?. > > Thanks, > wuyan Wu Yan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Merge branch 'master' into timezone - change functions to be static - replace realpath - 8273111: Default timezone should return zone ID if /etc/localtime is valid but not canonicalization on linux ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5327/files - new: https://git.openjdk.java.net/jdk/pull/5327/files/38177cd0..93cff3d1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5327&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5327&range=02-03 Stats: 1449026 lines in 13982 files changed: 735454 ins; 659127 del; 54445 mod Patch: https://git.openjdk.java.net/jdk/pull/5327.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5327/head:pull/5327 PR: https://git.openjdk.java.net/jdk/pull/5327 From duke at openjdk.java.net Thu Oct 14 05:30:54 2021 From: duke at openjdk.java.net (TatWai Chong) Date: Thu, 14 Oct 2021 05:30:54 GMT Subject: Integrated: 8269559: AArch64: Implement string_compare intrinsic in SVE In-Reply-To: References: Message-ID: On Mon, 16 Aug 2021 20:59:55 GMT, TatWai Chong wrote: > This patch implements string_compare intrinsic in SVE. > It supports all LL, LU, UL and UU comparisons. > > As we haven't found an existing benchmark to measure performance impact, > we created a benchmark derived from the test [1] for this evaluation. > This benchmark is attached to this patch. > > Besides, remove the unused temporary register `vtmp3` from the existing > match rules for StrCmp. > > The result below shows all varients can be benefited largely. > Command: make exploded-test TEST="micro:StringCompareToDifferentLength" > > Benchmark (size) Mode Cnt Score Speedup Units > compareToLL 24 avgt 10 1.0x ms/op > compareToLL 36 avgt 10 1.0x ms/op > compareToLL 72 avgt 10 1.0x ms/op > compareToLL 128 avgt 10 1.4x ms/op > compareToLL 256 avgt 10 1.8x ms/op > compareToLL 512 avgt 10 2.7x ms/op > compareToLU 24 avgt 10 1.6x ms/op > compareToLU 36 avgt 10 1.8x ms/op > compareToLU 72 avgt 10 2.3x ms/op > compareToLU 128 avgt 10 3.8x ms/op > compareToLU 256 avgt 10 4.7x ms/op > compareToLU 512 avgt 10 6.3x ms/op > compareToUL 24 avgt 10 1.6x ms/op > compareToUL 36 avgt 10 1.7x ms/op > compareToUL 72 avgt 10 2.2x ms/op > compareToUL 128 avgt 10 3.3x ms/op > compareToUL 256 avgt 10 4.4x ms/op > compareToUL 512 avgt 10 6.1x ms/op > compareToUU 24 avgt 10 1.0x ms/op > compareToUU 36 avgt 10 1.0x ms/op > compareToUU 72 avgt 10 1.4x ms/op > compareToUU 128 avgt 10 2.2x ms/op > compareToUU 256 avgt 10 2.6x ms/op > compareToUU 512 avgt 10 3.7x ms/op > > [1] https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/compiler/intrinsics/string/TestStringCompareToDifferentLength.java This pull request has now been integrated. Changeset: 8b1b6f9f Author: TatWai Chong Committer: Nick Gasson URL: https://git.openjdk.java.net/jdk/commit/8b1b6f9fb375bbc2de339ad8f526ca4d5f83dc70 Stats: 517 lines in 11 files changed: 421 ins; 1 del; 95 mod 8269559: AArch64: Implement string_compare intrinsic in SVE Reviewed-by: ngasson, aph ------------- PR: https://git.openjdk.java.net/jdk/pull/5129 From forax at openjdk.java.net Thu Oct 14 06:05:52 2021 From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Thu, 14 Oct 2021 06:05:52 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v13] In-Reply-To: <_XTZju-Itu7LJ6br_wNN5PQr1DWmCsFY7ehTpWEU3bo=.316e7a9c-d79b-4768-aca2-d1116244a7a8@github.com> References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> <_XTZju-Itu7LJ6br_wNN5PQr1DWmCsFY7ehTpWEU3bo=.316e7a9c-d79b-4768-aca2-d1116244a7a8@github.com> Message-ID: On Thu, 14 Oct 2021 00:54:57 GMT, Mandy Chung wrote: >> src/java.base/share/classes/jdk/internal/reflect/MethodHandleAccessorFactory.java line 151: >> >>> 149: var setter = isReadOnly ? null : JLIA.unreflectField(field, true); >>> 150: Class type = field.getType(); >>> 151: if (type == Boolean.TYPE) { >> >> dumb question: any reason why `boolean.class` (which is compiled to a LDC) is not used? > > I only see `boolean.class` compiled to `getstatic Boolean.TYPE`. Is there a javac flag to compile it to a LDC? The LDC bytecode instruction for a class takes a class name not a descriptor as parameter, so there is no way to encode LDC Z. Valhalla may change that. ------------- PR: https://git.openjdk.java.net/jdk/pull/5027 From david.holmes at oracle.com Thu Oct 14 06:12:42 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 14 Oct 2021 16:12:42 +1000 Subject: Integrated: 8269559: AArch64: Implement string_compare intrinsic in SVE In-Reply-To: References: Message-ID: We are seeing a large number of Aarch64 test failures in our CI after this push. Somewhat bizarre failure modes: - truncated classfiles - unexpected EOF encountered - illegal state reading a stream I think we will need to back this change out while this is investigated further. David ----- On 14/10/2021 3:30 pm, TatWai Chong wrote: > On Mon, 16 Aug 2021 20:59:55 GMT, TatWai Chong wrote: > >> This patch implements string_compare intrinsic in SVE. >> It supports all LL, LU, UL and UU comparisons. >> >> As we haven't found an existing benchmark to measure performance impact, >> we created a benchmark derived from the test [1] for this evaluation. >> This benchmark is attached to this patch. >> >> Besides, remove the unused temporary register `vtmp3` from the existing >> match rules for StrCmp. >> >> The result below shows all varients can be benefited largely. >> Command: make exploded-test TEST="micro:StringCompareToDifferentLength" >> >> Benchmark (size) Mode Cnt Score Speedup Units >> compareToLL 24 avgt 10 1.0x ms/op >> compareToLL 36 avgt 10 1.0x ms/op >> compareToLL 72 avgt 10 1.0x ms/op >> compareToLL 128 avgt 10 1.4x ms/op >> compareToLL 256 avgt 10 1.8x ms/op >> compareToLL 512 avgt 10 2.7x ms/op >> compareToLU 24 avgt 10 1.6x ms/op >> compareToLU 36 avgt 10 1.8x ms/op >> compareToLU 72 avgt 10 2.3x ms/op >> compareToLU 128 avgt 10 3.8x ms/op >> compareToLU 256 avgt 10 4.7x ms/op >> compareToLU 512 avgt 10 6.3x ms/op >> compareToUL 24 avgt 10 1.6x ms/op >> compareToUL 36 avgt 10 1.7x ms/op >> compareToUL 72 avgt 10 2.2x ms/op >> compareToUL 128 avgt 10 3.3x ms/op >> compareToUL 256 avgt 10 4.4x ms/op >> compareToUL 512 avgt 10 6.1x ms/op >> compareToUU 24 avgt 10 1.0x ms/op >> compareToUU 36 avgt 10 1.0x ms/op >> compareToUU 72 avgt 10 1.4x ms/op >> compareToUU 128 avgt 10 2.2x ms/op >> compareToUU 256 avgt 10 2.6x ms/op >> compareToUU 512 avgt 10 3.7x ms/op >> >> [1] https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/compiler/intrinsics/string/TestStringCompareToDifferentLength.java > > This pull request has now been integrated. > > Changeset: 8b1b6f9f > Author: TatWai Chong > Committer: Nick Gasson > URL: https://git.openjdk.java.net/jdk/commit/8b1b6f9fb375bbc2de339ad8f526ca4d5f83dc70 > Stats: 517 lines in 11 files changed: 421 ins; 1 del; 95 mod > > 8269559: AArch64: Implement string_compare intrinsic in SVE > > Reviewed-by: ngasson, aph > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/5129 > From ngasson at openjdk.java.net Thu Oct 14 06:28:55 2021 From: ngasson at openjdk.java.net (Nick Gasson) Date: Thu, 14 Oct 2021 06:28:55 GMT Subject: RFR: 8269559: AArch64: Implement string_compare intrinsic in SVE [v4] In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 01:17:17 GMT, TatWai Chong wrote: >> This patch implements string_compare intrinsic in SVE. >> It supports all LL, LU, UL and UU comparisons. >> >> As we haven't found an existing benchmark to measure performance impact, >> we created a benchmark derived from the test [1] for this evaluation. >> This benchmark is attached to this patch. >> >> Besides, remove the unused temporary register `vtmp3` from the existing >> match rules for StrCmp. >> >> The result below shows all varients can be benefited largely. >> Command: make exploded-test TEST="micro:StringCompareToDifferentLength" >> >> Benchmark (size) Mode Cnt Score Speedup Units >> compareToLL 24 avgt 10 1.0x ms/op >> compareToLL 36 avgt 10 1.0x ms/op >> compareToLL 72 avgt 10 1.0x ms/op >> compareToLL 128 avgt 10 1.4x ms/op >> compareToLL 256 avgt 10 1.8x ms/op >> compareToLL 512 avgt 10 2.7x ms/op >> compareToLU 24 avgt 10 1.6x ms/op >> compareToLU 36 avgt 10 1.8x ms/op >> compareToLU 72 avgt 10 2.3x ms/op >> compareToLU 128 avgt 10 3.8x ms/op >> compareToLU 256 avgt 10 4.7x ms/op >> compareToLU 512 avgt 10 6.3x ms/op >> compareToUL 24 avgt 10 1.6x ms/op >> compareToUL 36 avgt 10 1.7x ms/op >> compareToUL 72 avgt 10 2.2x ms/op >> compareToUL 128 avgt 10 3.3x ms/op >> compareToUL 256 avgt 10 4.4x ms/op >> compareToUL 512 avgt 10 6.1x ms/op >> compareToUU 24 avgt 10 1.0x ms/op >> compareToUU 36 avgt 10 1.0x ms/op >> compareToUU 72 avgt 10 1.4x ms/op >> compareToUU 128 avgt 10 2.2x ms/op >> compareToUU 256 avgt 10 2.6x ms/op >> compareToUU 512 avgt 10 3.7x ms/op >> >> [1] https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/compiler/intrinsics/string/TestStringCompareToDifferentLength.java > > TatWai Chong has updated the pull request incrementally with one additional commit since the last revision: > > Replace `sve_cmpne` with up-to-date `sve_cmp`. Hm, I didn't see anything like that when we tested this patch internally. I'll create another PR to revert it for now. ------------- PR: https://git.openjdk.java.net/jdk/pull/5129 From david.holmes at oracle.com Thu Oct 14 06:38:26 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 14 Oct 2021 16:38:26 +1000 Subject: RFR: 8269559: AArch64: Implement string_compare intrinsic in SVE [v4] In-Reply-To: References: Message-ID: On 14/10/2021 4:28 pm, Nick Gasson wrote: > On Thu, 14 Oct 2021 01:17:17 GMT, TatWai Chong wrote: > >>> This patch implements string_compare intrinsic in SVE. >>> It supports all LL, LU, UL and UU comparisons. >>> >>> As we haven't found an existing benchmark to measure performance impact, >>> we created a benchmark derived from the test [1] for this evaluation. >>> This benchmark is attached to this patch. >>> >>> Besides, remove the unused temporary register `vtmp3` from the existing >>> match rules for StrCmp. >>> >>> The result below shows all varients can be benefited largely. >>> Command: make exploded-test TEST="micro:StringCompareToDifferentLength" >>> >>> Benchmark (size) Mode Cnt Score Speedup Units >>> compareToLL 24 avgt 10 1.0x ms/op >>> compareToLL 36 avgt 10 1.0x ms/op >>> compareToLL 72 avgt 10 1.0x ms/op >>> compareToLL 128 avgt 10 1.4x ms/op >>> compareToLL 256 avgt 10 1.8x ms/op >>> compareToLL 512 avgt 10 2.7x ms/op >>> compareToLU 24 avgt 10 1.6x ms/op >>> compareToLU 36 avgt 10 1.8x ms/op >>> compareToLU 72 avgt 10 2.3x ms/op >>> compareToLU 128 avgt 10 3.8x ms/op >>> compareToLU 256 avgt 10 4.7x ms/op >>> compareToLU 512 avgt 10 6.3x ms/op >>> compareToUL 24 avgt 10 1.6x ms/op >>> compareToUL 36 avgt 10 1.7x ms/op >>> compareToUL 72 avgt 10 2.2x ms/op >>> compareToUL 128 avgt 10 3.3x ms/op >>> compareToUL 256 avgt 10 4.4x ms/op >>> compareToUL 512 avgt 10 6.1x ms/op >>> compareToUU 24 avgt 10 1.0x ms/op >>> compareToUU 36 avgt 10 1.0x ms/op >>> compareToUU 72 avgt 10 1.4x ms/op >>> compareToUU 128 avgt 10 2.2x ms/op >>> compareToUU 256 avgt 10 2.6x ms/op >>> compareToUU 512 avgt 10 3.7x ms/op >>> >>> [1] https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/compiler/intrinsics/string/TestStringCompareToDifferentLength.java >> >> TatWai Chong has updated the pull request incrementally with one additional commit since the last revision: >> >> Replace `sve_cmpne` with up-to-date `sve_cmp`. > > Hm, I didn't see anything like that when we tested this patch internally. I'll create another PR to revert it for now. Filed: https://bugs.openjdk.java.net/browse/JDK-8275263 If a backout is needed then it should be converted to a "backout" issue per: https://openjdk.java.net/guide/index.html#backing-out-a-change Thanks, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/5129 > From ngasson at openjdk.java.net Thu Oct 14 06:43:09 2021 From: ngasson at openjdk.java.net (Nick Gasson) Date: Thu, 14 Oct 2021 06:43:09 GMT Subject: RFR: 8275262: Backout JDK-8269559 Message-ID: This reverts "8269559: AArch64: Implement string_compare intrinsic in SVE" which caused some unknown failures in Oracle's CI. ------------- Commit messages: - 8275262: Backout JDK-8269559 Changes: https://git.openjdk.java.net/jdk/pull/5941/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5941&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275262 Stats: 517 lines in 11 files changed: 1 ins; 421 del; 95 mod Patch: https://git.openjdk.java.net/jdk/pull/5941.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5941/head:pull/5941 PR: https://git.openjdk.java.net/jdk/pull/5941 From dholmes at openjdk.java.net Thu Oct 14 06:50:47 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 14 Oct 2021 06:50:47 GMT Subject: RFR: 8275262: Backout JDK-8269559 In-Reply-To: References: Message-ID: <5AWjOqqXbV_kbpwSAY4vPwRKgHFrhmDe9IBn6q6y7KE=.cb114c0c-8559-4fae-8101-333fb24ac483@github.com> On Thu, 14 Oct 2021 06:37:19 GMT, Nick Gasson wrote: > This reverts "8269559: AArch64: Implement string_compare intrinsic in SVE" which caused some unknown failures in Oracle's CI. Thanks for attending to this so quickly @nick-arm ! The issue is only on (some of) our macOS Aarch64 systems. Let me know if I can provide more info on hardware etc. David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5941 From ngasson at openjdk.java.net Thu Oct 14 06:55:48 2021 From: ngasson at openjdk.java.net (Nick Gasson) Date: Thu, 14 Oct 2021 06:55:48 GMT Subject: RFR: 8275262: Backout JDK-8269559 In-Reply-To: <5AWjOqqXbV_kbpwSAY4vPwRKgHFrhmDe9IBn6q6y7KE=.cb114c0c-8559-4fae-8101-333fb24ac483@github.com> References: <5AWjOqqXbV_kbpwSAY4vPwRKgHFrhmDe9IBn6q6y7KE=.cb114c0c-8559-4fae-8101-333fb24ac483@github.com> Message-ID: On Thu, 14 Oct 2021 06:48:18 GMT, David Holmes wrote: >> This reverts "8269559: AArch64: Implement string_compare intrinsic in SVE" which caused some unknown failures in Oracle's CI. > > Thanks for attending to this so quickly @nick-arm ! > > The issue is only on (some of) our macOS Aarch64 systems. Let me know if I can provide more info on hardware etc. > > David Thanks @dholmes-ora . I'll wait for the GitHub Actions tests to finish. Should I retitle this to "[BACKOUT] AArch64: Implement string_compare intrinsic in SVE" as per the developer's guide? ------------- PR: https://git.openjdk.java.net/jdk/pull/5941 From david.holmes at oracle.com Thu Oct 14 07:06:29 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 14 Oct 2021 17:06:29 +1000 Subject: RFR: 8275262: Backout JDK-8269559 In-Reply-To: References: <5AWjOqqXbV_kbpwSAY4vPwRKgHFrhmDe9IBn6q6y7KE=.cb114c0c-8559-4fae-8101-333fb24ac483@github.com> Message-ID: <990d102e-91ba-5ce5-b365-390ded6f5655@oracle.com> On 14/10/2021 4:55 pm, Nick Gasson wrote: > On Thu, 14 Oct 2021 06:48:18 GMT, David Holmes wrote: > >>> This reverts "8269559: AArch64: Implement string_compare intrinsic in SVE" which caused some unknown failures in Oracle's CI. >> >> Thanks for attending to this so quickly @nick-arm ! >> >> The issue is only on (some of) our macOS Aarch64 systems. Let me know if I can provide more info on hardware etc. >> >> David > > Thanks @dholmes-ora . I'll wait for the GitHub Actions tests to finish. Should I retitle this to "[BACKOUT] AArch64: Implement string_compare intrinsic in SVE" as per the developer's guide? Yes please follow whatever the dev guide states to do. Thanks, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/5941 > From tschatzl at openjdk.java.net Thu Oct 14 07:16:54 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Thu, 14 Oct 2021 07:16:54 GMT Subject: RFR: 8275262: [BACKOUT] AArch64: Implement string_compare intrinsic in SVE In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 06:37:19 GMT, Nick Gasson wrote: > This reverts "8269559: AArch64: Implement string_compare intrinsic in SVE" which caused some unknown failures in Oracle's CI. Lgtm. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5941 From aph at openjdk.java.net Thu Oct 14 08:27:48 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 14 Oct 2021 08:27:48 GMT Subject: RFR: 8275262: [BACKOUT] AArch64: Implement string_compare intrinsic in SVE In-Reply-To: <990d102e-91ba-5ce5-b365-390ded6f5655@oracle.com> References: <990d102e-91ba-5ce5-b365-390ded6f5655@oracle.com> Message-ID: On Thu, 14 Oct 2021 07:08:20 GMT, David Holmes wrote: > The issue is only on (some of) our macOS Aarch64 systems. Let me know if I can provide more info on hardware etc. Any info about what failed? A reproducer would be nice. ------------- PR: https://git.openjdk.java.net/jdk/pull/5941 From ngasson at openjdk.java.net Thu Oct 14 08:35:54 2021 From: ngasson at openjdk.java.net (Nick Gasson) Date: Thu, 14 Oct 2021 08:35:54 GMT Subject: RFR: 8275262: [BACKOUT] AArch64: Implement string_compare intrinsic in SVE In-Reply-To: References: <990d102e-91ba-5ce5-b365-390ded6f5655@oracle.com> Message-ID: On Thu, 14 Oct 2021 08:24:41 GMT, Andrew Haley wrote: > > The issue is only on (some of) our macOS Aarch64 systems. Let me know if I can provide more info on hardware etc. > > Any info about what failed? A reproducer would be nice. I just ran tier1 on an M1 Mac with no failures - perhaps it's OS version dependent if it only failed on some systems? I have: $ uname -a Darwin [...] 20.2.0 Darwin Kernel Version 20.2.0: Wed Dec 2 20:40:21 PST 2020; root:xnu-7195.60.75~1/RELEASE_ARM64_T8101 arm64 ------------- PR: https://git.openjdk.java.net/jdk/pull/5941 From aph at openjdk.java.net Thu Oct 14 09:33:51 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 14 Oct 2021 09:33:51 GMT Subject: RFR: 8275262: [BACKOUT] AArch64: Implement string_compare intrinsic in SVE In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 06:37:19 GMT, Nick Gasson wrote: > This reverts "8269559: AArch64: Implement string_compare intrinsic in SVE" which caused some unknown failures in Oracle's CI. It might be a spurious failure, then. I guess we need to see the test logs. ------------- PR: https://git.openjdk.java.net/jdk/pull/5941 From ngasson at openjdk.java.net Thu Oct 14 09:39:55 2021 From: ngasson at openjdk.java.net (Nick Gasson) Date: Thu, 14 Oct 2021 09:39:55 GMT Subject: RFR: 8275262: [BACKOUT] AArch64: Implement string_compare intrinsic in SVE In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 09:31:11 GMT, Andrew Haley wrote: > It might be a spurious failure, then. I guess we need to see the test logs. I'll revert it for in now in case we missed something. ------------- PR: https://git.openjdk.java.net/jdk/pull/5941 From ngasson at openjdk.java.net Thu Oct 14 09:39:56 2021 From: ngasson at openjdk.java.net (Nick Gasson) Date: Thu, 14 Oct 2021 09:39:56 GMT Subject: Integrated: 8275262: [BACKOUT] AArch64: Implement string_compare intrinsic in SVE In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 06:37:19 GMT, Nick Gasson wrote: > This reverts "8269559: AArch64: Implement string_compare intrinsic in SVE" which caused some unknown failures in Oracle's CI. This pull request has now been integrated. Changeset: 333c4692 Author: Nick Gasson URL: https://git.openjdk.java.net/jdk/commit/333c4692d898d582fe162cc9621acd3e1c242d67 Stats: 517 lines in 11 files changed: 1 ins; 421 del; 95 mod 8275262: [BACKOUT] AArch64: Implement string_compare intrinsic in SVE Reviewed-by: dholmes, tschatzl ------------- PR: https://git.openjdk.java.net/jdk/pull/5941 From maurizio.cimadamore at oracle.com Thu Oct 14 09:54:00 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 14 Oct 2021 10:54:00 +0100 Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v13] In-Reply-To: References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> <_XTZju-Itu7LJ6br_wNN5PQr1DWmCsFY7ehTpWEU3bo=.316e7a9c-d79b-4768-aca2-d1116244a7a8@github.com> Message-ID: <6397799e-b137-53b6-6f06-4f542ad828f3@oracle.com> On 14/10/2021 07:05, R?mi Forax wrote: > On Thu, 14 Oct 2021 00:54:57 GMT, Mandy Chung wrote: > >>> src/java.base/share/classes/jdk/internal/reflect/MethodHandleAccessorFactory.java line 151: >>> >>>> 149: var setter = isReadOnly ? null : JLIA.unreflectField(field, true); >>>> 150: Class type = field.getType(); >>>> 151: if (type == Boolean.TYPE) { >>> dumb question: any reason why `boolean.class` (which is compiled to a LDC) is not used? >> I only see `boolean.class` compiled to `getstatic Boolean.TYPE`. Is there a javac flag to compile it to a LDC? > The LDC bytecode instruction for a class takes a class name not a descriptor as parameter, so there is no way to encode LDC Z. Valhalla may change that. Remi is right - I got ahead of myself :-) > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/5027 From david.holmes at oracle.com Thu Oct 14 10:19:27 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 14 Oct 2021 20:19:27 +1000 Subject: RFR: 8275262: [BACKOUT] AArch64: Implement string_compare intrinsic in SVE In-Reply-To: References: <990d102e-91ba-5ce5-b365-390ded6f5655@oracle.com> Message-ID: <55e07be6-9915-2228-2ca2-974ae7459f01@oracle.com> On 14/10/2021 6:27 pm, Andrew Haley wrote: > On Thu, 14 Oct 2021 07:08:20 GMT, David Holmes wrote: > >> The issue is only on (some of) our macOS Aarch64 systems. Let me know if I can provide more info on hardware etc. > > Any info about what failed? A reproducer would be nice. See https://bugs.openjdk.java.net/browse/JDK-8275263 for some info on the failures. It seems really bizarre. David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/5941 > From lancea at openjdk.java.net Thu Oct 14 10:45:48 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 14 Oct 2021 10:45:48 GMT Subject: RFR: 8153490: Cannot setBytes() if incoming buffer's length is bigger than number of elements we want to insert. [v4] In-Reply-To: <_tHPXNasHvbTb633vjjGNy-D5xN92ypyHq_2MTNlVdc=.c815fc4e-f65d-4c23-97ee-91730a1c9891@github.com> References: <_tHPXNasHvbTb633vjjGNy-D5xN92ypyHq_2MTNlVdc=.c815fc4e-f65d-4c23-97ee-91730a1c9891@github.com> Message-ID: On Thu, 14 Oct 2021 01:46:31 GMT, Mitsuru Kariya wrote: > Sorry for my very slow response. No problem at all. I was delayed in getting the CSR created and finalized. > These `{@code bytes}` point to the `bytes` argument, but should I change it to `{@code byte}s`? Yes please make that minor change. Thank you ------------- PR: https://git.openjdk.java.net/jdk/pull/4001 From aph at openjdk.java.net Thu Oct 14 12:35:50 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 14 Oct 2021 12:35:50 GMT Subject: RFR: 8275262: [BACKOUT] AArch64: Implement string_compare intrinsic in SVE In-Reply-To: <55e07be6-9915-2228-2ca2-974ae7459f01@oracle.com> References: <55e07be6-9915-2228-2ca2-974ae7459f01@oracle.com> Message-ID: On Thu, 14 Oct 2021 10:21:20 GMT, David Holmes wrote: > See https://bugs.openjdk.java.net/browse/JDK-8275263 for some info on the failures. It seems really bizarre. I would understand this a lot better if the affected machines actually used SVE, but they don't have the hardware. That does reduce the bug surface: we only need to look at the affected common code, and the only thing I can immediately see is that a couple of unused register arguments have been added. Unless, of course, the affected Macs think they have SVE... ? I don't think that's possible. I'd definitely be looking at the host toolchain for differences. ------------- PR: https://git.openjdk.java.net/jdk/pull/5941 From rriggs at openjdk.java.net Thu Oct 14 14:50:59 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 14 Oct 2021 14:50:59 GMT Subject: RFR: 8275013: Improve discussion of serialization method declarations in java.io.Object{Input, Output}Stream In-Reply-To: References: Message-ID: On Sun, 10 Oct 2021 20:25:43 GMT, Joe Darcy wrote: > The java.io.ObjectInputStream and java.io.ObjectOuputStream classes are part of the serialization feature. These classes contain brief descriptions of some of the methods serializable classes can define to interact with the serialization mechanism, readObject, readObjectNoData, and writeObject. These descriptions are not entirely consistent with one another and at least one is arguably misleading. > > This PR makes the brief discussion the same in both classes and addresses the misleading point: the throws clauses of the methods will not effect whether or not the methods are found by serialization, but throwing unchecked exceptions not declared in the standard signatures is ill-advised. (The current implementation looks up the methods by name using core reflection; the method modifiers are checked to match but the throws information is not.) > > Please also review the corresponding CSR : https://bugs.openjdk.java.net/browse/JDK-8275014 src/java.base/share/classes/java/io/ObjectOutputStream.java line 105: > 103: * declared to throw checked exceptions consistent with these > 104: * signatures. > 105: * Why the mix of 'should' vs 'must' in this paragraph? The change above downgrades a 'must' to a 'should'. The original text and the java serialization spec use 'must'. Other JDK doc uses 'should' as being more readable but is supposed to mean 'must'. ------------- PR: https://git.openjdk.java.net/jdk/pull/5883 From jboes at openjdk.java.net Thu Oct 14 14:55:08 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Thu, 14 Oct 2021 14:55:08 GMT Subject: RFR: 8275137: jdk.unsupported/sun.reflect.ReflectionFactory.readObjectNoDataForSerialization uses wrong signature Message-ID: sun.reflect.ReflectionFactory provides MethodHandles for the various serialization methods, it is a critical internal API in the jdk.unsupported module (see JEP 260 [1]) that may be used by 3rd party serialization libraries. One of these serialization methods is readObjectNoData [2]: ```private void readObjectNoData() throws ObjectStreamException;``` The issue: The method that returns the matching handle, sun.reflect.ReflectionFactory.readObjectNoDataForSerialization, uses an erroneous signature `readObjectNoData(ObjectInputStream)` - note the superfluous parameter. This change updates the specification and fixes the implementation in java.base/jdk.internal.reflect.ReflectionFactory. Testing: tier 1-3 [1] https://openjdk.java.net/jeps/260 [2] https://docs.oracle.com/en/java/javase/15/docs/specs/serialization/input.html#the-readobjectnodata-method ------------- Commit messages: - initial commit Changes: https://git.openjdk.java.net/jdk/pull/5951/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5951&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275137 Stats: 28 lines in 3 files changed: 4 ins; 6 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/5951.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5951/head:pull/5951 PR: https://git.openjdk.java.net/jdk/pull/5951 From dfuchs at openjdk.java.net Thu Oct 14 15:07:50 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 14 Oct 2021 15:07:50 GMT Subject: RFR: 8275137: jdk.unsupported/sun.reflect.ReflectionFactory.readObjectNoDataForSerialization uses wrong signature In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 14:44:34 GMT, Julia Boes wrote: > sun.reflect.ReflectionFactory provides MethodHandles for the various serialization methods, it is a critical internal API in the jdk.unsupported module (see JEP 260 [1]) that may be used by 3rd party serialization libraries. > > One of these serialization methods is readObjectNoData [2]: > > ```private void readObjectNoData() throws ObjectStreamException;``` > > The issue: The method that returns the matching handle, sun.reflect.ReflectionFactory.readObjectNoDataForSerialization, uses an erroneous signature `readObjectNoData(ObjectInputStream)` - note the superfluous parameter. > > This change updates the specification and fixes the implementation in java.base/jdk.internal.reflect.ReflectionFactory. > > Testing: tier 1-3 > > [1] https://openjdk.java.net/jeps/260 > [2] https://docs.oracle.com/en/java/javase/15/docs/specs/serialization/input.html#the-readobjectnodata-method LGTM. The update on the `throws` declaration in the test is a bit of a distraction. ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5951 From jboes at openjdk.java.net Thu Oct 14 15:40:47 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Thu, 14 Oct 2021 15:40:47 GMT Subject: RFR: 8275137: jdk.unsupported/sun.reflect.ReflectionFactory.readObjectNoDataForSerialization uses wrong signature In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 15:04:23 GMT, Daniel Fuchs wrote: > The update on the throws declaration in the test is a bit of a distraction. Right, should have mentioned that the only relevant change _in the test_ is on line 253, the rest is cleanup. ------------- PR: https://git.openjdk.java.net/jdk/pull/5951 From rriggs at openjdk.java.net Thu Oct 14 15:55:53 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 14 Oct 2021 15:55:53 GMT Subject: RFR: 8275197: Remove unused fields in ThaiBuddhistChronology In-Reply-To: References: Message-ID: On Tue, 12 Oct 2021 21:10:12 GMT, Andrey Turbanov wrote: > Remove 3 unused HashMap's. > Reported here https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-September/081866.html > I did the similar PR to treetenbp and it was merged https://github.com/ThreeTen/threetenbp/pull/155 Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5917 From naoto at openjdk.java.net Thu Oct 14 15:59:13 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 14 Oct 2021 15:59:13 GMT Subject: RFR: 8275145: file.encoding system property has an incorrect value on Windows Message-ID: Fixing a regression in which `file.encoding` was initialized by `sprops->encoding` instead of `sprops->sun_jnu_encoding` on non macOS platforms. tier1-3 tests passed on all platforms. ------------- Commit messages: - 8275145: file.encoding system property has an incorrect value on Windows Changes: https://git.openjdk.java.net/jdk/pull/5953/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5953&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275145 Stats: 9 lines in 1 file changed: 8 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5953.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5953/head:pull/5953 PR: https://git.openjdk.java.net/jdk/pull/5953 From iris at openjdk.java.net Thu Oct 14 16:00:52 2021 From: iris at openjdk.java.net (Iris Clark) Date: Thu, 14 Oct 2021 16:00:52 GMT Subject: RFR: 8275197: Remove unused fields in ThaiBuddhistChronology In-Reply-To: References: Message-ID: On Tue, 12 Oct 2021 21:10:12 GMT, Andrey Turbanov wrote: > Remove 3 unused HashMap's. > Reported here https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-September/081866.html > I did the similar PR to treetenbp and it was merged https://github.com/ThreeTen/threetenbp/pull/155 Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5917 From mchung at openjdk.java.net Thu Oct 14 16:07:55 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 14 Oct 2021 16:07:55 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v13] In-Reply-To: References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> Message-ID: On Wed, 13 Oct 2021 23:53:17 GMT, Maurizio Cimadamore wrote: >> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> Minor cleanup. Improve javadoc in CallerSensitiveAdapter > > src/java.base/share/classes/jdk/internal/reflect/DirectMethodHandleAccessor.java line 86: > >> 84: } >> 85: >> 86: private static final int PARAM_COUNT_MASK = 0x00FF; > > Is this packing logic required? I get it that it saves footprint - but then you have to always unmask bits to get the argument count (see invoke and other places). If you keep this, it might be worth documenting what the bit layout is supposed to be? It's not driven by performance data. It's part of Peter's contribution. I also prefer it without the packing. I propose to keep the parameter count as a separate variable and examine it when there is footprint issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/5027 From darcy at openjdk.java.net Thu Oct 14 16:10:50 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 14 Oct 2021 16:10:50 GMT Subject: RFR: 8275013: Improve discussion of serialization method declarations in java.io.Object{Input, Output}Stream In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 14:47:28 GMT, Roger Riggs wrote: >> The java.io.ObjectInputStream and java.io.ObjectOuputStream classes are part of the serialization feature. These classes contain brief descriptions of some of the methods serializable classes can define to interact with the serialization mechanism, readObject, readObjectNoData, and writeObject. These descriptions are not entirely consistent with one another and at least one is arguably misleading. >> >> This PR makes the brief discussion the same in both classes and addresses the misleading point: the throws clauses of the methods will not effect whether or not the methods are found by serialization, but throwing unchecked exceptions not declared in the standard signatures is ill-advised. (The current implementation looks up the methods by name using core reflection; the method modifiers are checked to match but the throws information is not.) >> >> Please also review the corresponding CSR : https://bugs.openjdk.java.net/browse/JDK-8275014 > > src/java.base/share/classes/java/io/ObjectOutputStream.java line 105: > >> 103: * declared to throw checked exceptions consistent with these >> 104: * signatures. >> 105: * > > Why the mix of 'should' vs 'must' in this paragraph? The change above downgrades a 'must' to a 'should'. > The original text and the java serialization spec use 'must'. Other JDK doc uses 'should' as being more readable but is supposed to mean 'must'. Because there is a difference in consequence if the name, modifiers, return type, etc. don't match as opposed to the throws clause not matching. As stated, if the name, modifiers, etc. do not match the method is *not* used by serialization. Either the method is not found from the getDeclaredMethod call or is screened out afterward. If the throws information doesn't match, the method is still found and used by serialization. As the method is invoked reflective at runtime, if it throws a checked exception other than one of the declared one, exception handling code propagates out an InvocationTargetException. ------------- PR: https://git.openjdk.java.net/jdk/pull/5883 From hchao at openjdk.java.net Thu Oct 14 16:13:10 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Thu, 14 Oct 2021 16:13:10 GMT Subject: RFR: 8272163: Add -version option to keytool and jarsigner Message-ID: <09nuObEA1zfkqsqe4YoypKcdexK1L5zdRjtXUKHLt_g=.676c0c70-e861-460d-b28e-bdada92a5136@github.com> It'd be useful to have a -version option for keytool and jarsigner. Many other JDK tools already have a -version option. This is to add -version option to keytool and jarsigner like jar command does. ------------- Commit messages: - 8272163: Add -version option to keytool and jarsigner Changes: https://git.openjdk.java.net/jdk/pull/5954/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5954&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272163 Stats: 117 lines in 6 files changed: 116 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5954.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5954/head:pull/5954 PR: https://git.openjdk.java.net/jdk/pull/5954 From mchung at openjdk.java.net Thu Oct 14 16:22:50 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 14 Oct 2021 16:22:50 GMT Subject: RFR: 8275145: file.encoding system property has an incorrect value on Windows In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 15:50:28 GMT, Naoto Sato wrote: > Fixing a regression in which `file.encoding` was initialized by `sprops->encoding` instead of `sprops->sun_jnu_encoding` on non macOS platforms. tier1-3 tests passed on all platforms. Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5953 From iris at openjdk.java.net Thu Oct 14 16:22:50 2021 From: iris at openjdk.java.net (Iris Clark) Date: Thu, 14 Oct 2021 16:22:50 GMT Subject: RFR: 8275145: file.encoding system property has an incorrect value on Windows In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 15:50:28 GMT, Naoto Sato wrote: > Fixing a regression in which `file.encoding` was initialized by `sprops->encoding` instead of `sprops->sun_jnu_encoding` on non macOS platforms. tier1-3 tests passed on all platforms. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5953 From rriggs at openjdk.java.net Thu Oct 14 16:37:50 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 14 Oct 2021 16:37:50 GMT Subject: RFR: 8275145: file.encoding system property has an incorrect value on Windows In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 15:50:28 GMT, Naoto Sato wrote: > Fixing a regression in which `file.encoding` was initialized by `sprops->encoding` instead of `sprops->sun_jnu_encoding` on non macOS platforms. tier1-3 tests passed on all platforms. Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5953 From mchung at openjdk.java.net Thu Oct 14 16:51:50 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 14 Oct 2021 16:51:50 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v13] In-Reply-To: References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> Message-ID: On Thu, 14 Oct 2021 00:23:29 GMT, Maurizio Cimadamore wrote: > I noted that in the static case, Poly does regress for fields - do we know why instance Poly is better than static Poly? That seems surprising. I think you're asking why the regression of instance Poly is smaller than that of static Poly? We don't know and Claes will look into it. ------------- PR: https://git.openjdk.java.net/jdk/pull/5027 From alanb at openjdk.java.net Thu Oct 14 16:53:52 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 14 Oct 2021 16:53:52 GMT Subject: RFR: 8275145: file.encoding system property has an incorrect value on Windows In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 15:50:28 GMT, Naoto Sato wrote: > Fixing a regression in which `file.encoding` was initialized by `sprops->encoding` instead of `sprops->sun_jnu_encoding` on non macOS platforms. tier1-3 tests passed on all platforms. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5953 From duke at openjdk.java.net Thu Oct 14 16:54:57 2021 From: duke at openjdk.java.net (Raffaello Giulietti) Date: Thu, 14 Oct 2021 16:54:57 GMT Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v2] In-Reply-To: References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com> Message-ID: On Fri, 16 Apr 2021 11:30:32 GMT, Raffaello Giulietti wrote: >> Hello, >> >> here's a PR for a patch submitted on March 2020 [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a thing. >> >> The patch has been edited to adhere to OpenJDK code conventions about multi-line (block) comments. Nothing in the code proper has changed, except for the addition of redundant but clarifying parentheses in some expressions. >> >> >> Greetings >> Raffaello > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > 4511638: Double.toString(double) sometimes produces incorrect results Hello, Paul Zimmermann of INRIA kindly provided me 19'545 doubles generated on purpose as hard test cases. All have the form 2^q*10^(-k), with k as in my writing (https://drive.google.com/file/d/1luHhyQF9zKlM8yJ1nebU0OgVYhfC6CBN/view) They all pass on my machine and will be added to the this PR asap. Greetings Raffaello ------------- PR: https://git.openjdk.java.net/jdk/pull/3402 From psandoz at openjdk.java.net Thu Oct 14 17:21:25 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Thu, 14 Oct 2021 17:21:25 GMT Subject: RFR: 8271515: Integration of JEP 417: Vector API (Third Incubator) [v2] In-Reply-To: <_QQ9ntdJJfzVcAGrbjev0ZM-xNfD4wNATphnXkb-Y00=.bbf46985-8776-4dda-ada5-b15ab50774aa@github.com> References: <_QQ9ntdJJfzVcAGrbjev0ZM-xNfD4wNATphnXkb-Y00=.bbf46985-8776-4dda-ada5-b15ab50774aa@github.com> Message-ID: <0LvaNkXLAVEoVt15uJ3Y2ZFzbctyTk9A76JhKXmZBqo=.f827b200-6aca-49ec-bcf5-76dbe194f4a0@github.com> > This PR improves the performance of vector operations that accept masks on architectures that support masking in hardware, specifically Intel AVX512 and ARM SVE. > > On architectures that do not support masking in hardware the same technique as before is applied to most operations, specifically composition using blend. > > Masked loads/stores are a special form of masked operation that require additional care to ensure out-of-bounds access throw exceptions. The range checking has not been fully optimized and will require further work. > > No API enhancements were required and only a few additional tests were needed. Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision: Apply patch from https://github.com/openjdk/panama-vector/pull/152 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5873/files - new: https://git.openjdk.java.net/jdk/pull/5873/files/f558b74b..bfb8fff8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5873&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5873&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5873.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5873/head:pull/5873 PR: https://git.openjdk.java.net/jdk/pull/5873 From mbien42 at gmail.com Thu Oct 14 17:23:13 2021 From: mbien42 at gmail.com (Michael Bien) Date: Thu, 14 Oct 2021 19:23:13 +0200 Subject: SourceVersion::feature In-Reply-To: <8dda85be-e55e-7d0f-0a6f-5db40691fed1@gmail.com> References: <8dda85be-e55e-7d0f-0a6f-5db40691fed1@gmail.com> Message-ID: <9bda1fa7-ff68-e0a5-0bbc-b9ef92847ad2@gmail.com> is this the right mailing list for javax.lang.model.* discussions? if yes: instead of adding ??? /** ???? * Returns the version as int representing the feature release. ???? * @see Runtime.Version#feature() ???? */ ??? public int feature() { ??????? return this.ordinal(); ??? } to SourceVersion. a note could be added to the doc that the ordinal can be used as feature version. Since this statement would apply to the past too, the note could be backported to all maintained JDKs. This comes with the usual downside of not being able to add enums for in-between versions in future. (doing both would be an option too of course) To not use the ordinal, client code has to go through some enum init rituals to be able to do version comparisons: ?? final static SOURCE_VERSION_RELEASE_18; ?? static { SourceVersion tmp18; ??????? try { ??????????? tmp18 = SourceVersion.valueOf("RELEASE_18"); ??????? } catch (IllegalArgumentException ex) { tmp18 = null; ??????? } ??????? SOURCE_VERSION_RELEASE_18 = tmp18; ??????? //... more versions ?? } just to be able to ??? if (SOURCE_VERSION_RELEASE_18 != null && version.compareTo(SOURCE_VERSION_RELEASE_18) >= 0) {} or ??? if (Integer.parseInt(version.name().substring(version.name().indexOf('_')+1)) >= 18) {} which is shorter but not a good solution either. what the client code actually wants is: ??? if (SourceVersion.latest().feature() >= 18) {} it was a wise decision for java.lang.Runtime.Version to not use enums :) best regards, michael On 09.10.21 20:58, Michael Bien wrote: > Hello, > > could javax.lang.model.SourceVersion receive a feature() method > returning the version as an int, analog to java.lang.Runtime.Version? > > if (SourceVersion.latest().feature() >= 18) {} > > is simpler than comparing enums which may or may not exist dependent > on the deployed java version and cleaner than ordinal() tricks. > > best regards, > > michael > From psandoz at openjdk.java.net Thu Oct 14 17:30:52 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Thu, 14 Oct 2021 17:30:52 GMT Subject: RFR: 8271515: Integration of JEP 417: Vector API (Third Incubator) [v2] In-Reply-To: <0LvaNkXLAVEoVt15uJ3Y2ZFzbctyTk9A76JhKXmZBqo=.f827b200-6aca-49ec-bcf5-76dbe194f4a0@github.com> References: <_QQ9ntdJJfzVcAGrbjev0ZM-xNfD4wNATphnXkb-Y00=.bbf46985-8776-4dda-ada5-b15ab50774aa@github.com> <0LvaNkXLAVEoVt15uJ3Y2ZFzbctyTk9A76JhKXmZBqo=.f827b200-6aca-49ec-bcf5-76dbe194f4a0@github.com> Message-ID: On Thu, 14 Oct 2021 17:21:25 GMT, Paul Sandoz wrote: >> This PR improves the performance of vector operations that accept masks on architectures that support masking in hardware, specifically Intel AVX512 and ARM SVE. >> >> On architectures that do not support masking in hardware the same technique as before is applied to most operations, specifically composition using blend. >> >> Masked loads/stores are a special form of masked operation that require additional care to ensure out-of-bounds access throw exceptions. The range checking has not been fully optimized and will require further work. >> >> No API enhancements were required and only a few additional tests were needed. > > Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision: > > Apply patch from https://github.com/openjdk/panama-vector/pull/152 @njian there is a conflict with `macroAssembler_aarch64.cpp`: --- a/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp +++ b/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp @@@ -2580,8 -2495,8 +2571,13 @@@ void MacroAssembler::pop_call_clobbered } void MacroAssembler::push_CPU_state(bool save_vectors, bool use_sve, ++<<<<<<< HEAD + int sve_vector_size_in_bytes, int total_predicate_in_bytes) { + push(0x3fffffff, sp); // integer registers except lr & sp ++======= + int sve_vector_size_in_bytes) { + push(RegSet::range(r0, r29), sp); // integer registers except lr & sp ++>>>>>>> master if (save_vectors && use_sve && sve_vector_size_in_bytes > 16) { sub(sp, sp, sve_vector_size_in_bytes * FloatRegisterImpl::number_of_registers); for (int i = 0; i < FloatRegisterImpl::number_of_registers; i++) { I think the resolution is this: @@ -2581,7 +2572,7 @@ void MacroAssembler::pop_call_clobbered_registers_except(RegSet exclude) { void MacroAssembler::push_CPU_state(bool save_vectors, bool use_sve, int sve_vector_size_in_bytes, int total_predicate_in_bytes) { - push(0x3fffffff, sp); // integer registers except lr & sp + push(RegSet::range(r0, r29), sp); // integer registers except lr & sp is that correct? ------------- PR: https://git.openjdk.java.net/jdk/pull/5873 From mchung at openjdk.java.net Thu Oct 14 19:38:52 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 14 Oct 2021 19:38:52 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v13] In-Reply-To: References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> Message-ID: On Wed, 13 Oct 2021 18:53:22 GMT, Mandy Chung wrote: >> This reimplements core reflection with method handles. >> >> For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. >> >> The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. >> >> The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. >> >> Ran tier1-tier8 tests. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8013527 >> [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > Minor cleanup. Improve javadoc in CallerSensitiveAdapter The static Const/Poly/Var is doing better than the instance Const/Poly/Var in the old implementation, which might imply that Unsafe might be slightly faster for static field access than instance field access (I have to dig further.). For the new implementation using MH, the cost of static field access and instance field access looks like similar. ------------- PR: https://git.openjdk.java.net/jdk/pull/5027 From redestad at openjdk.java.net Thu Oct 14 19:48:52 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 14 Oct 2021 19:48:52 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v13] In-Reply-To: References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> Message-ID: <_kTzNKC6on6X-1TYsh45WtJvm_8mJuSTmvE6qsVSM0g=.b44481a1-9007-4ae3-a7e6-f82f0d149da7@github.com> On Thu, 14 Oct 2021 19:36:02 GMT, Mandy Chung wrote: >> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> Minor cleanup. Improve javadoc in CallerSensitiveAdapter > > The static Const/Poly/Var is doing better than the instance Const/Poly/Var in the old implementation, which might imply that Unsafe might be slightly faster for static field access than instance field access (I have to dig further.). > > For the new implementation using MH, the cost of static field access and instance field access looks like similar. Not sure which results show instance beating static? In both my runs and @mlchung's numbers above static appears slightly faster than instance (note that lower is better here). This seems reasonable since static does not carry a receiver, and a similar relative skew is there in the baseline as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/5027 From redestad at openjdk.java.net Thu Oct 14 19:56:53 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 14 Oct 2021 19:56:53 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v13] In-Reply-To: References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> Message-ID: On Wed, 13 Oct 2021 18:53:22 GMT, Mandy Chung wrote: >> This reimplements core reflection with method handles. >> >> For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. >> >> The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. >> >> The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. >> >> Ran tier1-tier8 tests. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8013527 >> [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > Minor cleanup. Improve javadoc in CallerSensitiveAdapter In my runs the relative regression for `instanceFieldPoly` is roughly the same as `staticFieldPoly` (0.61x vs 0.62x). ------------- PR: https://git.openjdk.java.net/jdk/pull/5027 From mcimadamore at openjdk.java.net Thu Oct 14 20:25:55 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 14 Oct 2021 20:25:55 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v13] In-Reply-To: References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> Message-ID: On Thu, 14 Oct 2021 19:53:46 GMT, Claes Redestad wrote: > In my runs the relative regression for `instanceFieldPoly` is roughly the same as `staticFieldPoly` (0.61x vs 0.62x). I was looking at this: https://github.com/openjdk/jdk/pull/5027#issuecomment-939185418 (e.g. I didn't run benchmarks myself) baseline ReflectionSpeedBenchmark.instanceFieldPoly avgt 10 67.089 ? 3.288 ns/op JEP 417 ReflectionSpeedBenchmark.instanceFieldPoly avgt 10 98.671 ? 2.015 ns/op ------------- PR: https://git.openjdk.java.net/jdk/pull/5027 From herrick at openjdk.java.net Thu Oct 14 20:31:13 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Thu, 14 Oct 2021 20:31:13 GMT Subject: RFR: JDK-8263155: Allow additional contents for DMG Message-ID: JDK-8263155: Allow additional contents for DMG ------------- Commit messages: - JDK-8263155: Allow additional contents for DMG - JDK-8263155: Allow additional contents for DMG - JDK-8263155: Allow additional contents for DMG Changes: https://git.openjdk.java.net/jdk/pull/5912/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5912&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263155 Stats: 169 lines in 8 files changed: 153 ins; 0 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/5912.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5912/head:pull/5912 PR: https://git.openjdk.java.net/jdk/pull/5912 From joe.darcy at oracle.com Thu Oct 14 20:53:02 2021 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Thu, 14 Oct 2021 13:53:02 -0700 Subject: SourceVersion::feature In-Reply-To: <9bda1fa7-ff68-e0a5-0bbc-b9ef92847ad2@gmail.com> References: <8dda85be-e55e-7d0f-0a6f-5db40691fed1@gmail.com> <9bda1fa7-ff68-e0a5-0bbc-b9ef92847ad2@gmail.com> Message-ID: <6169ca08-39d7-36c5-5250-08a7091a5fd0@oracle.com> On 10/14/2021 10:23 AM, Michael Bien wrote: > is this the right mailing list for javax.lang.model.* discussions? The compiler-dev list would be appropriate as well, but core-libs will work. First, I understand the desire for a method like this. One of the potential issues is SourceVersion models language versions and while, to date, there has been a simple linear progression, that is not guaranteed to be case arbitrarily far into the future, even though it is the most likely outcome. Since java.lang.Runtime.Version is in the platform now, I think this request would be better satisfied via a ??? public static SourceVersion valueOf(Runtime.Version version) method on SourceVersion. That way the modeling of SourceVersion can absorb any non-linearity in versioning and presumably provide sufficient information for a? Runtime.Version -> SourceVersion mapping to query. I've filed the RFE ??? JDK-8275308: Add valueOf(Runtime.Version) factory to SourceVersion Cheers, -Joe > > if yes: > > instead of adding > ??? /** > ???? * Returns the version as int representing the feature release. > ???? * @see Runtime.Version#feature() > ???? */ > ??? public int feature() { > ??????? return this.ordinal(); > ??? } > to SourceVersion. > > a note could be added to the doc that the ordinal can be used as > feature version. Since this statement would apply to the past too, the > note could be backported to all maintained JDKs. This comes with the > usual downside of not being able to add enums for in-between versions > in future. > > (doing both would be an option too of course) > > > To not use the ordinal, client code has to go through some enum init > rituals to be able to do version comparisons: > > ?? final static SOURCE_VERSION_RELEASE_18; > ?? static { > SourceVersion tmp18; > ??????? try { > ??????????? tmp18 = SourceVersion.valueOf("RELEASE_18"); > ??????? } catch (IllegalArgumentException ex) { > tmp18 = null; > ??????? } > ??????? SOURCE_VERSION_RELEASE_18 = tmp18; > ??????? //... more versions > ?? } > just to be able to > > ??? if (SOURCE_VERSION_RELEASE_18 != null && > version.compareTo(SOURCE_VERSION_RELEASE_18) >= 0) {} > > or > > ??? if > (Integer.parseInt(version.name().substring(version.name().indexOf('_')+1)) > >= 18) {} > > which is shorter but not a good solution either. > > what the client code actually wants is: > > ??? if (SourceVersion.latest().feature() >= 18) {} > > > it was a wise decision for java.lang.Runtime.Version to not use enums :) > > best regards, > michael > > > > On 09.10.21 20:58, Michael Bien wrote: >> Hello, >> >> could javax.lang.model.SourceVersion receive a feature() method >> returning the version as an int, analog to java.lang.Runtime.Version? >> >> if (SourceVersion.latest().feature() >= 18) {} >> >> is simpler than comparing enums which may or may not exist dependent >> on the deployed java version and cleaner than ordinal() tricks. >> >> best regards, >> >> michael >> From darcy at openjdk.java.net Thu Oct 14 20:58:53 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 14 Oct 2021 20:58:53 GMT Subject: RFR: 8275145: file.encoding system property has an incorrect value on Windows In-Reply-To: References: Message-ID: <6HGNTSiYJ2E0YxiSO1iEtU8SDgQ4lysMrz8ZoOuZ_Oo=.350f6d14-2948-4ae5-a6be-161a2ddeaef7@github.com> On Thu, 14 Oct 2021 15:50:28 GMT, Naoto Sato wrote: > Fixing a regression in which `file.encoding` was initialized by `sprops->encoding` instead of `sprops->sun_jnu_encoding` on non macOS platforms. tier1-3 tests passed on all platforms. Please file a CSR for the change in behavior. ------------- PR: https://git.openjdk.java.net/jdk/pull/5953 From naoto at openjdk.java.net Thu Oct 14 21:28:53 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 14 Oct 2021 21:28:53 GMT Subject: RFR: 8275145: file.encoding system property has an incorrect value on Windows In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 15:50:28 GMT, Naoto Sato wrote: > Fixing a regression in which `file.encoding` was initialized by `sprops->encoding` instead of `sprops->sun_jnu_encoding` on non macOS platforms. tier1-3 tests passed on all platforms. Filed a CSR: https://bugs.openjdk.java.net/browse/JDK-8275309 ------------- PR: https://git.openjdk.java.net/jdk/pull/5953 From coleenp at openjdk.java.net Thu Oct 14 22:06:49 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 14 Oct 2021 22:06:49 GMT Subject: RFR: 8266936: Add a finalization JFR event [v16] In-Reply-To: References: Message-ID: On Wed, 13 Oct 2021 18:03:25 GMT, Markus Gr?nlund wrote: >> Greetings, >> >> Object.finalize() was deprecated in JDK9. There is an ongoing effort to replace and mitigate Object.finalize() uses in the JDK libraries; please see https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. >> >> We also like to assist users in replacing and mitigating uses in non-JDK code. >> >> Hence, this changeset adds a periodic JFR event to help identify which classes are overriding Object.finalize(). >> >> Thanks >> Markus > > Markus Gr?nlund has 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. src/hotspot/share/jfr/support/jfrSymbolTable.cpp line 75: > 73: > 74: JfrSymbolTable::JfrSymbolTable() : > 75: _symbol_table(new SymbolTable(this)), I'm confused about which symbol table this is. Is this the same SymbolTable as classfile/symbolTable.cpp? that instance is assumed to be a singleton. Is this a different SymbolTable and can it have a different name (thought it was JfrSymbolTable). src/hotspot/share/jfr/support/jfrSymbolTable.hpp line 68: > 66: template class, typename, size_t> > 67: friend class HashTableHost; > 68: typedef HashTableHost SymbolTable; Oh here it is. Since it's an enclosed type, can you rename it something simpler like Symbols and the other Strings? ------------- PR: https://git.openjdk.java.net/jdk/pull/4731 From coleenp at openjdk.java.net Thu Oct 14 22:06:50 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 14 Oct 2021 22:06:50 GMT Subject: RFR: 8266936: Add a finalization JFR event [v10] In-Reply-To: References: Message-ID: On Mon, 13 Sep 2021 10:54:18 GMT, Markus Gr?nlund wrote: >> src/hotspot/share/services/finalizerService.cpp line 44: >> >>> 42: _ik(ik), >>> 43: _objects_on_heap(0), >>> 44: _total_finalizers_run(0) {} >> >> Is this hashtable for every InstanceKlass that defines a finalizer? How many are there generally? Why couldn't this be a simple hashtable like ResourceHashtable (soon to be renamed) which you can write in only a few lines of code? > > This hashtable holds a FinalizerEntry for every InstanceKlass that provides a non-empty finalizer method and have allocated at least one object. How many there are in general depends on the application. A ResourceHashtable does not have the concurrency property required, as lookups and inserts will happen as part of object allocation. ok. >> src/hotspot/share/services/finalizerService.cpp line 331: >> >>> 329: } >>> 330: Thread* const thread = Thread::current(); >>> 331: // We use current size >> >> Since you remove entries on unloading, I don't see any reason to have any concurrent cleanup. >> You do however need in the lookup code, some code that doesn't find the InstanceKlass if !ik->is_loader_alive() > > "Since you remove entries on unloading, I don't see any reason to have any concurrent cleanup." > Thank you, that is true. The only concurrent work required will be to grow the table. > > "You do however need in the lookup code, some code that doesn't find the InstanceKlass if !ik->is_loader_alive()" > > A precondition is that the code doing the lookup hold the ClassLoaderDataGraph_lock or is at a safepoint. Is that still the case? Would not purge_unloaded() take out the InstanceKlass from the table, as part of unloading, before !ik->is_loader_alive() is published to the outside world? Ok, I see - grow the table. I'm not sure if you need to ask ik->is_loader_alive() or not, but I think you do. The InstanceKlass is removed from your table during class unloading but before that during concurrent class unloading, the class might not be alive while you look at it and concurrent class unloading hasn't gotten around to removing it yet. Since you save classes regardless of CLD, you have to check if it's alive. See classLoaderDataGraph.cpp ClassLoaderDataGraphIterator for example. The CLDG_lock only keeps the graph from not getting modified, but the classes in it might be dead. ------------- PR: https://git.openjdk.java.net/jdk/pull/4731 From coleenp at openjdk.java.net Thu Oct 14 22:06:50 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 14 Oct 2021 22:06:50 GMT Subject: RFR: 8266936: Add a finalization JFR event [v10] In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 21:58:42 GMT, Coleen Phillimore wrote: >> "Since you remove entries on unloading, I don't see any reason to have any concurrent cleanup." >> Thank you, that is true. The only concurrent work required will be to grow the table. >> >> "You do however need in the lookup code, some code that doesn't find the InstanceKlass if !ik->is_loader_alive()" >> >> A precondition is that the code doing the lookup hold the ClassLoaderDataGraph_lock or is at a safepoint. Is that still the case? Would not purge_unloaded() take out the InstanceKlass from the table, as part of unloading, before !ik->is_loader_alive() is published to the outside world? > > Ok, I see - grow the table. > > I'm not sure if you need to ask ik->is_loader_alive() or not, but I think you do. The InstanceKlass is removed from your table during class unloading but before that during concurrent class unloading, the class might not be alive while you look at it and concurrent class unloading hasn't gotten around to removing it yet. Since you save classes regardless of CLD, you have to check if it's alive. See classLoaderDataGraph.cpp ClassLoaderDataGraphIterator for example. The CLDG_lock only keeps the graph from not getting modified, but the classes in it might be dead. That said, I don't see where you return an InstanceKlass in the table, which would need this check. Not in class_unloading_do because this follows the _unloading list. ------------- PR: https://git.openjdk.java.net/jdk/pull/4731 From herrick at openjdk.java.net Thu Oct 14 22:12:46 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Thu, 14 Oct 2021 22:12:46 GMT Subject: RFR: JDK-8263155: Allow additional contents for DMG In-Reply-To: References: Message-ID: On Tue, 12 Oct 2021 16:47:04 GMT, Andy Herrick wrote: > JDK-8263155: Allow additional contents for DMG This enhancement adds a command line option "--mac-dmg-content" that can be used to add any other content to a dmg image. The default DMGsetup.scpt is modified to show all the additional content on a second row in Finder (under the application or java runtime and it's install directory). Changes only ap[ply to dmg type bundles ------------- PR: https://git.openjdk.java.net/jdk/pull/5912 From mik3hall at gmail.com Thu Oct 14 22:14:59 2021 From: mik3hall at gmail.com (Michael Hall) Date: Thu, 14 Oct 2021 17:14:59 -0500 Subject: RFR: JDK-8263155: Allow additional contents for DMG In-Reply-To: References: Message-ID: > On Oct 14, 2021, at 5:12 PM, Andy Herrick wrote: > > On Tue, 12 Oct 2021 16:47:04 GMT, Andy Herrick wrote: > >> JDK-8263155: Allow additional contents for DMG > > This enhancement adds a command line option "--mac-dmg-content" that can be used to add any other content to a dmg image. The default DMGsetup.scpt is modified to show all the additional content on a second row in Finder (under the application or java runtime and it's install directory). > Changes only ap[ply to dmg type bundles > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/5912 +1 From mgronlun at openjdk.java.net Thu Oct 14 22:31:54 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Thu, 14 Oct 2021 22:31:54 GMT Subject: RFR: 8266936: Add a finalization JFR event [v10] In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 22:02:43 GMT, Coleen Phillimore wrote: >> Ok, I see - grow the table. >> >> I'm not sure if you need to ask ik->is_loader_alive() or not, but I think you do. The InstanceKlass is removed from your table during class unloading but before that during concurrent class unloading, the class might not be alive while you look at it and concurrent class unloading hasn't gotten around to removing it yet. Since you save classes regardless of CLD, you have to check if it's alive. See classLoaderDataGraph.cpp ClassLoaderDataGraphIterator for example. The CLDG_lock only keeps the graph from not getting modified, but the classes in it might be dead. > > That said, I don't see where you return an InstanceKlass in the table, which would need this check. Not in class_unloading_do because this follows the _unloading list. So there is already support for concurrent class unloading today in JFR, and the protocol is built around the CLDG_lock. If JFR holds it, concurrent class unloading cannot run. If GC holds it, JFR cannot inspect classes. That's why the table inspection is guarded via the CLDG_lock, for mutual exclusion to avoid this problem. I.e. if concurrent class unloading is in progress, JFR will not inspect the table. ------------- PR: https://git.openjdk.java.net/jdk/pull/4731 From mgronlun at openjdk.java.net Thu Oct 14 22:39:50 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Thu, 14 Oct 2021 22:39:50 GMT Subject: RFR: 8266936: Add a finalization JFR event [v16] In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 21:46:36 GMT, Coleen Phillimore wrote: >> Markus Gr?nlund 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. > > src/hotspot/share/jfr/support/jfrSymbolTable.hpp line 68: > >> 66: template class, typename, size_t> >> 67: friend class HashTableHost; >> 68: typedef HashTableHost SymbolTable; > > Oh here it is. Since it's an enclosed type, can you rename it something simpler like Symbols and the other Strings? Maybe :) ------------- PR: https://git.openjdk.java.net/jdk/pull/4731 From naoto at openjdk.java.net Thu Oct 14 23:46:47 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 14 Oct 2021 23:46:47 GMT Subject: RFR: 8274544: Langtools command's usage were garbled on Japanese Windows In-Reply-To: References: Message-ID: On Mon, 4 Oct 2021 10:24:01 GMT, Jan Lahoda wrote: >> Helllo @naotoj . >> I used `System.console()` and `Console.charset()`. >> >> The following executables had same issue, I fixed them. >>> jar.exe, javac.exe, javadoc.exe, javap.exe, jdeps.exe, jlink.exe, jmod.exe, jpackage.exe >> >> I could not find out the following executables had same issue or not >>> jabswitch.exe, jcmd.exe, jfr.exe, jhsdb.exe, jimage.exe, jinfo.exe, jmap.exe, jps.exe, jrunscript.exe, jstack.exe, jstat.exe, jstatd.exe, kinit.exe, klist.exe, ktab.exe >> >> The following executables worked fine. >>> jarsigner.exe, java.exe, javaw.exe, jdb.exe, jdeprscan.exe, jshell.exe, keytool.exe, rmiregistry.exe, serialver.exe >> >> The following executables were GUI apps >>> jaccessinspector.exe, jaccesswalker.exe, jconsole.exe >> >> These fixes don't have testcases. >> Do you have any idea about testcase for this issue ? > > @takiguc - if JShell is still an issue, is there a chance you could try this: > https://github.com/lahodaj/jdk/commit/cfa6b3eebbc22c5a48d31cfd692ff98690653686 > > Not sure if it will help, but it might (this won't change the default charset, but could send the output in a sensible encoding for the console. > > Thanks! I believe both @lahodaj and my proposed changes are needed, which I provided here: https://github.com/openjdk/jdk/commit/82a9033953655042480c90d388fcbc8053fc5ff5 Can you check this works? ------------- PR: https://git.openjdk.java.net/jdk/pull/5771 From smarks at openjdk.java.net Thu Oct 14 23:58:53 2021 From: smarks at openjdk.java.net (Stuart Marks) Date: Thu, 14 Oct 2021 23:58:53 GMT Subject: RFR: 8275013: Improve discussion of serialization method declarations in java.io.Object{Input, Output}Stream In-Reply-To: References: Message-ID: On Sun, 10 Oct 2021 20:25:43 GMT, Joe Darcy wrote: > The java.io.ObjectInputStream and java.io.ObjectOuputStream classes are part of the serialization feature. These classes contain brief descriptions of some of the methods serializable classes can define to interact with the serialization mechanism, readObject, readObjectNoData, and writeObject. These descriptions are not entirely consistent with one another and at least one is arguably misleading. > > This PR makes the brief discussion the same in both classes and addresses the misleading point: the throws clauses of the methods will not effect whether or not the methods are found by serialization, but throwing unchecked exceptions not declared in the standard signatures is ill-advised. (The current implementation looks up the methods by name using core reflection; the method modifiers are checked to match but the throws information is not.) > > Please also review the corresponding CSR : https://bugs.openjdk.java.net/browse/JDK-8275014 Marked as reviewed by smarks (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5883 From njian at openjdk.java.net Fri Oct 15 02:35:54 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Fri, 15 Oct 2021 02:35:54 GMT Subject: RFR: 8271515: Integration of JEP 417: Vector API (Third Incubator) [v2] In-Reply-To: <0LvaNkXLAVEoVt15uJ3Y2ZFzbctyTk9A76JhKXmZBqo=.f827b200-6aca-49ec-bcf5-76dbe194f4a0@github.com> References: <_QQ9ntdJJfzVcAGrbjev0ZM-xNfD4wNATphnXkb-Y00=.bbf46985-8776-4dda-ada5-b15ab50774aa@github.com> <0LvaNkXLAVEoVt15uJ3Y2ZFzbctyTk9A76JhKXmZBqo=.f827b200-6aca-49ec-bcf5-76dbe194f4a0@github.com> Message-ID: On Thu, 14 Oct 2021 17:21:25 GMT, Paul Sandoz wrote: >> This PR improves the performance of vector operations that accept masks on architectures that support masking in hardware, specifically Intel AVX512 and ARM SVE. >> >> On architectures that do not support masking in hardware the same technique as before is applied to most operations, specifically composition using blend. >> >> Masked loads/stores are a special form of masked operation that require additional care to ensure out-of-bounds access throw exceptions. The range checking has not been fully optimized and will require further work. >> >> No API enhancements were required and only a few additional tests were needed. > > Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision: > > Apply patch from https://github.com/openjdk/panama-vector/pull/152 > @njian there is a conflict with `macroAssembler_aarch64.cpp`: > > I think the resolution is this: > > ``` > @@ -2581,7 +2572,7 @@ void MacroAssembler::pop_call_clobbered_registers_except(RegSet exclude) { > > void MacroAssembler::push_CPU_state(bool save_vectors, bool use_sve, > int sve_vector_size_in_bytes, int total_predicate_in_bytes) { > - push(0x3fffffff, sp); // integer registers except lr & sp > + push(RegSet::range(r0, r29), sp); // integer registers except lr & sp > ``` > > is that correct? Yes, I think so. ------------- PR: https://git.openjdk.java.net/jdk/pull/5873 From duke at openjdk.java.net Fri Oct 15 07:23:59 2021 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Fri, 15 Oct 2021 07:23:59 GMT Subject: RFR: 8275293: A change done with JDK-8268764 mismatches the java.rmi.server.ObjID.hashCode spec Message-ID: It looks like we cannot use `Long.hashCode(long)` for `java.rmi.server.ObjID.hashCode()` due to JavaDoc: https://docs.oracle.com/en/java/javase/17/docs/api/java.rmi/java/rmi/server/ObjID.html#hashCode(). ------------- Commit messages: - 8275293: A change done with JDK-8268764 mismatches the java.rmi.server.ObjID.hashCode spec Changes: https://git.openjdk.java.net/jdk/pull/5963/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5963&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275293 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5963.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5963/head:pull/5963 PR: https://git.openjdk.java.net/jdk/pull/5963 From duke at openjdk.java.net Fri Oct 15 07:23:59 2021 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Fri, 15 Oct 2021 07:23:59 GMT Subject: RFR: 8275293: A change done with JDK-8268764 mismatches the java.rmi.server.ObjID.hashCode spec In-Reply-To: References: Message-ID: On Fri, 15 Oct 2021 07:17:52 GMT, ?????? ??????? wrote: > It looks like we cannot use `Long.hashCode(long)` for `java.rmi.server.ObjID.hashCode()` due to JavaDoc: https://docs.oracle.com/en/java/javase/17/docs/api/java.rmi/java/rmi/server/ObjID.html#hashCode(). @stuart-marks FYI ------------- PR: https://git.openjdk.java.net/jdk/pull/5963 From duke at openjdk.java.net Fri Oct 15 08:08:48 2021 From: duke at openjdk.java.net (Raffaello Giulietti) Date: Fri, 15 Oct 2021 08:08:48 GMT Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v2] In-Reply-To: References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com> Message-ID: On Fri, 16 Apr 2021 11:30:32 GMT, Raffaello Giulietti wrote: >> Hello, >> >> here's a PR for a patch submitted on March 2020 [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a thing. >> >> The patch has been edited to adhere to OpenJDK code conventions about multi-line (block) comments. Nothing in the code proper has changed, except for the addition of redundant but clarifying parentheses in some expressions. >> >> >> Greetings >> Raffaello > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > 4511638: Double.toString(double) sometimes produces incorrect results "All have the form 2^q10^(-k)" (Paul Zimmermann's reply) not quite, for example 0x1.00003eaba12cap-804 = 2251808225167717/2^855 is not of this form, but these cases come from the continued fraction expansion of 2^q10^(-k). (my reply) Right, it is correctly stated in the test class (to be pushed) but incorrectly in my previous post Raffaello ------------- PR: https://git.openjdk.java.net/jdk/pull/3402 From duke at openjdk.java.net Fri Oct 15 08:27:54 2021 From: duke at openjdk.java.net (zimmermann6) Date: Fri, 15 Oct 2021 08:27:54 GMT Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v2] In-Reply-To: References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com> Message-ID: On Thu, 14 Oct 2021 16:51:42 GMT, Raffaello Giulietti wrote: > All have the form 2^q*10^(-k) not quite, for example 0x1.00003eaba12cap-804 = 2251808225167717/2^855 is not of this form, but these cases come from the continued fraction expansion of 2^q*10^(-k). ------------- PR: https://git.openjdk.java.net/jdk/pull/3402 From aph-open at littlepinkcloud.com Fri Oct 15 08:57:37 2021 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Fri, 15 Oct 2021 09:57:37 +0100 Subject: Optimization (?) of HashSet(Collection) In-Reply-To: <909441633346463@mail.yandex.ru> References: <909441633346463@mail.yandex.ru> Message-ID: <1798fd2a-2c6c-998f-7174-ebb7ec859a1e@littlepinkcloud.com> On 10/4/21 12:57, ?????? ??????? wrote: > > in the code of HashSet(Collection) we have an optimization opportunity: > > public HashSet(Collection c) { > map = new HashMap<>(Math.max((int) (c.size()/.75f) + 1, 16)); > addAll(c); > } > > instead of using addAll() inherited from j.u.Collection we can use c.forEach(this::add): > > public HashSet(Collection c) { > map = new HashMap<>(Math.max((int) (c.size()/.75f) + 1, 16)); > c.forEach(this::add); > } > > This allows to rid Iterator and use counting loops for e.g. ArrayList instead of hasNext()/next(). Well, perhaps, but this sort of low-level hackery is not IMO something we should reflexively do in the core class libraries. > We are also likely to benefit from this change in case the argument collection is synchronized as it's going to be locked only once. That's a good point, but would a synchronized collection really lock coarsely around forEach(), rather than in add(). > I've used the benchmark [1] to analyze the impact and it demonstrates measurable improvement [2]. > > What puzzles we a bit is the result for j.u.ArrayList. At warm-up time it demonstrates better results than at measurement time: > > length = 10 > > # Run progress: 4,44% complete, ETA 00:21:41 > # Fork: 3 of 5 > # Warmup Iteration 1: 134,699 ns/op > # Warmup Iteration 2: 115,391 ns/op > # Warmup Iteration 3: 130,110 ns/op > # Warmup Iteration 4: 114,465 ns/op <---- > # Warmup Iteration 5: 114,849 ns/op > # Warmup Iteration 6: 115,073 ns/op > # Warmup Iteration 7: 113,988 ns/op > # Warmup Iteration 8: 115,301 ns/op > # Warmup Iteration 9: 115,452 ns/op > # Warmup Iteration 10: 124,493 ns/op <---- > Iteration 1: 123,776 ns/op > Iteration 2: 123,719 ns/op > Iteration 3: 123,725 ns/op > Iteration 4: 126,892 ns/op > Iteration 5: 125,493 ns/op > Iteration 6: 124,661 ns/op > Iteration 7: 123,783 ns/op > Iteration 8: 123,975 ns/op > Iteration 9: 124,047 ns/op > Iteration 10: 123,899 ns/op > > length = 100 > > # Run progress: 11,11% complete, ETA 00:20:10 > # Fork: 1 of 5 > # Warmup Iteration 1: 1236,695 ns/op > # Warmup Iteration 2: 1069,909 ns/op > # Warmup Iteration 3: 1243,852 ns/op > # Warmup Iteration 4: 1059,038 ns/op <---- > # Warmup Iteration 5: 1057,670 ns/op > # Warmup Iteration 6: 1057,117 ns/op > # Warmup Iteration 7: 1056,932 ns/op > # Warmup Iteration 8: 1054,909 ns/op > # Warmup Iteration 9: 1058,106 ns/op > # Warmup Iteration 10: 1145,699 ns/op <---- > Iteration 1: 1139,155 ns/op > Iteration 2: 1141,662 ns/op > Iteration 3: 1139,061 ns/op > Iteration 4: 1139,306 ns/op > Iteration 5: 1138,475 ns/op > Iteration 6: 1140,491 ns/op > Iteration 7: 1144,017 ns/op > Iteration 8: 1139,411 ns/op > Iteration 9: 1142,729 ns/op > Iteration 10: 1144,042 ns/op > > > Here I use 1 s warm-up iteration on 2s measurement iteration. It looks like at iteration 4 the code is top-optimized, > and later at the end of warm-up a kind of deoptimization happens. There's still visible improvement however. > > The benchmark is run with 5 forks, and this deoptimization is visible for length = {10, 100}. > > So my two question are: > - What is the reason of the deoptimization and can we do something about it? C2 does this sort of thing all the time: it's a heuristic probabilistic optimizer. I've seen plenty of bimodal examples, where inlining changes and each time a program is run it's either fast or slow, quasi-randomly. If you really want to know, use -prof perfasm in JMH. > - Whether suggested changes is worth implementations? IMO the gain is too small. Others may disagree. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From mgronlun at openjdk.java.net Fri Oct 15 09:27:54 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Fri, 15 Oct 2021 09:27:54 GMT Subject: RFR: 8266936: Add a finalization JFR event [v17] In-Reply-To: References: Message-ID: > Greetings, > > Object.finalize() was deprecated in JDK9. There is an ongoing effort to replace and mitigate Object.finalize() uses in the JDK libraries; please see https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. > > We also like to assist users in replacing and mitigating uses in non-JDK code. > > Hence, this changeset adds a periodic JFR event to help identify which classes are overriding Object.finalize(). > > Thanks > Markus Markus Gr?nlund has updated the pull request incrementally with two additional commits since the last revision: - renames - spelling ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4731/files - new: https://git.openjdk.java.net/jdk/pull/4731/files/96a9d6bf..9b418149 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=16 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=15-16 Stats: 80 lines in 6 files changed: 0 ins; 0 del; 80 mod Patch: https://git.openjdk.java.net/jdk/pull/4731.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4731/head:pull/4731 PR: https://git.openjdk.java.net/jdk/pull/4731 From duke at openjdk.java.net Fri Oct 15 09:30:18 2021 From: duke at openjdk.java.net (Mitsuru Kariya) Date: Fri, 15 Oct 2021 09:30:18 GMT Subject: RFR: 8153490: Cannot setBytes() if incoming buffer's length is bigger than number of elements we want to insert. [v5] In-Reply-To: References: Message-ID: <4MzAaDkmgdWxj_kxwdy7hq3I4jPQV39QX_Qg22TSjiI=.ff6a346a-4000-4cee-b50c-649a6a42ef14@github.com> > Fix `SerialBlob.setBytes(long pos, byte[] bytes, int offset, int length)` in the following cases: > > 1. `pos - 1 + bytes.length - offset > this.length() && pos - 1 + length <= this.length()` > The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully. > (test31) > > 2. `pos - 1 + length > this.length()` > The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully. *1 > (test32) > > 3. `pos == this.length() + 1` > The original implementation throws `SerialException` but this case should end successfully. *2 > (test33) > > 4. `length < 0` > The original implementation throws `ArrayIndexOutOfBoundsException` but this case should throw `SerialException`. > (test34) > > 5. `offset + length > Integer.MAX_VALUE` > The original implementation throws `ArrayIndexOutOfBoundsException` (or `OutOfMemoryError` in most cases) but this case should throw `SerialException`. > (test35) > > Additionally, fix `SerialClob.setString(long pos, String str, int offset, int length)` in the following cases: > > 1. `offset > str.length()` > The original implementaion throws `StringIndexOutOfBoundsException` but this case should throw `SerialException`. > (test39) > > 2. `pos - 1 + str.length() - offset > this.length() && pos - 1 + length <= this.length()` > The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully. > (test32) > > 3. `pos - 1 + length > this.length()` > The original implementaion throws `SerialException` but this case should end successfully. *3 > (test40) > > 4. `pos == this.length() + 1` > The original implementaion throws `SerialException` but this case should end successfully. *4 > (test41) > > 5. `length < 0` > The original implementation throws `StringIndexOutOfBoundsException` but this case should throw `SerialException`. > (test42) > > 6. `offset + length > Integer.MAX_VALUE` > The original implementation throws `ArrayIndexOutOfBoundsException` (or `OutOfMemoryError` in most cases) but this case should throw `SerialException`. > (test43) > > > The javadoc has also been modified according to the above. > > *1 The documentation of `Blob.setBytes()` says, "If the end of the Blob value is reached while writing the array of bytes, then the length of the Blob value will be increased to accommodate the extra bytes." > > *2 The documentation of `Blob.setBytes()` says, "If the value specified for pos is greater than the length+1 of the BLOB value then the behavior is undefined." > So, it should work correctly when pos == length+1 of the BLOB value. > > *3 The documentation of `Clob.setString()` says, "If the end of the Clob value is eached while writing the given string, then the length of the Clob value will be increased to accommodate the extra characters." > > *4 The documentation of `Clob.setString()` says, "If the value specified for pos is greater than the length+1 of the CLOB value then the behavior is undefined." > So, it should work correctly when pos == length+1 of the CLOB value. Mitsuru Kariya has updated the pull request incrementally with one additional commit since the last revision: Follow the comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4001/files - new: https://git.openjdk.java.net/jdk/pull/4001/files/69fb2f4a..c5d8056b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4001&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4001&range=03-04 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/4001.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4001/head:pull/4001 PR: https://git.openjdk.java.net/jdk/pull/4001 From mgronlun at openjdk.java.net Fri Oct 15 09:30:52 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Fri, 15 Oct 2021 09:30:52 GMT Subject: RFR: 8266936: Add a finalization JFR event [v16] In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 21:43:27 GMT, Coleen Phillimore wrote: >> Markus Gr?nlund 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. > > src/hotspot/share/jfr/support/jfrSymbolTable.cpp line 75: > >> 73: >> 74: JfrSymbolTable::JfrSymbolTable() : >> 75: _symbol_table(new SymbolTable(this)), > > I'm confused about which symbol table this is. Is this the same SymbolTable as classfile/symbolTable.cpp? that instance is assumed to be a singleton. Is this a different SymbolTable and can it have a different name (thought it was JfrSymbolTable). Renamed. ------------- PR: https://git.openjdk.java.net/jdk/pull/4731 From mgronlun at openjdk.java.net Fri Oct 15 09:30:53 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Fri, 15 Oct 2021 09:30:53 GMT Subject: RFR: 8266936: Add a finalization JFR event [v16] In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 22:36:30 GMT, Markus Gr?nlund wrote: >> src/hotspot/share/jfr/support/jfrSymbolTable.hpp line 68: >> >>> 66: template class, typename, size_t> >>> 67: friend class HashTableHost; >>> 68: typedef HashTableHost SymbolTable; >> >> Oh here it is. Since it's an enclosed type, can you rename it something simpler like Symbols and the other Strings? > > Maybe :) Renamed. ------------- PR: https://git.openjdk.java.net/jdk/pull/4731 From mli at openjdk.java.net Fri Oct 15 09:50:05 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Fri, 15 Oct 2021 09:50:05 GMT Subject: RFR: 8273111: Default timezone should return zone ID if /etc/localtime is valid but not canonicalization on linux [v4] In-Reply-To: References: <6gmVj3r1hjhG5jvo_dSly3ShNnZZSCn-NIjtnvSySrk=.a88def27-7b80-425b-9ab8-2f94f5004b47@github.com> Message-ID: On Thu, 14 Oct 2021 02:08:45 GMT, Wu Yan wrote: >> Hi, >> Please help me review the change to enhance getting time zone ID from /etc/localtime on linux. >> >> We use `realpath` instead of `readlink` to obtain the link name of /etc/localtime, because `readlink` can only read the value of a symbolic of link, not the canonicalized absolute pathname. >> >> For example, the value of /etc/localtime is "../usr/share/zoneinfo//Asia/Shanghai", then the linkbuf obtained by `readlink` is "../usr/share/zoneinfo//Asia/Shanghai", and then the call of `getZoneName(linkbuf)` will get "/Asia/Shanghai", not "Asia/Shanghai", which consider as invalid in `ZoneInfoFile.getZoneInfo()`. Using `realpath`, you can get ?/usr/share/zoneinfo/Asia/Shanghai? directly from ?/etc/localtime?. >> >> Thanks, >> wuyan > > Wu Yan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge branch 'master' into timezone > - change functions to be static > - replace realpath > - 8273111: Default timezone should return zone ID if /etc/localtime is valid but not canonicalization on linux src/java.base/unix/native/libjava/TimeZone_md.c line 82: > 80: > 81: /* > 82: * remove repeated path separators ('/') in the giving 'path'. given? src/java.base/unix/native/libjava/TimeZone_md.c line 89: > 87: char *left = path; > 88: char *right = path; > 89: char *end = path + strlen(path); "char* end"? better to align with existing code style src/java.base/unix/native/libjava/TimeZone_md.c line 95: > 93: for (; right < end; right++) { > 94: if (*right == '/' && *(right + 1) == '/') break; > 95: } Is this for loop necessary? Seems it's ok to merge with the nested loop below. ------------- PR: https://git.openjdk.java.net/jdk/pull/5327 From prappo at openjdk.java.net Fri Oct 15 11:46:49 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Fri, 15 Oct 2021 11:46:49 GMT Subject: RFR: 8275293: A change done with JDK-8268764 mismatches the java.rmi.server.ObjID.hashCode spec In-Reply-To: References: Message-ID: <5N0Wnnrkg1Ev859mmdvDCp7qmhhxLHVPFoia8_SD3yE=.348c06b8-c444-4cc8-8903-c2aac0ed7e0d@github.com> On Fri, 15 Oct 2021 07:17:52 GMT, ?????? ??????? wrote: > It looks like we cannot use `Long.hashCode(long)` for `java.rmi.server.ObjID.hashCode()` due to JavaDoc: https://docs.oracle.com/en/java/javase/17/docs/api/java.rmi/java/rmi/server/ObjID.html#hashCode(). It's important to be precise here: it's not "JavaDoc", it's the specification. ------------- PR: https://git.openjdk.java.net/jdk/pull/5963 From duke at openjdk.java.net Fri Oct 15 12:45:51 2021 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Fri, 15 Oct 2021 12:45:51 GMT Subject: RFR: 8275293: A change done with JDK-8268764 mismatches the java.rmi.server.ObjID.hashCode spec In-Reply-To: <5N0Wnnrkg1Ev859mmdvDCp7qmhhxLHVPFoia8_SD3yE=.348c06b8-c444-4cc8-8903-c2aac0ed7e0d@github.com> References: <5N0Wnnrkg1Ev859mmdvDCp7qmhhxLHVPFoia8_SD3yE=.348c06b8-c444-4cc8-8903-c2aac0ed7e0d@github.com> Message-ID: <9H-CanYqBMiem_KItZYS5-WWh3fvscDCTgRSL1mpMTM=.0cd152d1-a750-4dfc-92e9-cac06f247a0a@github.com> On Fri, 15 Oct 2021 11:43:53 GMT, Pavel Rappo wrote: >> It looks like we cannot use `Long.hashCode(long)` for `java.rmi.server.ObjID.hashCode()` due to specification: https://docs.oracle.com/en/java/javase/17/docs/api/java.rmi/java/rmi/server/ObjID.html#hashCode(). > > It's important to be precise here: it's not "JavaDoc", it's the specification. @pavelrappo you are right. I've reworded the description ------------- PR: https://git.openjdk.java.net/jdk/pull/5963 From duke at openjdk.java.net Fri Oct 15 14:08:08 2021 From: duke at openjdk.java.net (Vamsi Parasa) Date: Fri, 15 Oct 2021 14:08:08 GMT Subject: RFR: 8275167: x86 intrinsic for unsignedMultiplyHigh Message-ID: <7IzrZdL0elgXbuisyLNYC2wkyOTe1RHUPuGRI7YsAQ4=.aed9dea3-4775-4592-b43e-c3e08e167f90@github.com> Optimize the new Math.unsignedMultiplyHigh using the x86 mul instruction. This change show 1.87X improvement on a micro benchmark. ------------- Commit messages: - fix typo in function name - 8275167: x86 intrinsic for unsignedMultiplyHigh Changes: https://git.openjdk.java.net/jdk/pull/5933/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5933&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275167 Stats: 59 lines in 11 files changed: 59 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5933.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5933/head:pull/5933 PR: https://git.openjdk.java.net/jdk/pull/5933 From rriggs at openjdk.java.net Fri Oct 15 14:21:55 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 15 Oct 2021 14:21:55 GMT Subject: RFR: 8275293: A change done with JDK-8268764 mismatches the java.rmi.server.ObjID.hashCode spec In-Reply-To: References: Message-ID: On Fri, 15 Oct 2021 07:17:52 GMT, ?????? ??????? wrote: > It looks like we cannot use `Long.hashCode(long)` for `java.rmi.server.ObjID.hashCode()` due to specification: https://docs.oracle.com/en/java/javase/17/docs/api/java.rmi/java/rmi/server/ObjID.html#hashCode(). Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5963 From rriggs at openjdk.java.net Fri Oct 15 14:42:48 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 15 Oct 2021 14:42:48 GMT Subject: RFR: 8275013: Improve discussion of serialization method declarations in java.io.Object{Input, Output}Stream In-Reply-To: References: Message-ID: On Sun, 10 Oct 2021 20:25:43 GMT, Joe Darcy wrote: > The java.io.ObjectInputStream and java.io.ObjectOuputStream classes are part of the serialization feature. These classes contain brief descriptions of some of the methods serializable classes can define to interact with the serialization mechanism, readObject, readObjectNoData, and writeObject. These descriptions are not entirely consistent with one another and at least one is arguably misleading. > > This PR makes the brief discussion the same in both classes and addresses the misleading point: the throws clauses of the methods will not effect whether or not the methods are found by serialization, but throwing unchecked exceptions not declared in the standard signatures is ill-advised. (The current implementation looks up the methods by name using core reflection; the method modifiers are checked to match but the throws information is not.) > > Please also review the corresponding CSR : https://bugs.openjdk.java.net/browse/JDK-8275014 Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5883 From plevart at openjdk.java.net Fri Oct 15 15:12:57 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Fri, 15 Oct 2021 15:12:57 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v13] In-Reply-To: References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> Message-ID: On Thu, 14 Oct 2021 16:05:19 GMT, Mandy Chung wrote: >> src/java.base/share/classes/jdk/internal/reflect/DirectMethodHandleAccessor.java line 86: >> >>> 84: } >>> 85: >>> 86: private static final int PARAM_COUNT_MASK = 0x00FF; >> >> Is this packing logic required? I get it that it saves footprint - but then you have to always unmask bits to get the argument count (see invoke and other places). If you keep this, it might be worth documenting what the bit layout is supposed to be? > > It's not driven by performance data. It's part of Peter's contribution. I also prefer it without the packing. I propose to keep the parameter count as a separate field and examine it when there is footprint issue. The reason for this packing is (was) ORing the value with a non-zero value so that field never held zero value. When for example an individual value (say paramCount) is used in a separate @Stable field, its value set may include the default value (zero) which is then not optimized by JIT as a constant. This is from @Stable docs: * By extension, any variable (either array or field) which has annotated * as stable is called a stable variable, and its non-null or non-zero * value is called a stable value. ...and: * The HotSpot VM relies on this annotation to promote a non-null (resp., * non-zero) component value to a constant, thereby enabling superior * optimizations of code depending on such a value (such as constant folding). * More specifically, the HotSpot VM will process non-null stable fields (final * or otherwise) in a similar manner to static final fields with respect to * promoting the field's value to a constant. Thus, placing aside the * differences for null/non-null values and arrays, a final stable field is * treated as if it is really final from both the Java language and the HotSpot So now that some of these fields are final and not annotated with @Stable any more but are treated as "trusted final" fields, the question is whether JIT is treating the default (zero, null) values differently or not. If they are treated as static final fields where default value makes no difference, then it's ok to split this multi-valued field into individual fields. ------------- PR: https://git.openjdk.java.net/jdk/pull/5027 From dfuchs at openjdk.java.net Fri Oct 15 15:31:53 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 15 Oct 2021 15:31:53 GMT Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v3] In-Reply-To: References: Message-ID: <-JuSgJLSkme6YraHYehOdUah6GSER-EUo3Mq4TVjXKU=.f700cbe6-021a-43c4-a5ae-c0dc7b42d313@github.com> On Tue, 12 Oct 2021 15:43:24 GMT, Aleksei Efimov wrote: >> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver. >> >> The following API classes are added to `java.net.spi` package to facilitate this: >> - `InetAddressResolverProvider` - abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers. >> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations. >> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations. >> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation. >> >> More details in [JEP-418](https://openjdk.java.net/jeps/418). >> >> Testing: new and existing `tier1:tier3` tests > > Aleksei Efimov has updated the pull request incrementally with two additional commits since the last revision: > > - Add @since tags to new API classes > - Add checks and test for empty stream resolver results src/java.base/share/classes/java/net/InetAddress.java line 231: > 229: * The first provider found will be used to instantiate the {@link InetAddressResolver InetAddressResolver} > 230: * by invoking the {@link InetAddressResolverProvider#get(InetAddressResolverProvider.Configuration)} > 231: * method. The instantiated {@code InetAddressResolver} will be installed as the system-wide Maybe "... method. The **returned** {@code InetAddressResolver} will be installed ..." src/java.base/share/classes/java/net/InetAddress.java line 486: > 484: return cns; > 485: } finally { > 486: bootstrapResolver = null; This is incorrect. This will set bootstrapResolver to null in the case where you return it at line 468 - which means that a second call will then find it null. I believe you want to set it to null in the finally clause only if you reached line 470. You could achieve this by declaring a local variable - e.g `InetAddressResolver tempResolver = null;` before entering the try-finally then set that variable at line 470 `return tempResolver = bootstrapResolver;` and in finally do `if (tempResolver == null) bootsrapResolver = null;` To test this you could try to call e.g. `InetAddress.getByName` twice in succession in your test: I believe it will fail with the code as it stands, but will succeed with my proposed changes... src/java.base/share/classes/java/net/InetAddress.java line 860: > 858: return host; > 859: } > 860: } catch (RuntimeException | UnknownHostException e) { This may deserve a comment: resolver.lookUpHostName and InetAddress.getAllbyName0 delegate to the system-wide resolver, which could be custom, and we treat any unexpected RuntimeException thrown by the provider at that point as we would treat an UnknownHostException or an unmatched host name. src/java.base/share/classes/java/net/InetAddress.java line 1063: > 1061: public Stream lookupAddresses(String host, LookupPolicy policy) > 1062: throws UnknownHostException { > 1063: Objects.requireNonNull(host); Should we also double check that `policy` is not null? Or maybe assert it? src/java.base/share/classes/java/net/InetAddress.java line 1203: > 1201: + " as hosts file " + hostsFile + " not found "); > 1202: } > 1203: // Check number of found addresses: I wonder if the logic here could be simplified by first checking whether only IPv4 addresses are requested, and then if only IPv6 addresses are requested. That is - evacuate the simple cases first and then only deal with the more complex case where you have to combine the two lists... ------------- PR: https://git.openjdk.java.net/jdk/pull/5822 From bpb at openjdk.java.net Fri Oct 15 15:56:51 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 15 Oct 2021 15:56:51 GMT Subject: RFR: 8275167: x86 intrinsic for unsignedMultiplyHigh In-Reply-To: <7IzrZdL0elgXbuisyLNYC2wkyOTe1RHUPuGRI7YsAQ4=.aed9dea3-4775-4592-b43e-c3e08e167f90@github.com> References: <7IzrZdL0elgXbuisyLNYC2wkyOTe1RHUPuGRI7YsAQ4=.aed9dea3-4775-4592-b43e-c3e08e167f90@github.com> Message-ID: On Wed, 13 Oct 2021 18:55:10 GMT, Vamsi Parasa wrote: > Optimize the new Math.unsignedMultiplyHigh using the x86 mul instruction. This change show 1.87X improvement on a micro benchmark. The `java.lang.Math` change looks good, of course. On the rest I cannot comment but it is good to see something being done here. ------------- PR: https://git.openjdk.java.net/jdk/pull/5933 From aph at openjdk.java.net Fri Oct 15 16:17:51 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Fri, 15 Oct 2021 16:17:51 GMT Subject: RFR: 8275167: x86 intrinsic for unsignedMultiplyHigh In-Reply-To: <7IzrZdL0elgXbuisyLNYC2wkyOTe1RHUPuGRI7YsAQ4=.aed9dea3-4775-4592-b43e-c3e08e167f90@github.com> References: <7IzrZdL0elgXbuisyLNYC2wkyOTe1RHUPuGRI7YsAQ4=.aed9dea3-4775-4592-b43e-c3e08e167f90@github.com> Message-ID: On Wed, 13 Oct 2021 18:55:10 GMT, Vamsi Parasa wrote: > Optimize the new Math.unsignedMultiplyHigh using the x86 mul instruction. This change show 1.87X improvement on a micro benchmark. src/hotspot/share/opto/mulnode.cpp line 468: > 466: } > 467: > 468: //============================================================================= MulHiLNode::Value() and UMulHiLNode::Value() seem to be identical. Perhaps some refactoring would be in order, maybe make a common shared routine. ------------- PR: https://git.openjdk.java.net/jdk/pull/5933 From darcy at openjdk.java.net Fri Oct 15 16:20:52 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 15 Oct 2021 16:20:52 GMT Subject: Integrated: 8275013: Improve discussion of serialization method declarations in java.io.Object{Input, Output}Stream In-Reply-To: References: Message-ID: On Sun, 10 Oct 2021 20:25:43 GMT, Joe Darcy wrote: > The java.io.ObjectInputStream and java.io.ObjectOuputStream classes are part of the serialization feature. These classes contain brief descriptions of some of the methods serializable classes can define to interact with the serialization mechanism, readObject, readObjectNoData, and writeObject. These descriptions are not entirely consistent with one another and at least one is arguably misleading. > > This PR makes the brief discussion the same in both classes and addresses the misleading point: the throws clauses of the methods will not effect whether or not the methods are found by serialization, but throwing unchecked exceptions not declared in the standard signatures is ill-advised. (The current implementation looks up the methods by name using core reflection; the method modifiers are checked to match but the throws information is not.) > > Please also review the corresponding CSR : https://bugs.openjdk.java.net/browse/JDK-8275014 This pull request has now been integrated. Changeset: 8c4da9c1 Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/8c4da9c15fec7bd27e243e9a6c9ebcad63109506 Stats: 18 lines in 2 files changed: 13 ins; 0 del; 5 mod 8275013: Improve discussion of serialization method declarations in java.io.Object{Input, Output}Stream Reviewed-by: smarks, rriggs ------------- PR: https://git.openjdk.java.net/jdk/pull/5883 From mcimadamore at openjdk.java.net Fri Oct 15 16:54:58 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 15 Oct 2021 16:54:58 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v5] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/419 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: * Fix javadoc issue in VaList * Fix bug in concurrent logic for shared scope acquire ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5907/files - new: https://git.openjdk.java.net/jdk/pull/5907/files/27e71ee7..5ed94c30 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=03-04 Stats: 10 lines in 2 files changed: 2 ins; 3 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/5907.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5907/head:pull/5907 PR: https://git.openjdk.java.net/jdk/pull/5907 From mcimadamore at openjdk.java.net Fri Oct 15 16:56:08 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 15 Oct 2021 16:56:08 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v5] In-Reply-To: References: Message-ID: On Fri, 15 Oct 2021 16:54:58 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/419 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > * Fix javadoc issue in VaList > * Fix bug in concurrent logic for shared scope acquire src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/SharedScope.java line 138: > 136: ResourceCleanup prev = (ResourceCleanup) FST.getAcquire(this); > 137: cleanup.next = prev; > 138: ResourceCleanup newSegment = (ResourceCleanup) FST.compareAndExchangeRelease(this, prev, cleanup); In this place we can actually overwrite CLOSED_LIST (if getAcquired has seen such value). While this particular add will fail later on (since we check witness), another concurrent add might then pass, since it sees a value other than CLOSED_LIST (which is supposed to be a terminal state). Also, after consulting with @DougLea and @shipilev - it seems like using volatile semantics is the way to go here. This should fix a spurious (and very rare) failure on TestResourceScope on arm64. ------------- PR: https://git.openjdk.java.net/jdk/pull/5907 From aph at openjdk.java.net Fri Oct 15 16:58:52 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Fri, 15 Oct 2021 16:58:52 GMT Subject: RFR: 8275167: x86 intrinsic for unsignedMultiplyHigh In-Reply-To: <7IzrZdL0elgXbuisyLNYC2wkyOTe1RHUPuGRI7YsAQ4=.aed9dea3-4775-4592-b43e-c3e08e167f90@github.com> References: <7IzrZdL0elgXbuisyLNYC2wkyOTe1RHUPuGRI7YsAQ4=.aed9dea3-4775-4592-b43e-c3e08e167f90@github.com> Message-ID: On Wed, 13 Oct 2021 18:55:10 GMT, Vamsi Parasa wrote: > Optimize the new Math.unsignedMultiplyHigh using the x86 mul instruction. This change show 1.87X improvement on a micro benchmark. test/micro/org/openjdk/bench/java/lang/MathBench.java line 547: > 545: return Math.unsignedMultiplyHigh(long747, long13); > 546: } > 547: As far as I can tell, the JMH overhead dominates when trying to measure the latency of events in the nanosecond range. `unsignedMultiplyHigh` should have a latency of maybe 1.5-2ns. Is that what you saw? ------------- PR: https://git.openjdk.java.net/jdk/pull/5933 From dfuchs at openjdk.java.net Fri Oct 15 17:24:53 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 15 Oct 2021 17:24:53 GMT Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v3] In-Reply-To: References: Message-ID: On Tue, 12 Oct 2021 15:43:24 GMT, Aleksei Efimov wrote: >> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver. >> >> The following API classes are added to `java.net.spi` package to facilitate this: >> - `InetAddressResolverProvider` - abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers. >> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations. >> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations. >> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation. >> >> More details in [JEP-418](https://openjdk.java.net/jeps/418). >> >> Testing: new and existing `tier1:tier3` tests > > Aleksei Efimov has updated the pull request incrementally with two additional commits since the last revision: > > - Add @since tags to new API classes > - Add checks and test for empty stream resolver results test/jdk/java/net/spi/InetAddressResolverProvider/providers/recursive/recursive.init.provider/impl/InetAddressUsageInGetProviderImpl.java line 38: > 36: String localHostName; > 37: try { > 38: localHostName = InetAddress.getLocalHost().getHostName(); Try to call InetAddress.getLocalHost().getHostName(); twice here. test/lib/jdk/test/lib/net/IPSupport.java line 88: > 86: } catch (SocketException se2) { > 87: return false; > 88: } The implementation of this method now conflicts with its name. Maybe we should pass a `Class` as parameter, and construct the loopback address from there. IIRC the issue with the original implementation was that it would say that IPv6 was not supported if IPv6 had only been disabled on the loopback interface - and that caused trouble because the native implementation of the built-in resolver had a different view of the situation - and saw that an IPv6 stack was available on the machine. Maybe this would deserve a comment too - so that future maintainers can figure out what we are trying to do here. ------------- PR: https://git.openjdk.java.net/jdk/pull/5822 From darcy at openjdk.java.net Fri Oct 15 17:28:52 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 15 Oct 2021 17:28:52 GMT Subject: Integrated: JDK-8275249: Suppress warnings on non-serializable array component types in jdk.jlink In-Reply-To: References: Message-ID: <-g2U7sa0mJLb9s0G9tYlHq2QZdOXClo7qJQFv8eD6gY=.2469e6ee-fa58-4a25-8d47-171817bcd2cf@github.com> On Wed, 13 Oct 2021 21:08:41 GMT, Joe Darcy wrote: > After a refinement to the checks under development in #5709, the new checks examine array types of serial fields and warn if the underlying component type is not serializable. Per the JLS, all array types are serializable, but if the base component is not serializable, the serialization process can throw an exception. > > From "Java Object Serialization Specification: 2 - Object Output Classes": > > "If the object is an array, writeObject is called recursively to write the ObjectStreamClass of the array. The handle for the array is assigned. It is followed by the length of the array. Each element of the array is then written to the stream, after which writeObject returns." > > The jdk.jlink module has one instance of this coding pattern that needs suppression to compile successfully under the future warning. This pull request has now been integrated. Changeset: f1781851 Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/f17818516cf80e6e208309200c98b23919c3cddb Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8275249: Suppress warnings on non-serializable array component types in jdk.jlink Reviewed-by: iris ------------- PR: https://git.openjdk.java.net/jdk/pull/5936 From coleenp at openjdk.java.net Fri Oct 15 18:16:55 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 15 Oct 2021 18:16:55 GMT Subject: RFR: 8266936: Add a finalization JFR event [v17] In-Reply-To: References: Message-ID: On Fri, 15 Oct 2021 09:27:54 GMT, Markus Gr?nlund wrote: >> Greetings, >> >> Object.finalize() was deprecated in JDK9. There is an ongoing effort to replace and mitigate Object.finalize() uses in the JDK libraries; please see https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. >> >> We also like to assist users in replacing and mitigating uses in non-JDK code. >> >> Hence, this changeset adds a periodic JFR event to help identify which classes are overriding Object.finalize(). >> >> Thanks >> Markus > > Markus Gr?nlund has updated the pull request incrementally with two additional commits since the last revision: > > - renames > - spelling Thanks for doing the renames. Looks good! ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4731 From kvn at openjdk.java.net Fri Oct 15 18:48:48 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 15 Oct 2021 18:48:48 GMT Subject: RFR: 8275167: x86 intrinsic for unsignedMultiplyHigh In-Reply-To: <7IzrZdL0elgXbuisyLNYC2wkyOTe1RHUPuGRI7YsAQ4=.aed9dea3-4775-4592-b43e-c3e08e167f90@github.com> References: <7IzrZdL0elgXbuisyLNYC2wkyOTe1RHUPuGRI7YsAQ4=.aed9dea3-4775-4592-b43e-c3e08e167f90@github.com> Message-ID: On Wed, 13 Oct 2021 18:55:10 GMT, Vamsi Parasa wrote: > Optimize the new Math.unsignedMultiplyHigh using the x86 mul instruction. This change show 1.87X improvement on a micro benchmark. How you verified correctness of results? I suggest to extend `test/jdk//java/lang/Math/MultiplicationTests.java` test to cover unsigned method. ------------- Changes requested by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5933 From duke at openjdk.java.net Fri Oct 15 19:21:53 2021 From: duke at openjdk.java.net (Vamsi Parasa) Date: Fri, 15 Oct 2021 19:21:53 GMT Subject: RFR: 8275167: x86 intrinsic for unsignedMultiplyHigh In-Reply-To: References: <7IzrZdL0elgXbuisyLNYC2wkyOTe1RHUPuGRI7YsAQ4=.aed9dea3-4775-4592-b43e-c3e08e167f90@github.com> Message-ID: On Fri, 15 Oct 2021 18:45:41 GMT, Vladimir Kozlov wrote: > How you verified correctness of results? I suggest to extend `test/jdk//java/lang/Math/MultiplicationTests.java` test to cover unsigned method. Tests for unsignedMultiplyHigh were already added in test/jdk//java/lang/Math/MultiplicationTests.java (in July 2021 by Brian Burkhalter). Used that test to verify the correctness of the results. ------------- PR: https://git.openjdk.java.net/jdk/pull/5933 From duke at openjdk.java.net Fri Oct 15 19:34:00 2021 From: duke at openjdk.java.net (Vamsi Parasa) Date: Fri, 15 Oct 2021 19:34:00 GMT Subject: RFR: 8275167: x86 intrinsic for unsignedMultiplyHigh In-Reply-To: References: <7IzrZdL0elgXbuisyLNYC2wkyOTe1RHUPuGRI7YsAQ4=.aed9dea3-4775-4592-b43e-c3e08e167f90@github.com> Message-ID: On Fri, 15 Oct 2021 16:14:25 GMT, Andrew Haley wrote: >> Optimize the new Math.unsignedMultiplyHigh using the x86 mul instruction. This change show 1.87X improvement on a micro benchmark. > > src/hotspot/share/opto/mulnode.cpp line 468: > >> 466: } >> 467: >> 468: //============================================================================= > > MulHiLNode::Value() and UMulHiLNode::Value() seem to be identical. Perhaps some refactoring would be in order, maybe make a common shared routine. Sure, will do the refactoring to use a shared routine. > test/micro/org/openjdk/bench/java/lang/MathBench.java line 547: > >> 545: return Math.unsignedMultiplyHigh(long747, long13); >> 546: } >> 547: > > As far as I can tell, the JMH overhead dominates when trying to measure the latency of events in the nanosecond range. `unsignedMultiplyHigh` should have a latency of maybe 1.5-2ns. Is that what you saw? Yes, the JMH overhead was dominating the measurement of latency. The latency observed for `unsignedMultiplyHigh` was 2.3ns with the intrinsic enabled. ------------- PR: https://git.openjdk.java.net/jdk/pull/5933 From lancea at openjdk.java.net Fri Oct 15 20:14:56 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Fri, 15 Oct 2021 20:14:56 GMT Subject: RFR: 8153490: Cannot setBytes() if incoming buffer's length is bigger than number of elements we want to insert. [v5] In-Reply-To: <4MzAaDkmgdWxj_kxwdy7hq3I4jPQV39QX_Qg22TSjiI=.ff6a346a-4000-4cee-b50c-649a6a42ef14@github.com> References: <4MzAaDkmgdWxj_kxwdy7hq3I4jPQV39QX_Qg22TSjiI=.ff6a346a-4000-4cee-b50c-649a6a42ef14@github.com> Message-ID: <_0nDdDcIZ4OQr7EJyzINbD4kRrRmbkF3_KPzz-BlFBA=.92dcb8ec-eb04-49b8-b7ea-48bacc749166@github.com> On Fri, 15 Oct 2021 09:30:18 GMT, Mitsuru Kariya wrote: >> Fix `SerialBlob.setBytes(long pos, byte[] bytes, int offset, int length)` in the following cases: >> >> 1. `pos - 1 + bytes.length - offset > this.length() && pos - 1 + length <= this.length()` >> The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully. >> (test31) >> >> 2. `pos - 1 + length > this.length()` >> The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully. *1 >> (test32) >> >> 3. `pos == this.length() + 1` >> The original implementation throws `SerialException` but this case should end successfully. *2 >> (test33) >> >> 4. `length < 0` >> The original implementation throws `ArrayIndexOutOfBoundsException` but this case should throw `SerialException`. >> (test34) >> >> 5. `offset + length > Integer.MAX_VALUE` >> The original implementation throws `ArrayIndexOutOfBoundsException` (or `OutOfMemoryError` in most cases) but this case should throw `SerialException`. >> (test35) >> >> Additionally, fix `SerialClob.setString(long pos, String str, int offset, int length)` in the following cases: >> >> 1. `offset > str.length()` >> The original implementaion throws `StringIndexOutOfBoundsException` but this case should throw `SerialException`. >> (test39) >> >> 2. `pos - 1 + str.length() - offset > this.length() && pos - 1 + length <= this.length()` >> The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully. >> (test32) >> >> 3. `pos - 1 + length > this.length()` >> The original implementaion throws `SerialException` but this case should end successfully. *3 >> (test40) >> >> 4. `pos == this.length() + 1` >> The original implementaion throws `SerialException` but this case should end successfully. *4 >> (test41) >> >> 5. `length < 0` >> The original implementation throws `StringIndexOutOfBoundsException` but this case should throw `SerialException`. >> (test42) >> >> 6. `offset + length > Integer.MAX_VALUE` >> The original implementation throws `ArrayIndexOutOfBoundsException` (or `OutOfMemoryError` in most cases) but this case should throw `SerialException`. >> (test43) >> >> >> The javadoc has also been modified according to the above. >> >> *1 The documentation of `Blob.setBytes()` says, "If the end of the Blob value is reached while writing the array of bytes, then the length of the Blob value will be increased to accommodate the extra bytes." >> >> *2 The documentation of `Blob.setBytes()` says, "If the value specified for pos is greater than the length+1 of the BLOB value then the behavior is undefined." >> So, it should work correctly when pos == length+1 of the BLOB value. >> >> *3 The documentation of `Clob.setString()` says, "If the end of the Clob value is eached while writing the given string, then the length of the Clob value will be increased to accommodate the extra characters." >> >> *4 The documentation of `Clob.setString()` says, "If the value specified for pos is greater than the length+1 of the CLOB value then the behavior is undefined." >> So, it should work correctly when pos == length+1 of the CLOB value. > > Mitsuru Kariya has updated the pull request incrementally with one additional commit since the last revision: > > Follow the comment Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4001 From duke at openjdk.java.net Fri Oct 15 20:15:05 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Fri, 15 Oct 2021 20:15:05 GMT Subject: RFR: 8275342: Change nested classes in java.prefs to static nested classes Message-ID: Non-static classes hold a link to their parent classes, which can be avoided. ------------- Commit messages: - [PATCH] Change nested classes in java.prefs to static nested classes Changes: https://git.openjdk.java.net/jdk/pull/5971/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5971&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275342 Stats: 20 lines in 3 files changed: 1 ins; 11 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/5971.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5971/head:pull/5971 PR: https://git.openjdk.java.net/jdk/pull/5971 From duke at openjdk.java.net Fri Oct 15 20:15:06 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Fri, 15 Oct 2021 20:15:06 GMT Subject: RFR: 8275342: Change nested classes in java.prefs to static nested classes In-Reply-To: References: Message-ID: On Fri, 15 Oct 2021 18:51:44 GMT, Andrey Turbanov wrote: > Non-static classes hold a link to their parent classes, which can be avoided. src/java.prefs/macosx/classes/java/util/prefs/MacOSXPreferencesFile.java line 102: > 100: } > 101: > 102: private class SyncTask extends TimerTask { IDEA suggested to add `static` here too. But this class is unused. And I think it's better to drop it. ------------- PR: https://git.openjdk.java.net/jdk/pull/5971 From kvn at openjdk.java.net Fri Oct 15 20:22:45 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 15 Oct 2021 20:22:45 GMT Subject: RFR: 8275167: x86 intrinsic for unsignedMultiplyHigh In-Reply-To: References: <7IzrZdL0elgXbuisyLNYC2wkyOTe1RHUPuGRI7YsAQ4=.aed9dea3-4775-4592-b43e-c3e08e167f90@github.com> Message-ID: <8MuiklM5Nt3VkzyVHbWqwMh_LkVvVY2Mf65_0zTx4Kw=.9351008f-b489-4103-be9d-87e6fc4a8f39@github.com> On Fri, 15 Oct 2021 19:19:13 GMT, Vamsi Parasa wrote: > > How you verified correctness of results? I suggest to extend `test/jdk//java/lang/Math/MultiplicationTests.java` test to cover unsigned method. > > Tests for unsignedMultiplyHigh were already added in test/jdk//java/lang/Math/MultiplicationTests.java (in July 2021 by Brian Burkhalter). Used that test to verify the correctness of the results. Good. It seems I have old version of the test. Did you run it with -Xcomp? How you verified that intrinsic is used? ------------- PR: https://git.openjdk.java.net/jdk/pull/5933 From naoto at openjdk.java.net Fri Oct 15 20:39:56 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 15 Oct 2021 20:39:56 GMT Subject: Integrated: 8275145: file.encoding system property has an incorrect value on Windows In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 15:50:28 GMT, Naoto Sato wrote: > Fixing a regression in which `file.encoding` was initialized by `sprops->encoding` instead of `sprops->sun_jnu_encoding` on non macOS platforms. tier1-3 tests passed on all platforms. This pull request has now been integrated. Changeset: ad9e234f Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/ad9e234f5ed61635f926618a40f453fe7b6b491f Stats: 9 lines in 1 file changed: 8 ins; 0 del; 1 mod 8275145: file.encoding system property has an incorrect value on Windows Reviewed-by: mchung, iris, rriggs, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/5953 From lancea at openjdk.java.net Fri Oct 15 20:41:52 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Fri, 15 Oct 2021 20:41:52 GMT Subject: Integrated: 8275163: Deflater::deflate methods omit javadoc for ReadOnlyBufferException In-Reply-To: <4urLy1RPeFcDkf62nUQf3ijw8FGxNJhjYD8pTvYK0Xc=.ec34d620-1240-4b01-9fae-44823f20c90d@github.com> References: <4urLy1RPeFcDkf62nUQf3ijw8FGxNJhjYD8pTvYK0Xc=.ec34d620-1240-4b01-9fae-44823f20c90d@github.com> Message-ID: <3XckL6YXHlbGoPBWvbKpGSXQMurbNB-d5Z5Aiy8Ql4s=.a98b5eaa-dc8b-46c3-bab4-12c3ebcfd3a1@github.com> On Wed, 13 Oct 2021 17:43:29 GMT, Lance Andersen wrote: > Hi all, > > Please review the fix to address a javadoc issue for the Deflater::deflate methods that were added as part of JDK-6341887 that could throw a ReadOnlyBufferException. > > The` @throws ` clause for `ReadOnlyBufferException` was inadvertently omitted from the javadoc for these new methods. > > A CSR, JDK-8275164, has also been created for this issue. > > Best > Lance This pull request has now been integrated. Changeset: 831802dd Author: Lance Andersen URL: https://git.openjdk.java.net/jdk/commit/831802ddb103f8f9747a9fb139af8365924da801 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8275163: Deflater::deflate methods omit javadoc for ReadOnlyBufferException Reviewed-by: bpb, iris, naoto ------------- PR: https://git.openjdk.java.net/jdk/pull/5931 From duke at openjdk.java.net Fri Oct 15 21:06:52 2021 From: duke at openjdk.java.net (Vamsi Parasa) Date: Fri, 15 Oct 2021 21:06:52 GMT Subject: RFR: 8275167: x86 intrinsic for unsignedMultiplyHigh In-Reply-To: <8MuiklM5Nt3VkzyVHbWqwMh_LkVvVY2Mf65_0zTx4Kw=.9351008f-b489-4103-be9d-87e6fc4a8f39@github.com> References: <7IzrZdL0elgXbuisyLNYC2wkyOTe1RHUPuGRI7YsAQ4=.aed9dea3-4775-4592-b43e-c3e08e167f90@github.com> <8MuiklM5Nt3VkzyVHbWqwMh_LkVvVY2Mf65_0zTx4Kw=.9351008f-b489-4103-be9d-87e6fc4a8f39@github.com> Message-ID: On Fri, 15 Oct 2021 20:19:31 GMT, Vladimir Kozlov wrote: > > > How you verified correctness of results? I suggest to extend `test/jdk//java/lang/Math/MultiplicationTests.java` test to cover unsigned method. > > > > > > Tests for unsignedMultiplyHigh were already added in test/jdk//java/lang/Math/MultiplicationTests.java (in July 2021 by Brian Burkhalter). Used that test to verify the correctness of the results. > > Good. It seems I have old version of the test. Did you run it with -Xcomp? How you verified that intrinsic is used? The tests were not run with -Xcomp. Looked at the generated x86 code using the disassembler (hsdis) and verified that that correct instruction (mul) instead of (imul, without the intrinsic) was being generated. ------------- PR: https://git.openjdk.java.net/jdk/pull/5933 From joe.darcy at oracle.com Fri Oct 15 23:19:30 2021 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Fri, 15 Oct 2021 16:19:30 -0700 Subject: SourceVersion::feature In-Reply-To: <6169ca08-39d7-36c5-5250-08a7091a5fd0@oracle.com> References: <8dda85be-e55e-7d0f-0a6f-5db40691fed1@gmail.com> <9bda1fa7-ff68-e0a5-0bbc-b9ef92847ad2@gmail.com> <6169ca08-39d7-36c5-5250-08a7091a5fd0@oracle.com> Message-ID: <40fe607e-aba2-79ec-3505-f12d33003a5e@oracle.com> PS See https://github.com/openjdk/jdk/pull/5973 -Joe On 10/14/2021 1:53 PM, Joseph D. Darcy wrote: > On 10/14/2021 10:23 AM, Michael Bien wrote: >> is this the right mailing list for javax.lang.model.* discussions? > > > The compiler-dev list would be appropriate as well, but core-libs will > work. > > First, I understand the desire for a method like this. One of the > potential issues is SourceVersion models language versions and while, > to date, there has been a simple linear progression, that is not > guaranteed to be case arbitrarily far into the future, even though it > is the most likely outcome. > > Since java.lang.Runtime.Version is in the platform now, I think this > request would be better satisfied via a > > ??? public static SourceVersion valueOf(Runtime.Version version) > > method on SourceVersion. That way the modeling of SourceVersion can > absorb any non-linearity in versioning and presumably provide > sufficient information for a? Runtime.Version -> SourceVersion mapping > to query. > > I've filed the RFE > > ??? JDK-8275308: Add valueOf(Runtime.Version) factory to SourceVersion > > Cheers, > > -Joe > > >> >> if yes: >> >> instead of adding >> ??? /** >> ???? * Returns the version as int representing the feature release. >> ???? * @see Runtime.Version#feature() >> ???? */ >> ??? public int feature() { >> ??????? return this.ordinal(); >> ??? } >> to SourceVersion. >> >> a note could be added to the doc that the ordinal can be used as >> feature version. Since this statement would apply to the past too, >> the note could be backported to all maintained JDKs. This comes with >> the usual downside of not being able to add enums for in-between >> versions in future. >> >> (doing both would be an option too of course) >> >> >> To not use the ordinal, client code has to go through some enum init >> rituals to be able to do version comparisons: >> >> ?? final static SOURCE_VERSION_RELEASE_18; >> ?? static { >> SourceVersion tmp18; >> ??????? try { >> ??????????? tmp18 = SourceVersion.valueOf("RELEASE_18"); >> ??????? } catch (IllegalArgumentException ex) { >> tmp18 = null; >> ??????? } >> ??????? SOURCE_VERSION_RELEASE_18 = tmp18; >> ??????? //... more versions >> ?? } >> just to be able to >> >> ??? if (SOURCE_VERSION_RELEASE_18 != null && >> version.compareTo(SOURCE_VERSION_RELEASE_18) >= 0) {} >> >> or >> >> ??? if >> (Integer.parseInt(version.name().substring(version.name().indexOf('_')+1)) >> >= 18) {} >> >> which is shorter but not a good solution either. >> >> what the client code actually wants is: >> >> ??? if (SourceVersion.latest().feature() >= 18) {} >> >> >> it was a wise decision for java.lang.Runtime.Version to not use enums :) >> >> best regards, >> michael >> >> >> >> On 09.10.21 20:58, Michael Bien wrote: >>> Hello, >>> >>> could javax.lang.model.SourceVersion receive a feature() method >>> returning the version as an int, analog to java.lang.Runtime.Version? >>> >>> if (SourceVersion.latest().feature() >= 18) {} >>> >>> is simpler than comparing enums which may or may not exist dependent >>> on the deployed java version and cleaner than ordinal() tricks. >>> >>> best regards, >>> >>> michael >>> From psandoz at openjdk.java.net Sat Oct 16 00:56:14 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Sat, 16 Oct 2021 00:56:14 GMT Subject: RFR: 8271515: Integration of JEP 417: Vector API (Third Incubator) [v3] In-Reply-To: <_QQ9ntdJJfzVcAGrbjev0ZM-xNfD4wNATphnXkb-Y00=.bbf46985-8776-4dda-ada5-b15ab50774aa@github.com> References: <_QQ9ntdJJfzVcAGrbjev0ZM-xNfD4wNATphnXkb-Y00=.bbf46985-8776-4dda-ada5-b15ab50774aa@github.com> Message-ID: > This PR improves the performance of vector operations that accept masks on architectures that support masking in hardware, specifically Intel AVX512 and ARM SVE. > > On architectures that do not support masking in hardware the same technique as before is applied to most operations, specifically composition using blend. > > Masked loads/stores are a special form of masked operation that require additional care to ensure out-of-bounds access throw exceptions. The range checking has not been fully optimized and will require further work. > > No API enhancements were required and only a few additional tests were needed. Paul Sandoz 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 JDK-8271515-vector-api - Apply patch from https://github.com/openjdk/panama-vector/pull/152 - Apply patch from https://github.com/openjdk/panama-vector/pull/142 - Apply patch from https://github.com/openjdk/panama-vector/pull/139 - Apply patch from https://github.com/openjdk/panama-vector/pull/151 - Add new files. - 8271515: Integration of JEP 417: Vector API (Third Incubator) ------------- Changes: https://git.openjdk.java.net/jdk/pull/5873/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5873&range=02 Stats: 21998 lines in 106 files changed: 16227 ins; 2077 del; 3694 mod Patch: https://git.openjdk.java.net/jdk/pull/5873.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5873/head:pull/5873 PR: https://git.openjdk.java.net/jdk/pull/5873 From amaembo at gmail.com Sat Oct 16 03:54:30 2021 From: amaembo at gmail.com (Tagir Valeev) Date: Sat, 16 Oct 2021 10:54:30 +0700 Subject: RFR: 8274412: Add a method to Stream API to consume and close the stream without using try-with-resources In-Reply-To: References: Message-ID: Hello! > I am not really sure we?ve gotten the right idiom here yet. I?d like to slow down a bit before making an API decision. > > What id suggest is capturing the proposed api and spec on list, and let?s let this sit and bake for a bit longer. My sense is that something better may well emerge if we do. I see, thanks for the discussion. Closing the PR for now. > > Sent from my MacBook Wheel > > > On Oct 9, 2021, at 5:41 AM, Tagir F.Valeev wrote: > > > > ?On Sun, 3 Oct 2021 11:00:25 GMT, Tagir F. Valeev wrote: > > > >> Currently, when the stream holds a resource, it's necessary to wrap it with try-with-resources. This undermines the compact and fluent style of stream API calls. For example, if we want to get the `List` of files inside the directory and timely close the underlying filehandle, we should use something like this: > >> > >> > >> List paths; > >> try (Stream stream = Files.list(Path.of("/etc"))) { > >> paths = stream.toList(); > >> } > >> // use paths > >> > >> > >> I suggest to add a new default method to Stream interface named `consumeAndClose`, which allows performing terminal stream operation and closing the stream at the same time. It may look like this: > >> > >> > >> default R consumeAndClose(Function, ? extends R> function) { > >> Objects.requireNonNull(function); > >> try(this) { > >> return function.apply(this); > >> } > >> } > >> > >> > >> Now, it will be possible to get the list of the files in the fluent manner: > >> > >> > >> List list = Files.list(Path.of("/etc")).consumeAndClose(Stream::toList); > > > > CSR is [posted](https://bugs.openjdk.java.net/browse/JDK-8274994), please review! > > > > ------------- > > > > PR: https://git.openjdk.java.net/jdk/pull/5796 From tvaleev at openjdk.java.net Sat Oct 16 03:59:52 2021 From: tvaleev at openjdk.java.net (Tagir F.Valeev) Date: Sat, 16 Oct 2021 03:59:52 GMT Subject: Withdrawn: 8274412: Add a method to Stream API to consume and close the stream without using try-with-resources In-Reply-To: References: Message-ID: On Sun, 3 Oct 2021 11:00:25 GMT, Tagir F. Valeev wrote: > Currently, when the stream holds a resource, it's necessary to wrap it with try-with-resources. This undermines the compact and fluent style of stream API calls. For example, if we want to get the `List` of files inside the directory and timely close the underlying filehandle, we should use something like this: > > > List paths; > try (Stream stream = Files.list(Path.of("/etc"))) { > paths = stream.toList(); > } > // use paths > > > I suggest to add a new default method to Stream interface named `consumeAndClose`, which allows performing terminal stream operation and closing the stream at the same time. It may look like this: > > > default R consumeAndClose(Function, ? extends R> function) { > Objects.requireNonNull(function); > try(this) { > return function.apply(this); > } > } > > > Now, it will be possible to get the list of the files in the fluent manner: > > > List list = Files.list(Path.of("/etc")).consumeAndClose(Stream::toList); This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/5796 From zjx001202 at gmail.com Sat Oct 16 04:25:40 2021 From: zjx001202 at gmail.com (Glavo) Date: Sat, 16 Oct 2021 12:25:40 +0800 Subject: RFR: 8274412: Add a method to Stream API to consume and close the stream without using try-with-resources In-Reply-To: References: Message-ID: I don't think it is a perfect solution to combine the close operation with the terminator operation, because there are similar issues in the intermediate operation. Consider this use case (for example only): try (var stream = Files.list(path) .flatMap(dir -> { try { return Files.list(dir); } catch (IOException e) { return Stream.empty(); } })) { // ... } It looks closed, but it doesn't. Closing the Stream generated by flatMap will not close all member Stream. Further consideration is needed to deal with the problem of closing the Stream. Perhaps it is a withCleaner method that registers the Stream with the cleaner, or other solutions. Tagir F.Valeev ?2021?10?4??? ??2:52??? > Currently, when the stream holds a resource, it's necessary to wrap it > with try-with-resources. This undermines the compact and fluent style of > stream API calls. For example, if we want to get the `List` of files inside > the directory and timely close the underlying filehandle, we should use > something like this: > > > List paths; > try (Stream stream = Files.list(Path.of("/etc"))) { > paths = stream.toList(); > } > // use paths > > > I suggest to add a new default method to Stream interface named > `consumeAndClose`, which allows performing terminal stream operation and > closing the stream at the same time. It may look like this: > > > default R consumeAndClose(Function, ? extends R> > function) { > Objects.requireNonNull(function); > try(this) { > return function.apply(this); > } > } > > > Now, it will be possible to get the list of the files in the fluent manner: > > > List list = > Files.list(Path.of("/etc")).consumeAndClose(Stream::toList); > > ------------- > > Commit messages: > - Fix tests > - 8274412: Add a method to Stream API to consume and close the stream > without using try-with-resources > > Changes: https://git.openjdk.java.net/jdk/pull/5796/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5796&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8274412 > Stats: 140 lines in 5 files changed: 135 ins; 0 del; 5 mod > Patch: https://git.openjdk.java.net/jdk/pull/5796.diff > Fetch: git fetch https://git.openjdk.java.net/jdk > pull/5796/head:pull/5796 > > PR: https://git.openjdk.java.net/jdk/pull/5796 > From forax at univ-mlv.fr Sat Oct 16 07:32:24 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 16 Oct 2021 09:32:24 +0200 (CEST) Subject: RFR: 8274412: Add a method to Stream API to consume and close the stream without using try-with-resources In-Reply-To: References: Message-ID: <1117666913.2809787.1634369544311.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "Glavo" > To: "Tagir F.Valeev" > Cc: "core-libs-dev" > Sent: Samedi 16 Octobre 2021 06:25:40 > Subject: Re: RFR: 8274412: Add a method to Stream API to consume and close the stream without using try-with-resources > I don't think it is a perfect solution to combine the close operation > with the terminator operation, because there are similar issues > in the intermediate operation. > > Consider this use case (for example only): > > try (var stream = Files.list(path) > .flatMap(dir -> { > try { > return Files.list(dir); > } catch (IOException e) { > return Stream.empty(); > } > })) { > // ... > } > > It looks closed, but it doesn't. Closing the Stream generated by flatMap > will not close all member Stream. The stream is closed, from the javadoc "Each mapped stream is closed after its contents have been placed into this stream." > Further consideration is needed to > deal with the problem of closing the Stream. Perhaps it is a withCleaner > method that registers the Stream with the cleaner, or other solutions. > > regards, R?mi > > > Tagir F.Valeev ?2021?10?4??? ??2:52??? > >> Currently, when the stream holds a resource, it's necessary to wrap it >> with try-with-resources. This undermines the compact and fluent style of >> stream API calls. For example, if we want to get the `List` of files inside >> the directory and timely close the underlying filehandle, we should use >> something like this: >> >> >> List paths; >> try (Stream stream = Files.list(Path.of("/etc"))) { >> paths = stream.toList(); >> } >> // use paths >> >> >> I suggest to add a new default method to Stream interface named >> `consumeAndClose`, which allows performing terminal stream operation and >> closing the stream at the same time. It may look like this: >> >> >> default R consumeAndClose(Function, ? extends R> >> function) { >> Objects.requireNonNull(function); >> try(this) { >> return function.apply(this); >> } >> } >> >> >> Now, it will be possible to get the list of the files in the fluent manner: >> >> >> List list = >> Files.list(Path.of("/etc")).consumeAndClose(Stream::toList); >> >> ------------- >> >> Commit messages: >> - Fix tests >> - 8274412: Add a method to Stream API to consume and close the stream >> without using try-with-resources >> >> Changes: https://git.openjdk.java.net/jdk/pull/5796/files >> Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5796&range=00 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8274412 >> Stats: 140 lines in 5 files changed: 135 ins; 0 del; 5 mod >> Patch: https://git.openjdk.java.net/jdk/pull/5796.diff >> Fetch: git fetch https://git.openjdk.java.net/jdk >> pull/5796/head:pull/5796 >> >> PR: https://git.openjdk.java.net/jdk/pull/5796 From zjx001202 at gmail.com Sat Oct 16 08:04:53 2021 From: zjx001202 at gmail.com (Glavo) Date: Sat, 16 Oct 2021 16:04:53 +0800 Subject: RFR: 8274412: Add a method to Stream API to consume and close the stream without using try-with-resources In-Reply-To: <1117666913.2809787.1634369544311.JavaMail.zimbra@u-pem.fr> References: <1117666913.2809787.1634369544311.JavaMail.zimbra@u-pem.fr> Message-ID: Oh, sorry, I found that I misunderstood the closing time. I tried it in the wrong way, so I came to the wrong conclusion. Thank you for your reminder. From msheppar at openjdk.java.net Sat Oct 16 10:51:48 2021 From: msheppar at openjdk.java.net (Mark Sheppard) Date: Sat, 16 Oct 2021 10:51:48 GMT Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v3] In-Reply-To: References: Message-ID: On Tue, 12 Oct 2021 15:43:24 GMT, Aleksei Efimov wrote: >> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver. >> >> The following API classes are added to `java.net.spi` package to facilitate this: >> - `InetAddressResolverProvider` - abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers. >> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations. >> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations. >> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation. >> >> More details in [JEP-418](https://openjdk.java.net/jeps/418). >> >> Testing: new and existing `tier1:tier3` tests > > Aleksei Efimov has updated the pull request incrementally with two additional commits since the last revision: > > - Add @since tags to new API classes > - Add checks and test for empty stream resolver results What?s in a name? I find the method names of the InetAddressResolver interface a bit ambiguous. Typically in this DNS problem space one speaks of lookup to resolve a hostname to its associated addresses and reverse lookup to resolve an IP address to a hostname (or names) associated with it. For the method names lookupHostname, and lookupAddresses, and the semantics conveyed in those names, I would expect lookupHostname to resolve a hostname, that is, take a hostname as parameter and the return value the addresses, while lookupAddresses I would expect to resolve an address to its hostname, that is, take an address and return a hostname. However, the current pair of methods names convey the opposite, lookupHostname resolves an address and lookupAddresses resolves a hostname. I would proffer a method name change to use lookup and reverseLookup OR to use resolvesHostname and resolveAddress, to resolve a hostname and address respectively. Thus, lookupHostname should be renamed to reverseLookup and lookupAddresses to lookup OR lookupHostname renamed to resolveAddress and lookupAddresses renamed to resolveHostname. ------------- PR: https://git.openjdk.java.net/jdk/pull/5822 From mcimadamore at openjdk.java.net Sat Oct 16 11:11:59 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Sat, 16 Oct 2021 11:11:59 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v6] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/419 Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision: - * use `invokeWithArguments` to simplify new test - Add test for liveness check with high-aririty downcalls (make sure that if an exception occurs in a downcall because of liveness, ref count of other resources are left intact). ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5907/files - new: https://git.openjdk.java.net/jdk/pull/5907/files/5ed94c30..a4db81fe Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=04-05 Stats: 39 lines in 2 files changed: 39 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5907.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5907/head:pull/5907 PR: https://git.openjdk.java.net/jdk/pull/5907 From mrjarviscraft at gmail.com Sat Oct 16 11:42:33 2021 From: mrjarviscraft at gmail.com (Japris Pogrammer) Date: Sat, 16 Oct 2021 14:42:33 +0300 Subject: AbstractProcessor overrides process(..) for no reason Message-ID: Hi there, I've seen that javax.annotation.processing.AbstractProcessor overrides `Processor#process(..)` method without any changes to it [1]: - it still is abstract - signature is untouched - javadoc is untouched Is this done intentionally or this redundant override can be eliminated? [1]: https://github.com/openjdk/jdk/blob/bfcf6a29a16bc12d77a897fbec304868957c3188/src/java.compiler/share/classes/javax/annotation/processing/AbstractProcessor.java#L167-L171 Thanks, Peter From msheppar at openjdk.java.net Sat Oct 16 12:33:52 2021 From: msheppar at openjdk.java.net (Mark Sheppard) Date: Sat, 16 Oct 2021 12:33:52 GMT Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v3] In-Reply-To: References: Message-ID: On Tue, 12 Oct 2021 15:43:24 GMT, Aleksei Efimov wrote: >> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver. >> >> The following API classes are added to `java.net.spi` package to facilitate this: >> - `InetAddressResolverProvider` - abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers. >> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations. >> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations. >> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation. >> >> More details in [JEP-418](https://openjdk.java.net/jeps/418). >> >> Testing: new and existing `tier1:tier3` tests > > Aleksei Efimov has updated the pull request incrementally with two additional commits since the last revision: > > - Add @since tags to new API classes > - Add checks and test for empty stream resolver results Refactor remove Configuration and simplify interface: In the InetAddressResolver a Configuration abstraction is defined, and this is supplied to a get method of the InetAddressResolverProvider. The objective is to ?inject? some platform configuration into an InetAddressResolver. This consistents of two pieces of platform configuration detail, a builtin resolver reference and the hostname. Why not provide them as parameters to the provider get method and dispense with the Configuration abstraction? Thus simplifying the interface. The hostname is being supplied by the getLocalHostName of an InetAddressImpl. This is essentially a wrapper to the library call gethostname. This could be provided as a static method in InetAddressImpl, called once during loadResolver to provide the hostname parameter String. The hostname is a static piece of system configuration, which requires a system restart if it were to be changed - so need to provide a lambda. So Suggestion is refector remove Configuration to simplify the interface and provide the BULITIN_RESOLVER and hostname as parameters to the InetAddressResolverProvider::get method ------------- PR: https://git.openjdk.java.net/jdk/pull/5822 From mgronlun at openjdk.java.net Sat Oct 16 15:24:52 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Sat, 16 Oct 2021 15:24:52 GMT Subject: RFR: 8266936: Add a finalization JFR event [v18] In-Reply-To: References: Message-ID: > Greetings, > > Object.finalize() was deprecated in JDK9. There is an ongoing effort to replace and mitigate Object.finalize() uses in the JDK libraries; please see https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. > > We also like to assist users in replacing and mitigating uses in non-JDK code. > > Hence, this changeset adds a periodic JFR event to help identify which classes are overriding Object.finalize(). > > Thanks > Markus Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: ThreadBlockInVM instead of ThreadToNativeFromVM for sampling exclusion ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4731/files - new: https://git.openjdk.java.net/jdk/pull/4731/files/9b418149..d10eb309 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=17 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=16-17 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4731.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4731/head:pull/4731 PR: https://git.openjdk.java.net/jdk/pull/4731 From mbien42 at gmail.com Sat Oct 16 16:22:29 2021 From: mbien42 at gmail.com (Michael Bien) Date: Sat, 16 Oct 2021 18:22:29 +0200 Subject: SourceVersion::feature In-Reply-To: <40fe607e-aba2-79ec-3505-f12d33003a5e@oracle.com> References: <8dda85be-e55e-7d0f-0a6f-5db40691fed1@gmail.com> <9bda1fa7-ff68-e0a5-0bbc-b9ef92847ad2@gmail.com> <6169ca08-39d7-36c5-5250-08a7091a5fd0@oracle.com> <40fe607e-aba2-79ec-3505-f12d33003a5e@oracle.com> Message-ID: thank you! I replied on the PR. -michael On 16.10.21 01:19, Joseph D. Darcy wrote: > PS See https://github.com/openjdk/jdk/pull/5973 > > -Joe > > On 10/14/2021 1:53 PM, Joseph D. Darcy wrote: >> On 10/14/2021 10:23 AM, Michael Bien wrote: >>> is this the right mailing list for javax.lang.model.* discussions? >> >> >> The compiler-dev list would be appropriate as well, but core-libs >> will work. >> >> First, I understand the desire for a method like this. One of the >> potential issues is SourceVersion models language versions and while, >> to date, there has been a simple linear progression, that is not >> guaranteed to be case arbitrarily far into the future, even though it >> is the most likely outcome. >> >> Since java.lang.Runtime.Version is in the platform now, I think this >> request would be better satisfied via a >> >> ??? public static SourceVersion valueOf(Runtime.Version version) >> >> method on SourceVersion. That way the modeling of SourceVersion can >> absorb any non-linearity in versioning and presumably provide >> sufficient information for a? Runtime.Version -> SourceVersion >> mapping to query. >> >> I've filed the RFE >> >> ??? JDK-8275308: Add valueOf(Runtime.Version) factory to SourceVersion >> >> Cheers, >> >> -Joe >> >> >>> >>> if yes: >>> >>> instead of adding >>> ??? /** >>> ???? * Returns the version as int representing the feature release. >>> ???? * @see Runtime.Version#feature() >>> ???? */ >>> ??? public int feature() { >>> ??????? return this.ordinal(); >>> ??? } >>> to SourceVersion. >>> >>> a note could be added to the doc that the ordinal can be used as >>> feature version. Since this statement would apply to the past too, >>> the note could be backported to all maintained JDKs. This comes with >>> the usual downside of not being able to add enums for in-between >>> versions in future. >>> >>> (doing both would be an option too of course) >>> >>> >>> To not use the ordinal, client code has to go through some enum init >>> rituals to be able to do version comparisons: >>> >>> ?? final static SOURCE_VERSION_RELEASE_18; >>> ?? static { >>> SourceVersion tmp18; >>> ??????? try { >>> ??????????? tmp18 = SourceVersion.valueOf("RELEASE_18"); >>> ??????? } catch (IllegalArgumentException ex) { >>> tmp18 = null; >>> ??????? } >>> ??????? SOURCE_VERSION_RELEASE_18 = tmp18; >>> ??????? //... more versions >>> ?? } >>> just to be able to >>> >>> ??? if (SOURCE_VERSION_RELEASE_18 != null && >>> version.compareTo(SOURCE_VERSION_RELEASE_18) >= 0) {} >>> >>> or >>> >>> ??? if >>> (Integer.parseInt(version.name().substring(version.name().indexOf('_')+1)) >>> >= 18) {} >>> >>> which is shorter but not a good solution either. >>> >>> what the client code actually wants is: >>> >>> ??? if (SourceVersion.latest().feature() >= 18) {} >>> >>> >>> it was a wise decision for java.lang.Runtime.Version to not use >>> enums :) >>> >>> best regards, >>> michael >>> >>> >>> >>> On 09.10.21 20:58, Michael Bien wrote: >>>> Hello, >>>> >>>> could javax.lang.model.SourceVersion receive a feature() method >>>> returning the version as an int, analog to java.lang.Runtime.Version? >>>> >>>> if (SourceVersion.latest().feature() >= 18) {} >>>> >>>> is simpler than comparing enums which may or may not exist >>>> dependent on the deployed java version and cleaner than ordinal() >>>> tricks. >>>> >>>> best regards, >>>> >>>> michael >>>> From mchung at openjdk.java.net Sat Oct 16 21:25:52 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Sat, 16 Oct 2021 21:25:52 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v13] In-Reply-To: References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> Message-ID: On Fri, 15 Oct 2021 15:09:23 GMT, Peter Levart wrote: >> It's not driven by performance data. It's part of Peter's contribution. I also prefer it without the packing. I propose to keep the parameter count as a separate field and examine it when there is footprint issue. > > The reason for this packing is (was) ORing the value with a non-zero value so that field never held zero value. When for example an individual value (say paramCount) is used in a separate @Stable field, its value set may include the default value (zero) which is then not optimized by JIT as a constant. This is from @Stable docs: > > * By extension, any variable (either array or field) which has annotated > * as stable is called a stable variable, and its non-null or non-zero > * value is called a stable value. > > ...and: > > * The HotSpot VM relies on this annotation to promote a non-null (resp., > * non-zero) component value to a constant, thereby enabling superior > * optimizations of code depending on such a value (such as constant folding). > * More specifically, the HotSpot VM will process non-null stable fields (final > * or otherwise) in a similar manner to static final fields with respect to > * promoting the field's value to a constant. Thus, placing aside the > * differences for null/non-null values and arrays, a final stable field is > * treated as if it is really final from both the Java language and the HotSpot > > So now that some of these fields are final and not annotated with @Stable any more but are treated as "trusted final" fields, the question is whether JIT is treating the default (zero, null) values differently or not. If they are treated as static final fields where default value makes no difference, then it's ok to split this multi-valued field into individual fields. The compiler team confirms that the zero value only matters for stable fields. For static/trusted non-static final fields, zero value is treated as a constant. ------------- PR: https://git.openjdk.java.net/jdk/pull/5027 From ecki at zusammenkunft.net Sun Oct 17 02:56:17 2021 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Sun, 17 Oct 2021 02:56:17 +0000 Subject: InnocuousThread names (was: [8u] RFR 8190482: InnocuousThread creation should not require the caller to possess enableContextClassLoaderOverride) In-Reply-To: References: <2B573F3A-49B4-48B5-B488-61748D216754@amazon.com> Message-ID: Apropos InnocousThread backporting - I Wonder if we should remove the auto threadname infrastructure and only create properly named threads. The generic name seems to be rather confusing and it seems it is only used in an NIO Pool, where a thread-name should be set, anyway? https://github.com/openjdk/jdk/blob/6765f902505fbdd02f25b599f942437cd805cad1/src/java.base/share/classes/sun/nio/ch/ThreadPool.java#L86 Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: jdk8u-dev im Auftrag von Zhengyu Gu Gesendet: Sunday, October 17, 2021 1:39:12 AM An: Hohensee, Paul ; jdk8u-dev Betreff: Re: [8u] RFR 8190482: InnocuousThread creation should not require the caller to possess enableContextClassLoaderOverride Thanks, Paul -Zhengyu On 10/15/21 17:30, Hohensee, Paul wrote: > Lgtm. > > Thanks, > Paul > > ?-----Original Message----- > From: jdk8u-dev on behalf of Zhengyu Gu > Date: Tuesday, October 5, 2021 at 8:12 AM > To: jdk8u-dev > Subject: [8u] RFR 8190482: InnocuousThread creation should not require the caller to possess enableContextClassLoaderOverride > > This backport is for parity with Oracle 8u321. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8190482 > Webrev: http://hg.openjdk.java.net/jdk/jdk/rev/5e7cf99b1303 > > The original patch does not apply cleanly. There is not newThread(String > name, Runnable target) method in 8u, so discard this part of change. > > > 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8190482-8u/webrev.00/ > > > Thanks, > > -Zhengyu > > From ecki at zusammenkunft.net Sun Oct 17 03:24:17 2021 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Sun, 17 Oct 2021 03:24:17 +0000 Subject: (ch) InnocuousThread names In-Reply-To: References: <2B573F3A-49B4-48B5-B488-61748D216754@amazon.com> Message-ID: Looking at the code some more I wonder: * if defaultThreadFactoty should use a Thread group for the pool or at least for NIO? * If it can skip the security manager check and use InnocousThread in all cases (to avoid ThreadLocals - not sure if some encode cache is hurt by it?) * If it can skip the priveledged call as IThread does that itself. https://github.com/openjdk/jdk/blob/6765f902505fbdd02f25b599f942437cd805cad1/src/java.base/share/classes/sun/nio/ch/ThreadPool.java#L76 -- http://bernd.eckenfels.net ________________________________ Von: Bernd Eckenfels Gesendet: Sunday, October 17, 2021 4:56:17 AM An: OpenJDK Dev list ; nio-dev at openjdk.java.net Betreff: InnocuousThread names (was: [8u] RFR 8190482: InnocuousThread creation should not require the caller to possess enableContextClassLoaderOverride) Apropos InnocousThread backporting - I Wonder if we should remove the auto threadname infrastructure and only create properly named threads. The generic name seems to be rather confusing and it seems it is only used in an NIO Pool, where a thread-name should be set, anyway? https://github.com/openjdk/jdk/blob/6765f902505fbdd02f25b599f942437cd805cad1/src/java.base/share/classes/sun/nio/ch/ThreadPool.java#L86 Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: jdk8u-dev im Auftrag von Zhengyu Gu Gesendet: Sunday, October 17, 2021 1:39:12 AM An: Hohensee, Paul ; jdk8u-dev Betreff: Re: [8u] RFR 8190482: InnocuousThread creation should not require the caller to possess enableContextClassLoaderOverride Thanks, Paul -Zhengyu On 10/15/21 17:30, Hohensee, Paul wrote: > Lgtm. > > Thanks, > Paul > > ?-----Original Message----- > From: jdk8u-dev on behalf of Zhengyu Gu > Date: Tuesday, October 5, 2021 at 8:12 AM > To: jdk8u-dev > Subject: [8u] RFR 8190482: InnocuousThread creation should not require the caller to possess enableContextClassLoaderOverride > > This backport is for parity with Oracle 8u321. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8190482 > Webrev: http://hg.openjdk.java.net/jdk/jdk/rev/5e7cf99b1303 > > The original patch does not apply cleanly. There is not newThread(String > name, Runnable target) method in 8u, so discard this part of change. > > > 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8190482-8u/webrev.00/ > > > Thanks, > > -Zhengyu > > From aefimov at openjdk.java.net Sun Oct 17 15:58:54 2021 From: aefimov at openjdk.java.net (Aleksei Efimov) Date: Sun, 17 Oct 2021 15:58:54 GMT Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v3] In-Reply-To: References: Message-ID: On Sat, 16 Oct 2021 12:30:44 GMT, Mark Sheppard wrote: > So Suggestion is refector remove Configuration to simplify the interface and provide the BULITIN_RESOLVER and hostname as parameters to the InetAddressResolverProvider::get method During work on this JEP we've examined the approach suggested above, and there are few issues with it: - `InetAddressResolverProvider.Configuration` interface API might evolve, e.g. there might be a need to pass additional configuration items. - local hostname is a dynamic information, therefore it cannot be passed as string parameter to `InetAddressResolverProvider::get`. It's been also discussed in the CSR comments [here](https://bugs.openjdk.java.net/browse/JDK-8274558) ------------- PR: https://git.openjdk.java.net/jdk/pull/5822 From aefimov at openjdk.java.net Sun Oct 17 16:36:51 2021 From: aefimov at openjdk.java.net (Aleksei Efimov) Date: Sun, 17 Oct 2021 16:36:51 GMT Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v3] In-Reply-To: References: Message-ID: <0Xvj7H_JyjEfXTUr1GI3ooLL1cGBuWLDAtrP83WuQV0=.7e172d30-620d-4ce1-9bac-62db6dc19e52@github.com> On Sat, 16 Oct 2021 10:48:32 GMT, Mark Sheppard wrote: > What?s in a name? I find the method names of the InetAddressResolver interface a bit ambiguous. Typically in this DNS problem space one speaks of lookup to resolve a hostname to its associated addresses and reverse lookup to resolve an IP address to a hostname (or names) associated with it. I'm not sure that I see an ambiguity here: Interface has two methods, both are for lookup operations. That is why `lookup` word is used in both names. Then we put a description of a returned result after operation name: `Addresses` and `HostName` are the results. In cases when we want to highlight a parameter type in a method name we can use ?by?/?with? prepositions: for instance, `InetAddress.getByName` `InetAddress.getByAddress` `ScheduledExecutorService.scheduleWithFixedDelay`. We can try and apply this approach to the description of DNS operations above: > lookup to resolve a hostname to its associated addresses operation: `lookup` result: `addresses` -> methodName: `lookupAddresses` > reverse lookup to resolve an IP address to a hostname operation: `lookup` (we've dropped reverse word here) result: `hostname` -> methodName: `lookupHostName` ------------- PR: https://git.openjdk.java.net/jdk/pull/5822 From Alan.Bateman at oracle.com Sun Oct 17 18:28:25 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 17 Oct 2021 19:28:25 +0100 Subject: (ch) InnocuousThread names In-Reply-To: References: <2B573F3A-49B4-48B5-B488-61748D216754@amazon.com> Message-ID: <3f70ecd4-a05e-1ec6-1266-c2dd0940d767@oracle.com> On 17/10/2021 04:24, Bernd Eckenfels wrote: > Looking at the code some more I wonder: > > * ?if defaultThreadFactoty should use a Thread group for the pool or > at least for NIO? > * If it can skip the security manager check and use InnocousThread > in all cases (to avoid ThreadLocals - not sure if some encode > cache is hurt by it?) > > * If it can skip the priveledged call as IThread does that itself. > Changing it to use InnocousThread unconditionally would likely change the performance profile as TLs would be cleared so I don't think we should change that. The SM is terminally deprecated and there will be cleaned required right across the JDK once it is eventually removed, it is possible that many usages of InnocousThread will no longer be needed. You may be right that it no longer needs the doPriv to create the InnocousThread, it looks like the code changed but some of the use-sites were not updated. -Alan From alanb at openjdk.java.net Sun Oct 17 18:35:57 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 17 Oct 2021 18:35:57 GMT Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v3] In-Reply-To: References: Message-ID: On Sun, 17 Oct 2021 15:55:59 GMT, Aleksei Efimov wrote: > * `InetAddressResolverProvider.Configuration` interface API might evolve, e.g. there might be a need to pass additional configuration items. > * local hostname is a dynamic information, therefore it cannot be passed as string parameter to `InetAddressResolverProvider::get`. Right, I think we've ended up with a good model here that supports the common case, stacking, and can be extended in the future to add new configuration if required. Also if good use-cases come up when Configuration can be changed to be non-sealed. ------------- PR: https://git.openjdk.java.net/jdk/pull/5822 From joe.darcy at oracle.com Sun Oct 17 18:47:11 2021 From: joe.darcy at oracle.com (Joe Darcy) Date: Sun, 17 Oct 2021 11:47:11 -0700 Subject: AbstractProcessor overrides process(..) for no reason In-Reply-To: References: Message-ID: Hello, I think the occurrence of the placeholder for process? method in AbstractProcessor is innocuous. It doesn't result an a javadoc entry with the configuration options for the JDK doc build. While looking at the class, I noticed some place where @Override could be used: ?? https://github.com/openjdk/jdk/pull/5979 Thanks, -Joe On 10/16/2021 4:42 AM, Japris Pogrammer wrote: > Hi there, I've seen that javax.annotation.processing.AbstractProcessor > overrides `Processor#process(..)` method without any changes to it [1]: > - it still is abstract > - signature is untouched > - javadoc is untouched > Is this done intentionally or this redundant override can be eliminated? > > [1]: > https://github.com/openjdk/jdk/blob/bfcf6a29a16bc12d77a897fbec304868957c3188/src/java.compiler/share/classes/javax/annotation/processing/AbstractProcessor.java#L167-L171 > > > Thanks, > Peter From msheppar at openjdk.java.net Sun Oct 17 21:06:51 2021 From: msheppar at openjdk.java.net (Mark Sheppard) Date: Sun, 17 Oct 2021 21:06:51 GMT Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v3] In-Reply-To: <0Xvj7H_JyjEfXTUr1GI3ooLL1cGBuWLDAtrP83WuQV0=.7e172d30-620d-4ce1-9bac-62db6dc19e52@github.com> References: <0Xvj7H_JyjEfXTUr1GI3ooLL1cGBuWLDAtrP83WuQV0=.7e172d30-620d-4ce1-9bac-62db6dc19e52@github.com> Message-ID: On Sun, 17 Oct 2021 16:33:57 GMT, Aleksei Efimov wrote: > > What?s in a name? I find the method names of the InetAddressResolver interface a bit ambiguous. Typically in this DNS problem space one speaks of lookup to resolve a hostname to its associated addresses and reverse lookup to resolve an IP address to a hostname (or names) associated with it. > > I'm not sure that I see an ambiguity here: Interface has two methods, both are for lookup operations. That is why `lookup` word is used in both names. Then we put a description of a returned result after operation name: `Addresses` and `HostName` are the results. In cases when we want to highlight a parameter type in a method name we can use ?by?/?with? prepositions: for instance, `InetAddress.getByName` `InetAddress.getByAddress` `ScheduledExecutorService.scheduleWithFixedDelay`. > > We can try and apply this approach to the description of DNS operations above: > > > lookup to resolve a hostname to its associated addresses > > operation: `lookup` result: `addresses` -> methodName: `lookupAddresses` > > > reverse lookup to resolve an IP address to a hostname > > operation: `lookup` (we've dropped reverse word here) result: `hostname` -> methodName: `lookupHostName` Yes, ambiguity wasn?t quite the word I was looking for. Maybe contradictory or oxymoron might do !! Let me try and clarify the rational behind the suggestion. To re-iterate, the parlance of the DNS domain in context of address resolution is lookup for hostname to IP address resolution and reverse lookup for address to hostname mapping. For me, the natural verb to method translation is lookup and **reverseLookup OR resolveHostname and resolveAddress. The latter names are pretty definitive and unambiguous. It clear and obvious without the need to pursue the full signature of the method, what the semantics of the methods should be. At the java InetAddress API level there is getByName(String host) and getByAddress(byte[] addr). At the native OS level there is gethostbyname, gethostbyaddr and the evolved api getnameinfo and getaddrinfo. getByName requires a hostname lookup and getByAdress requires (eventually - I know the docs says there?s no reverse lookup) an address reverse lookup. Thus, a logical mapping is getByName ?> lookupHostname, and getByAddr ?> lookupAddress, but the opposite will occur getByName --> lookupAddresses and getByAddress --> lookupHostname. Therfore I proffer maps neatly to rename methods to resolveHostname and resolveAddress such that the mapping are getByName --> resolveHostname and getByAddress --> resolveAddress. I will concede that it can be reasonable argued that the native library functions getnameinfo and getaddrinfo may better abstract to lookupHostname and lookupAddresses respectively. But, I have always found these two library calls a bit contorted and the legacy gethostbyname and gethostbyaddress were more logical. In you proposition above: > operation: `lookup` result: `addresses` -> methodName: `lookupAddresses` > operation: `lookup` (we've dropped reverse word here) result: `hostname` -> methodName: `lookupHostName` You are generating the name from the result of the action. I?m arguing that it should be based on the operation on the subject i.e. the parameter being passed. If this was hashmap lookup, then it is an operation of mapping hostname to addresses mapHostnameToAddresses, i.e. looking up a hostname, and mapping an address to a hostname mapAddressToHostname i.e. looking up an address. Of course, it is possible to just **overload** a lookup method, one taking Sting and t?other taking byte adder in the method?s parameters, respectively. Then, you don?t have to concede too much in this argument. But, for me as an ordinary developer, resolveAddress and resolveHostname are crystal clear and unambiguous. ------------- PR: https://git.openjdk.java.net/jdk/pull/5822 From msheppar at openjdk.java.net Sun Oct 17 21:41:49 2021 From: msheppar at openjdk.java.net (Mark Sheppard) Date: Sun, 17 Oct 2021 21:41:49 GMT Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v3] In-Reply-To: References: Message-ID: <-8BcYWYlwGxmsmAY7JBT2h_Ahae3fONnwgGJxfedrJY=.8826d18f-4e00-496e-b06c-96d44e0eeb6c@github.com> On Sun, 17 Oct 2021 15:55:59 GMT, Aleksei Efimov wrote: > > So Suggestion is refector remove Configuration to simplify the interface and provide the BULITIN_RESOLVER and hostname as parameters to the InetAddressResolverProvider::get method > > During work on this JEP we've examined the approach suggested above, and there are few issues with it: > > * `InetAddressResolverProvider.Configuration` interface API might evolve, e.g. there might be a need to pass additional configuration items. > > * local hostname is a dynamic information, therefore it cannot be passed as string parameter to `InetAddressResolverProvider::get`. > > > It's been also discussed in the CSR comments [here](https://bugs.openjdk.java.net/browse/JDK-8274558) OK grand ... I didn't see the CSR discussion :-( WRT hostname being dynamic and requires a lambda ... is it really dynamic? I know it can be changed, but IIRC most (unix and windows) if not all systems require a restart for such a change change to take effect, and usually requires a dns cache flush also, in which case an application will be restarting also. In the case of working over VPN, VPN software usually changes the hostname dynamically, but that name change is only valid for the duration of the VPN session, and when you exit the VPN, it reverts back to the original hostname. In such cases an application will need to be restarted. There's no seemless working from VPN to non VPN. I think that a hostname is constant while a host is up, but it can be changed, and when changed a host restart is required. I don't think it is quite as dynamic as has been suggested, but I open to correction. It is something that can be investigated. ------------- PR: https://git.openjdk.java.net/jdk/pull/5822 From duke at openjdk.java.net Mon Oct 18 07:40:01 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Mon, 18 Oct 2021 07:40:01 GMT Subject: RFR: 8275386: Change nested classes in jdk.jlink to static nested classes Message-ID: Non-static classes hold a link to their parent classes, which can be avoided. ------------- Commit messages: - [PATCH] Change nested classes in jdk.jlink to static nested classes Changes: https://git.openjdk.java.net/jdk/pull/5983/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5983&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275386 Stats: 6 lines in 3 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/5983.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5983/head:pull/5983 PR: https://git.openjdk.java.net/jdk/pull/5983 From mgronlun at openjdk.java.net Mon Oct 18 08:29:46 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 18 Oct 2021 08:29:46 GMT Subject: RFR: 8266936: Add a finalization JFR event [v19] In-Reply-To: References: Message-ID: > Greetings, > > Object.finalize() was deprecated in JDK9. There is an ongoing effort to replace and mitigate Object.finalize() uses in the JDK libraries; please see https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. > > We also like to assist users in replacing and mitigating uses in non-JDK code. > > Hence, this changeset adds a periodic JFR event to help identify which classes are overriding Object.finalize(). > > Thanks > Markus Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: relax memory ordering constraint ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4731/files - new: https://git.openjdk.java.net/jdk/pull/4731/files/d10eb309..85a46263 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=18 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=17-18 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/4731.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4731/head:pull/4731 PR: https://git.openjdk.java.net/jdk/pull/4731 From myano at openjdk.java.net Mon Oct 18 09:57:53 2021 From: myano at openjdk.java.net (Masanori Yano) Date: Mon, 18 Oct 2021 09:57:53 GMT Subject: RFR: 8233674: JarURLConnection.getJarFile throws Exception if some process is holding the file In-Reply-To: References: Message-ID: On Mon, 27 Sep 2021 08:04:23 GMT, Alan Bateman wrote: >> It?s a good idea to ask the Microsoft folks about that, but I don't know the way to ask. Could you tell me how to do it? >> >> As you say, CreateFile function is used in other parts of the JDK, but it have a significant impact to fix all of that. Therefore, I fixed the problem about opening zip files and jar files which is reported in the JBS. > >> It?s a good idea to ask the Microsoft folks about that, but I don't know the way to ask. Could you tell me how to do it? >> >> As you say, CreateFile function is used in other parts of the JDK, but it have a significant impact to fix all of that. Therefore, I fixed the problem about opening zip files and jar files which is reported in the JBS. > > I think we need to find out if the issue you are working around is a bug/issue with the virus checker or that Microsoft recommends that all applications should put a retry to work around these issues. As regards the patch then it is incomplete. If we are forced to put a workaround into the JDK code then I think it will have to do everywhere, not just for zip/JAR files. @AlanBateman Could you reply to the above comment? ------------- PR: https://git.openjdk.java.net/jdk/pull/5460 From myano at openjdk.java.net Mon Oct 18 10:14:54 2021 From: myano at openjdk.java.net (Masanori Yano) Date: Mon, 18 Oct 2021 10:14:54 GMT Subject: RFR: 8250678: ModuleDescriptor.Version parsing treats empty segments inconsistently In-Reply-To: References: <5FwhmsS85upnfXAKPCBCQTsWorJN17vOBFZXCN6iP8M=.377740a1-6f1e-4e37-9344-25a60ffdd891@github.com> Message-ID: On Wed, 6 Oct 2021 18:40:36 GMT, Mark Reinhold wrote: >> @mbreinhold Could you comment on this pull request? > >> @mbreinhold Could you comment on this pull request? > > This is somewhat tricky code. I?ll take a look, but give me a few days. @mbreinhold (@AlanBateman ) Could you tell me how many more days do you need for your confirmation? ------------- PR: https://git.openjdk.java.net/jdk/pull/5679 From alanb at openjdk.java.net Mon Oct 18 10:24:59 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 18 Oct 2021 10:24:59 GMT Subject: RFR: 8233674: JarURLConnection.getJarFile throws Exception if some process is holding the file In-Reply-To: References: Message-ID: On Mon, 27 Sep 2021 08:04:23 GMT, Alan Bateman wrote: >> It?s a good idea to ask the Microsoft folks about that, but I don't know the way to ask. Could you tell me how to do it? >> >> As you say, CreateFile function is used in other parts of the JDK, but it have a significant impact to fix all of that. Therefore, I fixed the problem about opening zip files and jar files which is reported in the JBS. > >> It?s a good idea to ask the Microsoft folks about that, but I don't know the way to ask. Could you tell me how to do it? >> >> As you say, CreateFile function is used in other parts of the JDK, but it have a significant impact to fix all of that. Therefore, I fixed the problem about opening zip files and jar files which is reported in the JBS. > > I think we need to find out if the issue you are working around is a bug/issue with the virus checker or that Microsoft recommends that all applications should put a retry to work around these issues. As regards the patch then it is incomplete. If we are forced to put a workaround into the JDK code then I think it will have to do everywhere, not just for zip/JAR files. > @AlanBateman Could you reply to the above comment? I view this issue as something for the anti-virus vendor to fix. It would be very disappointing to force the JDK to put in a workaround for this. A workaround would be very intrusive and require changes in many areas of the JDK. ------------- PR: https://git.openjdk.java.net/jdk/pull/5460 From michaelm at openjdk.java.net Mon Oct 18 11:43:52 2021 From: michaelm at openjdk.java.net (Michael McMahon) Date: Mon, 18 Oct 2021 11:43:52 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v9] In-Reply-To: References: Message-ID: On Tue, 12 Oct 2021 10:40:15 GMT, Julia Boes wrote: >> This change implements a simple web server that can be run on the command-line with `java -m jdk.httpserver`. >> >> This is facilitated by adding an entry point for the `jdk.httpserver` module, an implementation class whose main method is run when the above command is executed. This is the first such module entry point in the JDK. >> >> The server is a minimal HTTP server that serves the static files of a given directory, similar to existing alternatives on other platforms and convenient for testing, development, and debugging. >> >> Additionally, a small API is introduced for programmatic creation and customization. >> >> Testing: tier1-3. > > Julia Boes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits: > > - Minor rewording of bind address output > - Merge branch 'master' into simpleserver > - Merge branch 'master' into simpleserver > - update output for all interfaces > - use ipv4/ipv6 specific loopback address and add add how-to output for all interfaces > - Merge branch 'master' into simpleserver > - change default bind address from anylocal to loopback > - address PR comments > - Merge branch 'master' into simpleserver > - Merge remote-tracking branch 'origin/simpleserver' into simpleserver > - ... and 14 more: https://git.openjdk.java.net/jdk/compare/b1b66965...e86609d0 test/jdk/com/sun/net/httpserver/simpleserver/ServerMimeTypesResolutionTest.java line 200: > 198: */ > 199: // @Test(dataProvider = "commonExtensions") > 200: public static void testCommonExtensions(String extension) { Is this test and the one below supposed to be commented out? ------------- PR: https://git.openjdk.java.net/jdk/pull/5505 From jboes at openjdk.java.net Mon Oct 18 12:21:59 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Mon, 18 Oct 2021 12:21:59 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v9] In-Reply-To: References: Message-ID: On Mon, 18 Oct 2021 11:38:22 GMT, Michael McMahon wrote: >> Julia Boes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits: >> >> - Minor rewording of bind address output >> - Merge branch 'master' into simpleserver >> - Merge branch 'master' into simpleserver >> - update output for all interfaces >> - use ipv4/ipv6 specific loopback address and add add how-to output for all interfaces >> - Merge branch 'master' into simpleserver >> - change default bind address from anylocal to loopback >> - address PR comments >> - Merge branch 'master' into simpleserver >> - Merge remote-tracking branch 'origin/simpleserver' into simpleserver >> - ... and 14 more: https://git.openjdk.java.net/jdk/compare/b1b66965...e86609d0 > > test/jdk/com/sun/net/httpserver/simpleserver/ServerMimeTypesResolutionTest.java line 200: > >> 198: */ >> 199: // @Test(dataProvider = "commonExtensions") >> 200: public static void testCommonExtensions(String extension) { > > Is this test and the one below supposed to be commented out? Yes, `testCommonExtensions` is a manual test to find common mime types that are currently not supported, `printUnsupportedFileExtensions` prints the list of types found. ------------- PR: https://git.openjdk.java.net/jdk/pull/5505 From herrick at openjdk.java.net Mon Oct 18 13:31:58 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Mon, 18 Oct 2021 13:31:58 GMT Subject: Integrated: 8274346: Support for additional content in an app-image. In-Reply-To: References: Message-ID: On Thu, 30 Sep 2021 18:51:49 GMT, Andy Herrick wrote: > 8274346: Support for additional content in an app-image. This pull request has now been integrated. Changeset: d548f2fc Author: Andy Herrick URL: https://git.openjdk.java.net/jdk/commit/d548f2fc0dbc9e7864dd1701873bbf3d12a75ecb Stats: 167 lines in 10 files changed: 157 ins; 0 del; 10 mod 8274346: Support for additional content in an app-image. Reviewed-by: asemenyuk, almatvee ------------- PR: https://git.openjdk.java.net/jdk/pull/5780 From jpai at openjdk.java.net Mon Oct 18 13:54:11 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Mon, 18 Oct 2021 13:54:11 GMT Subject: RFR: 8269336: Malformed jdk.serialFilter incorrectly handled Message-ID: Can I please get a review for this change which addresses https://bugs.openjdk.java.net/browse/JDK-8269336? As noted in that issue, this change will now propagate any exception that occurred during parsing and creation of the filter configured through the `jdk.serialFilter` system property. It will also continue to log those errors, like it previously did. A new jtreg test has been introduced to reproduce this issue and verify the fix. Given that invalid values for this system property will now start throwing exception, will this change need a CSR? ------------- Commit messages: - 8269336: Malformed jdk.serialFilter incorrectly handled Changes: https://git.openjdk.java.net/jdk/pull/5988/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5988&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269336 Stats: 90 lines in 2 files changed: 89 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5988.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5988/head:pull/5988 PR: https://git.openjdk.java.net/jdk/pull/5988 From michaelm at openjdk.java.net Mon Oct 18 13:58:55 2021 From: michaelm at openjdk.java.net (Michael McMahon) Date: Mon, 18 Oct 2021 13:58:55 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v9] In-Reply-To: References: Message-ID: <2Fk3re4SLz7A9vMEvJItkQfB7BCLhzAuQRoD5KXfUoc=.66a62f2d-36e0-4d53-bbb0-cca2f9cd110e@github.com> On Tue, 12 Oct 2021 10:40:15 GMT, Julia Boes wrote: >> This change implements a simple web server that can be run on the command-line with `java -m jdk.httpserver`. >> >> This is facilitated by adding an entry point for the `jdk.httpserver` module, an implementation class whose main method is run when the above command is executed. This is the first such module entry point in the JDK. >> >> The server is a minimal HTTP server that serves the static files of a given directory, similar to existing alternatives on other platforms and convenient for testing, development, and debugging. >> >> Additionally, a small API is introduced for programmatic creation and customization. >> >> Testing: tier1-3. > > Julia Boes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits: > > - Minor rewording of bind address output > - Merge branch 'master' into simpleserver > - Merge branch 'master' into simpleserver > - update output for all interfaces > - use ipv4/ipv6 specific loopback address and add add how-to output for all interfaces > - Merge branch 'master' into simpleserver > - change default bind address from anylocal to loopback > - address PR comments > - Merge branch 'master' into simpleserver > - Merge remote-tracking branch 'origin/simpleserver' into simpleserver > - ... and 14 more: https://git.openjdk.java.net/jdk/compare/b1b66965...e86609d0 Marked as reviewed by michaelm (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5505 From mchung at openjdk.java.net Mon Oct 18 16:10:21 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 18 Oct 2021 16:10:21 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v14] In-Reply-To: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> Message-ID: > This reimplements core reflection with method handles. > > For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. > > The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. > > The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. > > Ran tier1-tier8 tests. > > [1] https://bugs.openjdk.java.net/browse/JDK-8013527 > [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: Separate paramFlgas into paramCount and flags fields ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5027/files - new: https://git.openjdk.java.net/jdk/pull/5027/files/c25d651a..c1bb48fe Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5027&range=13 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5027&range=12-13 Stats: 36 lines in 2 files changed: 9 ins; 13 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/5027.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5027/head:pull/5027 PR: https://git.openjdk.java.net/jdk/pull/5027 From egahlin at openjdk.java.net Mon Oct 18 16:27:55 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Mon, 18 Oct 2021 16:27:55 GMT Subject: RFR: 8266936: Add a finalization JFR event [v10] In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 15:23:35 GMT, Markus Gr?nlund wrote: >> Greetings, >> >> Object.finalize() was deprecated in JDK9. There is an ongoing effort to replace and mitigate Object.finalize() uses in the JDK libraries; please see https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. >> >> We also like to assist users in replacing and mitigating uses in non-JDK code. >> >> Hence, this changeset adds a periodic JFR event to help identify which classes are overriding Object.finalize(). >> >> Thanks >> Markus > > Markus Gr?nlund has updated the pull request incrementally with three additional commits since the last revision: > > - localize > - cleanup > - FinalizerStatistics Marked as reviewed by egahlin (Reviewer). src/java.base/share/classes/java/lang/ref/Finalizer.java line 71: > 69: } > 70: > 71: extraneous whitespace? test/jdk/jdk/jfr/event/runtime/TestFinalizerStatisticsEvent.java line 98: > 96: case TEST_CLASS_NAME: { > 97: Asserts.assertTrue(event.getString("codeSource").startsWith("file://")); > 98: foundTestClassName = true; Could we (sanity) check "objects" and "totalFinalzersRun" fields as well? ------------- PR: https://git.openjdk.java.net/jdk/pull/4731 From mgronlun at openjdk.java.net Mon Oct 18 16:38:50 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 18 Oct 2021 16:38:50 GMT Subject: RFR: 8266936: Add a finalization JFR event [v10] In-Reply-To: References: Message-ID: On Tue, 31 Aug 2021 08:42:58 GMT, Erik Gahlin wrote: >> Markus Gr?nlund has updated the pull request incrementally with three additional commits since the last revision: >> >> - localize >> - cleanup >> - FinalizerStatistics > > test/jdk/jdk/jfr/event/runtime/TestFinalizerStatisticsEvent.java line 98: > >> 96: case TEST_CLASS_NAME: { >> 97: Asserts.assertTrue(event.getString("codeSource").startsWith("file://")); >> 98: foundTestClassName = true; > > Could we (sanity) check "objects" and "totalFinalzersRun" fields as well? It's risky to do because of the non-deterministic nature of when the Finalizer thread runs (if at all). The best I could think of is to check if either field is 0 or more, but that becomes so weak it's not much of a sanity check. ------------- PR: https://git.openjdk.java.net/jdk/pull/4731 From mgronlun at openjdk.java.net Mon Oct 18 16:51:53 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 18 Oct 2021 16:51:53 GMT Subject: RFR: 8266936: Add a finalization JFR event [v20] In-Reply-To: References: Message-ID: > Greetings, > > Object.finalize() was deprecated in JDK9. There is an ongoing effort to replace and mitigate Object.finalize() uses in the JDK libraries; please see https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. > > We also like to assist users in replacing and mitigating uses in non-JDK code. > > Hence, this changeset adds a periodic JFR event to help identify which classes are overriding Object.finalize(). > > Thanks > Markus Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: no constexpr for constant values ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4731/files - new: https://git.openjdk.java.net/jdk/pull/4731/files/85a46263..b3268c90 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=19 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=18-19 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4731.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4731/head:pull/4731 PR: https://git.openjdk.java.net/jdk/pull/4731 From mgronlun at openjdk.java.net Mon Oct 18 16:51:54 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 18 Oct 2021 16:51:54 GMT Subject: RFR: 8266936: Add a finalization JFR event [v12] In-Reply-To: References: <7qUo6JdWeitC5Tw90sAEdokNLL1B0cp7nU8pBRLFoOc=.9d912b5c-41f6-42cd-a393-85f46daad623@github.com> Message-ID: <_fUcg-t8JOZ8qDTmngQnSHCnofBQLQIbClMfd0V92i0=.67daf704-61cc-4b14-8a54-dd41da28482c@github.com> On Fri, 24 Sep 2021 22:31:18 GMT, Mandy Chung wrote: >> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: >> >> no precompiled headers and mtServiceability nmt classification > > Hi Markus, > > It's a little surprised to see Finalizer.c to depend JMM interface which is used by `java.management` and `jdk.management` modules only. It's more appropriate for it to be a JVM_* entry point for Finalizer to report completion of the finalization instead. I understand that you want to make FinalizerService to be a conditional feature which is a good idea. Such JVM entry can be made as a nop if not INCLUDE_SERVICES. Thank you for staying around with this protracted PR. Thanks @mlchung , @coleenp and @egahlin for your reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/4731 From mgronlun at openjdk.java.net Mon Oct 18 16:51:55 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 18 Oct 2021 16:51:55 GMT Subject: RFR: 8266936: Add a finalization JFR event [v10] In-Reply-To: References: Message-ID: On Tue, 31 Aug 2021 08:45:54 GMT, Erik Gahlin wrote: >> Markus Gr?nlund has updated the pull request incrementally with three additional commits since the last revision: >> >> - localize >> - cleanup >> - FinalizerStatistics > > src/java.base/share/classes/java/lang/ref/Finalizer.java line 71: > >> 69: } >> 70: >> 71: > > extraneous whitespace? I think this version is outdated, and the extra whitespace was removed in later versions. ------------- PR: https://git.openjdk.java.net/jdk/pull/4731 From mgronlun at openjdk.java.net Mon Oct 18 16:55:56 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 18 Oct 2021 16:55:56 GMT Subject: Integrated: 8266936: Add a finalization JFR event In-Reply-To: References: Message-ID: On Thu, 8 Jul 2021 19:47:26 GMT, Markus Gr?nlund wrote: > Greetings, > > Object.finalize() was deprecated in JDK9. There is an ongoing effort to replace and mitigate Object.finalize() uses in the JDK libraries; please see https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. > > We also like to assist users in replacing and mitigating uses in non-JDK code. > > Hence, this changeset adds a periodic JFR event to help identify which classes are overriding Object.finalize(). > > Thanks > Markus This pull request has now been integrated. Changeset: 72a976ef Author: Markus Gr?nlund URL: https://git.openjdk.java.net/jdk/commit/72a976ef05fc2c62657920a560a0abc60b27c852 Stats: 1917 lines in 36 files changed: 1375 ins; 409 del; 133 mod 8266936: Add a finalization JFR event Reviewed-by: coleenp, mchung, egahlin ------------- PR: https://git.openjdk.java.net/jdk/pull/4731 From itakiguchi at openjdk.java.net Mon Oct 18 17:47:55 2021 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Mon, 18 Oct 2021 17:47:55 GMT Subject: RFR: 8274544: Langtools command's usage were garbled on Japanese Windows In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 23:43:47 GMT, Naoto Sato wrote: >> @takiguc - if JShell is still an issue, is there a chance you could try this: >> https://github.com/lahodaj/jdk/commit/cfa6b3eebbc22c5a48d31cfd692ff98690653686 >> >> Not sure if it will help, but it might (this won't change the default charset, but could send the output in a sensible encoding for the console. >> >> Thanks! > > I believe both @lahodaj and my proposed changes are needed, which I provided here: https://github.com/openjdk/jdk/commit/82a9033953655042480c90d388fcbc8053fc5ff5 > Can you check this works? Hello @naotoj . [82a9033](https://github.com/openjdk/jdk/commit/82a9033953655042480c90d388fcbc8053fc5ff5) worked on Windows platform, then I got your point. To minimize changes, I think I should create new method and call from JShellToolBuilder.java and JShellToolProvider.java. static PrintStream derivePrintStream(PrintStream ps) { if (Charset.defaultCharset().equals(NATIVE_CHARSET)) { return ps; } else { return new PrintStream(new WriterOutputStream( new OutputStreamWriter(ps, NATIVE_CHARSET), Charset.defaultCharset())); } } Additionally, I tested this issue on non-UTF-8 platform like RHEL7/CentOS7 EUC locale (ja_JP.eucjp). It seemed JLine's terminal's encoding was still UTF-8. I could not input Japanese character as expected, also Cut & Paste with Japanese string did not work. In my investigation, Charset.defaultCharset() was used on AbstractTerminal.java https://github.com/openjdk/jdk/blob/master/src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/AbstractTerminal.java#L55-L62 I should be like, this.encoding = encoding != null ? encoding : nativeCharset; (JLine was upgraded by b19, I need to rebase if it's required) One more thing, For Inter-Process Communication between jshell front-end and agent, I think default charset should be same for non UTF-8 environment. I think JdiInitiator.java should be modified. Please give me your suggestion. ------------- PR: https://git.openjdk.java.net/jdk/pull/5771 From naoto at openjdk.java.net Mon Oct 18 20:58:07 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 18 Oct 2021 20:58:07 GMT Subject: RFR: 7008363: TEST_BUG: test/java/lang/StringCoding/CheckEncodings.sh does nothing and is very slow at that Message-ID: Removing a problem-listed test case, which has little value in itself. Confirmed it did succeed on all platforms before the removal. ------------- Commit messages: - 7008363: TEST_BUG: test/java/lang/StringCoding/CheckEncodings.sh does nothing and is very slow at that Changes: https://git.openjdk.java.net/jdk/pull/5996/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5996&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-7008363 Stats: 96 lines in 3 files changed: 0 ins; 96 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5996.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5996/head:pull/5996 PR: https://git.openjdk.java.net/jdk/pull/5996 From iris at openjdk.java.net Mon Oct 18 21:51:49 2021 From: iris at openjdk.java.net (Iris Clark) Date: Mon, 18 Oct 2021 21:51:49 GMT Subject: RFR: 7008363: TEST_BUG: test/java/lang/StringCoding/CheckEncodings.sh does nothing and is very slow at that In-Reply-To: References: Message-ID: On Mon, 18 Oct 2021 20:49:07 GMT, Naoto Sato wrote: > Removing a problem-listed test case, which has little value in itself. Confirmed it did succeed on all platforms before the removal. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5996 From lancea at openjdk.java.net Mon Oct 18 22:01:54 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 18 Oct 2021 22:01:54 GMT Subject: RFR: 7008363: TEST_BUG: test/java/lang/StringCoding/CheckEncodings.sh does nothing and is very slow at that In-Reply-To: References: Message-ID: On Mon, 18 Oct 2021 20:49:07 GMT, Naoto Sato wrote: > Removing a problem-listed test case, which has little value in itself. Confirmed it did succeed on all platforms before the removal. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5996 From bpb at openjdk.java.net Mon Oct 18 22:56:47 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 18 Oct 2021 22:56:47 GMT Subject: RFR: 7008363: TEST_BUG: test/java/lang/StringCoding/CheckEncodings.sh does nothing and is very slow at that In-Reply-To: References: Message-ID: On Mon, 18 Oct 2021 20:49:07 GMT, Naoto Sato wrote: > Removing a problem-listed test case, which has little value in itself. Confirmed it did succeed on all platforms before the removal. Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5996 From naoto at openjdk.java.net Mon Oct 18 23:28:47 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 18 Oct 2021 23:28:47 GMT Subject: RFR: 8274544: Langtools command's usage were garbled on Japanese Windows [v3] In-Reply-To: References: Message-ID: On Wed, 6 Oct 2021 05:04:28 GMT, Ichiroh Takiguchi wrote: >> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13. >> After JDK18-b13, javac and some other langtool command's usage were garbled on Japanese Windows. >> These commands use PrintWriter instead of standard out/err with PrintStream. > > Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision: > > 8274544: Langtools command's usage were garbled on Japanese Windows this.encoding = encoding != null ? encoding : nativeCharset; I am not familiar with `JLine`, but if it is working in a Console, it should refer to `Console.charset()` first. As to `JdiInitiator`, not sure I understand the situation. Would you mind providing some examples that would cause problems? ------------- PR: https://git.openjdk.java.net/jdk/pull/5771 From sviswanathan at openjdk.java.net Tue Oct 19 01:11:52 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Tue, 19 Oct 2021 01:11:52 GMT Subject: RFR: 8271515: Integration of JEP 417: Vector API (Third Incubator) [v3] In-Reply-To: References: <_QQ9ntdJJfzVcAGrbjev0ZM-xNfD4wNATphnXkb-Y00=.bbf46985-8776-4dda-ada5-b15ab50774aa@github.com> Message-ID: On Sat, 16 Oct 2021 00:56:14 GMT, Paul Sandoz wrote: >> This PR improves the performance of vector operations that accept masks on architectures that support masking in hardware, specifically Intel AVX512 and ARM SVE. >> >> On architectures that do not support masking in hardware the same technique as before is applied to most operations, specifically composition using blend. >> >> Masked loads/stores are a special form of masked operation that require additional care to ensure out-of-bounds access throw exceptions. The range checking has not been fully optimized and will require further work. >> >> No API enhancements were required and only a few additional tests were needed. > > Paul Sandoz 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 JDK-8271515-vector-api > - Apply patch from https://github.com/openjdk/panama-vector/pull/152 > - Apply patch from https://github.com/openjdk/panama-vector/pull/142 > - Apply patch from https://github.com/openjdk/panama-vector/pull/139 > - Apply patch from https://github.com/openjdk/panama-vector/pull/151 > - Add new files. > - 8271515: Integration of JEP 417: Vector API (Third Incubator) src/hotspot/share/utilities/globalDefinitions.hpp line 36: > 34: > 35: #include COMPILER_HEADER(utilities/globalDefinitions) > 36: #include "utilities/globalDefinitions_vecApi.hpp" This change is not needed. src/hotspot/share/utilities/globalDefinitions_vecApi.hpp line 29: > 27: // the intent of this file to provide a header that can be included in .s files. > 28: > 29: #ifndef SHARE_VM_UTILITIES_GLOBALDEFINITIONS_VECAPI_HPP The file src/hotspot/share/utilities/globalDefinitions_vecApi.hpp is not needed. src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractMask.java line 67: > 65: > 66: @Override > 67: public boolean laneIsSet(int i) { Missing ForceInline. src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte128Vector.java line 278: > 276: @Override > 277: @ForceInline > 278: public Byte128Vector lanewise(Unary op, VectorMask m) { Should this method be final as well? src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte128Vector.java line 290: > 288: @Override > 289: @ForceInline > 290: public Byte128Vector lanewise(Binary op, Vector v, VectorMask m) { Should this method be final as well? src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte128Vector.java line 313: > 311: public final > 312: Byte128Vector > 313: lanewise(Ternary op, Vector v1, Vector v2) { For unary and binary operator above, we use VectorOperators.Unary and VectorOperators.Binary. Should we use VectorOperators.Ternary here as well then? src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte128Vector.java line 321: > 319: public final > 320: Byte128Vector > 321: lanewise(Ternary op, Vector v1, Vector v2, VectorMask m) { Should we use VectorOperators.Ternary here? src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte128Vector.java line 731: > 729: @Override > 730: @ForceInline > 731: public long toLong() { Should this and other mask operation methods be final methods? src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java line 603: > 601: if (opKind(op, VO_SPECIAL)) { > 602: if (op == ZOMO) { > 603: return blend(broadcast(-1), compare(NE, 0, m)); This doesn't look correct. The lanes where mask is false should get the original lane value in this vector. ------------- PR: https://git.openjdk.java.net/jdk/pull/5873 From jjg at openjdk.java.net Tue Oct 19 01:29:47 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 19 Oct 2021 01:29:47 GMT Subject: RFR: 8274544: Langtools command's usage were garbled on Japanese Windows [v3] In-Reply-To: References: Message-ID: <4rJtaiFtRYh-V2G3x2iCtQBtbD-lDGvqu5iVUQ_a-bA=.becf558e-ea95-4054-9f7d-3d5fe34c31c8@github.com> On Wed, 6 Oct 2021 05:04:28 GMT, Ichiroh Takiguchi wrote: >> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13. >> After JDK18-b13, javac and some other langtool command's usage were garbled on Japanese Windows. >> These commands use PrintWriter instead of standard out/err with PrintStream. > > Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision: > > 8274544: Langtools command's usage were garbled on Japanese Windows This is pretty ugly code to be replicating so many times. What if the tools have been run in an environment where `System.out` and `System.err` have already been redirected in some manner, with `System.setOut` or `System.setErr`? You should not assume that `System.out` and `System.err` will always refer to the console. ------------- PR: https://git.openjdk.java.net/jdk/pull/5771 From njian at openjdk.java.net Tue Oct 19 01:43:52 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Tue, 19 Oct 2021 01:43:52 GMT Subject: RFR: 8271515: Integration of JEP 417: Vector API (Third Incubator) [v3] In-Reply-To: References: <_QQ9ntdJJfzVcAGrbjev0ZM-xNfD4wNATphnXkb-Y00=.bbf46985-8776-4dda-ada5-b15ab50774aa@github.com> Message-ID: On Wed, 13 Oct 2021 19:33:12 GMT, Vladimir Kozlov wrote: > C2 and x86 changes seems fine. Could any reviewer please help to review AArch64 changes in this patch? @theRealAph @adinn @nick-arm ? The AArch64 changes include: 1. SVE scalable predicate register allocation support 2. SVE backend support for vector masking operations with predicate feature ------------- PR: https://git.openjdk.java.net/jdk/pull/5873 From dholmes at openjdk.java.net Tue Oct 19 02:27:48 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 19 Oct 2021 02:27:48 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v6] In-Reply-To: References: Message-ID: On Sat, 16 Oct 2021 11:11:59 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/419 > > Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision: > > - * use `invokeWithArguments` to simplify new test > - Add test for liveness check with high-aririty downcalls > (make sure that if an exception occurs in a downcall because of liveness, > ref count of other resources are left intact). Hotspot changes seem fine. Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/5907 From wuyan at openjdk.java.net Tue Oct 19 04:08:12 2021 From: wuyan at openjdk.java.net (Wu Yan) Date: Tue, 19 Oct 2021 04:08:12 GMT Subject: RFR: 8273111: Default timezone should return zone ID if /etc/localtime is valid but not canonicalization on linux [v5] In-Reply-To: <6gmVj3r1hjhG5jvo_dSly3ShNnZZSCn-NIjtnvSySrk=.a88def27-7b80-425b-9ab8-2f94f5004b47@github.com> References: <6gmVj3r1hjhG5jvo_dSly3ShNnZZSCn-NIjtnvSySrk=.a88def27-7b80-425b-9ab8-2f94f5004b47@github.com> Message-ID: > Hi, > Please help me review the change to enhance getting time zone ID from /etc/localtime on linux. > > We use `realpath` instead of `readlink` to obtain the link name of /etc/localtime, because `readlink` can only read the value of a symbolic of link, not the canonicalized absolute pathname. > > For example, the value of /etc/localtime is "../usr/share/zoneinfo//Asia/Shanghai", then the linkbuf obtained by `readlink` is "../usr/share/zoneinfo//Asia/Shanghai", and then the call of `getZoneName(linkbuf)` will get "/Asia/Shanghai", not "Asia/Shanghai", which consider as invalid in `ZoneInfoFile.getZoneInfo()`. Using `realpath`, you can get ?/usr/share/zoneinfo/Asia/Shanghai? directly from ?/etc/localtime?. > > Thanks, > wuyan Wu Yan has updated the pull request incrementally with one additional commit since the last revision: fix code style ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5327/files - new: https://git.openjdk.java.net/jdk/pull/5327/files/93cff3d1..ba9cc656 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5327&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5327&range=03-04 Stats: 9 lines in 1 file changed: 0 ins; 6 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5327.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5327/head:pull/5327 PR: https://git.openjdk.java.net/jdk/pull/5327 From wuyan at openjdk.java.net Tue Oct 19 04:17:01 2021 From: wuyan at openjdk.java.net (Wu Yan) Date: Tue, 19 Oct 2021 04:17:01 GMT Subject: RFR: 8273111: Default timezone should return zone ID if /etc/localtime is valid but not canonicalization on linux [v4] In-Reply-To: References: <6gmVj3r1hjhG5jvo_dSly3ShNnZZSCn-NIjtnvSySrk=.a88def27-7b80-425b-9ab8-2f94f5004b47@github.com> Message-ID: On Fri, 15 Oct 2021 07:03:18 GMT, Hamlin Li wrote: >> Wu Yan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: >> >> - Merge branch 'master' into timezone >> - change functions to be static >> - replace realpath >> - 8273111: Default timezone should return zone ID if /etc/localtime is valid but not canonicalization on linux > > src/java.base/unix/native/libjava/TimeZone_md.c line 82: > >> 80: >> 81: /* >> 82: * remove repeated path separators ('/') in the giving 'path'. > > given? Thanks, fix it. > src/java.base/unix/native/libjava/TimeZone_md.c line 89: > >> 87: char *left = path; >> 88: char *right = path; >> 89: char *end = path + strlen(path); > > "char* end"? better to align with existing code style OK, fixed it. > src/java.base/unix/native/libjava/TimeZone_md.c line 95: > >> 93: for (; right < end; right++) { >> 94: if (*right == '/' && *(right + 1) == '/') break; >> 95: } > > Is this for loop necessary? Seems it's ok to merge with the nested loop below. Thanks for your suggestion, this for loop is indeed unnecessary. Removed it. ------------- PR: https://git.openjdk.java.net/jdk/pull/5327 From duke at openjdk.java.net Tue Oct 19 06:35:55 2021 From: duke at openjdk.java.net (Mitsuru Kariya) Date: Tue, 19 Oct 2021 06:35:55 GMT Subject: RFR: 8153490: Cannot setBytes() if incoming buffer's length is bigger than number of elements we want to insert. [v5] In-Reply-To: <4MzAaDkmgdWxj_kxwdy7hq3I4jPQV39QX_Qg22TSjiI=.ff6a346a-4000-4cee-b50c-649a6a42ef14@github.com> References: <4MzAaDkmgdWxj_kxwdy7hq3I4jPQV39QX_Qg22TSjiI=.ff6a346a-4000-4cee-b50c-649a6a42ef14@github.com> Message-ID: <77FFslCAcaAsUso2PU1eIEwdGJ6ZmnJVMyC34AhOgXg=.5570b0c4-204b-4f36-9905-a808c02d0096@github.com> On Fri, 15 Oct 2021 09:30:18 GMT, Mitsuru Kariya wrote: >> Fix `SerialBlob.setBytes(long pos, byte[] bytes, int offset, int length)` in the following cases: >> >> 1. `pos - 1 + bytes.length - offset > this.length() && pos - 1 + length <= this.length()` >> The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully. >> (test31) >> >> 2. `pos - 1 + length > this.length()` >> The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully. *1 >> (test32) >> >> 3. `pos == this.length() + 1` >> The original implementation throws `SerialException` but this case should end successfully. *2 >> (test33) >> >> 4. `length < 0` >> The original implementation throws `ArrayIndexOutOfBoundsException` but this case should throw `SerialException`. >> (test34) >> >> 5. `offset + length > Integer.MAX_VALUE` >> The original implementation throws `ArrayIndexOutOfBoundsException` (or `OutOfMemoryError` in most cases) but this case should throw `SerialException`. >> (test35) >> >> Additionally, fix `SerialClob.setString(long pos, String str, int offset, int length)` in the following cases: >> >> 1. `offset > str.length()` >> The original implementaion throws `StringIndexOutOfBoundsException` but this case should throw `SerialException`. >> (test39) >> >> 2. `pos - 1 + str.length() - offset > this.length() && pos - 1 + length <= this.length()` >> The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully. >> (test32) >> >> 3. `pos - 1 + length > this.length()` >> The original implementaion throws `SerialException` but this case should end successfully. *3 >> (test40) >> >> 4. `pos == this.length() + 1` >> The original implementaion throws `SerialException` but this case should end successfully. *4 >> (test41) >> >> 5. `length < 0` >> The original implementation throws `StringIndexOutOfBoundsException` but this case should throw `SerialException`. >> (test42) >> >> 6. `offset + length > Integer.MAX_VALUE` >> The original implementation throws `ArrayIndexOutOfBoundsException` (or `OutOfMemoryError` in most cases) but this case should throw `SerialException`. >> (test43) >> >> >> The javadoc has also been modified according to the above. >> >> *1 The documentation of `Blob.setBytes()` says, "If the end of the Blob value is reached while writing the array of bytes, then the length of the Blob value will be increased to accommodate the extra bytes." >> >> *2 The documentation of `Blob.setBytes()` says, "If the value specified for pos is greater than the length+1 of the BLOB value then the behavior is undefined." >> So, it should work correctly when pos == length+1 of the BLOB value. >> >> *3 The documentation of `Clob.setString()` says, "If the end of the Clob value is eached while writing the given string, then the length of the Clob value will be increased to accommodate the extra characters." >> >> *4 The documentation of `Clob.setString()` says, "If the value specified for pos is greater than the length+1 of the CLOB value then the behavior is undefined." >> So, it should work correctly when pos == length+1 of the CLOB value. > > Mitsuru Kariya has updated the pull request incrementally with one additional commit since the last revision: > > Follow the comment The pre-submit test seems to have failed because the compiler was not found in some environments. Should I take any action? Or should I issue the /integrate pull request command? ------------- PR: https://git.openjdk.java.net/jdk/pull/4001 From mli at openjdk.java.net Tue Oct 19 07:06:52 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Tue, 19 Oct 2021 07:06:52 GMT Subject: RFR: 8273111: Default timezone should return zone ID if /etc/localtime is valid but not canonicalization on linux [v5] In-Reply-To: References: <6gmVj3r1hjhG5jvo_dSly3ShNnZZSCn-NIjtnvSySrk=.a88def27-7b80-425b-9ab8-2f94f5004b47@github.com> Message-ID: On Tue, 19 Oct 2021 04:08:12 GMT, Wu Yan wrote: >> Hi, >> Please help me review the change to enhance getting time zone ID from /etc/localtime on linux. >> >> We use `realpath` instead of `readlink` to obtain the link name of /etc/localtime, because `readlink` can only read the value of a symbolic of link, not the canonicalized absolute pathname. >> >> For example, the value of /etc/localtime is "../usr/share/zoneinfo//Asia/Shanghai", then the linkbuf obtained by `readlink` is "../usr/share/zoneinfo//Asia/Shanghai", and then the call of `getZoneName(linkbuf)` will get "/Asia/Shanghai", not "Asia/Shanghai", which consider as invalid in `ZoneInfoFile.getZoneInfo()`. Using `realpath`, you can get ?/usr/share/zoneinfo/Asia/Shanghai? directly from ?/etc/localtime?. >> >> Thanks, >> wuyan > > Wu Yan has updated the pull request incrementally with one additional commit since the last revision: > > fix code style looks good ------------- Marked as reviewed by mli (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5327 From whuang at openjdk.java.net Tue Oct 19 07:56:52 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Tue, 19 Oct 2021 07:56:52 GMT Subject: RFR: 7008363: TEST_BUG: test/java/lang/StringCoding/CheckEncodings.sh does nothing and is very slow at that In-Reply-To: References: Message-ID: On Mon, 18 Oct 2021 20:49:07 GMT, Naoto Sato wrote: > Removing a problem-listed test case, which has little value in itself. Confirmed it did succeed on all platforms before the removal. Marked as reviewed by whuang (Author). ------------- PR: https://git.openjdk.java.net/jdk/pull/5996 From jboes at openjdk.java.net Tue Oct 19 10:22:00 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Tue, 19 Oct 2021 10:22:00 GMT Subject: Integrated: 8245095: Implementation of JEP 408: Simple Web Server In-Reply-To: References: Message-ID: On Tue, 14 Sep 2021 08:52:37 GMT, Julia Boes wrote: > This change implements a simple web server that can be run on the command-line with `java -m jdk.httpserver`. > > This is facilitated by adding an entry point for the `jdk.httpserver` module, an implementation class whose main method is run when the above command is executed. This is the first such module entry point in the JDK. > > The server is a minimal HTTP server that serves the static files of a given directory, similar to existing alternatives on other platforms and convenient for testing, development, and debugging. > > Additionally, a small API is introduced for programmatic creation and customization. > > Testing: tier1-3. This pull request has now been integrated. Changeset: 9d191fce Author: Julia Boes URL: https://git.openjdk.java.net/jdk/commit/9d191fce55fa70d6a2affc724fad57b0e20e4bde Stats: 7181 lines in 42 files changed: 7146 ins; 15 del; 20 mod 8245095: Implementation of JEP 408: Simple Web Server Co-authored-by: Julia Boes Co-authored-by: Chris Hegarty Co-authored-by: Michael McMahon Co-authored-by: Daniel Fuchs Co-authored-by: Jan Lahoda Co-authored-by: Ivan ?ipka Reviewed-by: ihse, jlaskey, michaelm, chegar, dfuchs ------------- PR: https://git.openjdk.java.net/jdk/pull/5505 From jai.forums2013 at gmail.com Tue Oct 19 12:31:07 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Tue, 19 Oct 2021 18:01:07 +0530 Subject: JDK-8275509: (jlink) SystemModulesPlugin generates a jdk.internal.module.SystemModules$all.class which isn't reproducible Message-ID: This relates to the intermittent failures in tools/jlink/JLinkReproducibleTest.java test case which has been ProblemListed for a while now. The root cause is https://bugs.openjdk.java.net/browse/JDK-8275509. I couldn't find any specific mailing lists for jlink tool and I remember seeing jlink/jpackage related discussions on this mailing list previously, so creating this discussion here. The jlink tool uses plugins to let them transform contents of the modules that are part of the image. One such plugin is the SystemModulesPlugin and as per its javadoc specification its role is to prevent parsing of module-info.class files during JVM startup. To do so, it creates specialized dynamically generated class files (during jlink). The class file(s) are then bundled into the image that gets generated. One such class file is a dynamically generated jdk/internal/module/SystemModules$all.class. The SystemModulesPlugin generates the bytecode for this class. The details of that bytecode are very implementation specific. One part of the bytecode generation involves bytecode for an internal method called "moduleDescriptors()". One of the statements generated for this method implementation is a call to jdk.internal.module.Builder.build(int hashCode) method[1]. What this call does is, it creates a (pre-populated/validated) instance of the java.lang.module.ModuleDescriptor. The SystemModulesPlugin, when generating the bytecode of this method, uses the hashCode() of the ModuleDescriptor of the current JVM instance (through a typical ModuleDescriptor#hashCode() call)[2]. By doing so, it ends up generating bytecode which "embeds" the current runtime specific hashcode into the generated class file. The contract of java.lang.Object#hashCode() states: " ... This integer need not remain consistent from one execution of an application to another execution of the same application. .... " Effectively, what this means is, if jlink is used to generate an image with the exact same set of modules (requirements, package, exports, opens etc...) it still can (and does) end up generating a jdk/internal/module/SystemModules$all.class file whose binary content will differ across these runs, thus being non-reproducible. The implementation in java.lang.module.ModuleDescriptor is such that if the hashcode passed to it (during construction) is 0, then it lazily computes the correct hashcode whenever the invocation of hashCode() happens at runtime. What that means is, the SystemModulesPlugin in its bytecode generation for the moduleDescriptors() method could always pass 0 as the hashcode to the jdk.internal.module.Builder.build(int hashCode) call. That's something that I experimented with and after that change, with 100s of runs of the JLinkReproducibleTest, I no longer get any failures. However, given that the SystemModulesPlugin's goal appears to be to reduce the booting time for system modules, I was wondering if this change would introduce any performance penalty that is big enough. What this change will end up doing is, whenever the next time the hashCode method on instances of the system module's ModuleDescriptor gets called, it will have to compute it and that computation is relatively expensive (given how many "components" it uses to calculate it[3]). It's a (mostly) one time thing for each instance, but I don't know how expensive that would be. Do we have any existing benchmarks in this area that I could reuse to see what performance impact this might have? Keeping aside the performance issue for a bit, is this proposed patch something worth considering: --- a/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java +++ b/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java @@ -1099,7 +1099,13 @@ public final class SystemModulesPlugin extends AbstractPlugin { ???????????????? mv.visitVarInsn(ALOAD, MD_VAR); ???????????????? pushInt(mv, index); ???????????????? mv.visitVarInsn(ALOAD, BUILDER_VAR); -??????????????? mv.visitLdcInsn(md.hashCode()); +??????????????? // Let the ModuleDescriptor hashcode be computed at runtime. +??????????????? // Embedding the current hashcode of the ModuleDescriptor +??????????????? // into the bytecode of a generated class can cause the generated +??????????????? // bytecode to be not reproducible, since an object's hashcode is allowed +??????????????? // to change across JVM runs. +??????????????? mv.visitLdcInsn(0); // the hashcode to be passed to the +????????????????????????????????????????? // jdk.internal.module.Builder.build(int) method ???????????????? mv.visitMethodInsn(INVOKEVIRTUAL, MODULE_DESCRIPTOR_BUILDER, ???????????????????? "build", "(I)Ljava/lang/module/ModuleDescriptor;", ???????????????????? false); The other option I experimented with was to make ModuleDescriptor#hashCode() generate the same hashcode across multiple JVM runs. Although I do have a "working" version of that change, I decided not to spend too much time on it because the java.lang.Object#hashCode() contract itself clearly states that this value isn't expected to be same across multiple JVM runs. So whatever I do here is going to be brittle. [1] https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/module/Builder.java#L265 [2] https://github.com/openjdk/jdk/blob/master/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java#L1102 [3] https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/module/ModuleDescriptor.java#L2250 P.S: The major part of accurate investigation work for these intermittent failures was already done by Dongbo He in https://bugs.openjdk.java.net/browse/JDK-8258945. I just used that script and details to try and come up with a patch. -Jaikiran From jpai at openjdk.java.net Tue Oct 19 13:09:02 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 19 Oct 2021 13:09:02 GMT Subject: RFR: 8268595: java/io/Serializable/serialFilter/GlobalFilterTest.java#id1 failed in timeout Message-ID: <3utjHiAKf2SmUTuhFh4-9YTk476V2OggSFiIK5mFzj0=.96dcbfb3-8746-477e-8c25-c586cd1f0cc6@github.com> The `GlobalFilterTest` has to 2 `@test` tags. One of them has failed with a timeout as noted in https://bugs.openjdk.java.net/browse/JDK-8268595. The timeout seems to have happened even after the tests had already completed successfully. Like I note in the JBS comments of that issue, I suspect it might have to do with the "-XX:StartFlightRecording:name=DeserializationEvent,dumponexit=true" usage in this test action. The commit in this PR removes that second `@test` altogether because (correct me if I'm wrong) from what I understand, this test never enables the DeserializationEvent which means there is no JFR events being captured for deserialization in this test, nor does the test do any JFR events related testing. So, I think this second `@test` is virtually a no-op when it comes to the JFR testing. There's a separate `TestDeserializationEvent` which has a comprehensive testing of the DeserializationEvent. ------------- Commit messages: - 8268595: java/io/Serializable/serialFilter/GlobalFilterTest.java#id1 failed in timeout Changes: https://git.openjdk.java.net/jdk/pull/6008/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6008&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268595 Stats: 12 lines in 1 file changed: 0 ins; 12 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6008.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6008/head:pull/6008 PR: https://git.openjdk.java.net/jdk/pull/6008 From aefimov at openjdk.java.net Tue Oct 19 13:28:26 2021 From: aefimov at openjdk.java.net (Aleksei Efimov) Date: Tue, 19 Oct 2021 13:28:26 GMT Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v4] In-Reply-To: References: Message-ID: > This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver. > > The following API classes are added to `java.net.spi` package to facilitate this: > - `InetAddressResolverProvider` - abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers. > - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations. > - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations. > - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation. > > More details in [JEP-418](https://openjdk.java.net/jeps/418). > > Testing: new and existing `tier1:tier3` tests Aleksei Efimov has updated the pull request incrementally with four additional commits since the last revision: - Remove no longer used import from IPSupport - Rename IPSupport.hasAddress and update it to use SocketChannel.open - Address review comments: javadoc + code cleanup - Address resolver bootstraping issue ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5822/files - new: https://git.openjdk.java.net/jdk/pull/5822/files/d302a49a..ac0d2184 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5822&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5822&range=02-03 Stats: 245 lines in 5 files changed: 180 ins; 35 del; 30 mod Patch: https://git.openjdk.java.net/jdk/pull/5822.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5822/head:pull/5822 PR: https://git.openjdk.java.net/jdk/pull/5822 From aefimov at openjdk.java.net Tue Oct 19 13:28:36 2021 From: aefimov at openjdk.java.net (Aleksei Efimov) Date: Tue, 19 Oct 2021 13:28:36 GMT Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v3] In-Reply-To: <-JuSgJLSkme6YraHYehOdUah6GSER-EUo3Mq4TVjXKU=.f700cbe6-021a-43c4-a5ae-c0dc7b42d313@github.com> References: <-JuSgJLSkme6YraHYehOdUah6GSER-EUo3Mq4TVjXKU=.f700cbe6-021a-43c4-a5ae-c0dc7b42d313@github.com> Message-ID: On Fri, 15 Oct 2021 14:25:02 GMT, Daniel Fuchs wrote: >> Aleksei Efimov has updated the pull request incrementally with two additional commits since the last revision: >> >> - Add @since tags to new API classes >> - Add checks and test for empty stream resolver results > > src/java.base/share/classes/java/net/InetAddress.java line 231: > >> 229: * The first provider found will be used to instantiate the {@link InetAddressResolver InetAddressResolver} >> 230: * by invoking the {@link InetAddressResolverProvider#get(InetAddressResolverProvider.Configuration)} >> 231: * method. The instantiated {@code InetAddressResolver} will be installed as the system-wide > > Maybe "... method. The **returned** {@code InetAddressResolver} will be installed ..." Changed as suggested in 648e65b8e6ae9687f7164ea3e81c51ab2b5e2dfe. > src/java.base/share/classes/java/net/InetAddress.java line 486: > >> 484: return cns; >> 485: } finally { >> 486: bootstrapResolver = null; > > This is incorrect. This will set bootstrapResolver to null in the case where you return it at line 468 - which means that a second call will then find it null. I believe you want to set it to null in the finally clause only if you reached line 470. You could achieve this by declaring a local variable - e.g `InetAddressResolver tempResolver = null;` before entering the try-finally then set that variable at line 470 `return tempResolver = bootstrapResolver;` and in finally do `if (tempResolver == null) bootsrapResolver = null;` > > To test this you could try to call e.g. `InetAddress.getByName` twice in succession in your test: I believe it will fail with the code as it stands, but will succeed with my proposed changes... Good catch, thank you Daniel. Added a test for that and fixed it in cd19ecd63838d3c2b713ed66d41107fe01a2d3e6. Now the `bootstrapResolver` field is set back to `null` in finally block only if a call to `InetAddress.resolver()` entered a resolver initialization part. > src/java.base/share/classes/java/net/InetAddress.java line 860: > >> 858: return host; >> 859: } >> 860: } catch (RuntimeException | UnknownHostException e) { > > This may deserve a comment: resolver.lookUpHostName and InetAddress.getAllbyName0 delegate to the system-wide resolver, which could be custom, and we treat any unexpected RuntimeException thrown by the provider at that point as we would treat an UnknownHostException or an unmatched host name. Agree - comment added as part of 648e65b8e6ae9687f7164ea3e81c51ab2b5e2dfe. > src/java.base/share/classes/java/net/InetAddress.java line 1063: > >> 1061: public Stream lookupAddresses(String host, LookupPolicy policy) >> 1062: throws UnknownHostException { >> 1063: Objects.requireNonNull(host); > > Should we also double check that `policy` is not null? Or maybe assert it? Yes, we should since custom resolvers might call the built-in one with `null` - added non-null check in 648e65b . > src/java.base/share/classes/java/net/InetAddress.java line 1203: > >> 1201: + " as hosts file " + hostsFile + " not found "); >> 1202: } >> 1203: // Check number of found addresses: > > I wonder if the logic here could be simplified by first checking whether only IPv4 addresses are requested, and then if only IPv6 addresses are requested. > > That is - evacuate the simple cases first and then only deal with the more complex case where you have to combine the two lists... Tried to simplify it in 648e65b8e6ae9687f7164ea3e81c51ab2b5e2dfe ------------- PR: https://git.openjdk.java.net/jdk/pull/5822 From Alan.Bateman at oracle.com Tue Oct 19 13:29:51 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 19 Oct 2021 14:29:51 +0100 Subject: JDK-8275509: (jlink) SystemModulesPlugin generates a jdk.internal.module.SystemModules$all.class which isn't reproducible In-Reply-To: References: Message-ID: <4a4901a8-ca90-c9f3-0b2f-a37e521bfe65@oracle.com> On 19/10/2021 13:31, Jaikiran Pai wrote: > This relates to the intermittent failures in > tools/jlink/JLinkReproducibleTest.java test case which has been > ProblemListed for a while now. The root cause is > https://bugs.openjdk.java.net/browse/JDK-8275509. I couldn't find any > specific mailing lists for jlink tool and I remember seeing > jlink/jpackage related discussions on this mailing list previously, so > creating this discussion here. Reproducible builds have been a game of whack-a-mole. Many issues have been fixed in recent releases to the JDK is a lot better than it used to be. As it happens, someone else interested in reproducible builds brought up the issue of the hashCode on jigsaw-dev a few weeks ago [1]. The system modules plugin pre-dates the archiving of the module graph in the CDS archive so the performance profile is probably very different from when the plugin was created. I'll defer to Claes on what benchmarks to run. As regards changing the plugin then if we aren't creating the MD with a hashCode then I'd prefer to drop the hashCode parameter from the Builder and the shared secret. In other words, do some cleanup rather than leave it orfaned. -Alan [1] https://mail.openjdk.java.net/pipermail/jigsaw-dev/2021-September/014708.html From aefimov at openjdk.java.net Tue Oct 19 13:31:09 2021 From: aefimov at openjdk.java.net (Aleksei Efimov) Date: Tue, 19 Oct 2021 13:31:09 GMT Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v3] In-Reply-To: References: Message-ID: On Fri, 15 Oct 2021 17:09:46 GMT, Daniel Fuchs wrote: >> Aleksei Efimov has updated the pull request incrementally with two additional commits since the last revision: >> >> - Add @since tags to new API classes >> - Add checks and test for empty stream resolver results > > test/jdk/java/net/spi/InetAddressResolverProvider/providers/recursive/recursive.init.provider/impl/InetAddressUsageInGetProviderImpl.java line 38: > >> 36: String localHostName; >> 37: try { >> 38: localHostName = InetAddress.getLocalHost().getHostName(); > > Try to call InetAddress.getLocalHost().getHostName(); twice here. New `BootstrapResolverUsageTest` test is added to trigger the bootstrap resolver problem. `InetAddress.getByName` calls with unique names are used instead of `InetAddress.getLocalHost()` to avoid caching of LHN resolution results. Added in cd19ecd63838d3c2b713ed66d41107fe01a2d3e6. ------------- PR: https://git.openjdk.java.net/jdk/pull/5822 From aefimov at openjdk.java.net Tue Oct 19 13:34:50 2021 From: aefimov at openjdk.java.net (Aleksei Efimov) Date: Tue, 19 Oct 2021 13:34:50 GMT Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v3] In-Reply-To: References: Message-ID: On Fri, 15 Oct 2021 17:19:26 GMT, Daniel Fuchs wrote: >> Aleksei Efimov has updated the pull request incrementally with two additional commits since the last revision: >> >> - Add @since tags to new API classes >> - Add checks and test for empty stream resolver results > > test/lib/jdk/test/lib/net/IPSupport.java line 88: > >> 86: } catch (SocketException se2) { >> 87: return false; >> 88: } > > The implementation of this method now conflicts with its name. Maybe we should pass a `Class` as parameter, and construct the loopback address from there. IIRC the issue with the original implementation was that it would say that IPv6 was not supported if IPv6 had only been disabled on the loopback interface - and that caused trouble because the native implementation of the built-in resolver had a different view of the situation - and saw that an IPv6 stack was available on the machine. Maybe this would deserve a comment too - so that future maintainers can figure out what we are trying to do here. Thanks for a good suggestion: renamed to `isSupported`, changed parameter type to `Class addressType` and updated it to use `SocketChannel.open(ProtocolFamily pf)` [API](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/nio/channels/SocketChannel.html#open(java.net.ProtocolFamily)) added in `15` to check if the plafrom supports addresses of specified address type. Pushed as 95a21e57fbe8be147d23e6a6901ae307e8237cbb. All new tests (especially `LookupPolicyMappingTest`) pass in environment with `IPv6` addresses disabled. ------------- PR: https://git.openjdk.java.net/jdk/pull/5822 From claes.redestad at oracle.com Tue Oct 19 13:37:06 2021 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 19 Oct 2021 15:37:06 +0200 Subject: JDK-8275509: (jlink) SystemModulesPlugin generates a jdk.internal.module.SystemModules$all.class which isn't reproducible In-Reply-To: References: Message-ID: <901f27aa-ad2b-9e3f-92b6-6337d55705eb@oracle.com> On 2021-10-19 14:31, Jaikiran Pai wrote: > The other option I experimented with was to make > ModuleDescriptor#hashCode() generate the same hashcode across multiple > JVM runs. Although I do have a "working" version of that change, I > decided not to spend too much time on it because the > java.lang.Object#hashCode() contract itself clearly states that this > value isn't expected to be same across multiple JVM runs. So whatever > I do here is going to be brittle. I'm assuming the cause for ModuleDescriptor#hashCode being is due to the various enums not having an explicitly defined hashCode? I think this should be fixed. Either way you're going to be brittle since the patch to emit a 0 is relying on the ModuleDescriptor#hashCode implementation disallowing 0 as a hash value (a 0 will force a recalculation). While it'll only happen at most once per module these relatively expensive calculations are something we want to avoid on startup if we can do so for free. /Claes From jai.forums2013 at gmail.com Tue Oct 19 13:49:21 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Tue, 19 Oct 2021 19:19:21 +0530 Subject: JDK-8275509: (jlink) SystemModulesPlugin generates a jdk.internal.module.SystemModules$all.class which isn't reproducible In-Reply-To: <4a4901a8-ca90-c9f3-0b2f-a37e521bfe65@oracle.com> References: <4a4901a8-ca90-c9f3-0b2f-a37e521bfe65@oracle.com> Message-ID: <77faaab4-831c-de4f-2f64-f7305cb8f9fb@gmail.com> Hello Alan, On 19/10/21 6:59 pm, Alan Bateman wrote: > On 19/10/2021 13:31, Jaikiran Pai wrote: >> This relates to the intermittent failures in >> tools/jlink/JLinkReproducibleTest.java test case which has been >> ProblemListed for a while now. The root cause is >> https://bugs.openjdk.java.net/browse/JDK-8275509. I couldn't find any >> specific mailing lists for jlink tool and I remember seeing >> jlink/jpackage related discussions on this mailing list previously, >> so creating this discussion here. > > Reproducible builds have been a game of whack-a-mole. Many issues have > been fixed in recent releases to the JDK is a lot better than it used > to be. As it happens, someone else interested in reproducible builds > brought up the issue of the hashCode on jigsaw-dev a few weeks ago [1]. Ah! So this exact same investigation had already happened a few weeks back then. I haven't subscribed to that list, so missed it. I see in one of those messages this part: "Off hand I can't think of any issues with the ModuleDescriptor hashCode. It is computed at link time and should be deterministic. If I were to guess then then this may be something to do with the module version recorded at compile-time at that is one of the components that the hash is based on." To be clear, is the ModuleDescriptor#hashCode() expected to return reproducible (same) hashCode across multiple runs? What currently changes the hashCode() across multiple runs is various components within ModuleDescriptor's hashCode() implementation using the hashCode() of the enums (specifically the various Modifier enums). For example here https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/module/ModuleDescriptor.java#L330 (the mods.hashCode()). Since the hashCode() returned by enums is literally through a call to java.lang.Object#hashCode(), those hashCode() value ended up changing across JVM runs, in one of the setups I was testing (which I didn't consider a surprise since that's what the Object#hashCode() stated). The other approach that I talked about in my previous mail of trying to make ModuleDescriptor#hashCode() reproducible involved using the enum's ordinal value as a part of the hashCode() computation instead of calling the enum's hashCode() method. Very crudely, it looked like: diff --git a/src/java.base/share/classes/java/lang/module/ModuleDescriptor.java b/src/java.base/share/classes/java/lang/module/ModuleDescriptor.java index a412dd753cc..13c8cd04360 100644 --- a/src/java.base/share/classes/java/lang/module/ModuleDescriptor.java +++ b/src/java.base/share/classes/java/lang/module/ModuleDescriptor.java @@ -327,7 +327,7 @@ public class ModuleDescriptor ????????? */ ???????? @Override ???????? public int hashCode() { -??????????? int hash = name.hashCode() * 43 + mods.hashCode(); +??????????? int hash = name.hashCode() * 43 + enumOrdinalHashCode(mods); ???????????? if (compiledVersion != null) ???????????????? hash = hash * 43 + compiledVersion.hashCode(); ???????????? if (rawCompiledVersion != null) @@ -505,7 +505,7 @@ public class ModuleDescriptor ????????? */ ???????? @Override ???????? public int hashCode() { -??????????? int hash = mods.hashCode(); +??????????? int hash = enumOrdinalHashCode(mods); ???????????? hash = hash * 43 + source.hashCode(); ???????????? return hash * 43 + targets.hashCode(); ???????? } @@ -708,7 +708,7 @@ public class ModuleDescriptor ????????? */ ???????? @Override ???????? public int hashCode() { -??????????? int hash = mods.hashCode(); +??????????? int hash = enumOrdinalHashCode(mods); ???????????? hash = hash * 43 + source.hashCode(); ???????????? return hash * 43 + targets.hashCode(); ???????? } @@ -2261,7 +2261,7 @@ public class ModuleDescriptor ???????? int hc = hash; ???????? if (hc == 0) { ???????????? hc = name.hashCode(); -??????????? hc = hc * 43 + Objects.hashCode(modifiers); +??????????? hc = hc * 43 + enumOrdinalHashCode(modifiers); ???????????? hc = hc * 43 + requires.hashCode(); ???????????? hc = hc * 43 + Objects.hashCode(packages); ???????????? hc = hc * 43 + exports.hashCode(); @@ -2546,6 +2546,21 @@ public class ModuleDescriptor ???????????????? .collect(Collectors.joining(" ")); ???? } +??? /** +???? * Generates and returns a hashcode for the enum instances. The returned hashcode +???? * is a sum of each of the enum instances' {@link Enum#ordinal() ordinal} value. +???? */ +??? private static int enumOrdinalHashCode(final Iterable> enums) { +??????? int h = 0; +??????? for (final Enum e : enums) { +??????????? if (e == null) { +??????????????? continue; +??????????? } +??????????? h += e.ordinal(); +??????? } +??????? return h; +??? } + ???? private static > ???? int compare(T obj1, T obj2) { ???????? if (obj1 != null) { With this change (and this change only, no changes in SystemModulesPlugin were needed) I was able to consistently run that test without any failures. But I didn't pursue this effort further because I thought making ModuleDescriptor#hashCode() return reproducible result wasn't a goal. Do you think we should be making ModuleDescriptor#hashCode() deterministic and reproducible across runs? If so, if that above patch looks reasonable, I can clean it up a bit and run some further tests. -Jaikiran From rriggs at openjdk.java.net Tue Oct 19 13:51:56 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 19 Oct 2021 13:51:56 GMT Subject: RFR: 8269336: Malformed jdk.serialFilter incorrectly handled In-Reply-To: References: Message-ID: On Mon, 18 Oct 2021 13:44:56 GMT, Jaikiran Pai wrote: > Can I please get a review for this change which addresses https://bugs.openjdk.java.net/browse/JDK-8269336? > > As noted in that issue, this change will now propagate any exception that occurred during parsing and creation of the filter configured through the `jdk.serialFilter` system property. It will also continue to log those errors, like it previously did. > > A new jtreg test has been introduced to reproduce this issue and verify the fix. > > Given that invalid values for this system property will now start throwing exception, will this change need a CSR? src/java.base/share/classes/java/io/ObjectInputFilter.java line 641: > 639: "Error configuring filter: {0}", (Object) re); > 640: // Do not continue if configuration not initialized > 641: throw new ExceptionInInitializerError(re); Just re-throw the RuntimeException. It will be caught by the caller of the static initialize and wrapped in ExceptioninInitializerError. I don't think a CSR is needed since this exception is not part of an API. ------------- PR: https://git.openjdk.java.net/jdk/pull/5988 From jai.forums2013 at gmail.com Tue Oct 19 13:52:27 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Tue, 19 Oct 2021 19:22:27 +0530 Subject: JDK-8275509: (jlink) SystemModulesPlugin generates a jdk.internal.module.SystemModules$all.class which isn't reproducible In-Reply-To: <901f27aa-ad2b-9e3f-92b6-6337d55705eb@oracle.com> References: <901f27aa-ad2b-9e3f-92b6-6337d55705eb@oracle.com> Message-ID: <3d9e075b-6352-b0d8-ca24-6b5358ec349c@gmail.com> Hello Claes, On 19/10/21 7:07 pm, Claes Redestad wrote: > On 2021-10-19 14:31, Jaikiran Pai wrote: >> The other option I experimented with was to make >> ModuleDescriptor#hashCode() generate the same hashcode across >> multiple JVM runs. Although I do have a "working" version of that >> change, I decided not to spend too much time on it because the >> java.lang.Object#hashCode() contract itself clearly states that this >> value isn't expected to be same across multiple JVM runs. So whatever >> I do here is going to be brittle. > > I'm assuming the cause for ModuleDescriptor#hashCode being is due to > the various enums not having an explicitly defined hashCode? You are right. That was what was causing the change in values. I just sent a separate reply in this thread with additional details. > I think this should be fixed. Okay, I'll pursue this path then. > > Either way you're going to be brittle since the patch to emit a 0 is > relying on the ModuleDescriptor#hashCode implementation disallowing 0 > as a hash value (a 0 will force a recalculation). While it'll only > happen at most once per module these relatively expensive calculations > are something we want to avoid on startup if we can do so for free. Understood. Thank you for these inputs. -Jaikiran From aefimov at openjdk.java.net Tue Oct 19 13:56:50 2021 From: aefimov at openjdk.java.net (Aleksei Efimov) Date: Tue, 19 Oct 2021 13:56:50 GMT Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v3] In-Reply-To: <-8BcYWYlwGxmsmAY7JBT2h_Ahae3fONnwgGJxfedrJY=.8826d18f-4e00-496e-b06c-96d44e0eeb6c@github.com> References: <-8BcYWYlwGxmsmAY7JBT2h_Ahae3fONnwgGJxfedrJY=.8826d18f-4e00-496e-b06c-96d44e0eeb6c@github.com> Message-ID: On Sun, 17 Oct 2021 21:39:06 GMT, Mark Sheppard wrote: > I think that a hostname is constant while a host is up, but it can be changed, and when changed a host restart is required. I don't think it is quite as dynamic as has been suggested, but I open to correction. It is possible to change a host name without host restart. What has been tested: - Checked O/S type - Linux - `hostnamectl` cmd was used to change a host name - In output below there is only one `jshell` instance running. jshell> InetAddress.getLocalHost() $1 ==> test-host-name/192.168.0.155 $ hostnamectl set-hostname 'test-host-name-changed' # Need to sleep for 5 seconds since local host # is cached for 5 seconds since last resolution $ sleep 5 jshell> InetAddress.getLocalHost() $2 ==> test-host-name-changed/192.168.0.155 I believe it proves that we need to treat a host name as dynamically changing information. ------------- PR: https://git.openjdk.java.net/jdk/pull/5822 From weijun at openjdk.java.net Tue Oct 19 14:01:11 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 19 Oct 2021 14:01:11 GMT Subject: RFR: 8275512: Upgrade required version of jtreg to 6.1 Message-ID: <8ZF_bktOd9u8s06pS5q_VfPnDplwwjhlpz8pdLyHnvw=.67c1b571-5f34-4251-9872-34ccb89dbd5a@github.com> As a follow up of JEP 411, we will soon disallow security manager by default. jtreg 6.1 does not set its own security manager if JDK version is >= 18. ------------- Commit messages: - 8275512: Upgrade required version of jtreg to 6.1 Changes: https://git.openjdk.java.net/jdk/pull/6012/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6012&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275512 Stats: 7 lines in 6 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/6012.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6012/head:pull/6012 PR: https://git.openjdk.java.net/jdk/pull/6012 From ihse at openjdk.java.net Tue Oct 19 14:09:49 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 19 Oct 2021 14:09:49 GMT Subject: RFR: 8275512: Upgrade required version of jtreg to 6.1 In-Reply-To: <8ZF_bktOd9u8s06pS5q_VfPnDplwwjhlpz8pdLyHnvw=.67c1b571-5f34-4251-9872-34ccb89dbd5a@github.com> References: <8ZF_bktOd9u8s06pS5q_VfPnDplwwjhlpz8pdLyHnvw=.67c1b571-5f34-4251-9872-34ccb89dbd5a@github.com> Message-ID: <1Lt3IpTy-rZBwrcdQpbCaw1mCBR42UyLd0JIn_55qJ4=.cf17c8d5-ee9d-4ad1-8f21-ff7a4e5eeacd@github.com> On Tue, 19 Oct 2021 13:51:45 GMT, Weijun Wang wrote: > As a follow up of JEP 411, we will soon disallow security manager by default. jtreg 6.1 does not set its own security manager if JDK version is >= 18. LGTM ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6012 From Alan.Bateman at oracle.com Tue Oct 19 14:10:26 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 19 Oct 2021 15:10:26 +0100 Subject: JDK-8275509: (jlink) SystemModulesPlugin generates a jdk.internal.module.SystemModules$all.class which isn't reproducible In-Reply-To: <77faaab4-831c-de4f-2f64-f7305cb8f9fb@gmail.com> References: <4a4901a8-ca90-c9f3-0b2f-a37e521bfe65@oracle.com> <77faaab4-831c-de4f-2f64-f7305cb8f9fb@gmail.com> Message-ID: <60708e84-4888-9584-50e0-df3ae5d8b0b5@oracle.com> On 19/10/2021 14:49, Jaikiran Pai wrote: > > Ah! So this exact same investigation had already happened a few weeks > back then. I haven't subscribed to that list, so missed it. I see in > one of those messages this part: > > "Off hand I can't think of any issues with the ModuleDescriptor > hashCode. It is computed at link time and should be deterministic. If > I were to guess then then this may be something to do with the module > version recorded at compile-time at that is one of the components that > the hash is based on." > > To be clear, is the ModuleDescriptor#hashCode() expected to return > reproducible (same) hashCode across multiple runs? What currently > changes the hashCode() across multiple runs is various components > within ModuleDescriptor's hashCode() implementation using the > hashCode() of the enums (specifically the various Modifier enums). The discussion on jigsaw-dev didn't get to the bottom of the issue at the time, mostly because it wasn't easy to reproduce. Now that the issue is clearer then we should fix it. Aside from reproducible builds then I expect it is possible to use a ModuleDescriptor.Builder to create a ModuleDescriptor that is equal to a ModuleDescriptor in boot layer configuration but with a different hashCode. On the surface, changing the MD hash code to use the ordinal of the modifiers should be okay. If the enums values are re-ordered then it should also be okay but clearly doing so would end up with a build that is not binary identical to a build done with a different order. I think we need to think though if there are any implications. -Alan From jpai at openjdk.java.net Tue Oct 19 14:22:26 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 19 Oct 2021 14:22:26 GMT Subject: RFR: 8269336: Malformed jdk.serialFilter incorrectly handled [v2] In-Reply-To: References: Message-ID: > Can I please get a review for this change which addresses https://bugs.openjdk.java.net/browse/JDK-8269336? > > As noted in that issue, this change will now propagate any exception that occurred during parsing and creation of the filter configured through the `jdk.serialFilter` system property. It will also continue to log those errors, like it previously did. > > A new jtreg test has been introduced to reproduce this issue and verify the fix. > > Given that invalid values for this system property will now start throwing exception, will this change need a CSR? Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: Roger's review suggestion - rethrow the RuntimeException instead of wrapping in ExceptionInInitializerError ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5988/files - new: https://git.openjdk.java.net/jdk/pull/5988/files/3169a338..d443049a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5988&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5988&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5988.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5988/head:pull/5988 PR: https://git.openjdk.java.net/jdk/pull/5988 From jpai at openjdk.java.net Tue Oct 19 14:22:31 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 19 Oct 2021 14:22:31 GMT Subject: RFR: 8269336: Malformed jdk.serialFilter incorrectly handled [v2] In-Reply-To: References: Message-ID: On Tue, 19 Oct 2021 13:48:33 GMT, Roger Riggs wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> Roger's review suggestion - rethrow the RuntimeException instead of wrapping in ExceptionInInitializerError > > src/java.base/share/classes/java/io/ObjectInputFilter.java line 641: > >> 639: "Error configuring filter: {0}", (Object) re); >> 640: // Do not continue if configuration not initialized >> 641: throw new ExceptionInInitializerError(re); > > Just re-throw the RuntimeException. > It will be caught by the caller of the static initialize and wrapped in ExceptioninInitializerError. > > I don't think a CSR is needed since this exception is not part of an API. Done. Updated the PR. Test continues to pass. I had copy/pasted the wrapping into `ExceptioninInitializerError` from a few lines down, in that code. But looking at it more closely now, I guess, that other line which is throwing the `ExceptioninInitializerError` is doing that because what's being thrown in that block can potentially be a `Throwable`. ------------- PR: https://git.openjdk.java.net/jdk/pull/5988 From iignatyev at openjdk.java.net Tue Oct 19 15:44:51 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Tue, 19 Oct 2021 15:44:51 GMT Subject: RFR: 8275512: Upgrade required version of jtreg to 6.1 In-Reply-To: <8ZF_bktOd9u8s06pS5q_VfPnDplwwjhlpz8pdLyHnvw=.67c1b571-5f34-4251-9872-34ccb89dbd5a@github.com> References: <8ZF_bktOd9u8s06pS5q_VfPnDplwwjhlpz8pdLyHnvw=.67c1b571-5f34-4251-9872-34ccb89dbd5a@github.com> Message-ID: On Tue, 19 Oct 2021 13:51:45 GMT, Weijun Wang wrote: > As a follow up of JEP 411, we will soon disallow security manager by default. jtreg 6.1 does not set its own security manager if JDK version is >= 18. LGTM ------------- Marked as reviewed by iignatyev (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6012 From naoto at openjdk.java.net Tue Oct 19 15:57:57 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 19 Oct 2021 15:57:57 GMT Subject: Integrated: 7008363: TEST_BUG: test/java/lang/StringCoding/CheckEncodings.sh does nothing and is very slow at that In-Reply-To: References: Message-ID: On Mon, 18 Oct 2021 20:49:07 GMT, Naoto Sato wrote: > Removing a problem-listed test case, which has little value in itself. Confirmed it did succeed on all platforms before the removal. This pull request has now been integrated. Changeset: 8a3e0a1f Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/8a3e0a1fc1fef02edf9621b13e8be8b96a12bb0f Stats: 96 lines in 3 files changed: 0 ins; 96 del; 0 mod 7008363: TEST_BUG: test/java/lang/StringCoding/CheckEncodings.sh does nothing and is very slow at that Reviewed-by: iris, lancea, bpb, whuang ------------- PR: https://git.openjdk.java.net/jdk/pull/5996 From dfuchs at openjdk.java.net Tue Oct 19 17:05:49 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 19 Oct 2021 17:05:49 GMT Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v4] In-Reply-To: References: Message-ID: On Tue, 19 Oct 2021 13:28:26 GMT, Aleksei Efimov wrote: >> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver. >> >> The following API classes are added to `java.net.spi` package to facilitate this: >> - `InetAddressResolverProvider` - abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers. >> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations. >> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations. >> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation. >> >> More details in [JEP-418](https://openjdk.java.net/jeps/418). >> >> Testing: new and existing `tier1:tier3` tests > > Aleksei Efimov has updated the pull request incrementally with four additional commits since the last revision: > > - Remove no longer used import from IPSupport > - Rename IPSupport.hasAddress and update it to use SocketChannel.open > - Address review comments: javadoc + code cleanup > - Address resolver bootstraping issue Changes look good to me. ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5822 From hseigel at openjdk.java.net Tue Oct 19 17:19:07 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 19 Oct 2021 17:19:07 GMT Subject: RFR: 8272614: Unused parameters in MethodHandleNatives linking methods Message-ID: Please review this small fix for JDK-8272614 to remove the unused indexInCP argument to linkCallSite() and linkDynamicConstant(). The fix was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-6 on Linux x64. Thanks, Harold ------------- Commit messages: - 8272614: Unused parameters in MethodHandleNatives linking methods Changes: https://git.openjdk.java.net/jdk/pull/6021/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6021&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272614 Stats: 8 lines in 3 files changed: 0 ins; 3 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/6021.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6021/head:pull/6021 PR: https://git.openjdk.java.net/jdk/pull/6021 From weijun at openjdk.java.net Tue Oct 19 17:24:17 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 19 Oct 2021 17:24:17 GMT Subject: RFR: 8275512: Upgrade required version of jtreg to 6.1 [v2] In-Reply-To: <8ZF_bktOd9u8s06pS5q_VfPnDplwwjhlpz8pdLyHnvw=.67c1b571-5f34-4251-9872-34ccb89dbd5a@github.com> References: <8ZF_bktOd9u8s06pS5q_VfPnDplwwjhlpz8pdLyHnvw=.67c1b571-5f34-4251-9872-34ccb89dbd5a@github.com> Message-ID: > As a follow up of JEP 411, we will soon disallow security manager by default. jtreg 6.1 does not set its own security manager if JDK version is >= 18. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: upgrade the version in GHA config only in patch2: unchanged: ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6012/files - new: https://git.openjdk.java.net/jdk/pull/6012/files/b86e799c..f5ffc49b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6012&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6012&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6012.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6012/head:pull/6012 PR: https://git.openjdk.java.net/jdk/pull/6012 From joehw at openjdk.java.net Tue Oct 19 17:30:56 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Tue, 19 Oct 2021 17:30:56 GMT Subject: RFR: 8275512: Upgrade required version of jtreg to 6.1 [v2] In-Reply-To: References: <8ZF_bktOd9u8s06pS5q_VfPnDplwwjhlpz8pdLyHnvw=.67c1b571-5f34-4251-9872-34ccb89dbd5a@github.com> Message-ID: On Tue, 19 Oct 2021 17:24:17 GMT, Weijun Wang wrote: >> As a follow up of JEP 411, we will soon disallow security manager by default. jtreg 6.1 does not set its own security manager if JDK version is >= 18. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > upgrade the version in GHA config > > only in patch2: > unchanged: Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6012 From lancea at openjdk.java.net Tue Oct 19 20:19:33 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 19 Oct 2021 20:19:33 GMT Subject: RFR: 8275512: Upgrade required version of jtreg to 6.1 [v2] In-Reply-To: References: <8ZF_bktOd9u8s06pS5q_VfPnDplwwjhlpz8pdLyHnvw=.67c1b571-5f34-4251-9872-34ccb89dbd5a@github.com> Message-ID: On Tue, 19 Oct 2021 17:24:17 GMT, Weijun Wang wrote: >> As a follow up of JEP 411, we will soon disallow security manager by default. jtreg 6.1 does not set its own security manager if JDK version is >= 18. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > upgrade the version in GHA config > > only in patch2: > unchanged: Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6012 From psandoz at openjdk.java.net Tue Oct 19 20:21:47 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Tue, 19 Oct 2021 20:21:47 GMT Subject: RFR: 8271515: Integration of JEP 417: Vector API (Third Incubator) [v3] In-Reply-To: References: <_QQ9ntdJJfzVcAGrbjev0ZM-xNfD4wNATphnXkb-Y00=.bbf46985-8776-4dda-ada5-b15ab50774aa@github.com> Message-ID: <5Vyao27ssAe8dot0Z6Epc3KlRi57Aaf8j3UdroTSbFU=.1aae99e3-de3c-49b2-a14b-88fa24e9779b@github.com> On Mon, 18 Oct 2021 22:56:37 GMT, Sandhya Viswanathan wrote: >> Paul Sandoz 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 JDK-8271515-vector-api >> - Apply patch from https://github.com/openjdk/panama-vector/pull/152 >> - Apply patch from https://github.com/openjdk/panama-vector/pull/142 >> - Apply patch from https://github.com/openjdk/panama-vector/pull/139 >> - Apply patch from https://github.com/openjdk/panama-vector/pull/151 >> - Add new files. >> - 8271515: Integration of JEP 417: Vector API (Third Incubator) > > src/hotspot/share/utilities/globalDefinitions_vecApi.hpp line 29: > >> 27: // the intent of this file to provide a header that can be included in .s files. >> 28: >> 29: #ifndef SHARE_VM_UTILITIES_GLOBALDEFINITIONS_VECAPI_HPP > > The file src/hotspot/share/utilities/globalDefinitions_vecApi.hpp is not needed. I notice src/jdk.incubator.vector/windows/native/libsvml/globals_vectorApiSupport_windows.S.inc contains a refence in comments to that file, I presume i can remove that comment too? > src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte128Vector.java line 278: > >> 276: @Override >> 277: @ForceInline >> 278: public Byte128Vector lanewise(Unary op, VectorMask m) { > > Should this method be final as well? It's actually redundant because the class is final. Better to drop final from all declarations, at the risk of creating a larger diff. > src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte128Vector.java line 321: > >> 319: public final >> 320: Byte128Vector >> 321: lanewise(Ternary op, Vector v1, Vector v2, VectorMask m) { > > Should we use VectorOperators.Ternary here? We static import `import static jdk.incubator.vector.VectorOperators.*;`, and the qualification of enclosing type `VectorOperators` seems inconsistently used. I think we can drop it at all declarations. > src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java line 603: > >> 601: if (opKind(op, VO_SPECIAL)) { >> 602: if (op == ZOMO) { >> 603: return blend(broadcast(-1), compare(NE, 0, m)); > > This doesn't look correct. The lanes where mask is false should get the original lane value in this vector. That should work, since `compare(NE, 0, m) === compare(NE, 0).and(m)`, so when an `m` lane is unset the lane element of `this` vector will be selected. Running jshell against a build of PR: $ ~/Projects/jdk/jdk/build/macosx-x86_64-server-release/images/jdk/bin/jshell --add-modules jdk.incubator.vector | Welcome to JShell -- Version 18-internal | For an introduction type: /help intro jshell> import jdk.incubator.vector.* jshell> var s = IntVector.SPECIES_256; s ==> Species[int, 8, S_256_BIT] jshell> var v = IntVector.fromArray(s, new int[]{0, 1, 0, -2, 0, 3, 0, -4}, 0); v ==> [0, 1, 0, -2, 0, 3, 0, -4] jshell> var z = v.lanewise(VectorOperators.ZOMO); z ==> [0, -1, 0, -1, 0, -1, 0, -1] jshell> z = v.lanewise(VectorOperators.ZOMO, s.loadMask(new boolean[]{false, false, false, false, true, true, true, true}, 0)); z ==> [0, 1, 0, -2, 0, -1, 0, -1] jshell> ------------- PR: https://git.openjdk.java.net/jdk/pull/5873 From sviswanathan at openjdk.java.net Tue Oct 19 20:21:52 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Tue, 19 Oct 2021 20:21:52 GMT Subject: RFR: 8271515: Integration of JEP 417: Vector API (Third Incubator) [v3] In-Reply-To: <5Vyao27ssAe8dot0Z6Epc3KlRi57Aaf8j3UdroTSbFU=.1aae99e3-de3c-49b2-a14b-88fa24e9779b@github.com> References: <_QQ9ntdJJfzVcAGrbjev0ZM-xNfD4wNATphnXkb-Y00=.bbf46985-8776-4dda-ada5-b15ab50774aa@github.com> <5Vyao27ssAe8dot0Z6Epc3KlRi57Aaf8j3UdroTSbFU=.1aae99e3-de3c-49b2-a14b-88fa24e9779b@github.com> Message-ID: On Tue, 19 Oct 2021 18:54:01 GMT, Paul Sandoz wrote: >> src/hotspot/share/utilities/globalDefinitions_vecApi.hpp line 29: >> >>> 27: // the intent of this file to provide a header that can be included in .s files. >>> 28: >>> 29: #ifndef SHARE_VM_UTILITIES_GLOBALDEFINITIONS_VECAPI_HPP >> >> The file src/hotspot/share/utilities/globalDefinitions_vecApi.hpp is not needed. > > I notice src/jdk.incubator.vector/windows/native/libsvml/globals_vectorApiSupport_windows.S.inc contains a refence in comments to that file, I presume i can remove that comment too? Yes, that comment can also be removed. It is a leftover from when svml was built as part of libjvm.so. >> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte128Vector.java line 278: >> >>> 276: @Override >>> 277: @ForceInline >>> 278: public Byte128Vector lanewise(Unary op, VectorMask m) { >> >> Should this method be final as well? > > It's actually redundant because the class is final. Better to drop final from all declarations, at the risk of creating a larger diff. Got it. I am ok with leaving things as is if it makes it easier. ------------- PR: https://git.openjdk.java.net/jdk/pull/5873 From psandoz at openjdk.java.net Tue Oct 19 20:21:55 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Tue, 19 Oct 2021 20:21:55 GMT Subject: RFR: 8271515: Integration of JEP 417: Vector API (Third Incubator) [v3] In-Reply-To: References: <_QQ9ntdJJfzVcAGrbjev0ZM-xNfD4wNATphnXkb-Y00=.bbf46985-8776-4dda-ada5-b15ab50774aa@github.com> <5Vyao27ssAe8dot0Z6Epc3KlRi57Aaf8j3UdroTSbFU=.1aae99e3-de3c-49b2-a14b-88fa24e9779b@github.com> Message-ID: On Tue, 19 Oct 2021 18:57:59 GMT, Sandhya Viswanathan wrote: >> It's actually redundant because the class is final. Better to drop final from all declarations, at the risk of creating a larger diff. > > Got it. I am ok with leaving things as is if it makes it easier. For now to reduce changes in this PR i would prefer to do a follow cleanup for code consistency for that and for `final` methods. ------------- PR: https://git.openjdk.java.net/jdk/pull/5873 From duke at openjdk.java.net Tue Oct 19 20:34:55 2021 From: duke at openjdk.java.net (Vamsi Parasa) Date: Tue, 19 Oct 2021 20:34:55 GMT Subject: RFR: 8275167: x86 intrinsic for unsignedMultiplyHigh [v2] In-Reply-To: <7IzrZdL0elgXbuisyLNYC2wkyOTe1RHUPuGRI7YsAQ4=.aed9dea3-4775-4592-b43e-c3e08e167f90@github.com> References: <7IzrZdL0elgXbuisyLNYC2wkyOTe1RHUPuGRI7YsAQ4=.aed9dea3-4775-4592-b43e-c3e08e167f90@github.com> Message-ID: > Optimize the new Math.unsignedMultiplyHigh using the x86 mul instruction. This change show 1.87X improvement on a micro benchmark. Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision: refactoring to remove code duplication by using a common routine for UMulHiLNode and MulHiLNode ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5933/files - new: https://git.openjdk.java.net/jdk/pull/5933/files/cb30b268..a10a9fbe Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5933&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5933&range=00-01 Stats: 25 lines in 2 files changed: 12 ins; 12 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5933.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5933/head:pull/5933 PR: https://git.openjdk.java.net/jdk/pull/5933 From duke at openjdk.java.net Tue Oct 19 20:35:03 2021 From: duke at openjdk.java.net (Vamsi Parasa) Date: Tue, 19 Oct 2021 20:35:03 GMT Subject: RFR: 8275167: x86 intrinsic for unsignedMultiplyHigh [v2] In-Reply-To: References: <7IzrZdL0elgXbuisyLNYC2wkyOTe1RHUPuGRI7YsAQ4=.aed9dea3-4775-4592-b43e-c3e08e167f90@github.com> <8MuiklM5Nt3VkzyVHbWqwMh_LkVvVY2Mf65_0zTx4Kw=.9351008f-b489-4103-be9d-87e6fc4a8f39@github.com> Message-ID: <5AqWGf-saY2vk4Z14pSF25waVdcU0j06jW3aSUH76dg=.bba122ee-cf23-44be-bdbc-8bf54b4a6b71@github.com> On Fri, 15 Oct 2021 21:04:12 GMT, Vamsi Parasa wrote: > > > How you verified correctness of results? I suggest to extend `test/jdk//java/lang/Math/MultiplicationTests.java` test to cover unsigned method. > > > > > > Tests for unsignedMultiplyHigh were already added in test/jdk//java/lang/Math/MultiplicationTests.java (in July 2021 by Brian Burkhalter). Used that test to verify the correctness of the results. > > Good. It seems I have old version of the test. Did you run it with -Xcomp? How you verified that intrinsic is used? I have verified that the intrinsic is being used by looking at the x86 assembly code generated by using perfasm profiler. ------------- PR: https://git.openjdk.java.net/jdk/pull/5933 From duke at openjdk.java.net Tue Oct 19 20:35:17 2021 From: duke at openjdk.java.net (Vamsi Parasa) Date: Tue, 19 Oct 2021 20:35:17 GMT Subject: RFR: 8275167: x86 intrinsic for unsignedMultiplyHigh [v2] In-Reply-To: References: <7IzrZdL0elgXbuisyLNYC2wkyOTe1RHUPuGRI7YsAQ4=.aed9dea3-4775-4592-b43e-c3e08e167f90@github.com> Message-ID: On Fri, 15 Oct 2021 19:31:24 GMT, Vamsi Parasa wrote: >> src/hotspot/share/opto/mulnode.cpp line 468: >> >>> 466: } >>> 467: >>> 468: //============================================================================= >> >> MulHiLNode::Value() and UMulHiLNode::Value() seem to be identical. Perhaps some refactoring would be in order, maybe make a common shared routine. > > Sure, will do the refactoring to use a shared routine. Pushed the refactored code to use a common routine for MulHiLNode::Value() and UMulHiLNode::Value(). Please review... ------------- PR: https://git.openjdk.java.net/jdk/pull/5933 From duke at openjdk.java.net Tue Oct 19 20:35:26 2021 From: duke at openjdk.java.net (Vamsi Parasa) Date: Tue, 19 Oct 2021 20:35:26 GMT Subject: Withdrawn: 8275167: x86 intrinsic for unsignedMultiplyHigh In-Reply-To: <7IzrZdL0elgXbuisyLNYC2wkyOTe1RHUPuGRI7YsAQ4=.aed9dea3-4775-4592-b43e-c3e08e167f90@github.com> References: <7IzrZdL0elgXbuisyLNYC2wkyOTe1RHUPuGRI7YsAQ4=.aed9dea3-4775-4592-b43e-c3e08e167f90@github.com> Message-ID: <0g7B5EoV8DdxjVj7jQpJJD7aAjvqbr_M0rl2GyA9ing=.0a6e9bdb-7eab-4fbf-911a-6db783b6882b@github.com> On Wed, 13 Oct 2021 18:55:10 GMT, Vamsi Parasa wrote: > Optimize the new Math.unsignedMultiplyHigh using the x86 mul instruction. This change show 1.87X improvement on a micro benchmark. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/5933 From sviswanathan at openjdk.java.net Tue Oct 19 20:45:35 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Tue, 19 Oct 2021 20:45:35 GMT Subject: RFR: 8271515: Integration of JEP 417: Vector API (Third Incubator) [v3] In-Reply-To: <5Vyao27ssAe8dot0Z6Epc3KlRi57Aaf8j3UdroTSbFU=.1aae99e3-de3c-49b2-a14b-88fa24e9779b@github.com> References: <_QQ9ntdJJfzVcAGrbjev0ZM-xNfD4wNATphnXkb-Y00=.bbf46985-8776-4dda-ada5-b15ab50774aa@github.com> <5Vyao27ssAe8dot0Z6Epc3KlRi57Aaf8j3UdroTSbFU=.1aae99e3-de3c-49b2-a14b-88fa24e9779b@github.com> Message-ID: On Tue, 19 Oct 2021 19:51:54 GMT, Paul Sandoz wrote: >> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java line 603: >> >>> 601: if (opKind(op, VO_SPECIAL)) { >>> 602: if (op == ZOMO) { >>> 603: return blend(broadcast(-1), compare(NE, 0, m)); >> >> This doesn't look correct. The lanes where mask is false should get the original lane value in this vector. > > That should work, since `compare(NE, 0, m) === compare(NE, 0).and(m)`, so when an `m` lane is unset the lane element of `this` vector will be selected. > > Running jshell against a build of PR: > > $ ~/Projects/jdk/jdk/build/macosx-x86_64-server-release/images/jdk/bin/jshell --add-modules jdk.incubator.vector > | Welcome to JShell -- Version 18-internal > | For an introduction type: /help intro > > jshell> import jdk.incubator.vector.* > > jshell> var s = IntVector.SPECIES_256; > s ==> Species[int, 8, S_256_BIT] > > jshell> var v = IntVector.fromArray(s, new int[]{0, 1, 0, -2, 0, 3, 0, -4}, 0); > v ==> [0, 1, 0, -2, 0, 3, 0, -4] > > jshell> var z = v.lanewise(VectorOperators.ZOMO); > z ==> [0, -1, 0, -1, 0, -1, 0, -1] > > jshell> z = v.lanewise(VectorOperators.ZOMO, s.loadMask(new boolean[]{false, false, false, false, true, true, true, true}, 0)); > z ==> [0, 1, 0, -2, 0, -1, 0, -1] > > jshell> Yes, you are correct. There is no problem here. ------------- PR: https://git.openjdk.java.net/jdk/pull/5873 From jjg at openjdk.java.net Tue Oct 19 20:45:40 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 19 Oct 2021 20:45:40 GMT Subject: RFR: 8275512: Upgrade required version of jtreg to 6.1 [v2] In-Reply-To: References: <8ZF_bktOd9u8s06pS5q_VfPnDplwwjhlpz8pdLyHnvw=.67c1b571-5f34-4251-9872-34ccb89dbd5a@github.com> Message-ID: On Tue, 19 Oct 2021 17:24:17 GMT, Weijun Wang wrote: >> As a follow up of JEP 411, we will soon disallow security manager by default. jtreg 6.1 does not set its own security manager if JDK version is >= 18. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > upgrade the version in GHA config > > only in patch2: > unchanged: Marked as reviewed by jjg (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6012 From mchung at openjdk.java.net Tue Oct 19 20:54:09 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 19 Oct 2021 20:54:09 GMT Subject: RFR: 8275512: Upgrade required version of jtreg to 6.1 [v2] In-Reply-To: References: <8ZF_bktOd9u8s06pS5q_VfPnDplwwjhlpz8pdLyHnvw=.67c1b571-5f34-4251-9872-34ccb89dbd5a@github.com> Message-ID: On Tue, 19 Oct 2021 17:24:17 GMT, Weijun Wang wrote: >> As a follow up of JEP 411, we will soon disallow security manager by default. jtreg 6.1 does not set its own security manager if JDK version is >= 18. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > upgrade the version in GHA config > > only in patch2: > unchanged: Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6012 From weijun at openjdk.java.net Tue Oct 19 21:09:22 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 19 Oct 2021 21:09:22 GMT Subject: Integrated: 8275512: Upgrade required version of jtreg to 6.1 In-Reply-To: <8ZF_bktOd9u8s06pS5q_VfPnDplwwjhlpz8pdLyHnvw=.67c1b571-5f34-4251-9872-34ccb89dbd5a@github.com> References: <8ZF_bktOd9u8s06pS5q_VfPnDplwwjhlpz8pdLyHnvw=.67c1b571-5f34-4251-9872-34ccb89dbd5a@github.com> Message-ID: On Tue, 19 Oct 2021 13:51:45 GMT, Weijun Wang wrote: > As a follow up of JEP 411, we will soon disallow security manager by default. jtreg 6.1 does not set its own security manager if JDK version is >= 18. This pull request has now been integrated. Changeset: c24fb852 Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/c24fb852f20bf0fc2817dfed52ff1609a5bced59 Stats: 8 lines in 7 files changed: 0 ins; 0 del; 8 mod 8275512: Upgrade required version of jtreg to 6.1 Reviewed-by: ihse, iignatyev, joehw, lancea, jjg, mchung ------------- PR: https://git.openjdk.java.net/jdk/pull/6012 From dholmes at openjdk.java.net Tue Oct 19 21:52:07 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 19 Oct 2021 21:52:07 GMT Subject: RFR: 8272614: Unused parameters in MethodHandleNatives linking methods In-Reply-To: References: Message-ID: On Tue, 19 Oct 2021 17:12:16 GMT, Harold Seigel wrote: > Please review this small fix for JDK-8272614 to remove the unused indexInCP argument to linkCallSite() and linkDynamicConstant(). The fix was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-6 on Linux x64. > > Thanks, Harold LGTM! Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6021 From psandoz at openjdk.java.net Tue Oct 19 22:40:41 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Tue, 19 Oct 2021 22:40:41 GMT Subject: RFR: 8271515: Integration of JEP 417: Vector API (Third Incubator) [v4] In-Reply-To: <_QQ9ntdJJfzVcAGrbjev0ZM-xNfD4wNATphnXkb-Y00=.bbf46985-8776-4dda-ada5-b15ab50774aa@github.com> References: <_QQ9ntdJJfzVcAGrbjev0ZM-xNfD4wNATphnXkb-Y00=.bbf46985-8776-4dda-ada5-b15ab50774aa@github.com> Message-ID: > This PR improves the performance of vector operations that accept masks on architectures that support masking in hardware, specifically Intel AVX512 and ARM SVE. > > On architectures that do not support masking in hardware the same technique as before is applied to most operations, specifically composition using blend. > > Masked loads/stores are a special form of masked operation that require additional care to ensure out-of-bounds access throw exceptions. The range checking has not been fully optimized and will require further work. > > No API enhancements were required and only a few additional tests were needed. Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision: Resolve review comments. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5873/files - new: https://git.openjdk.java.net/jdk/pull/5873/files/32d58f17..101cd23a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5873&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5873&range=02-03 Stats: 50 lines in 4 files changed: 1 ins; 49 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5873.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5873/head:pull/5873 PR: https://git.openjdk.java.net/jdk/pull/5873 From sviswanathan at openjdk.java.net Tue Oct 19 22:40:44 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Tue, 19 Oct 2021 22:40:44 GMT Subject: RFR: 8271515: Integration of JEP 417: Vector API (Third Incubator) [v4] In-Reply-To: References: <_QQ9ntdJJfzVcAGrbjev0ZM-xNfD4wNATphnXkb-Y00=.bbf46985-8776-4dda-ada5-b15ab50774aa@github.com> Message-ID: On Tue, 19 Oct 2021 22:37:10 GMT, Paul Sandoz wrote: >> This PR improves the performance of vector operations that accept masks on architectures that support masking in hardware, specifically Intel AVX512 and ARM SVE. >> >> On architectures that do not support masking in hardware the same technique as before is applied to most operations, specifically composition using blend. >> >> Masked loads/stores are a special form of masked operation that require additional care to ensure out-of-bounds access throw exceptions. The range checking has not been fully optimized and will require further work. >> >> No API enhancements were required and only a few additional tests were needed. > > Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision: > > Resolve review comments. Marked as reviewed by sviswanathan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5873 From sviswanathan at openjdk.java.net Tue Oct 19 22:40:49 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Tue, 19 Oct 2021 22:40:49 GMT Subject: RFR: 8271515: Integration of JEP 417: Vector API (Third Incubator) [v3] In-Reply-To: References: <_QQ9ntdJJfzVcAGrbjev0ZM-xNfD4wNATphnXkb-Y00=.bbf46985-8776-4dda-ada5-b15ab50774aa@github.com> Message-ID: <3_mnZHJQE6OzJrloA48Fj6hlOu1plIUnHlWRPFpkc70=.e2d80d75-0bb5-4e48-a8da-80ddee06ffd5@github.com> On Sat, 16 Oct 2021 00:56:14 GMT, Paul Sandoz wrote: >> This PR improves the performance of vector operations that accept masks on architectures that support masking in hardware, specifically Intel AVX512 and ARM SVE. >> >> On architectures that do not support masking in hardware the same technique as before is applied to most operations, specifically composition using blend. >> >> Masked loads/stores are a special form of masked operation that require additional care to ensure out-of-bounds access throw exceptions. The range checking has not been fully optimized and will require further work. >> >> No API enhancements were required and only a few additional tests were needed. > > Paul Sandoz 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 JDK-8271515-vector-api > - Apply patch from https://github.com/openjdk/panama-vector/pull/152 > - Apply patch from https://github.com/openjdk/panama-vector/pull/142 > - Apply patch from https://github.com/openjdk/panama-vector/pull/139 > - Apply patch from https://github.com/openjdk/panama-vector/pull/151 > - Add new files. > - 8271515: Integration of JEP 417: Vector API (Third Incubator) The Java changes look good to me. src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMask.java line 574: > 572: * @throws ClassCastException if the species is wrong > 573: */ > 574: abstract VectorMask check(Class> maskClass, Vector vector); This is a package-private method so the java doc style comments are not needed here. ------------- PR: https://git.openjdk.java.net/jdk/pull/5873 From psandoz at openjdk.java.net Tue Oct 19 22:40:52 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Tue, 19 Oct 2021 22:40:52 GMT Subject: RFR: 8271515: Integration of JEP 417: Vector API (Third Incubator) [v3] In-Reply-To: <3_mnZHJQE6OzJrloA48Fj6hlOu1plIUnHlWRPFpkc70=.e2d80d75-0bb5-4e48-a8da-80ddee06ffd5@github.com> References: <_QQ9ntdJJfzVcAGrbjev0ZM-xNfD4wNATphnXkb-Y00=.bbf46985-8776-4dda-ada5-b15ab50774aa@github.com> <3_mnZHJQE6OzJrloA48Fj6hlOu1plIUnHlWRPFpkc70=.e2d80d75-0bb5-4e48-a8da-80ddee06ffd5@github.com> Message-ID: <9jOILX8e6SyWk4LEd68IYSh_S9KRCaUwrz8GUIqO5VY=.18090bd3-c5de-4995-a8bd-b97fd2ed8fea@github.com> On Tue, 19 Oct 2021 21:14:08 GMT, Sandhya Viswanathan wrote: >> Paul Sandoz 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 JDK-8271515-vector-api >> - Apply patch from https://github.com/openjdk/panama-vector/pull/152 >> - Apply patch from https://github.com/openjdk/panama-vector/pull/142 >> - Apply patch from https://github.com/openjdk/panama-vector/pull/139 >> - Apply patch from https://github.com/openjdk/panama-vector/pull/151 >> - Add new files. >> - 8271515: Integration of JEP 417: Vector API (Third Incubator) > > src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMask.java line 574: > >> 572: * @throws ClassCastException if the species is wrong >> 573: */ >> 574: abstract VectorMask check(Class> maskClass, Vector vector); > > This is a package-private method so the java doc style comments are not needed here. I think that is fine, documentation for us :-) I converted to package private since it only really makes sense for internal use right now. ------------- PR: https://git.openjdk.java.net/jdk/pull/5873 From sviswanathan at openjdk.java.net Tue Oct 19 22:40:53 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Tue, 19 Oct 2021 22:40:53 GMT Subject: RFR: 8271515: Integration of JEP 417: Vector API (Third Incubator) [v3] In-Reply-To: <9jOILX8e6SyWk4LEd68IYSh_S9KRCaUwrz8GUIqO5VY=.18090bd3-c5de-4995-a8bd-b97fd2ed8fea@github.com> References: <_QQ9ntdJJfzVcAGrbjev0ZM-xNfD4wNATphnXkb-Y00=.bbf46985-8776-4dda-ada5-b15ab50774aa@github.com> <3_mnZHJQE6OzJrloA48Fj6hlOu1plIUnHlWRPFpkc70=.e2d80d75-0bb5-4e48-a8da-80ddee06ffd5@github.com> <9jOILX8e6SyWk4LEd68IYSh_S9KRCaUwrz8GUIqO5VY=.18090bd3-c5de-4995-a8bd-b97fd2ed8fea@github.com> Message-ID: On Tue, 19 Oct 2021 22:34:13 GMT, Paul Sandoz wrote: >> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMask.java line 574: >> >>> 572: * @throws ClassCastException if the species is wrong >>> 573: */ >>> 574: abstract VectorMask check(Class> maskClass, Vector vector); >> >> This is a package-private method so the java doc style comments are not needed here. > > I think that is fine, documentation for us :-) I converted to package private since it only really makes sense for internal use right now. Sounds good. ------------- PR: https://git.openjdk.java.net/jdk/pull/5873 From lancea at openjdk.java.net Tue Oct 19 22:47:08 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 19 Oct 2021 22:47:08 GMT Subject: RFR: 8153490: Cannot setBytes() if incoming buffer's length is bigger than number of elements we want to insert. [v5] In-Reply-To: <77FFslCAcaAsUso2PU1eIEwdGJ6ZmnJVMyC34AhOgXg=.5570b0c4-204b-4f36-9905-a808c02d0096@github.com> References: <4MzAaDkmgdWxj_kxwdy7hq3I4jPQV39QX_Qg22TSjiI=.ff6a346a-4000-4cee-b50c-649a6a42ef14@github.com> <77FFslCAcaAsUso2PU1eIEwdGJ6ZmnJVMyC34AhOgXg=.5570b0c4-204b-4f36-9905-a808c02d0096@github.com> Message-ID: <0o4tWFzMGrK2s8gxx3V9eIbBcYIUxtIVXWqMRw6GJoo=.f5f22694-9788-433e-a3a5-c06805069770@github.com> On Tue, 19 Oct 2021 06:32:57 GMT, Mitsuru Kariya wrote: > The pre-submit test seems to have failed because the compiler was not found in some environments. > Should I take any action? > Or should I issue the /integrate pull request command? You should be OK. Just as an extra sanity check, I will run those tiers internally tomorrow so please stay tuned ------------- PR: https://git.openjdk.java.net/jdk/pull/4001 From psandoz at openjdk.java.net Wed Oct 20 00:22:30 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 20 Oct 2021 00:22:30 GMT Subject: RFR: 8271515: Integration of JEP 417: Vector API (Third Incubator) [v5] In-Reply-To: <_QQ9ntdJJfzVcAGrbjev0ZM-xNfD4wNATphnXkb-Y00=.bbf46985-8776-4dda-ada5-b15ab50774aa@github.com> References: <_QQ9ntdJJfzVcAGrbjev0ZM-xNfD4wNATphnXkb-Y00=.bbf46985-8776-4dda-ada5-b15ab50774aa@github.com> Message-ID: > This PR improves the performance of vector operations that accept masks on architectures that support masking in hardware, specifically Intel AVX512 and ARM SVE. > > On architectures that do not support masking in hardware the same technique as before is applied to most operations, specifically composition using blend. > > Masked loads/stores are a special form of masked operation that require additional care to ensure out-of-bounds access throw exceptions. The range checking has not been fully optimized and will require further work. > > No API enhancements were required and only a few additional tests were needed. Paul Sandoz has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: - Merge branch 'master' into JDK-8271515-vector-api - Resolve review comments. - Merge branch 'master' into JDK-8271515-vector-api - Apply patch from https://github.com/openjdk/panama-vector/pull/152 - Apply patch from https://github.com/openjdk/panama-vector/pull/142 - Apply patch from https://github.com/openjdk/panama-vector/pull/139 - Apply patch from https://github.com/openjdk/panama-vector/pull/151 - Add new files. - 8271515: Integration of JEP 417: Vector API (Third Incubator) ------------- Changes: https://git.openjdk.java.net/jdk/pull/5873/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5873&range=04 Stats: 21956 lines in 105 files changed: 16182 ins; 2080 del; 3694 mod Patch: https://git.openjdk.java.net/jdk/pull/5873.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5873/head:pull/5873 PR: https://git.openjdk.java.net/jdk/pull/5873 From ngasson at openjdk.java.net Wed Oct 20 03:16:12 2021 From: ngasson at openjdk.java.net (Nick Gasson) Date: Wed, 20 Oct 2021 03:16:12 GMT Subject: RFR: 8271515: Integration of JEP 417: Vector API (Third Incubator) [v5] In-Reply-To: References: <_QQ9ntdJJfzVcAGrbjev0ZM-xNfD4wNATphnXkb-Y00=.bbf46985-8776-4dda-ada5-b15ab50774aa@github.com> Message-ID: On Wed, 20 Oct 2021 00:22:30 GMT, Paul Sandoz wrote: >> This PR improves the performance of vector operations that accept masks on architectures that support masking in hardware, specifically Intel AVX512 and ARM SVE. >> >> On architectures that do not support masking in hardware the same technique as before is applied to most operations, specifically composition using blend. >> >> Masked loads/stores are a special form of masked operation that require additional care to ensure out-of-bounds access throw exceptions. The range checking has not been fully optimized and will require further work. >> >> No API enhancements were required and only a few additional tests were needed. > > Paul Sandoz has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: > > - Merge branch 'master' into JDK-8271515-vector-api > - Resolve review comments. > - Merge branch 'master' into JDK-8271515-vector-api > - Apply patch from https://github.com/openjdk/panama-vector/pull/152 > - Apply patch from https://github.com/openjdk/panama-vector/pull/142 > - Apply patch from https://github.com/openjdk/panama-vector/pull/139 > - Apply patch from https://github.com/openjdk/panama-vector/pull/151 > - Add new files. > - 8271515: Integration of JEP 417: Vector API (Third Incubator) AArch64 changes look ok apart from some minor comments. src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 2057: > 2055: > 2056: const int num_of_regs = PRegisterImpl::number_of_saved_registers; > 2057: unsigned char regs[num_of_regs]; Seems clearer to use `PRegisterImpl::number_of_saved_registers` directly rather than introducing `num_of_regs`. src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 2078: > 2076: } > 2077: > 2078: // Return the number of dwords poped popped src/hotspot/cpu/aarch64/register_aarch64.hpp line 248: > 246: // AArch64 has 8 governing predicate registers, but p7 is used as an > 247: // all-1s register so the predicates to save are from p0 to p6 if we > 248: // don't have non-governing predicate registers support. This comment is a bit difficult to read. How about: // AArch64 has 8 governing predicate registers, but p7 is used as an // all-1s register so the predicates to save are from p0 to p6. We // don't support non-governing predicate registers. src/hotspot/cpu/aarch64/vmreg_aarch64.hpp line 42: > 40: > 41: inline Register as_Register() { > 42: assert(is_Register(), "must be"); I think it's better to leave this file as it was if you're only making whitespace changes here. ------------- Marked as reviewed by ngasson (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5873 From lzhai at openjdk.java.net Wed Oct 20 09:31:10 2021 From: lzhai at openjdk.java.net (Leslie Zhai) Date: Wed, 20 Oct 2021 09:31:10 GMT Subject: RFR: 8275512: Upgrade required version of jtreg to 6.1 [v2] In-Reply-To: References: <8ZF_bktOd9u8s06pS5q_VfPnDplwwjhlpz8pdLyHnvw=.67c1b571-5f34-4251-9872-34ccb89dbd5a@github.com> Message-ID: On Tue, 19 Oct 2021 17:24:17 GMT, Weijun Wang wrote: >> As a follow up of JEP 411, we will soon disallow security manager by default. jtreg 6.1 does not set its own security manager if JDK version is >= 18. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > upgrade the version in GHA config > > only in patch2: > unchanged: Hi @wangweij But how to be suitable for jtreg version 6-dev+0? Running tests using JTREG control variable 'VM_OPTIONS=-XX:+UseZGC;TIMEOUT_FACTOR=20;VERBOSE=summary' Test selection 'tier1', will run: * jtreg:test/hotspot/jtreg:tier1 * jtreg:test/jdk:tier1 * jtreg:test/langtools:tier1 * jtreg:test/jaxp:tier1 * jtreg:test/lib-test:tier1 Running test 'jtreg:test/hotspot/jtreg:tier1' Error: The testsuite at /var/lib/jenkins/repos/openjdk/jdk/test/hotspot/jtreg requires jtreg version 6.1 b1 or higher and this is jtreg version 6-dev+0. Thanks, Leslie Zhai ------------- PR: https://git.openjdk.java.net/jdk/pull/6012 From ihse at openjdk.java.net Wed Oct 20 10:33:12 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 20 Oct 2021 10:33:12 GMT Subject: RFR: 8275512: Upgrade required version of jtreg to 6.1 [v2] In-Reply-To: References: <8ZF_bktOd9u8s06pS5q_VfPnDplwwjhlpz8pdLyHnvw=.67c1b571-5f34-4251-9872-34ccb89dbd5a@github.com> Message-ID: <3fR1ogAG0CXuhf9_gJZrD-GGi9RqG_lP5bGD7fd_GPY=.2ed9d3b9-3b80-4300-a90f-6d5fe954d945@github.com> On Wed, 20 Oct 2021 09:28:30 GMT, Leslie Zhai wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> upgrade the version in GHA config >> >> only in patch2: >> unchanged: > > Hi @wangweij > > But how to be suitable for jtreg version 6-dev+0? > > > Running tests using JTREG control variable 'VM_OPTIONS=-XX:+UseZGC;TIMEOUT_FACTOR=20;VERBOSE=summary' > Test selection 'tier1', will run: > * jtreg:test/hotspot/jtreg:tier1 > * jtreg:test/jdk:tier1 > * jtreg:test/langtools:tier1 > * jtreg:test/jaxp:tier1 > * jtreg:test/lib-test:tier1 > > Running test 'jtreg:test/hotspot/jtreg:tier1' > Error: The testsuite at /var/lib/jenkins/repos/openjdk/jdk/test/hotspot/jtreg requires jtreg version 6.1 b1 or higher and this is jtreg version 6-dev+0. > > > Thanks, > Leslie Zhai @xiangzhai The entire point of this PR is to *not* allow jtreg 6.0. You need to upgrade your local jtreg installation to 6.1. ------------- PR: https://git.openjdk.java.net/jdk/pull/6012 From mcimadamore at openjdk.java.net Wed Oct 20 11:14:19 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 20 Oct 2021 11:14:19 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v7] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/419 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Fix failing microbenchmarks. Contributed by @FrauBoes (thanks!) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5907/files - new: https://git.openjdk.java.net/jdk/pull/5907/files/a4db81fe..52189683 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=05-06 Stats: 39 lines in 9 files changed: 1 ins; 10 del; 28 mod Patch: https://git.openjdk.java.net/jdk/pull/5907.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5907/head:pull/5907 PR: https://git.openjdk.java.net/jdk/pull/5907 From aefimov at openjdk.java.net Wed Oct 20 11:52:38 2021 From: aefimov at openjdk.java.net (Aleksei Efimov) Date: Wed, 20 Oct 2021 11:52:38 GMT Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v5] In-Reply-To: References: Message-ID: > This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver. > > The following API classes are added to `java.net.spi` package to facilitate this: > - `InetAddressResolverProvider` - abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers. > - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations. > - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations. > - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation. > > More details in [JEP-418](https://openjdk.java.net/jeps/418). > > Testing: new and existing `tier1:tier3` tests Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision: Change InetAddressResolver method names ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5822/files - new: https://git.openjdk.java.net/jdk/pull/5822/files/ac0d2184..30226481 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5822&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5822&range=03-04 Stats: 33 lines in 9 files changed: 0 ins; 0 del; 33 mod Patch: https://git.openjdk.java.net/jdk/pull/5822.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5822/head:pull/5822 PR: https://git.openjdk.java.net/jdk/pull/5822 From aefimov at openjdk.java.net Wed Oct 20 11:52:40 2021 From: aefimov at openjdk.java.net (Aleksei Efimov) Date: Wed, 20 Oct 2021 11:52:40 GMT Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v3] In-Reply-To: References: <0Xvj7H_JyjEfXTUr1GI3ooLL1cGBuWLDAtrP83WuQV0=.7e172d30-620d-4ce1-9bac-62db6dc19e52@github.com> Message-ID: On Sun, 17 Oct 2021 21:03:56 GMT, Mark Sheppard wrote: > getByName requires a hostname lookup and getByAdress requires (eventually - I know the docs says there?s no reverse lookup) an address reverse lookup. Thus, a logical mapping is getByName ?> lookupHostname, and getByAddr ?> lookupAddress, but the opposite will occur getByName --> lookupAddresses and getByAddress --> lookupHostname. Therfore I proffer maps neatly to rename methods to resolveHostname and resolveAddress such that the mapping are getByName --> resolveHostname and getByAddress --> resolveAddress. Thank you, Mark, for highlighting the naming contradiction in the `InetAddressResolver` interface method names. It can be solved by making these names symmetrical to `InetAddress` API. In 302264810725f86a4569161754f7b052c78fd826 `InetAddressResolver` method names have been updated to stress input parameters type, which brings them in sync with `InetAddress` API: - `InetAddressResolver.lookupAddresses` is renamed to `InetAddressResolver.lookupByName` - `InetAddressResolver.lookupHostName` is renamed to `InetAddressResolver.lookupByAddress` ------------- PR: https://git.openjdk.java.net/jdk/pull/5822 From rriggs at openjdk.java.net Wed Oct 20 13:36:08 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 20 Oct 2021 13:36:08 GMT Subject: RFR: 8268595: java/io/Serializable/serialFilter/GlobalFilterTest.java#id1 failed in timeout In-Reply-To: <3utjHiAKf2SmUTuhFh4-9YTk476V2OggSFiIK5mFzj0=.96dcbfb3-8746-477e-8c25-c586cd1f0cc6@github.com> References: <3utjHiAKf2SmUTuhFh4-9YTk476V2OggSFiIK5mFzj0=.96dcbfb3-8746-477e-8c25-c586cd1f0cc6@github.com> Message-ID: On Tue, 19 Oct 2021 13:00:01 GMT, Jaikiran Pai wrote: > The `GlobalFilterTest` has to 2 `@test` tags. One of them has failed with a timeout as noted in https://bugs.openjdk.java.net/browse/JDK-8268595. The timeout seems to have happened even after the tests had already completed successfully. Like I note in the JBS comments of that issue, I suspect it might have to do with the "-XX:StartFlightRecording:name=DeserializationEvent,dumponexit=true" usage in this test action. > > The commit in this PR removes that second `@test` altogether because (correct me if I'm wrong) from what I understand, this test never enables the DeserializationEvent which means there is no JFR events being captured for deserialization in this test, nor does the test do any JFR events related testing. So, I think this second `@test` is virtually a no-op when it comes to the JFR testing. There's a separate `TestDeserializationEvent` which has a comprehensive testing of the DeserializationEvent. @chegar Please comment on this change. The purpose of the second test group is not clear. Thanks ------------- PR: https://git.openjdk.java.net/jdk/pull/6008 From rriggs at openjdk.java.net Wed Oct 20 13:38:09 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 20 Oct 2021 13:38:09 GMT Subject: RFR: 8269336: Malformed jdk.serialFilter incorrectly handled [v2] In-Reply-To: References: Message-ID: <1UC35QiJHs68xKYUp7BMSWUVYonxgNuZKmn7ysTxs8I=.0cc275f4-8ef5-4149-ade0-95f620445940@github.com> On Tue, 19 Oct 2021 14:22:26 GMT, Jaikiran Pai wrote: >> Can I please get a review for this change which addresses https://bugs.openjdk.java.net/browse/JDK-8269336? >> >> As noted in that issue, this change will now propagate any exception that occurred during parsing and creation of the filter configured through the `jdk.serialFilter` system property. It will also continue to log those errors, like it previously did. >> >> A new jtreg test has been introduced to reproduce this issue and verify the fix. >> >> Given that invalid values for this system property will now start throwing exception, will this change need a CSR? > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Roger's review suggestion - rethrow the RuntimeException instead of wrapping in ExceptionInInitializerError LGTM ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5988 From mbalao at openjdk.java.net Wed Oct 20 13:49:19 2021 From: mbalao at openjdk.java.net (Martin Balao) Date: Wed, 20 Oct 2021 13:49:19 GMT Subject: RFR: 8275535: Retrying a failed authentication on multiple LDAP servers can lead to users blocked Message-ID: I'd like to propose a fix for JDK-8275535. This fix reverts the behavior to the state previous to JDK-8160768, where an authentication failure stops from trying other LDAP servers with the same credentials [1]. After JDK-8160768 we have 2 possible loops to stop: the one that iterates over different URLs and the one that iterates over different endpoints (after a DNS query that returns multiple values). No test regressions observed in jdk/com/sun/jndi/ldap. -- [1] - https://hg.openjdk.java.net/jdk/jdk/rev/a609d549992a#l2.137 ------------- Commit messages: - Initial commit for JDK-8275535. Changes: https://git.openjdk.java.net/jdk/pull/6043/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6043&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275535 Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6043.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6043/head:pull/6043 PR: https://git.openjdk.java.net/jdk/pull/6043 From mcimadamore at openjdk.java.net Wed Oct 20 14:00:30 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 20 Oct 2021 14:00:30 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v8] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/419 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Fix copyright header in TestArrayCopy ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5907/files - new: https://git.openjdk.java.net/jdk/pull/5907/files/52189683..414952ad Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=06-07 Stats: 16 lines in 1 file changed: 0 ins; 0 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/5907.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5907/head:pull/5907 PR: https://git.openjdk.java.net/jdk/pull/5907 From jpai at openjdk.java.net Wed Oct 20 15:15:13 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Wed, 20 Oct 2021 15:15:13 GMT Subject: RFR: 8269336: Malformed jdk.serialFilter incorrectly handled [v2] In-Reply-To: References: Message-ID: On Tue, 19 Oct 2021 14:22:26 GMT, Jaikiran Pai wrote: >> Can I please get a review for this change which addresses https://bugs.openjdk.java.net/browse/JDK-8269336? >> >> As noted in that issue, this change will now propagate any exception that occurred during parsing and creation of the filter configured through the `jdk.serialFilter` system property. It will also continue to log those errors, like it previously did. >> >> A new jtreg test has been introduced to reproduce this issue and verify the fix. >> >> Given that invalid values for this system property will now start throwing exception, will this change need a CSR? > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Roger's review suggestion - rethrow the RuntimeException instead of wrapping in ExceptionInInitializerError Thank you Roger for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/5988 From jpai at openjdk.java.net Wed Oct 20 15:15:15 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Wed, 20 Oct 2021 15:15:15 GMT Subject: Integrated: 8269336: Malformed jdk.serialFilter incorrectly handled In-Reply-To: References: Message-ID: <-pA9grn29T1AfhT2J2fWy8zqCcOl6-PuoIeMFoNcFMM=.d2f6a4cd-8101-4ad0-91b5-8cc62fedbf1a@github.com> On Mon, 18 Oct 2021 13:44:56 GMT, Jaikiran Pai wrote: > Can I please get a review for this change which addresses https://bugs.openjdk.java.net/browse/JDK-8269336? > > As noted in that issue, this change will now propagate any exception that occurred during parsing and creation of the filter configured through the `jdk.serialFilter` system property. It will also continue to log those errors, like it previously did. > > A new jtreg test has been introduced to reproduce this issue and verify the fix. > > Given that invalid values for this system property will now start throwing exception, will this change need a CSR? This pull request has now been integrated. Changeset: 35e5bb5f Author: Jaikiran Pai URL: https://git.openjdk.java.net/jdk/commit/35e5bb5f59c01a1b07893780fa73f93c2abab653 Stats: 90 lines in 2 files changed: 89 ins; 0 del; 1 mod 8269336: Malformed jdk.serialFilter incorrectly handled Reviewed-by: rriggs ------------- PR: https://git.openjdk.java.net/jdk/pull/5988 From psandoz at openjdk.java.net Wed Oct 20 15:28:34 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 20 Oct 2021 15:28:34 GMT Subject: RFR: 8271515: Integration of JEP 417: Vector API (Third Incubator) [v6] In-Reply-To: <_QQ9ntdJJfzVcAGrbjev0ZM-xNfD4wNATphnXkb-Y00=.bbf46985-8776-4dda-ada5-b15ab50774aa@github.com> References: <_QQ9ntdJJfzVcAGrbjev0ZM-xNfD4wNATphnXkb-Y00=.bbf46985-8776-4dda-ada5-b15ab50774aa@github.com> Message-ID: > This PR improves the performance of vector operations that accept masks on architectures that support masking in hardware, specifically Intel AVX512 and ARM SVE. > > On architectures that do not support masking in hardware the same technique as before is applied to most operations, specifically composition using blend. > > Masked loads/stores are a special form of masked operation that require additional care to ensure out-of-bounds access throw exceptions. The range checking has not been fully optimized and will require further work. > > No API enhancements were required and only a few additional tests were needed. Paul Sandoz has updated the pull request incrementally with two additional commits since the last revision: - Merge pull request #1 from nsjian/JDK-8271515 Address AArch64 review comments from Nick. - Address review comments from Nick. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5873/files - new: https://git.openjdk.java.net/jdk/pull/5873/files/9945ce8d..2919465a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5873&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5873&range=04-05 Stats: 35 lines in 5 files changed: 3 ins; 2 del; 30 mod Patch: https://git.openjdk.java.net/jdk/pull/5873.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5873/head:pull/5873 PR: https://git.openjdk.java.net/jdk/pull/5873 From dfuchs at openjdk.java.net Wed Oct 20 15:45:08 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 20 Oct 2021 15:45:08 GMT Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v5] In-Reply-To: References: Message-ID: On Wed, 20 Oct 2021 11:52:38 GMT, Aleksei Efimov wrote: >> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver. >> >> The following API classes are added to `java.net.spi` package to facilitate this: >> - `InetAddressResolverProvider` - abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers. >> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations. >> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations. >> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation. >> >> More details in [JEP-418](https://openjdk.java.net/jeps/418). >> >> Testing: new and existing `tier1:tier3` tests > > Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision: > > Change InetAddressResolver method names Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5822 From lfoltan at openjdk.java.net Wed Oct 20 15:46:07 2021 From: lfoltan at openjdk.java.net (Lois Foltan) Date: Wed, 20 Oct 2021 15:46:07 GMT Subject: RFR: 8272614: Unused parameters in MethodHandleNatives linking methods In-Reply-To: References: Message-ID: On Tue, 19 Oct 2021 17:12:16 GMT, Harold Seigel wrote: > Please review this small fix for JDK-8272614 to remove the unused indexInCP argument to linkCallSite() and linkDynamicConstant(). The fix was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-6 on Linux x64. > > Thanks, Harold LGTM! ------------- Marked as reviewed by lfoltan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6021 From hseigel at openjdk.java.net Wed Oct 20 15:51:12 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 20 Oct 2021 15:51:12 GMT Subject: Integrated: 8272614: Unused parameters in MethodHandleNatives linking methods In-Reply-To: References: Message-ID: On Tue, 19 Oct 2021 17:12:16 GMT, Harold Seigel wrote: > Please review this small fix for JDK-8272614 to remove the unused indexInCP argument to linkCallSite() and linkDynamicConstant(). The fix was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-6 on Linux x64. > > Thanks, Harold This pull request has now been integrated. Changeset: bbc60611 Author: Harold Seigel URL: https://git.openjdk.java.net/jdk/commit/bbc606117fcd8b48fc8f830c50cf7eb573da1c4c Stats: 8 lines in 3 files changed: 0 ins; 3 del; 5 mod 8272614: Unused parameters in MethodHandleNatives linking methods Reviewed-by: dholmes, lfoltan ------------- PR: https://git.openjdk.java.net/jdk/pull/6021 From hseigel at openjdk.java.net Wed Oct 20 15:51:12 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 20 Oct 2021 15:51:12 GMT Subject: RFR: 8272614: Unused parameters in MethodHandleNatives linking methods In-Reply-To: References: Message-ID: On Tue, 19 Oct 2021 17:12:16 GMT, Harold Seigel wrote: > Please review this small fix for JDK-8272614 to remove the unused indexInCP argument to linkCallSite() and linkDynamicConstant(). The fix was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-6 on Linux x64. > > Thanks, Harold Thanks David and Lois! ------------- PR: https://git.openjdk.java.net/jdk/pull/6021 From isipka at openjdk.java.net Wed Oct 20 17:23:21 2021 From: isipka at openjdk.java.net (Ivan =?UTF-8?B?xaBpcGth?=) Date: Wed, 20 Oct 2021 17:23:21 GMT Subject: RFR: 8275650: Problemlist java/io/File/createTempFile/SpecialTempFile.java for Windows 11 Message-ID: cc @ctornqvi ------------- Commit messages: - 8274122: added to problem list Changes: https://git.openjdk.java.net/jdk/pull/6025/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6025&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275650 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6025.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6025/head:pull/6025 PR: https://git.openjdk.java.net/jdk/pull/6025 From iignatyev at openjdk.java.net Wed Oct 20 17:23:21 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Wed, 20 Oct 2021 17:23:21 GMT Subject: RFR: 8275650: Problemlist java/io/File/createTempFile/SpecialTempFile.java for Windows 11 In-Reply-To: References: Message-ID: On Wed, 20 Oct 2021 00:04:08 GMT, Ivan ?ipka wrote: > cc @ctornqvi Marked as reviewed by iignatyev (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6025 From naoto at openjdk.java.net Wed Oct 20 17:32:22 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 20 Oct 2021 17:32:22 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value Message-ID: During the review of JEP 400, a proposal to provide an overloaded method to `Charset.forName()` was suggested [[1]](https://github.com/openjdk/jdk/pull/4733#discussion_r669693954). This PR is to implement the proposal. A CSR is also drafted as https://bugs.openjdk.java.net/browse/JDK-8275348 ------------- Commit messages: - 8270490: Charset.forName() taking fallback default value Changes: https://git.openjdk.java.net/jdk/pull/6045/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6045&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8270490 Stats: 117 lines in 3 files changed: 115 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/6045.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6045/head:pull/6045 PR: https://git.openjdk.java.net/jdk/pull/6045 From sviswanathan at openjdk.java.net Wed Oct 20 17:36:05 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Wed, 20 Oct 2021 17:36:05 GMT Subject: RFR: 8275167: x86 intrinsic for unsignedMultiplyHigh [v2] In-Reply-To: References: <7IzrZdL0elgXbuisyLNYC2wkyOTe1RHUPuGRI7YsAQ4=.aed9dea3-4775-4592-b43e-c3e08e167f90@github.com> Message-ID: On Tue, 19 Oct 2021 20:34:55 GMT, Vamsi Parasa wrote: >> Optimize the new Math.unsignedMultiplyHigh using the x86 mul instruction. This change show 1.87X improvement on a micro benchmark. > > Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision: > > refactoring to remove code duplication by using a common routine for UMulHiLNode and MulHiLNode Marked as reviewed by sviswanathan (Reviewer). The patch looks good to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/5933 From sviswanathan at openjdk.java.net Wed Oct 20 17:36:06 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Wed, 20 Oct 2021 17:36:06 GMT Subject: RFR: 8275167: x86 intrinsic for unsignedMultiplyHigh [v2] In-Reply-To: <8MuiklM5Nt3VkzyVHbWqwMh_LkVvVY2Mf65_0zTx4Kw=.9351008f-b489-4103-be9d-87e6fc4a8f39@github.com> References: <7IzrZdL0elgXbuisyLNYC2wkyOTe1RHUPuGRI7YsAQ4=.aed9dea3-4775-4592-b43e-c3e08e167f90@github.com> <8MuiklM5Nt3VkzyVHbWqwMh_LkVvVY2Mf65_0zTx4Kw=.9351008f-b489-4103-be9d-87e6fc4a8f39@github.com> Message-ID: On Fri, 15 Oct 2021 20:19:31 GMT, Vladimir Kozlov wrote: >>> How you verified correctness of results? I suggest to extend `test/jdk//java/lang/Math/MultiplicationTests.java` test to cover unsigned method. >> >> Tests for unsignedMultiplyHigh were already added in test/jdk//java/lang/Math/MultiplicationTests.java (in July 2021 by Brian Burkhalter). Used that test to verify the correctness of the results. > >> > How you verified correctness of results? I suggest to extend `test/jdk//java/lang/Math/MultiplicationTests.java` test to cover unsigned method. >> >> Tests for unsignedMultiplyHigh were already added in test/jdk//java/lang/Math/MultiplicationTests.java (in July 2021 by Brian Burkhalter). Used that test to verify the correctness of the results. > > Good. It seems I have old version of the test. > Did you run it with -Xcomp? How you verified that intrinsic is used? @vnkozlov if the patch looks ok to you, could you please run this through your testing? ------------- PR: https://git.openjdk.java.net/jdk/pull/5933 From alanb at openjdk.java.net Wed Oct 20 18:36:20 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 20 Oct 2021 18:36:20 GMT Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v5] In-Reply-To: References: Message-ID: <1v6OpqkyZp6XBq9lXQfahKEEgtBIdPjNWydqJ9Cwipc=.959e01c2-1e2d-4540-8ed5-41198dd71c2b@github.com> On Wed, 20 Oct 2021 11:52:38 GMT, Aleksei Efimov wrote: >> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver. >> >> The following API classes are added to `java.net.spi` package to facilitate this: >> - `InetAddressResolverProvider` - abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers. >> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations. >> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations. >> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation. >> >> More details in [JEP-418](https://openjdk.java.net/jeps/418). >> >> Testing: new and existing `tier1:tier3` tests > > Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision: > > Change InetAddressResolver method names src/java.base/share/classes/java/net/InetAddress.java line 340: > 338: > 339: /* Used to store the system-wide resolver */ > 340: private static volatile InetAddressResolver resolver; Can this be @Stable? src/java.base/share/classes/java/net/spi/InetAddressResolver.java line 34: > 32: > 33: /** > 34: * This interface defines operations for looking-up host names and IP addresses. I think change "looking-up" to "looking up". src/java.base/share/classes/java/net/spi/InetAddressResolver.java line 102: > 100: > 101: /** > 102: * Specifies if IPv4 addresses need to be queried during lookup. It might be better to change this to "Characteristic value signifying ..." rather than "Specifies". src/java.base/share/classes/java/net/spi/InetAddressResolver.java line 186: > 184: > 185: /** > 186: * Returns an integer value which specifies lookup operation characteristics. I think I'd change the first line here to something like "Returns a set of characteristics of this lookup policy". src/java.base/share/classes/java/net/spi/InetAddressResolverProvider.java line 35: > 33: /** > 34: * A resolver provider class is a factory for custom implementations of {@linkplain > 35: * InetAddressResolver resolvers} which define operations for looking-up (resolving) host names This reads "custom implementations of resolvers". It might be better to start with "Service-provider class for InetAddress resolvers". src/java.base/share/classes/java/net/spi/InetAddressResolverProvider.java line 52: > 50: /** > 51: * Initialise and return the {@link InetAddressResolver} provided by > 52: * this provider. This method is called by {@link InetAddress} when "the InetAddressResolver" suggests there is just one instance. That is probably the case but I don't think you want to be restricted to that. src/java.base/share/classes/java/net/spi/InetAddressResolverProvider.java line 88: > 86: * {@code RuntimePermission("inetAddressResolverProvider")}. > 87: * @implNote It is recommended that an {@code InetAddressResolverProvider} service > 88: * implementation does not perform any heavy initialization in its "heavy initialization" is probably not the best phrase here. Maybe it should say that the initialisation should be as simple as possible to avoid recursive initialisation issues. src/java.base/share/classes/java/net/spi/InetAddressResolverProvider.java line 110: > 108: /** > 109: * A {@code Configuration} interface is supplied to the > 110: * {@link InetAddressResolverProvider#get(Configuration)} method when installing a I think this should be "Configuration object" rather than "interface" here. ------------- PR: https://git.openjdk.java.net/jdk/pull/5822 From joehw at openjdk.java.net Wed Oct 20 18:40:05 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Wed, 20 Oct 2021 18:40:05 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value In-Reply-To: References: Message-ID: On Wed, 20 Oct 2021 17:23:36 GMT, Naoto Sato wrote: > During the review of JEP 400, a proposal to provide an overloaded method to `Charset.forName()` was suggested [[1]](https://github.com/openjdk/jdk/pull/4733#discussion_r669693954). This PR is to implement the proposal. A CSR is also drafted as https://bugs.openjdk.java.net/browse/JDK-8275348 Marked as reviewed by joehw (Reviewer). src/java.base/share/classes/java/nio/charset/Charset.java line 545: > 543: * @return A charset object for the named charset, or {@code fallback} > 544: * in case the charset object for the named charset is not > 545: * available. May be {@code null} A minor comment: it seems to me returning the fallback charset is sufficient, and "May be null" may be not necessary since the fallback charset is provided, it's expected if it's null. ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From alanb at openjdk.java.net Wed Oct 20 18:50:08 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 20 Oct 2021 18:50:08 GMT Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v5] In-Reply-To: References: Message-ID: On Wed, 20 Oct 2021 11:52:38 GMT, Aleksei Efimov wrote: >> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver. >> >> The following API classes are added to `java.net.spi` package to facilitate this: >> - `InetAddressResolverProvider` - abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers. >> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations. >> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations. >> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation. >> >> More details in [JEP-418](https://openjdk.java.net/jeps/418). >> >> Testing: new and existing `tier1:tier3` tests > > Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision: > > Change InetAddressResolver method names src/java.base/share/classes/java/net/InetAddress.java line 244: > 242: * @implNote > 243: * For any lookup operation that might occur before the VM is fully booted the built-in > 244: * resolver will be used. I think we will need decide if InetAddress class description is the right place for this or whether some/most of it should move to InetAddressResolverProvider. It might be that we update the existing "Host Name Resolution" section with some basic/readable text to make the reader aware that there is a provider mechanism with a link to InetAddressResolverProvider with the details. ------------- PR: https://git.openjdk.java.net/jdk/pull/5822 From naoto at openjdk.java.net Wed Oct 20 19:02:30 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 20 Oct 2021 19:02:30 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v2] In-Reply-To: References: Message-ID: <9673dBKTx-9BLrJfErLJe1X_0K6yCCCusPhY4LdgoPI=.d0b1df23-bd53-4bae-b972-aec328a41fb5@github.com> > During the review of JEP 400, a proposal to provide an overloaded method to `Charset.forName()` was suggested [[1]](https://github.com/openjdk/jdk/pull/4733#discussion_r669693954). This PR is to implement the proposal. A CSR is also drafted as https://bugs.openjdk.java.net/browse/JDK-8275348 Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Moved the null sentence into @param tag. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6045/files - new: https://git.openjdk.java.net/jdk/pull/6045/files/a31dbdc7..4c2142be Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6045&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6045&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/6045.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6045/head:pull/6045 PR: https://git.openjdk.java.net/jdk/pull/6045 From naoto at openjdk.java.net Wed Oct 20 19:02:31 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 20 Oct 2021 19:02:31 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v2] In-Reply-To: References: Message-ID: On Wed, 20 Oct 2021 18:37:05 GMT, Joe Wang wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Moved the null sentence into @param tag. > > src/java.base/share/classes/java/nio/charset/Charset.java line 545: > >> 543: * @return A charset object for the named charset, or {@code fallback} >> 544: * in case the charset object for the named charset is not >> 545: * available. May be {@code null} > > A minor comment: it seems to me returning the fallback charset is sufficient, and "May be null" may be not necessary since the fallback charset is provided, it's expected if it's null. Thanks, Joe. Moved that explanation into the `fallback` param, which I initially intended. ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From alanb at openjdk.java.net Wed Oct 20 19:02:31 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 20 Oct 2021 19:02:31 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v2] In-Reply-To: References: Message-ID: On Wed, 20 Oct 2021 18:56:22 GMT, Naoto Sato wrote: >> src/java.base/share/classes/java/nio/charset/Charset.java line 545: >> >>> 543: * @return A charset object for the named charset, or {@code fallback} >>> 544: * in case the charset object for the named charset is not >>> 545: * available. May be {@code null} >> >> A minor comment: it seems to me returning the fallback charset is sufficient, and "May be null" may be not necessary since the fallback charset is provided, it's expected if it's null. > > Thanks, Joe. Moved that explanation into the `fallback` param, which I initially intended. The java.nio.charset package has the usual "Unless otherwise noted, passing a null argument ..." so if fallback is allowed to be null then you will need to add ", can null" to its description. ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From kvn at openjdk.java.net Wed Oct 20 19:11:09 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 20 Oct 2021 19:11:09 GMT Subject: RFR: 8275167: x86 intrinsic for unsignedMultiplyHigh [v2] In-Reply-To: References: <7IzrZdL0elgXbuisyLNYC2wkyOTe1RHUPuGRI7YsAQ4=.aed9dea3-4775-4592-b43e-c3e08e167f90@github.com> Message-ID: On Tue, 19 Oct 2021 20:34:55 GMT, Vamsi Parasa wrote: >> Optimize the new Math.unsignedMultiplyHigh using the x86 mul instruction. This change show 1.87X improvement on a micro benchmark. > > Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision: > > refactoring to remove code duplication by using a common routine for UMulHiLNode and MulHiLNode Looks good. And I submitted testing. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5933 From joehw at openjdk.java.net Wed Oct 20 19:15:09 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Wed, 20 Oct 2021 19:15:09 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v2] In-Reply-To: <9673dBKTx-9BLrJfErLJe1X_0K6yCCCusPhY4LdgoPI=.d0b1df23-bd53-4bae-b972-aec328a41fb5@github.com> References: <9673dBKTx-9BLrJfErLJe1X_0K6yCCCusPhY4LdgoPI=.d0b1df23-bd53-4bae-b972-aec328a41fb5@github.com> Message-ID: On Wed, 20 Oct 2021 19:02:30 GMT, Naoto Sato wrote: >> During the review of JEP 400, a proposal to provide an overloaded method to `Charset.forName()` was suggested [[1]](https://github.com/openjdk/jdk/pull/4733#discussion_r669693954). This PR is to implement the proposal. A CSR is also drafted as https://bugs.openjdk.java.net/browse/JDK-8275348 > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Moved the null sentence into @param tag. Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From naoto at openjdk.java.net Wed Oct 20 19:15:09 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 20 Oct 2021 19:15:09 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v2] In-Reply-To: References: Message-ID: On Wed, 20 Oct 2021 18:58:34 GMT, Alan Bateman wrote: >> Thanks, Joe. Moved that explanation into the `fallback` param, which I initially intended. > > The java.nio.charset package has the usual "Unless otherwise noted, passing a null argument ..." so if fallback is allowed to be null then you will need to add ", can null" to its description. Our comments crossed I guess? Moved the null allowance into `fallback`. ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From rriggs at openjdk.java.net Wed Oct 20 21:05:03 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 20 Oct 2021 21:05:03 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v2] In-Reply-To: <9673dBKTx-9BLrJfErLJe1X_0K6yCCCusPhY4LdgoPI=.d0b1df23-bd53-4bae-b972-aec328a41fb5@github.com> References: <9673dBKTx-9BLrJfErLJe1X_0K6yCCCusPhY4LdgoPI=.d0b1df23-bd53-4bae-b972-aec328a41fb5@github.com> Message-ID: <0SG8S4-aHXxYnbK9sq7IVi_sPcMsl_61iQTVxb2jYSA=.cbbd1868-bc04-45b5-83e1-6174a5091eed@github.com> On Wed, 20 Oct 2021 19:02:30 GMT, Naoto Sato wrote: >> During the review of JEP 400, a proposal to provide an overloaded method to `Charset.forName()` was suggested [[1]](https://github.com/openjdk/jdk/pull/4733#discussion_r669693954). This PR is to implement the proposal. A CSR is also drafted as https://bugs.openjdk.java.net/browse/JDK-8275348 > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Moved the null sentence into @param tag. Looks good ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6045 From rriggs at openjdk.java.net Wed Oct 20 22:05:18 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 20 Oct 2021 22:05:18 GMT Subject: RFR: 8273660: Propagate CNF exception in FieldValues.get via an IOException Message-ID: The ObjectInputStream.GetField method `get(String name, Object val)` should have been throwing a ClassNotFoundException if the class was not found. Instead the implementation was returning null. A design error does not allow the `get(String name, Object val)` method to throw CNFE as it should. However, an exception must be thrown to prevent invalid data from being returned. Wrapping the CNFE in IOException allows it to be thrown and the exception handled. The call to `get(String name, Object val)` is always from within a `readObject` method so the deserialization logic can catch the IOException and unwrap it to handle the CNFE. ------------- Commit messages: - 8273660: Propagate CNF exception in FieldValues.get via an IOException Changes: https://git.openjdk.java.net/jdk/pull/6053/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6053&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273660 Stats: 112 lines in 2 files changed: 109 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/6053.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6053/head:pull/6053 PR: https://git.openjdk.java.net/jdk/pull/6053 From kvn at openjdk.java.net Wed Oct 20 22:18:09 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 20 Oct 2021 22:18:09 GMT Subject: RFR: 8275167: x86 intrinsic for unsignedMultiplyHigh [v2] In-Reply-To: References: <7IzrZdL0elgXbuisyLNYC2wkyOTe1RHUPuGRI7YsAQ4=.aed9dea3-4775-4592-b43e-c3e08e167f90@github.com> Message-ID: On Tue, 19 Oct 2021 20:34:55 GMT, Vamsi Parasa wrote: >> Optimize the new Math.unsignedMultiplyHigh using the x86 mul instruction. This change show 1.87X improvement on a micro benchmark. > > Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision: > > refactoring to remove code duplication by using a common routine for UMulHiLNode and MulHiLNode Tests passed. You can integrate changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/5933 From duke at openjdk.java.net Wed Oct 20 22:22:01 2021 From: duke at openjdk.java.net (Vamsi Parasa) Date: Wed, 20 Oct 2021 22:22:01 GMT Subject: RFR: 8275167: x86 intrinsic for unsignedMultiplyHigh [v2] In-Reply-To: References: <7IzrZdL0elgXbuisyLNYC2wkyOTe1RHUPuGRI7YsAQ4=.aed9dea3-4775-4592-b43e-c3e08e167f90@github.com> Message-ID: On Wed, 20 Oct 2021 22:14:33 GMT, Vladimir Kozlov wrote: > Tests passed. You can integrate changes. Thanks Vladimir! What are the next steps to integrate the change? ------------- PR: https://git.openjdk.java.net/jdk/pull/5933 From duke at openjdk.java.net Wed Oct 20 22:44:06 2021 From: duke at openjdk.java.net (Vamsi Parasa) Date: Wed, 20 Oct 2021 22:44:06 GMT Subject: Integrated: 8275167: x86 intrinsic for unsignedMultiplyHigh In-Reply-To: <7IzrZdL0elgXbuisyLNYC2wkyOTe1RHUPuGRI7YsAQ4=.aed9dea3-4775-4592-b43e-c3e08e167f90@github.com> References: <7IzrZdL0elgXbuisyLNYC2wkyOTe1RHUPuGRI7YsAQ4=.aed9dea3-4775-4592-b43e-c3e08e167f90@github.com> Message-ID: On Wed, 13 Oct 2021 18:55:10 GMT, Vamsi Parasa wrote: > Optimize the new Math.unsignedMultiplyHigh using the x86 mul instruction. This change show 1.87X improvement on a micro benchmark. This pull request has now been integrated. Changeset: af7c56b8 Author: vamsi-parasa Committer: Sandhya Viswanathan URL: https://git.openjdk.java.net/jdk/commit/af7c56b85bb2828a9d68f9e1c753a4adfa7ebb4f Stats: 63 lines in 11 files changed: 61 ins; 2 del; 0 mod 8275167: x86 intrinsic for unsignedMultiplyHigh Reviewed-by: kvn, sviswanathan ------------- PR: https://git.openjdk.java.net/jdk/pull/5933 From darcy at openjdk.java.net Thu Oct 21 01:13:18 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 21 Oct 2021 01:13:18 GMT Subject: RFR: JDK-8275686: Suppress warnings on non-serializable non-transient instance fields in java.rmi Message-ID: Another serialization warnings cleanup; this time in java.rmi. ------------- Commit messages: - JDK-8275686: Suppress warnings on non-serializable non-transient instance fields in java.rmi Changes: https://git.openjdk.java.net/jdk/pull/6055/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6055&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275686 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6055.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6055/head:pull/6055 PR: https://git.openjdk.java.net/jdk/pull/6055 From serb at openjdk.java.net Thu Oct 21 01:35:04 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 21 Oct 2021 01:35:04 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v2] In-Reply-To: <9673dBKTx-9BLrJfErLJe1X_0K6yCCCusPhY4LdgoPI=.d0b1df23-bd53-4bae-b972-aec328a41fb5@github.com> References: <9673dBKTx-9BLrJfErLJe1X_0K6yCCCusPhY4LdgoPI=.d0b1df23-bd53-4bae-b972-aec328a41fb5@github.com> Message-ID: On Wed, 20 Oct 2021 19:02:30 GMT, Naoto Sato wrote: >> During the review of JEP 400, a proposal to provide an overloaded method to `Charset.forName()` was suggested [[1]](https://github.com/openjdk/jdk/pull/4733#discussion_r669693954). This PR is to implement the proposal. A CSR is also drafted as https://bugs.openjdk.java.net/browse/JDK-8275348 > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Moved the null sentence into @param tag. src/java.base/share/classes/java/io/Console.java line 587: > 585: try { > 586: cs = Charset.forName(csname, null); > 587: } catch (Exception ignored) { } The comment which suggests this enhancement was about eliminating such "exception ignored" code paths. Is it still needed here? And if it is needed why do we pass the null as a fallback? src/java.base/share/classes/java/io/Console.java line 594: > 592: cs = Charset.forName(StaticProperty.nativeEncoding(), Charset.defaultCharset()); > 593: } catch (Exception ignored) { > 594: cs = Charset.defaultCharset(); What kind of actual improvements do we get here since the catch block is still in place? ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From njian at openjdk.java.net Thu Oct 21 01:59:09 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Thu, 21 Oct 2021 01:59:09 GMT Subject: RFR: 8271515: Integration of JEP 417: Vector API (Third Incubator) [v5] In-Reply-To: References: <_QQ9ntdJJfzVcAGrbjev0ZM-xNfD4wNATphnXkb-Y00=.bbf46985-8776-4dda-ada5-b15ab50774aa@github.com> Message-ID: On Wed, 20 Oct 2021 03:13:07 GMT, Nick Gasson wrote: > AArch64 changes look ok apart from some minor comments. Thank you @nick-arm for the review! All your comments have been addressed. ------------- PR: https://git.openjdk.java.net/jdk/pull/5873 From bpb at openjdk.java.net Thu Oct 21 02:12:04 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 21 Oct 2021 02:12:04 GMT Subject: RFR: JDK-8275686: Suppress warnings on non-serializable non-transient instance fields in java.rmi In-Reply-To: References: Message-ID: On Thu, 21 Oct 2021 01:06:33 GMT, Joe Darcy wrote: > Another serialization warnings cleanup; this time in java.rmi. Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6055 From iris at openjdk.java.net Thu Oct 21 02:17:05 2021 From: iris at openjdk.java.net (Iris Clark) Date: Thu, 21 Oct 2021 02:17:05 GMT Subject: RFR: JDK-8275686: Suppress warnings on non-serializable non-transient instance fields in java.rmi In-Reply-To: References: Message-ID: On Thu, 21 Oct 2021 01:06:33 GMT, Joe Darcy wrote: > Another serialization warnings cleanup; this time in java.rmi. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6055 From darcy at openjdk.java.net Thu Oct 21 04:47:12 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 21 Oct 2021 04:47:12 GMT Subject: RFR: JDK-8275688: Suppress warnings on non-serializable non-transient instance fields in DualPivotQuicksort Message-ID: This should be the last core libraries cleanup of non-serializable non-transient instance fields ahead of the upcoming javac lint warnings: https://mail.openjdk.java.net/pipermail/jdk-dev/2021-October/006166.html ------------- Commit messages: - JDK-8275688: Suppress warnings on non-serializable non-transient instance fields in DualPivotQuicksort Changes: https://git.openjdk.java.net/jdk/pull/6058/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6058&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275688 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6058.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6058/head:pull/6058 PR: https://git.openjdk.java.net/jdk/pull/6058 From alanb at openjdk.java.net Thu Oct 21 06:54:07 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 21 Oct 2021 06:54:07 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v2] In-Reply-To: References: <9673dBKTx-9BLrJfErLJe1X_0K6yCCCusPhY4LdgoPI=.d0b1df23-bd53-4bae-b972-aec328a41fb5@github.com> Message-ID: On Thu, 21 Oct 2021 01:30:05 GMT, Sergey Bylokhov wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Moved the null sentence into @param tag. > > src/java.base/share/classes/java/io/Console.java line 587: > >> 585: try { >> 586: cs = Charset.forName(csname, null); >> 587: } catch (Exception ignored) { } > > The comment which suggests this enhancement was about eliminating such "exception ignored" code paths. Is it still needed here? And if it is needed why do we pass the null as a fallback? Right, I think both try-catch usages will be removed. ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From myano at openjdk.java.net Thu Oct 21 07:54:04 2021 From: myano at openjdk.java.net (Masanori Yano) Date: Thu, 21 Oct 2021 07:54:04 GMT Subject: RFR: 8250678: ModuleDescriptor.Version parsing treats empty segments inconsistently In-Reply-To: <-RdwCCyA_gS04j8OgqlqsTAnTzGoQduJXjciYuwvh0w=.eb4ae2a2-63c0-4b5e-aca5-513cc3862790@github.com> References: <5FwhmsS85upnfXAKPCBCQTsWorJN17vOBFZXCN6iP8M=.377740a1-6f1e-4e37-9344-25a60ffdd891@github.com> <-RdwCCyA_gS04j8OgqlqsTAnTzGoQduJXjciYuwvh0w=.eb4ae2a2-63c0-4b5e-aca5-513cc3862790@github.com> Message-ID: <6xTj7n1rlAOYfR2jI950J4kjt3Y4L45Tm-LcRrUxvXo=.d4676606-bdba-4119-9b3b-835ee5151886@github.com> On Mon, 27 Sep 2021 08:22:02 GMT, Alan Bateman wrote: >> Could you please review the 8250678 bug fixes? >> >> The `parse` method of ModuleDescriptor.Version class behaves incorrectly when the input string contains consecutive delimiters. >> >> The `parse` method treats strings as three sections, but the parsing method differs between the method for the version sections and the ones for others. In version sections, the `parse` method takes a single character in a loop and determines whether it is a delimiter. In pre and build sections, the parse method takes two characters in a loop and determines whether the second character is the delimiter. Therefore, if the string contains a sequence of delimiters in pre or build section, the `parse` method treats character at the odd-numbered position as a token and the one at even-numbered as a delimiter. >> >> A string containing consecutive delimiters is an incorrect version string, but this behavior does not follow the API specification. >> https://download.java.net/java/early_access/jdk18/docs/api/java.base/java/lang/module/ModuleDescriptor.Version.html >> >> Therefore, I propose to fix the parsing method of pre and build section in the same way as the version. > > I think this is okay, just maybe unusual to have repeated punctuation creating the case where a component is empty. @mbreinhold may wish to comment on this PR. @AlanBateman I have been waiting for a reply from @mbreinhold , but I haven't received it yet. I would like to contribute this PR as soon as possible. Do you have any ideas on how to do it? ------------- PR: https://git.openjdk.java.net/jdk/pull/5679 From dfuchs at openjdk.java.net Thu Oct 21 09:37:13 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 21 Oct 2021 09:37:13 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v2] In-Reply-To: References: <9673dBKTx-9BLrJfErLJe1X_0K6yCCCusPhY4LdgoPI=.d0b1df23-bd53-4bae-b972-aec328a41fb5@github.com> Message-ID: <2dVpiRSN-mhp69KZZ9jIUc7O1YiJ3CP5H1uRlEI7nMY=.3d5733d0-7d66-422d-8c21-01aea560f9cf@github.com> On Thu, 21 Oct 2021 06:50:41 GMT, Alan Bateman wrote: >> src/java.base/share/classes/java/io/Console.java line 587: >> >>> 585: try { >>> 586: cs = Charset.forName(csname, null); >>> 587: } catch (Exception ignored) { } >> >> The comment which suggests this enhancement was about eliminating such "exception ignored" code paths. Is it still needed here? And if it is needed why do we pass the null as a fallback? > > Right, I think both try-catch usages will be removed. Apparently `IllegalCharsetNameException` or `IllegalArgumentException` could still be thrown - so removing the `try-catch` would be a change of behaviour in those cases. It all depends on whether there is a chance that these exceptions could be thrown in this particular context (with these particular input parameters) - which I am not able to tell - but maybe someone more familiar with this code could... ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From jai.forums2013 at gmail.com Thu Oct 21 09:49:58 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Thu, 21 Oct 2021 15:19:58 +0530 Subject: JDK-8275509: (jlink) SystemModulesPlugin generates a jdk.internal.module.SystemModules$all.class which isn't reproducible In-Reply-To: <60708e84-4888-9584-50e0-df3ae5d8b0b5@oracle.com> References: <4a4901a8-ca90-c9f3-0b2f-a37e521bfe65@oracle.com> <77faaab4-831c-de4f-2f64-f7305cb8f9fb@gmail.com> <60708e84-4888-9584-50e0-df3ae5d8b0b5@oracle.com> Message-ID: <72b9f8de-c4f9-9509-bf1e-ec6148f40860@gmail.com> Hello Alan, On 19/10/21 7:40 pm, Alan Bateman wrote: > On 19/10/2021 14:49, Jaikiran Pai wrote: >> >> Ah! So this exact same investigation had already happened a few weeks >> back then. I haven't subscribed to that list, so missed it. I see in >> one of those messages this part: >> >> "Off hand I can't think of any issues with the ModuleDescriptor >> hashCode. It is computed at link time and should be deterministic. If >> I were to guess then then this may be something to do with the module >> version recorded at compile-time at that is one of the components >> that the hash is based on." >> >> To be clear, is the ModuleDescriptor#hashCode() expected to return >> reproducible (same) hashCode across multiple runs? What currently >> changes the hashCode() across multiple runs is various components >> within ModuleDescriptor's hashCode() implementation using the >> hashCode() of the enums (specifically the various Modifier enums). > > The discussion on jigsaw-dev didn't get to the bottom of the issue at > the time, mostly because it wasn't easy to reproduce. > > Now that the issue is clearer then we should fix it. Aside from > reproducible builds then I expect it is possible to use a > ModuleDescriptor.Builder to create a ModuleDescriptor that is equal to > a ModuleDescriptor in boot layer configuration but with a different > hashCode. > Based on this input, one of the tests I have included for verifying this proposed hashCode fix, involves dealing with a boot layer ModuleDescriptor and then verifying it's hashCode against a ModuleDescriptor that is built for the same module using the ModuleDescriptor.Builder. It does reproduce the hashCode issue. However, that test seems to have exposed a different bug with CDS and equality checks against enums (which impact ModuleDescriptor#equals()). More precisely, consider this trivial Java code: import java.lang.module.*; import java.io.*; import java.util.*; public class EnumEquality { ?? ?public static void main(final String[] args) throws Exception { ?? ???? String moduleName = "java.sql"; ?? ???? // load the "java.sql" module from boot layer ??????? Optional bootModule = ModuleLayer.boot().findModule(moduleName); ??????? if (bootModule.isEmpty()) { ??????????? throw new RuntimeException(moduleName + " module is missing in boot layer"); ??????? } ??????? ModuleDescriptor m1 = bootModule.get().getDescriptor(); ??????? // now recreate the same module using the ModuleDescriptor.read on the module's module-info.class ??????? ModuleDescriptor m2; ??????? try (InputStream moduleInfo = bootModule.get().getResourceAsStream("module-info.class")) { ??????????? if (moduleInfo == null) { ??????????????? throw new RuntimeException("Could not locate module-info.class in " + moduleName + " module"); ??????????? } ??????????? // this will internally use a ModuleDescriptor.Builder to construct the ModuleDescriptor ??????????? m2 = ModuleDescriptor.read(moduleInfo); ??????? } ??????? if (!m1.equals(m2)) { ?????? ???? // root cause - the enums aren't "equal" ??????????? for (ModuleDescriptor.Requires r1 : m1.requires()) { ??????????????? if (r1.name().equals("java.base")) { ??????????????????? for (ModuleDescriptor.Requires r2 : m2.requires()) { ??????????????????????? if (r2.name().equals("java.base")) { ??????????????????????????? System.out.println("Modifiers r1 " + r1.modifiers() + " r2 " + r2.modifiers() ?????????????????????????? ???? + " --> equals? " + r1.modifiers().equals(r2.modifiers())); ??????????????????????? } ??????????????????? } ??????????????? } ??????????? } ??????????? throw new RuntimeException("ModuleDescriptor(s) aren't equal: \n" + m1 + "\n" + m2); ??????? } ?? ???? System.out.println("Success"); ?? ?} } This program uses "java.sql" as the module under test. This "java.sql" is a boot layer module and among other things has: ??? requires transitive java.logging; ??? requires transitive java.transaction.xa; ??? requires transitive java.xml; in its module definition[1]. The program first loads this module's ModuleDescriptor into an instance m1, using the boot() module layer. It then "reconstructs" this same module by reading the module-info.class of this module, using the ModuleDescriptor.read() API (which internally calls ModuleDescriptor.Builder). This is stored into m2. m1 and m2 are then checked for equality (using a call to equals() method). This equality check keeps failing consistently. Digging into it, it appears that since the ModuleDescriptor#equals() calls equals() on enum types (in this specific case on ModuleDescriptor.Requires.Modifier) and since enum type equality is implemented as identity checks, those identity checks are surprisingly failing. More specifically ModuleDescriptor.Requires.Modifier.MANDATED == ModuleDescriptor.Requires.Modifier.MANDATED is equating to false because at runtime I see that two different instances of ModuleDescriptor.Requires.Modifier.MANDATED have been loaded (by the same boot module classloader). Although I use ModuleDescriptor.Requires.Modifier.MANDATED as an example, the same is reproducible with other enum values like ModuleDescriptor.Requires.Modifier.TRANSITIVE. This appears to be specific to CDS since running the above program with: java -Xshare:off EnumEquality succeeds and the ModuleDescriptor equality check passes. In short, it looks like there is some general issue with CDS and equality checks with enums and perhaps deserves a separate JBS issue? [1] https://github.com/openjdk/jdk/blob/master/src/java.sql/share/classes/module-info.java#L34 -Jaikiran From Alan.Bateman at oracle.com Thu Oct 21 12:25:10 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 21 Oct 2021 13:25:10 +0100 Subject: JDK-8275509: (jlink) SystemModulesPlugin generates a jdk.internal.module.SystemModules$all.class which isn't reproducible In-Reply-To: <72b9f8de-c4f9-9509-bf1e-ec6148f40860@gmail.com> References: <4a4901a8-ca90-c9f3-0b2f-a37e521bfe65@oracle.com> <77faaab4-831c-de4f-2f64-f7305cb8f9fb@gmail.com> <60708e84-4888-9584-50e0-df3ae5d8b0b5@oracle.com> <72b9f8de-c4f9-9509-bf1e-ec6148f40860@gmail.com> Message-ID: <89cad5a5-08f0-3bde-5279-7fcb0550d4db@oracle.com> On 21/10/2021 10:49, Jaikiran Pai wrote: > : > > Digging into it, it appears that since the ModuleDescriptor#equals() > calls equals() on enum types (in this specific case on > ModuleDescriptor.Requires.Modifier) and since enum type equality is > implemented as identity checks, those identity checks are surprisingly > failing. More specifically ModuleDescriptor.Requires.Modifier.MANDATED > == ModuleDescriptor.Requires.Modifier.MANDATED is equating to false > because at runtime I see that two different instances of > ModuleDescriptor.Requires.Modifier.MANDATED have been loaded (by the > same boot module classloader). Although I use > ModuleDescriptor.Requires.Modifier.MANDATED as an example, the same is > reproducible with other enum values like > ModuleDescriptor.Requires.Modifier.TRANSITIVE. > > This appears to be specific to CDS since running the above program with: > > java -Xshare:off EnumEquality > > succeeds and the ModuleDescriptor equality check passes. > > In short, it looks like there is some general issue with CDS and > equality checks with enums and perhaps deserves a separate JBS issue? I've asked Ioi Lam to comment on this, off-hand I'm not aware of any issues with CDS here but it may be related to the archiving of object graphs. -Alan From rriggs at openjdk.java.net Thu Oct 21 14:00:02 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 21 Oct 2021 14:00:02 GMT Subject: RFR: JDK-8275686: Suppress warnings on non-serializable non-transient instance fields in java.rmi In-Reply-To: References: Message-ID: On Thu, 21 Oct 2021 01:06:33 GMT, Joe Darcy wrote: > Another serialization warnings cleanup; this time in java.rmi. Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6055 From rriggs at openjdk.java.net Thu Oct 21 14:04:05 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 21 Oct 2021 14:04:05 GMT Subject: RFR: JDK-8275688: Suppress warnings on non-serializable non-transient instance fields in DualPivotQuicksort In-Reply-To: References: Message-ID: On Thu, 21 Oct 2021 04:40:25 GMT, Joe Darcy wrote: > This should be the last core libraries cleanup of non-serializable non-transient instance fields ahead of the upcoming javac lint warnings: https://mail.openjdk.java.net/pipermail/jdk-dev/2021-October/006166.html Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6058 From weijun at openjdk.java.net Thu Oct 21 14:08:12 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 21 Oct 2021 14:08:12 GMT Subject: Integrated: 8270380: Change the default value of the java.security.manager system property to disallow In-Reply-To: References: Message-ID: On Fri, 20 Aug 2021 22:44:34 GMT, Weijun Wang wrote: > This change modifies the default value of the `java.security.manager` system property from "allow" to "disallow". This means unless it's explicitly set to "allow", any call to `System.setSecurityManager()` would throw an UOE. > > This change was previously announced on the [jdk-dev alias](https://mail.openjdk.java.net/pipermail/jdk-dev/2021-May/005616.html) and is documented in [JEP 411](https://openjdk.java.net/jeps/411#Description). > > The `AllowSecurityManager.java` and `SecurityManagerWarnings.java` tests are updated to confirm this behavior change. Two other tests are updated because they were added after JDK-8267184 and do not have `-Djava.security.manager=allow` on its `@run` line even it they need to install a `SecurityManager` at runtime. This pull request has now been integrated. Changeset: d589b664 Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/d589b664cc809aea39ec094e99b1898df1bf3c19 Stats: 30 lines in 6 files changed: 5 ins; 8 del; 17 mod 8270380: Change the default value of the java.security.manager system property to disallow Reviewed-by: lancea, mullan, rriggs ------------- PR: https://git.openjdk.java.net/jdk/pull/5204 From rriggs at openjdk.java.net Thu Oct 21 15:03:09 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 21 Oct 2021 15:03:09 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v2] In-Reply-To: References: <9673dBKTx-9BLrJfErLJe1X_0K6yCCCusPhY4LdgoPI=.d0b1df23-bd53-4bae-b972-aec328a41fb5@github.com> Message-ID: On Thu, 21 Oct 2021 01:31:31 GMT, Sergey Bylokhov wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Moved the null sentence into @param tag. > > src/java.base/share/classes/java/io/Console.java line 594: > >> 592: cs = Charset.forName(StaticProperty.nativeEncoding(), Charset.defaultCharset()); >> 593: } catch (Exception ignored) { >> 594: cs = Charset.defaultCharset(); > > What kind of actual improvements do we get here since the catch block is still in place? In the case of Console, both charset names come from system properties and could refer to invalid or unavailable charsets. (null is handled separately). The code silently ignores the invalid values. The new method , as is, is not a fully satisfying replacement. Catching Exception is too broad a catch but may be warranted in this case so that some Console charset is selected. The new method would be useful in more cases if the default was returned for any of IllegalCharsetNameException, IllegalArgumentException, and UnsupportedCharsetException. ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From darcy at openjdk.java.net Thu Oct 21 15:19:42 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 21 Oct 2021 15:19:42 GMT Subject: RFR: JDK-8275688: Suppress warnings on non-serializable non-transient instance fields in DualPivotQuicksort [v2] In-Reply-To: References: Message-ID: > This should be the last core libraries cleanup of non-serializable non-transient instance fields ahead of the upcoming javac lint warnings: https://mail.openjdk.java.net/pipermail/jdk-dev/2021-October/006166.html Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Update copyright. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6058/files - new: https://git.openjdk.java.net/jdk/pull/6058/files/126782c3..72176dfe Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6058&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6058&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6058.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6058/head:pull/6058 PR: https://git.openjdk.java.net/jdk/pull/6058 From mcimadamore at openjdk.java.net Thu Oct 21 15:20:16 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 21 Oct 2021 15:20:16 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v9] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/419 Maurizio Cimadamore 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: - Fix regression in VaList treatment on AArch64 (contributed by @nick-arm) - Merge branch 'master' into JEP-419 - Fix copyright header in TestArrayCopy - Fix failing microbenchmarks. Contributed by @FrauBoes (thanks!) - * use `invokeWithArguments` to simplify new test - Add test for liveness check with high-aririty downcalls (make sure that if an exception occurs in a downcall because of liveness, ref count of other resources are left intact). - * Fix javadoc issue in VaList * Fix bug in concurrent logic for shared scope acquire - Address review comments - Apply suggestions from code review Co-authored-by: Paul Sandoz - Fix TestLinkToNativeRBP test - ... and 5 more: https://git.openjdk.java.net/jdk/compare/aeabb3df...5c69eabf ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5907/files - new: https://git.openjdk.java.net/jdk/pull/5907/files/414952ad..5c69eabf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=07-08 Stats: 25202 lines in 587 files changed: 18962 ins; 4240 del; 2000 mod Patch: https://git.openjdk.java.net/jdk/pull/5907.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5907/head:pull/5907 PR: https://git.openjdk.java.net/jdk/pull/5907 From darcy at openjdk.java.net Thu Oct 21 15:29:09 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 21 Oct 2021 15:29:09 GMT Subject: Integrated: JDK-8275686: Suppress warnings on non-serializable non-transient instance fields in java.rmi In-Reply-To: References: Message-ID: On Thu, 21 Oct 2021 01:06:33 GMT, Joe Darcy wrote: > Another serialization warnings cleanup; this time in java.rmi. This pull request has now been integrated. Changeset: 3cb241a9 Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/3cb241a91fd2cc6b0b3b333288028694e60f723f Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8275686: Suppress warnings on non-serializable non-transient instance fields in java.rmi Reviewed-by: bpb, iris, rriggs ------------- PR: https://git.openjdk.java.net/jdk/pull/6055 From darcy at openjdk.java.net Thu Oct 21 15:31:11 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 21 Oct 2021 15:31:11 GMT Subject: Integrated: JDK-8275688: Suppress warnings on non-serializable non-transient instance fields in DualPivotQuicksort In-Reply-To: References: Message-ID: On Thu, 21 Oct 2021 04:40:25 GMT, Joe Darcy wrote: > This should be the last core libraries cleanup of non-serializable non-transient instance fields ahead of the upcoming javac lint warnings: https://mail.openjdk.java.net/pipermail/jdk-dev/2021-October/006166.html This pull request has now been integrated. Changeset: 0761a4b9 Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/0761a4b915217abb08ef9b5c1a60878aedf5572c Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod 8275688: Suppress warnings on non-serializable non-transient instance fields in DualPivotQuicksort Reviewed-by: rriggs ------------- PR: https://git.openjdk.java.net/jdk/pull/6058 From herrick at openjdk.java.net Thu Oct 21 15:36:36 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Thu, 21 Oct 2021 15:36:36 GMT Subject: RFR: JDK-8263155: Allow additional contents for DMG [v2] In-Reply-To: References: Message-ID: > JDK-8263155: Allow additional contents for DMG Andy Herrick 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 JDK-8263155 - Merge branch 'master' into JDK-8263155 - JDK-8263155: Allow additional contents for DMG - JDK-8263155: Allow additional contents for DMG - JDK-8263155: Allow additional contents for DMG ------------- Changes: https://git.openjdk.java.net/jdk/pull/5912/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5912&range=01 Stats: 171 lines in 8 files changed: 154 ins; 1 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/5912.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5912/head:pull/5912 PR: https://git.openjdk.java.net/jdk/pull/5912 From naoto at openjdk.java.net Thu Oct 21 16:06:07 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 21 Oct 2021 16:06:07 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v2] In-Reply-To: <2dVpiRSN-mhp69KZZ9jIUc7O1YiJ3CP5H1uRlEI7nMY=.3d5733d0-7d66-422d-8c21-01aea560f9cf@github.com> References: <9673dBKTx-9BLrJfErLJe1X_0K6yCCCusPhY4LdgoPI=.d0b1df23-bd53-4bae-b972-aec328a41fb5@github.com> <2dVpiRSN-mhp69KZZ9jIUc7O1YiJ3CP5H1uRlEI7nMY=.3d5733d0-7d66-422d-8c21-01aea560f9cf@github.com> Message-ID: On Thu, 21 Oct 2021 09:33:30 GMT, Daniel Fuchs wrote: >> Right, I think both try-catch usages will be removed. > > Apparently `IllegalCharsetNameException` or `IllegalArgumentException` could still be thrown - so removing the `try-catch` would be a change of behaviour in those cases. It all depends on whether there is a chance that these exceptions could be thrown in this particular context (with these particular input parameters) - which I am not able to tell - but maybe someone more familiar with this code could... I first thought of swallowing all exceptions in 2-arg forName(), but decided not to do that. Because `IllegalArgumentException` and `IllegalCharsetNameException` are for the validity of the passed `charsetName`, like detecting `null` or invalid chars like "??". On the other hand, `UnsupportedCharsetException` is for the availability which varies depending on the user's settings and or platform, which can be safely replaced with `fallback` charset. So yes, it is not totally getting rid of `try-catch` but it avoids `UnsupportedCharsetException` which is only detectable at runtime. ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From naoto at openjdk.java.net Thu Oct 21 16:06:08 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 21 Oct 2021 16:06:08 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v2] In-Reply-To: References: <9673dBKTx-9BLrJfErLJe1X_0K6yCCCusPhY4LdgoPI=.d0b1df23-bd53-4bae-b972-aec328a41fb5@github.com> Message-ID: On Thu, 21 Oct 2021 15:00:03 GMT, Roger Riggs wrote: >> src/java.base/share/classes/java/io/Console.java line 594: >> >>> 592: cs = Charset.forName(StaticProperty.nativeEncoding(), Charset.defaultCharset()); >>> 593: } catch (Exception ignored) { >>> 594: cs = Charset.defaultCharset(); >> >> What kind of actual improvements do we get here since the catch block is still in place? > > In the case of Console, both charset names come from system properties and could refer to invalid or unavailable charsets. (null is handled separately). The code silently ignores the invalid values. The new method , as is, is not a fully satisfying replacement. Catching Exception is too broad a catch but may be warranted in this case so that some Console charset is selected. > > The new method would be useful in more cases if the default was returned for any of > IllegalCharsetNameException, IllegalArgumentException, and UnsupportedCharsetException. Since we do support all the encodings for platforms we support out-of-the-box, it could still be possible that the user can specify his/her console encoding to the one we do not support. In that case, we can safely use the default `UTF-8` without throwing/catching `UnsupportedCharsetException`. ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From itakiguchi at openjdk.java.net Thu Oct 21 16:09:04 2021 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Thu, 21 Oct 2021 16:09:04 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v2] In-Reply-To: <9673dBKTx-9BLrJfErLJe1X_0K6yCCCusPhY4LdgoPI=.d0b1df23-bd53-4bae-b972-aec328a41fb5@github.com> References: <9673dBKTx-9BLrJfErLJe1X_0K6yCCCusPhY4LdgoPI=.d0b1df23-bd53-4bae-b972-aec328a41fb5@github.com> Message-ID: <3U2qAPXYrhhhfg8dF80__Gam5t7qXQWmJWcAOhTqAZE=.f0be7879-0180-4e6e-ad5d-837751536e77@github.com> On Wed, 20 Oct 2021 19:02:30 GMT, Naoto Sato wrote: >> During the review of JEP 400, a proposal to provide an overloaded method to `Charset.forName()` was suggested [[1]](https://github.com/openjdk/jdk/pull/4733#discussion_r669693954). This PR is to implement the proposal. A CSR is also drafted as https://bugs.openjdk.java.net/browse/JDK-8275348 > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Moved the null sentence into @param tag. I'm not reviewer. I'd like to write down following code without `try-catch`. var cs = Charset.forName(charsetName, null); if (cs == null) cs = StandardCharsets.UTF_8; or please find out more easy way. ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From itakiguchi at openjdk.java.net Thu Oct 21 16:24:03 2021 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Thu, 21 Oct 2021 16:24:03 GMT Subject: RFR: 8274544: Langtools command's usage were garbled on Japanese Windows [v3] In-Reply-To: <4rJtaiFtRYh-V2G3x2iCtQBtbD-lDGvqu5iVUQ_a-bA=.becf558e-ea95-4054-9f7d-3d5fe34c31c8@github.com> References: <4rJtaiFtRYh-V2G3x2iCtQBtbD-lDGvqu5iVUQ_a-bA=.becf558e-ea95-4054-9f7d-3d5fe34c31c8@github.com> Message-ID: On Tue, 19 Oct 2021 01:26:35 GMT, Jonathan Gibbons wrote: >> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision: >> >> 8274544: Langtools command's usage were garbled on Japanese Windows > > This is pretty ugly code to be replicating so many times. > > What if the tools have been run in an environment where `System.out` and `System.err` have already been redirected in some manner, with `System.setOut` or `System.setErr`? You should not assume that `System.out` and `System.err` will always refer to the console. @jonathan-gibbons I appreciate your comment. I'd like to confirm something. > This is pretty ugly code to be replicating so many times. > What if the tools have been run in an environment where `System.out` and `System.err` have already been redirected in some manner, with `System.setOut` or `System.setErr`? You should not assume that `System.out` and `System.err` will always refer to the console. I was confused since the fixed code did not call System.out/System.err directly. I tried following code on Japanese Windows. import java.io.*; import java.nio.charset.*; public class OutputCheck { public static void main(String[] args) throws Exception { String s = "\u3042"; System.out.println("[1]:"+s); PrintStream ps = System.out; System.setOut(new PrintStream(System.out)); System.out.println("[2]:"+s); ps.println("[3]:"+s); System.setOut(new PrintStream(System.out, true, Charset.forName(System.getProperty("native.encoding")))); System.out.println("[4]:"+s); } } Output is: > jdk-18-b14\bin\java OutputCheck.java [1]:? [2]:?? [3]:? [4]:? [2] refers default charset (UTF-8) [3] is same as [1] [4] specifies native.encoding system encoding Could you explain more detail ? ------------- PR: https://git.openjdk.java.net/jdk/pull/5771 From ioi.lam at oracle.com Thu Oct 21 16:29:12 2021 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 21 Oct 2021 09:29:12 -0700 Subject: JDK-8275509: (jlink) SystemModulesPlugin generates a jdk.internal.module.SystemModules$all.class which isn't reproducible In-Reply-To: <89cad5a5-08f0-3bde-5279-7fcb0550d4db@oracle.com> References: <4a4901a8-ca90-c9f3-0b2f-a37e521bfe65@oracle.com> <77faaab4-831c-de4f-2f64-f7305cb8f9fb@gmail.com> <60708e84-4888-9584-50e0-df3ae5d8b0b5@oracle.com> <72b9f8de-c4f9-9509-bf1e-ec6148f40860@gmail.com> <89cad5a5-08f0-3bde-5279-7fcb0550d4db@oracle.com> Message-ID: <122a3aee-42bc-b471-5ba8-eb3bebc5e7bb@oracle.com> On 10/21/21 5:25 AM, Alan Bateman wrote: > On 21/10/2021 10:49, Jaikiran Pai wrote: >> : >> >> Digging into it, it appears that since the ModuleDescriptor#equals() >> calls equals() on enum types (in this specific case on >> ModuleDescriptor.Requires.Modifier) and since enum type equality is >> implemented as identity checks, those identity checks are >> surprisingly failing. More specifically >> ModuleDescriptor.Requires.Modifier.MANDATED == >> ModuleDescriptor.Requires.Modifier.MANDATED is equating to false >> because at runtime I see that two different instances of >> ModuleDescriptor.Requires.Modifier.MANDATED have been loaded (by the >> same boot module classloader). Although I use >> ModuleDescriptor.Requires.Modifier.MANDATED as an example, the same >> is reproducible with other enum values like >> ModuleDescriptor.Requires.Modifier.TRANSITIVE. >> >> This appears to be specific to CDS since running the above program with: >> >> java -Xshare:off EnumEquality >> >> succeeds and the ModuleDescriptor equality check passes. >> >> In short, it looks like there is some general issue with CDS and >> equality checks with enums and perhaps deserves a separate JBS issue? > I've asked Ioi Lam to comment on this, off-hand I'm not aware of any > issues with CDS here but it may be related to the archiving of object > graphs. > > -Alan Hi Jaikiran and Alan, Thanks for reporting this issue. It's a bug in CDS. I have filed https://bugs.openjdk.java.net/browse/JDK-8275731 and am working on a fix. This is my initial analysis of the problem. ====>>> Can anyone think of similar problems that may happen elsewhere? The static constructors of enum classes are executed at both CDS dump time and run time. E.g., ??? public enum Modifier { ??????? OPEN ??? } The method essentially does this: ??? public static final Modifier OPEN = new Modifier("OPEN"); If a reference of Modifier.OPEN is stored inside the CDS archived heap during dump time, it will be different than the value of Modifier.OPEN that is re-created at runtime by the execution of Modifier. Thanks - Ioi From naoto at openjdk.java.net Thu Oct 21 18:04:07 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 21 Oct 2021 18:04:07 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v2] In-Reply-To: <3U2qAPXYrhhhfg8dF80__Gam5t7qXQWmJWcAOhTqAZE=.f0be7879-0180-4e6e-ad5d-837751536e77@github.com> References: <9673dBKTx-9BLrJfErLJe1X_0K6yCCCusPhY4LdgoPI=.d0b1df23-bd53-4bae-b972-aec328a41fb5@github.com> <3U2qAPXYrhhhfg8dF80__Gam5t7qXQWmJWcAOhTqAZE=.f0be7879-0180-4e6e-ad5d-837751536e77@github.com> Message-ID: On Thu, 21 Oct 2021 16:06:31 GMT, Ichiroh Takiguchi wrote: > I'd like to write down following code without `try-catch`. You don't *have to* try-catch those exceptions if you are not interested, as they are subclasses of `RuntimeException`. > ``` > var cs = Charset.forName(charsetName, null); > if (cs == null) cs = StandardCharsets.UTF_8; > ``` This could be simplified to var cs = Charset.forName(charsetName, StandardCharsets.UTF_8); ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From aefimov at openjdk.java.net Thu Oct 21 18:21:54 2021 From: aefimov at openjdk.java.net (Aleksei Efimov) Date: Thu, 21 Oct 2021 18:21:54 GMT Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v5] In-Reply-To: References: Message-ID: On Wed, 20 Oct 2021 18:47:32 GMT, Alan Bateman wrote: >> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision: >> >> Change InetAddressResolver method names > > src/java.base/share/classes/java/net/InetAddress.java line 244: > >> 242: * @implNote >> 243: * For any lookup operation that might occur before the VM is fully booted the built-in >> 244: * resolver will be used. > > I think we will need decide if InetAddress class description is the right place for this or whether some/most of it should move to InetAddressResolverProvider. It might be that we update the existing "Host Name Resolution" section with some basic/readable text to make the reader aware that there is a provider mechanism with a link to InetAddressResolverProvider with the details. Thanks for a good suggestion, Alan. It looks better now (2a554c91864e3b42a0ea315b0a671782fe341927) with some basic text for provider mechanism added to `Host Name Resolution`, and `InetAddress Resolver Providers` section moved to `InetAddressResolverProvider`. ------------- PR: https://git.openjdk.java.net/jdk/pull/5822 From aefimov at openjdk.java.net Thu Oct 21 18:21:50 2021 From: aefimov at openjdk.java.net (Aleksei Efimov) Date: Thu, 21 Oct 2021 18:21:50 GMT Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v6] In-Reply-To: References: Message-ID: > This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver. > > The following API classes are added to `java.net.spi` package to facilitate this: > - `InetAddressResolverProvider` - abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers. > - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations. > - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations. > - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation. > > More details in [JEP-418](https://openjdk.java.net/jeps/418). > > Testing: new and existing `tier1:tier3` tests Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision: Review updates + move resolver docs to the provider class (CSR update to follow) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5822/files - new: https://git.openjdk.java.net/jdk/pull/5822/files/30226481..2a554c91 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5822&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5822&range=04-05 Stats: 123 lines in 3 files changed: 49 ins; 40 del; 34 mod Patch: https://git.openjdk.java.net/jdk/pull/5822.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5822/head:pull/5822 PR: https://git.openjdk.java.net/jdk/pull/5822 From asemenyuk at openjdk.java.net Thu Oct 21 18:22:10 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Thu, 21 Oct 2021 18:22:10 GMT Subject: RFR: JDK-8263155: Allow additional contents for DMG [v2] In-Reply-To: References: Message-ID: On Thu, 21 Oct 2021 15:36:36 GMT, Andy Herrick wrote: >> JDK-8263155: Allow additional contents for DMG > > Andy Herrick 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 JDK-8263155 > - Merge branch 'master' into JDK-8263155 > - JDK-8263155: Allow additional contents for DMG > - JDK-8263155: Allow additional contents for DMG > - JDK-8263155: Allow additional contents for DMG Marked as reviewed by asemenyuk (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5912 From dfuchs at openjdk.java.net Thu Oct 21 19:12:09 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 21 Oct 2021 19:12:09 GMT Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v6] In-Reply-To: References: Message-ID: On Thu, 21 Oct 2021 18:21:50 GMT, Aleksei Efimov wrote: >> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver. >> >> The following API classes are added to `java.net.spi` package to facilitate this: >> - `InetAddressResolverProvider` - abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers. >> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations. >> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations. >> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation. >> >> More details in [JEP-418](https://openjdk.java.net/jeps/418). >> >> Testing: new and existing `tier1:tier3` tests > > Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision: > > Review updates + move resolver docs to the provider class (CSR update to follow) src/java.base/share/classes/java/net/InetAddress.java line 152: > 150: * > 151: *

Host Name Resolution

> 152: * Host name-to-IP address resolution is accomplished through the use maybe you need a `

` there even though it's the first paragaph under the header. src/java.base/share/classes/java/net/InetAddress.java line 159: > 157: * by > 158: * deploying an {@link InetAddressResolverProvider}. > 159: *

The built-in resolver implementation is used by did you double check that anchors defined with `

` actually work in the generated API doc? Also maybe leave a blank line before any opening `` tag... src/java.base/share/classes/java/net/spi/InetAddressResolver.java line 36: > 34: * This interface defines operations for looking-up host names and IP addresses. > 35: * An instance of {@code InetAddressResolver} is > 36: * installed as a Maybe it would be more appropriate to link _system-wide-resolver_ instead (on the next line in the same sentence). src/java.base/share/classes/java/net/spi/InetAddressResolverProvider.java line 37: > 35: * > 36: *

A resolver provider is a factory for custom implementations of {@linkplain > 37: * InetAddressResolver resolvers}. A resolver define operations for looking up ... a resolver define**s** ... ------------- PR: https://git.openjdk.java.net/jdk/pull/5822 From almatvee at openjdk.java.net Thu Oct 21 22:31:05 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Thu, 21 Oct 2021 22:31:05 GMT Subject: RFR: JDK-8263155: Allow additional contents for DMG [v2] In-Reply-To: References: Message-ID: On Thu, 21 Oct 2021 15:36:36 GMT, Andy Herrick wrote: >> JDK-8263155: Allow additional contents for DMG > > Andy Herrick 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 JDK-8263155 > - Merge branch 'master' into JDK-8263155 > - JDK-8263155: Allow additional contents for DMG > - JDK-8263155: Allow additional contents for DMG > - JDK-8263155: Allow additional contents for DMG Marked as reviewed by almatvee (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5912 From duke at openjdk.java.net Thu Oct 21 23:09:37 2021 From: duke at openjdk.java.net (Raffaello Giulietti) Date: Thu, 21 Oct 2021 23:09:37 GMT Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v3] In-Reply-To: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com> References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com> Message-ID: > Hello, > > here's a PR for a patch submitted on March 2020 [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a thing. > > The patch has been edited to adhere to OpenJDK code conventions about multi-line (block) comments. Nothing in the code proper has changed, except for the addition of redundant but clarifying parentheses in some expressions. > > > Greetings > Raffaello Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - 4511638: Double.toString(double) sometimes produces incorrect results Adjusted hashes in test/langtools/tools/javac/sym/ElementStructureTest.java - 4511638: Double.toString(double) sometimes produces incorrect results Merge branch 'master' into JDK-4511638 - 4511638: Double.toString(double) sometimes produces incorrect results - 4511638: Double.toString(double) sometimes produces incorrect results Refactored test classes to better match OpenJDK conventions. Added tests recommended by Guy Steele and Paul Zimmermann. - Changed MAX_CHARS to static - 4511638: Double.toString(double) sometimes produces incorrect results - 4511638: Double.toString(double) sometimes produces incorrect results ------------- Changes: https://git.openjdk.java.net/jdk/pull/3402/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3402&range=02 Stats: 23941 lines in 16 files changed: 23805 ins; 61 del; 75 mod Patch: https://git.openjdk.java.net/jdk/pull/3402.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3402/head:pull/3402 PR: https://git.openjdk.java.net/jdk/pull/3402 From itakiguchi at openjdk.java.net Fri Oct 22 00:29:03 2021 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Fri, 22 Oct 2021 00:29:03 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v2] In-Reply-To: References: <9673dBKTx-9BLrJfErLJe1X_0K6yCCCusPhY4LdgoPI=.d0b1df23-bd53-4bae-b972-aec328a41fb5@github.com> <3U2qAPXYrhhhfg8dF80__Gam5t7qXQWmJWcAOhTqAZE=.f0be7879-0180-4e6e-ad5d-837751536e77@github.com> Message-ID: On Thu, 21 Oct 2021 18:00:46 GMT, Naoto Sato wrote: >> I'm not reviewer. >> >> I'd like to write down following code without `try-catch`. >> >> var cs = Charset.forName(charsetName, null); >> if (cs == null) cs = StandardCharsets.UTF_8; >> >> or please find out more easy way. > >> I'd like to write down following code without `try-catch`. > > You don't *have to* try-catch those exceptions if you are not interested, as they are subclasses of `RuntimeException`. > >> ``` >> var cs = Charset.forName(charsetName, null); >> if (cs == null) cs = StandardCharsets.UTF_8; >> ``` > > This could be simplified to > > > var cs = Charset.forName(charsetName, StandardCharsets.UTF_8); @naotoj Oh sorry, I'd like to detect fallback charset is used, like: var cs = Charset.forName(charsetName, null); if (cs == null) { System.err.println("Used UTF-8 encoding instead of "+charsetName+"); cs = StandardCharsets.UTF_8; } ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From wuyan at openjdk.java.net Fri Oct 22 01:40:02 2021 From: wuyan at openjdk.java.net (Wu Yan) Date: Fri, 22 Oct 2021 01:40:02 GMT Subject: RFR: 8273111: Default timezone should return zone ID if /etc/localtime is valid but not canonicalization on linux In-Reply-To: References: <6gmVj3r1hjhG5jvo_dSly3ShNnZZSCn-NIjtnvSySrk=.a88def27-7b80-425b-9ab8-2f94f5004b47@github.com> Message-ID: On Wed, 1 Sep 2021 13:39:46 GMT, Naoto Sato wrote: >> Hi, >> Please help me review the change to enhance getting time zone ID from /etc/localtime on linux. >> >> We use `realpath` instead of `readlink` to obtain the link name of /etc/localtime, because `readlink` can only read the value of a symbolic of link, not the canonicalized absolute pathname. >> >> For example, the value of /etc/localtime is "../usr/share/zoneinfo//Asia/Shanghai", then the linkbuf obtained by `readlink` is "../usr/share/zoneinfo//Asia/Shanghai", and then the call of `getZoneName(linkbuf)` will get "/Asia/Shanghai", not "Asia/Shanghai", which consider as invalid in `ZoneInfoFile.getZoneInfo()`. Using `realpath`, you can get ?/usr/share/zoneinfo/Asia/Shanghai? directly from ?/etc/localtime?. >> >> Thanks, >> wuyan > > The change looks reasonable. Please test your fix with macOS as well. Hi, @naotoj, I pushed the new commit, do you need to review again? ------------- PR: https://git.openjdk.java.net/jdk/pull/5327 From iignatyev at openjdk.java.net Fri Oct 22 01:50:02 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Fri, 22 Oct 2021 01:50:02 GMT Subject: RFR: 8275650: Problemlist java/io/File/createTempFile/SpecialTempFile.java for Windows 11 In-Reply-To: References: Message-ID: On Wed, 20 Oct 2021 00:04:08 GMT, Ivan ?ipka wrote: > cc @ctornqvi as it has been discussed internally, jtreg doesn?t recognize $os-$arch-$version pattern in problem list (but understands $os-$version) so for the test to be excluded only on windows 11, you should use `windows-11` ------------- Changes requested by iignatyev (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6025 From serb at openjdk.java.net Fri Oct 22 02:11:01 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 22 Oct 2021 02:11:01 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v2] In-Reply-To: References: <9673dBKTx-9BLrJfErLJe1X_0K6yCCCusPhY4LdgoPI=.d0b1df23-bd53-4bae-b972-aec328a41fb5@github.com> <2dVpiRSN-mhp69KZZ9jIUc7O1YiJ3CP5H1uRlEI7nMY=.3d5733d0-7d66-422d-8c21-01aea560f9cf@github.com> Message-ID: On Thu, 21 Oct 2021 16:03:29 GMT, Naoto Sato wrote: >> Apparently `IllegalCharsetNameException` or `IllegalArgumentException` could still be thrown - so removing the `try-catch` would be a change of behaviour in those cases. It all depends on whether there is a chance that these exceptions could be thrown in this particular context (with these particular input parameters) - which I am not able to tell - but maybe someone more familiar with this code could... > > I first thought of swallowing all exceptions in 2-arg forName(), but decided not to do that. Because `IllegalArgumentException` and `IllegalCharsetNameException` are for the validity of the passed `charsetName`, like detecting `null` or invalid chars like "??". On the other hand, `UnsupportedCharsetException` is for the availability which varies depending on the user's settings and or platform, which can be safely replaced with `fallback` charset. So yes, it is not totally getting rid of `try-catch` but it avoids `UnsupportedCharsetException` which is only detectable at runtime. Then what is the benefit, if the user will have to write such code anyway?: try { cs = Charset.forName(StaticProperty.nativeEncoding(), fallback); } catch (Exception ignored) { cs = fallback; } Even in the current code update it can work well w/o the second parameter. ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From thihup at gmail.com Fri Oct 22 02:44:42 2021 From: thihup at gmail.com (Thiago Henrique Hupner) Date: Thu, 21 Oct 2021 23:44:42 -0300 Subject: Make j.l.i.CallSite class sealed Message-ID: Currently, the java.lang.invoke.CallSite has a package-private constructor, and in its Javadoc it already mentions all the three subclasses: ConstantCallSite, MutableCallSite and VolatileCallSite. I guess that now that Java has support for sealed classes, the CallSite could be a candidate for it too. So CallSite would be sealed and the permitted subclasses would be non-sealed, to allow existing behavior. https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/invoke/CallSite.html From duke at openjdk.java.net Fri Oct 22 03:38:03 2021 From: duke at openjdk.java.net (Glavo) Date: Fri, 22 Oct 2021 03:38:03 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v2] In-Reply-To: <9673dBKTx-9BLrJfErLJe1X_0K6yCCCusPhY4LdgoPI=.d0b1df23-bd53-4bae-b972-aec328a41fb5@github.com> References: <9673dBKTx-9BLrJfErLJe1X_0K6yCCCusPhY4LdgoPI=.d0b1df23-bd53-4bae-b972-aec328a41fb5@github.com> Message-ID: On Wed, 20 Oct 2021 19:02:30 GMT, Naoto Sato wrote: >> During the review of JEP 400, a proposal to provide an overloaded method to `Charset.forName()` was suggested [[1]](https://github.com/openjdk/jdk/pull/4733#discussion_r669693954). This PR is to implement the proposal. A CSR is also drafted as https://bugs.openjdk.java.net/browse/JDK-8275348 > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Moved the null sentence into @param tag. I'm not reviewer. I think maybe we should check all the usage of `Charset.isSupported`. At present, `Charset.isSupported` and `Charset.forName` are often used continuously, such as in `StringCoding`: class StringCoding { // ... private static Charset lookupCharset(String csn) { if (Charset.isSupported(csn)) { try { return Charset.forName(csn); } catch (UnsupportedCharsetException x) { throw new Error(x); } } return null; } //... } This calls `Charset.lookup` twice. Replacing it with such code should eliminate unnecessary lookup: private static Charset lookupCharset(String csn) { return Charset.forName(csn, null); } ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From jai.forums2013 at gmail.com Fri Oct 22 04:09:38 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Fri, 22 Oct 2021 09:39:38 +0530 Subject: JDK-8275509: (jlink) SystemModulesPlugin generates a jdk.internal.module.SystemModules$all.class which isn't reproducible In-Reply-To: <122a3aee-42bc-b471-5ba8-eb3bebc5e7bb@oracle.com> References: <4a4901a8-ca90-c9f3-0b2f-a37e521bfe65@oracle.com> <77faaab4-831c-de4f-2f64-f7305cb8f9fb@gmail.com> <60708e84-4888-9584-50e0-df3ae5d8b0b5@oracle.com> <72b9f8de-c4f9-9509-bf1e-ec6148f40860@gmail.com> <89cad5a5-08f0-3bde-5279-7fcb0550d4db@oracle.com> <122a3aee-42bc-b471-5ba8-eb3bebc5e7bb@oracle.com> Message-ID: <71aeec43-ae77-e1f8-d4e4-c5e2d31289e7@gmail.com> Hello Ioi, On 21/10/21 9:59 pm, Ioi Lam wrote: > > > On 10/21/21 5:25 AM, Alan Bateman wrote: >> On 21/10/2021 10:49, Jaikiran Pai wrote: >>> : >>> >>> Digging into it, it appears that since the ModuleDescriptor#equals() >>> calls equals() on enum types (in this specific case on >>> ModuleDescriptor.Requires.Modifier) and since enum type equality is >>> implemented as identity checks, those identity checks are >>> surprisingly failing. More specifically >>> ModuleDescriptor.Requires.Modifier.MANDATED == >>> ModuleDescriptor.Requires.Modifier.MANDATED is equating to false >>> because at runtime I see that two different instances of >>> ModuleDescriptor.Requires.Modifier.MANDATED have been loaded (by the >>> same boot module classloader). Although I use >>> ModuleDescriptor.Requires.Modifier.MANDATED as an example, the same >>> is reproducible with other enum values like >>> ModuleDescriptor.Requires.Modifier.TRANSITIVE. >>> >>> This appears to be specific to CDS since running the above program >>> with: >>> >>> java -Xshare:off EnumEquality >>> >>> succeeds and the ModuleDescriptor equality check passes. >>> >>> In short, it looks like there is some general issue with CDS and >>> equality checks with enums and perhaps deserves a separate JBS issue? >> I've asked Ioi Lam to comment on this, off-hand I'm not aware of any >> issues with CDS here but it may be related to the archiving of object >> graphs. >> >> -Alan > > Hi Jaikiran and Alan, > > Thanks for reporting this issue. It's a bug in CDS. I have filed > https://bugs.openjdk.java.net/browse/JDK-8275731 and am working on a fix. Thank you for looking into this. > > This is my initial analysis of the problem. > > ====>>> Can anyone think of similar problems that may happen elsewhere? > > The static constructors of enum classes are executed at both CDS dump > time and run time. E.g., > > ??? public enum Modifier { > ??????? OPEN > ??? } > > The method essentially does this: > > ??? public static final Modifier OPEN = new Modifier("OPEN"); > > If a reference of Modifier.OPEN is stored inside the CDS archived heap > during dump time, it will be different than the value of Modifier.OPEN > that is re-created at runtime by the execution of Modifier. I have almost next to nothing knowledge about CDS internals. My only understanding of it is based on some documentation that I have read. One of them being this one https://docs.oracle.com/en/java/javase/17/vm/class-data-sharing.html#GUID-7EAA3411-8CF0-4D19-BD05-DF5E1780AA91. Based on that documentation (and other similar ones), it was my understanding that CDS was meant to store/share class "metadata" like it states in that doc: "When the JVM starts, the shared archive is memory-mapped to allow sharing of read-only JVM metadata for these classes among multiple JVM processes." But from what you explain in that enum example, it looks like it also stores class instance data that is computed at build time on the host where the JDK image was generated? Did I understand it correctly? Is this only for enums or does it also store the static initialization data of "class" types too? If it does store the static init data of class types too, then wouldn't such data be host/build time specific and as such the classes that need to be enrolled into the default CDS archive of the JDK should be very selective (by reviewing what they do in their static init)? Like I said, I haven't looked into this in detail so perhaps it already is selective in the JDK build? -Jaikiran From duke at openjdk.java.net Fri Oct 22 04:57:12 2021 From: duke at openjdk.java.net (Glavo) Date: Fri, 22 Oct 2021 04:57:12 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v2] In-Reply-To: <9673dBKTx-9BLrJfErLJe1X_0K6yCCCusPhY4LdgoPI=.d0b1df23-bd53-4bae-b972-aec328a41fb5@github.com> References: <9673dBKTx-9BLrJfErLJe1X_0K6yCCCusPhY4LdgoPI=.d0b1df23-bd53-4bae-b972-aec328a41fb5@github.com> Message-ID: On Wed, 20 Oct 2021 19:02:30 GMT, Naoto Sato wrote: >> During the review of JEP 400, a proposal to provide an overloaded method to `Charset.forName()` was suggested [[1]](https://github.com/openjdk/jdk/pull/4733#discussion_r669693954). This PR is to implement the proposal. A CSR is also drafted as https://bugs.openjdk.java.net/browse/JDK-8275348 > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Moved the null sentence into @param tag. Oh, I found that I checked the outdated source code. Now this problem does not exist in `StringCoding`. I simply browsed the latest source code of JDK and found that this idiom no longer appears outside jline. I believe that the source code of jline does not need to be modified in openjdk. But I noticed `LauncherHelper.makePlatformString` (https://github.com/openjdk/jdk/blob/c978ca87de2d9152345dfd85983278c42bb28cd3/src/java.base/share/classes/sun/launcher/LauncherHelper.java#L887) I don't understand why it stores `encoding` string and `isCharsetSupported` boolean values. Nor do I find references to these two fields in native code. I think it can benefit from the improvement in this PR like this? private static final String encprop = "sun.jnu.encoding"; private static Charset charset = null; /* * converts a c or a byte array to a platform specific string, * previously implemented as a native method in the launcher. */ static String makePlatformString(boolean printToStderr, byte[] inArray) { initOutput(printToStderr); if (charset == null) { charset = Charset.forName(encprop, Charset.defaultCharset()); } return new String(inArray, charset); } ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From ioi.lam at oracle.com Fri Oct 22 06:59:37 2021 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 21 Oct 2021 23:59:37 -0700 Subject: JDK-8275509: (jlink) SystemModulesPlugin generates a jdk.internal.module.SystemModules$all.class which isn't reproducible In-Reply-To: <71aeec43-ae77-e1f8-d4e4-c5e2d31289e7@gmail.com> References: <4a4901a8-ca90-c9f3-0b2f-a37e521bfe65@oracle.com> <77faaab4-831c-de4f-2f64-f7305cb8f9fb@gmail.com> <60708e84-4888-9584-50e0-df3ae5d8b0b5@oracle.com> <72b9f8de-c4f9-9509-bf1e-ec6148f40860@gmail.com> <89cad5a5-08f0-3bde-5279-7fcb0550d4db@oracle.com> <122a3aee-42bc-b471-5ba8-eb3bebc5e7bb@oracle.com> <71aeec43-ae77-e1f8-d4e4-c5e2d31289e7@gmail.com> Message-ID: <9ea84f87-b1ce-b1d5-a54b-e7ca547529a6@oracle.com> On 10/21/21 9:09 PM, Jaikiran Pai wrote: > Hello Ioi, > > >> >> This is my initial analysis of the problem. >> >> ====>>> Can anyone think of similar problems that may happen elsewhere? >> >> The static constructors of enum classes are executed at both CDS dump >> time and run time. E.g., >> >> ??? public enum Modifier { >> ??????? OPEN >> ??? } >> >> The method essentially does this: >> >> ??? public static final Modifier OPEN = new Modifier("OPEN"); >> >> If a reference of Modifier.OPEN is stored inside the CDS archived >> heap during dump time, it will be different than the value of >> Modifier.OPEN that is re-created at runtime by the execution of >> Modifier. > > I have almost next to nothing knowledge about CDS internals. My only > understanding of it is based on some documentation that I have read. > One of them being this one > https://docs.oracle.com/en/java/javase/17/vm/class-data-sharing.html#GUID-7EAA3411-8CF0-4D19-BD05-DF5E1780AA91. > > Based on that documentation (and other similar ones), it was my > understanding that CDS was meant to store/share class "metadata" like > it states in that doc: > > "When the JVM starts, the shared archive is memory-mapped to allow > sharing of read-only JVM metadata for these classes among multiple JVM > processes." > > But from what you explain in that enum example, it looks like it also > stores class instance data that is computed at build time on the host > where the JDK image was generated? Did I understand it correctly? Is > this only for enums or does it also store the static initialization > data of "class" types too? If it does store the static init data of > class types too, then wouldn't such data be host/build time specific > and as such the classes that need to be enrolled into the default CDS > archive of the JDK should be very selective (by reviewing what they do > in their static init)? Like I said, I haven't looked into this in > detail so perhaps it already is selective in the JDK build? > Hi Jaikiran, CDS also has the ability to archive Java heap object. Since https://bugs.openjdk.java.net/browse/JDK-8244778 , we have archived the entire module graph to improve start-up time. At run time, the module graph (as well as other archived heap objects) are loaded from the CDS archive and put into the Java heap (either through memory mapping or copying). You can see the related code in jdk.internal.module.ModuleBootstrap::boot() When the module system has started up, the module graph will reference a copy of the OPEN enum object that was created as part of the archive. However, the Modifier. will also be executed at VM start-up, causing a second copy of the OPEN enum object to be stored into the static field Modified::OPEN. When an application tries to get the OPEN enum, it will get the copy stored in the static field Modified::OPEN. If you walk the module graph, you get get a reference to the other copy. Since these are two distinct heap objects, the == operator will return comparing them. Thanks - Ioi From jai.forums2013 at gmail.com Fri Oct 22 08:09:45 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Fri, 22 Oct 2021 13:39:45 +0530 Subject: JDK-8275509: (jlink) SystemModulesPlugin generates a jdk.internal.module.SystemModules$all.class which isn't reproducible In-Reply-To: <9ea84f87-b1ce-b1d5-a54b-e7ca547529a6@oracle.com> References: <4a4901a8-ca90-c9f3-0b2f-a37e521bfe65@oracle.com> <77faaab4-831c-de4f-2f64-f7305cb8f9fb@gmail.com> <60708e84-4888-9584-50e0-df3ae5d8b0b5@oracle.com> <72b9f8de-c4f9-9509-bf1e-ec6148f40860@gmail.com> <89cad5a5-08f0-3bde-5279-7fcb0550d4db@oracle.com> <122a3aee-42bc-b471-5ba8-eb3bebc5e7bb@oracle.com> <71aeec43-ae77-e1f8-d4e4-c5e2d31289e7@gmail.com> <9ea84f87-b1ce-b1d5-a54b-e7ca547529a6@oracle.com> Message-ID: <4efe18eb-2fc0-9a27-87f0-3752d5edd65c@gmail.com> Hello Ioi, On 22/10/21 12:29 pm, Ioi Lam wrote: > > > On 10/21/21 9:09 PM, Jaikiran Pai wrote: >> Hello Ioi, >> >> >>> >>> This is my initial analysis of the problem. >>> >>> ====>>> Can anyone think of similar problems that may happen elsewhere? >>> >>> The static constructors of enum classes are executed at both CDS >>> dump time and run time. E.g., >>> >>> ??? public enum Modifier { >>> ??????? OPEN >>> ??? } >>> >>> The method essentially does this: >>> >>> ??? public static final Modifier OPEN = new Modifier("OPEN"); >>> >>> If a reference of Modifier.OPEN is stored inside the CDS archived >>> heap during dump time, it will be different than the value of >>> Modifier.OPEN that is re-created at runtime by the execution of >>> Modifier. >> >> I have almost next to nothing knowledge about CDS internals. My only >> understanding of it is based on some documentation that I have read. >> One of them being this one >> https://docs.oracle.com/en/java/javase/17/vm/class-data-sharing.html#GUID-7EAA3411-8CF0-4D19-BD05-DF5E1780AA91. >> >> Based on that documentation (and other similar ones), it was my >> understanding that CDS was meant to store/share class "metadata" like >> it states in that doc: >> >> "When the JVM starts, the shared archive is memory-mapped to allow >> sharing of read-only JVM metadata for these classes among multiple >> JVM processes." >> >> But from what you explain in that enum example, it looks like it also >> stores class instance data that is computed at build time on the host >> where the JDK image was generated? Did I understand it correctly? Is >> this only for enums or does it also store the static initialization >> data of "class" types too? If it does store the static init data of >> class types too, then wouldn't such data be host/build time specific >> and as such the classes that need to be enrolled into the default CDS >> archive of the JDK should be very selective (by reviewing what they >> do in their static init)? Like I said, I haven't looked into this in >> detail so perhaps it already is selective in the JDK build? >> > > Hi Jaikiran, > Thank you very much for the detailed response. > CDS also has the ability to archive Java heap object. Since > https://bugs.openjdk.java.net/browse/JDK-8244778 , we have archived > the entire module graph to improve start-up time. At run time, the > module graph (as well as other archived heap objects) are loaded from > the CDS archive and put into the Java heap (either through memory > mapping or copying). That is interesting and something that I hadn't known. > > You can see the related code in > jdk.internal.module.ModuleBootstrap::boot() I just had a look at it and it's quite elaborate and it'll take a me while to fully grasp it (if at all) given its understandable complexity. > > When the module system has started up, the module graph will reference > a copy of the OPEN enum object that was created as part of the > archive. However, the Modifier. will also be executed at VM > start-up, causing a second copy of the OPEN enum object to be stored > into the static field Modified::OPEN. Thank you for that detail. That helps me understand this a bit more (and opens a few questions). To be clear - the VM startup code which creates that other copy, ends up creating that copy because that piece of initialization happens even before the module system has fully started up and created those references from the archived state? Otherwise, the classloaders I believe would be smart enough to not run that static init again, had the module system with that graph from the archived state been fully "up"? So would this mean that this not just impacts enums but essentially every class referenced within the module system (of just boot layer?) that has state which is initialized during static init? To be more precise, consider the very common example of loggers which are typically static initialized and stored in a static (final) field: private static final java.util.logger.Logger logger = Logger.getLogger(SomeClass.class); If the boot layer module graph has any classes which has state like this, it would then mean that if such classes do get initialized very early on during VM startup, then they too are impacted and the module graph holding instances of such classes will end up using a different instance for such fields as compared to the rest of the application code? In essence, such classes which get accessed early (before module system with the archived graph is "up") during VM startup can end up _virtually_ having their static initialization run twice (I understand it won't be run twice, but that's the end result, isn't it)? -Jaikiran From jpai at openjdk.java.net Fri Oct 22 08:56:00 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Fri, 22 Oct 2021 08:56:00 GMT Subject: RFR: 8268595: java/io/Serializable/serialFilter/GlobalFilterTest.java#id1 failed in timeout In-Reply-To: <3utjHiAKf2SmUTuhFh4-9YTk476V2OggSFiIK5mFzj0=.96dcbfb3-8746-477e-8c25-c586cd1f0cc6@github.com> References: <3utjHiAKf2SmUTuhFh4-9YTk476V2OggSFiIK5mFzj0=.96dcbfb3-8746-477e-8c25-c586cd1f0cc6@github.com> Message-ID: On Tue, 19 Oct 2021 13:00:01 GMT, Jaikiran Pai wrote: > The `GlobalFilterTest` has to 2 `@test` tags. One of them has failed with a timeout as noted in https://bugs.openjdk.java.net/browse/JDK-8268595. The timeout seems to have happened even after the tests had already completed successfully. Like I note in the JBS comments of that issue, I suspect it might have to do with the "-XX:StartFlightRecording:name=DeserializationEvent,dumponexit=true" usage in this test action. > > The commit in this PR removes that second `@test` altogether because (correct me if I'm wrong) from what I understand, this test never enables the DeserializationEvent which means there is no JFR events being captured for deserialization in this test, nor does the test do any JFR events related testing. So, I think this second `@test` is virtually a no-op when it comes to the JFR testing. There's a separate `TestDeserializationEvent` which has a comprehensive testing of the DeserializationEvent. Roger, I think you meant to mention @ChrisHegarty and not chegar? ------------- PR: https://git.openjdk.java.net/jdk/pull/6008 From jpai at openjdk.java.net Fri Oct 22 09:41:30 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Fri, 22 Oct 2021 09:41:30 GMT Subject: RFR: 8275509: ModuleDescriptor.hashCode isn't reproducible across builds Message-ID: Can I please get a review for this change which fixes the issue reported in https://bugs.openjdk.java.net/browse/JDK-8275509? The `ModuleDescriptor.hashCode()` method uses the hash code of its various components to compute the final hash code. While doing so it ends up calling hashCode() on (collection of) various `enum` types. Since the hashCode() of enum types is generated from a call to `java.lang.Object.hashCode()`, their value isn't guaranteed to stay the same across multiple JVM runs. The commit here proposes to use the ordinal of the enum as the hash code. As Alan notes in the mailing list discussion, any changes to the ordinal of the enum (either due to addition of new value, removal of a value or just reordering existing values, all of which I think will be rare in these specific enum types) isn't expected to produce the same hash code across those changed runtimes and that should be okay. The rest of the ModuleDescriptor.hashCode() has been reviewed too and apart from calls to the enum types hashCode(), rest of the calls in that implementation, either directly or indirectly end up as calls on `java.lang.String.hashCode()` and as such aren't expected to cause non-deterministic values. A new jtreg test has been added to reproduce this issue and verify the fix. ------------- Commit messages: - minor test comment fix - 8275509: ModuleDescriptor.hashCode isn't reproducible across builds Changes: https://git.openjdk.java.net/jdk/pull/6078/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6078&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275509 Stats: 178 lines in 2 files changed: 174 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/6078.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6078/head:pull/6078 PR: https://git.openjdk.java.net/jdk/pull/6078 From alanb at openjdk.java.net Fri Oct 22 10:20:05 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 22 Oct 2021 10:20:05 GMT Subject: RFR: 8275509: ModuleDescriptor.hashCode isn't reproducible across builds In-Reply-To: References: Message-ID: On Fri, 22 Oct 2021 09:33:35 GMT, Jaikiran Pai wrote: > Can I please get a review for this change which fixes the issue reported in https://bugs.openjdk.java.net/browse/JDK-8275509? > > The `ModuleDescriptor.hashCode()` method uses the hash code of its various components to compute the final hash code. While doing so it ends up calling hashCode() on (collection of) various `enum` types. Since the hashCode() of enum types is generated from a call to `java.lang.Object.hashCode()`, their value isn't guaranteed to stay the same across multiple JVM runs. > > The commit here proposes to use the ordinal of the enum as the hash code. As Alan notes in the mailing list discussion, any changes to the ordinal of the enum (either due to addition of new value, removal of a value or just reordering existing values, all of which I think will be rare in these specific enum types) isn't expected to produce the same hash code across those changed runtimes and that should be okay. > > The rest of the ModuleDescriptor.hashCode() has been reviewed too and apart from calls to the enum types hashCode(), rest of the calls in that implementation, either directly or indirectly end up as calls on `java.lang.String.hashCode()` and as such aren't expected to cause non-deterministic values. > > A new jtreg test has been added to reproduce this issue and verify the fix. src/java.base/share/classes/java/lang/module/ModuleDescriptor.java line 2559: > 2557: continue; > 2558: } > 2559: h += e.ordinal(); This e == null check suggests there is an issue elsewhere, can you explain the scenario where you see this? Also can you drop the spurious use of "final" here, it's inconsistent with the existing code. Do you want us to look at the test? It looks like it needs clean-up and I'm not sure if you want to wait for the CDS issue or not. ------------- PR: https://git.openjdk.java.net/jdk/pull/6078 From jpai at openjdk.java.net Fri Oct 22 10:39:34 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Fri, 22 Oct 2021 10:39:34 GMT Subject: RFR: 8275509: ModuleDescriptor.hashCode isn't reproducible across builds [v2] In-Reply-To: References: Message-ID: <7Q31qbS249wAuGxCY6FCh7IV77aCIimBSnTHXfQR7HE=.9c891d45-4257-4586-a458-d52b5a5a004b@github.com> > Can I please get a review for this change which fixes the issue reported in https://bugs.openjdk.java.net/browse/JDK-8275509? > > The `ModuleDescriptor.hashCode()` method uses the hash code of its various components to compute the final hash code. While doing so it ends up calling hashCode() on (collection of) various `enum` types. Since the hashCode() of enum types is generated from a call to `java.lang.Object.hashCode()`, their value isn't guaranteed to stay the same across multiple JVM runs. > > The commit here proposes to use the ordinal of the enum as the hash code. As Alan notes in the mailing list discussion, any changes to the ordinal of the enum (either due to addition of new value, removal of a value or just reordering existing values, all of which I think will be rare in these specific enum types) isn't expected to produce the same hash code across those changed runtimes and that should be okay. > > The rest of the ModuleDescriptor.hashCode() has been reviewed too and apart from calls to the enum types hashCode(), rest of the calls in that implementation, either directly or indirectly end up as calls on `java.lang.String.hashCode()` and as such aren't expected to cause non-deterministic values. > > A new jtreg test has been added to reproduce this issue and verify the fix. Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision: - drop final - no need to check for null values ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6078/files - new: https://git.openjdk.java.net/jdk/pull/6078/files/f583dce3..c4ad8067 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6078&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6078&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6078.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6078/head:pull/6078 PR: https://git.openjdk.java.net/jdk/pull/6078 From jpai at openjdk.java.net Fri Oct 22 10:39:38 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Fri, 22 Oct 2021 10:39:38 GMT Subject: RFR: 8275509: ModuleDescriptor.hashCode isn't reproducible across builds [v2] In-Reply-To: References: Message-ID: On Fri, 22 Oct 2021 10:17:13 GMT, Alan Bateman wrote: >> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision: >> >> - drop final >> - no need to check for null values > > src/java.base/share/classes/java/lang/module/ModuleDescriptor.java line 2559: > >> 2557: continue; >> 2558: } >> 2559: h += e.ordinal(); > > This e == null check suggests there is an issue elsewhere, can you explain the scenario where you see this? Also can you drop the spurious use of "final" here, it's inconsistent with the existing code. > > Do you want us to look at the test? It looks like it needs clean-up and I'm not sure if you want to wait for the CDS issue or not. Hello Alan, > This e == null check suggests there is an issue elsewhere, can you explain the scenario where you see this? That was just a pre-emptive defensive check I had added. There isn't a scenario in that flow where any of the elements are currently null. I have updated this PR to remove that check. Test continues to pass with this change. Also removed the "final". > Do you want us to look at the test? It looks like it needs clean-up and I'm not sure if you want to wait for the CDS issue or not. Yes please. The test is ready for review. The only place where there's a `TODO` is where that part of commented code is affected by the bug mentioned in that comment. I would like to use that check (the commented out one) but I don't want to wait for that other bug to be fixed for this PR, since I am unsure how big or how long it might take for the other bug to be fixed. I plan to uncomment that part in a separate PR once that other bug is fixed, if that's OK. ------------- PR: https://git.openjdk.java.net/jdk/pull/6078 From jpai at openjdk.java.net Fri Oct 22 10:44:31 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Fri, 22 Oct 2021 10:44:31 GMT Subject: RFR: 8275509: ModuleDescriptor.hashCode isn't reproducible across builds [v3] In-Reply-To: References: Message-ID: > Can I please get a review for this change which fixes the issue reported in https://bugs.openjdk.java.net/browse/JDK-8275509? > > The `ModuleDescriptor.hashCode()` method uses the hash code of its various components to compute the final hash code. While doing so it ends up calling hashCode() on (collection of) various `enum` types. Since the hashCode() of enum types is generated from a call to `java.lang.Object.hashCode()`, their value isn't guaranteed to stay the same across multiple JVM runs. > > The commit here proposes to use the ordinal of the enum as the hash code. As Alan notes in the mailing list discussion, any changes to the ordinal of the enum (either due to addition of new value, removal of a value or just reordering existing values, all of which I think will be rare in these specific enum types) isn't expected to produce the same hash code across those changed runtimes and that should be okay. > > The rest of the ModuleDescriptor.hashCode() has been reviewed too and apart from calls to the enum types hashCode(), rest of the calls in that implementation, either directly or indirectly end up as calls on `java.lang.String.hashCode()` and as such aren't expected to cause non-deterministic values. > > A new jtreg test has been added to reproduce this issue and verify the fix. Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: drop another final to make it consistent with rest of the code ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6078/files - new: https://git.openjdk.java.net/jdk/pull/6078/files/c4ad8067..89669ea4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6078&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6078&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6078.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6078/head:pull/6078 PR: https://git.openjdk.java.net/jdk/pull/6078 From herrick at openjdk.java.net Fri Oct 22 12:21:09 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Fri, 22 Oct 2021 12:21:09 GMT Subject: Integrated: JDK-8263155: Allow additional contents for DMG In-Reply-To: References: Message-ID: <-_552gNE6yv75GFeWqFdIE-iRTfBMVZSlePVvmrqkhI=.e5e4f744-92b6-4e11-8c4b-f2e29cd03606@github.com> On Tue, 12 Oct 2021 16:47:04 GMT, Andy Herrick wrote: > JDK-8263155: Allow additional contents for DMG This pull request has now been integrated. Changeset: b2128a96 Author: Andy Herrick URL: https://git.openjdk.java.net/jdk/commit/b2128a96670daeca93aca84ee7613b2b337ddfa4 Stats: 171 lines in 8 files changed: 154 ins; 1 del; 16 mod 8263155: Allow additional contents for DMG Reviewed-by: asemenyuk, almatvee ------------- PR: https://git.openjdk.java.net/jdk/pull/5912 From rriggs at openjdk.java.net Fri Oct 22 14:14:08 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 22 Oct 2021 14:14:08 GMT Subject: RFR: 8268595: java/io/Serializable/serialFilter/GlobalFilterTest.java#id1 failed in timeout In-Reply-To: <3utjHiAKf2SmUTuhFh4-9YTk476V2OggSFiIK5mFzj0=.96dcbfb3-8746-477e-8c25-c586cd1f0cc6@github.com> References: <3utjHiAKf2SmUTuhFh4-9YTk476V2OggSFiIK5mFzj0=.96dcbfb3-8746-477e-8c25-c586cd1f0cc6@github.com> Message-ID: On Tue, 19 Oct 2021 13:00:01 GMT, Jaikiran Pai wrote: > The `GlobalFilterTest` has to 2 `@test` tags. One of them has failed with a timeout as noted in https://bugs.openjdk.java.net/browse/JDK-8268595. The timeout seems to have happened even after the tests had already completed successfully. Like I note in the JBS comments of that issue, I suspect it might have to do with the "-XX:StartFlightRecording:name=DeserializationEvent,dumponexit=true" usage in this test action. > > The commit in this PR removes that second `@test` altogether because (correct me if I'm wrong) from what I understand, this test never enables the DeserializationEvent which means there is no JFR events being captured for deserialization in this test, nor does the test do any JFR events related testing. So, I think this second `@test` is virtually a no-op when it comes to the JFR testing. There's a separate `TestDeserializationEvent` which has a comprehensive testing of the DeserializationEvent. Yes, I meant @ChrisHegarty. tnx. ------------- PR: https://git.openjdk.java.net/jdk/pull/6008 From aefimov at openjdk.java.net Fri Oct 22 14:27:41 2021 From: aefimov at openjdk.java.net (Aleksei Efimov) Date: Fri, 22 Oct 2021 14:27:41 GMT Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v7] In-Reply-To: References: Message-ID: > This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver. > > The following API classes are added to `java.net.spi` package to facilitate this: > - `InetAddressResolverProvider` - abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers. > - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations. > - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations. > - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation. > > More details in [JEP-418](https://openjdk.java.net/jeps/418). > > Testing: new and existing `tier1:tier3` tests Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision: More javadoc updates to API classes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5822/files - new: https://git.openjdk.java.net/jdk/pull/5822/files/2a554c91..fa655be2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5822&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5822&range=05-06 Stats: 88 lines in 3 files changed: 22 ins; 8 del; 58 mod Patch: https://git.openjdk.java.net/jdk/pull/5822.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5822/head:pull/5822 PR: https://git.openjdk.java.net/jdk/pull/5822 From aefimov at openjdk.java.net Fri Oct 22 15:17:04 2021 From: aefimov at openjdk.java.net (Aleksei Efimov) Date: Fri, 22 Oct 2021 15:17:04 GMT Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v5] In-Reply-To: References: Message-ID: On Wed, 20 Oct 2021 15:41:35 GMT, Daniel Fuchs wrote: >> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision: >> >> Change InetAddressResolver method names > > Marked as reviewed by dfuchs (Reviewer). @dfuch @AlanBateman fa655be2bb0a402b70916567d34cc29a7898f938 and 2a554c91864e3b42a0ea315b0a671782fe341927 contain reworked `InetAddress`/`InetAddressResolverProvider`/`InetAddressResolver` specs with the following changes: - `InetAddress Resolver Providers` InetAddress section was modified and moved to `InetAddressResolverProvider`. - `Host Name Resolution` InetAddress section was updated to reference new InetAddress resolver SPI. - Changes for previous review comments. - javadoc formatting clean-up ------------- PR: https://git.openjdk.java.net/jdk/pull/5822 From naoto at openjdk.java.net Fri Oct 22 16:24:05 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 22 Oct 2021 16:24:05 GMT Subject: RFR: 8273111: Default timezone should return zone ID if /etc/localtime is valid but not canonicalization on linux [v5] In-Reply-To: References: <6gmVj3r1hjhG5jvo_dSly3ShNnZZSCn-NIjtnvSySrk=.a88def27-7b80-425b-9ab8-2f94f5004b47@github.com> Message-ID: On Tue, 19 Oct 2021 04:08:12 GMT, Wu Yan wrote: >> Hi, >> Please help me review the change to enhance getting time zone ID from /etc/localtime on linux. >> >> We use `realpath` instead of `readlink` to obtain the link name of /etc/localtime, because `readlink` can only read the value of a symbolic of link, not the canonicalized absolute pathname. >> >> For example, the value of /etc/localtime is "../usr/share/zoneinfo//Asia/Shanghai", then the linkbuf obtained by `readlink` is "../usr/share/zoneinfo//Asia/Shanghai", and then the call of `getZoneName(linkbuf)` will get "/Asia/Shanghai", not "Asia/Shanghai", which consider as invalid in `ZoneInfoFile.getZoneInfo()`. Using `realpath`, you can get ?/usr/share/zoneinfo/Asia/Shanghai? directly from ?/etc/localtime?. >> >> Thanks, >> wuyan > > Wu Yan has updated the pull request incrementally with one additional commit since the last revision: > > fix code style Looks good. Thanks for the fix. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5327 From wuyan at openjdk.java.net Fri Oct 22 16:26:21 2021 From: wuyan at openjdk.java.net (Wu Yan) Date: Fri, 22 Oct 2021 16:26:21 GMT Subject: Integrated: 8273111: Default timezone should return zone ID if /etc/localtime is valid but not canonicalization on linux In-Reply-To: <6gmVj3r1hjhG5jvo_dSly3ShNnZZSCn-NIjtnvSySrk=.a88def27-7b80-425b-9ab8-2f94f5004b47@github.com> References: <6gmVj3r1hjhG5jvo_dSly3ShNnZZSCn-NIjtnvSySrk=.a88def27-7b80-425b-9ab8-2f94f5004b47@github.com> Message-ID: On Wed, 1 Sep 2021 06:45:26 GMT, Wu Yan wrote: > Hi, > Please help me review the change to enhance getting time zone ID from /etc/localtime on linux. > > We use `realpath` instead of `readlink` to obtain the link name of /etc/localtime, because `readlink` can only read the value of a symbolic of link, not the canonicalized absolute pathname. > > For example, the value of /etc/localtime is "../usr/share/zoneinfo//Asia/Shanghai", then the linkbuf obtained by `readlink` is "../usr/share/zoneinfo//Asia/Shanghai", and then the call of `getZoneName(linkbuf)` will get "/Asia/Shanghai", not "Asia/Shanghai", which consider as invalid in `ZoneInfoFile.getZoneInfo()`. Using `realpath`, you can get ?/usr/share/zoneinfo/Asia/Shanghai? directly from ?/etc/localtime?. > > Thanks, > wuyan This pull request has now been integrated. Changeset: 88bbf3c2 Author: Wu Yan Committer: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/88bbf3c2e6ac9f6d88cbb361cfbb4c16bb8eafc1 Stats: 352 lines in 4 files changed: 203 ins; 145 del; 4 mod 8273111: Default timezone should return zone ID if /etc/localtime is valid but not canonicalization on linux Co-authored-by: Sun Jianye Reviewed-by: naoto, mli ------------- PR: https://git.openjdk.java.net/jdk/pull/5327 From naoto at openjdk.java.net Fri Oct 22 17:33:43 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 22 Oct 2021 17:33:43 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v3] In-Reply-To: References: Message-ID: <7IjiRqEGugX1DiruWOX9zP7nh9b7zUc0EwCOMGpNspE=.e5c488da-e4b3-42bf-852e-e45506906fa0@github.com> > During the review of JEP 400, a proposal to provide an overloaded method to `Charset.forName()` was suggested [[1]](https://github.com/openjdk/jdk/pull/4733#discussion_r669693954). This PR is to implement the proposal. A CSR is also drafted as https://bugs.openjdk.java.net/browse/JDK-8275348 Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Removed `@throws IllegalCharsetNameException` ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6045/files - new: https://git.openjdk.java.net/jdk/pull/6045/files/4c2142be..7c73c5ba Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6045&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6045&range=01-02 Stats: 32 lines in 3 files changed: 6 ins; 22 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/6045.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6045/head:pull/6045 PR: https://git.openjdk.java.net/jdk/pull/6045 From naoto at openjdk.java.net Fri Oct 22 17:38:08 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 22 Oct 2021 17:38:08 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v2] In-Reply-To: References: <9673dBKTx-9BLrJfErLJe1X_0K6yCCCusPhY4LdgoPI=.d0b1df23-bd53-4bae-b972-aec328a41fb5@github.com> <2dVpiRSN-mhp69KZZ9jIUc7O1YiJ3CP5H1uRlEI7nMY=.3d5733d0-7d66-422d-8c21-01aea560f9cf@github.com> Message-ID: On Fri, 22 Oct 2021 02:07:44 GMT, Sergey Bylokhov wrote: >> I first thought of swallowing all exceptions in 2-arg forName(), but decided not to do that. Because `IllegalArgumentException` and `IllegalCharsetNameException` are for the validity of the passed `charsetName`, like detecting `null` or invalid chars like "??". On the other hand, `UnsupportedCharsetException` is for the availability which varies depending on the user's settings and or platform, which can be safely replaced with `fallback` charset. So yes, it is not totally getting rid of `try-catch` but it avoids `UnsupportedCharsetException` which is only detectable at runtime. > > Then what is the benefit, if the user will have to write such code anyway?: > > try { > cs = Charset.forName(StaticProperty.nativeEncoding(), fallback); > } catch (Exception ignored) { > cs = fallback; > } > > Even in the current code update it can work well w/o the second parameter. OK, I revised the API to swallow `IllegalCharsetNameException`. This will effectively remove try-catch clauses, as `IllegalArgumentException` is considered an error, and simply avoided by a null check. ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From naoto at openjdk.java.net Fri Oct 22 17:38:07 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 22 Oct 2021 17:38:07 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v2] In-Reply-To: References: <9673dBKTx-9BLrJfErLJe1X_0K6yCCCusPhY4LdgoPI=.d0b1df23-bd53-4bae-b972-aec328a41fb5@github.com> Message-ID: On Fri, 22 Oct 2021 04:54:35 GMT, Glavo wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Moved the null sentence into @param tag. > > Oh, I found that I checked the outdated source code. Now this problem does not exist in `StringCoding`. > > I simply browsed the latest source code of JDK and found that this idiom no longer appears outside jline. I believe that the source code of jline does not need to be modified in openjdk. > > But I noticed `LauncherHelper.makePlatformString` (https://github.com/openjdk/jdk/blob/c978ca87de2d9152345dfd85983278c42bb28cd3/src/java.base/share/classes/sun/launcher/LauncherHelper.java#L887) > > I don't understand why it stores `encoding` string and `isCharsetSupported` boolean values. Nor do I find references to these two fields in native code. I think it may be improved in this PR like this: > > > > private static final String encprop = "sun.jnu.encoding"; > private static Charset charset = null; > > /* > * converts a c or a byte array to a platform specific string, > * previously implemented as a native method in the launcher. > */ > static String makePlatformString(boolean printToStderr, byte[] inArray) { > initOutput(printToStderr); > if (charset == null) { > charset = Charset.forName(System.getProperty(encprop), Charset.defaultCharset()); > } > return new String(inArray, charset); > } @Glavo, thank you for the suggestions. Although applying the new method in the JDK code would be useful, I'd keep this PR just to introduce this new method. ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From prr at openjdk.java.net Fri Oct 22 19:09:21 2021 From: prr at openjdk.java.net (Phil Race) Date: Fri, 22 Oct 2021 19:09:21 GMT Subject: RFR: 8275170: Some jtreg sound tests should be marked headful Message-ID: This fix adds "headful sound" keywords to a number of javax/sound jtreg tests The jtreg javax.sound tests are written in such a way that if a needed audio device or other platform resource is not available, they just exit with a "pass" for the test. It is as if headful tests just swallowed HeadlessException and issued a pass. If we allowed that we'd be effectively testing almost nothing of real importance. Currently almost all sound tests have no keyword like "headful" to indicate they may need access to a hardware resource to do anything useful so a similar situation arises there except when someone runs those tests manually on a local system which has audio devices. Of course "headful" and "audio device" aren't exactly interchangeable terms but if tests are allowed to be run - or worse usually or always run - in a situation where they potentially are on a system without an audio device (a headless VM) or are running in a session which doesn't have full desktop access - which may in some cases be how audio device access is granted, then they are more likely to be running in this scenario where the testing isn't valid. Another point is that headful tests must be run one at a time - no concurrency because you can't have multiple tests moving the mouse at the same time Whereas for headless tests, a test harness may choose to run concurrently - perhaps even in the same VM When tests that really need access to an audio device are run it is probably safer to consider the headful attribute as implying one test at a time is best .. granted on a desktop it isn't usual for a single app to be able to monopolize access to a speaker, but for input devices that is what you'd generally expect. By no means am I sure that the tests being updated here are the full set that need tagging. There are a lot of tests and they are all known to pass on systems with NO audio devices, so the search has been for tests which call APIs which will definitely need access to some device in order to do anything useful. So likely there are more to be added - either by a reviewer pointing them out or by later discovery. Alternatively we could mark ALL sound tests headful .. but given where we are starting from that might be erring unnecessarily far in the opposite direction. By adding both headful and sound keywords it gives options to someone who wants to identify the tests and perhaps run just tests which need "sound" on some config they know supports audio but isn't headful. ------------- Commit messages: - 8275170: Some jtreg sound tests should be marked headful Changes: https://git.openjdk.java.net/jdk/pull/6086/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6086&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275170 Stats: 63 lines in 58 files changed: 59 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/6086.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6086/head:pull/6086 PR: https://git.openjdk.java.net/jdk/pull/6086 From rriggs at openjdk.java.net Fri Oct 22 20:06:08 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 22 Oct 2021 20:06:08 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v3] In-Reply-To: <7IjiRqEGugX1DiruWOX9zP7nh9b7zUc0EwCOMGpNspE=.e5c488da-e4b3-42bf-852e-e45506906fa0@github.com> References: <7IjiRqEGugX1DiruWOX9zP7nh9b7zUc0EwCOMGpNspE=.e5c488da-e4b3-42bf-852e-e45506906fa0@github.com> Message-ID: On Fri, 22 Oct 2021 17:33:43 GMT, Naoto Sato wrote: >> During the review of JEP 400, a proposal to provide an overloaded method to `Charset.forName()` was suggested [[1]](https://github.com/openjdk/jdk/pull/4733#discussion_r669693954). This PR is to implement the proposal. A CSR is also drafted as https://bugs.openjdk.java.net/browse/JDK-8275348 > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Removed `@throws IllegalCharsetNameException` Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From duke at openjdk.java.net Fri Oct 22 22:21:14 2021 From: duke at openjdk.java.net (duke) Date: Fri, 22 Oct 2021 22:21:14 GMT Subject: Withdrawn: 8268788: Annotations with lambda expressions can still cause AnnotationFormatError In-Reply-To: References: Message-ID: On Wed, 30 Jun 2021 20:08:27 GMT, Sergei Ustimenko wrote: > Change #3294 helps to avoid `AnnotaionFormatException` in `sun.reflect.annotation.AnnotationInvocationHandler.validateAnnotationMethods`. While it fixes the case with e.g. `Runnable` that generates the synthetic method without parameters, validation still fails on synthetic methods that have parameters e.g. `Function`, `BiFunction`, etc. > > This change removes the restriction on parameters count to be zero i.e. lambdas with parameters > would be skipped from validation. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/4642 From serb at openjdk.java.net Sat Oct 23 01:38:02 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sat, 23 Oct 2021 01:38:02 GMT Subject: RFR: 8275170: Some jtreg sound tests should be marked headful In-Reply-To: References: Message-ID: On Fri, 22 Oct 2021 19:01:27 GMT, Phil Race wrote: > This fix adds "headful sound" keywords to a number of javax/sound jtreg tests > > The jtreg javax.sound tests are written in such a way that if a needed audio device > or other platform resource is not available, they just exit with a "pass" for the test. > It is as if headful tests just swallowed HeadlessException and issued a pass. > If we allowed that we'd be effectively testing almost nothing of real importance. > > Currently almost all sound tests have no keyword like "headful" to indicate they > may need access to a hardware resource to do anything useful so a similar > situation arises there except when someone runs those tests manually on > a local system which has audio devices. > > Of course "headful" and "audio device" aren't exactly interchangeable terms > but if tests are allowed to be run - or worse usually or always run - in a situation > where they potentially are on a system without an audio device (a headless VM) or are running in > a session which doesn't have full desktop access - which may in some > cases be how audio device access is granted, then they are more likely > to be running in this scenario where the testing isn't valid. > > Another point is that headful tests must be run one at a time - no concurrency because > you can't have multiple tests moving the mouse at the same time > Whereas for headless tests, a test harness may choose to run concurrently - perhaps even in the same VM > When tests that really need access to an audio device are run it is probably safer to consider > the headful attribute as implying one test at a time is best .. granted on a desktop it isn't > usual for a single app to be able to monopolize access to a speaker, but for input devices > that is what you'd generally expect. > > By no means am I sure that the tests being updated here are the full set that need tagging. > There are a lot of tests and they are all known to pass on systems with NO audio > devices, so the search has been for tests which call APIs which will definitely > need access to some device in order to do anything useful. > So likely there are more to be added - either by a reviewer pointing them out or by later discovery. > Alternatively we could mark ALL sound tests headful .. but given where we are starting from > that might be erring unnecessarily far in the opposite direction. > > By adding both headful and sound keywords it gives options to someone who > wants to identify the tests and perhaps run just tests which need "sound" on some > config they know supports audio but isn't headful. I am not sure this is the right thing to do, as you pointed out the headless system may or may not have the sound configured, similar to the headful system may not have a sound. I see a lot of headful systems in the cloud where the audio device is not configured, and the opposite where the headless system actually has some audio devices. And this change just makes things complicated by assignee the headful keyword to the unrelated sound system. Actually, it is the step in the opposite direction that was done when these tests were moved to tier3, at that the headful keyword was removed from these tests to make tier3 coverage as much as possible. I am still not sure what problem do you want to solve? If the problem is to run the tests on the system where the sound is configured then just run them there, so it will not be necessary to validate each test does it really need a sound/headful keyword or not, otherwise what is the benefit? ------------- PR: https://git.openjdk.java.net/jdk/pull/6086 From serb at openjdk.java.net Sat Oct 23 01:46:07 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sat, 23 Oct 2021 01:46:07 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v3] In-Reply-To: <7IjiRqEGugX1DiruWOX9zP7nh9b7zUc0EwCOMGpNspE=.e5c488da-e4b3-42bf-852e-e45506906fa0@github.com> References: <7IjiRqEGugX1DiruWOX9zP7nh9b7zUc0EwCOMGpNspE=.e5c488da-e4b3-42bf-852e-e45506906fa0@github.com> Message-ID: On Fri, 22 Oct 2021 17:33:43 GMT, Naoto Sato wrote: >> During the review of JEP 400, a proposal to provide an overloaded method to `Charset.forName()` was suggested [[1]](https://github.com/openjdk/jdk/pull/4733#discussion_r669693954). This PR is to implement the proposal. A CSR is also drafted as https://bugs.openjdk.java.net/browse/JDK-8275348 > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Removed `@throws IllegalCharsetNameException` src/java.base/share/classes/java/io/Console.java line 589: > 587: } > 588: if (cs == null) { > 589: cs = Charset.forName(StaticProperty.nativeEncoding(), Charset.defaultCharset()); Not sure but looks like this class tries to maintain 80 chars per line rule? ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From itakiguchi at openjdk.java.net Sat Oct 23 03:19:06 2021 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Sat, 23 Oct 2021 03:19:06 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v3] In-Reply-To: <7IjiRqEGugX1DiruWOX9zP7nh9b7zUc0EwCOMGpNspE=.e5c488da-e4b3-42bf-852e-e45506906fa0@github.com> References: <7IjiRqEGugX1DiruWOX9zP7nh9b7zUc0EwCOMGpNspE=.e5c488da-e4b3-42bf-852e-e45506906fa0@github.com> Message-ID: <7GKyMwKrVn66eA1mqrp_OVlLh6G0hwAIfdiJToM6S78=.0fcdd0c8-09da-4c32-8eb6-bd6181ae5d71@github.com> On Fri, 22 Oct 2021 17:33:43 GMT, Naoto Sato wrote: >> During the review of JEP 400, a proposal to provide an overloaded method to `Charset.forName()` was suggested [[1]](https://github.com/openjdk/jdk/pull/4733#discussion_r669693954). This PR is to implement the proposal. A CSR is also drafted as https://bugs.openjdk.java.net/browse/JDK-8275348 > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Removed `@throws IllegalCharsetNameException` About javadoc, I think following description is not clear. * @param fallback * fallback charset in case the charset object for the named * charset is not available. May be {@code null} ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From duke at openjdk.java.net Sat Oct 23 06:39:10 2021 From: duke at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Sat, 23 Oct 2021 06:39:10 GMT Subject: RFR: 8275512: Upgrade required version of jtreg to 6.1 [v2] In-Reply-To: References: <8ZF_bktOd9u8s06pS5q_VfPnDplwwjhlpz8pdLyHnvw=.67c1b571-5f34-4251-9872-34ccb89dbd5a@github.com> Message-ID: On Wed, 20 Oct 2021 09:28:30 GMT, Leslie Zhai wrote: > requires jtreg version 6.1 b1 or higher This confused me a bit too; I was using jtreg-6+1.tar.gz from [Adoption Group build](https://ci.adoptopenjdk.net/view/Dependencies/job/dependency_pipeline/lastSuccessfulBuild/artifact/jtreg/), and apparently 6+1 is 6.0b1, not 6.1. For now I'm using jtregtip. ------------- PR: https://git.openjdk.java.net/jdk/pull/6012 From alanb at openjdk.java.net Sat Oct 23 06:46:04 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 23 Oct 2021 06:46:04 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v3] In-Reply-To: <7IjiRqEGugX1DiruWOX9zP7nh9b7zUc0EwCOMGpNspE=.e5c488da-e4b3-42bf-852e-e45506906fa0@github.com> References: <7IjiRqEGugX1DiruWOX9zP7nh9b7zUc0EwCOMGpNspE=.e5c488da-e4b3-42bf-852e-e45506906fa0@github.com> Message-ID: On Fri, 22 Oct 2021 17:33:43 GMT, Naoto Sato wrote: >> During the review of JEP 400, a proposal to provide an overloaded method to `Charset.forName()` was suggested [[1]](https://github.com/openjdk/jdk/pull/4733#discussion_r669693954). This PR is to implement the proposal. A CSR is also drafted as https://bugs.openjdk.java.net/browse/JDK-8275348 > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Removed `@throws IllegalCharsetNameException` I think you'll need to adjust the description make it clear that "fallback" is used when the input is not a legal charset name or the charset is not available. ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From alanb at openjdk.java.net Sat Oct 23 07:04:05 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 23 Oct 2021 07:04:05 GMT Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v7] In-Reply-To: References: Message-ID: <8edQIj95FsYJ3_gmv98KEIVAwFvNxduvXIgrkY96vSk=.6d3f216f-c956-4906-8b81-5f57a79d00d9@github.com> On Fri, 22 Oct 2021 14:27:41 GMT, Aleksei Efimov wrote: >> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver. >> >> The following API classes are added to `java.net.spi` package to facilitate this: >> - `InetAddressResolverProvider` - abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers. >> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations. >> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations. >> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation. >> >> More details in [JEP-418](https://openjdk.java.net/jeps/418). >> >> Testing: new and existing `tier1:tier3` tests > > Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision: > > More javadoc updates to API classes I've done another pass over the API. Overall it's looking very good and my comments are just to improve the javadoc in a few places to make it clearer. src/java.base/share/classes/java/net/InetAddress.java line 169: > 167: * Access Protocol (LDAP). > 168: * The particular naming services that the built-in resolver uses by default > 169: * depend on the configuration of the local machine. depend -> depends src/java.base/share/classes/java/net/spi/InetAddressResolver.java line 38: > 36: * deployed as a > 37: * system-wide resolver. {@link InetAddress} delegates all lookup requests to > 38: * the deployed system-wide resolver instance. I think the class description would be a bit clearer if we drop sentence 2 because it overlaps with paragraph 2. I think we can adjust sentence 3 to "InetAddress delegates all lookup operations to the system-wide resolver" and it will all flow nicely. src/java.base/share/classes/java/net/spi/InetAddressResolver.java line 88: > 86: * to a valid IP address length > 87: */ > 88: String lookupByAddress(byte[] addr) throws UnknownHostException; I assume this throws NPE if addr is null. src/java.base/share/classes/java/net/spi/InetAddressResolver.java line 137: > 135: /** > 136: * This factory method creates {@link LookupPolicy LookupPolicy} instance with a provided > 137: * {@code characteristics} value. This should be "This factory method creates a LookupPolicy ...". src/java.base/share/classes/java/net/spi/InetAddressResolverProvider.java line 45: > 43: * system-wide resolver instance, which is used by > 44: * > 45: * InetAddress. I think we should prune some some of the text from the class description to avoid repetition. Here's a suggestion: 1. Add the following immediately after the sentence "A given innovation ..." "It is set after the VM is fully initialized and when an invocation of a method in InetAddress class triggers the first lookup operation. 2. Replace the text in L47-65 with: "A resolver provider is located and loaded by InetAddress to create the systwm-wide resolver as follows: 3. Replace the remaining three usages of "install" with "set". ------------- PR: https://git.openjdk.java.net/jdk/pull/5822 From alanb at openjdk.java.net Sat Oct 23 07:04:06 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 23 Oct 2021 07:04:06 GMT Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v5] In-Reply-To: <1v6OpqkyZp6XBq9lXQfahKEEgtBIdPjNWydqJ9Cwipc=.959e01c2-1e2d-4540-8ed5-41198dd71c2b@github.com> References: <1v6OpqkyZp6XBq9lXQfahKEEgtBIdPjNWydqJ9Cwipc=.959e01c2-1e2d-4540-8ed5-41198dd71c2b@github.com> Message-ID: On Wed, 20 Oct 2021 18:25:24 GMT, Alan Bateman wrote: >> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision: >> >> Change InetAddressResolver method names > > src/java.base/share/classes/java/net/spi/InetAddressResolverProvider.java line 52: > >> 50: /** >> 51: * Initialise and return the {@link InetAddressResolver} provided by >> 52: * this provider. This method is called by {@link InetAddress} when > > "the InetAddressResolver" suggests there is just one instance. That is probably the case but I don't think you want to be restricted to that. Initialise -> Initialize to be consistent with other usages that use US spelling. ------------- PR: https://git.openjdk.java.net/jdk/pull/5822 From jincheng at ca.ibm.com Sat Oct 23 15:03:19 2021 From: jincheng at ca.ibm.com (Cheng Jin) Date: Sat, 23 Oct 2021 11:03:19 -0400 Subject: Incorrect assumption on the class name in compile(InputSource input, String name) at XSLTC.java Message-ID: Hi there, The code in compile(InputSource input, String name) at https://github.com/openjdk/jdk/blob/master/src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/XSLTC.java seems incorrect as follows: public boolean compile(InputSource input, String name) { try { // Reset globals in case we're called by compile(ArrayList v); reset(); // The systemId may not be set, so we'll have to check the URL String systemId = null; if (input != null) { systemId = input.getSystemId(); } // Set the translet class name if not already set if (_className == null) { if (name != null) { setClassName(name); } else if (systemId != null && !systemId.equals("")) { setClassName(Util.baseName(systemId)); <------- incorrect here } // Ensure we have a non-empty class name at this point if (_className == null || _className.length() == 0) { setClassName("GregorSamsa"); // default translet name } } ... Specifically, the code above assumes that systemId is something like "xxx:yyy" in which case the class name (_className) is "die.verwandlung.yyy" ("die.verwandlung." is the default package name since Java11) However,Util.baseName(systemId) returns null when systemId is something like "xxx:" (empty after ":"), in which case the class name (_className) ends up with "die.verwandlung."(an invalid class name inserted in the constant pool of the generated bytecode). >From the perspective of robustness, the code above should be updated to handle the situation. e.g. else if (systemId != null && !systemId.equals("")) { String baseName = Util.baseName(systemId); if ((baseName != null) && (baseName.length() > 0)) { <------ setClassName(baseName); } which means it should check whether the returned base name from Util.baseName(systemId) is empty before setting the class name; otherwise, it should use the default class name ("GregorSamsa"). Let me know if any other concern on this fix. Thanks and Best Regards Cheng Jin From chegar at openjdk.java.net Sat Oct 23 15:32:02 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Sat, 23 Oct 2021 15:32:02 GMT Subject: RFR: 8268595: java/io/Serializable/serialFilter/GlobalFilterTest.java#id1 failed in timeout In-Reply-To: <3utjHiAKf2SmUTuhFh4-9YTk476V2OggSFiIK5mFzj0=.96dcbfb3-8746-477e-8c25-c586cd1f0cc6@github.com> References: <3utjHiAKf2SmUTuhFh4-9YTk476V2OggSFiIK5mFzj0=.96dcbfb3-8746-477e-8c25-c586cd1f0cc6@github.com> Message-ID: On Tue, 19 Oct 2021 13:00:01 GMT, Jaikiran Pai wrote: > The `GlobalFilterTest` has to 2 `@test` tags. One of them has failed with a timeout as noted in https://bugs.openjdk.java.net/browse/JDK-8268595. The timeout seems to have happened even after the tests had already completed successfully. Like I note in the JBS comments of that issue, I suspect it might have to do with the "-XX:StartFlightRecording:name=DeserializationEvent,dumponexit=true" usage in this test action. > > The commit in this PR removes that second `@test` altogether because (correct me if I'm wrong) from what I understand, this test never enables the DeserializationEvent which means there is no JFR events being captured for deserialization in this test, nor does the test do any JFR events related testing. So, I think this second `@test` is virtually a no-op when it comes to the JFR testing. There's a separate `TestDeserializationEvent` which has a comprehensive testing of the DeserializationEvent. Marked as reviewed by chegar (Reviewer). I agree that the second `@test` is not all that useful, and can probably be just removed. If I remember correctly, I added the second `@test` during development of the feature before the more comprehensive test was added, and also when experimenting with the event being enabled by default, but it is not adding much value now. ------------- PR: https://git.openjdk.java.net/jdk/pull/6008 From serb at openjdk.java.net Sat Oct 23 19:32:01 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sat, 23 Oct 2021 19:32:01 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v3] In-Reply-To: <7IjiRqEGugX1DiruWOX9zP7nh9b7zUc0EwCOMGpNspE=.e5c488da-e4b3-42bf-852e-e45506906fa0@github.com> References: <7IjiRqEGugX1DiruWOX9zP7nh9b7zUc0EwCOMGpNspE=.e5c488da-e4b3-42bf-852e-e45506906fa0@github.com> Message-ID: On Fri, 22 Oct 2021 17:33:43 GMT, Naoto Sato wrote: >> During the review of JEP 400, a proposal to provide an overloaded method to `Charset.forName()` was suggested [[1]](https://github.com/openjdk/jdk/pull/4733#discussion_r669693954). This PR is to implement the proposal. A CSR is also drafted as https://bugs.openjdk.java.net/browse/JDK-8275348 > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Removed `@throws IllegalCharsetNameException` Just an idea, should we check that the second parameter is null or not? Any pros and cons of that? For example should this code be allowed: var cs = Charset.forName(charsetName, null); if (cs == null) { System.err.println("Used UTF-8 encoding instead of "+charsetName+"); cs = StandardCharsets.UTF_8; } Or something like this should be forced: var cs = Charset.forName(charsetName, fallback); if (cs == fallback) { System.err.println("Used UTF-8 encoding instead of "+charsetName+"); } I have no preference. ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From smarks at openjdk.java.net Sat Oct 23 21:11:06 2021 From: smarks at openjdk.java.net (Stuart Marks) Date: Sat, 23 Oct 2021 21:11:06 GMT Subject: RFR: 8275293: A change done with JDK-8268764 mismatches the java.rmi.server.ObjID.hashCode spec In-Reply-To: References: Message-ID: On Fri, 15 Oct 2021 07:17:52 GMT, ?????? ??????? wrote: > It looks like we cannot use `Long.hashCode(long)` for `java.rmi.server.ObjID.hashCode()` due to specification: https://docs.oracle.com/en/java/javase/17/docs/api/java.rmi/java/rmi/server/ObjID.html#hashCode(). Marked as reviewed by smarks (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5963 From duke at openjdk.java.net Sat Oct 23 21:11:06 2021 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Sat, 23 Oct 2021 21:11:06 GMT Subject: Integrated: 8275293: A change done with JDK-8268764 mismatches the java.rmi.server.ObjID.hashCode spec In-Reply-To: References: Message-ID: On Fri, 15 Oct 2021 07:17:52 GMT, ?????? ??????? wrote: > It looks like we cannot use `Long.hashCode(long)` for `java.rmi.server.ObjID.hashCode()` due to specification: https://docs.oracle.com/en/java/javase/17/docs/api/java.rmi/java/rmi/server/ObjID.html#hashCode(). This pull request has now been integrated. Changeset: 5bbe4cae Author: Sergey Tsypanov Committer: Stuart Marks URL: https://git.openjdk.java.net/jdk/commit/5bbe4cae8746765d2ce965b06fd1e5cf512326ae Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8275293: A change done with JDK-8268764 mismatches the java.rmi.server.ObjID.hashCode spec Reviewed-by: rriggs, smarks ------------- PR: https://git.openjdk.java.net/jdk/pull/5963 From lancea at openjdk.java.net Sat Oct 23 21:16:07 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Sat, 23 Oct 2021 21:16:07 GMT Subject: RFR: 8153490: Cannot setBytes() if incoming buffer's length is bigger than number of elements we want to insert. [v5] In-Reply-To: <4MzAaDkmgdWxj_kxwdy7hq3I4jPQV39QX_Qg22TSjiI=.ff6a346a-4000-4cee-b50c-649a6a42ef14@github.com> References: <4MzAaDkmgdWxj_kxwdy7hq3I4jPQV39QX_Qg22TSjiI=.ff6a346a-4000-4cee-b50c-649a6a42ef14@github.com> Message-ID: On Fri, 15 Oct 2021 09:30:18 GMT, Mitsuru Kariya wrote: >> Fix `SerialBlob.setBytes(long pos, byte[] bytes, int offset, int length)` in the following cases: >> >> 1. `pos - 1 + bytes.length - offset > this.length() && pos - 1 + length <= this.length()` >> The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully. >> (test31) >> >> 2. `pos - 1 + length > this.length()` >> The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully. *1 >> (test32) >> >> 3. `pos == this.length() + 1` >> The original implementation throws `SerialException` but this case should end successfully. *2 >> (test33) >> >> 4. `length < 0` >> The original implementation throws `ArrayIndexOutOfBoundsException` but this case should throw `SerialException`. >> (test34) >> >> 5. `offset + length > Integer.MAX_VALUE` >> The original implementation throws `ArrayIndexOutOfBoundsException` (or `OutOfMemoryError` in most cases) but this case should throw `SerialException`. >> (test35) >> >> Additionally, fix `SerialClob.setString(long pos, String str, int offset, int length)` in the following cases: >> >> 1. `offset > str.length()` >> The original implementaion throws `StringIndexOutOfBoundsException` but this case should throw `SerialException`. >> (test39) >> >> 2. `pos - 1 + str.length() - offset > this.length() && pos - 1 + length <= this.length()` >> The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully. >> (test32) >> >> 3. `pos - 1 + length > this.length()` >> The original implementaion throws `SerialException` but this case should end successfully. *3 >> (test40) >> >> 4. `pos == this.length() + 1` >> The original implementaion throws `SerialException` but this case should end successfully. *4 >> (test41) >> >> 5. `length < 0` >> The original implementation throws `StringIndexOutOfBoundsException` but this case should throw `SerialException`. >> (test42) >> >> 6. `offset + length > Integer.MAX_VALUE` >> The original implementation throws `ArrayIndexOutOfBoundsException` (or `OutOfMemoryError` in most cases) but this case should throw `SerialException`. >> (test43) >> >> >> The javadoc has also been modified according to the above. >> >> *1 The documentation of `Blob.setBytes()` says, "If the end of the Blob value is reached while writing the array of bytes, then the length of the Blob value will be increased to accommodate the extra bytes." >> >> *2 The documentation of `Blob.setBytes()` says, "If the value specified for pos is greater than the length+1 of the BLOB value then the behavior is undefined." >> So, it should work correctly when pos == length+1 of the BLOB value. >> >> *3 The documentation of `Clob.setString()` says, "If the end of the Clob value is eached while writing the given string, then the length of the Clob value will be increased to accommodate the extra characters." >> >> *4 The documentation of `Clob.setString()` says, "If the value specified for pos is greater than the length+1 of the CLOB value then the behavior is undefined." >> So, it should work correctly when pos == length+1 of the CLOB value. > > Mitsuru Kariya has updated the pull request incrementally with one additional commit since the last revision: > > Follow the comment Any chance you can sync up your workspace with master? I am getting errors when I fetch and try to run our internal tests. ------------- PR: https://git.openjdk.java.net/jdk/pull/4001 From naoto at openjdk.java.net Sat Oct 23 22:13:35 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Sat, 23 Oct 2021 22:13:35 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v4] In-Reply-To: References: Message-ID: > During the review of JEP 400, a proposal to provide an overloaded method to `Charset.forName()` was suggested [[1]](https://github.com/openjdk/jdk/pull/4733#discussion_r669693954). This PR is to implement the proposal. A CSR is also drafted as https://bugs.openjdk.java.net/browse/JDK-8275348 Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Reflecting review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6045/files - new: https://git.openjdk.java.net/jdk/pull/6045/files/7c73c5ba..0e787e7a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6045&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6045&range=02-03 Stats: 7 lines in 2 files changed: 2 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/6045.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6045/head:pull/6045 PR: https://git.openjdk.java.net/jdk/pull/6045 From naoto at openjdk.java.net Sat Oct 23 22:13:37 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Sat, 23 Oct 2021 22:13:37 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v3] In-Reply-To: References: <7IjiRqEGugX1DiruWOX9zP7nh9b7zUc0EwCOMGpNspE=.e5c488da-e4b3-42bf-852e-e45506906fa0@github.com> Message-ID: On Sat, 23 Oct 2021 06:42:52 GMT, Alan Bateman wrote: > I think you'll need to adjust the description make it clear that "fallback" is used when the input is not a legal charset name or the charset is not available. Made the method description clearer. ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From naoto at openjdk.java.net Sat Oct 23 22:13:41 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Sat, 23 Oct 2021 22:13:41 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v3] In-Reply-To: References: <7IjiRqEGugX1DiruWOX9zP7nh9b7zUc0EwCOMGpNspE=.e5c488da-e4b3-42bf-852e-e45506906fa0@github.com> Message-ID: On Sat, 23 Oct 2021 19:29:30 GMT, Sergey Bylokhov wrote: > Just an idea, should we check that the second parameter is null or not? Any pros and cons of that? For example should this code be allowed: > > ``` > var cs = Charset.forName(charsetName, null); > if (cs == null) { > System.err.println("Used UTF-8 encoding instead of "+charsetName+"); > cs = StandardCharsets.UTF_8; > } > ``` Yes, that's the whole purpose of allowing `null` for `fallback`. > src/java.base/share/classes/java/io/Console.java line 589: > >> 587: } >> 588: if (cs == null) { >> 589: cs = Charset.forName(StaticProperty.nativeEncoding(), Charset.defaultCharset()); > > Not sure but looks like this class tries to maintain 80 chars per line rule? Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From jpai at openjdk.java.net Sun Oct 24 04:23:03 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Sun, 24 Oct 2021 04:23:03 GMT Subject: RFR: 8258117: jar tool sets the time stamp of module-info.class entries to the current time [v2] In-Reply-To: References: Message-ID: <78qG2XrUpzrdHfPMiPTFcN4szYF2F9ilg7maRbARGhM=.a079ec7c-9700-4d0b-a7e5-eee374cc4f62@github.com> On Fri, 17 Sep 2021 12:54:07 GMT, Jaikiran Pai wrote: >> The commit here is a potential fix for the issue noted in https://bugs.openjdk.java.net/browse/JDK-8258117. >> >> The change here repurposes an existing internal interface `ModuleInfoEntry` to keep track of the last modified timestamp of a `module-info.class` descriptor. >> >> This commit uses the timestamp of the `module-info.class` on the filesystem to set the time on the `JarEntry`. There are a couple of cases to consider here: >> >> 1. When creating a jar (using `--create`), we use the source `module-info.class` from the filesystem and then add extended info to it (attributes like packages, module version etc...). In such cases, this patch will use the lastmodified timestamp from the filesystem of `module-info.class` even though we might end up updating/extending/modifying (for example by adding a module version) its content while storing it as a `JarEntry`. >> >> 2. When updating a jar (using `--update`), this patch will use the lastmodified timestamp of `module-info.class` either from the filesystem or from the source jar's entry (depending on whether a new `module-info.class` is being passed to the command). Here too, it's possible that we might end up changing/modifying/extending the `module-info.class` (for example, changing the module version to a new version) that gets written into the updated jar file, but this patch _won't_ use `System.currentTimeMillis()` even in such cases. >> >> If we do have to track actual changes that might happen to `module-info.class` while extending its info (in `extendedInfoBytes()`) and then decide whether to use current system time as last modified time, then this will require a bigger change and also a discussion on what kind of extending of module-info.class content will require a change to the lastmodifiedtime of that entry. > > Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge latest from master branch > - 8258117: jar tool sets the time stamp of module-info.class entries to the current time Keep alive. ------------- PR: https://git.openjdk.java.net/jdk/pull/5486 From duke at openjdk.java.net Sun Oct 24 07:55:01 2021 From: duke at openjdk.java.net (Mitsuru Kariya) Date: Sun, 24 Oct 2021 07:55:01 GMT Subject: RFR: 8153490: Cannot setBytes() if incoming buffer's length is bigger than number of elements we want to insert. [v6] In-Reply-To: References: Message-ID: > Fix `SerialBlob.setBytes(long pos, byte[] bytes, int offset, int length)` in the following cases: > > 1. `pos - 1 + bytes.length - offset > this.length() && pos - 1 + length <= this.length()` > The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully. > (test31) > > 2. `pos - 1 + length > this.length()` > The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully. *1 > (test32) > > 3. `pos == this.length() + 1` > The original implementation throws `SerialException` but this case should end successfully. *2 > (test33) > > 4. `length < 0` > The original implementation throws `ArrayIndexOutOfBoundsException` but this case should throw `SerialException`. > (test34) > > 5. `offset + length > Integer.MAX_VALUE` > The original implementation throws `ArrayIndexOutOfBoundsException` (or `OutOfMemoryError` in most cases) but this case should throw `SerialException`. > (test35) > > Additionally, fix `SerialClob.setString(long pos, String str, int offset, int length)` in the following cases: > > 1. `offset > str.length()` > The original implementaion throws `StringIndexOutOfBoundsException` but this case should throw `SerialException`. > (test39) > > 2. `pos - 1 + str.length() - offset > this.length() && pos - 1 + length <= this.length()` > The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully. > (test32) > > 3. `pos - 1 + length > this.length()` > The original implementaion throws `SerialException` but this case should end successfully. *3 > (test40) > > 4. `pos == this.length() + 1` > The original implementaion throws `SerialException` but this case should end successfully. *4 > (test41) > > 5. `length < 0` > The original implementation throws `StringIndexOutOfBoundsException` but this case should throw `SerialException`. > (test42) > > 6. `offset + length > Integer.MAX_VALUE` > The original implementation throws `ArrayIndexOutOfBoundsException` (or `OutOfMemoryError` in most cases) but this case should throw `SerialException`. > (test43) > > > The javadoc has also been modified according to the above. > > *1 The documentation of `Blob.setBytes()` says, "If the end of the Blob value is reached while writing the array of bytes, then the length of the Blob value will be increased to accommodate the extra bytes." > > *2 The documentation of `Blob.setBytes()` says, "If the value specified for pos is greater than the length+1 of the BLOB value then the behavior is undefined." > So, it should work correctly when pos == length+1 of the BLOB value. > > *3 The documentation of `Clob.setString()` says, "If the end of the Clob value is eached while writing the given string, then the length of the Clob value will be increased to accommodate the extra characters." > > *4 The documentation of `Clob.setString()` says, "If the value specified for pos is greater than the length+1 of the CLOB value then the behavior is undefined." > So, it should work correctly when pos == length+1 of the CLOB value. Mitsuru Kariya has updated the pull request 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 JDK-8153490 - Follow the comment - Modify javadoc for consistency - Fix for length + offset > Integer.MAX_VALUE case - Add check: ensure length >= 0 - 8153490:Cannot setBytes() if incoming buffer's length is bigger than number of elements we want to insert. Fix SerialBlob.setBytes(long pos, byte[] bytes, int offset, int length) in the following cases: 1. pos - 1 + bytes.length - offset > this.length() && pos - 1 + length <= this.length() The original implementation throws ArrayIndexOutOfBoundsException but this case should end successfully. (test31) 2. pos - 1 + length > this.length() The original implementation throws ArrayIndexOutOfBoundsException but this case should end successfully. *1 (test32) 3. pos == this.length() + 1 The original implementation throws SerialException but this case should end successfully. *2 (test33) Additionally, fix SerialClob.setString(long pos, String str, int offset, int length) in the following cases: 1. offset > str.length() The original implementaion throws StringIndexOutOfBoundsException but this case should throw SerialException. (test39) 2. pos - 1 + str.length() - offset > this.length() && pos - 1 + length <= this.length() The original implementation throws ArrayIndexOutOfBoundsException but this case should end successfully. (test32) 3. pos - 1 + length > this.length() The original implementaion throws SerialException but this case should end successfully. *3 (test40) 4. pos == this.length() + 1 The original implementaion throws SerialException but this case should end successfully. *4 (test41) The javadoc has also been modified according to the above. *1 The documentation of Blob.setBytes() says, "If the end of the Blob value is reached while writing the array of bytes, then the length of the Blob value will be increased to accommodate the extra bytes." *2 The documentation of Blob.setBytes() says, "If the value specified for pos is greater than the length+1 of the BLOB value then the behavior is undefined." So, it should work correctly when pos == length+1 of the BLOB value. *3 The documentation of Clob.setString() says, "If the end of the Clob value is reached while writing the given string, then the length of the Clob value will be increased to accommodate the extra characters." *4 The documentation of Clob.setString() says, "If the value specified for pos is greater than the length+1 of the CLOB value then the behavior is undefined." So, it should work correctly when pos == length+1 of the CLOB value. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4001/files - new: https://git.openjdk.java.net/jdk/pull/4001/files/c5d8056b..5ff182ce Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4001&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4001&range=04-05 Stats: 836554 lines in 8575 files changed: 668559 ins; 128412 del; 39583 mod Patch: https://git.openjdk.java.net/jdk/pull/4001.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4001/head:pull/4001 PR: https://git.openjdk.java.net/jdk/pull/4001 From prr at openjdk.java.net Sun Oct 24 16:48:04 2021 From: prr at openjdk.java.net (Phil Race) Date: Sun, 24 Oct 2021 16:48:04 GMT Subject: RFR: 8275170: Some jtreg sound tests should be marked headful In-Reply-To: References: Message-ID: On Fri, 22 Oct 2021 19:01:27 GMT, Phil Race wrote: > This fix adds "headful sound" keywords to a number of javax/sound jtreg tests > > The jtreg javax.sound tests are written in such a way that if a needed audio device > or other platform resource is not available, they just exit with a "pass" for the test. > It is as if headful tests just swallowed HeadlessException and issued a pass. > If we allowed that we'd be effectively testing almost nothing of real importance. > > Currently almost all sound tests have no keyword like "headful" to indicate they > may need access to a hardware resource to do anything useful so a similar > situation arises there except when someone runs those tests manually on > a local system which has audio devices. > > Of course "headful" and "audio device" aren't exactly interchangeable terms > but if tests are allowed to be run - or worse usually or always run - in a situation > where they potentially are on a system without an audio device (a headless VM) or are running in > a session which doesn't have full desktop access - which may in some > cases be how audio device access is granted, then they are more likely > to be running in this scenario where the testing isn't valid. > > Another point is that headful tests must be run one at a time - no concurrency because > you can't have multiple tests moving the mouse at the same time > Whereas for headless tests, a test harness may choose to run concurrently - perhaps even in the same VM > When tests that really need access to an audio device are run it is probably safer to consider > the headful attribute as implying one test at a time is best .. granted on a desktop it isn't > usual for a single app to be able to monopolize access to a speaker, but for input devices > that is what you'd generally expect. > > By no means am I sure that the tests being updated here are the full set that need tagging. > There are a lot of tests and they are all known to pass on systems with NO audio > devices, so the search has been for tests which call APIs which will definitely > need access to some device in order to do anything useful. > So likely there are more to be added - either by a reviewer pointing them out or by later discovery. > Alternatively we could mark ALL sound tests headful .. but given where we are starting from > that might be erring unnecessarily far in the opposite direction. > > By adding both headful and sound keywords it gives options to someone who > wants to identify the tests and perhaps run just tests which need "sound" on some > config they know supports audio but isn't headful. This makes the tests eligible to be run on headful systems. In practice it seems like ONLY headful systems actually have the sound devices. The sound keyword isn't understood by anything yet, so adding headful is the only way we have right now of ensuring these tests are eligible to be run on systems that have the necessary support. As I explained in the initial PR description headful is also useful for implying exclusive access. And without this keyword it means that these tests are ALWAYS run on systems without sound device support. So for years we've effectively problem listed these tests due to the tests not having headful and silently passing when there's no sound. Without headful no one runs these on systems that have the needed device. So this solves a big hole that we aren't testing this case. The 2 keywords give flexibility - anyone who wants to filter when its marked headful and needing sound can do this, but just adding sound right now will solve nothing. And there are a couple of tests NOT in OpenJDK that already do this so we have precedent - and in a previous life one was added by you and the other approved by you .. ------------- PR: https://git.openjdk.java.net/jdk/pull/6086 From andrewluotechnologies at outlook.com Sun Oct 24 20:47:52 2021 From: andrewluotechnologies at outlook.com (Andrew Luo) Date: Sun, 24 Oct 2021 20:47:52 +0000 Subject: Fix AbstractLdapNamingEnumeration next to throw NoSuchElementException instead of NullPointerException Message-ID: I have a small PR to fix a bug in AbstractLdapNamingEnumeration - details are in the PR: https://github.com/openjdk/jdk/pull/6095 (Note: I'm already an OpenJDK contributor and have signed an OCA but don't have an author account to be able to create bugs) Thanks, -Andrew From serb at openjdk.java.net Sun Oct 24 23:03:06 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sun, 24 Oct 2021 23:03:06 GMT Subject: RFR: 8275170: Some jtreg sound tests should be marked headful In-Reply-To: References: Message-ID: On Sun, 24 Oct 2021 16:45:15 GMT, Phil Race wrote: > This makes the tests eligible to be run on headful systems. In practice it seems like ONLY headful systems actually have the sound devices. The sound keyword isn't understood by anything yet, so adding headful is the only way we have right now of ensuring these tests are eligible to be run on systems that have the necessary support. This is not the right approach, it was made a hard work to eliminate the headful keyword from any tests including sound which are not throw the headless exception or something. The "headful" means that the test will fail otherwise due to UI session missing. We should not abuse it to select some other unrelated tests. Like we do not doing this for printer. The problem you try to solve is that you have a "bad" system where nothing is configured and the "good" system where UI/sound(what about printer?) are configured. And you want to exclude all tests from the "bad" host and run them on the "good" one by using the headful keyword which is not targeted for this usecase. > As I explained in the initial PR description headful is also useful for implying exclusive access. Such exclusive access should not be needed by the sound, in fact it was found a few hard too spot concurrency bugs when we start to run the sound tests in parallel. > And without this keyword it means that these tests are ALWAYS run on systems without sound device support. Is it always just because the sound is not configured on the systems where you run the tests without headful keyword? How it is related to the "headfulness" of the systems? > So for years we've effectively problem listed these tests due to the tests not having headful and silently passing when there's no sound. Without headful no one runs these on systems that have the needed device. This was done intentionally that everybody who run the tests also run the tests for the sound, moreover it was included the openjdk tier3, before it was accidentally removed from there. > The 2 keywords give flexibility - anyone who wants to filter when its marked headful and needing sound can do this, but just adding sound right now will solve nothing. Such flexibility exists already, it is possible to run test/jdk/javax/sound on any computer you want and exclude it from the jdk_desktop test run. > And there are a couple of tests NOT in OpenJDK that already do this so we have precedent - and in a previous life one was added by you and the other approved by you .. If it is not in the OpenJDK then we do not need to discuss it here and that's not actually a precedent. We should investigate each case one by one, the headful keyword does not solve any issue on windows, since all windows are headful(or most of them where we interested in the audio), on macOS the sound subsystem is built-in. And on Linux it is possible to configure sound as well and it will work fine w/o X server. I think most of the sound tests are written according to the spec which does not required UI, and if it was necessary to make it pass by running on the system which have UI system configured make me think that some product bug was workaround. ------------- PR: https://git.openjdk.java.net/jdk/pull/6086 From ihse at openjdk.java.net Mon Oct 25 08:08:09 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 25 Oct 2021 08:08:09 GMT Subject: RFR: 8275509: ModuleDescriptor.hashCode isn't reproducible across builds [v3] In-Reply-To: References: Message-ID: On Fri, 22 Oct 2021 10:44:31 GMT, Jaikiran Pai wrote: >> Can I please get a review for this change which fixes the issue reported in https://bugs.openjdk.java.net/browse/JDK-8275509? >> >> The `ModuleDescriptor.hashCode()` method uses the hash code of its various components to compute the final hash code. While doing so it ends up calling hashCode() on (collection of) various `enum` types. Since the hashCode() of enum types is generated from a call to `java.lang.Object.hashCode()`, their value isn't guaranteed to stay the same across multiple JVM runs. >> >> The commit here proposes to use the ordinal of the enum as the hash code. As Alan notes in the mailing list discussion, any changes to the ordinal of the enum (either due to addition of new value, removal of a value or just reordering existing values, all of which I think will be rare in these specific enum types) isn't expected to produce the same hash code across those changed runtimes and that should be okay. >> >> The rest of the ModuleDescriptor.hashCode() has been reviewed too and apart from calls to the enum types hashCode(), rest of the calls in that implementation, either directly or indirectly end up as calls on `java.lang.String.hashCode()` and as such aren't expected to cause non-deterministic values. >> >> A new jtreg test has been added to reproduce this issue and verify the fix. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > drop another final to make it consistent with rest of the code test/jdk/java/lang/module/ModuleDescriptorHashCodeTest.java line 159: > 157: } > 158: } > 159: } It seems you're missing a newline at the EOF. ------------- PR: https://git.openjdk.java.net/jdk/pull/6078 From jpai at openjdk.java.net Mon Oct 25 09:21:28 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Mon, 25 Oct 2021 09:21:28 GMT Subject: RFR: 8275509: ModuleDescriptor.hashCode isn't reproducible across builds [v4] In-Reply-To: References: Message-ID: > Can I please get a review for this change which fixes the issue reported in https://bugs.openjdk.java.net/browse/JDK-8275509? > > The `ModuleDescriptor.hashCode()` method uses the hash code of its various components to compute the final hash code. While doing so it ends up calling hashCode() on (collection of) various `enum` types. Since the hashCode() of enum types is generated from a call to `java.lang.Object.hashCode()`, their value isn't guaranteed to stay the same across multiple JVM runs. > > The commit here proposes to use the ordinal of the enum as the hash code. As Alan notes in the mailing list discussion, any changes to the ordinal of the enum (either due to addition of new value, removal of a value or just reordering existing values, all of which I think will be rare in these specific enum types) isn't expected to produce the same hash code across those changed runtimes and that should be okay. > > The rest of the ModuleDescriptor.hashCode() has been reviewed too and apart from calls to the enum types hashCode(), rest of the calls in that implementation, either directly or indirectly end up as calls on `java.lang.String.hashCode()` and as such aren't expected to cause non-deterministic values. > > A new jtreg test has been added to reproduce this issue and verify the fix. Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: add newline at end of test class ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6078/files - new: https://git.openjdk.java.net/jdk/pull/6078/files/89669ea4..006255d9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6078&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6078&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6078.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6078/head:pull/6078 PR: https://git.openjdk.java.net/jdk/pull/6078 From jpai at openjdk.java.net Mon Oct 25 09:21:29 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Mon, 25 Oct 2021 09:21:29 GMT Subject: RFR: 8275509: ModuleDescriptor.hashCode isn't reproducible across builds [v3] In-Reply-To: References: Message-ID: On Mon, 25 Oct 2021 08:04:43 GMT, Magnus Ihse Bursie wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> drop another final to make it consistent with rest of the code > > test/jdk/java/lang/module/ModuleDescriptorHashCodeTest.java line 159: > >> 157: } >> 158: } >> 159: } > > It seems you're missing a newline at the EOF. Indeed. Updated the PR to fix it. ------------- PR: https://git.openjdk.java.net/jdk/pull/6078 From jpai at openjdk.java.net Mon Oct 25 09:23:01 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Mon, 25 Oct 2021 09:23:01 GMT Subject: RFR: 8268595: java/io/Serializable/serialFilter/GlobalFilterTest.java#id1 failed in timeout In-Reply-To: <3utjHiAKf2SmUTuhFh4-9YTk476V2OggSFiIK5mFzj0=.96dcbfb3-8746-477e-8c25-c586cd1f0cc6@github.com> References: <3utjHiAKf2SmUTuhFh4-9YTk476V2OggSFiIK5mFzj0=.96dcbfb3-8746-477e-8c25-c586cd1f0cc6@github.com> Message-ID: On Tue, 19 Oct 2021 13:00:01 GMT, Jaikiran Pai wrote: > The `GlobalFilterTest` has to 2 `@test` tags. One of them has failed with a timeout as noted in https://bugs.openjdk.java.net/browse/JDK-8268595. The timeout seems to have happened even after the tests had already completed successfully. Like I note in the JBS comments of that issue, I suspect it might have to do with the "-XX:StartFlightRecording:name=DeserializationEvent,dumponexit=true" usage in this test action. > > The commit in this PR removes that second `@test` altogether because (correct me if I'm wrong) from what I understand, this test never enables the DeserializationEvent which means there is no JFR events being captured for deserialization in this test, nor does the test do any JFR events related testing. So, I think this second `@test` is virtually a no-op when it comes to the JFR testing. There's a separate `TestDeserializationEvent` which has a comprehensive testing of the DeserializationEvent. Thank you for the review Chris. Roger, should I go ahead with the merge? ------------- PR: https://git.openjdk.java.net/jdk/pull/6008 From redestad at openjdk.java.net Mon Oct 25 11:31:14 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 25 Oct 2021 11:31:14 GMT Subject: RFR: 8275863: Use encodeASCII for ASCII-compatible DoubleByte encodings Message-ID: Enhance ASCII-compatible `DoubleByte` encodings to make use of the `StringCoding.implEncodeAsciiArray` intrinsic, which makes many such `CharsetEncoder`s encode ASCII text at speeds comparable to most single-byte encoders - and also more in line with how well these charsets behave when calling `String.getBytes`: Before: Benchmark (size) (type) Mode Cnt Score Error Units CharsetEncodeDecode.encode 16384 ISO-8859-1 avgt 30 3.021 ? 0.120 us/op CharsetEncodeDecode.encode 16384 Shift-JIS avgt 30 47.793 ? 1.942 us/op CharsetEncodeDecode.encode 16384 GB2312 avgt 30 49.598 ? 2.006 us/op CharsetEncodeDecode.encode 16384 EUC-JP avgt 30 68.709 ? 5.019 us/op CharsetEncodeDecode.encode 16384 EUC-KR avgt 30 48.033 ? 1.651 us/op Patched: Benchmark (size) (type) Mode Cnt Score Error Units CharsetEncodeDecode.encode 16384 ISO-8859-1 avgt 30 2.856 ? 0.078 us/op CharsetEncodeDecode.encode 16384 Shift-JIS avgt 30 5.287 ? 0.209 us/op CharsetEncodeDecode.encode 16384 GB2312 avgt 30 5.490 ? 0.251 us/op CharsetEncodeDecode.encode 16384 EUC-JP avgt 30 7.657 ? 0.368 us/op CharsetEncodeDecode.encode 16384 EUC-KR avgt 30 5.718 ? 0.267 us/op The `isASCIICompatible` predicate on `DoubleByte` was added in JEP 254 for the purpose of implementing such ASCII fast-paths, but is only used in what is now `String.encodeWithEncoder` to speed up `String.getBytes(...)` operations. Testing: tier1-3 ------------- Commit messages: - Use field directly - Grant accessClassInPackage.jdk.internal.access permission to jdk.charsets module - 8275863: Use encodeASCII for ASCII-compatible DoubleByte encodings Changes: https://git.openjdk.java.net/jdk/pull/6102/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6102&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275863 Stats: 35 lines in 5 files changed: 24 ins; 4 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/6102.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6102/head:pull/6102 PR: https://git.openjdk.java.net/jdk/pull/6102 From rriggs at openjdk.java.net Mon Oct 25 14:04:04 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 25 Oct 2021 14:04:04 GMT Subject: RFR: 8268595: java/io/Serializable/serialFilter/GlobalFilterTest.java#id1 failed in timeout In-Reply-To: <3utjHiAKf2SmUTuhFh4-9YTk476V2OggSFiIK5mFzj0=.96dcbfb3-8746-477e-8c25-c586cd1f0cc6@github.com> References: <3utjHiAKf2SmUTuhFh4-9YTk476V2OggSFiIK5mFzj0=.96dcbfb3-8746-477e-8c25-c586cd1f0cc6@github.com> Message-ID: <2FgXL_321RlLPse_qFedOhLwVWlCZv5bNDCtvAYbZ-0=.7f3c7e42-aaa8-4777-819c-518aa99e9465@github.com> On Tue, 19 Oct 2021 13:00:01 GMT, Jaikiran Pai wrote: > The `GlobalFilterTest` has to 2 `@test` tags. One of them has failed with a timeout as noted in https://bugs.openjdk.java.net/browse/JDK-8268595. The timeout seems to have happened even after the tests had already completed successfully. Like I note in the JBS comments of that issue, I suspect it might have to do with the "-XX:StartFlightRecording:name=DeserializationEvent,dumponexit=true" usage in this test action. > > The commit in this PR removes that second `@test` altogether because (correct me if I'm wrong) from what I understand, this test never enables the DeserializationEvent which means there is no JFR events being captured for deserialization in this test, nor does the test do any JFR events related testing. So, I think this second `@test` is virtually a no-op when it comes to the JFR testing. There's a separate `TestDeserializationEvent` which has a comprehensive testing of the DeserializationEvent. LGTM ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6008 From rriggs at openjdk.java.net Mon Oct 25 14:16:09 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 25 Oct 2021 14:16:09 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v4] In-Reply-To: References: Message-ID: <8S6MNJSIX_s2OXqoy2rD0ty4kyjxuVZ4wG_6W0qFtOw=.97aafb88-bbcf-4f18-8729-bbbd5c066d08@github.com> On Sat, 23 Oct 2021 22:13:35 GMT, Naoto Sato wrote: >> During the review of JEP 400, a proposal to provide an overloaded method to `Charset.forName()` was suggested [[1]](https://github.com/openjdk/jdk/pull/4733#discussion_r669693954). This PR is to implement the proposal. A CSR is also drafted as https://bugs.openjdk.java.net/browse/JDK-8275348 > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Reflecting review comments Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From itakiguchi at openjdk.java.net Mon Oct 25 14:20:52 2021 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Mon, 25 Oct 2021 14:20:52 GMT Subject: RFR: 8274544: Langtools command's usage were garbled on Japanese Windows [v4] In-Reply-To: References: Message-ID: > JEP-400 (UTF-8 by Default) was eabled on JDK18-b13. > After JDK18-b13, javac and some other langtool command's usage were garbled on Japanese Windows. > These commands use PrintWriter instead of standard out/err with PrintStream. Ichiroh Takiguchi 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: - 8274544: Langtools command's usage were garbled on Japanese Windows - 8274544: Langtools command's usage were garbled on Japanese Windows - 8274544: Langtools command's usage were garbled on Japanese Windows - Langtools command's usage were grabled on Japanese Windows ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5771/files - new: https://git.openjdk.java.net/jdk/pull/5771/files/4427d87c..e2a87848 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5771&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5771&range=02-03 Stats: 35926 lines in 1051 files changed: 24201 ins; 7865 del; 3860 mod Patch: https://git.openjdk.java.net/jdk/pull/5771.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5771/head:pull/5771 PR: https://git.openjdk.java.net/jdk/pull/5771 From jpai at openjdk.java.net Mon Oct 25 14:27:12 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Mon, 25 Oct 2021 14:27:12 GMT Subject: RFR: 8268595: java/io/Serializable/serialFilter/GlobalFilterTest.java#id1 failed in timeout In-Reply-To: <3utjHiAKf2SmUTuhFh4-9YTk476V2OggSFiIK5mFzj0=.96dcbfb3-8746-477e-8c25-c586cd1f0cc6@github.com> References: <3utjHiAKf2SmUTuhFh4-9YTk476V2OggSFiIK5mFzj0=.96dcbfb3-8746-477e-8c25-c586cd1f0cc6@github.com> Message-ID: On Tue, 19 Oct 2021 13:00:01 GMT, Jaikiran Pai wrote: > The `GlobalFilterTest` has to 2 `@test` tags. One of them has failed with a timeout as noted in https://bugs.openjdk.java.net/browse/JDK-8268595. The timeout seems to have happened even after the tests had already completed successfully. Like I note in the JBS comments of that issue, I suspect it might have to do with the "-XX:StartFlightRecording:name=DeserializationEvent,dumponexit=true" usage in this test action. > > The commit in this PR removes that second `@test` altogether because (correct me if I'm wrong) from what I understand, this test never enables the DeserializationEvent which means there is no JFR events being captured for deserialization in this test, nor does the test do any JFR events related testing. So, I think this second `@test` is virtually a no-op when it comes to the JFR testing. There's a separate `TestDeserializationEvent` which has a comprehensive testing of the DeserializationEvent. Thank you Roger. ------------- PR: https://git.openjdk.java.net/jdk/pull/6008 From jpai at openjdk.java.net Mon Oct 25 14:27:13 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Mon, 25 Oct 2021 14:27:13 GMT Subject: Integrated: 8268595: java/io/Serializable/serialFilter/GlobalFilterTest.java#id1 failed in timeout In-Reply-To: <3utjHiAKf2SmUTuhFh4-9YTk476V2OggSFiIK5mFzj0=.96dcbfb3-8746-477e-8c25-c586cd1f0cc6@github.com> References: <3utjHiAKf2SmUTuhFh4-9YTk476V2OggSFiIK5mFzj0=.96dcbfb3-8746-477e-8c25-c586cd1f0cc6@github.com> Message-ID: On Tue, 19 Oct 2021 13:00:01 GMT, Jaikiran Pai wrote: > The `GlobalFilterTest` has to 2 `@test` tags. One of them has failed with a timeout as noted in https://bugs.openjdk.java.net/browse/JDK-8268595. The timeout seems to have happened even after the tests had already completed successfully. Like I note in the JBS comments of that issue, I suspect it might have to do with the "-XX:StartFlightRecording:name=DeserializationEvent,dumponexit=true" usage in this test action. > > The commit in this PR removes that second `@test` altogether because (correct me if I'm wrong) from what I understand, this test never enables the DeserializationEvent which means there is no JFR events being captured for deserialization in this test, nor does the test do any JFR events related testing. So, I think this second `@test` is virtually a no-op when it comes to the JFR testing. There's a separate `TestDeserializationEvent` which has a comprehensive testing of the DeserializationEvent. This pull request has now been integrated. Changeset: f143d2a8 Author: Jaikiran Pai URL: https://git.openjdk.java.net/jdk/commit/f143d2a88e1972cdce9eb6f61c2eb9754cb89251 Stats: 12 lines in 1 file changed: 0 ins; 12 del; 0 mod 8268595: java/io/Serializable/serialFilter/GlobalFilterTest.java#id1 failed in timeout Reviewed-by: chegar, rriggs ------------- PR: https://git.openjdk.java.net/jdk/pull/6008 From itakiguchi at openjdk.java.net Mon Oct 25 16:04:13 2021 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Mon, 25 Oct 2021 16:04:13 GMT Subject: RFR: 8274544: Langtools command's usage were garbled on Japanese Windows [v4] In-Reply-To: References: Message-ID: On Mon, 25 Oct 2021 14:20:52 GMT, Ichiroh Takiguchi wrote: >> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13. >> After JDK18-b13, javac and some other langtool command's usage were garbled on Japanese Windows. >> These commands use PrintWriter instead of standard out/err with PrintStream. > > Ichiroh Takiguchi 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: > > - 8274544: Langtools command's usage were garbled on Japanese Windows > - 8274544: Langtools command's usage were garbled on Japanese Windows > - 8274544: Langtools command's usage were garbled on Japanese Windows > - Langtools command's usage were grabled on Japanese Windows Terminal setting $ locale LANG=ja_JP.eucjp LC_CTYPE="ja_JP.eucjp" LC_NUMERIC="ja_JP.eucjp" LC_TIME="ja_JP.eucjp" LC_COLLATE="ja_JP.eucjp" LC_MONETARY="ja_JP.eucjp" LC_MESSAGES="ja_JP.eucjp" LC_PAPER="ja_JP.eucjp" LC_NAME="ja_JP.eucjp" LC_ADDRESS="ja_JP.eucjp" LC_TELEPHONE="ja_JP.eucjp" LC_MEASUREMENT="ja_JP.eucjp" LC_IDENTIFICATION="ja_JP.eucjp" LC_ALL= Java testcase by using Scanner. $ cat scan.java import java.util.*; public class scan { public static void main(String[] args) throws Exception { System.out.println("Please input some characters:"); Scanner scanner = new Scanner(System.in); System.out.println(scanner.next()); } } $ ~/jdk-18-b19/bin/java scan.java Please input some characters: ????? ?????????? When `src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/AbstractTerminal.java` is modified $ jshell | JShell????? -- ?????18-internal | ??????????????????: /help intro jshell> import java.nio.charset.* jshell> System.out.println(System.getProperty("native.encoding")) EUC-JP-LINUX jshell> System.out.println(Charset.defaultCharset()) UTF-8 jshell> var scan = new Scanner(System.in) scan ==> java.util.Scanner[delimiters=\p{javaWhitespace}+] ... \E][infinity string=\Q?\E] jshell> var s = scan.next() ????? s ==> "?????" jshell> System.out.println(s) ????? jshell> /exit | ????? $ ------------- PR: https://git.openjdk.java.net/jdk/pull/5771 From naoto at openjdk.java.net Mon Oct 25 16:18:17 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 25 Oct 2021 16:18:17 GMT Subject: RFR: 8275767: JDK source code contains redundant boolean operations in jdk.charsets Message-ID: Trivial clean-up. ------------- Commit messages: - 8275767: JDK source code contains redundant boolean operations in jdk.charsets Changes: https://git.openjdk.java.net/jdk/pull/6110/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6110&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275767 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/6110.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6110/head:pull/6110 PR: https://git.openjdk.java.net/jdk/pull/6110 From joehw at openjdk.java.net Mon Oct 25 16:29:05 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Mon, 25 Oct 2021 16:29:05 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v4] In-Reply-To: References: Message-ID: On Sat, 23 Oct 2021 22:13:35 GMT, Naoto Sato wrote: >> During the review of JEP 400, a proposal to provide an overloaded method to `Charset.forName()` was suggested [[1]](https://github.com/openjdk/jdk/pull/4733#discussion_r669693954). This PR is to implement the proposal. A CSR is also drafted as https://bugs.openjdk.java.net/browse/JDK-8275348 > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Reflecting review comments Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From lancea at openjdk.java.net Mon Oct 25 16:39:03 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 25 Oct 2021 16:39:03 GMT Subject: RFR: 8275767: JDK source code contains redundant boolean operations in jdk.charsets In-Reply-To: References: Message-ID: On Mon, 25 Oct 2021 16:08:29 GMT, Naoto Sato wrote: > Trivial clean-up. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6110 From bpb at openjdk.java.net Mon Oct 25 16:47:16 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 25 Oct 2021 16:47:16 GMT Subject: RFR: 8275536: Add test to check that File::lastModified returns same time stamp as Files.getLastModifiedTime [v3] In-Reply-To: References: Message-ID: On Thu, 21 Oct 2021 22:54:34 GMT, Clive Verghese wrote: >> The test validated that the precision returned by `java.io.File.lastModified` and `java.nio.file.Files.getLastModifiedTime` are the same. > > Clive Verghese has updated the pull request incrementally with one additional commit since the last revision: > > Move test from java/nio to java/io Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6054 From rriggs at openjdk.java.net Mon Oct 25 17:01:03 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 25 Oct 2021 17:01:03 GMT Subject: RFR: 8275767: JDK source code contains redundant boolean operations in jdk.charsets In-Reply-To: References: Message-ID: On Mon, 25 Oct 2021 16:08:29 GMT, Naoto Sato wrote: > Trivial clean-up. Given that the code has been that way for a *long time*, did you check that both paths work as intended and that tests exist for both paths? ------------- PR: https://git.openjdk.java.net/jdk/pull/6110 From naoto at openjdk.java.net Mon Oct 25 17:19:11 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 25 Oct 2021 17:19:11 GMT Subject: RFR: 8275767: JDK source code contains redundant boolean operations in jdk.charsets In-Reply-To: References: Message-ID: On Mon, 25 Oct 2021 16:08:29 GMT, Naoto Sato wrote: > Trivial clean-up. No, I did not check. I simply removed the `true &&` as it is logically correct. There's a test specifying `IBM964` in `sun.nio.cs.TestIBMBugs.java`, but not sure it tests both paths or not. ------------- PR: https://git.openjdk.java.net/jdk/pull/6110 From rriggs at openjdk.java.net Mon Oct 25 18:04:11 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 25 Oct 2021 18:04:11 GMT Subject: RFR: 8275767: JDK source code contains redundant boolean operations in jdk.charsets In-Reply-To: References: Message-ID: On Mon, 25 Oct 2021 16:08:29 GMT, Naoto Sato wrote: > Trivial clean-up. LGTM ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6110 From iris at openjdk.java.net Mon Oct 25 18:08:04 2021 From: iris at openjdk.java.net (Iris Clark) Date: Mon, 25 Oct 2021 18:08:04 GMT Subject: RFR: 8275767: JDK source code contains redundant boolean operations in jdk.charsets In-Reply-To: References: Message-ID: On Mon, 25 Oct 2021 16:08:29 GMT, Naoto Sato wrote: > Trivial clean-up. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6110 From cverghese at openjdk.java.net Mon Oct 25 18:37:16 2021 From: cverghese at openjdk.java.net (Clive Verghese) Date: Mon, 25 Oct 2021 18:37:16 GMT Subject: Integrated: 8275536: Add test to check that File::lastModified returns same time stamp as Files.getLastModifiedTime In-Reply-To: References: Message-ID: On Thu, 21 Oct 2021 00:27:20 GMT, Clive Verghese wrote: > The test validated that the precision returned by `java.io.File.lastModified` and `java.nio.file.Files.getLastModifiedTime` are the same. This pull request has now been integrated. Changeset: 97d3280e Author: Clive Verghese Committer: Paul Hohensee URL: https://git.openjdk.java.net/jdk/commit/97d3280eb4735f5b84cd4a9a1286e35c1c48113a Stats: 60 lines in 1 file changed: 60 ins; 0 del; 0 mod 8275536: Add test to check that File::lastModified returns same time stamp as Files.getLastModifiedTime Reviewed-by: alanb, bpb ------------- PR: https://git.openjdk.java.net/jdk/pull/6054 From serb at openjdk.java.net Mon Oct 25 21:22:32 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 25 Oct 2021 21:22:32 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v4] In-Reply-To: References: Message-ID: On Sat, 23 Oct 2021 22:13:35 GMT, Naoto Sato wrote: >> During the review of JEP 400, a proposal to provide an overloaded method to `Charset.forName()` was suggested [[1]](https://github.com/openjdk/jdk/pull/4733#discussion_r669693954). This PR is to implement the proposal. A CSR is also drafted as https://bugs.openjdk.java.net/browse/JDK-8275348 > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Reflecting review comments Thank you for clarification. ------------- Marked as reviewed by serb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6045 From dlsmith at openjdk.java.net Mon Oct 25 21:42:39 2021 From: dlsmith at openjdk.java.net (Dan Smith) Date: Mon, 25 Oct 2021 21:42:39 GMT Subject: RFR: JDK-8274848: LambdaMetaFactory::metafactory on REF_invokeSpecial impl method has incorrect behavior [v2] In-Reply-To: References: Message-ID: On Tue, 12 Oct 2021 16:21:33 GMT, Mandy Chung wrote: >> Classes compiled prior to the nestmate support will generate `REF_invokeSpecial` if the implementation method is a private instance method. Since a lambda proxy class is a hidden class, a nestmate of the host class, it can invoke the private implementation method but it has to use `REF_invokeVirtual` or `REF_invokeInterface`. In order to support the old classes running on the new runtime, LMF implementation adjusts the reference kind from `REF_invokeSpecial` to `REF_invokeVirtual/REF_invokeInterface`. >> >> This PR fixes the check properly to ensure the adjustment is only made if the implementation method is private method in the host class. > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > remove filelist which was added accidentally Source changes look good. The test seems like way too much overhead for this small thing. Looks like a lot of the ASM code is just to verify that javac generates the test case you expect? I'd suggest invoking the LMF API directly instead, testing both private and non-private `invokespecial` MethodHandles, just making sure the rules can be used without error. ------------- PR: https://git.openjdk.java.net/jdk/pull/5901 From serb at openjdk.java.net Tue Oct 26 02:08:18 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 26 Oct 2021 02:08:18 GMT Subject: RFR: 8275293: A change done with JDK-8268764 mismatches the java.rmi.server.ObjID.hashCode spec In-Reply-To: References: Message-ID: On Fri, 15 Oct 2021 07:17:52 GMT, ?????? ??????? wrote: > It looks like we cannot use `Long.hashCode(long)` for `java.rmi.server.ObjID.hashCode()` due to specification: https://docs.oracle.com/en/java/javase/17/docs/api/java.rmi/java/rmi/server/ObjID.html#hashCode(). Just a suggestion, it is always a good thing to add a jtreg test case, especially if it is regression. ------------- PR: https://git.openjdk.java.net/jdk/pull/5963 From smarks at openjdk.java.net Tue Oct 26 02:13:18 2021 From: smarks at openjdk.java.net (Stuart Marks) Date: Tue, 26 Oct 2021 02:13:18 GMT Subject: RFR: 8275293: A change done with JDK-8268764 mismatches the java.rmi.server.ObjID.hashCode spec In-Reply-To: References: Message-ID: On Fri, 15 Oct 2021 07:17:52 GMT, ?????? ??????? wrote: > It looks like we cannot use `Long.hashCode(long)` for `java.rmi.server.ObjID.hashCode()` due to specification: https://docs.oracle.com/en/java/javase/17/docs/api/java.rmi/java/rmi/server/ObjID.html#hashCode(). Oh yes, good point in general. In this case the problem was caught by the failure of a JCK test, so I don't think a separate regression test is necessary. I've added the `noreg-jck` label to the bug to indicate this. ------------- PR: https://git.openjdk.java.net/jdk/pull/5963 From serb at openjdk.java.net Tue Oct 26 02:17:17 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 26 Oct 2021 02:17:17 GMT Subject: RFR: 8275293: A change done with JDK-8268764 mismatches the java.rmi.server.ObjID.hashCode spec In-Reply-To: References: Message-ID: On Fri, 15 Oct 2021 07:17:52 GMT, ?????? ??????? wrote: > It looks like we cannot use `Long.hashCode(long)` for `java.rmi.server.ObjID.hashCode()` due to specification: https://docs.oracle.com/en/java/javase/17/docs/api/java.rmi/java/rmi/server/ObjID.html#hashCode(). I think this one was missed due to the absence of the coverage in the jtreg test suite, and some people have no access to the jck to run it in advance. ------------- PR: https://git.openjdk.java.net/jdk/pull/5963 From rreddy at openjdk.java.net Tue Oct 26 06:30:39 2021 From: rreddy at openjdk.java.net (Ravi Reddy) Date: Tue, 26 Oct 2021 06:30:39 GMT Subject: RFR: 8193682: Infinite loop in ZipOutputStream.close() [v4] In-Reply-To: References: Message-ID: > Hi all, > > Please review this fix for Infinite loop in ZipOutputStream.close(). > The main issue here is when ever there is an exception during close operations on GZip we are not setting the deflator to a finished state which is leading to an infinite loop when we try writing on the same GZip instance( since we use while(!def.finished()) inside the write operation). > > Thanks, > Ravi Ravi Reddy has updated the pull request incrementally with one additional commit since the last revision: 8193682 : Infinite loop in ZipOutputStream.close() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5522/files - new: https://git.openjdk.java.net/jdk/pull/5522/files/d18eb3c1..5f1922bf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5522&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5522&range=02-03 Stats: 26 lines in 2 files changed: 12 ins; 7 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/5522.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5522/head:pull/5522 PR: https://git.openjdk.java.net/jdk/pull/5522 From rreddy at openjdk.java.net Tue Oct 26 07:08:14 2021 From: rreddy at openjdk.java.net (Ravi Reddy) Date: Tue, 26 Oct 2021 07:08:14 GMT Subject: RFR: 8193682: Infinite loop in ZipOutputStream.close() [v4] In-Reply-To: References: Message-ID: On Tue, 26 Oct 2021 06:30:39 GMT, Ravi Reddy wrote: >> Hi all, >> >> Please review this fix for Infinite loop in ZipOutputStream.close(). >> The main issue here is when ever there is an exception during close operations on GZip we are not setting the deflator to a finished state which is leading to an infinite loop when we try writing on the same GZip instance( since we use while(!def.finished()) inside the write operation). >> >> Thanks, >> Ravi > > Ravi Reddy has updated the pull request incrementally with one additional commit since the last revision: > > 8193682 : Infinite loop in ZipOutputStream.close() Hi , I have made the changes in fix , I think changing existing behavior in deflate() will need a spec change. With this fix , I'm closing deflater on exception scenarios in finish method of GZipOutputStream and close method of DeflaterOutputStream. Even though the document for finsih/close methods does not clearly specifies if the deflater will be closed or not , the current behaviour of these methods does close the deflater whenever finish/close are called. \ Thanks, Ravi ------------- PR: https://git.openjdk.java.net/jdk/pull/5522 From dfuchs at openjdk.java.net Tue Oct 26 10:46:09 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 26 Oct 2021 10:46:09 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v4] In-Reply-To: References: Message-ID: On Sat, 23 Oct 2021 22:13:35 GMT, Naoto Sato wrote: >> During the review of JEP 400, a proposal to provide an overloaded method to `Charset.forName()` was suggested [[1]](https://github.com/openjdk/jdk/pull/4733#discussion_r669693954). This PR is to implement the proposal. A CSR is also drafted as https://bugs.openjdk.java.net/browse/JDK-8275348 > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Reflecting review comments src/java.base/share/classes/java/io/Console.java line 590: > 588: if (cs == null) { > 589: cs = Charset.forName(StaticProperty.nativeEncoding(), > 590: Charset.defaultCharset()); I assume that `StaticProperty.nativeEncoding()` will never be `null`? Otherwise an IAE would be thrown here where previously `Charset.defaultCharset()` would be used. ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From duke at openjdk.java.net Tue Oct 26 11:25:25 2021 From: duke at openjdk.java.net (intrigus) Date: Tue, 26 Oct 2021 11:25:25 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v14] In-Reply-To: References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> Message-ID: On Mon, 18 Oct 2021 16:10:21 GMT, Mandy Chung wrote: >> This reimplements core reflection with method handles. >> >> For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. >> >> The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. >> >> The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. >> >> Ran tier1-tier8 tests. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8013527 >> [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > Separate paramFlgas into paramCount and flags fields (I've looked at the changed code as someone that is NOT familiar with the implementation of method handles and reflection. The code did not answer my question.) Is it still possible to reflectively invoke methods with 127 * 2 (long) + 1 (int) = 255 parameters? The following code tests this once using `Method.invoke` and another time it tries to test it using `MethodHandles.lookup().unreflect()`. (I'm assuming (!) that the new code in this PR is pretty much "equivalent" to `MethodHandles.lookup().unreflect()`) The test using method handles fails with an (expected) IAE. Question: Can someone confirm that `Method.invoke` will still work with 255 parameters after this PR gets merged?

java.lang.IllegalArgumentException: bad parameter count 256 at java.base/java.lang.invoke.MethodHandleStatics.newIllegalArgumentException(MethodHandleStatics.java:134) at java.base/java.lang.invoke.MethodType.checkSlotCount(MethodType.java:229) at java.base/java.lang.invoke.MethodType.insertParameterTypes(MethodType.java:440) at java.base/java.lang.invoke.MethodType.appendParameterTypes(MethodType.java:464) at java.base/java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(DirectMethodHandle.java:257) at java.base/java.lang.invoke.DirectMethodHandle.preparedLambdaForm(DirectMethodHandle.java:234) at java.base/java.lang.invoke.DirectMethodHandle.preparedLambdaForm(DirectMethodHandle.java:219) at java.base/java.lang.invoke.DirectMethodHandle.preparedLambdaForm(DirectMethodHandle.java:228) at java.base/java.lang.invoke.DirectMethodHandle.make(DirectMethodHandle.java:108) at java.base/java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(MethodHandles.java:3988) at java.base/java.lang.invoke.MethodHandles$Lookup.getDirectMethodNoSecurityManager(MethodHandles.java:3944) at java.base/java.lang.invoke.MethodHandles$Lookup.unreflect(MethodHandles.java:3351) at ReflectionParameterCountTest.lambda$0(ReflectionParameterCountTest.java:42) at org.junit.jupiter.api.AssertDoesNotThrow.assertDoesNotThrow(AssertDoesNotThrow.java:50)
import static org.junit.jupiter.api.Assertions.assertDoesNotThrow; import static org.junit.jupiter.api.Assertions.assertEquals; import java.lang.invoke.MethodHandle; import java.lang.invoke.MethodHandles; import java.lang.reflect.Method; import org.junit.jupiter.api.Test; public class ReflectionParameterCountTest { @Test public void testReflectionMaxParameterCount() throws Throwable { Method m = this.getClass().getMethod("f", long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, long.class, int.class); long resultViaMethod = (long) m.invoke(m, 0L, 1L, 2L, 3L, 4L, 5L, 6L, 7L, 8L, 9L, 10L, 11L, 12L, 13L, 14L, 15L, 16L, 17L, 18L, 19L, 20L, 21L, 22L, 23L, 24L, 25L, 26L, 27L, 28L, 29L, 30L, 31L, 32L, 33L, 34L, 35L, 36L, 37L, 38L, 39L, 40L, 41L, 42L, 43L, 44L, 45L, 46L, 47L, 48L, 49L, 50L, 51L, 52L, 53L, 54L, 55L, 56L, 57L, 58L, 59L, 60L, 61L, 62L, 63L, 64L, 65L, 66L, 67L, 68L, 69L, 70L, 71L, 72L, 73L, 74L, 75L, 76L, 77L, 78L, 79L, 80L, 81L, 82L, 83L, 84L, 85L, 86L, 87L, 88L, 89L, 90L, 91L, 92L, 93L, 94L, 95L, 96L, 97L, 98L, 99L, 100L, 101L, 102L, 103L, 104L, 105L, 106L, 107L, 108L, 109L, 110L, 111L, 112L, 113L, 114L, 115L, 116L, 117L, 118L, 119L, 120L, 121L, 122L, 123L, 124L, 125L, 126L, 127); assertEquals(127, resultViaMethod); assertDoesNotThrow(() -> { MethodHandles.lookup().unreflect(m); }); MethodHandle mh = MethodHandles.lookup().unreflect(m); long resultViaMethodHandle = (long) mh.invoke(m, 0L, 1L, 2L, 3L, 4L, 5L, 6L, 7L, 8L, 9L, 10L, 11L, 12L, 13L, 14L, 15L, 16L, 17L, 18L, 19L, 20L, 21L, 22L, 23L, 24L, 25L, 26L, 27L, 28L, 29L, 30L, 31L, 32L, 33L, 34L, 35L, 36L, 37L, 38L, 39L, 40L, 41L, 42L, 43L, 44L, 45L, 46L, 47L, 48L, 49L, 50L, 51L, 52L, 53L, 54L, 55L, 56L, 57L, 58L, 59L, 60L, 61L, 62L, 63L, 64L, 65L, 66L, 67L, 68L, 69L, 70L, 71L, 72L, 73L, 74L, 75L, 76L, 77L, 78L, 79L, 80L, 81L, 82L, 83L, 84L, 85L, 86L, 87L, 88L, 89L, 90L, 91L, 92L, 93L, 94L, 95L, 96L, 97L, 98L, 99L, 100L, 101L, 102L, 103L, 104L, 105L, 106L, 107L, 108L, 109L, 110L, 111L, 112L, 113L, 114L, 115L, 116L, 117L, 118L, 119L, 120L, 121L, 122L, 123L, 124L, 125L, 126L, 127); assertEquals(127, resultViaMethodHandle); } public static long f(long a0, long a1, long a2, long a3, long a4, long a5, long a6, long a7, long a8, long a9, long a10, long a11, long a12, long a13, long a14, long a15, long a16, long a17, long a18, long a19, long a20, long a21, long a22, long a23, long a24, long a25, long a26, long a27, long a28, long a29, long a30, long a31, long a32, long a33, long a34, long a35, long a36, long a37, long a38, long a39, long a40, long a41, long a42, long a43, long a44, long a45, long a46, long a47, long a48, long a49, long a50, long a51, long a52, long a53, long a54, long a55, long a56, long a57, long a58, long a59, long a60, long a61, long a62, long a63, long a64, long a65, long a66, long a67, long a68, long a69, long a70, long a71, long a72, long a73, long a74, long a75, long a76, long a77, long a78, long a79, long a80, long a81, long a82, long a83, long a84, long a85, long a86, long a87, long a88, long a89, long a90, long a91, long a92, long a93, long a94, long a95, long a96, long a97, long a98, long a99, long a100, long a101, long a102, long a103, long a104, long a105, long a106, long a107, long a108, long a109, long a110, long a111, long a112, long a113, long a114, long a115, long a116, long a117, long a118, long a119, long a120, long a121, long a122, long a123, long a124, long a125, long a126, int a127) { return a127; } } ------------- PR: https://git.openjdk.java.net/jdk/pull/5027 From jboes at openjdk.java.net Tue Oct 26 12:21:17 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Tue, 26 Oct 2021 12:21:17 GMT Subject: Integrated: 8275137: jdk.unsupported/sun.reflect.ReflectionFactory.readObjectNoDataForSerialization uses wrong signature In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 14:44:34 GMT, Julia Boes wrote: > sun.reflect.ReflectionFactory provides MethodHandles for the various serialization methods, it is a critical internal API in the jdk.unsupported module (see JEP 260 [1]) that may be used by 3rd party serialization libraries. > > One of these serialization methods is readObjectNoData [2]: > > ```private void readObjectNoData() throws ObjectStreamException;``` > > The issue: The method that returns the matching handle, sun.reflect.ReflectionFactory.readObjectNoDataForSerialization, uses an erroneous signature `readObjectNoData(ObjectInputStream)` - note the superfluous parameter. > > This change updates the specification and fixes the implementation in java.base/jdk.internal.reflect.ReflectionFactory. > > Testing: tier 1-3 > > [1] https://openjdk.java.net/jeps/260 > [2] https://docs.oracle.com/en/java/javase/15/docs/specs/serialization/input.html#the-readobjectnodata-method This pull request has now been integrated. Changeset: 4961373a Author: Julia Boes URL: https://git.openjdk.java.net/jdk/commit/4961373a676126cd557f92a2e7bbc8c66b2976b1 Stats: 28 lines in 3 files changed: 4 ins; 6 del; 18 mod 8275137: jdk.unsupported/sun.reflect.ReflectionFactory.readObjectNoDataForSerialization uses wrong signature Reviewed-by: dfuchs ------------- PR: https://git.openjdk.java.net/jdk/pull/5951 From alanb at openjdk.java.net Tue Oct 26 12:30:21 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 26 Oct 2021 12:30:21 GMT Subject: RFR: 8193682: Infinite loop in ZipOutputStream.close() [v4] In-Reply-To: References: Message-ID: On Tue, 26 Oct 2021 06:30:39 GMT, Ravi Reddy wrote: >> Hi all, >> >> Please review this fix for Infinite loop in ZipOutputStream.close(). >> The main issue here is when ever there is an exception during close operations on GZip we are not setting the deflator to a finished state which is leading to an infinite loop when we try writing on the same GZip instance( since we use while(!def.finished()) inside the write operation). >> >> Thanks, >> Ravi > > Ravi Reddy has updated the pull request incrementally with one additional commit since the last revision: > > 8193682 : Infinite loop in ZipOutputStream.close() src/java.base/share/classes/java/util/zip/DeflaterOutputStream.java line 247: > 245: if (usesDefaultDeflater) > 246: def.end(); > 247: throw e; The formatting is a bit wonky but I think this version is the best so far. It does mean that the stream state is undefined when close throws but this has always been the case. ------------- PR: https://git.openjdk.java.net/jdk/pull/5522 From naoto at openjdk.java.net Tue Oct 26 12:36:20 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 26 Oct 2021 12:36:20 GMT Subject: Integrated: 8275767: JDK source code contains redundant boolean operations in jdk.charsets In-Reply-To: References: Message-ID: On Mon, 25 Oct 2021 16:08:29 GMT, Naoto Sato wrote: > Trivial clean-up. This pull request has now been integrated. Changeset: 63e0f344 Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/63e0f344e9a2da135c76caff11e437dfc40408a6 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8275767: JDK source code contains redundant boolean operations in jdk.charsets Reviewed-by: lancea, rriggs, iris ------------- PR: https://git.openjdk.java.net/jdk/pull/6110 From aefimov at openjdk.java.net Tue Oct 26 12:52:58 2021 From: aefimov at openjdk.java.net (Aleksei Efimov) Date: Tue, 26 Oct 2021 12:52:58 GMT Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v8] In-Reply-To: References: Message-ID: > This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver. > > The following API classes are added to `java.net.spi` package to facilitate this: > - `InetAddressResolverProvider` - abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers. > - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations. > - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations. > - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation. > > More details in [JEP-418](https://openjdk.java.net/jeps/418). > > Testing: new and existing `tier1:tier3` tests Aleksei Efimov 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 14 additional commits since the last revision: - Changes to address review comments - Update tests to address SM deprecation - Merge branch 'master' into JDK-8244202_JEP418_impl - More javadoc updates to API classes - Review updates + move resolver docs to the provider class (CSR update to follow) - Change InetAddressResolver method names - Remove no longer used import from IPSupport - Rename IPSupport.hasAddress and update it to use SocketChannel.open - Address review comments: javadoc + code cleanup - Address resolver bootstraping issue - ... and 4 more: https://git.openjdk.java.net/jdk/compare/a8495826...1378686b ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5822/files - new: https://git.openjdk.java.net/jdk/pull/5822/files/fa655be2..1378686b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5822&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5822&range=06-07 Stats: 32082 lines in 838 files changed: 22928 ins; 6060 del; 3094 mod Patch: https://git.openjdk.java.net/jdk/pull/5822.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5822/head:pull/5822 PR: https://git.openjdk.java.net/jdk/pull/5822 From aefimov at openjdk.java.net Tue Oct 26 12:53:06 2021 From: aefimov at openjdk.java.net (Aleksei Efimov) Date: Tue, 26 Oct 2021 12:53:06 GMT Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v7] In-Reply-To: <8edQIj95FsYJ3_gmv98KEIVAwFvNxduvXIgrkY96vSk=.6d3f216f-c956-4906-8b81-5f57a79d00d9@github.com> References: <8edQIj95FsYJ3_gmv98KEIVAwFvNxduvXIgrkY96vSk=.6d3f216f-c956-4906-8b81-5f57a79d00d9@github.com> Message-ID: On Sat, 23 Oct 2021 06:19:46 GMT, Alan Bateman wrote: >> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision: >> >> More javadoc updates to API classes > > src/java.base/share/classes/java/net/InetAddress.java line 169: > >> 167: * Access Protocol (LDAP). >> 168: * The particular naming services that the built-in resolver uses by default >> 169: * depend on the configuration of the local machine. > > depend -> depends Thanks, changed in 1378686becfcbf18793556de8381b5ebcd79698d > src/java.base/share/classes/java/net/spi/InetAddressResolver.java line 38: > >> 36: * deployed as a >> 37: * system-wide resolver. {@link InetAddress} delegates all lookup requests to >> 38: * the deployed system-wide resolver instance. > > I think the class description would be a bit clearer if we drop sentence 2 because it overlaps with paragraph 2. I think we can adjust sentence 3 to "InetAddress delegates all lookup operations to the system-wide resolver" and it will all flow nicely. Thanks, changed as suggested in 1378686becfcbf18793556de8381b5ebcd79698d > src/java.base/share/classes/java/net/spi/InetAddressResolver.java line 88: > >> 86: * to a valid IP address length >> 87: */ >> 88: String lookupByAddress(byte[] addr) throws UnknownHostException; > > I assume this throws NPE if addr is null. 1378686becfcbf18793556de8381b5ebcd79698d: added @ throws NPE javadoc, also added additional checks for `null` parameter values into the built-in and hosts file resolver implementations. > src/java.base/share/classes/java/net/spi/InetAddressResolverProvider.java line 45: > >> 43: * system-wide resolver instance, which is used by >> 44: * >> 45: * InetAddress. > > I think we should prune some some of the text from the class description to avoid repetition. Here's a suggestion: > > 1. Add the following immediately after the sentence "A given innovation ..." > "It is set after the VM is fully initialized and when an invocation of a method in InetAddress class triggers the first lookup operation. > > 2. Replace the text in L47-65 with: > "A resolver provider is located and loaded by InetAddress to create the systwm-wide resolver as follows: > > 3. Replace the remaining three usages of "install" with "set". Thanks, changed as suggested: 1378686becfcbf18793556de8381b5ebcd79698d ------------- PR: https://git.openjdk.java.net/jdk/pull/5822 From aefimov at openjdk.java.net Tue Oct 26 12:53:09 2021 From: aefimov at openjdk.java.net (Aleksei Efimov) Date: Tue, 26 Oct 2021 12:53:09 GMT Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v5] In-Reply-To: References: <1v6OpqkyZp6XBq9lXQfahKEEgtBIdPjNWydqJ9Cwipc=.959e01c2-1e2d-4540-8ed5-41198dd71c2b@github.com> Message-ID: On Sat, 23 Oct 2021 06:33:52 GMT, Alan Bateman wrote: >> src/java.base/share/classes/java/net/spi/InetAddressResolverProvider.java line 52: >> >>> 50: /** >>> 51: * Initialise and return the {@link InetAddressResolver} provided by >>> 52: * this provider. This method is called by {@link InetAddress} when >> >> "the InetAddressResolver" suggests there is just one instance. That is probably the case but I don't think you want to be restricted to that. > > Initialise -> Initialize to be consistent with other usages that use US spelling. Thanks, changed in 1378686becfcbf18793556de8381b5ebcd79698d ------------- PR: https://git.openjdk.java.net/jdk/pull/5822 From aefimov at openjdk.java.net Tue Oct 26 12:55:11 2021 From: aefimov at openjdk.java.net (Aleksei Efimov) Date: Tue, 26 Oct 2021 12:55:11 GMT Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v7] In-Reply-To: References: <8edQIj95FsYJ3_gmv98KEIVAwFvNxduvXIgrkY96vSk=.6d3f216f-c956-4906-8b81-5f57a79d00d9@github.com> Message-ID: On Tue, 26 Oct 2021 12:49:30 GMT, Aleksei Efimov wrote: >> src/java.base/share/classes/java/net/spi/InetAddressResolverProvider.java line 45: >> >>> 43: * system-wide resolver instance, which is used by >>> 44: * >>> 45: * InetAddress. >> >> I think we should prune some some of the text from the class description to avoid repetition. Here's a suggestion: >> >> 1. Add the following immediately after the sentence "A given innovation ..." >> "It is set after the VM is fully initialized and when an invocation of a method in InetAddress class triggers the first lookup operation. >> >> 2. Replace the text in L47-65 with: >> "A resolver provider is located and loaded by InetAddress to create the systwm-wide resolver as follows: >> >> 3. Replace the remaining three usages of "install" with "set". > > Thanks, changed as suggested: 1378686becfcbf18793556de8381b5ebcd79698d Pruned `InetAddressResolverProvider` class-level doc as suggested: 1378686becfcbf18793556de8381b5ebcd79698d ------------- PR: https://git.openjdk.java.net/jdk/pull/5822 From naoto at openjdk.java.net Tue Oct 26 13:02:16 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 26 Oct 2021 13:02:16 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v4] In-Reply-To: References: Message-ID: On Tue, 26 Oct 2021 10:42:49 GMT, Daniel Fuchs wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Reflecting review comments > > src/java.base/share/classes/java/io/Console.java line 590: > >> 588: if (cs == null) { >> 589: cs = Charset.forName(StaticProperty.nativeEncoding(), >> 590: Charset.defaultCharset()); > > I assume that `StaticProperty.nativeEncoding()` will never be `null`? Otherwise an IAE would be thrown here where previously `Charset.defaultCharset()` would be used. Yes. `StaticProperty.nativeEncoding()` caches the value to `native.encoding` system property. The value is not optional, so it should be considered an error if `StaticProperty.nativeEncoding()` returned `null`. https://download.java.net/java/early_access/jdk18/docs/api/java.base/java/lang/System.html#native.encoding ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From alanb at openjdk.java.net Tue Oct 26 13:11:21 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 26 Oct 2021 13:11:21 GMT Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v8] In-Reply-To: References: Message-ID: <1ocUc2kRrpqHA-uWpjWrTtByfCvRoXWV-tbDJCEjmbs=.1149b134-96fc-45c3-81e3-1cee89b8d3aa@github.com> On Tue, 26 Oct 2021 12:52:58 GMT, Aleksei Efimov wrote: >> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver. >> >> The following API classes are added to `java.net.spi` package to facilitate this: >> - `InetAddressResolverProvider` - abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers. >> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations. >> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations. >> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation. >> >> More details in [JEP-418](https://openjdk.java.net/jeps/418). >> >> Testing: new and existing `tier1:tier3` tests > > Aleksei Efimov 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 14 additional commits since the last revision: > > - Changes to address review comments > - Update tests to address SM deprecation > - Merge branch 'master' into JDK-8244202_JEP418_impl > - More javadoc updates to API classes > - Review updates + move resolver docs to the provider class (CSR update to follow) > - Change InetAddressResolver method names > - Remove no longer used import from IPSupport > - Rename IPSupport.hasAddress and update it to use SocketChannel.open > - Address review comments: javadoc + code cleanup > - Address resolver bootstraping issue > - ... and 4 more: https://git.openjdk.java.net/jdk/compare/c2db4e04...1378686b Thanks for the updates to the API docs, you've addressed all my comments. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5822 From dfuchs at openjdk.java.net Tue Oct 26 13:21:13 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 26 Oct 2021 13:21:13 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v4] In-Reply-To: References: Message-ID: <8L1W2kyFbAv3m7lxkWXUCy_015_ux9vZfhMLX--nUas=.ab4e6845-25c3-4527-b8cf-42302eaa6a70@github.com> On Sat, 23 Oct 2021 22:13:35 GMT, Naoto Sato wrote: >> During the review of JEP 400, a proposal to provide an overloaded method to `Charset.forName()` was suggested [[1]](https://github.com/openjdk/jdk/pull/4733#discussion_r669693954). This PR is to implement the proposal. A CSR is also drafted as https://bugs.openjdk.java.net/browse/JDK-8275348 > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Reflecting review comments Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From dfuchs at openjdk.java.net Tue Oct 26 13:21:14 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 26 Oct 2021 13:21:14 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v4] In-Reply-To: References: Message-ID: <9THjSfJ50FMcPGdFjqjdPXk6m_JfBvqwgHkiRGciU_c=.1a094cbe-69d8-4433-85e3-cb09318f874d@github.com> On Tue, 26 Oct 2021 12:59:11 GMT, Naoto Sato wrote: >> src/java.base/share/classes/java/io/Console.java line 590: >> >>> 588: if (cs == null) { >>> 589: cs = Charset.forName(StaticProperty.nativeEncoding(), >>> 590: Charset.defaultCharset()); >> >> I assume that `StaticProperty.nativeEncoding()` will never be `null`? Otherwise an IAE would be thrown here where previously `Charset.defaultCharset()` would be used. > > Yes. `StaticProperty.nativeEncoding()` caches the value to `native.encoding` system property. The value is not optional, so it should be considered an error if `StaticProperty.nativeEncoding()` returned `null`. > https://download.java.net/java/early_access/jdk18/docs/api/java.base/java/lang/System.html#native.encoding Thanks for the clarification. ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From dfuchs at openjdk.java.net Tue Oct 26 15:10:24 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 26 Oct 2021 15:10:24 GMT Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v8] In-Reply-To: References: Message-ID: On Tue, 26 Oct 2021 12:52:58 GMT, Aleksei Efimov wrote: >> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver. >> >> The following API classes are added to `java.net.spi` package to facilitate this: >> - `InetAddressResolverProvider` - abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers. >> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations. >> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations. >> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation. >> >> More details in [JEP-418](https://openjdk.java.net/jeps/418). >> >> Testing: new and existing `tier1:tier3` tests > > Aleksei Efimov 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 14 additional commits since the last revision: > > - Changes to address review comments > - Update tests to address SM deprecation > - Merge branch 'master' into JDK-8244202_JEP418_impl > - More javadoc updates to API classes > - Review updates + move resolver docs to the provider class (CSR update to follow) > - Change InetAddressResolver method names > - Remove no longer used import from IPSupport > - Rename IPSupport.hasAddress and update it to use SocketChannel.open > - Address review comments: javadoc + code cleanup > - Address resolver bootstraping issue > - ... and 4 more: https://git.openjdk.java.net/jdk/compare/10094444...1378686b Marked as reviewed by dfuchs (Reviewer). src/java.base/share/classes/java/net/InetAddress.java line 1151: > 1149: > 1150: Objects.requireNonNull(host); > 1151: Objects.requireNonNull(lookupPolicy); for consistency we could add `@throws NullPointerException` to the API doc of that method - since it seems to have everything else... ------------- PR: https://git.openjdk.java.net/jdk/pull/5822 From joe.darcy at oracle.com Tue Oct 26 15:35:57 2021 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Tue, 26 Oct 2021 08:35:57 -0700 Subject: RFR: 8275293: A change done with JDK-8268764 mismatches the java.rmi.server.ObjID.hashCode spec In-Reply-To: References: Message-ID: <7fcdf652-58dd-7bdf-3b8d-a1b05834ea75@oracle.com> It is a non-goal to replicate all of the JCK test coverage in the regression test suite. -Joe On 10/25/2021 7:17 PM, Sergey Bylokhov wrote: > On Fri, 15 Oct 2021 07:17:52 GMT, ?????? ??????? wrote: > >> It looks like we cannot use `Long.hashCode(long)` for `java.rmi.server.ObjID.hashCode()` due to specification: https://docs.oracle.com/en/java/javase/17/docs/api/java.rmi/java/rmi/server/ObjID.html#hashCode(). > I think this one was missed due to the absence of the coverage in the jtreg test suite, and some people have no access to the jck to run it in advance. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/5963 From mchung at openjdk.java.net Tue Oct 26 16:18:14 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 26 Oct 2021 16:18:14 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v14] In-Reply-To: References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> Message-ID: On Mon, 25 Oct 2021 22:39:47 GMT, intrigus wrote: > Question: Can someone confirm that `Method.invoke` will still work with 255 parameters after this PR gets merged? Thanks for the test case. For the case when method handles cannot be created due to the arity limit, it can fall back to the VM native reflection support. I have a fix for it. ------------- PR: https://git.openjdk.java.net/jdk/pull/5027 From aefimov at openjdk.java.net Tue Oct 26 16:24:48 2021 From: aefimov at openjdk.java.net (Aleksei Efimov) Date: Tue, 26 Oct 2021 16:24:48 GMT Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v9] In-Reply-To: References: Message-ID: > This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver. > > The following API classes are added to `java.net.spi` package to facilitate this: > - `InetAddressResolverProvider` - abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers. > - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations. > - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations. > - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation. > > More details in [JEP-418](https://openjdk.java.net/jeps/418). > > Testing: new and existing `tier1:tier3` tests Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision: Add @ throws NPE to hosts file resolver javadoc ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5822/files - new: https://git.openjdk.java.net/jdk/pull/5822/files/1378686b..2ca78ba9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5822&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5822&range=07-08 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5822.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5822/head:pull/5822 PR: https://git.openjdk.java.net/jdk/pull/5822 From aefimov at openjdk.java.net Tue Oct 26 16:24:55 2021 From: aefimov at openjdk.java.net (Aleksei Efimov) Date: Tue, 26 Oct 2021 16:24:55 GMT Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v8] In-Reply-To: References: Message-ID: On Tue, 26 Oct 2021 15:04:54 GMT, Daniel Fuchs wrote: >> Aleksei Efimov 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 14 additional commits since the last revision: >> >> - Changes to address review comments >> - Update tests to address SM deprecation >> - Merge branch 'master' into JDK-8244202_JEP418_impl >> - More javadoc updates to API classes >> - Review updates + move resolver docs to the provider class (CSR update to follow) >> - Change InetAddressResolver method names >> - Remove no longer used import from IPSupport >> - Rename IPSupport.hasAddress and update it to use SocketChannel.open >> - Address review comments: javadoc + code cleanup >> - Address resolver bootstraping issue >> - ... and 4 more: https://git.openjdk.java.net/jdk/compare/1bbecc93...1378686b > > src/java.base/share/classes/java/net/InetAddress.java line 1151: > >> 1149: >> 1150: Objects.requireNonNull(host); >> 1151: Objects.requireNonNull(lookupPolicy); > > for consistency we could add `@throws NullPointerException` to the API doc of that method - since it seems to have everything else... Added `@throws NullPointerException` to the hosts file resolver API docs: 2ca78ba98dc81cd6cc44b53dc7d56a6ae42c2736 ------------- PR: https://git.openjdk.java.net/jdk/pull/5822 From dfuchs at openjdk.java.net Tue Oct 26 16:30:16 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 26 Oct 2021 16:30:16 GMT Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v9] In-Reply-To: References: Message-ID: <0mvmoo3ws7YZ_Wf_9bZmvjDHZZ5PQFaOCBhpn4x-q30=.08ef6e7a-f8b1-4b3f-9a1f-2d91e44d2598@github.com> On Tue, 26 Oct 2021 16:24:48 GMT, Aleksei Efimov wrote: >> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver. >> >> The following API classes are added to `java.net.spi` package to facilitate this: >> - `InetAddressResolverProvider` - abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers. >> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations. >> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations. >> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation. >> >> More details in [JEP-418](https://openjdk.java.net/jeps/418). >> >> Testing: new and existing `tier1:tier3` tests > > Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision: > > Add @ throws NPE to hosts file resolver javadoc Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5822 From mchung at openjdk.java.net Tue Oct 26 16:35:34 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 26 Oct 2021 16:35:34 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v15] In-Reply-To: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> Message-ID: > This reimplements core reflection with method handles. > > For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. > > The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. > > The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. > > Ran tier1-tier8 tests. > > [1] https://bugs.openjdk.java.net/browse/JDK-8013527 > [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 Mandy Chung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 40 commits: - Fall back to the VM native reflection support if method handle cannot be created - fix bug id in test - Merge - Merge branch 'master' of https://github.com/openjdk/jdk into reimplement-method-invoke - Merge branch 'master' of https://github.com/openjdk/jdk into reimplement-method-invoke - Separate paramFlgas into paramCount and flags fields - Minor cleanup. Improve javadoc in CallerSensitiveAdapter - Fix left-over assignment - Remove duplicated microbenchmarks - Avoid pitfall with unwanted inlining in some cases. Also remove boxing/unboxing to focus on the invocation cost - ... and 30 more: https://git.openjdk.java.net/jdk/compare/97d3280e...64738bb2 ------------- Changes: https://git.openjdk.java.net/jdk/pull/5027/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5027&range=14 Stats: 6409 lines in 78 files changed: 5864 ins; 317 del; 228 mod Patch: https://git.openjdk.java.net/jdk/pull/5027.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5027/head:pull/5027 PR: https://git.openjdk.java.net/jdk/pull/5027 From lancea at openjdk.java.net Tue Oct 26 17:39:11 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 26 Oct 2021 17:39:11 GMT Subject: RFR: 8193682: Infinite loop in ZipOutputStream.close() [v4] In-Reply-To: References: Message-ID: On Tue, 26 Oct 2021 06:30:39 GMT, Ravi Reddy wrote: >> Hi all, >> >> Please review this fix for Infinite loop in ZipOutputStream.close(). >> The main issue here is when ever there is an exception during close operations on GZip we are not setting the deflator to a finished state which is leading to an infinite loop when we try writing on the same GZip instance( since we use while(!def.finished()) inside the write operation). >> >> Thanks, >> Ravi > > Ravi Reddy has updated the pull request incrementally with one additional commit since the last revision: > > 8193682 : Infinite loop in ZipOutputStream.close() I think overall this looks good. Thank you for continuing to work on this. I do believe it would be worth adding a CSR just to document the behavior realizing that it was always left undefined in the past Please also add a comment to each test describing its intent test/jdk/java/util/zip/GZIP/GZipLoopTest.java line 41: > 39: public class GZipLoopTest { > 40: private static final int FINISH_NUM = 512; > 41: private static OutputStream outStream = new OutputStream() { Please add a comment describing the intent of outstream and for FINISH_NUM. You might also consider a different name vs FINISH_NUM. Perhaps the comment will clarify this test/jdk/java/util/zip/GZIP/GZipLoopTest.java line 57: > 55: @Test > 56: public void testGZipClose() throws IOException { > 57: rand.nextBytes(b); You could possibly consider using a BeforeTest or BeforeMethod if you choose to reduce redundancy. No biggie otherwise. test/jdk/java/util/zip/GZIP/GZipLoopTest.java line 65: > 63: } catch (IOException e) { > 64: //expected > 65: } For the above if an IOException is expected, should this be tested via assertThrows()? ------------- PR: https://git.openjdk.java.net/jdk/pull/5522 From naoto at openjdk.java.net Tue Oct 26 18:26:09 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 26 Oct 2021 18:26:09 GMT Subject: RFR: 8275863: Use encodeASCII for ASCII-compatible DoubleByte encodings In-Reply-To: References: Message-ID: On Mon, 25 Oct 2021 10:16:23 GMT, Claes Redestad wrote: > Enhance ASCII-compatible `DoubleByte` encodings to make use of the `StringCoding.implEncodeAsciiArray` intrinsic, which makes many such `CharsetEncoder`s encode ASCII text at speeds comparable to most single-byte encoders - and also more in line with how well these charsets behave when calling `String.getBytes`: > > Before: > > Benchmark (size) (type) Mode Cnt Score Error Units > CharsetEncodeDecode.encode 16384 ISO-8859-1 avgt 30 3.021 ? 0.120 us/op > CharsetEncodeDecode.encode 16384 Shift-JIS avgt 30 47.793 ? 1.942 us/op > CharsetEncodeDecode.encode 16384 GB2312 avgt 30 49.598 ? 2.006 us/op > CharsetEncodeDecode.encode 16384 EUC-JP avgt 30 68.709 ? 5.019 us/op > CharsetEncodeDecode.encode 16384 EUC-KR avgt 30 48.033 ? 1.651 us/op > > > Patched: > > Benchmark (size) (type) Mode Cnt Score Error Units > CharsetEncodeDecode.encode 16384 ISO-8859-1 avgt 30 2.856 ? 0.078 us/op > CharsetEncodeDecode.encode 16384 Shift-JIS avgt 30 5.287 ? 0.209 us/op > CharsetEncodeDecode.encode 16384 GB2312 avgt 30 5.490 ? 0.251 us/op > CharsetEncodeDecode.encode 16384 EUC-JP avgt 30 7.657 ? 0.368 us/op > CharsetEncodeDecode.encode 16384 EUC-KR avgt 30 5.718 ? 0.267 us/op > > > The `isASCIICompatible` predicate on `DoubleByte` was added in JEP 254 for the purpose of implementing such ASCII fast-paths, but is only used in what is now `String.encodeWithEncoder` to speed up `String.getBytes(...)` operations. > > Testing: tier1-3 Looks good. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6102 From rriggs at openjdk.java.net Tue Oct 26 19:00:15 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 26 Oct 2021 19:00:15 GMT Subject: RFR: 8275863: Use encodeASCII for ASCII-compatible DoubleByte encodings In-Reply-To: References: Message-ID: On Mon, 25 Oct 2021 10:16:23 GMT, Claes Redestad wrote: > Enhance ASCII-compatible `DoubleByte` encodings to make use of the `StringCoding.implEncodeAsciiArray` intrinsic, which makes many such `CharsetEncoder`s encode ASCII text at speeds comparable to most single-byte encoders - and also more in line with how well these charsets behave when calling `String.getBytes`: > > Before: > > Benchmark (size) (type) Mode Cnt Score Error Units > CharsetEncodeDecode.encode 16384 ISO-8859-1 avgt 30 3.021 ? 0.120 us/op > CharsetEncodeDecode.encode 16384 Shift-JIS avgt 30 47.793 ? 1.942 us/op > CharsetEncodeDecode.encode 16384 GB2312 avgt 30 49.598 ? 2.006 us/op > CharsetEncodeDecode.encode 16384 EUC-JP avgt 30 68.709 ? 5.019 us/op > CharsetEncodeDecode.encode 16384 EUC-KR avgt 30 48.033 ? 1.651 us/op > > > Patched: > > Benchmark (size) (type) Mode Cnt Score Error Units > CharsetEncodeDecode.encode 16384 ISO-8859-1 avgt 30 2.856 ? 0.078 us/op > CharsetEncodeDecode.encode 16384 Shift-JIS avgt 30 5.287 ? 0.209 us/op > CharsetEncodeDecode.encode 16384 GB2312 avgt 30 5.490 ? 0.251 us/op > CharsetEncodeDecode.encode 16384 EUC-JP avgt 30 7.657 ? 0.368 us/op > CharsetEncodeDecode.encode 16384 EUC-KR avgt 30 5.718 ? 0.267 us/op > > > The `isASCIICompatible` predicate on `DoubleByte` was added in JEP 254 for the purpose of implementing such ASCII fast-paths, but is only used in what is now `String.encodeWithEncoder` to speed up `String.getBytes(...)` operations. > > Testing: tier1-3 Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6102 From alanb at openjdk.java.net Tue Oct 26 19:08:15 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 26 Oct 2021 19:08:15 GMT Subject: RFR: 8275863: Use encodeASCII for ASCII-compatible DoubleByte encodings In-Reply-To: References: Message-ID: <7GvaEmUjCwTZUQVIo09tAKMT1rwqsmfdZy-gA-Q5fk0=.44e2b58d-573f-4fcd-bc83-5e59fad9a422@github.com> On Mon, 25 Oct 2021 10:16:23 GMT, Claes Redestad wrote: > Enhance ASCII-compatible `DoubleByte` encodings to make use of the `StringCoding.implEncodeAsciiArray` intrinsic, which makes many such `CharsetEncoder`s encode ASCII text at speeds comparable to most single-byte encoders - and also more in line with how well these charsets behave when calling `String.getBytes`: > > Before: > > Benchmark (size) (type) Mode Cnt Score Error Units > CharsetEncodeDecode.encode 16384 ISO-8859-1 avgt 30 3.021 ? 0.120 us/op > CharsetEncodeDecode.encode 16384 Shift-JIS avgt 30 47.793 ? 1.942 us/op > CharsetEncodeDecode.encode 16384 GB2312 avgt 30 49.598 ? 2.006 us/op > CharsetEncodeDecode.encode 16384 EUC-JP avgt 30 68.709 ? 5.019 us/op > CharsetEncodeDecode.encode 16384 EUC-KR avgt 30 48.033 ? 1.651 us/op > > > Patched: > > Benchmark (size) (type) Mode Cnt Score Error Units > CharsetEncodeDecode.encode 16384 ISO-8859-1 avgt 30 2.856 ? 0.078 us/op > CharsetEncodeDecode.encode 16384 Shift-JIS avgt 30 5.287 ? 0.209 us/op > CharsetEncodeDecode.encode 16384 GB2312 avgt 30 5.490 ? 0.251 us/op > CharsetEncodeDecode.encode 16384 EUC-JP avgt 30 7.657 ? 0.368 us/op > CharsetEncodeDecode.encode 16384 EUC-KR avgt 30 5.718 ? 0.267 us/op > > > The `isASCIICompatible` predicate on `DoubleByte` was added in JEP 254 for the purpose of implementing such ASCII fast-paths, but is only used in what is now `String.encodeWithEncoder` to speed up `String.getBytes(...)` operations. > > Testing: tier1-3 Good work ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6102 From bpb at openjdk.java.net Tue Oct 26 19:10:23 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 26 Oct 2021 19:10:23 GMT Subject: RFR: 8274750: java/io/File/GetXSpace.java failed: '/dev': 191488 != 190976 Message-ID: <6dZETgaCb3y_013oTmXeAqtD7GCV6Bab_nEehUsdh2U=.ba24c845-5ce6-4774-aac9-cf4f0879799d@github.com> Please consider this proposed change to ignore comparing the total size of `/dev` as returned by `DF(1)` and `STAT(2)` on macOS. ------------- Commit messages: - 8274750: java/io/File/GetXSpace.java failed: '/dev': 191488 != 190976 Changes: https://git.openjdk.java.net/jdk/pull/6122/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6122&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274750 Stats: 8 lines in 1 file changed: 7 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6122.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6122/head:pull/6122 PR: https://git.openjdk.java.net/jdk/pull/6122 From bpb at openjdk.java.net Tue Oct 26 19:10:24 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 26 Oct 2021 19:10:24 GMT Subject: RFR: 8274750: java/io/File/GetXSpace.java failed: '/dev': 191488 != 190976 In-Reply-To: <6dZETgaCb3y_013oTmXeAqtD7GCV6Bab_nEehUsdh2U=.ba24c845-5ce6-4774-aac9-cf4f0879799d@github.com> References: <6dZETgaCb3y_013oTmXeAqtD7GCV6Bab_nEehUsdh2U=.ba24c845-5ce6-4774-aac9-cf4f0879799d@github.com> Message-ID: On Tue, 26 Oct 2021 19:00:44 GMT, Brian Burkhalter wrote: > Please consider this proposed change to ignore comparing the total size of `/dev` as returned by `DF(1)` and `STAT(2)` on macOS. Alternative approaches would be to compare `File.getTotalSpace()` with `FileStore.getTotalSpace()` and / or have a tolerance on the comparison. ------------- PR: https://git.openjdk.java.net/jdk/pull/6122 From raffaello.giulietti at gmail.com Tue Oct 26 19:28:06 2021 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Tue, 26 Oct 2021 21:28:06 +0200 Subject: RFR (CSR): 8202555: Double.toString(double) sometimes produces incorrect results Message-ID: <548a4cd0-6aaf-a946-2521-4fc001000ae2@gmail.com> Hello, PR [1] and the accompanying article [2] have been subject to some positive reactions in the last couple of weeks. A fresh set of about 20 thousand additional hard test cases kindly provided by Paul Zimmermann of INRIA and other tests proposed by Guy Steele have been added to the code. The corresponding CSR [3] is in Finalized state for review. The proposed spec has been carefully written to uniquely define the outcomes and the code in the PR has been extensively tested to match the proposed spec. Behavioral backward compatibility has been a major goal for the CSR. In fact, in the vast majority of cases, the CSR and the current implementation agree on the outcomes. As the CSR is a prerequisite for the advancement of the PR, I beg everybody entitled (and interested) to review and approve it and/or discuss it further. Greetings Raffaello ---- [1] https://github.com/openjdk/jdk/pull/3402 [2] https://drive.google.com/file/d/1luHhyQF9zKlM8yJ1nebU0OgVYhfC6CBN/view [3] https://bugs.openjdk.java.net/browse/JDK-8202555 From isipka at openjdk.java.net Tue Oct 26 19:48:47 2021 From: isipka at openjdk.java.net (Ivan =?UTF-8?B?xaBpcGth?=) Date: Tue, 26 Oct 2021 19:48:47 GMT Subject: RFR: 8275650: Problemlist java/io/File/createTempFile/SpecialTempFile.java for Windows 11 [v2] In-Reply-To: References: Message-ID: > cc @ctornqvi Ivan ?ipka 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: - fixed OS identifier - 8274122: added to problem list ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6025/files - new: https://git.openjdk.java.net/jdk/pull/6025/files/55b0228c..931a9ea4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6025&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6025&range=00-01 Stats: 20953 lines in 477 files changed: 16782 ins; 2674 del; 1497 mod Patch: https://git.openjdk.java.net/jdk/pull/6025.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6025/head:pull/6025 PR: https://git.openjdk.java.net/jdk/pull/6025 From naoto at openjdk.java.net Tue Oct 26 20:27:15 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 26 Oct 2021 20:27:15 GMT Subject: RFR: 8274750: java/io/File/GetXSpace.java failed: '/dev': 191488 != 190976 In-Reply-To: <6dZETgaCb3y_013oTmXeAqtD7GCV6Bab_nEehUsdh2U=.ba24c845-5ce6-4774-aac9-cf4f0879799d@github.com> References: <6dZETgaCb3y_013oTmXeAqtD7GCV6Bab_nEehUsdh2U=.ba24c845-5ce6-4774-aac9-cf4f0879799d@github.com> Message-ID: <2I7pc6rkAwreIivOk_NeenI07sbLozPpatUD3QecZn8=.82902a28-2869-4ee6-a92a-d10a7e4b42e6@github.com> On Tue, 26 Oct 2021 19:00:44 GMT, Brian Burkhalter wrote: > Please consider this proposed change to ignore comparing the total size of `/dev` as returned by `DF(1)` and `STAT(2)` on macOS. test/jdk/java/io/File/GetXSpace.java line 210: > 208: if (Platform.isOSX() && s.name().equals("/dev")) { > 209: out.println("/dev:\n Skipping size comparison for /dev on macOS"); > 210: return; Should it call `pass()`? ------------- PR: https://git.openjdk.java.net/jdk/pull/6122 From bpb at openjdk.java.net Tue Oct 26 20:31:11 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 26 Oct 2021 20:31:11 GMT Subject: RFR: 8274750: java/io/File/GetXSpace.java failed: '/dev': 191488 != 190976 In-Reply-To: <2I7pc6rkAwreIivOk_NeenI07sbLozPpatUD3QecZn8=.82902a28-2869-4ee6-a92a-d10a7e4b42e6@github.com> References: <6dZETgaCb3y_013oTmXeAqtD7GCV6Bab_nEehUsdh2U=.ba24c845-5ce6-4774-aac9-cf4f0879799d@github.com> <2I7pc6rkAwreIivOk_NeenI07sbLozPpatUD3QecZn8=.82902a28-2869-4ee6-a92a-d10a7e4b42e6@github.com> Message-ID: On Tue, 26 Oct 2021 20:24:28 GMT, Naoto Sato wrote: >> Please consider this proposed change to ignore comparing the total size of `/dev` as returned by `DF(1)` and `STAT(2)` on macOS. > > test/jdk/java/io/File/GetXSpace.java line 210: > >> 208: if (Platform.isOSX() && s.name().equals("/dev")) { >> 209: out.println("/dev:\n Skipping size comparison for /dev on macOS"); >> 210: return; > > Should it call `pass()`? I don't know. As it is skipped it is not exactly passed but ignored. ------------- PR: https://git.openjdk.java.net/jdk/pull/6122 From bpb at openjdk.java.net Tue Oct 26 21:03:14 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 26 Oct 2021 21:03:14 GMT Subject: RFR: 8275650: Problemlist java/io/File/createTempFile/SpecialTempFile.java for Windows 11 [v2] In-Reply-To: References: Message-ID: <1SIBUzvCABEdNsoeGoiCsWnhSWD_IYz7tPezUPtglLY=.19364882-00f4-4e3c-a150-da7003f91661@github.com> On Tue, 26 Oct 2021 19:48:47 GMT, Ivan ?ipka wrote: >> cc @ctornqvi > > Ivan ?ipka 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: > > - fixed OS identifier > - 8274122: added to problem list Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6025 From iignatyev at openjdk.java.net Tue Oct 26 21:03:17 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Tue, 26 Oct 2021 21:03:17 GMT Subject: RFR: 8275650: Problemlist java/io/File/createTempFile/SpecialTempFile.java for Windows 11 [v2] In-Reply-To: References: Message-ID: On Tue, 26 Oct 2021 19:48:47 GMT, Ivan ?ipka wrote: >> cc @ctornqvi > > Ivan ?ipka 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: > > - fixed OS identifier > - 8274122: added to problem list And now you use an incorrect bug id in the problem list, it should be 8274122 ------------- PR: https://git.openjdk.java.net/jdk/pull/6025 From bpb at openjdk.java.net Tue Oct 26 21:08:10 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 26 Oct 2021 21:08:10 GMT Subject: RFR: 8275650: Problemlist java/io/File/createTempFile/SpecialTempFile.java for Windows 11 [v2] In-Reply-To: References: Message-ID: <3VpeLXWat6Dpf2WJCMquD03QesuORjCqYX2Q5oAVoOA=.295672f0-39dd-40ce-87e9-6a59156d530f@github.com> On Tue, 26 Oct 2021 20:59:45 GMT, Igor Ignatyev wrote: >> Ivan ?ipka has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: >> >> - fixed OS identifier >> - 8274122: added to problem list > > And now you use an incorrect bug id in the problem list, it should be 8274122 Oops! Thanks @iignatev ! ------------- PR: https://git.openjdk.java.net/jdk/pull/6025 From mchung at openjdk.java.net Wed Oct 27 02:32:31 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 27 Oct 2021 02:32:31 GMT Subject: RFR: JDK-8275703: System.loadLibrary fails on Big Sur for libraries hidden from filesystem Message-ID: <1d0vB2i2qrGaWRxtX_FqnYWrKcgXHaPvShDeSSG9cXg=.f733da58-3eaf-4eda-8c93-f8e81a384326@github.com> On, macOS 11.x, system libraries are loaded from dynamic linker cache. The libraries are no longer present on the filesystem. `NativeLibraries::loadLibrary` checks for the file existence before calling `JVM_LoadLibrary`. Such check no longer applies on Big Sur. This proposes that on macOS >= 11, it will skip the file existence check and attempt to load a library for each path from java.library.path and system library path. ------------- Commit messages: - trim whitespaces - add copyright header - fix typo - JDK-8275703: System.loadLibrary fails on Big Sur for libraries hidden from filesystem Changes: https://git.openjdk.java.net/jdk/pull/6127/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6127&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275703 Stats: 198 lines in 9 files changed: 170 ins; 2 del; 26 mod Patch: https://git.openjdk.java.net/jdk/pull/6127.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6127/head:pull/6127 PR: https://git.openjdk.java.net/jdk/pull/6127 From dholmes at openjdk.java.net Wed Oct 27 02:44:13 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 27 Oct 2021 02:44:13 GMT Subject: RFR: JDK-8275703: System.loadLibrary fails on Big Sur for libraries hidden from filesystem In-Reply-To: <1d0vB2i2qrGaWRxtX_FqnYWrKcgXHaPvShDeSSG9cXg=.f733da58-3eaf-4eda-8c93-f8e81a384326@github.com> References: <1d0vB2i2qrGaWRxtX_FqnYWrKcgXHaPvShDeSSG9cXg=.f733da58-3eaf-4eda-8c93-f8e81a384326@github.com> Message-ID: On Tue, 26 Oct 2021 22:51:29 GMT, Mandy Chung wrote: > On, macOS 11.x, system libraries are loaded from dynamic linker cache. The libraries are no longer present on the filesystem. `NativeLibraries::loadLibrary` checks for the file existence before calling `JVM_LoadLibrary`. Such check no longer applies on Big Sur. This proposes that on macOS >= 11, it will skip the file existence check and attempt to load a library for each path from java.library.path and system library path. Hi Mandy, Hotspot changes are fine. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6127 From jpai at openjdk.java.net Wed Oct 27 02:54:08 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Wed, 27 Oct 2021 02:54:08 GMT Subject: RFR: JDK-8275703: System.loadLibrary fails on Big Sur for libraries hidden from filesystem In-Reply-To: <1d0vB2i2qrGaWRxtX_FqnYWrKcgXHaPvShDeSSG9cXg=.f733da58-3eaf-4eda-8c93-f8e81a384326@github.com> References: <1d0vB2i2qrGaWRxtX_FqnYWrKcgXHaPvShDeSSG9cXg=.f733da58-3eaf-4eda-8c93-f8e81a384326@github.com> Message-ID: On Tue, 26 Oct 2021 22:51:29 GMT, Mandy Chung wrote: > On, macOS 11.x, system libraries are loaded from dynamic linker cache. The libraries are no longer present on the filesystem. `NativeLibraries::loadLibrary` checks for the file existence before calling `JVM_LoadLibrary`. Such check no longer applies on Big Sur. This proposes that on macOS >= 11, it will skip the file existence check and attempt to load a library for each path from java.library.path and system library path. src/java.base/macosx/classes/jdk/internal/loader/ClassLoaderHelper.java line 44: > 42: } catch (NumberFormatException e) {} > 43: } > 44: hasDynamicLoaderCache = major >= 11; Hello Mandy, I'm not too familiar with MacOS versioning schemes. However, in this specific logic, if the `os.version` value doesn't contain a dot character, then the `major` is initialized to `11`, which would then evaluate this `hasDynamicLoaderCache` to `true`. That would mean if the `os.version` is (for example) `10`, then `hasDynamicLoaderCache` will be incorrectly set to `true` here, isn't it? ------------- PR: https://git.openjdk.java.net/jdk/pull/6127 From jpai at openjdk.java.net Wed Oct 27 03:36:11 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Wed, 27 Oct 2021 03:36:11 GMT Subject: RFR: JDK-8275703: System.loadLibrary fails on Big Sur for libraries hidden from filesystem In-Reply-To: <1d0vB2i2qrGaWRxtX_FqnYWrKcgXHaPvShDeSSG9cXg=.f733da58-3eaf-4eda-8c93-f8e81a384326@github.com> References: <1d0vB2i2qrGaWRxtX_FqnYWrKcgXHaPvShDeSSG9cXg=.f733da58-3eaf-4eda-8c93-f8e81a384326@github.com> Message-ID: On Tue, 26 Oct 2021 22:51:29 GMT, Mandy Chung wrote: > On, macOS 11.x, system libraries are loaded from dynamic linker cache. The libraries are no longer present on the filesystem. `NativeLibraries::loadLibrary` checks for the file existence before calling `JVM_LoadLibrary`. Such check no longer applies on Big Sur. This proposes that on macOS >= 11, it will skip the file existence check and attempt to load a library for each path from java.library.path and system library path. src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java line 166: > 164: return null; > 165: } > 166: return file.getCanonicalPath(); I think a `!file.exists()` check would still be needed here to handle the case when `loadLibraryOnlyIfPresent` is `false`, isn't it? ------------- PR: https://git.openjdk.java.net/jdk/pull/6127 From jpai at openjdk.java.net Wed Oct 27 03:42:08 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Wed, 27 Oct 2021 03:42:08 GMT Subject: RFR: JDK-8275703: System.loadLibrary fails on Big Sur for libraries hidden from filesystem In-Reply-To: References: <1d0vB2i2qrGaWRxtX_FqnYWrKcgXHaPvShDeSSG9cXg=.f733da58-3eaf-4eda-8c93-f8e81a384326@github.com> Message-ID: <5BAH1dAVPdl7UnZRnSpe_7xOaX8Whsu_E0drRbcia-0=.449e99a7-ac53-4ffa-929b-b3ddc21c2f31@github.com> On Wed, 27 Oct 2021 03:31:00 GMT, Jaikiran Pai wrote: >> On, macOS 11.x, system libraries are loaded from dynamic linker cache. The libraries are no longer present on the filesystem. `NativeLibraries::loadLibrary` checks for the file existence before calling `JVM_LoadLibrary`. Such check no longer applies on Big Sur. This proposes that on macOS >= 11, it will skip the file existence check and attempt to load a library for each path from java.library.path and system library path. > > src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java line 166: > >> 164: return null; >> 165: } >> 166: return file.getCanonicalPath(); > > I think a `!file.exists()` check would still be needed here to handle the case when `loadLibraryOnlyIfPresent` is `false`, isn't it? Ignore this previous comment. I read your JBS comment just now which says: > The JDK side determines the path of the given library name and checks if it exists before calling JVM_LoadLibrary. A potential fix for MacOS might be to skip the file presence check and pass it to JVM. So, I think, the whole point of this change in this block is to skip the file existence check and return back a file path. ------------- PR: https://git.openjdk.java.net/jdk/pull/6127 From duke at openjdk.java.net Wed Oct 27 07:12:32 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Wed, 27 Oct 2021 07:12:32 GMT Subject: RFR: 8276042: Remove unused local variables in java.naming Message-ID: <4G5GZ1ouQNL7u6snGAa-RDS3yJAp8Jsztt8wUdYSRFk=.7c2f6a72-f70c-4e7c-8442-8f667986eff8@github.com> 8276042: Remove unused local variables in java.naming ------------- Commit messages: - [PATCH] Remove unused local variable in java.naming Changes: https://git.openjdk.java.net/jdk/pull/6091/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6091&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276042 Stats: 10 lines in 5 files changed: 0 ins; 5 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/6091.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6091/head:pull/6091 PR: https://git.openjdk.java.net/jdk/pull/6091 From myano at openjdk.java.net Wed Oct 27 08:58:10 2021 From: myano at openjdk.java.net (Masanori Yano) Date: Wed, 27 Oct 2021 08:58:10 GMT Subject: RFR: 8250678: ModuleDescriptor.Version parsing treats empty segments inconsistently In-Reply-To: References: <5FwhmsS85upnfXAKPCBCQTsWorJN17vOBFZXCN6iP8M=.377740a1-6f1e-4e37-9344-25a60ffdd891@github.com> Message-ID: <_YWc7pJMgLoHWb8cby4plj2XwXz_cL1OfWjoJAlQV5M=.532e6cde-dd9c-4352-b9a6-21b1af0dce8e@github.com> On Wed, 6 Oct 2021 18:40:36 GMT, Mark Reinhold wrote: >> @mbreinhold Could you comment on this pull request? > >> @mbreinhold Could you comment on this pull request? > > This is somewhat tricky code. I?ll take a look, but give me a few days. @mbreinhold @AlanBateman Could you please reply to the above comments? ------------- PR: https://git.openjdk.java.net/jdk/pull/5679 From alanb at openjdk.java.net Wed Oct 27 09:54:09 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 27 Oct 2021 09:54:09 GMT Subject: RFR: JDK-8275703: System.loadLibrary fails on Big Sur for libraries hidden from filesystem In-Reply-To: <1d0vB2i2qrGaWRxtX_FqnYWrKcgXHaPvShDeSSG9cXg=.f733da58-3eaf-4eda-8c93-f8e81a384326@github.com> References: <1d0vB2i2qrGaWRxtX_FqnYWrKcgXHaPvShDeSSG9cXg=.f733da58-3eaf-4eda-8c93-f8e81a384326@github.com> Message-ID: <7H9sfqoYxuFgFvRWHuB8yDkJmsTgPg2XTBLnAb3Xt_s=.5f584e17-d492-414c-ba47-d4d1ca583291@github.com> On Tue, 26 Oct 2021 22:51:29 GMT, Mandy Chung wrote: > On, macOS 11.x, system libraries are loaded from dynamic linker cache. The libraries are no longer present on the filesystem. `NativeLibraries::loadLibrary` checks for the file existence before calling `JVM_LoadLibrary`. Such check no longer applies on Big Sur. This proposes that on macOS >= 11, it will skip the file existence check and attempt to load a library for each path from java.library.path and system library path. The change is unfortunate but looks okay. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6127 From redestad at openjdk.java.net Wed Oct 27 10:11:16 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 27 Oct 2021 10:11:16 GMT Subject: RFR: 8275863: Use encodeASCII for ASCII-compatible DoubleByte encodings In-Reply-To: References: Message-ID: On Mon, 25 Oct 2021 10:16:23 GMT, Claes Redestad wrote: > Enhance ASCII-compatible `DoubleByte` encodings to make use of the `StringCoding.implEncodeAsciiArray` intrinsic, which makes many such `CharsetEncoder`s encode ASCII text at speeds comparable to most single-byte encoders - and also more in line with how well these charsets behave when calling `String.getBytes`: > > Before: > > Benchmark (size) (type) Mode Cnt Score Error Units > CharsetEncodeDecode.encode 16384 ISO-8859-1 avgt 30 3.021 ? 0.120 us/op > CharsetEncodeDecode.encode 16384 Shift-JIS avgt 30 47.793 ? 1.942 us/op > CharsetEncodeDecode.encode 16384 GB2312 avgt 30 49.598 ? 2.006 us/op > CharsetEncodeDecode.encode 16384 EUC-JP avgt 30 68.709 ? 5.019 us/op > CharsetEncodeDecode.encode 16384 EUC-KR avgt 30 48.033 ? 1.651 us/op > > > Patched: > > Benchmark (size) (type) Mode Cnt Score Error Units > CharsetEncodeDecode.encode 16384 ISO-8859-1 avgt 30 2.856 ? 0.078 us/op > CharsetEncodeDecode.encode 16384 Shift-JIS avgt 30 5.287 ? 0.209 us/op > CharsetEncodeDecode.encode 16384 GB2312 avgt 30 5.490 ? 0.251 us/op > CharsetEncodeDecode.encode 16384 EUC-JP avgt 30 7.657 ? 0.368 us/op > CharsetEncodeDecode.encode 16384 EUC-KR avgt 30 5.718 ? 0.267 us/op > > > The `isASCIICompatible` predicate on `DoubleByte` was added in JEP 254 for the purpose of implementing such ASCII fast-paths, but is only used in what is now `String.encodeWithEncoder` to speed up `String.getBytes(...)` operations. > > Testing: tier1-3 Thanks for reviewing! ------------- PR: https://git.openjdk.java.net/jdk/pull/6102 From redestad at openjdk.java.net Wed Oct 27 10:11:16 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 27 Oct 2021 10:11:16 GMT Subject: Integrated: 8275863: Use encodeASCII for ASCII-compatible DoubleByte encodings In-Reply-To: References: Message-ID: On Mon, 25 Oct 2021 10:16:23 GMT, Claes Redestad wrote: > Enhance ASCII-compatible `DoubleByte` encodings to make use of the `StringCoding.implEncodeAsciiArray` intrinsic, which makes many such `CharsetEncoder`s encode ASCII text at speeds comparable to most single-byte encoders - and also more in line with how well these charsets behave when calling `String.getBytes`: > > Before: > > Benchmark (size) (type) Mode Cnt Score Error Units > CharsetEncodeDecode.encode 16384 ISO-8859-1 avgt 30 3.021 ? 0.120 us/op > CharsetEncodeDecode.encode 16384 Shift-JIS avgt 30 47.793 ? 1.942 us/op > CharsetEncodeDecode.encode 16384 GB2312 avgt 30 49.598 ? 2.006 us/op > CharsetEncodeDecode.encode 16384 EUC-JP avgt 30 68.709 ? 5.019 us/op > CharsetEncodeDecode.encode 16384 EUC-KR avgt 30 48.033 ? 1.651 us/op > > > Patched: > > Benchmark (size) (type) Mode Cnt Score Error Units > CharsetEncodeDecode.encode 16384 ISO-8859-1 avgt 30 2.856 ? 0.078 us/op > CharsetEncodeDecode.encode 16384 Shift-JIS avgt 30 5.287 ? 0.209 us/op > CharsetEncodeDecode.encode 16384 GB2312 avgt 30 5.490 ? 0.251 us/op > CharsetEncodeDecode.encode 16384 EUC-JP avgt 30 7.657 ? 0.368 us/op > CharsetEncodeDecode.encode 16384 EUC-KR avgt 30 5.718 ? 0.267 us/op > > > The `isASCIICompatible` predicate on `DoubleByte` was added in JEP 254 for the purpose of implementing such ASCII fast-paths, but is only used in what is now `String.encodeWithEncoder` to speed up `String.getBytes(...)` operations. > > Testing: tier1-3 This pull request has now been integrated. Changeset: 6c05cc9d Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/6c05cc9d15fb6014b8293a66ef132f3461badca1 Stats: 35 lines in 5 files changed: 24 ins; 4 del; 7 mod 8275863: Use encodeASCII for ASCII-compatible DoubleByte encodings Reviewed-by: naoto, rriggs, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/6102 From aefimov at openjdk.java.net Wed Oct 27 11:43:14 2021 From: aefimov at openjdk.java.net (Aleksei Efimov) Date: Wed, 27 Oct 2021 11:43:14 GMT Subject: RFR: 8276042: Remove unused local variables in java.naming In-Reply-To: <4G5GZ1ouQNL7u6snGAa-RDS3yJAp8Jsztt8wUdYSRFk=.7c2f6a72-f70c-4e7c-8442-8f667986eff8@github.com> References: <4G5GZ1ouQNL7u6snGAa-RDS3yJAp8Jsztt8wUdYSRFk=.7c2f6a72-f70c-4e7c-8442-8f667986eff8@github.com> Message-ID: On Sat, 23 Oct 2021 12:51:15 GMT, Andrey Turbanov wrote: > 8276042: Remove unused local variables in java.naming Hi Andrey, Thanks for cleaning up the code. Changes look good to me, with one suggestion below. src/java.naming/share/classes/com/sun/jndi/toolkit/ctx/PartialCompositeContext.java line 514: > 512: Object obj = cont.getResolvedObj(); > 513: > 514: if (obj instanceof PartialCompositeContext) { Since we're changing this method, maybe `instanceof` pattern matching can be used here to remove casting below. ------------- Marked as reviewed by aefimov (Committer). PR: https://git.openjdk.java.net/jdk/pull/6091 From naoto at openjdk.java.net Wed Oct 27 12:43:22 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 27 Oct 2021 12:43:22 GMT Subject: Integrated: 8270490: Charset.forName() taking fallback default value In-Reply-To: References: Message-ID: <-gFztgSCXQOYd4c0MrhisA2hISZu8KuhLShRNLff3As=.29e9193f-108b-4c7a-bd91-8feebcb53d15@github.com> On Wed, 20 Oct 2021 17:23:36 GMT, Naoto Sato wrote: > During the review of JEP 400, a proposal to provide an overloaded method to `Charset.forName()` was suggested [[1]](https://github.com/openjdk/jdk/pull/4733#discussion_r669693954). This PR is to implement the proposal. A CSR is also drafted as https://bugs.openjdk.java.net/browse/JDK-8275348 This pull request has now been integrated. Changeset: 168081ef Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/168081efc8af1f5d1d7524246eb4a0675bd49ae0 Stats: 114 lines in 3 files changed: 106 ins; 5 del; 3 mod 8270490: Charset.forName() taking fallback default value Reviewed-by: joehw, rriggs, serb, dfuchs ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From alanb at openjdk.java.net Wed Oct 27 14:11:15 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 27 Oct 2021 14:11:15 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v15] In-Reply-To: References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> Message-ID: On Tue, 26 Oct 2021 16:35:34 GMT, Mandy Chung wrote: >> This reimplements core reflection with method handles. >> >> For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. >> >> The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. >> >> The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. >> >> Ran tier1-tier8 tests. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8013527 >> [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 > > Mandy Chung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 40 commits: > > - Fall back to the VM native reflection support if method handle cannot be created > - fix bug id in test > - Merge > - Merge branch 'master' of https://github.com/openjdk/jdk into reimplement-method-invoke > - Merge branch 'master' of https://github.com/openjdk/jdk into reimplement-method-invoke > - Separate paramFlgas into paramCount and flags fields > - Minor cleanup. Improve javadoc in CallerSensitiveAdapter > - Fix left-over assignment > - Remove duplicated microbenchmarks > - Avoid pitfall with unwanted inlining in some cases. Also remove boxing/unboxing to focus on the invocation cost > - ... and 30 more: https://git.openjdk.java.net/jdk/compare/97d3280e...64738bb2 src/java.base/share/classes/jdk/internal/reflect/AccessorUtils.java line 34: > 32: */ > 33: public class AccessorUtils { > 34: static boolean isIllegalArgument(Class accessorType, RuntimeException e) { It might be useful to add a method description. In isolation, it's not immediately clear what it does. ------------- PR: https://git.openjdk.java.net/jdk/pull/5027 From shade at openjdk.java.net Wed Oct 27 14:46:21 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 27 Oct 2021 14:46:21 GMT Subject: RFR: 8252990: Intrinsify Unsafe.storeStoreFence Message-ID: `Unsafe.storeStoreFence` currently delegates to stronger `Unsafe.storeFence`. We can teach compilers to map this directly to already existing rules that handle `MemBarStoreStore`. Like explicit `LoadFence`/`StoreFence`, we introduce the special node to differentiate explicit fence and implicit store-store barriers. This node is usually used to simulate safe `final`-field like constructions in special JDK classes, like `ConstantCallSite` and friends. Motivational performance difference on benchmarks from JDK-8276054 on ARM32: Benchmark Mode Cnt Score Error Units Multiple.plain avgt 3 2.669 ? 0.004 ns/op Multiple.release avgt 3 16.688 ? 0.057 ns/op Multiple.storeStore avgt 3 14.021 ? 0.144 ns/op // Better MultipleWithLoads.plain avgt 3 4.672 ? 0.053 ns/op MultipleWithLoads.release avgt 3 16.689 ? 0.044 ns/op MultipleWithLoads.storeStore avgt 3 14.012 ? 0.010 ns/op // Better MultipleWithStores.plain avgt 3 14.687 ? 0.009 ns/op MultipleWithStores.release avgt 3 45.393 ? 0.192 ns/op MultipleWithStores.storeStore avgt 3 38.048 ? 0.033 ns/op // Better Publishing.plain avgt 3 27.079 ? 0.201 ns/op Publishing.release avgt 3 27.088 ? 0.241 ns/op Publishing.storeStore avgt 3 27.009 ? 0.259 ns/op // Within error, hidden by allocation Single.plain avgt 3 2.670 ? 0.002 ns/op Single.releaseFence avgt 3 6.675 ? 0.001 ns/op Single.storeStoreFence avgt 3 8.012 ? 0.027 ns/op // Worse, seems to be ARM32 implementation artifact As expected, this does not affect x86_64 at all, because both `release` and `storeStore` are effectively no-ops, only affecting compiler optimizations: Benchmark Mode Cnt Score Error Units Multiple.plain avgt 3 0.406 ? 0.002 ns/op Multiple.release avgt 3 0.409 ? 0.018 ns/op Multiple.storeStore avgt 3 0.406 ? 0.001 ns/op MultipleWithLoads.plain avgt 3 4.328 ? 0.006 ns/op MultipleWithLoads.release avgt 3 4.600 ? 0.014 ns/op MultipleWithLoads.storeStore avgt 3 4.602 ? 0.006 ns/op MultipleWithStores.plain avgt 3 0.812 ? 0.001 ns/op MultipleWithStores.release avgt 3 0.812 ? 0.002 ns/op MultipleWithStores.storeStore avgt 3 0.812 ? 0.002 ns/op Publishing.plain avgt 3 6.370 ? 0.059 ns/op Publishing.release avgt 3 6.358 ? 0.436 ns/op Publishing.storeStore avgt 3 6.367 ? 0.054 ns/op Single.plain avgt 3 0.407 ? 0.039 ns/op Single.releaseFence avgt 3 0.406 ? 0.001 ns/op Single.storeStoreFence avgt 3 0.406 ? 0.001 ns/op Additional testing: - [x] Linux x86_64 fastdebug `tier1` ------------- Commit messages: - Formatting - Little cleanup - 8252990: Intrinsify Unsafe.storeStoreFence Changes: https://git.openjdk.java.net/jdk/pull/6136/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6136&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252990 Stats: 39 lines in 16 files changed: 33 ins; 5 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6136.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6136/head:pull/6136 PR: https://git.openjdk.java.net/jdk/pull/6136 From duke at openjdk.java.net Wed Oct 27 15:42:32 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Wed, 27 Oct 2021 15:42:32 GMT Subject: RFR: 8276042: Remove unused local variables in java.naming [v2] In-Reply-To: <4G5GZ1ouQNL7u6snGAa-RDS3yJAp8Jsztt8wUdYSRFk=.7c2f6a72-f70c-4e7c-8442-8f667986eff8@github.com> References: <4G5GZ1ouQNL7u6snGAa-RDS3yJAp8Jsztt8wUdYSRFk=.7c2f6a72-f70c-4e7c-8442-8f667986eff8@github.com> Message-ID: > 8276042: Remove unused local variables in java.naming Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8276042: Remove unused local variables in java.naming use instanceof pattern ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6091/files - new: https://git.openjdk.java.net/jdk/pull/6091/files/58bfec0d..f697d88c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6091&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6091&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/6091.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6091/head:pull/6091 PR: https://git.openjdk.java.net/jdk/pull/6091 From duke at openjdk.java.net Wed Oct 27 15:42:33 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Wed, 27 Oct 2021 15:42:33 GMT Subject: RFR: 8276042: Remove unused local variables in java.naming [v2] In-Reply-To: References: <4G5GZ1ouQNL7u6snGAa-RDS3yJAp8Jsztt8wUdYSRFk=.7c2f6a72-f70c-4e7c-8442-8f667986eff8@github.com> Message-ID: On Wed, 27 Oct 2021 11:08:31 GMT, Aleksei Efimov wrote: >> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8276042: Remove unused local variables in java.naming >> use instanceof pattern > > src/java.naming/share/classes/com/sun/jndi/toolkit/ctx/PartialCompositeContext.java line 514: > >> 512: Object obj = cont.getResolvedObj(); >> 513: >> 514: if (obj instanceof PartialCompositeContext) { > > Since we're changing this method, maybe `instanceof` pattern matching can be used here to remove casting below. done ------------- PR: https://git.openjdk.java.net/jdk/pull/6091 From aefimov at openjdk.java.net Wed Oct 27 15:46:23 2021 From: aefimov at openjdk.java.net (Aleksei Efimov) Date: Wed, 27 Oct 2021 15:46:23 GMT Subject: RFR: 8276042: Remove unused local variables in java.naming [v2] In-Reply-To: References: <4G5GZ1ouQNL7u6snGAa-RDS3yJAp8Jsztt8wUdYSRFk=.7c2f6a72-f70c-4e7c-8442-8f667986eff8@github.com> Message-ID: <3hgODKoCXphnzvtdWoqCXueU9oIBGh7K5ExPCl4capQ=.f895bd63-9b09-4735-a631-0eee2433178c@github.com> On Wed, 27 Oct 2021 15:42:32 GMT, Andrey Turbanov wrote: >> 8276042: Remove unused local variables in java.naming > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8276042: Remove unused local variables in java.naming > use instanceof pattern Marked as reviewed by aefimov (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6091 From dfuchs at openjdk.java.net Wed Oct 27 15:52:09 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 27 Oct 2021 15:52:09 GMT Subject: RFR: 8276042: Remove unused local variables in java.naming [v2] In-Reply-To: References: <4G5GZ1ouQNL7u6snGAa-RDS3yJAp8Jsztt8wUdYSRFk=.7c2f6a72-f70c-4e7c-8442-8f667986eff8@github.com> Message-ID: On Wed, 27 Oct 2021 15:42:32 GMT, Andrey Turbanov wrote: >> 8276042: Remove unused local variables in java.naming > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8276042: Remove unused local variables in java.naming > use instanceof pattern Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6091 From mchung at openjdk.java.net Wed Oct 27 16:12:20 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 27 Oct 2021 16:12:20 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v15] In-Reply-To: References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> Message-ID: On Wed, 27 Oct 2021 14:08:05 GMT, Alan Bateman wrote: >> Mandy Chung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 40 commits: >> >> - Fall back to the VM native reflection support if method handle cannot be created >> - fix bug id in test >> - Merge >> - Merge branch 'master' of https://github.com/openjdk/jdk into reimplement-method-invoke >> - Merge branch 'master' of https://github.com/openjdk/jdk into reimplement-method-invoke >> - Separate paramFlgas into paramCount and flags fields >> - Minor cleanup. Improve javadoc in CallerSensitiveAdapter >> - Fix left-over assignment >> - Remove duplicated microbenchmarks >> - Avoid pitfall with unwanted inlining in some cases. Also remove boxing/unboxing to focus on the invocation cost >> - ... and 30 more: https://git.openjdk.java.net/jdk/compare/97d3280e...64738bb2 > > src/java.base/share/classes/jdk/internal/reflect/AccessorUtils.java line 34: > >> 32: */ >> 33: public class AccessorUtils { >> 34: static boolean isIllegalArgument(Class accessorType, RuntimeException e) { > > It might be useful to add a method description. In isolation, it's not immediately clear what it does. I agree that'd be helpful. I'll add the javadoc. ------------- PR: https://git.openjdk.java.net/jdk/pull/5027 From mchung at openjdk.java.net Wed Oct 27 16:16:14 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 27 Oct 2021 16:16:14 GMT Subject: RFR: JDK-8275703: System.loadLibrary fails on Big Sur for libraries hidden from filesystem In-Reply-To: <5BAH1dAVPdl7UnZRnSpe_7xOaX8Whsu_E0drRbcia-0=.449e99a7-ac53-4ffa-929b-b3ddc21c2f31@github.com> References: <1d0vB2i2qrGaWRxtX_FqnYWrKcgXHaPvShDeSSG9cXg=.f733da58-3eaf-4eda-8c93-f8e81a384326@github.com> <5BAH1dAVPdl7UnZRnSpe_7xOaX8Whsu_E0drRbcia-0=.449e99a7-ac53-4ffa-929b-b3ddc21c2f31@github.com> Message-ID: On Wed, 27 Oct 2021 03:39:39 GMT, Jaikiran Pai wrote: > So, I think, the whole point of this change in this block is to skip the file existence check and return back a file path. exactly. ------------- PR: https://git.openjdk.java.net/jdk/pull/6127 From duke at openjdk.java.net Wed Oct 27 16:21:20 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Wed, 27 Oct 2021 16:21:20 GMT Subject: Integrated: 8274879: Replace uses of StringBuffer with StringBuilder within java.base classes In-Reply-To: References: Message-ID: <9BGa0d9dkCjuAJV2PJrCCMDAMGjW6WSkDGeuWSn3Xh8=.6eacd128-16e4-4d80-a9a4-310e9107f6af@github.com> On Thu, 9 Sep 2021 06:50:21 GMT, Andrey Turbanov wrote: > StringBuffer is a legacy synchronized class. There are more modern alternatives which perform better: > 1. Plain String concatenation should be preferred > 2. StringBuilder is a direct replacement to StringBuffer which generally have better performance > > In [JDK-8264029](https://bugs.openjdk.java.net/browse/JDK-8264029) I migrated only usages which were automatically detected by IDEA. It turns out there are more usages which can be migrated. This pull request has now been integrated. Changeset: 9a3e9542 Author: Andrey Turbanov Committer: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/9a3e9542997860de79d07a4411b1007e9cd5c348 Stats: 31 lines in 11 files changed: 0 ins; 0 del; 31 mod 8274879: Replace uses of StringBuffer with StringBuilder within java.base classes Reviewed-by: naoto ------------- PR: https://git.openjdk.java.net/jdk/pull/5432 From mchung at openjdk.java.net Wed Oct 27 16:28:16 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 27 Oct 2021 16:28:16 GMT Subject: RFR: JDK-8275703: System.loadLibrary fails on Big Sur for libraries hidden from filesystem In-Reply-To: References: <1d0vB2i2qrGaWRxtX_FqnYWrKcgXHaPvShDeSSG9cXg=.f733da58-3eaf-4eda-8c93-f8e81a384326@github.com> Message-ID: On Wed, 27 Oct 2021 02:51:24 GMT, Jaikiran Pai wrote: >> On, macOS 11.x, system libraries are loaded from dynamic linker cache. The libraries are no longer present on the filesystem. `NativeLibraries::loadLibrary` checks for the file existence before calling `JVM_LoadLibrary`. Such check no longer applies on Big Sur. This proposes that on macOS >= 11, it will skip the file existence check and attempt to load a library for each path from java.library.path and system library path. > > src/java.base/macosx/classes/jdk/internal/loader/ClassLoaderHelper.java line 44: > >> 42: } catch (NumberFormatException e) {} >> 43: } >> 44: hasDynamicLoaderCache = major >= 11; > > Hello Mandy, > I'm not too familiar with MacOS versioning schemes. However, in this specific logic, if the `os.version` value doesn't contain a dot character, then the `major` is initialized to `11`, which would then evaluate this `hasDynamicLoaderCache` to `true`. That would mean if the `os.version` is (for example) `10`, then `hasDynamicLoaderCache` will be incorrectly set to `true` here, isn't it? macOS product version contains 3 parts: major, minor, and patch version. But it does not hurt to handle the case where no dot exists in the string. int major = 11; int i = osVersion.indexOf('.'); try { major = Integer.parseInt(i < 0 ? osVersion : osVersion.substring(0, i)); } catch (NumberFormatException e) {} ------------- PR: https://git.openjdk.java.net/jdk/pull/6127 From michaelm at openjdk.java.net Wed Oct 27 17:23:17 2021 From: michaelm at openjdk.java.net (Michael McMahon) Date: Wed, 27 Oct 2021 17:23:17 GMT Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v9] In-Reply-To: References: Message-ID: On Tue, 26 Oct 2021 16:24:48 GMT, Aleksei Efimov wrote: >> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver. >> >> The following API classes are added to `java.net.spi` package to facilitate this: >> - `InetAddressResolverProvider` - abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers. >> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations. >> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations. >> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation. >> >> More details in [JEP-418](https://openjdk.java.net/jeps/418). >> >> Testing: new and existing `tier1:tier3` tests > > Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision: > > Add @ throws NPE to hosts file resolver javadoc src/java.base/share/classes/java/net/InetAddress.java line 841: > 839: // 'resolver.lookupByAddress' and 'InetAddress.getAllByName0' delegate to the system-wide resolver, > 840: // which could be a custom one. At that point we treat any unexpected RuntimeException thrown by > 841: // the resolver as we would treat an UnknownHostException or an unmatched host name. indentation issue in comment above src/java.base/share/classes/java/net/InetAddress.java line 1308: > 1306: * Creates an InetAddress based on the provided host name and IP address. > 1307: * System {@linkplain InetAddressResolver resolver} is not used to check > 1308: * the validity of the address. Is this term "system resolver" defined somewhere? I think it means the configured resolver for the current VM. Previously, it really was the system resolver. So, I think it's potentially confusing, as there is also reference to the java.net.preferIPv6Addresses system property as having a possible value "system" which refers to the operating system. Since the CSR is approved, I'm happy to discuss this point post integration. ------------- PR: https://git.openjdk.java.net/jdk/pull/5822 From mchung at openjdk.java.net Wed Oct 27 17:27:41 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 27 Oct 2021 17:27:41 GMT Subject: RFR: JDK-8275703: System.loadLibrary fails on Big Sur for libraries hidden from filesystem [v2] In-Reply-To: <1d0vB2i2qrGaWRxtX_FqnYWrKcgXHaPvShDeSSG9cXg=.f733da58-3eaf-4eda-8c93-f8e81a384326@github.com> References: <1d0vB2i2qrGaWRxtX_FqnYWrKcgXHaPvShDeSSG9cXg=.f733da58-3eaf-4eda-8c93-f8e81a384326@github.com> Message-ID: > On, macOS 11.x, system libraries are loaded from dynamic linker cache. The libraries are no longer present on the filesystem. `NativeLibraries::loadLibrary` checks for the file existence before calling `JVM_LoadLibrary`. Such check no longer applies on Big Sur. This proposes that on macOS >= 11, it will skip the file existence check and attempt to load a library for each path from java.library.path and system library path. Mandy Chung has updated the pull request incrementally with two additional commits since the last revision: - Adjust parsing os.version to handle no dot version in case it's allowed - Exclude building exeLibraryCache.c on other platforms except macOS ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6127/files - new: https://git.openjdk.java.net/jdk/pull/6127/files/e034029f..710925b5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6127&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6127&range=00-01 Stats: 12 lines in 5 files changed: 2 ins; 3 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/6127.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6127/head:pull/6127 PR: https://git.openjdk.java.net/jdk/pull/6127 From javalists at cbfiddle.com Wed Oct 27 18:24:13 2021 From: javalists at cbfiddle.com (Alan Snyder) Date: Wed, 27 Oct 2021 11:24:13 -0700 Subject: RFR: JDK-8275703: System.loadLibrary fails on Big Sur for libraries hidden from filesystem In-Reply-To: References: <1d0vB2i2qrGaWRxtX_FqnYWrKcgXHaPvShDeSSG9cXg=.f733da58-3eaf-4eda-8c93-f8e81a384326@github.com> Message-ID: <0FE666F4-659B-4B1E-A4B9-B3FC658B5FD8@cbfiddle.com> > On Oct 27, 2021, at 9:28 AM, Mandy Chung wrote: > >>> On, macOS 11.x, system libraries are loaded from dynamic linker cache. The libraries are no longer present on the filesystem. `NativeLibraries::loadLibrary` checks for the file existence before calling `JVM_LoadLibrary`. Such check no longer applies on Big Sur. This proposes that on macOS >= 11, it will skip the file existence check and attempt to load a library for each path from java.library.path and system library path. > I?m curious about this issue. I never load system libraries directly. I load my own libraries (that support JNI entry points) and the system loader loads the necessary system frameworks that they were linked against. What?s different in this case that motivates loading system libraries directly from Java? Alan From mcimadamore at openjdk.java.net Wed Oct 27 18:32:08 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 27 Oct 2021 18:32:08 GMT Subject: RFR: JDK-8275703: System.loadLibrary fails on Big Sur for libraries hidden from filesystem [v2] In-Reply-To: References: <1d0vB2i2qrGaWRxtX_FqnYWrKcgXHaPvShDeSSG9cXg=.f733da58-3eaf-4eda-8c93-f8e81a384326@github.com> Message-ID: On Wed, 27 Oct 2021 17:27:41 GMT, Mandy Chung wrote: >> On, macOS 11.x, system libraries are loaded from dynamic linker cache. The libraries are no longer present on the filesystem. `NativeLibraries::loadLibrary` checks for the file existence before calling `JVM_LoadLibrary`. Such check no longer applies on Big Sur. This proposes that on macOS >= 11, it will skip the file existence check and attempt to load a library for each path from java.library.path and system library path. > > Mandy Chung has updated the pull request incrementally with two additional commits since the last revision: > > - Adjust parsing os.version to handle no dot version in case it's allowed > - Exclude building exeLibraryCache.c on other platforms except macOS This came up on panama-dev a bunch of time now. In fact, in the panama use case this would make sense for other systems as well. For instance on linux systems, there's a bunch of known library names in gnu/lib-names.h which programs can depend on, but for which System::load/loadLibrary cannot be used - as they are neither library names, nor paths - for instance "libm.so.6". ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6127 From mchung at openjdk.java.net Wed Oct 27 19:05:12 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 27 Oct 2021 19:05:12 GMT Subject: RFR: JDK-8275703: System.loadLibrary fails on Big Sur for libraries hidden from filesystem In-Reply-To: <0FE666F4-659B-4B1E-A4B9-B3FC658B5FD8@cbfiddle.com> References: <1d0vB2i2qrGaWRxtX_FqnYWrKcgXHaPvShDeSSG9cXg=.f733da58-3eaf-4eda-8c93-f8e81a384326@github.com> <0FE666F4-659B-4B1E-A4B9-B3FC658B5FD8@cbfiddle.com> Message-ID: On Wed, 27 Oct 2021 18:25:40 GMT, Alan Snyder wrote: > I never load system libraries directly. I load my own libraries (that support JNI entry points) and the system loader loads the necessary system frameworks that they were linked against. > > What's different in this case that motivates loading system libraries directly from Java Panama would be the right place to provide the support of loading system libraries directly from Java and enhance the interconnection between JVM and native code. The bug report is an example showing that developers want to load a system library for their native code to use. It's not surprise that they use `System::load/loadLibrary` even it's designed for JNI without Panama since it works. So this patch is for compatibility for existing applications to continue to run on Big Sur. ------------- PR: https://git.openjdk.java.net/jdk/pull/6127 From duke at openjdk.java.net Wed Oct 27 19:35:38 2021 From: duke at openjdk.java.net (Raffaello Giulietti) Date: Wed, 27 Oct 2021 19:35:38 GMT Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v4] In-Reply-To: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com> References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com> Message-ID: > Hello, > > here's a PR for a patch submitted on March 2020 [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a thing. > > The patch has been edited to adhere to OpenJDK code conventions about multi-line (block) comments. Nothing in the code proper has changed, except for the addition of redundant but clarifying parentheses in some expressions. > > > Greetings > Raffaello Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: - 4511638: Double.toString(double) sometimes produces incorrect results Merge branch 'master' into JDK-4511638 - 4511638: Double.toString(double) sometimes produces incorrect results Slight adjustments to Javadoc as suggested in the JDK-8202555 (CSR) comments. - 4511638: Double.toString(double) sometimes produces incorrect results Adjusted hashes in test/langtools/tools/javac/sym/ElementStructureTest.java - 4511638: Double.toString(double) sometimes produces incorrect results Merge branch 'master' into JDK-4511638 - 4511638: Double.toString(double) sometimes produces incorrect results - 4511638: Double.toString(double) sometimes produces incorrect results Refactored test classes to better match OpenJDK conventions. Added tests recommended by Guy Steele and Paul Zimmermann. - Changed MAX_CHARS to static - 4511638: Double.toString(double) sometimes produces incorrect results - 4511638: Double.toString(double) sometimes produces incorrect results ------------- Changes: https://git.openjdk.java.net/jdk/pull/3402/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3402&range=03 Stats: 23945 lines in 16 files changed: 23809 ins; 61 del; 75 mod Patch: https://git.openjdk.java.net/jdk/pull/3402.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3402/head:pull/3402 PR: https://git.openjdk.java.net/jdk/pull/3402 From lancea at openjdk.java.net Wed Oct 27 19:36:37 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 27 Oct 2021 19:36:37 GMT Subject: RFR: 8153490: Cannot setBytes() if incoming buffer's length is bigger than number of elements we want to insert. [v6] In-Reply-To: References: Message-ID: On Sun, 24 Oct 2021 07:55:01 GMT, Mitsuru Kariya wrote: >> Fix `SerialBlob.setBytes(long pos, byte[] bytes, int offset, int length)` in the following cases: >> >> 1. `pos - 1 + bytes.length - offset > this.length() && pos - 1 + length <= this.length()` >> The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully. >> (test31) >> >> 2. `pos - 1 + length > this.length()` >> The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully. *1 >> (test32) >> >> 3. `pos == this.length() + 1` >> The original implementation throws `SerialException` but this case should end successfully. *2 >> (test33) >> >> 4. `length < 0` >> The original implementation throws `ArrayIndexOutOfBoundsException` but this case should throw `SerialException`. >> (test34) >> >> 5. `offset + length > Integer.MAX_VALUE` >> The original implementation throws `ArrayIndexOutOfBoundsException` (or `OutOfMemoryError` in most cases) but this case should throw `SerialException`. >> (test35) >> >> Additionally, fix `SerialClob.setString(long pos, String str, int offset, int length)` in the following cases: >> >> 1. `offset > str.length()` >> The original implementaion throws `StringIndexOutOfBoundsException` but this case should throw `SerialException`. >> (test39) >> >> 2. `pos - 1 + str.length() - offset > this.length() && pos - 1 + length <= this.length()` >> The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully. >> (test32) >> >> 3. `pos - 1 + length > this.length()` >> The original implementaion throws `SerialException` but this case should end successfully. *3 >> (test40) >> >> 4. `pos == this.length() + 1` >> The original implementaion throws `SerialException` but this case should end successfully. *4 >> (test41) >> >> 5. `length < 0` >> The original implementation throws `StringIndexOutOfBoundsException` but this case should throw `SerialException`. >> (test42) >> >> 6. `offset + length > Integer.MAX_VALUE` >> The original implementation throws `ArrayIndexOutOfBoundsException` (or `OutOfMemoryError` in most cases) but this case should throw `SerialException`. >> (test43) >> >> >> The javadoc has also been modified according to the above. >> >> *1 The documentation of `Blob.setBytes()` says, "If the end of the Blob value is reached while writing the array of bytes, then the length of the Blob value will be increased to accommodate the extra bytes." >> >> *2 The documentation of `Blob.setBytes()` says, "If the value specified for pos is greater than the length+1 of the BLOB value then the behavior is undefined." >> So, it should work correctly when pos == length+1 of the BLOB value. >> >> *3 The documentation of `Clob.setString()` says, "If the end of the Clob value is eached while writing the given string, then the length of the Clob value will be increased to accommodate the extra characters." >> >> *4 The documentation of `Clob.setString()` says, "If the value specified for pos is greater than the length+1 of the CLOB value then the behavior is undefined." >> So, it should work correctly when pos == length+1 of the CLOB value. > > Mitsuru Kariya has updated the pull request 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 JDK-8153490 > - Follow the comment > - Modify javadoc for consistency > - Fix for length + offset > Integer.MAX_VALUE case > - Add check: ensure length >= 0 > - 8153490:Cannot setBytes() if incoming buffer's length is bigger than number of elements we want to insert. > > Fix SerialBlob.setBytes(long pos, byte[] bytes, int offset, int length) in the > following cases: > > 1. pos - 1 + bytes.length - offset > this.length() && pos - 1 + length <= this.length() > The original implementation throws ArrayIndexOutOfBoundsException but this case > should end successfully. > (test31) > > 2. pos - 1 + length > this.length() > The original implementation throws ArrayIndexOutOfBoundsException but this case > should end successfully. *1 > (test32) > > 3. pos == this.length() + 1 > The original implementation throws SerialException but this case should end > successfully. *2 > (test33) > > Additionally, fix SerialClob.setString(long pos, String str, int offset, int length) > in the following cases: > > 1. offset > str.length() > The original implementaion throws StringIndexOutOfBoundsException but this case > should throw SerialException. > (test39) > > 2. pos - 1 + str.length() - offset > this.length() && pos - 1 + length <= this.length() > The original implementation throws ArrayIndexOutOfBoundsException but this case > should end successfully. > (test32) > > 3. pos - 1 + length > this.length() > The original implementaion throws SerialException but this case should end > successfully. *3 > (test40) > > 4. pos == this.length() + 1 > The original implementaion throws SerialException but this case should end > successfully. *4 > (test41) > > The javadoc has also been modified according to the above. > > *1 The documentation of Blob.setBytes() says, "If the end of the Blob value is > reached while writing the array of bytes, then the length of the Blob value > will be increased to accommodate the extra bytes." > > *2 The documentation of Blob.setBytes() says, "If the value specified for pos > is greater than the length+1 of the BLOB value then the behavior is > undefined." > So, it should work correctly when pos == length+1 of the BLOB value. > > *3 The documentation of Clob.setString() says, "If the end of the Clob value is > reached while writing the given string, then the length of the Clob value > will be increased to accommodate the extra characters." > > *4 The documentation of Clob.setString() says, "If the value specified for pos > is greater than the length+1 of the CLOB value then the behavior is > undefined." > So, it should work correctly when pos == length+1 of the CLOB value. Mach5 tiers 1-3 are clean so you should be OK to integrate your fix ------------- PR: https://git.openjdk.java.net/jdk/pull/4001 From mchung at openjdk.java.net Wed Oct 27 20:16:54 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 27 Oct 2021 20:16:54 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v16] In-Reply-To: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> Message-ID: > This reimplements core reflection with method handles. > > For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. > > The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. > > The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. > > Ran tier1-tier8 tests. > > [1] https://bugs.openjdk.java.net/browse/JDK-8013527 > [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 Mandy Chung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 43 commits: - fix copyright header and typo - improve documentation of AccessorUtils - Merge branch 'master' of https://github.com/openjdk/jdk into reimplement-method-invoke - Fall back to the VM native reflection support if method handle cannot be created - fix bug id in test - Merge - Merge branch 'master' of https://github.com/openjdk/jdk into reimplement-method-invoke - Merge branch 'master' of https://github.com/openjdk/jdk into reimplement-method-invoke - Separate paramFlgas into paramCount and flags fields - Minor cleanup. Improve javadoc in CallerSensitiveAdapter - ... and 33 more: https://git.openjdk.java.net/jdk/compare/9a3e9542...46cb306b ------------- Changes: https://git.openjdk.java.net/jdk/pull/5027/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5027&range=15 Stats: 6436 lines in 78 files changed: 5891 ins; 317 del; 228 mod Patch: https://git.openjdk.java.net/jdk/pull/5027.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5027/head:pull/5027 PR: https://git.openjdk.java.net/jdk/pull/5027 From psandoz at openjdk.java.net Wed Oct 27 21:42:29 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 27 Oct 2021 21:42:29 GMT Subject: RFR: 8271515: Integration of JEP 417: Vector API (Third Incubator) [v7] In-Reply-To: <_QQ9ntdJJfzVcAGrbjev0ZM-xNfD4wNATphnXkb-Y00=.bbf46985-8776-4dda-ada5-b15ab50774aa@github.com> References: <_QQ9ntdJJfzVcAGrbjev0ZM-xNfD4wNATphnXkb-Y00=.bbf46985-8776-4dda-ada5-b15ab50774aa@github.com> Message-ID: > This PR improves the performance of vector operations that accept masks on architectures that support masking in hardware, specifically Intel AVX512 and ARM SVE. > > On architectures that do not support masking in hardware the same technique as before is applied to most operations, specifically composition using blend. > > Masked loads/stores are a special form of masked operation that require additional care to ensure out-of-bounds access throw exceptions. The range checking has not been fully optimized and will require further work. > > No API enhancements were required and only a few additional tests were needed. Paul Sandoz has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: - Merge branch 'master' into JDK-8271515-vector-api - Merge pull request #1 from nsjian/JDK-8271515 Address AArch64 review comments from Nick. - Address review comments from Nick. - Merge branch 'master' into JDK-8271515-vector-api - Resolve review comments. - Merge branch 'master' into JDK-8271515-vector-api - Apply patch from https://github.com/openjdk/panama-vector/pull/152 - Apply patch from https://github.com/openjdk/panama-vector/pull/142 - Apply patch from https://github.com/openjdk/panama-vector/pull/139 - Apply patch from https://github.com/openjdk/panama-vector/pull/151 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/9a3e9542...c9a77225 ------------- Changes: https://git.openjdk.java.net/jdk/pull/5873/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5873&range=06 Stats: 21966 lines in 104 files changed: 16193 ins; 2089 del; 3684 mod Patch: https://git.openjdk.java.net/jdk/pull/5873.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5873/head:pull/5873 PR: https://git.openjdk.java.net/jdk/pull/5873 From amenkov at openjdk.java.net Wed Oct 27 22:12:14 2021 From: amenkov at openjdk.java.net (Alex Menkov) Date: Wed, 27 Oct 2021 22:12:14 GMT Subject: RFR: JDK-8274930: sun/tools/jps/TestJps.java can fail with long VM arguments string In-Reply-To: References: Message-ID: On Thu, 7 Oct 2021 21:46:47 GMT, Alex Menkov wrote: > The fix adds "-XX:PerfMaxStringConstLength" argument running target app (default is 1024, 8K should be enough for any environments) Ping. Need 2nd reviewer ------------- PR: https://git.openjdk.java.net/jdk/pull/5858 From cjplummer at openjdk.java.net Wed Oct 27 23:12:13 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 27 Oct 2021 23:12:13 GMT Subject: RFR: JDK-8274930: sun/tools/jps/TestJps.java can fail with long VM arguments string In-Reply-To: References: Message-ID: On Thu, 7 Oct 2021 21:46:47 GMT, Alex Menkov wrote: > The fix adds "-XX:PerfMaxStringConstLength" argument running target app (default is 1024, 8K should be enough for any environments) Marked as reviewed by cjplummer (Reviewer). Actually revoking my review for the moment. Do we have any tests that currently test the default PerfMaxStringConstLength, and this change could be subverting the test by making it so the length is never exceeded? ------------- PR: https://git.openjdk.java.net/jdk/pull/5858 From duke at openjdk.java.net Wed Oct 27 23:19:24 2021 From: duke at openjdk.java.net (Mitsuru Kariya) Date: Wed, 27 Oct 2021 23:19:24 GMT Subject: RFR: 8153490: Cannot setBytes() if incoming buffer's length is bigger than number of elements we want to insert. [v6] In-Reply-To: References: Message-ID: On Sun, 24 Oct 2021 07:55:01 GMT, Mitsuru Kariya wrote: >> Fix `SerialBlob.setBytes(long pos, byte[] bytes, int offset, int length)` in the following cases: >> >> 1. `pos - 1 + bytes.length - offset > this.length() && pos - 1 + length <= this.length()` >> The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully. >> (test31) >> >> 2. `pos - 1 + length > this.length()` >> The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully. *1 >> (test32) >> >> 3. `pos == this.length() + 1` >> The original implementation throws `SerialException` but this case should end successfully. *2 >> (test33) >> >> 4. `length < 0` >> The original implementation throws `ArrayIndexOutOfBoundsException` but this case should throw `SerialException`. >> (test34) >> >> 5. `offset + length > Integer.MAX_VALUE` >> The original implementation throws `ArrayIndexOutOfBoundsException` (or `OutOfMemoryError` in most cases) but this case should throw `SerialException`. >> (test35) >> >> Additionally, fix `SerialClob.setString(long pos, String str, int offset, int length)` in the following cases: >> >> 1. `offset > str.length()` >> The original implementaion throws `StringIndexOutOfBoundsException` but this case should throw `SerialException`. >> (test39) >> >> 2. `pos - 1 + str.length() - offset > this.length() && pos - 1 + length <= this.length()` >> The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully. >> (test32) >> >> 3. `pos - 1 + length > this.length()` >> The original implementaion throws `SerialException` but this case should end successfully. *3 >> (test40) >> >> 4. `pos == this.length() + 1` >> The original implementaion throws `SerialException` but this case should end successfully. *4 >> (test41) >> >> 5. `length < 0` >> The original implementation throws `StringIndexOutOfBoundsException` but this case should throw `SerialException`. >> (test42) >> >> 6. `offset + length > Integer.MAX_VALUE` >> The original implementation throws `ArrayIndexOutOfBoundsException` (or `OutOfMemoryError` in most cases) but this case should throw `SerialException`. >> (test43) >> >> >> The javadoc has also been modified according to the above. >> >> *1 The documentation of `Blob.setBytes()` says, "If the end of the Blob value is reached while writing the array of bytes, then the length of the Blob value will be increased to accommodate the extra bytes." >> >> *2 The documentation of `Blob.setBytes()` says, "If the value specified for pos is greater than the length+1 of the BLOB value then the behavior is undefined." >> So, it should work correctly when pos == length+1 of the BLOB value. >> >> *3 The documentation of `Clob.setString()` says, "If the end of the Clob value is eached while writing the given string, then the length of the Clob value will be increased to accommodate the extra characters." >> >> *4 The documentation of `Clob.setString()` says, "If the value specified for pos is greater than the length+1 of the CLOB value then the behavior is undefined." >> So, it should work correctly when pos == length+1 of the CLOB value. > > Mitsuru Kariya has updated the pull request 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 JDK-8153490 > - Follow the comment > - Modify javadoc for consistency > - Fix for length + offset > Integer.MAX_VALUE case > - Add check: ensure length >= 0 > - 8153490:Cannot setBytes() if incoming buffer's length is bigger than number of elements we want to insert. > > Fix SerialBlob.setBytes(long pos, byte[] bytes, int offset, int length) in the > following cases: > > 1. pos - 1 + bytes.length - offset > this.length() && pos - 1 + length <= this.length() > The original implementation throws ArrayIndexOutOfBoundsException but this case > should end successfully. > (test31) > > 2. pos - 1 + length > this.length() > The original implementation throws ArrayIndexOutOfBoundsException but this case > should end successfully. *1 > (test32) > > 3. pos == this.length() + 1 > The original implementation throws SerialException but this case should end > successfully. *2 > (test33) > > Additionally, fix SerialClob.setString(long pos, String str, int offset, int length) > in the following cases: > > 1. offset > str.length() > The original implementaion throws StringIndexOutOfBoundsException but this case > should throw SerialException. > (test39) > > 2. pos - 1 + str.length() - offset > this.length() && pos - 1 + length <= this.length() > The original implementation throws ArrayIndexOutOfBoundsException but this case > should end successfully. > (test32) > > 3. pos - 1 + length > this.length() > The original implementaion throws SerialException but this case should end > successfully. *3 > (test40) > > 4. pos == this.length() + 1 > The original implementaion throws SerialException but this case should end > successfully. *4 > (test41) > > The javadoc has also been modified according to the above. > > *1 The documentation of Blob.setBytes() says, "If the end of the Blob value is > reached while writing the array of bytes, then the length of the Blob value > will be increased to accommodate the extra bytes." > > *2 The documentation of Blob.setBytes() says, "If the value specified for pos > is greater than the length+1 of the BLOB value then the behavior is > undefined." > So, it should work correctly when pos == length+1 of the BLOB value. > > *3 The documentation of Clob.setString() says, "If the end of the Clob value is > reached while writing the given string, then the length of the Clob value > will be increased to accommodate the extra characters." > > *4 The documentation of Clob.setString() says, "If the value specified for pos > is greater than the length+1 of the CLOB value then the behavior is > undefined." > So, it should work correctly when pos == length+1 of the CLOB value. Thanks a lot! ------------- PR: https://git.openjdk.java.net/jdk/pull/4001 From mchung at openjdk.java.net Wed Oct 27 23:34:44 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 27 Oct 2021 23:34:44 GMT Subject: RFR: JDK-8274848: LambdaMetaFactory::metafactory on REF_invokeSpecial impl method has incorrect behavior [v3] In-Reply-To: References: Message-ID: > Classes compiled prior to the nestmate support will generate `REF_invokeSpecial` if the implementation method is a private instance method. Since a lambda proxy class is a hidden class, a nestmate of the host class, it can invoke the private implementation method but it has to use `REF_invokeVirtual` or `REF_invokeInterface`. In order to support the old classes running on the new runtime, LMF implementation adjusts the reference kind from `REF_invokeSpecial` to `REF_invokeVirtual/REF_invokeInterface`. > > This PR fixes the check properly to ensure the adjustment is only made if the implementation method is private method in the host class. Mandy Chung 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: - Update test to test LMF with no dependency on javac behavior - Merge branch 'master' of https://github.com/openjdk/jdk into invokespecial - Merge branch 'invokespecial' of https://github.com/mlchung/jdk into invokespecial - remove filelist which was added accidentally - JDK-8274848: LambdaMetaFactory::metafactory on REF_invokeSpecial impl method has incorrect behavior ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5901/files - new: https://git.openjdk.java.net/jdk/pull/5901/files/cfdd036e..c44a5910 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5901&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5901&range=01-02 Stats: 29565 lines in 721 files changed: 21974 ins; 5102 del; 2489 mod Patch: https://git.openjdk.java.net/jdk/pull/5901.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5901/head:pull/5901 PR: https://git.openjdk.java.net/jdk/pull/5901 From mchung at openjdk.java.net Wed Oct 27 23:34:46 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 27 Oct 2021 23:34:46 GMT Subject: RFR: JDK-8274848: LambdaMetaFactory::metafactory on REF_invokeSpecial impl method has incorrect behavior [v2] In-Reply-To: References: Message-ID: On Mon, 25 Oct 2021 21:39:34 GMT, Dan Smith wrote: > I'd suggest invoking the LMF API directly instead, testing both private and non-private invokespecial MethodHandles, just making sure the rules can be used without error. That's a good idea. I updated the test and see what you think. ------------- PR: https://git.openjdk.java.net/jdk/pull/5901 From dholmes at openjdk.java.net Thu Oct 28 02:36:13 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 28 Oct 2021 02:36:13 GMT Subject: RFR: 8252990: Intrinsify Unsafe.storeStoreFence In-Reply-To: References: Message-ID: On Wed, 27 Oct 2021 11:53:47 GMT, Aleksey Shipilev wrote: > `Unsafe.storeStoreFence` currently delegates to stronger `Unsafe.storeFence`. We can teach compilers to map this directly to already existing rules that handle `MemBarStoreStore`. Like explicit `LoadFence`/`StoreFence`, we introduce the special node to differentiate explicit fence and implicit store-store barriers. This node is usually used to simulate safe `final`-field like constructions in special JDK classes, like `ConstantCallSite` and friends. > > Motivational performance difference on benchmarks from JDK-8276054 on ARM32: > > > Benchmark Mode Cnt Score Error Units > Multiple.plain avgt 3 2.669 ? 0.004 ns/op > Multiple.release avgt 3 16.688 ? 0.057 ns/op > Multiple.storeStore avgt 3 14.021 ? 0.144 ns/op // Better > > MultipleWithLoads.plain avgt 3 4.672 ? 0.053 ns/op > MultipleWithLoads.release avgt 3 16.689 ? 0.044 ns/op > MultipleWithLoads.storeStore avgt 3 14.012 ? 0.010 ns/op // Better > > MultipleWithStores.plain avgt 3 14.687 ? 0.009 ns/op > MultipleWithStores.release avgt 3 45.393 ? 0.192 ns/op > MultipleWithStores.storeStore avgt 3 38.048 ? 0.033 ns/op // Better > > Publishing.plain avgt 3 27.079 ? 0.201 ns/op > Publishing.release avgt 3 27.088 ? 0.241 ns/op > Publishing.storeStore avgt 3 27.009 ? 0.259 ns/op // Within error, hidden by allocation > > Single.plain avgt 3 2.670 ? 0.002 ns/op > Single.releaseFence avgt 3 6.675 ? 0.001 ns/op > Single.storeStoreFence avgt 3 8.012 ? 0.027 ns/op // Worse, seems to be ARM32 implementation artifact > > > As expected, this does not affect x86_64 at all, because both `release` and `storeStore` are effectively no-ops, only affecting compiler optimizations: > > > Benchmark Mode Cnt Score Error Units > > Multiple.plain avgt 3 0.406 ? 0.002 ns/op > Multiple.release avgt 3 0.409 ? 0.018 ns/op > Multiple.storeStore avgt 3 0.406 ? 0.001 ns/op > > MultipleWithLoads.plain avgt 3 4.328 ? 0.006 ns/op > MultipleWithLoads.release avgt 3 4.600 ? 0.014 ns/op > MultipleWithLoads.storeStore avgt 3 4.602 ? 0.006 ns/op > > MultipleWithStores.plain avgt 3 0.812 ? 0.001 ns/op > MultipleWithStores.release avgt 3 0.812 ? 0.002 ns/op > MultipleWithStores.storeStore avgt 3 0.812 ? 0.002 ns/op > > Publishing.plain avgt 3 6.370 ? 0.059 ns/op > Publishing.release avgt 3 6.358 ? 0.436 ns/op > Publishing.storeStore avgt 3 6.367 ? 0.054 ns/op > > Single.plain avgt 3 0.407 ? 0.039 ns/op > Single.releaseFence avgt 3 0.406 ? 0.001 ns/op > Single.storeStoreFence avgt 3 0.406 ? 0.001 ns/op > > > Additional testing: > - [x] Linux x86_64 fastdebug `tier1` src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 3449: > 3447: public final void storeStoreFence() { > 3448: // Without the special intrinsic, default to a stronger storeFence, > 3449: // which is already intrinsified. Not clear me to me why we need to retain this fallback? ------------- PR: https://git.openjdk.java.net/jdk/pull/6136 From jpai at openjdk.java.net Thu Oct 28 04:43:08 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Thu, 28 Oct 2021 04:43:08 GMT Subject: RFR: 8275509: ModuleDescriptor.hashCode isn't reproducible across builds [v4] In-Reply-To: References: Message-ID: <5jhv7khljhGE2R076sMSNW_S8CMD7s7XJ_P0N6KBcCw=.84ddcd6b-c2cf-4013-b28e-aa65ba99c672@github.com> On Fri, 22 Oct 2021 10:33:42 GMT, Jaikiran Pai wrote: >> src/java.base/share/classes/java/lang/module/ModuleDescriptor.java line 2559: >> >>> 2557: continue; >>> 2558: } >>> 2559: h += e.ordinal(); >> >> This e == null check suggests there is an issue elsewhere, can you explain the scenario where you see this? Also can you drop the spurious use of "final" here, it's inconsistent with the existing code. >> >> Do you want us to look at the test? It looks like it needs clean-up and I'm not sure if you want to wait for the CDS issue or not. > > Hello Alan, > >> This e == null check suggests there is an issue elsewhere, can you explain the scenario where you see this? > > That was just a pre-emptive defensive check I had added. There isn't a scenario in that flow where any of the elements are currently null. I have updated this PR to remove that check. Test continues to pass with this change. Also removed the "final". > >> Do you want us to look at the test? It looks like it needs clean-up and I'm not sure if you want to wait for the CDS issue or not. > > Yes please. The test is ready for review. The only place where there's a `TODO` is where that part of commented code is affected by the bug mentioned in that comment. I would like to use that check (the commented out one) but I don't want to wait for that other bug to be fixed for this PR, since I am unsure how big or how long it might take for the other bug to be fixed. I plan to uncomment that part in a separate PR once that other bug is fixed, if that's OK. Hello Alan, Looking at the CDS issue that's being tracked at https://bugs.openjdk.java.net/browse/JDK-8275731, it's looking like a much bigger change and might take a while. In the meantime do you think this test case (and the fix to the hashCode() part) looks OK? I am open to deleting the commented out equality check in this test case since although that equality testing should be done, it doesn't have to be done as part of this hashCode() fix/test PR. Let me know what you and others prefer. ------------- PR: https://git.openjdk.java.net/jdk/pull/6078 From vtewari at openjdk.java.net Thu Oct 28 04:51:12 2021 From: vtewari at openjdk.java.net (Vyom Tewari) Date: Thu, 28 Oct 2021 04:51:12 GMT Subject: RFR: 8276042: Remove unused local variables in java.naming [v2] In-Reply-To: References: <4G5GZ1ouQNL7u6snGAa-RDS3yJAp8Jsztt8wUdYSRFk=.7c2f6a72-f70c-4e7c-8442-8f667986eff8@github.com> Message-ID: On Wed, 27 Oct 2021 15:42:32 GMT, Andrey Turbanov wrote: >> 8276042: Remove unused local variables in java.naming > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8276042: Remove unused local variables in java.naming > use instanceof pattern Looks good to me. ------------- Marked as reviewed by vtewari (Committer). PR: https://git.openjdk.java.net/jdk/pull/6091 From shade at openjdk.java.net Thu Oct 28 07:03:19 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 28 Oct 2021 07:03:19 GMT Subject: RFR: 8252990: Intrinsify Unsafe.storeStoreFence In-Reply-To: References: Message-ID: On Thu, 28 Oct 2021 02:32:41 GMT, David Holmes wrote: >> `Unsafe.storeStoreFence` currently delegates to stronger `Unsafe.storeFence`. We can teach compilers to map this directly to already existing rules that handle `MemBarStoreStore`. Like explicit `LoadFence`/`StoreFence`, we introduce the special node to differentiate explicit fence and implicit store-store barriers. This node is usually used to simulate safe `final`-field like constructions in special JDK classes, like `ConstantCallSite` and friends. >> >> Motivational performance difference on benchmarks from JDK-8276054 on ARM32: >> >> >> Benchmark Mode Cnt Score Error Units >> Multiple.plain avgt 3 2.669 ? 0.004 ns/op >> Multiple.release avgt 3 16.688 ? 0.057 ns/op >> Multiple.storeStore avgt 3 14.021 ? 0.144 ns/op // Better >> >> MultipleWithLoads.plain avgt 3 4.672 ? 0.053 ns/op >> MultipleWithLoads.release avgt 3 16.689 ? 0.044 ns/op >> MultipleWithLoads.storeStore avgt 3 14.012 ? 0.010 ns/op // Better >> >> MultipleWithStores.plain avgt 3 14.687 ? 0.009 ns/op >> MultipleWithStores.release avgt 3 45.393 ? 0.192 ns/op >> MultipleWithStores.storeStore avgt 3 38.048 ? 0.033 ns/op // Better >> >> Publishing.plain avgt 3 27.079 ? 0.201 ns/op >> Publishing.release avgt 3 27.088 ? 0.241 ns/op >> Publishing.storeStore avgt 3 27.009 ? 0.259 ns/op // Within error, hidden by allocation >> >> Single.plain avgt 3 2.670 ? 0.002 ns/op >> Single.releaseFence avgt 3 6.675 ? 0.001 ns/op >> Single.storeStoreFence avgt 3 8.012 ? 0.027 ns/op // Worse, seems to be ARM32 implementation artifact >> >> >> As expected, this does not affect x86_64 at all, because both `release` and `storeStore` are effectively no-ops, only affecting compiler optimizations: >> >> >> Benchmark Mode Cnt Score Error Units >> >> Multiple.plain avgt 3 0.406 ? 0.002 ns/op >> Multiple.release avgt 3 0.409 ? 0.018 ns/op >> Multiple.storeStore avgt 3 0.406 ? 0.001 ns/op >> >> MultipleWithLoads.plain avgt 3 4.328 ? 0.006 ns/op >> MultipleWithLoads.release avgt 3 4.600 ? 0.014 ns/op >> MultipleWithLoads.storeStore avgt 3 4.602 ? 0.006 ns/op >> >> MultipleWithStores.plain avgt 3 0.812 ? 0.001 ns/op >> MultipleWithStores.release avgt 3 0.812 ? 0.002 ns/op >> MultipleWithStores.storeStore avgt 3 0.812 ? 0.002 ns/op >> >> Publishing.plain avgt 3 6.370 ? 0.059 ns/op >> Publishing.release avgt 3 6.358 ? 0.436 ns/op >> Publishing.storeStore avgt 3 6.367 ? 0.054 ns/op >> >> Single.plain avgt 3 0.407 ? 0.039 ns/op >> Single.releaseFence avgt 3 0.406 ? 0.001 ns/op >> Single.storeStoreFence avgt 3 0.406 ? 0.001 ns/op >> >> >> Additional testing: >> - [x] Linux x86_64 fastdebug `tier1` > > src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 3449: > >> 3447: public final void storeStoreFence() { >> 3448: // Without the special intrinsic, default to a stronger storeFence, >> 3449: // which is already intrinsified. > > Not clear me to me why we need to retain this fallback? Something should happen when intrinsic is disabled. Other fences have native `Unsafe_{Load|Store|Full}Fence` entry points for this. We can, technically, do the same here, but I see no need. Instead, we can fall back to the already implemented stronger intrinsic. ------------- PR: https://git.openjdk.java.net/jdk/pull/6136 From dholmes at openjdk.java.net Thu Oct 28 07:28:11 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 28 Oct 2021 07:28:11 GMT Subject: RFR: 8252990: Intrinsify Unsafe.storeStoreFence In-Reply-To: References: Message-ID: On Wed, 27 Oct 2021 11:53:47 GMT, Aleksey Shipilev wrote: > `Unsafe.storeStoreFence` currently delegates to stronger `Unsafe.storeFence`. We can teach compilers to map this directly to already existing rules that handle `MemBarStoreStore`. Like explicit `LoadFence`/`StoreFence`, we introduce the special node to differentiate explicit fence and implicit store-store barriers. This node is usually used to simulate safe `final`-field like constructions in special JDK classes, like `ConstantCallSite` and friends. > > Motivational performance difference on benchmarks from JDK-8276054 on ARM32: > > > Benchmark Mode Cnt Score Error Units > Multiple.plain avgt 3 2.669 ? 0.004 ns/op > Multiple.release avgt 3 16.688 ? 0.057 ns/op > Multiple.storeStore avgt 3 14.021 ? 0.144 ns/op // Better > > MultipleWithLoads.plain avgt 3 4.672 ? 0.053 ns/op > MultipleWithLoads.release avgt 3 16.689 ? 0.044 ns/op > MultipleWithLoads.storeStore avgt 3 14.012 ? 0.010 ns/op // Better > > MultipleWithStores.plain avgt 3 14.687 ? 0.009 ns/op > MultipleWithStores.release avgt 3 45.393 ? 0.192 ns/op > MultipleWithStores.storeStore avgt 3 38.048 ? 0.033 ns/op // Better > > Publishing.plain avgt 3 27.079 ? 0.201 ns/op > Publishing.release avgt 3 27.088 ? 0.241 ns/op > Publishing.storeStore avgt 3 27.009 ? 0.259 ns/op // Within error, hidden by allocation > > Single.plain avgt 3 2.670 ? 0.002 ns/op > Single.releaseFence avgt 3 6.675 ? 0.001 ns/op > Single.storeStoreFence avgt 3 8.012 ? 0.027 ns/op // Worse, seems to be ARM32 implementation artifact > > > As expected, this does not affect x86_64 at all, because both `release` and `storeStore` are effectively no-ops, only affecting compiler optimizations: > > > Benchmark Mode Cnt Score Error Units > > Multiple.plain avgt 3 0.406 ? 0.002 ns/op > Multiple.release avgt 3 0.409 ? 0.018 ns/op > Multiple.storeStore avgt 3 0.406 ? 0.001 ns/op > > MultipleWithLoads.plain avgt 3 4.328 ? 0.006 ns/op > MultipleWithLoads.release avgt 3 4.600 ? 0.014 ns/op > MultipleWithLoads.storeStore avgt 3 4.602 ? 0.006 ns/op > > MultipleWithStores.plain avgt 3 0.812 ? 0.001 ns/op > MultipleWithStores.release avgt 3 0.812 ? 0.002 ns/op > MultipleWithStores.storeStore avgt 3 0.812 ? 0.002 ns/op > > Publishing.plain avgt 3 6.370 ? 0.059 ns/op > Publishing.release avgt 3 6.358 ? 0.436 ns/op > Publishing.storeStore avgt 3 6.367 ? 0.054 ns/op > > Single.plain avgt 3 0.407 ? 0.039 ns/op > Single.releaseFence avgt 3 0.406 ? 0.001 ns/op > Single.storeStoreFence avgt 3 0.406 ? 0.001 ns/op > > > Additional testing: > - [x] Linux x86_64 fastdebug `tier1` I'm certainly no JIT expert but the pattern for adding the new intrinsic seems consistent with the existing code. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6136 From dholmes at openjdk.java.net Thu Oct 28 07:28:11 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 28 Oct 2021 07:28:11 GMT Subject: RFR: 8252990: Intrinsify Unsafe.storeStoreFence In-Reply-To: References: Message-ID: On Thu, 28 Oct 2021 07:00:24 GMT, Aleksey Shipilev wrote: >> src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 3449: >> >>> 3447: public final void storeStoreFence() { >>> 3448: // Without the special intrinsic, default to a stronger storeFence, >>> 3449: // which is already intrinsified. >> >> Not clear me to me why we need to retain this fallback? > > Something should happen when intrinsic is disabled. Other fences have native `Unsafe_{Load|Store|Full}Fence` entry points for this. We can, technically, do the same here, but I see no need. Instead, we can fall back to the already implemented stronger intrinsic. Thanks for clarifying. Now we have all the intrinsics in place we have the choice of delegating either at the Java level or the native level, where previously we had to delegate at the Java level to get the benefit of the storeFence intrinsic. But it is fine as-is. ------------- PR: https://git.openjdk.java.net/jdk/pull/6136 From shade at openjdk.java.net Thu Oct 28 07:48:15 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 28 Oct 2021 07:48:15 GMT Subject: RFR: 8252990: Intrinsify Unsafe.storeStoreFence In-Reply-To: References: Message-ID: On Thu, 28 Oct 2021 07:23:52 GMT, David Holmes wrote: >> Something should happen when intrinsic is disabled. Other fences have native `Unsafe_{Load|Store|Full}Fence` entry points for this. We can, technically, do the same here, but I see no need. Instead, we can fall back to the already implemented stronger intrinsic. > > Thanks for clarifying. Now we have all the intrinsics in place we have the choice of delegating either at the Java level or the native level, where previously we had to delegate at the Java level to get the benefit of the storeFence intrinsic. But it is fine as-is. Now I am actually thinking to drop `Unsafe_{Load|Store}Fence` entry points and delegate `Unsafe.{load|store}Fence()` to `Unsafe.fullFence()` as the fallback, in a similar way. It looks to me calling all the way to `unsafe.cpp` for a single barrier is not that useful. That's something for a separate PR. So it would be something like: - `storeStore` intrinsifies efficiently, or falls back to `release` - `loadLoad` always falls back to `acquire` (seems to be little sense to intrinsify this, as all platforms alias it to `acquire`) - `acquire` intrinsifies efficiently, or falls back to `full` - `release` intrinsifies efficiently, or falls back to `full` - `full` intrinsifies efficiently, or falls back to `Unsafe_FullFence`, which calls `OrderAccess::fullFence()`. ------------- PR: https://git.openjdk.java.net/jdk/pull/6136 From duke at openjdk.java.net Thu Oct 28 08:45:20 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Thu, 28 Oct 2021 08:45:20 GMT Subject: Integrated: 8276042: Remove unused local variables in java.naming In-Reply-To: <4G5GZ1ouQNL7u6snGAa-RDS3yJAp8Jsztt8wUdYSRFk=.7c2f6a72-f70c-4e7c-8442-8f667986eff8@github.com> References: <4G5GZ1ouQNL7u6snGAa-RDS3yJAp8Jsztt8wUdYSRFk=.7c2f6a72-f70c-4e7c-8442-8f667986eff8@github.com> Message-ID: <-AF7Bq3KsTSIGMTU9-qTBhcrOv2s0_-bcXEI2d34qUw=.cd03c4a5-1fdf-4cd1-aeff-955b86fb6c22@github.com> On Sat, 23 Oct 2021 12:51:15 GMT, Andrey Turbanov wrote: > 8276042: Remove unused local variables in java.naming This pull request has now been integrated. Changeset: 593401fe Author: Andrey Turbanov Committer: Aleksei Efimov URL: https://git.openjdk.java.net/jdk/commit/593401fe8b38bbb8d331a862818fe077af157fcb Stats: 12 lines in 5 files changed: 0 ins; 5 del; 7 mod 8276042: Remove unused local variables in java.naming Reviewed-by: aefimov, dfuchs, vtewari ------------- PR: https://git.openjdk.java.net/jdk/pull/6091 From shade at openjdk.java.net Thu Oct 28 08:58:41 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 28 Oct 2021 08:58:41 GMT Subject: RFR: 8276096: Simplify Unsafe.{load|store}Fence fallbacks by delegating to fullFence Message-ID: `Unsafe.{load|store}Fence` falls back to `unsafe.cpp` for `OrderAccess::{acquire|release}Fence()`. It seems too heavy-handed (useless?) to call to runtime for a single memory barrier. We can simplify the native `Unsafe` interface by falling back to `fullFence` when `{load|store}Fence` intrinsics are not available. This would be similar to what `Unsafe.{loadLoad|storeStore}Fences` do. This is the behavior of these intrinsics now, on x86_64, using benchmarks from JDK-8276054: Benchmark Mode Cnt Score Error Units # Default Single.acquire avgt 3 0.407 ? 0.060 ns/op Single.full avgt 3 4.693 ? 0.005 ns/op Single.loadLoad avgt 3 0.415 ? 0.095 ns/op Single.plain avgt 3 0.406 ? 0.002 ns/op Single.release avgt 3 0.408 ? 0.047 ns/op Single.storeStore avgt 3 0.408 ? 0.043 ns/op # -XX:DisableIntrinsic=_storeFence Single.acquire avgt 3 0.408 ? 0.016 ns/op Single.full avgt 3 4.694 ? 0.002 ns/op Single.loadLoad avgt 3 0.406 ? 0.002 ns/op Single.plain avgt 3 0.406 ? 0.001 ns/op Single.release avgt 3 4.694 ? 0.003 ns/op <--- upgraded to full Single.storeStore avgt 3 4.690 ? 0.005 ns/op <--- upgraded to full # -XX:DisableIntrinsic=_loadFence Single.acquire avgt 3 4.691 ? 0.001 ns/op <--- upgraded to full Single.full avgt 3 4.693 ? 0.009 ns/op Single.loadLoad avgt 3 4.693 ? 0.013 ns/op <--- upgraded to full Single.plain avgt 3 0.408 ? 0.072 ns/op Single.release avgt 3 0.415 ? 0.016 ns/op Single.storeStore avgt 3 0.416 ? 0.041 ns/op # -XX:DisableIntrinsic=_fullFence Single.acquire avgt 3 0.406 ? 0.014 ns/op Single.full avgt 3 15.836 ? 0.151 ns/op <--- calls runtime Single.loadLoad avgt 3 0.406 ? 0.001 ns/op Single.plain avgt 3 0.426 ? 0.361 ns/op Single.release avgt 3 0.407 ? 0.021 ns/op Single.storeStore avgt 3 0.410 ? 0.061 ns/op # -XX:DisableIntrinsic=_fullFence,_loadFence Single.acquire avgt 3 15.822 ? 0.282 ns/op <--- upgraded, calls runtime Single.full avgt 3 15.851 ? 0.127 ns/op <--- calls runtime Single.loadLoad avgt 3 15.829 ? 0.045 ns/op <--- upgraded, calls runtime Single.plain avgt 3 0.406 ? 0.001 ns/op Single.release avgt 3 0.414 ? 0.156 ns/op Single.storeStore avgt 3 0.422 ? 0.452 ns/op # -XX:DisableIntrinsic=_fullFence,_storeFence Single.acquire avgt 3 0.407 ? 0.016 ns/op Single.full avgt 3 15.347 ? 6.783 ns/op <--- calls runtime Single.loadLoad avgt 3 0.406 ? 0.001 ns/op Single.plain avgt 3 0.406 ? 0.002 ns/op Single.release avgt 3 15.828 ? 0.019 ns/op <--- upgraded, calls runtime Single.storeStore avgt 3 15.834 ? 0.045 ns/op <--- upgraded, calls runtime # -XX:DisableIntrinsic=_fullFence,_loadFence,_storeFence Single.acquire avgt 3 15.838 ? 0.030 ns/op <--- upgraded, calls runtime Single.full avgt 3 15.854 ? 0.277 ns/op <--- calls runtime Single.loadLoad avgt 3 15.826 ? 0.160 ns/op <--- upgraded, calls runtime Single.plain avgt 3 0.406 ? 0.003 ns/op Single.release avgt 3 15.838 ? 0.019 ns/op <--- upgraded, calls runtime Single.storeStore avgt 3 15.844 ? 0.104 ns/op <--- upgraded, calls runtime Additional testing: - [x] Linux x86_64 fastdebug `tier1` ------------- Commit messages: - Fix Changes: https://git.openjdk.java.net/jdk/pull/6149/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6149&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276096 Stats: 22 lines in 3 files changed: 6 ins; 11 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/6149.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6149/head:pull/6149 PR: https://git.openjdk.java.net/jdk/pull/6149 From shade at openjdk.java.net Thu Oct 28 08:58:48 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 28 Oct 2021 08:58:48 GMT Subject: RFR: 8252990: Intrinsify Unsafe.storeStoreFence [v2] In-Reply-To: References: Message-ID: > `Unsafe.storeStoreFence` currently delegates to stronger `Unsafe.storeFence`. We can teach compilers to map this directly to already existing rules that handle `MemBarStoreStore`. Like explicit `LoadFence`/`StoreFence`, we introduce the special node to differentiate explicit fence and implicit store-store barriers. `storeStoreFence` is usually used to simulate safe `final`-field like constructions in special JDK classes, like `ConstantCallSite` and friends. > > Motivational performance difference on benchmarks from JDK-8276054 on ARM32: > > > Benchmark Mode Cnt Score Error Units > Multiple.plain avgt 3 2.669 ? 0.004 ns/op > Multiple.release avgt 3 16.688 ? 0.057 ns/op > Multiple.storeStore avgt 3 14.021 ? 0.144 ns/op // Better > > MultipleWithLoads.plain avgt 3 4.672 ? 0.053 ns/op > MultipleWithLoads.release avgt 3 16.689 ? 0.044 ns/op > MultipleWithLoads.storeStore avgt 3 14.012 ? 0.010 ns/op // Better > > MultipleWithStores.plain avgt 3 14.687 ? 0.009 ns/op > MultipleWithStores.release avgt 3 45.393 ? 0.192 ns/op > MultipleWithStores.storeStore avgt 3 38.048 ? 0.033 ns/op // Better > > Publishing.plain avgt 3 27.079 ? 0.201 ns/op > Publishing.release avgt 3 27.088 ? 0.241 ns/op > Publishing.storeStore avgt 3 27.009 ? 0.259 ns/op // Within error, hidden by allocation > > Single.plain avgt 3 2.670 ? 0.002 ns/op > Single.releaseFence avgt 3 6.675 ? 0.001 ns/op > Single.storeStoreFence avgt 3 8.012 ? 0.027 ns/op // Worse, seems to be ARM32 implementation artifact > > > As expected, this does not affect x86_64 at all, because both `release` and `storeStore` are effectively no-ops, only affecting compiler optimizations: > > > Benchmark Mode Cnt Score Error Units > > Multiple.plain avgt 3 0.406 ? 0.002 ns/op > Multiple.release avgt 3 0.409 ? 0.018 ns/op > Multiple.storeStore avgt 3 0.406 ? 0.001 ns/op > > MultipleWithLoads.plain avgt 3 4.328 ? 0.006 ns/op > MultipleWithLoads.release avgt 3 4.600 ? 0.014 ns/op > MultipleWithLoads.storeStore avgt 3 4.602 ? 0.006 ns/op > > MultipleWithStores.plain avgt 3 0.812 ? 0.001 ns/op > MultipleWithStores.release avgt 3 0.812 ? 0.002 ns/op > MultipleWithStores.storeStore avgt 3 0.812 ? 0.002 ns/op > > Publishing.plain avgt 3 6.370 ? 0.059 ns/op > Publishing.release avgt 3 6.358 ? 0.436 ns/op > Publishing.storeStore avgt 3 6.367 ? 0.054 ns/op > > Single.plain avgt 3 0.407 ? 0.039 ns/op > Single.releaseFence avgt 3 0.406 ? 0.001 ns/op > Single.storeStoreFence avgt 3 0.406 ? 0.001 ns/op > > > Additional testing: > - [x] Linux x86_64 fastdebug `tier1` Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Fix the comment to match JDK-8276096 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6136/files - new: https://git.openjdk.java.net/jdk/pull/6136/files/5277aa2a..1f24d71c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6136&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6136&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6136.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6136/head:pull/6136 PR: https://git.openjdk.java.net/jdk/pull/6136 From shade at openjdk.java.net Thu Oct 28 08:58:49 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 28 Oct 2021 08:58:49 GMT Subject: RFR: 8252990: Intrinsify Unsafe.storeStoreFence [v2] In-Reply-To: References: Message-ID: On Thu, 28 Oct 2021 07:41:59 GMT, Aleksey Shipilev wrote: >> Thanks for clarifying. Now we have all the intrinsics in place we have the choice of delegating either at the Java level or the native level, where previously we had to delegate at the Java level to get the benefit of the storeFence intrinsic. But it is fine as-is. > > Now I am actually thinking to drop `Unsafe_{Load|Store}Fence` entry points and delegate `Unsafe.{load|store}Fence()` to `Unsafe.fullFence()` as the fallback, in a similar way. It looks to me calling all the way to `unsafe.cpp` for a single barrier is not that useful. That's something for a separate PR. > > So it would be something like: > - `storeStore` intrinsifies efficiently, or falls back to `release` > - `loadLoad` always falls back to `acquire` (seems to be little sense to intrinsify this, as all platforms alias it to `acquire`) > - `acquire` intrinsifies efficiently, or falls back to `full` > - `release` intrinsifies efficiently, or falls back to `full` > - `full` intrinsifies efficiently, or falls back to `Unsafe_FullFence`, which calls `OrderAccess::fullFence()`. Doing it here: #6149, JDK-8276096. ------------- PR: https://git.openjdk.java.net/jdk/pull/6136 From thartmann at openjdk.java.net Thu Oct 28 09:09:14 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Thu, 28 Oct 2021 09:09:14 GMT Subject: RFR: 8252990: Intrinsify Unsafe.storeStoreFence [v2] In-Reply-To: References: Message-ID: On Thu, 28 Oct 2021 08:58:48 GMT, Aleksey Shipilev wrote: >> `Unsafe.storeStoreFence` currently delegates to stronger `Unsafe.storeFence`. We can teach compilers to map this directly to already existing rules that handle `MemBarStoreStore`. Like explicit `LoadFence`/`StoreFence`, we introduce the special node to differentiate explicit fence and implicit store-store barriers. `storeStoreFence` is usually used to simulate safe `final`-field like constructions in special JDK classes, like `ConstantCallSite` and friends. >> >> Motivational performance difference on benchmarks from JDK-8276054 on ARM32: >> >> >> Benchmark Mode Cnt Score Error Units >> Multiple.plain avgt 3 2.669 ? 0.004 ns/op >> Multiple.release avgt 3 16.688 ? 0.057 ns/op >> Multiple.storeStore avgt 3 14.021 ? 0.144 ns/op // Better >> >> MultipleWithLoads.plain avgt 3 4.672 ? 0.053 ns/op >> MultipleWithLoads.release avgt 3 16.689 ? 0.044 ns/op >> MultipleWithLoads.storeStore avgt 3 14.012 ? 0.010 ns/op // Better >> >> MultipleWithStores.plain avgt 3 14.687 ? 0.009 ns/op >> MultipleWithStores.release avgt 3 45.393 ? 0.192 ns/op >> MultipleWithStores.storeStore avgt 3 38.048 ? 0.033 ns/op // Better >> >> Publishing.plain avgt 3 27.079 ? 0.201 ns/op >> Publishing.release avgt 3 27.088 ? 0.241 ns/op >> Publishing.storeStore avgt 3 27.009 ? 0.259 ns/op // Within error, hidden by allocation >> >> Single.plain avgt 3 2.670 ? 0.002 ns/op >> Single.releaseFence avgt 3 6.675 ? 0.001 ns/op >> Single.storeStoreFence avgt 3 8.012 ? 0.027 ns/op // Worse, seems to be ARM32 implementation artifact >> >> >> As expected, this does not affect x86_64 at all, because both `release` and `storeStore` are effectively no-ops, only affecting compiler optimizations: >> >> >> Benchmark Mode Cnt Score Error Units >> >> Multiple.plain avgt 3 0.406 ? 0.002 ns/op >> Multiple.release avgt 3 0.409 ? 0.018 ns/op >> Multiple.storeStore avgt 3 0.406 ? 0.001 ns/op >> >> MultipleWithLoads.plain avgt 3 4.328 ? 0.006 ns/op >> MultipleWithLoads.release avgt 3 4.600 ? 0.014 ns/op >> MultipleWithLoads.storeStore avgt 3 4.602 ? 0.006 ns/op >> >> MultipleWithStores.plain avgt 3 0.812 ? 0.001 ns/op >> MultipleWithStores.release avgt 3 0.812 ? 0.002 ns/op >> MultipleWithStores.storeStore avgt 3 0.812 ? 0.002 ns/op >> >> Publishing.plain avgt 3 6.370 ? 0.059 ns/op >> Publishing.release avgt 3 6.358 ? 0.436 ns/op >> Publishing.storeStore avgt 3 6.367 ? 0.054 ns/op >> >> Single.plain avgt 3 0.407 ? 0.039 ns/op >> Single.releaseFence avgt 3 0.406 ? 0.001 ns/op >> Single.storeStoreFence avgt 3 0.406 ? 0.001 ns/op >> >> >> Additional testing: >> - [x] Linux x86_64 fastdebug `tier1` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Fix the comment to match JDK-8276096 That looks good to me. ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6136 From myano at openjdk.java.net Thu Oct 28 09:38:33 2021 From: myano at openjdk.java.net (Masanori Yano) Date: Thu, 28 Oct 2021 09:38:33 GMT Subject: RFR: 8262297: ImageIO.write() method will throw IndexOutOfBoundsException Message-ID: Could you please review the 8262297 bug fixes? In this case, ImageIO.write() should throw java.io.IOException rather than java.lang.IndexOutOfBoundsException. IndexOutOfBoundsException is caught and wrapped in IIOException in ImageIO.write() with this fix. In addition, IndexOutOfBoundsException is not expected to throw by RandomAccessFile#write() according to its API specification. So it should be fixed. ------------- Commit messages: - 8262297: ImageIO.write() method will throw IndexOutOfBoundsException Changes: https://git.openjdk.java.net/jdk/pull/6151/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6151&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262297 Stats: 96 lines in 4 files changed: 71 ins; 0 del; 25 mod Patch: https://git.openjdk.java.net/jdk/pull/6151.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6151/head:pull/6151 PR: https://git.openjdk.java.net/jdk/pull/6151 From myano at openjdk.java.net Thu Oct 28 09:41:17 2021 From: myano at openjdk.java.net (Masanori Yano) Date: Thu, 28 Oct 2021 09:41:17 GMT Subject: RFR: 8233674: JarURLConnection.getJarFile throws Exception if some process is holding the file In-Reply-To: References: Message-ID: On Fri, 10 Sep 2021 09:23:52 GMT, Masanori Yano wrote: > Could you please review the 8233674 bug fixes? > This problem is caused by the antivirus software opening the file for a short time, so CreateFile() should be retried. Thank you for your reply. I understand we have no need to fix the JDK. I will close this pull request. ------------- PR: https://git.openjdk.java.net/jdk/pull/5460 From myano at openjdk.java.net Thu Oct 28 09:41:17 2021 From: myano at openjdk.java.net (Masanori Yano) Date: Thu, 28 Oct 2021 09:41:17 GMT Subject: Withdrawn: 8233674: JarURLConnection.getJarFile throws Exception if some process is holding the file In-Reply-To: References: Message-ID: <_Ke99GmwxSN9hJbO1BGbSGwIE2J0ZcszsZkwPawkSXQ=.8b7f91dd-5fbb-4532-b201-8e0f4d3ebddb@github.com> On Fri, 10 Sep 2021 09:23:52 GMT, Masanori Yano wrote: > Could you please review the 8233674 bug fixes? > This problem is caused by the antivirus software opening the file for a short time, so CreateFile() should be retried. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/5460 From shade at openjdk.java.net Thu Oct 28 11:19:20 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 28 Oct 2021 11:19:20 GMT Subject: RFR: 8276102: JDK-8245095 integration reverted JDK-8247980 Message-ID: See the [integration commit](https://github.com/openjdk/jdk/commit/9d191fce55fa70d6a2affc724fad57b0e20e4bde#diff-5b9b15832385ab8e02ffca3ddef6d65a9dea73f45abbe5e4f0be561be02073ffR30 ) for JDK-8245095. It reintroduced `java/util/stream` in `exclusiveAccess.dirs`, which effectively reverts JDK-8247980. I noticed this because jdk:tier1 became slow again. @FrauBoes, that was not intentional, right? The solution is to drop `java/util/stream` again. Additional testing: - [x] Linux x86_64 fastdebug `jdk:tier1` tests are fast again ------------- Commit messages: - Fix Changes: https://git.openjdk.java.net/jdk/pull/6153/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6153&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276102 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6153.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6153/head:pull/6153 PR: https://git.openjdk.java.net/jdk/pull/6153 From rreddy at openjdk.java.net Thu Oct 28 11:56:45 2021 From: rreddy at openjdk.java.net (Ravi Reddy) Date: Thu, 28 Oct 2021 11:56:45 GMT Subject: RFR: 8193682: Infinite loop in ZipOutputStream.close() [v5] In-Reply-To: References: Message-ID: > Hi all, > > Please review this fix for Infinite loop in ZipOutputStream.close(). > The main issue here is when ever there is an exception during close operations on GZip we are not setting the deflator to a finished state which is leading to an infinite loop when we try writing on the same GZip instance( since we use while(!def.finished()) inside the write operation). > > Thanks, > Ravi Ravi Reddy has updated the pull request incrementally with one additional commit since the last revision: 8193682 : Infinite loop in ZipOutputStream.close() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5522/files - new: https://git.openjdk.java.net/jdk/pull/5522/files/5f1922bf..01d84462 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5522&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5522&range=03-04 Stats: 118 lines in 3 files changed: 11 ins; 58 del; 49 mod Patch: https://git.openjdk.java.net/jdk/pull/5522.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5522/head:pull/5522 PR: https://git.openjdk.java.net/jdk/pull/5522 From sgehwolf at openjdk.java.net Thu Oct 28 13:11:21 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Thu, 28 Oct 2021 13:11:21 GMT Subject: RFR: 8275735: [linux] Remove deprecated Metrics api (kernel memory limit) Message-ID: <7ZPXxcvf9coOZQFefQf8GQAUgskWHL1dvQkCknWUBUs=.4013d956-3ef7-4f40-8c4f-c0c8578fdae0@github.com> Please review this change to remove some API which no longer works as expected as recent OCI runtimes start to drop support for `--kernel-memory` switch. See the bug for references. This part of the API is not present in hotspot code. Testing: Container tests (cgroup v1) on Linux x86_64 (all pass) ------------- Commit messages: - 8275735: [linux] Remove deprecated Metrics api (kernel memory limit) Changes: https://git.openjdk.java.net/jdk/pull/6156/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6156&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275735 Stats: 104 lines in 6 files changed: 0 ins; 100 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/6156.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6156/head:pull/6156 PR: https://git.openjdk.java.net/jdk/pull/6156 From hseigel at openjdk.java.net Thu Oct 28 14:07:11 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Thu, 28 Oct 2021 14:07:11 GMT Subject: RFR: 8275735: [linux] Remove deprecated Metrics api (kernel memory limit) In-Reply-To: <7ZPXxcvf9coOZQFefQf8GQAUgskWHL1dvQkCknWUBUs=.4013d956-3ef7-4f40-8c4f-c0c8578fdae0@github.com> References: <7ZPXxcvf9coOZQFefQf8GQAUgskWHL1dvQkCknWUBUs=.4013d956-3ef7-4f40-8c4f-c0c8578fdae0@github.com> Message-ID: On Thu, 28 Oct 2021 13:03:56 GMT, Severin Gehwolf wrote: > Please review this change to remove some API which no longer works as expected as recent OCI runtimes start to drop support for `--kernel-memory` switch. See the bug for references. This part of the API is not present in hotspot code. > > Testing: Container tests (cgroup v1) on Linux x86_64 (all pass) The changes look good. Thanks for doing this. Harold ------------- Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6156 From sgehwolf at openjdk.java.net Thu Oct 28 14:11:09 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Thu, 28 Oct 2021 14:11:09 GMT Subject: RFR: 8275735: [linux] Remove deprecated Metrics api (kernel memory limit) In-Reply-To: References: <7ZPXxcvf9coOZQFefQf8GQAUgskWHL1dvQkCknWUBUs=.4013d956-3ef7-4f40-8c4f-c0c8578fdae0@github.com> Message-ID: On Thu, 28 Oct 2021 14:04:15 GMT, Harold Seigel wrote: > The changes look good. Thanks for doing this. Harold Thanks for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/6156 From Alan.Bateman at oracle.com Thu Oct 28 14:22:57 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 28 Oct 2021 15:22:57 +0100 Subject: RFR: 8275509: ModuleDescriptor.hashCode isn't reproducible across builds [v4] In-Reply-To: <5jhv7khljhGE2R076sMSNW_S8CMD7s7XJ_P0N6KBcCw=.84ddcd6b-c2cf-4013-b28e-aa65ba99c672@github.com> References: <5jhv7khljhGE2R076sMSNW_S8CMD7s7XJ_P0N6KBcCw=.84ddcd6b-c2cf-4013-b28e-aa65ba99c672@github.com> Message-ID: On 28/10/2021 05:43, Jaikiran Pai wrote: > : > Hello Alan, > > Looking at the CDS issue that's being tracked at https://bugs.openjdk.java.net/browse/JDK-8275731, it's looking like a much bigger change and might take a while. In the meantime do you think this test case (and the fix to the hashCode() part) looks OK? I am open to deleting the commented out equality check in this test case since although that equality testing should be done, it doesn't have to be done as part of this hashCode() fix/test PR. Let me know what you and others prefer. I think it's okay to move to using the ordinal of the hash code. I think the test will need a round or two of clean-up to get it more consistent with the existing naming and style of tests in this area.? I'd prefer not have commented out "TODO" code if possible. -Alan. From lancea at openjdk.java.net Thu Oct 28 14:32:16 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 28 Oct 2021 14:32:16 GMT Subject: RFR: 8193682: Infinite loop in ZipOutputStream.close() [v5] In-Reply-To: References: Message-ID: On Thu, 28 Oct 2021 11:56:45 GMT, Ravi Reddy wrote: >> Hi all, >> >> Please review this fix for Infinite loop in ZipOutputStream.close(). >> The main issue here is when ever there is an exception during close operations on GZip we are not setting the deflator to a finished state which is leading to an infinite loop when we try writing on the same GZip instance( since we use while(!def.finished()) inside the write operation). >> >> Thanks, >> Ravi > > Ravi Reddy has updated the pull request incrementally with one additional commit since the last revision: > > 8193682 : Infinite loop in ZipOutputStream.close() I think we are closer. The formatting is better. Thank you for changing the name for the constant. Please add comments describing the intent of the test, DataProvider, and BeforeTest method to make it clear to future maintainers when they look back on the tests. We should still create a CSR to highlight the change. ------------- PR: https://git.openjdk.java.net/jdk/pull/5522 From alanb at openjdk.java.net Thu Oct 28 14:33:14 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 28 Oct 2021 14:33:14 GMT Subject: RFR: 8262297: ImageIO.write() method will throw IndexOutOfBoundsException In-Reply-To: References: Message-ID: <0OrjZzeb7XifWJIH2jmrFAXflWPbagiJN7QvT8LA7XU=.dfb665f3-70c7-40c6-ba19-5b945337c446@github.com> On Thu, 28 Oct 2021 09:29:13 GMT, Masanori Yano wrote: > Could you please review the 8262297 bug fixes? > > In this case, ImageIO.write() should throw java.io.IOException rather than java.lang.IndexOutOfBoundsException. IndexOutOfBoundsException is caught and wrapped in IIOException in ImageIO.write() with this fix. In addition, IndexOutOfBoundsException is not expected to throw by RandomAccessFile#write() according to its API specification. So it should be fixed. src/java.base/share/classes/java/io/RandomAccessFile.java line 558: > 556: * @throws IndexOutOfBoundsException If {@code off} is negative, > 557: * {@code len} is negative, or {@code len} is greater than > 558: * {@code b.length - off} The IOOBE is specified in the super interface, it's just not shown in the javadoc because it's a runtime exception. So I think what you want here is: @throws IndexOutOfBoundsException {@inheritDoc} ------------- PR: https://git.openjdk.java.net/jdk/pull/6151 From isipka at openjdk.java.net Thu Oct 28 15:30:49 2021 From: isipka at openjdk.java.net (Ivan =?UTF-8?B?xaBpcGth?=) Date: Thu, 28 Oct 2021 15:30:49 GMT Subject: RFR: 8275650: Problemlist java/io/File/createTempFile/SpecialTempFile.java for Windows 11 [v3] In-Reply-To: References: Message-ID: > cc @ctornqvi Ivan ?ipka has updated the pull request incrementally with one additional commit since the last revision: changing os id ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6025/files - new: https://git.openjdk.java.net/jdk/pull/6025/files/931a9ea4..97d000a0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6025&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6025&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6025.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6025/head:pull/6025 PR: https://git.openjdk.java.net/jdk/pull/6025 From mchung at openjdk.java.net Thu Oct 28 15:31:29 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 28 Oct 2021 15:31:29 GMT Subject: Integrated: JDK-8275703: System.loadLibrary fails on Big Sur for libraries hidden from filesystem In-Reply-To: <1d0vB2i2qrGaWRxtX_FqnYWrKcgXHaPvShDeSSG9cXg=.f733da58-3eaf-4eda-8c93-f8e81a384326@github.com> References: <1d0vB2i2qrGaWRxtX_FqnYWrKcgXHaPvShDeSSG9cXg=.f733da58-3eaf-4eda-8c93-f8e81a384326@github.com> Message-ID: On Tue, 26 Oct 2021 22:51:29 GMT, Mandy Chung wrote: > On, macOS 11.x, system libraries are loaded from dynamic linker cache. The libraries are no longer present on the filesystem. `NativeLibraries::loadLibrary` checks for the file existence before calling `JVM_LoadLibrary`. Such check no longer applies on Big Sur. This proposes that on macOS >= 11, it will skip the file existence check and attempt to load a library for each path from java.library.path and system library path. This pull request has now been integrated. Changeset: 309acbf0 Author: Mandy Chung URL: https://git.openjdk.java.net/jdk/commit/309acbf0e86a0d248294503fccc7a936fa0a846e Stats: 203 lines in 10 files changed: 170 ins; 3 del; 30 mod 8275703: System.loadLibrary fails on Big Sur for libraries hidden from filesystem Reviewed-by: dholmes, alanb, mcimadamore ------------- PR: https://git.openjdk.java.net/jdk/pull/6127 From duke at openjdk.java.net Thu Oct 28 15:59:20 2021 From: duke at openjdk.java.net (Mitsuru Kariya) Date: Thu, 28 Oct 2021 15:59:20 GMT Subject: Integrated: 8153490: Cannot setBytes() if incoming buffer's length is bigger than number of elements we want to insert. In-Reply-To: References: Message-ID: On Wed, 12 May 2021 17:48:50 GMT, Mitsuru Kariya wrote: > Fix `SerialBlob.setBytes(long pos, byte[] bytes, int offset, int length)` in the following cases: > > 1. `pos - 1 + bytes.length - offset > this.length() && pos - 1 + length <= this.length()` > The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully. > (test31) > > 2. `pos - 1 + length > this.length()` > The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully. *1 > (test32) > > 3. `pos == this.length() + 1` > The original implementation throws `SerialException` but this case should end successfully. *2 > (test33) > > 4. `length < 0` > The original implementation throws `ArrayIndexOutOfBoundsException` but this case should throw `SerialException`. > (test34) > > 5. `offset + length > Integer.MAX_VALUE` > The original implementation throws `ArrayIndexOutOfBoundsException` (or `OutOfMemoryError` in most cases) but this case should throw `SerialException`. > (test35) > > Additionally, fix `SerialClob.setString(long pos, String str, int offset, int length)` in the following cases: > > 1. `offset > str.length()` > The original implementaion throws `StringIndexOutOfBoundsException` but this case should throw `SerialException`. > (test39) > > 2. `pos - 1 + str.length() - offset > this.length() && pos - 1 + length <= this.length()` > The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully. > (test32) > > 3. `pos - 1 + length > this.length()` > The original implementaion throws `SerialException` but this case should end successfully. *3 > (test40) > > 4. `pos == this.length() + 1` > The original implementaion throws `SerialException` but this case should end successfully. *4 > (test41) > > 5. `length < 0` > The original implementation throws `StringIndexOutOfBoundsException` but this case should throw `SerialException`. > (test42) > > 6. `offset + length > Integer.MAX_VALUE` > The original implementation throws `ArrayIndexOutOfBoundsException` (or `OutOfMemoryError` in most cases) but this case should throw `SerialException`. > (test43) > > > The javadoc has also been modified according to the above. > > *1 The documentation of `Blob.setBytes()` says, "If the end of the Blob value is reached while writing the array of bytes, then the length of the Blob value will be increased to accommodate the extra bytes." > > *2 The documentation of `Blob.setBytes()` says, "If the value specified for pos is greater than the length+1 of the BLOB value then the behavior is undefined." > So, it should work correctly when pos == length+1 of the BLOB value. > > *3 The documentation of `Clob.setString()` says, "If the end of the Clob value is eached while writing the given string, then the length of the Clob value will be increased to accommodate the extra characters." > > *4 The documentation of `Clob.setString()` says, "If the value specified for pos is greater than the length+1 of the CLOB value then the behavior is undefined." > So, it should work correctly when pos == length+1 of the CLOB value. This pull request has now been integrated. Changeset: 63b9f8c0 Author: Mitsuru Kariya Committer: Lance Andersen URL: https://git.openjdk.java.net/jdk/commit/63b9f8c0da2ed3634002f0f67b18555826aeddc4 Stats: 262 lines in 4 files changed: 168 ins; 9 del; 85 mod 8153490: Cannot setBytes() if incoming buffer's length is bigger than number of elements we want to insert. Reviewed-by: lancea ------------- PR: https://git.openjdk.java.net/jdk/pull/4001 From duke at openjdk.java.net Thu Oct 28 16:06:37 2021 From: duke at openjdk.java.net (Mitsuru Kariya) Date: Thu, 28 Oct 2021 16:06:37 GMT Subject: RFR: 8153490: Cannot setBytes() if incoming buffer's length is bigger than number of elements we want to insert. [v6] In-Reply-To: References: Message-ID: On Sun, 24 Oct 2021 07:55:01 GMT, Mitsuru Kariya wrote: >> Fix `SerialBlob.setBytes(long pos, byte[] bytes, int offset, int length)` in the following cases: >> >> 1. `pos - 1 + bytes.length - offset > this.length() && pos - 1 + length <= this.length()` >> The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully. >> (test31) >> >> 2. `pos - 1 + length > this.length()` >> The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully. *1 >> (test32) >> >> 3. `pos == this.length() + 1` >> The original implementation throws `SerialException` but this case should end successfully. *2 >> (test33) >> >> 4. `length < 0` >> The original implementation throws `ArrayIndexOutOfBoundsException` but this case should throw `SerialException`. >> (test34) >> >> 5. `offset + length > Integer.MAX_VALUE` >> The original implementation throws `ArrayIndexOutOfBoundsException` (or `OutOfMemoryError` in most cases) but this case should throw `SerialException`. >> (test35) >> >> Additionally, fix `SerialClob.setString(long pos, String str, int offset, int length)` in the following cases: >> >> 1. `offset > str.length()` >> The original implementaion throws `StringIndexOutOfBoundsException` but this case should throw `SerialException`. >> (test39) >> >> 2. `pos - 1 + str.length() - offset > this.length() && pos - 1 + length <= this.length()` >> The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully. >> (test32) >> >> 3. `pos - 1 + length > this.length()` >> The original implementaion throws `SerialException` but this case should end successfully. *3 >> (test40) >> >> 4. `pos == this.length() + 1` >> The original implementaion throws `SerialException` but this case should end successfully. *4 >> (test41) >> >> 5. `length < 0` >> The original implementation throws `StringIndexOutOfBoundsException` but this case should throw `SerialException`. >> (test42) >> >> 6. `offset + length > Integer.MAX_VALUE` >> The original implementation throws `ArrayIndexOutOfBoundsException` (or `OutOfMemoryError` in most cases) but this case should throw `SerialException`. >> (test43) >> >> >> The javadoc has also been modified according to the above. >> >> *1 The documentation of `Blob.setBytes()` says, "If the end of the Blob value is reached while writing the array of bytes, then the length of the Blob value will be increased to accommodate the extra bytes." >> >> *2 The documentation of `Blob.setBytes()` says, "If the value specified for pos is greater than the length+1 of the BLOB value then the behavior is undefined." >> So, it should work correctly when pos == length+1 of the BLOB value. >> >> *3 The documentation of `Clob.setString()` says, "If the end of the Clob value is eached while writing the given string, then the length of the Clob value will be increased to accommodate the extra characters." >> >> *4 The documentation of `Clob.setString()` says, "If the value specified for pos is greater than the length+1 of the CLOB value then the behavior is undefined." >> So, it should work correctly when pos == length+1 of the CLOB value. > > Mitsuru Kariya has updated the pull request 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 JDK-8153490 > - Follow the comment > - Modify javadoc for consistency > - Fix for length + offset > Integer.MAX_VALUE case > - Add check: ensure length >= 0 > - 8153490:Cannot setBytes() if incoming buffer's length is bigger than number of elements we want to insert. > > Fix SerialBlob.setBytes(long pos, byte[] bytes, int offset, int length) in the > following cases: > > 1. pos - 1 + bytes.length - offset > this.length() && pos - 1 + length <= this.length() > The original implementation throws ArrayIndexOutOfBoundsException but this case > should end successfully. > (test31) > > 2. pos - 1 + length > this.length() > The original implementation throws ArrayIndexOutOfBoundsException but this case > should end successfully. *1 > (test32) > > 3. pos == this.length() + 1 > The original implementation throws SerialException but this case should end > successfully. *2 > (test33) > > Additionally, fix SerialClob.setString(long pos, String str, int offset, int length) > in the following cases: > > 1. offset > str.length() > The original implementaion throws StringIndexOutOfBoundsException but this case > should throw SerialException. > (test39) > > 2. pos - 1 + str.length() - offset > this.length() && pos - 1 + length <= this.length() > The original implementation throws ArrayIndexOutOfBoundsException but this case > should end successfully. > (test32) > > 3. pos - 1 + length > this.length() > The original implementaion throws SerialException but this case should end > successfully. *3 > (test40) > > 4. pos == this.length() + 1 > The original implementaion throws SerialException but this case should end > successfully. *4 > (test41) > > The javadoc has also been modified according to the above. > > *1 The documentation of Blob.setBytes() says, "If the end of the Blob value is > reached while writing the array of bytes, then the length of the Blob value > will be increased to accommodate the extra bytes." > > *2 The documentation of Blob.setBytes() says, "If the value specified for pos > is greater than the length+1 of the BLOB value then the behavior is > undefined." > So, it should work correctly when pos == length+1 of the BLOB value. > > *3 The documentation of Clob.setString() says, "If the end of the Clob value is > reached while writing the given string, then the length of the Clob value > will be increased to accommodate the extra characters." > > *4 The documentation of Clob.setString() says, "If the value specified for pos > is greater than the length+1 of the CLOB value then the behavior is > undefined." > So, it should work correctly when pos == length+1 of the CLOB value. Thank you for your cooperation! ------------- PR: https://git.openjdk.java.net/jdk/pull/4001 From mchung at openjdk.java.net Thu Oct 28 16:09:09 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 28 Oct 2021 16:09:09 GMT Subject: RFR: 8275735: [linux] Remove deprecated Metrics api (kernel memory limit) In-Reply-To: <7ZPXxcvf9coOZQFefQf8GQAUgskWHL1dvQkCknWUBUs=.4013d956-3ef7-4f40-8c4f-c0c8578fdae0@github.com> References: <7ZPXxcvf9coOZQFefQf8GQAUgskWHL1dvQkCknWUBUs=.4013d956-3ef7-4f40-8c4f-c0c8578fdae0@github.com> Message-ID: On Thu, 28 Oct 2021 13:03:56 GMT, Severin Gehwolf wrote: > Please review this change to remove some API which no longer works as expected as recent OCI runtimes start to drop support for `--kernel-memory` switch. See the bug for references. This part of the API is not present in hotspot code. > > Testing: Container tests (cgroup v1) on Linux x86_64 (all pass) Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6156 From psandoz at openjdk.java.net Thu Oct 28 17:36:25 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Thu, 28 Oct 2021 17:36:25 GMT Subject: RFR: 8276096: Simplify Unsafe.{load|store}Fence fallbacks by delegating to fullFence In-Reply-To: References: Message-ID: <1XLxQe8x0LZNSMz8I-gJk4SPyaNRVl-dMxPEp0rjIRU=.a088a9d6-83e0-498e-8b90-308a53637f5c@github.com> On Thu, 28 Oct 2021 08:47:31 GMT, Aleksey Shipilev wrote: > `Unsafe.{load|store}Fence` falls back to `unsafe.cpp` for `OrderAccess::{acquire|release}Fence()`. It seems too heavy-handed (useless?) to call to runtime for a single memory barrier. We can simplify the native `Unsafe` interface by falling back to `fullFence` when `{load|store}Fence` intrinsics are not available. This would be similar to what `Unsafe.{loadLoad|storeStore}Fences` do. > > This is the behavior of these intrinsics now, on x86_64, using benchmarks from JDK-8276054: > > > Benchmark Mode Cnt Score Error Units > > # Default > Single.acquire avgt 3 0.407 ? 0.060 ns/op > Single.full avgt 3 4.693 ? 0.005 ns/op > Single.loadLoad avgt 3 0.415 ? 0.095 ns/op > Single.plain avgt 3 0.406 ? 0.002 ns/op > Single.release avgt 3 0.408 ? 0.047 ns/op > Single.storeStore avgt 3 0.408 ? 0.043 ns/op > > # -XX:DisableIntrinsic=_storeFence > Single.acquire avgt 3 0.408 ? 0.016 ns/op > Single.full avgt 3 4.694 ? 0.002 ns/op > Single.loadLoad avgt 3 0.406 ? 0.002 ns/op > Single.plain avgt 3 0.406 ? 0.001 ns/op > Single.release avgt 3 4.694 ? 0.003 ns/op <--- upgraded to full > Single.storeStore avgt 3 4.690 ? 0.005 ns/op <--- upgraded to full > > # -XX:DisableIntrinsic=_loadFence > Single.acquire avgt 3 4.691 ? 0.001 ns/op <--- upgraded to full > Single.full avgt 3 4.693 ? 0.009 ns/op > Single.loadLoad avgt 3 4.693 ? 0.013 ns/op <--- upgraded to full > Single.plain avgt 3 0.408 ? 0.072 ns/op > Single.release avgt 3 0.415 ? 0.016 ns/op > Single.storeStore avgt 3 0.416 ? 0.041 ns/op > > # -XX:DisableIntrinsic=_fullFence > Single.acquire avgt 3 0.406 ? 0.014 ns/op > Single.full avgt 3 15.836 ? 0.151 ns/op <--- calls runtime > Single.loadLoad avgt 3 0.406 ? 0.001 ns/op > Single.plain avgt 3 0.426 ? 0.361 ns/op > Single.release avgt 3 0.407 ? 0.021 ns/op > Single.storeStore avgt 3 0.410 ? 0.061 ns/op > > # -XX:DisableIntrinsic=_fullFence,_loadFence > Single.acquire avgt 3 15.822 ? 0.282 ns/op <--- upgraded, calls runtime > Single.full avgt 3 15.851 ? 0.127 ns/op <--- calls runtime > Single.loadLoad avgt 3 15.829 ? 0.045 ns/op <--- upgraded, calls runtime > Single.plain avgt 3 0.406 ? 0.001 ns/op > Single.release avgt 3 0.414 ? 0.156 ns/op > Single.storeStore avgt 3 0.422 ? 0.452 ns/op > > # -XX:DisableIntrinsic=_fullFence,_storeFence > Single.acquire avgt 3 0.407 ? 0.016 ns/op > Single.full avgt 3 15.347 ? 6.783 ns/op <--- calls runtime > Single.loadLoad avgt 3 0.406 ? 0.001 ns/op > Single.plain avgt 3 0.406 ? 0.002 ns/op > Single.release avgt 3 15.828 ? 0.019 ns/op <--- upgraded, calls runtime > Single.storeStore avgt 3 15.834 ? 0.045 ns/op <--- upgraded, calls runtime > > # -XX:DisableIntrinsic=_fullFence,_loadFence,_storeFence > Single.acquire avgt 3 15.838 ? 0.030 ns/op <--- upgraded, calls runtime > Single.full avgt 3 15.854 ? 0.277 ns/op <--- calls runtime > Single.loadLoad avgt 3 15.826 ? 0.160 ns/op <--- upgraded, calls runtime > Single.plain avgt 3 0.406 ? 0.003 ns/op > Single.release avgt 3 15.838 ? 0.019 ns/op <--- upgraded, calls runtime > Single.storeStore avgt 3 15.844 ? 0.104 ns/op <--- upgraded, calls runtime > > > Additional testing: > - [x] Linux x86_64 fastdebug `tier1` Marked as reviewed by psandoz (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6149 From bpb at openjdk.java.net Thu Oct 28 18:15:33 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 28 Oct 2021 18:15:33 GMT Subject: RFR: 8274750: java/io/File/GetXSpace.java failed: '/dev': 191488 != 190976 [v2] In-Reply-To: <6dZETgaCb3y_013oTmXeAqtD7GCV6Bab_nEehUsdh2U=.ba24c845-5ce6-4774-aac9-cf4f0879799d@github.com> References: <6dZETgaCb3y_013oTmXeAqtD7GCV6Bab_nEehUsdh2U=.ba24c845-5ce6-4774-aac9-cf4f0879799d@github.com> Message-ID: > Please consider this proposed change to ignore comparing the total size of `/dev` as returned by `DF(1)` and `STAT(2)` on macOS. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8274750: Change location of check that file system is not /dev on macOS ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6122/files - new: https://git.openjdk.java.net/jdk/pull/6122/files/80729c5f..c48f3132 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6122&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6122&range=00-01 Stats: 10 lines in 1 file changed: 1 ins; 7 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/6122.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6122/head:pull/6122 PR: https://git.openjdk.java.net/jdk/pull/6122 From bpb at openjdk.java.net Thu Oct 28 18:15:33 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 28 Oct 2021 18:15:33 GMT Subject: RFR: 8274750: java/io/File/GetXSpace.java failed: '/dev': 191488 != 190976 In-Reply-To: <6dZETgaCb3y_013oTmXeAqtD7GCV6Bab_nEehUsdh2U=.ba24c845-5ce6-4774-aac9-cf4f0879799d@github.com> References: <6dZETgaCb3y_013oTmXeAqtD7GCV6Bab_nEehUsdh2U=.ba24c845-5ce6-4774-aac9-cf4f0879799d@github.com> Message-ID: On Tue, 26 Oct 2021 19:00:44 GMT, Brian Burkhalter wrote: > Please consider this proposed change to ignore comparing the total size of `/dev` as returned by `DF(1)` and `STAT(2)` on macOS. Please refer to the issue for more detail, but this change is proposed because the total size of `/dev` can in fact change over time on macOS. Given that `df` and `getTotalSpace()` derive their values at different points in time, there is no way to guarantee that the two values will be equal. ------------- PR: https://git.openjdk.java.net/jdk/pull/6122 From msheppar at openjdk.java.net Thu Oct 28 18:24:19 2021 From: msheppar at openjdk.java.net (Mark Sheppard) Date: Thu, 28 Oct 2021 18:24:19 GMT Subject: RFR: 8275650: Problemlist java/io/File/createTempFile/SpecialTempFile.java for Windows 11 [v3] In-Reply-To: References: Message-ID: On Thu, 28 Oct 2021 15:30:49 GMT, Ivan ?ipka wrote: >> cc @ctornqvi > > Ivan ?ipka has updated the pull request incrementally with one additional commit since the last revision: > > changing os id as per comment from Igor above, the bug id in the problemlist is incorrect, and it should be 8274122 you have used the bugid for this problemlist update ------------- PR: https://git.openjdk.java.net/jdk/pull/6025 From alanb at openjdk.java.net Thu Oct 28 18:27:21 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 28 Oct 2021 18:27:21 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v16] In-Reply-To: References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> Message-ID: <3lN4GfzXkb_cHwKlDtOjH5UxBwa27td2lGYfRfer-5A=.bbe6c1f6-6de6-47bf-9a57-463fb3a37f97@github.com> On Wed, 27 Oct 2021 20:16:54 GMT, Mandy Chung wrote: >> This reimplements core reflection with method handles. >> >> For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. >> >> The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. >> >> The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. >> >> Ran tier1-tier8 tests. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8013527 >> [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 > > Mandy Chung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 43 commits: > > - fix copyright header and typo > - improve documentation of AccessorUtils > - Merge branch 'master' of https://github.com/openjdk/jdk into reimplement-method-invoke > - Fall back to the VM native reflection support if method handle cannot be created > - fix bug id in test > - Merge > - Merge branch 'master' of https://github.com/openjdk/jdk into reimplement-method-invoke > - Merge branch 'master' of https://github.com/openjdk/jdk into reimplement-method-invoke > - Separate paramFlgas into paramCount and flags fields > - Minor cleanup. Improve javadoc in CallerSensitiveAdapter > - ... and 33 more: https://git.openjdk.java.net/jdk/compare/9a3e9542...46cb306b Good work. src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 683: > 681: } else if (val.equals("fields")) { > 682: useDirectMethodHandle = FIELD_MH_ACCESSOR; > 683: } Happy to see that property can be used to control both. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5027 From mchung at openjdk.java.net Thu Oct 28 18:27:22 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 28 Oct 2021 18:27:22 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v16] In-Reply-To: References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> Message-ID: <6iy5JAkLNASrtfHV-Mdzc5g9g-fKvop8Alg2LE4eruo=.b6180ea0-89f3-4b88-b61a-6595bdde4ce7@github.com> On Wed, 27 Oct 2021 20:16:54 GMT, Mandy Chung wrote: >> This reimplements core reflection with method handles. >> >> For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. >> >> The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. >> >> The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. >> >> Ran tier1-tier8 tests. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8013527 >> [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 > > Mandy Chung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 43 commits: > > - fix copyright header and typo > - improve documentation of AccessorUtils > - Merge branch 'master' of https://github.com/openjdk/jdk into reimplement-method-invoke > - Fall back to the VM native reflection support if method handle cannot be created > - fix bug id in test > - Merge > - Merge branch 'master' of https://github.com/openjdk/jdk into reimplement-method-invoke > - Merge branch 'master' of https://github.com/openjdk/jdk into reimplement-method-invoke > - Separate paramFlgas into paramCount and flags fields > - Minor cleanup. Improve javadoc in CallerSensitiveAdapter > - ... and 33 more: https://git.openjdk.java.net/jdk/compare/9a3e9542...46cb306b Thanks all for the review. JEP 416 is now target to JDK 18. I'll integrate this PR today. ------------- PR: https://git.openjdk.java.net/jdk/pull/5027 From mchung at openjdk.java.net Thu Oct 28 18:36:24 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 28 Oct 2021 18:36:24 GMT Subject: Integrated: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle In-Reply-To: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> Message-ID: On Thu, 5 Aug 2021 23:51:13 GMT, Mandy Chung wrote: > This reimplements core reflection with method handles. > > For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. > > The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. > > The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. > > Ran tier1-tier8 tests. > > [1] https://bugs.openjdk.java.net/browse/JDK-8013527 > [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 This pull request has now been integrated. Changeset: c6339cb8 Author: Mandy Chung URL: https://git.openjdk.java.net/jdk/commit/c6339cb8a255d387bb182ad20dd69f3d460cf1ed Stats: 6436 lines in 78 files changed: 5891 ins; 317 del; 228 mod 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle 8013527: calling MethodHandles.lookup on itself leads to errors Co-authored-by: Peter Levart Co-authored-by: Claes Redestad Co-authored-by: Mandy Chung Reviewed-by: mcimadamore, plevart, egahlin, redestad, cjplummer, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/5027 From bpb at openjdk.java.net Thu Oct 28 18:49:08 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 28 Oct 2021 18:49:08 GMT Subject: RFR: 8274750: java/io/File/GetXSpace.java failed: '/dev': 191488 != 190976 [v2] In-Reply-To: References: <6dZETgaCb3y_013oTmXeAqtD7GCV6Bab_nEehUsdh2U=.ba24c845-5ce6-4774-aac9-cf4f0879799d@github.com> <2I7pc6rkAwreIivOk_NeenI07sbLozPpatUD3QecZn8=.82902a28-2869-4ee6-a92a-d10a7e4b42e6@github.com> Message-ID: On Tue, 26 Oct 2021 20:27:47 GMT, Brian Burkhalter wrote: >> test/jdk/java/io/File/GetXSpace.java line 210: >> >>> 208: if (Platform.isOSX() && s.name().equals("/dev")) { >>> 209: out.println("/dev:\n Skipping size comparison for /dev on macOS"); >>> 210: return; >> >> Should it call `pass()`? > > I don't know. As it is skipped it is not exactly passed but ignored. Commit 01 addresses this comment. ------------- PR: https://git.openjdk.java.net/jdk/pull/6122 From rriggs at openjdk.java.net Thu Oct 28 19:36:11 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 28 Oct 2021 19:36:11 GMT Subject: RFR: 8274750: java/io/File/GetXSpace.java failed: '/dev': 191488 != 190976 [v2] In-Reply-To: References: <6dZETgaCb3y_013oTmXeAqtD7GCV6Bab_nEehUsdh2U=.ba24c845-5ce6-4774-aac9-cf4f0879799d@github.com> Message-ID: On Thu, 28 Oct 2021 18:15:33 GMT, Brian Burkhalter wrote: >> Please consider this proposed change to ignore comparing the total size of `/dev` as returned by `DF(1)` and `STAT(2)` on macOS. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8274750: Change location of check that file system is not /dev on macOS LTGM (While you're in there you could suppress the compilation warnings about deprecated SM). ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6122 From naoto at openjdk.java.net Thu Oct 28 19:40:15 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 28 Oct 2021 19:40:15 GMT Subject: RFR: 8274750: java/io/File/GetXSpace.java failed: '/dev': 191488 != 190976 [v2] In-Reply-To: References: <6dZETgaCb3y_013oTmXeAqtD7GCV6Bab_nEehUsdh2U=.ba24c845-5ce6-4774-aac9-cf4f0879799d@github.com> Message-ID: On Thu, 28 Oct 2021 18:15:33 GMT, Brian Burkhalter wrote: >> Please consider this proposed change to ignore comparing the total size of `/dev` as returned by `DF(1)` and `STAT(2)` on macOS. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8274750: Change location of check that file system is not /dev on macOS Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6122 From bpb at openjdk.java.net Thu Oct 28 19:40:16 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 28 Oct 2021 19:40:16 GMT Subject: RFR: 8274750: java/io/File/GetXSpace.java failed: '/dev': 191488 != 190976 [v2] In-Reply-To: References: <6dZETgaCb3y_013oTmXeAqtD7GCV6Bab_nEehUsdh2U=.ba24c845-5ce6-4774-aac9-cf4f0879799d@github.com> Message-ID: On Thu, 28 Oct 2021 19:33:06 GMT, Roger Riggs wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8274750: Change location of check that file system is not /dev on macOS > > LTGM > > (While you're in there you could suppress the compilation warnings about deprecated SM). Good idea, @RogerRiggs , will do. ------------- PR: https://git.openjdk.java.net/jdk/pull/6122 From mchung at openjdk.java.net Thu Oct 28 20:26:47 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 28 Oct 2021 20:26:47 GMT Subject: RFR: JDK-8274848: LambdaMetaFactory::metafactory on REF_invokeSpecial impl method has incorrect behavior [v4] In-Reply-To: References: Message-ID: > Classes compiled prior to the nestmate support will generate `REF_invokeSpecial` if the implementation method is a private instance method. Since a lambda proxy class is a hidden class, a nestmate of the host class, it can invoke the private implementation method but it has to use `REF_invokeVirtual` or `REF_invokeInterface`. In order to support the old classes running on the new runtime, LMF implementation adjusts the reference kind from `REF_invokeSpecial` to `REF_invokeVirtual/REF_invokeInterface`. > > This PR fixes the check properly to ensure the adjustment is only made if the implementation method is private method in the host class. Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: convert to TestNG test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5901/files - new: https://git.openjdk.java.net/jdk/pull/5901/files/c44a5910..980be2b9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5901&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5901&range=02-03 Stats: 35 lines in 1 file changed: 18 ins; 0 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/5901.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5901/head:pull/5901 PR: https://git.openjdk.java.net/jdk/pull/5901 From psandoz at openjdk.java.net Thu Oct 28 20:26:50 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Thu, 28 Oct 2021 20:26:50 GMT Subject: RFR: JDK-8274848: LambdaMetaFactory::metafactory on REF_invokeSpecial impl method has incorrect behavior [v4] In-Reply-To: References: Message-ID: On Thu, 28 Oct 2021 20:23:41 GMT, Mandy Chung wrote: >> Classes compiled prior to the nestmate support will generate `REF_invokeSpecial` if the implementation method is a private instance method. Since a lambda proxy class is a hidden class, a nestmate of the host class, it can invoke the private implementation method but it has to use `REF_invokeVirtual` or `REF_invokeInterface`. In order to support the old classes running on the new runtime, LMF implementation adjusts the reference kind from `REF_invokeSpecial` to `REF_invokeVirtual/REF_invokeInterface`. >> >> This PR fixes the check properly to ensure the adjustment is only made if the implementation method is private method in the host class. > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > convert to TestNG test Marked as reviewed by psandoz (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5901 From dlsmith at openjdk.java.net Thu Oct 28 20:34:14 2021 From: dlsmith at openjdk.java.net (Dan Smith) Date: Thu, 28 Oct 2021 20:34:14 GMT Subject: RFR: JDK-8274848: LambdaMetaFactory::metafactory on REF_invokeSpecial impl method has incorrect behavior [v4] In-Reply-To: References: Message-ID: On Thu, 28 Oct 2021 20:26:47 GMT, Mandy Chung wrote: >> Classes compiled prior to the nestmate support will generate `REF_invokeSpecial` if the implementation method is a private instance method. Since a lambda proxy class is a hidden class, a nestmate of the host class, it can invoke the private implementation method but it has to use `REF_invokeVirtual` or `REF_invokeInterface`. In order to support the old classes running on the new runtime, LMF implementation adjusts the reference kind from `REF_invokeSpecial` to `REF_invokeVirtual/REF_invokeInterface`. >> >> This PR fixes the check properly to ensure the adjustment is only made if the implementation method is private method in the host class. > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > convert to TestNG test Marked as reviewed by dlsmith (Committer). Ahhh, much nicer. Thanks for updating the test. ------------- PR: https://git.openjdk.java.net/jdk/pull/5901 From bpb at openjdk.java.net Thu Oct 28 21:21:38 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 28 Oct 2021 21:21:38 GMT Subject: RFR: 8274750: java/io/File/GetXSpace.java failed: '/dev': 191488 != 190976 [v3] In-Reply-To: <6dZETgaCb3y_013oTmXeAqtD7GCV6Bab_nEehUsdh2U=.ba24c845-5ce6-4774-aac9-cf4f0879799d@github.com> References: <6dZETgaCb3y_013oTmXeAqtD7GCV6Bab_nEehUsdh2U=.ba24c845-5ce6-4774-aac9-cf4f0879799d@github.com> Message-ID: > Please consider this proposed change to ignore comparing the total size of `/dev` as returned by `DF(1)` and `STAT(2)` on macOS. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8274750: Suppress compilation warning about SecurityManager deprecation for removal ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6122/files - new: https://git.openjdk.java.net/jdk/pull/6122/files/c48f3132..03c4b908 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6122&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6122&range=01-02 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6122.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6122/head:pull/6122 PR: https://git.openjdk.java.net/jdk/pull/6122 From rriggs at openjdk.java.net Thu Oct 28 21:26:13 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 28 Oct 2021 21:26:13 GMT Subject: RFR: 8274750: java/io/File/GetXSpace.java failed: '/dev': 191488 != 190976 [v3] In-Reply-To: References: <6dZETgaCb3y_013oTmXeAqtD7GCV6Bab_nEehUsdh2U=.ba24c845-5ce6-4774-aac9-cf4f0879799d@github.com> Message-ID: On Thu, 28 Oct 2021 21:21:38 GMT, Brian Burkhalter wrote: >> Please consider this proposed change to ignore comparing the total size of `/dev` as returned by `DF(1)` and `STAT(2)` on macOS. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8274750: Suppress compilation warning about SecurityManager deprecation for removal Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6122 From isipka at openjdk.java.net Thu Oct 28 22:08:07 2021 From: isipka at openjdk.java.net (Ivan =?UTF-8?B?xaBpcGth?=) Date: Thu, 28 Oct 2021 22:08:07 GMT Subject: RFR: 8275650: Problemlist java/io/File/createTempFile/SpecialTempFile.java for Windows 11 [v2] In-Reply-To: References: Message-ID: On Tue, 26 Oct 2021 20:59:45 GMT, Igor Ignatyev wrote: >> Ivan ?ipka has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: >> >> - fixed OS identifier >> - 8274122: added to problem list > > And now you use an incorrect bug id in the problem list, it should be 8274122 Thank you @iignatev @bplb @msheppar. Problem listing the test works as expected details in ticket comment. ------------- PR: https://git.openjdk.java.net/jdk/pull/6025 From mchung at openjdk.java.net Thu Oct 28 22:28:24 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 28 Oct 2021 22:28:24 GMT Subject: Integrated: JDK-8274848: LambdaMetaFactory::metafactory on REF_invokeSpecial impl method has incorrect behavior In-Reply-To: References: Message-ID: <3jhWkQwp0w5JLcWKFv_OFoR2D5txTf9rwjQTl8UqArI=.02a8dcc6-ecba-4266-9b31-40b622231f85@github.com> On Mon, 11 Oct 2021 20:55:23 GMT, Mandy Chung wrote: > Classes compiled prior to the nestmate support will generate `REF_invokeSpecial` if the implementation method is a private instance method. Since a lambda proxy class is a hidden class, a nestmate of the host class, it can invoke the private implementation method but it has to use `REF_invokeVirtual` or `REF_invokeInterface`. In order to support the old classes running on the new runtime, LMF implementation adjusts the reference kind from `REF_invokeSpecial` to `REF_invokeVirtual/REF_invokeInterface`. > > This PR fixes the check properly to ensure the adjustment is only made if the implementation method is private method in the host class. This pull request has now been integrated. Changeset: 21da2183 Author: Mandy Chung URL: https://git.openjdk.java.net/jdk/commit/21da2183875feca3dbf4f1bd875b268a7fc8d560 Stats: 136 lines in 2 files changed: 135 ins; 0 del; 1 mod 8274848: LambdaMetaFactory::metafactory on REF_invokeSpecial impl method has incorrect behavior Reviewed-by: psandoz, dlsmith ------------- PR: https://git.openjdk.java.net/jdk/pull/5901 From isipka at openjdk.java.net Thu Oct 28 22:43:48 2021 From: isipka at openjdk.java.net (Ivan =?UTF-8?B?xaBpcGth?=) Date: Thu, 28 Oct 2021 22:43:48 GMT Subject: RFR: 8274122: Problemlist java/io/File/createTempFile/SpecialTempFile.java for Windows 11 [v4] In-Reply-To: References: Message-ID: > cc @ctornqvi Ivan ?ipka has updated the pull request incrementally with one additional commit since the last revision: fixed bugid ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6025/files - new: https://git.openjdk.java.net/jdk/pull/6025/files/97d000a0..f5ea03fa Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6025&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6025&range=02-03 Stats: 16 lines in 3 files changed: 15 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6025.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6025/head:pull/6025 PR: https://git.openjdk.java.net/jdk/pull/6025 From jpai at openjdk.java.net Fri Oct 29 04:19:49 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Fri, 29 Oct 2021 04:19:49 GMT Subject: RFR: 8275509: ModuleDescriptor.hashCode isn't reproducible across builds [v5] In-Reply-To: References: Message-ID: <94CX2gXE0-2LHg6NH-TNpbbC7-DjZt5NVOE3F5AWWh8=.b0824feb-912f-48bb-a0e7-a0ca691ae0b4@github.com> > Can I please get a review for this change which fixes the issue reported in https://bugs.openjdk.java.net/browse/JDK-8275509? > > The `ModuleDescriptor.hashCode()` method uses the hash code of its various components to compute the final hash code. While doing so it ends up calling hashCode() on (collection of) various `enum` types. Since the hashCode() of enum types is generated from a call to `java.lang.Object.hashCode()`, their value isn't guaranteed to stay the same across multiple JVM runs. > > The commit here proposes to use the ordinal of the enum as the hash code. As Alan notes in the mailing list discussion, any changes to the ordinal of the enum (either due to addition of new value, removal of a value or just reordering existing values, all of which I think will be rare in these specific enum types) isn't expected to produce the same hash code across those changed runtimes and that should be okay. > > The rest of the ModuleDescriptor.hashCode() has been reviewed too and apart from calls to the enum types hashCode(), rest of the calls in that implementation, either directly or indirectly end up as calls on `java.lang.String.hashCode()` and as such aren't expected to cause non-deterministic values. > > A new jtreg test has been added to reproduce this issue and verify the fix. Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: remove commented out TODO in test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6078/files - new: https://git.openjdk.java.net/jdk/pull/6078/files/006255d9..60deab10 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6078&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6078&range=03-04 Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6078.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6078/head:pull/6078 PR: https://git.openjdk.java.net/jdk/pull/6078 From jpai at openjdk.java.net Fri Oct 29 04:22:14 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Fri, 29 Oct 2021 04:22:14 GMT Subject: RFR: 8275509: ModuleDescriptor.hashCode isn't reproducible across builds [v4] In-Reply-To: References: Message-ID: On Mon, 25 Oct 2021 09:21:28 GMT, Jaikiran Pai wrote: >> Can I please get a review for this change which fixes the issue reported in https://bugs.openjdk.java.net/browse/JDK-8275509? >> >> The `ModuleDescriptor.hashCode()` method uses the hash code of its various components to compute the final hash code. While doing so it ends up calling hashCode() on (collection of) various `enum` types. Since the hashCode() of enum types is generated from a call to `java.lang.Object.hashCode()`, their value isn't guaranteed to stay the same across multiple JVM runs. >> >> The commit here proposes to use the ordinal of the enum as the hash code. As Alan notes in the mailing list discussion, any changes to the ordinal of the enum (either due to addition of new value, removal of a value or just reordering existing values, all of which I think will be rare in these specific enum types) isn't expected to produce the same hash code across those changed runtimes and that should be okay. >> >> The rest of the ModuleDescriptor.hashCode() has been reviewed too and apart from calls to the enum types hashCode(), rest of the calls in that implementation, either directly or indirectly end up as calls on `java.lang.String.hashCode()` and as such aren't expected to cause non-deterministic values. >> >> A new jtreg test has been added to reproduce this issue and verify the fix. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > add newline at end of test class Hello Alan, > I'd prefer not have commented out "TODO" code if possible. Done. I've updated the PR to remove that TODO. > I think the test will need a round or two of clean-up to get it more consistent with the existing naming and style of tests in this area.? Do you mean the jtreg `driver` style this test is using? I used it because it was necessary to compare output (the hashCode value) between multiple JVM runs. I use the `driver` along with the `ProcessBuilder` to capture the output between multiple JVM runs and compare those. ------------- PR: https://git.openjdk.java.net/jdk/pull/6078 From ysatowse at openjdk.java.net Fri Oct 29 05:03:43 2021 From: ysatowse at openjdk.java.net (Yoshiki Sato) Date: Fri, 29 Oct 2021 05:03:43 GMT Subject: RFR: 8275766: (tz) Update Timezone Data to 2021e Message-ID: Please review the integration of tzdata2021e (including tzdata2021d) to the JDK. The fix has passed all relevant JTREG regression tests and JCK tests. 8275754: (tz) Update Timezone Data to 2021d 8275849: TestZoneInfo310.java fails with tzdata2021e ------------- Commit messages: - 8275754: (tz) Update Timezone Data to 2021d Changes: https://git.openjdk.java.net/jdk/pull/6144/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6144&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275766 Stats: 52 lines in 6 files changed: 29 ins; 6 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/6144.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6144/head:pull/6144 PR: https://git.openjdk.java.net/jdk/pull/6144 From naoto at openjdk.java.net Fri Oct 29 05:03:43 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 29 Oct 2021 05:03:43 GMT Subject: RFR: 8275766: (tz) Update Timezone Data to 2021e In-Reply-To: References: Message-ID: On Thu, 28 Oct 2021 01:02:27 GMT, Yoshiki Sato wrote: > Please review the integration of tzdata2021e (including tzdata2021d) to the JDK. > The fix has passed all relevant JTREG regression tests and JCK tests. > > 8275754: (tz) Update Timezone Data to 2021d > 8275849: TestZoneInfo310.java fails with tzdata2021e Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6144 From serb at openjdk.java.net Fri Oct 29 05:47:10 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 29 Oct 2021 05:47:10 GMT Subject: RFR: 8273101: Eliminate the usage of threadgroup sandboxing in the java.util.logging In-Reply-To: References: Message-ID: On Wed, 1 Sep 2021 06:31:16 GMT, Sergey Bylokhov wrote: > At the time Java supported applets and webstart, a special mechanism for launching various applications in one JVM was used to reduce memory usage and each application was isolated from each other. > > This isolation was implemented via ThreadGroups where each application created its own thread group and all data for the application was stored in the context of its own group. > > Some parts of the JDK used ThreadGroups directly, others used special classes like sun.awt.AppContext. > > Such sandboxing became useless since the plugin and webstart are no longer supported and were removed in jdk11. > > Note that this is just a first step for the overall cleanup, here is my plan: > 1. Cleanup the usage of AppContext in the ?java.util.logging.LogManager" class in the java.base module. > 2. Cleanup the usage of TheadGroup in the JavaSound > 3. Cleanup the usage of TheadGroup in the JavaBeans > 4. Cleanup the usage of AppContext in the Swing > 5. Cleanup the usage of AppContext in the AWT > 6. Delete the AppContext class. > > The current PR is for the first step. So this is the request to delete the usage of AppContext in the LogManager and related tests. > > Tested by tier1/tier2/tier3 and jdk_desktop tests. Does anybody have any other suggestions? ------------- PR: https://git.openjdk.java.net/jdk/pull/5326 From iris at openjdk.java.net Fri Oct 29 06:39:10 2021 From: iris at openjdk.java.net (Iris Clark) Date: Fri, 29 Oct 2021 06:39:10 GMT Subject: RFR: 8275766: (tz) Update Timezone Data to 2021e In-Reply-To: References: Message-ID: On Thu, 28 Oct 2021 01:02:27 GMT, Yoshiki Sato wrote: > Please review the integration of tzdata2021e (including tzdata2021d) to the JDK. > The fix has passed all relevant JTREG regression tests and JCK tests. > > 8275754: (tz) Update Timezone Data to 2021d > 8275849: TestZoneInfo310.java fails with tzdata2021e Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6144 From serb at openjdk.java.net Fri Oct 29 07:08:10 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 29 Oct 2021 07:08:10 GMT Subject: RFR: 8262297: ImageIO.write() method will throw IndexOutOfBoundsException In-Reply-To: <0OrjZzeb7XifWJIH2jmrFAXflWPbagiJN7QvT8LA7XU=.dfb665f3-70c7-40c6-ba19-5b945337c446@github.com> References: <0OrjZzeb7XifWJIH2jmrFAXflWPbagiJN7QvT8LA7XU=.dfb665f3-70c7-40c6-ba19-5b945337c446@github.com> Message-ID: <_OEX7MVVvmpNuJ_huZyibp5iboMLLQAtsfi9Y5NAWnA=.2185e9c7-e33e-4308-a805-8acfaee39e1c@github.com> On Thu, 28 Oct 2021 14:30:20 GMT, Alan Bateman wrote: >> Could you please review the 8262297 bug fixes? >> >> In this case, ImageIO.write() should throw java.io.IOException rather than java.lang.IndexOutOfBoundsException. IndexOutOfBoundsException is caught and wrapped in IIOException in ImageIO.write() with this fix. In addition, IndexOutOfBoundsException is not expected to throw by RandomAccessFile#write() according to its API specification. So it should be fixed. > > src/java.base/share/classes/java/io/RandomAccessFile.java line 558: > >> 556: * @throws IndexOutOfBoundsException If {@code off} is negative, >> 557: * {@code len} is negative, or {@code len} is greater than >> 558: * {@code b.length - off} > > The IOOBE is specified in the super interface, it's just not shown in the javadoc because it's a runtime exception. So I think what you want here is: > > @throws IndexOutOfBoundsException {@inheritDoc} Unfortunately the parent class does not specify this exception via javadoc tags like "@throws IndexOutOfBoundsException", but instead just describe it in the method description should we fix it separately from the imageio fix? ------------- PR: https://git.openjdk.java.net/jdk/pull/6151 From alanb at openjdk.java.net Fri Oct 29 07:16:14 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 29 Oct 2021 07:16:14 GMT Subject: RFR: 8262297: ImageIO.write() method will throw IndexOutOfBoundsException In-Reply-To: <_OEX7MVVvmpNuJ_huZyibp5iboMLLQAtsfi9Y5NAWnA=.2185e9c7-e33e-4308-a805-8acfaee39e1c@github.com> References: <0OrjZzeb7XifWJIH2jmrFAXflWPbagiJN7QvT8LA7XU=.dfb665f3-70c7-40c6-ba19-5b945337c446@github.com> <_OEX7MVVvmpNuJ_huZyibp5iboMLLQAtsfi9Y5NAWnA=.2185e9c7-e33e-4308-a805-8acfaee39e1c@github.com> Message-ID: On Fri, 29 Oct 2021 07:01:04 GMT, Sergey Bylokhov wrote: > Unfortunately the parent class does not specify this exception via javadoc tags like "@throws IndexOutOfBoundsException", but instead just describe it in the method description > > should we fix it separately from the imageio fix? Yes, it might be better to separate them because we'll like need a CSR if we are missing @throws in a few places. ------------- PR: https://git.openjdk.java.net/jdk/pull/6151 From prr at openjdk.java.net Fri Oct 29 07:35:11 2021 From: prr at openjdk.java.net (Phil Race) Date: Fri, 29 Oct 2021 07:35:11 GMT Subject: RFR: 8262297: ImageIO.write() method will throw IndexOutOfBoundsException In-Reply-To: References: Message-ID: <3wcxnoPDynz6rpC7AkYvZyJhxPVMiVCS3j-ZTmuHuh4=.de6ee1b1-baa6-4015-b22a-089ad70af582@github.com> On Thu, 28 Oct 2021 09:29:13 GMT, Masanori Yano wrote: > Could you please review the 8262297 bug fixes? > > In this case, ImageIO.write() should throw java.io.IOException rather than java.lang.IndexOutOfBoundsException. IndexOutOfBoundsException is caught and wrapped in IIOException in ImageIO.write() with this fix. In addition, IndexOutOfBoundsException is not expected to throw by RandomAccessFile#write() according to its API specification. So it should be fixed. This needs looking at closely .. I don't know what's best but the imaging APIs are very exception heavy because of the arrays, indices, you name it that they consume. Most of the time its probably best for an IIO user to just get an IIOException wrapping the original cause. But there could be exceptions. ------------- PR: https://git.openjdk.java.net/jdk/pull/6151 From jboes at openjdk.java.net Fri Oct 29 08:08:15 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Fri, 29 Oct 2021 08:08:15 GMT Subject: RFR: 8276102: JDK-8245095 integration reverted JDK-8247980 In-Reply-To: References: Message-ID: On Thu, 28 Oct 2021 11:13:57 GMT, Aleksey Shipilev wrote: > See the [integration commit](https://github.com/openjdk/jdk/commit/9d191fce55fa70d6a2affc724fad57b0e20e4bde#diff-5b9b15832385ab8e02ffca3ddef6d65a9dea73f45abbe5e4f0be561be02073ffR30 > ) for JDK-8245095. It reintroduced `java/util/stream` in `exclusiveAccess.dirs`, which effectively reverts JDK-8247980. I noticed this because jdk:tier1 became slow again. > > @FrauBoes, that was not intentional, right? > > The solution is to drop `java/util/stream` again. > > Additional testing: > - [x] Linux x86_64 fastdebug `jdk:tier1` tests are fast again That was definitely not intentional, thanks for spotting @shipilev! ------------- PR: https://git.openjdk.java.net/jdk/pull/6153 From dfuchs at openjdk.java.net Fri Oct 29 09:03:08 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 29 Oct 2021 09:03:08 GMT Subject: RFR: 8276102: JDK-8245095 integration reverted JDK-8247980 In-Reply-To: References: Message-ID: On Thu, 28 Oct 2021 11:13:57 GMT, Aleksey Shipilev wrote: > See the [integration commit](https://github.com/openjdk/jdk/commit/9d191fce55fa70d6a2affc724fad57b0e20e4bde#diff-5b9b15832385ab8e02ffca3ddef6d65a9dea73f45abbe5e4f0be561be02073ffR30 > ) for JDK-8245095. It reintroduced `java/util/stream` in `exclusiveAccess.dirs`, which effectively reverts JDK-8247980. I noticed this because jdk:tier1 became slow again. > > @FrauBoes, that was not intentional, right? > > The solution is to drop `java/util/stream` again. > > Additional testing: > - [x] Linux x86_64 fastdebug `jdk:tier1` tests are fast again Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6153 From redestad at openjdk.java.net Fri Oct 29 09:10:09 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 29 Oct 2021 09:10:09 GMT Subject: RFR: 8276102: JDK-8245095 integration reverted JDK-8247980 In-Reply-To: References: Message-ID: On Thu, 28 Oct 2021 11:13:57 GMT, Aleksey Shipilev wrote: > See the [integration commit](https://github.com/openjdk/jdk/commit/9d191fce55fa70d6a2affc724fad57b0e20e4bde#diff-5b9b15832385ab8e02ffca3ddef6d65a9dea73f45abbe5e4f0be561be02073ffR30 > ) for JDK-8245095. It reintroduced `java/util/stream` in `exclusiveAccess.dirs`, which effectively reverts JDK-8247980. I noticed this because jdk:tier1 became slow again. > > @FrauBoes, that was not intentional, right? > > The solution is to drop `java/util/stream` again. > > Additional testing: > - [x] Linux x86_64 fastdebug `jdk:tier1` tests are fast again Marked as reviewed by redestad (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6153 From myano at openjdk.java.net Fri Oct 29 09:32:14 2021 From: myano at openjdk.java.net (Masanori Yano) Date: Fri, 29 Oct 2021 09:32:14 GMT Subject: RFR: 8262297: ImageIO.write() method will throw IndexOutOfBoundsException In-Reply-To: References: <0OrjZzeb7XifWJIH2jmrFAXflWPbagiJN7QvT8LA7XU=.dfb665f3-70c7-40c6-ba19-5b945337c446@github.com> <_OEX7MVVvmpNuJ_huZyibp5iboMLLQAtsfi9Y5NAWnA=.2185e9c7-e33e-4308-a805-8acfaee39e1c@github.com> Message-ID: <8My9Dw1ePGmnvCilFii5I7GWt3YjwW8kiDL2xATr4pU=.d6e738c4-a7a7-4f44-8458-272e40fe96fe@github.com> On Fri, 29 Oct 2021 07:13:32 GMT, Alan Bateman wrote: >> Unfortunately the parent class does not specify this exception via javadoc tags like "@throws IndexOutOfBoundsException", but instead just describe it in the method description >> >> should we fix it separately from the imageio fix? > >> Unfortunately the parent class does not specify this exception via javadoc tags like "@throws IndexOutOfBoundsException", but instead just describe it in the method description >> >> should we fix it separately from the imageio fix? > > Yes, it might be better to separate them because we'll like need a CSR if we are missing @throws in a few places. I understood to separate javadoc fix. I will remove the javadoc fix from this PR and issue another Bug ID. ------------- PR: https://git.openjdk.java.net/jdk/pull/6151 From myano at openjdk.java.net Fri Oct 29 09:36:37 2021 From: myano at openjdk.java.net (Masanori Yano) Date: Fri, 29 Oct 2021 09:36:37 GMT Subject: RFR: 8262297: ImageIO.write() method will throw IndexOutOfBoundsException [v2] In-Reply-To: References: Message-ID: > Could you please review the 8262297 bug fixes? > > In this case, ImageIO.write() should throw java.io.IOException rather than java.lang.IndexOutOfBoundsException. IndexOutOfBoundsException is caught and wrapped in IIOException in ImageIO.write() with this fix. In addition, IndexOutOfBoundsException is not expected to throw by RandomAccessFile#write() according to its API specification. So it should be fixed. Masanori Yano has updated the pull request incrementally with one additional commit since the last revision: 8262297: ImageIO.write() method will throw IndexOutOfBoundsException ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6151/files - new: https://git.openjdk.java.net/jdk/pull/6151/files/d6a652fa..08b54fff Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6151&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6151&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6151.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6151/head:pull/6151 PR: https://git.openjdk.java.net/jdk/pull/6151 From aph at openjdk.java.net Fri Oct 29 09:54:14 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Fri, 29 Oct 2021 09:54:14 GMT Subject: RFR: 8276096: Simplify Unsafe.{load|store}Fence fallbacks by delegating to fullFence In-Reply-To: References: Message-ID: On Thu, 28 Oct 2021 08:47:31 GMT, Aleksey Shipilev wrote: > `Unsafe.{load|store}Fence` falls back to `unsafe.cpp` for `OrderAccess::{acquire|release}Fence()`. It seems too heavy-handed (useless?) to call to runtime for a single memory barrier. We can simplify the native `Unsafe` interface by falling back to `fullFence` when `{load|store}Fence` intrinsics are not available. This would be similar to what `Unsafe.{loadLoad|storeStore}Fences` do. > > This is the behavior of these intrinsics now, on x86_64, using benchmarks from JDK-8276054: > > > Benchmark Mode Cnt Score Error Units > > # Default > Single.acquire avgt 3 0.407 ? 0.060 ns/op > Single.full avgt 3 4.693 ? 0.005 ns/op > Single.loadLoad avgt 3 0.415 ? 0.095 ns/op > Single.plain avgt 3 0.406 ? 0.002 ns/op > Single.release avgt 3 0.408 ? 0.047 ns/op > Single.storeStore avgt 3 0.408 ? 0.043 ns/op > > # -XX:DisableIntrinsic=_storeFence > Single.acquire avgt 3 0.408 ? 0.016 ns/op > Single.full avgt 3 4.694 ? 0.002 ns/op > Single.loadLoad avgt 3 0.406 ? 0.002 ns/op > Single.plain avgt 3 0.406 ? 0.001 ns/op > Single.release avgt 3 4.694 ? 0.003 ns/op <--- upgraded to full > Single.storeStore avgt 3 4.690 ? 0.005 ns/op <--- upgraded to full > > # -XX:DisableIntrinsic=_loadFence > Single.acquire avgt 3 4.691 ? 0.001 ns/op <--- upgraded to full > Single.full avgt 3 4.693 ? 0.009 ns/op > Single.loadLoad avgt 3 4.693 ? 0.013 ns/op <--- upgraded to full > Single.plain avgt 3 0.408 ? 0.072 ns/op > Single.release avgt 3 0.415 ? 0.016 ns/op > Single.storeStore avgt 3 0.416 ? 0.041 ns/op > > # -XX:DisableIntrinsic=_fullFence > Single.acquire avgt 3 0.406 ? 0.014 ns/op > Single.full avgt 3 15.836 ? 0.151 ns/op <--- calls runtime > Single.loadLoad avgt 3 0.406 ? 0.001 ns/op > Single.plain avgt 3 0.426 ? 0.361 ns/op > Single.release avgt 3 0.407 ? 0.021 ns/op > Single.storeStore avgt 3 0.410 ? 0.061 ns/op > > # -XX:DisableIntrinsic=_fullFence,_loadFence > Single.acquire avgt 3 15.822 ? 0.282 ns/op <--- upgraded, calls runtime > Single.full avgt 3 15.851 ? 0.127 ns/op <--- calls runtime > Single.loadLoad avgt 3 15.829 ? 0.045 ns/op <--- upgraded, calls runtime > Single.plain avgt 3 0.406 ? 0.001 ns/op > Single.release avgt 3 0.414 ? 0.156 ns/op > Single.storeStore avgt 3 0.422 ? 0.452 ns/op > > # -XX:DisableIntrinsic=_fullFence,_storeFence > Single.acquire avgt 3 0.407 ? 0.016 ns/op > Single.full avgt 3 15.347 ? 6.783 ns/op <--- calls runtime > Single.loadLoad avgt 3 0.406 ? 0.001 ns/op > Single.plain avgt 3 0.406 ? 0.002 ns/op > Single.release avgt 3 15.828 ? 0.019 ns/op <--- upgraded, calls runtime > Single.storeStore avgt 3 15.834 ? 0.045 ns/op <--- upgraded, calls runtime > > # -XX:DisableIntrinsic=_fullFence,_loadFence,_storeFence > Single.acquire avgt 3 15.838 ? 0.030 ns/op <--- upgraded, calls runtime > Single.full avgt 3 15.854 ? 0.277 ns/op <--- calls runtime > Single.loadLoad avgt 3 15.826 ? 0.160 ns/op <--- upgraded, calls runtime > Single.plain avgt 3 0.406 ? 0.003 ns/op > Single.release avgt 3 15.838 ? 0.019 ns/op <--- upgraded, calls runtime > Single.storeStore avgt 3 15.844 ? 0.104 ns/op <--- upgraded, calls runtime > > > Additional testing: > - [x] Linux x86_64 fastdebug `tier1` Marked as reviewed by aph (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6149 From shade at openjdk.java.net Fri Oct 29 10:29:18 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 29 Oct 2021 10:29:18 GMT Subject: RFR: 8276102: JDK-8245095 integration reverted JDK-8247980 In-Reply-To: References: Message-ID: <-M94Voz01Or3o58XloJiJI8Hnczq5LQqBziq1Nvj3XA=.2a03d0f2-5cea-40f8-af1b-ea359e14525d@github.com> On Thu, 28 Oct 2021 11:13:57 GMT, Aleksey Shipilev wrote: > See the [integration commit](https://github.com/openjdk/jdk/commit/9d191fce55fa70d6a2affc724fad57b0e20e4bde#diff-5b9b15832385ab8e02ffca3ddef6d65a9dea73f45abbe5e4f0be561be02073ffR30 > ) for JDK-8245095. It reintroduced `java/util/stream` in `exclusiveAccess.dirs`, which effectively reverts JDK-8247980. I noticed this because jdk:tier1 became slow again. > > @FrauBoes, that was not intentional, right? > > The solution is to drop `java/util/stream` again. > > Additional testing: > - [x] Linux x86_64 fastdebug `jdk:tier1` tests are fast again All right, thanks for reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/6153 From shade at openjdk.java.net Fri Oct 29 10:29:18 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 29 Oct 2021 10:29:18 GMT Subject: Integrated: 8276102: JDK-8245095 integration reverted JDK-8247980 In-Reply-To: References: Message-ID: On Thu, 28 Oct 2021 11:13:57 GMT, Aleksey Shipilev wrote: > See the [integration commit](https://github.com/openjdk/jdk/commit/9d191fce55fa70d6a2affc724fad57b0e20e4bde#diff-5b9b15832385ab8e02ffca3ddef6d65a9dea73f45abbe5e4f0be561be02073ffR30 > ) for JDK-8245095. It reintroduced `java/util/stream` in `exclusiveAccess.dirs`, which effectively reverts JDK-8247980. I noticed this because jdk:tier1 became slow again. > > @FrauBoes, that was not intentional, right? > > The solution is to drop `java/util/stream` again. > > Additional testing: > - [x] Linux x86_64 fastdebug `jdk:tier1` tests are fast again This pull request has now been integrated. Changeset: 15fd8a30 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/15fd8a300b503fada7611004b5cb1bda6ecc292e Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8276102: JDK-8245095 integration reverted JDK-8247980 Reviewed-by: dfuchs, redestad ------------- PR: https://git.openjdk.java.net/jdk/pull/6153 From whuang at openjdk.java.net Fri Oct 29 10:34:16 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Fri, 29 Oct 2021 10:34:16 GMT Subject: RFR: 8252990: Intrinsify Unsafe.storeStoreFence [v2] In-Reply-To: References: Message-ID: On Thu, 28 Oct 2021 08:58:48 GMT, Aleksey Shipilev wrote: >> `Unsafe.storeStoreFence` currently delegates to stronger `Unsafe.storeFence`. We can teach compilers to map this directly to already existing rules that handle `MemBarStoreStore`. Like explicit `LoadFence`/`StoreFence`, we introduce the special node to differentiate explicit fence and implicit store-store barriers. `storeStoreFence` is usually used to simulate safe `final`-field like constructions in special JDK classes, like `ConstantCallSite` and friends. >> >> Motivational performance difference on benchmarks from JDK-8276054 on ARM32: >> >> >> Benchmark Mode Cnt Score Error Units >> Multiple.plain avgt 3 2.669 ? 0.004 ns/op >> Multiple.release avgt 3 16.688 ? 0.057 ns/op >> Multiple.storeStore avgt 3 14.021 ? 0.144 ns/op // Better >> >> MultipleWithLoads.plain avgt 3 4.672 ? 0.053 ns/op >> MultipleWithLoads.release avgt 3 16.689 ? 0.044 ns/op >> MultipleWithLoads.storeStore avgt 3 14.012 ? 0.010 ns/op // Better >> >> MultipleWithStores.plain avgt 3 14.687 ? 0.009 ns/op >> MultipleWithStores.release avgt 3 45.393 ? 0.192 ns/op >> MultipleWithStores.storeStore avgt 3 38.048 ? 0.033 ns/op // Better >> >> Publishing.plain avgt 3 27.079 ? 0.201 ns/op >> Publishing.release avgt 3 27.088 ? 0.241 ns/op >> Publishing.storeStore avgt 3 27.009 ? 0.259 ns/op // Within error, hidden by allocation >> >> Single.plain avgt 3 2.670 ? 0.002 ns/op >> Single.releaseFence avgt 3 6.675 ? 0.001 ns/op >> Single.storeStoreFence avgt 3 8.012 ? 0.027 ns/op // Worse, seems to be ARM32 implementation artifact >> >> >> As expected, this does not affect x86_64 at all, because both `release` and `storeStore` are effectively no-ops, only affecting compiler optimizations: >> >> >> Benchmark Mode Cnt Score Error Units >> >> Multiple.plain avgt 3 0.406 ? 0.002 ns/op >> Multiple.release avgt 3 0.409 ? 0.018 ns/op >> Multiple.storeStore avgt 3 0.406 ? 0.001 ns/op >> >> MultipleWithLoads.plain avgt 3 4.328 ? 0.006 ns/op >> MultipleWithLoads.release avgt 3 4.600 ? 0.014 ns/op >> MultipleWithLoads.storeStore avgt 3 4.602 ? 0.006 ns/op >> >> MultipleWithStores.plain avgt 3 0.812 ? 0.001 ns/op >> MultipleWithStores.release avgt 3 0.812 ? 0.002 ns/op >> MultipleWithStores.storeStore avgt 3 0.812 ? 0.002 ns/op >> >> Publishing.plain avgt 3 6.370 ? 0.059 ns/op >> Publishing.release avgt 3 6.358 ? 0.436 ns/op >> Publishing.storeStore avgt 3 6.367 ? 0.054 ns/op >> >> Single.plain avgt 3 0.407 ? 0.039 ns/op >> Single.releaseFence avgt 3 0.406 ? 0.001 ns/op >> Single.storeStoreFence avgt 3 0.406 ? 0.001 ns/op >> >> >> Additional testing: >> - [x] Linux x86_64 fastdebug `tier1` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Fix the comment to match JDK-8276096 LGTM ------------- Marked as reviewed by whuang (Author). PR: https://git.openjdk.java.net/jdk/pull/6136 From isipka at openjdk.java.net Fri Oct 29 10:38:41 2021 From: isipka at openjdk.java.net (Ivan =?UTF-8?B?xaBpcGth?=) Date: Fri, 29 Oct 2021 10:38:41 GMT Subject: RFR: 8274122: Problemlist java/io/File/createTempFile/SpecialTempFile.java for Windows 11 [v5] In-Reply-To: References: Message-ID: > cc @ctornqvi Ivan ?ipka has updated the pull request incrementally with one additional commit since the last revision: removed file added by accident ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6025/files - new: https://git.openjdk.java.net/jdk/pull/6025/files/f5ea03fa..d29620d1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6025&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6025&range=03-04 Stats: 15 lines in 1 file changed: 0 ins; 15 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6025.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6025/head:pull/6025 PR: https://git.openjdk.java.net/jdk/pull/6025 From isipka at openjdk.java.net Fri Oct 29 10:41:09 2021 From: isipka at openjdk.java.net (Ivan =?UTF-8?B?xaBpcGth?=) Date: Fri, 29 Oct 2021 10:41:09 GMT Subject: RFR: 8274122: Problemlist java/io/File/createTempFile/SpecialTempFile.java for Windows 11 [v3] In-Reply-To: References: Message-ID: <_J5rrElv_lU_IF60Id2CXYkQVoOXH53WqzsCw2i9KI0=.819372b7-4597-4e24-8ae7-0be656b2e58e@github.com> On Thu, 28 Oct 2021 18:21:29 GMT, Mark Sheppard wrote: > as per comment from Igor above, the bug id in the problemlist is incorrect, and it should be 8274122 you have used the bugid for this problemlist update @msheppar the bug id has been updated ------------- PR: https://git.openjdk.java.net/jdk/pull/6025 From myano at openjdk.java.net Fri Oct 29 10:45:30 2021 From: myano at openjdk.java.net (Masanori Yano) Date: Fri, 29 Oct 2021 10:45:30 GMT Subject: RFR: 8276164: RandomAccessFile#write method could throw IndexOutOfBoundsException that is not described in javadoc Message-ID: Could you please review the 8276164 bug fixes? I suggest adding the missing javadoc of `@throws IndexOutOfBoundsException`. ------------- Commit messages: - 8276164: RandomAccessFile#write method could throw IndexOutOfBoundsException that is not described in javadoc Changes: https://git.openjdk.java.net/jdk/pull/6168/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6168&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276164 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6168.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6168/head:pull/6168 PR: https://git.openjdk.java.net/jdk/pull/6168 From msheppar at openjdk.java.net Fri Oct 29 10:49:08 2021 From: msheppar at openjdk.java.net (Mark Sheppard) Date: Fri, 29 Oct 2021 10:49:08 GMT Subject: RFR: 8274122: Problemlist java/io/File/createTempFile/SpecialTempFile.java for Windows 11 [v5] In-Reply-To: References: Message-ID: On Fri, 29 Oct 2021 10:38:41 GMT, Ivan ?ipka wrote: >> cc @ctornqvi > > Ivan ?ipka has updated the pull request incrementally with one additional commit since the last revision: > > removed file added by accident bugid in title should be 8275650: i.e. the bugid for problemlist update ------------- PR: https://git.openjdk.java.net/jdk/pull/6025 From alanb at openjdk.java.net Fri Oct 29 11:08:14 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 29 Oct 2021 11:08:14 GMT Subject: RFR: 8276164: RandomAccessFile#write method could throw IndexOutOfBoundsException that is not described in javadoc In-Reply-To: References: Message-ID: On Fri, 29 Oct 2021 10:37:07 GMT, Masanori Yano wrote: > Could you please review the 8276164 bug fixes? > > I suggest adding the missing javadoc of `@throws IndexOutOfBoundsException`. Thanks for separating this from the image I/O issue. For JDK-8276164 then I think we should add the @throws to DataOutput.write, then RAF can inherit it. ------------- PR: https://git.openjdk.java.net/jdk/pull/6168 From msheppar at openjdk.java.net Fri Oct 29 11:09:10 2021 From: msheppar at openjdk.java.net (Mark Sheppard) Date: Fri, 29 Oct 2021 11:09:10 GMT Subject: RFR: JDK-8275650 Problemlist java/io/File/createTempFile/SpecialTempFile.java for Windows 11 [v5] In-Reply-To: References: Message-ID: On Fri, 29 Oct 2021 10:38:41 GMT, Ivan ?ipka wrote: >> cc @ctornqvi > > Ivan ?ipka has updated the pull request incrementally with one additional commit since the last revision: > > removed file added by accident Marked as reviewed by msheppar (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6025 From myano at openjdk.java.net Fri Oct 29 12:51:46 2021 From: myano at openjdk.java.net (Masanori Yano) Date: Fri, 29 Oct 2021 12:51:46 GMT Subject: RFR: 8276164: RandomAccessFile#write method could throw IndexOutOfBoundsException that is not described in javadoc [v2] In-Reply-To: References: Message-ID: <7Rb_keoMCs0X76Ui4tfCIDCP9zmqKoQIKUssnrmCLMM=.95345941-4d31-454a-bd4e-d765828c7fe6@github.com> > Could you please review the 8276164 bug fixes? > > I suggest adding the missing javadoc of `@throws IndexOutOfBoundsException`. Masanori Yano has updated the pull request incrementally with two additional commits since the last revision: - 8276164: RandomAccessFile#write method could throw IndexOutOfBoundsException that is not described in javadoc - 8276164: RandomAccessFile#write method could throw IndexOutOfBoundsException that is not described in javadoc ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6168/files - new: https://git.openjdk.java.net/jdk/pull/6168/files/bf4b0e25..a1cf0531 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6168&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6168&range=00-01 Stats: 7 lines in 2 files changed: 3 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/6168.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6168/head:pull/6168 PR: https://git.openjdk.java.net/jdk/pull/6168 From jai.forums2013 at gmail.com Fri Oct 29 12:55:04 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Fri, 29 Oct 2021 18:25:04 +0530 Subject: JDK-8275509: (jlink) SystemModulesPlugin generates a jdk.internal.module.SystemModules$all.class which isn't reproducible In-Reply-To: <4efe18eb-2fc0-9a27-87f0-3752d5edd65c@gmail.com> References: <4a4901a8-ca90-c9f3-0b2f-a37e521bfe65@oracle.com> <77faaab4-831c-de4f-2f64-f7305cb8f9fb@gmail.com> <60708e84-4888-9584-50e0-df3ae5d8b0b5@oracle.com> <72b9f8de-c4f9-9509-bf1e-ec6148f40860@gmail.com> <89cad5a5-08f0-3bde-5279-7fcb0550d4db@oracle.com> <122a3aee-42bc-b471-5ba8-eb3bebc5e7bb@oracle.com> <71aeec43-ae77-e1f8-d4e4-c5e2d31289e7@gmail.com> <9ea84f87-b1ce-b1d5-a54b-e7ca547529a6@oracle.com> <4efe18eb-2fc0-9a27-87f0-3752d5edd65c@gmail.com> Message-ID: Hello Ioi (and others), On 22/10/21 1:39 pm, Jaikiran Pai wrote: > Hello Ioi, > > On 22/10/21 12:29 pm, Ioi Lam wrote: >> >> >> On 10/21/21 9:09 PM, Jaikiran Pai wrote: >>> Hello Ioi, >>> >>> >>>> >>>> This is my initial analysis of the problem. >>>> >>>> ====>>> Can anyone think of similar problems that may happen >>>> elsewhere? >>>> >>>> The static constructors of enum classes are executed at both CDS >>>> dump time and run time. E.g., >>>> >>>> ??? public enum Modifier { >>>> ??????? OPEN >>>> ??? } >>>> >>>> The method essentially does this: >>>> >>>> ??? public static final Modifier OPEN = new Modifier("OPEN"); >>>> >>>> If a reference of Modifier.OPEN is stored inside the CDS archived >>>> heap during dump time, it will be different than the value of >>>> Modifier.OPEN that is re-created at runtime by the execution of >>>> Modifier. >>> >>> I have almost next to nothing knowledge about CDS internals. My only >>> understanding of it is based on some documentation that I have read. >>> One of them being this one >>> https://docs.oracle.com/en/java/javase/17/vm/class-data-sharing.html#GUID-7EAA3411-8CF0-4D19-BD05-DF5E1780AA91. >>> >>> Based on that documentation (and other similar ones), it was my >>> understanding that CDS was meant to store/share class "metadata" >>> like it states in that doc: >>> >>> "When the JVM starts, the shared archive is memory-mapped to allow >>> sharing of read-only JVM metadata for these classes among multiple >>> JVM processes." >>> >>> But from what you explain in that enum example, it looks like it >>> also stores class instance data that is computed at build time on >>> the host where the JDK image was generated? Did I understand it >>> correctly? Is this only for enums or does it also store the static >>> initialization data of "class" types too? If it does store the >>> static init data of class types too, then wouldn't such data be >>> host/build time specific and as such the classes that need to be >>> enrolled into the default CDS archive of the JDK should be very >>> selective (by reviewing what they do in their static init)? Like I >>> said, I haven't looked into this in detail so perhaps it already is >>> selective in the JDK build? >>> >> >> Hi Jaikiran, >> > Thank you very much for the detailed response. > >> CDS also has the ability to archive Java heap object. Since >> https://bugs.openjdk.java.net/browse/JDK-8244778 , we have archived >> the entire module graph to improve start-up time. At run time, the >> module graph (as well as other archived heap objects) are loaded from >> the CDS archive and put into the Java heap (either through memory >> mapping or copying). > > That is interesting and something that I hadn't known. > >> >> You can see the related code in >> jdk.internal.module.ModuleBootstrap::boot() > I just had a look at it and it's quite elaborate and it'll take a me > while to fully grasp it (if at all) given its understandable complexity. >> >> When the module system has started up, the module graph will >> reference a copy of the OPEN enum object that was created as part of >> the archive. However, the Modifier. will also be executed at >> VM start-up, causing a second copy of the OPEN enum object to be >> stored into the static field Modified::OPEN. > > Thank you for that detail. That helps me understand this a bit more > (and opens a few questions). To be clear - the VM startup code which > creates that other copy, ends up creating that copy because that piece > of initialization happens even before the module system has fully > started up and created those references from the archived state? > Otherwise, the classloaders I believe would be smart enough to not run > that static init again, had the module system with that graph from the > archived state been fully "up"? > > So would this mean that this not just impacts enums but essentially > every class referenced within the module system (of just boot layer?) > that has state which is initialized during static init? To be more > precise, consider the very common example of loggers which are > typically static initialized and stored in a static (final) field: > > private static final java.util.logger.Logger logger = > Logger.getLogger(SomeClass.class); > > If the boot layer module graph has any classes which has state like > this, it would then mean that if such classes do get initialized very > early on during VM startup, then they too are impacted and the module > graph holding instances of such classes will end up using a different > instance for such fields as compared to the rest of the application code? > > In essence, such classes which get accessed early (before module > system with the archived graph is "up") during VM startup can end up > _virtually_ having their static initialization run twice (I understand > it won't be run twice, but that's the end result, isn't it)? > I was really curious why this was only applicable to enums and why other static initialization (like the one I explained above) wasn't impacted. So I decided to do a small PoC. To come up with an illustration that this impacts regular static initialization where enums aren't involved, I decided to add a small piece of code in the java.lang.module.ModuleDescriptor class. I chose this module system class more for convenience than any specific reason. Here's what the updated class looks like (the diff): diff --git a/src/java.base/share/classes/java/lang/module/ModuleDescriptor.java b/src/java.base/share/classes/java/lang/module/ModuleDescriptor.java index a412dd753cc..d08566afa42 100644 --- a/src/java.base/share/classes/java/lang/module/ModuleDescriptor.java +++ b/src/java.base/share/classes/java/lang/module/ModuleDescriptor.java @@ -1214,6 +1214,16 @@ public class ModuleDescriptor ???? private final Set packages; ???? private final String mainClass; +??? private static class Hello { +??????? private static final String ENV_KEY = "FOO"; +??????? private static final String envVal = System.getenv(ENV_KEY); +??? } + +??? /** +???? * javadoc comment +???? */ +??? public String fooVal = Hello.envVal; + ???? private ModuleDescriptor(String name, ????????????????????????????? Version version, ????????????????????????????? String rawVersionString, @@ -2302,6 +2312,8 @@ public class ModuleDescriptor ???????? if (!provides.isEmpty()) { ???????????? sb.append(", provides: ").append(provides); ???????? } +??????? sb.append(", Hello.envVal: " + Hello.envVal + " fooVal " + fooVal +??????????????? +? " System.getenv() val: " + System.getenv(Hello.ENV_KEY)); ???????? sb.append(" }"); ???????? return sb.toString(); ???? } What this update does is - it uses a class called "Hello" which has a static initialization logic (the System.getenv("FOO") call). The value of that static initialization is then used/set as a object instance value to a new field called "fooVal". The update to the toString() method is for easy debugging/demo and it prints the value of: ??? - The System.getenv("FOO") call when toString() is called ??? - The value set to the object instance field "fooVal" ??? - The value set to the Hello.envVal field In a regular lifecycle of a JVM all these 3 values should be the same value and even same object instance (identity equality). With this change, I then built the JDK from source. While building the JDK I set: export FOO="build server of JDK" and then make images Once the JDK was built, I then came up with a trivial Java program which looks like this: import java.lang.module.*; import java.io.*; import java.util.*; public class CDSHeapArchiveIssue { ?? ?public static void main(final String[] args) throws Exception { ??????? System.out.println("System.getenv() val is \"" + System.getenv("FOO") + "\""); ?? ???? String moduleName = "java.sql"; ?? ???? // load the "java.sql" module from boot layer ??????? Optional bootModule = ModuleLayer.boot().findModule(moduleName); ??????? if (bootModule.isEmpty()) { ??????????? throw new RuntimeException(moduleName + " module is missing in boot layer"); ??????? } ??????? ModuleDescriptor m1 = bootModule.get().getDescriptor(); ??????? System.out.println("Env val in boot MD is \"" + m1.fooVal + "\""); ??????? // now recreate the same module using the ModuleDescriptor.read on the module's module-info.class ??????? ModuleDescriptor m2; ??????? try (InputStream moduleInfo = bootModule.get().getResourceAsStream("module-info.class")) { ??????????? if (moduleInfo == null) { ??????????????? throw new RuntimeException("Could not locate module-info.class in " + moduleName + " module"); ??????????? } ??????????? // this will internally use a ModuleDescriptor.Builder to construct the ModuleDescriptor ??????????? m2 = ModuleDescriptor.read(moduleInfo); ??????? } ??????? System.out.println("Env val in built MD is \"" + m2.fooVal + "\""); ??????? if (m1.fooVal.equals(m2.fooVal) && System.getenv("FOO").equals(m1.fooVal)) { ??????????? System.out.println("Success"); ??????? } else { ??????????? System.out.println("Equality check failure"); ??????? } ?? ?} } This code does the following: ??? - Prints the current System.getenv("FOO") value ??? - Loads the java.sql boot module using ModuleLayer.boot()... call (java.sql module isn't special, any other boot module can be used too) ??? - Prints the ModuleDescriptor.fooVal instance value for that boot module ??? - Then builds the same module using the ModuleDescriptor.Builder API. ??? - Prints the ModuleDescriptor.fooVal instance value of this module ??? - Expects all 3 values - the System.getenv("FOO"), the m1.fooVal and m2.fooVal to be "equal()". If this expectation fails, it prints a failure message, else it prints a success message. I then run this compile this code and then run it against the JDK I just built. But before running I set the FOO environment value to something else like: export FOO="runtime host" and then: java CDSHeapArchiveIssue When I run this, I get the following output: java CDSHeapArchiveIssue System.getenv() val is "runtime host" Env val in boot MD is "build server of JDK" Env val in built MD is "runtime host" Equality check failure As you can see the value in the boot module descriptor instance is incorrect and has leaked from the build server where the JDK was built. Now if I switch off CDS and run the same code without any other changes as follows: java -Xshare:off CDSHeapArchiveIssue System.getenv() val is "runtime host" Env val in boot MD is "runtime host" Env val in built MD is "runtime host" Success I get the expected result. So clearly, this issue impacts not just enums but all kinds types of static initialization. I am not truly familiar with which exact classes will end up in the boot module layer, but whichever they are, they all are potentially impacted with this issue, isn't it? I had a look at which classes are selected in the CDS archive during JDK build as my limited knowledge around this tells me that there's a make/jdk/src/classes/build/tools/classlist/HelloClasslist.java[1] which generates the CDS class list and from what I can say it can pull in any "random" class (i.e. as far as I can see there isn't a specific static initialization review done for the classes involved). Am I misunderstanding the severity of this issue or is this serious enough that -Xshare:off should be default (or heap archiving disabled somehow by default till this is fixed) to prevent issues like these which can at the minimal be hard to debug bugs and on the extreme end perhaps leak things from the build server where the JDK was built? I guess it all boils down to which exact classes get replaced/mapped/copied over from the heap archive? Is there a definitive list that can be derived in the current JDK? Note that I used a call to System.getenv() to make it easier to visualize and explain the issue. The use of System.getenv() doesn't play any other role and any other similar static initialization too has the same issue (I have another piece of code without System.getenv() which too fails with the same issue). [1] https://github.com/openjdk/jdk/blob/master/make/jdk/src/classes/build/tools/classlist/HelloClasslist.java -Jaikiran From jboes at openjdk.java.net Fri Oct 29 14:37:10 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Fri, 29 Oct 2021 14:37:10 GMT Subject: RFR: 8273660: De-Serialization Stack is suppressing ClassNotFoundException In-Reply-To: References: Message-ID: <8q4oCNvzc7PTl9TxMBXSHKhHOJSG50ZBeI5W8w2TZ6Q=.fc4ff646-7324-450f-b1a8-ba3e5e91c7bb@github.com> On Wed, 20 Oct 2021 21:57:29 GMT, Roger Riggs wrote: > The ObjectInputStream.GetField method `get(String name, Object val)` should have been throwing > a ClassNotFoundException if the class was not found. Instead the implementation was returning null. > A design error does not allow the `get(String name, Object val)` method to throw CNFE as it should. > However, an exception must be thrown to prevent invalid data from being returned. > Wrapping the CNFE in IOException allows it to be thrown and the exception handled. > The call to `get(String name, Object val)` is always from within a `readObject` method > so the deserialization logic can catch the IOException and unwrap it to handle the CNFE. LGTM ------------- PR: https://git.openjdk.java.net/jdk/pull/6053 From dfuchs at openjdk.java.net Fri Oct 29 15:09:10 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 29 Oct 2021 15:09:10 GMT Subject: RFR: 8273660: De-Serialization Stack is suppressing ClassNotFoundException In-Reply-To: References: Message-ID: On Wed, 20 Oct 2021 21:57:29 GMT, Roger Riggs wrote: > The ObjectInputStream.GetField method `get(String name, Object val)` should have been throwing > a ClassNotFoundException if the class was not found. Instead the implementation was returning null. > A design error does not allow the `get(String name, Object val)` method to throw CNFE as it should. > However, an exception must be thrown to prevent invalid data from being returned. > Wrapping the CNFE in IOException allows it to be thrown and the exception handled. > The call to `get(String name, Object val)` is always from within a `readObject` method > so the deserialization logic can catch the IOException and unwrap it to handle the CNFE. src/java.base/share/classes/java/io/ObjectInputStream.java line 2663: > 2661: ClassNotFoundException ex = handles.lookupException(objHandle); > 2662: if (ex != null) { > 2663: // Wrap the exception so it can be handled in GetField.get(String, Object) I am not sure I understand this comment. We are in `GetField.get(String, Object)`, aren't we? ------------- PR: https://git.openjdk.java.net/jdk/pull/6053 From rriggs at openjdk.java.net Fri Oct 29 15:35:50 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 29 Oct 2021 15:35:50 GMT Subject: RFR: 8273660: De-Serialization Stack is suppressing ClassNotFoundException [v2] In-Reply-To: References: Message-ID: > The ObjectInputStream.GetField method `get(String name, Object val)` should have been throwing > a ClassNotFoundException if the class was not found. Instead the implementation was returning null. > A design error does not allow the `get(String name, Object val)` method to throw CNFE as it should. > However, an exception must be thrown to prevent invalid data from being returned. > Wrapping the CNFE in IOException allows it to be thrown and the exception handled. > The call to `get(String name, Object val)` is always from within a `readObject` method > so the deserialization logic can catch the IOException and unwrap it to handle the CNFE. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Correct comment on the handling of ClassNotFoundException ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6053/files - new: https://git.openjdk.java.net/jdk/pull/6053/files/bc467cab..438548e9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6053&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6053&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6053.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6053/head:pull/6053 PR: https://git.openjdk.java.net/jdk/pull/6053 From rriggs at openjdk.java.net Fri Oct 29 15:35:54 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 29 Oct 2021 15:35:54 GMT Subject: RFR: 8273660: De-Serialization Stack is suppressing ClassNotFoundException [v2] In-Reply-To: References: Message-ID: On Fri, 29 Oct 2021 15:06:12 GMT, Daniel Fuchs wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Correct comment on the handling of ClassNotFoundException > > src/java.base/share/classes/java/io/ObjectInputStream.java line 2663: > >> 2661: ClassNotFoundException ex = handles.lookupException(objHandle); >> 2662: if (ex != null) { >> 2663: // Wrap the exception so it can be handled in GetField.get(String, Object) > > I am not sure I understand this comment. We are in `GetField.get(String, Object)`, aren't we? Right, will correct comment to refer to the `invokeReadObject` call in `readSerialData`. ------------- PR: https://git.openjdk.java.net/jdk/pull/6053 From darcy at openjdk.java.net Fri Oct 29 15:45:11 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 29 Oct 2021 15:45:11 GMT Subject: RFR: 8273660: De-Serialization Stack is suppressing ClassNotFoundException [v2] In-Reply-To: References: Message-ID: On Fri, 29 Oct 2021 15:35:50 GMT, Roger Riggs wrote: >> The ObjectInputStream.GetField method `get(String name, Object val)` should have been throwing >> a ClassNotFoundException if the class was not found. Instead the implementation was returning null. >> A design error does not allow the `get(String name, Object val)` method to throw CNFE as it should. >> However, an exception must be thrown to prevent invalid data from being returned. >> Wrapping the CNFE in IOException allows it to be thrown and the exception handled. >> The call to `get(String name, Object val)` is always from within a `readObject` method >> so the deserialization logic can catch the IOException and unwrap it to handle the CNFE. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Correct comment on the handling of ClassNotFoundException Please file a CSR for the change in behavior. ------------- PR: https://git.openjdk.java.net/jdk/pull/6053 From duke at openjdk.java.net Fri Oct 29 16:09:32 2021 From: duke at openjdk.java.net (iaroslavski) Date: Fri, 29 Oct 2021 16:09:32 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v7] In-Reply-To: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> Message-ID: > Sorting: > > - adopt radix sort for sequential and parallel sorts on int/long/float/double arrays (almost random and length > 6K) > - fix tryMergeRuns() to better handle case when the last run is a single element > - minor javadoc and comment changes > > Testing: > - add new data inputs in tests for sorting > - add min/max/infinity values to float/double testing > - add tests for radix sort iaroslavski has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: - JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) Merge with external changes - JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) Added more comments - JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) Better naming of methods - JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) Simplified mixed insertion sort - Merge remote-tracking branch 'upstream/master' into JDK-8266431-Dual-Pivot-Quicksort-improvements-Radix-sort - JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) Update target version - JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) Testing: - remove @since and @date, otherwise jtreg tag parser fails - JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) Sorting: - move radix sort out from quicksort partitioning - rename radixSort to tryRadixSort - minor javadoc and comment changes Testing: - rename radixSort to tryRadixSort in helper - JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) Sorting: - adopt radix sort for sequential and parallel sorts on int/long/float/double arrays (almost random and length > 6K) - fix tryMergeRuns() to better handle case when the last run is a single element - minor javadoc and comment changes Testing: - add new data inputs in tests for sorting - add min/max/infinity values to float/double testing - add tests for radix sort ------------- Changes: https://git.openjdk.java.net/jdk/pull/3938/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3938&range=06 Stats: 1288 lines in 3 files changed: 855 ins; 102 del; 331 mod Patch: https://git.openjdk.java.net/jdk/pull/3938.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3938/head:pull/3938 PR: https://git.openjdk.java.net/jdk/pull/3938 From erikj at openjdk.java.net Fri Oct 29 16:13:13 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 29 Oct 2021 16:13:13 GMT Subject: RFR: 8275766: (tz) Update Timezone Data to 2021e In-Reply-To: References: Message-ID: On Thu, 28 Oct 2021 01:02:27 GMT, Yoshiki Sato wrote: > Please review the integration of tzdata2021e (including tzdata2021d) to the JDK. > The fix has passed all relevant JTREG regression tests and JCK tests. > > 8275754: (tz) Update Timezone Data to 2021d > 8275849: TestZoneInfo310.java fails with tzdata2021e Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6144 From bpb at openjdk.java.net Fri Oct 29 16:17:21 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 29 Oct 2021 16:17:21 GMT Subject: Integrated: 8274750: java/io/File/GetXSpace.java failed: '/dev': 191488 != 190976 In-Reply-To: <6dZETgaCb3y_013oTmXeAqtD7GCV6Bab_nEehUsdh2U=.ba24c845-5ce6-4774-aac9-cf4f0879799d@github.com> References: <6dZETgaCb3y_013oTmXeAqtD7GCV6Bab_nEehUsdh2U=.ba24c845-5ce6-4774-aac9-cf4f0879799d@github.com> Message-ID: On Tue, 26 Oct 2021 19:00:44 GMT, Brian Burkhalter wrote: > Please consider this proposed change to ignore comparing the total size of `/dev` as returned by `DF(1)` and `STAT(2)` on macOS. This pull request has now been integrated. Changeset: 13265f99 Author: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/13265f9901ab8334bbe1e7a571a9c5f386275dbf Stats: 5 lines in 1 file changed: 2 ins; 1 del; 2 mod 8274750: java/io/File/GetXSpace.java failed: '/dev': 191488 != 190976 Reviewed-by: rriggs, naoto ------------- PR: https://git.openjdk.java.net/jdk/pull/6122 From aefimov at openjdk.java.net Fri Oct 29 16:17:46 2021 From: aefimov at openjdk.java.net (Aleksei Efimov) Date: Fri, 29 Oct 2021 16:17:46 GMT Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v10] In-Reply-To: References: Message-ID: > This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver. > > The following API classes are added to `java.net.spi` package to facilitate this: > - `InetAddressResolverProvider` - abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers. > - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations. > - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations. > - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation. > > More details in [JEP-418](https://openjdk.java.net/jeps/418). > > Testing: new and existing `tier1:tier3` tests Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision: Replace 'system' with 'the system-wide', move comment section ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5822/files - new: https://git.openjdk.java.net/jdk/pull/5822/files/2ca78ba9..f660cc6e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5822&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5822&range=08-09 Stats: 8 lines in 1 file changed: 4 ins; 3 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5822.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5822/head:pull/5822 PR: https://git.openjdk.java.net/jdk/pull/5822 From aefimov at openjdk.java.net Fri Oct 29 16:17:51 2021 From: aefimov at openjdk.java.net (Aleksei Efimov) Date: Fri, 29 Oct 2021 16:17:51 GMT Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v9] In-Reply-To: References: Message-ID: On Wed, 27 Oct 2021 16:23:29 GMT, Michael McMahon wrote: >> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision: >> >> Add @ throws NPE to hosts file resolver javadoc > > src/java.base/share/classes/java/net/InetAddress.java line 841: > >> 839: // 'resolver.lookupByAddress' and 'InetAddress.getAllByName0' delegate to the system-wide resolver, >> 840: // which could be a custom one. At that point we treat any unexpected RuntimeException thrown by >> 841: // the resolver as we would treat an UnknownHostException or an unmatched host name. > > indentation issue in comment above Thanks - moved the comment block inside `catch` block (f660cc6ecc7a31c83de220160b9fd8d0fbacd1be) > src/java.base/share/classes/java/net/InetAddress.java line 1308: > >> 1306: * Creates an InetAddress based on the provided host name and IP address. >> 1307: * System {@linkplain InetAddressResolver resolver} is not used to check >> 1308: * the validity of the address. > > Is this term "system resolver" defined somewhere? I think it means the configured resolver for the current VM. Previously, it really was the system resolver. So, I think it's potentially confusing, as there is also reference to the java.net.preferIPv6Addresses system property as having a possible value "system" which refers to the operating system. Since the CSR is approved, I'm happy to discuss this point post integration. Thanks for highlighting that: Changed `"system"` to `"the system-wide"` - that's what was originally meant by `"system resolver"` (f660cc6ecc7a31c83de220160b9fd8d0fbacd1be). ------------- PR: https://git.openjdk.java.net/jdk/pull/5822 From naoto at openjdk.java.net Fri Oct 29 16:18:10 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 29 Oct 2021 16:18:10 GMT Subject: RFR: 8273660: De-Serialization Stack is suppressing ClassNotFoundException [v2] In-Reply-To: References: Message-ID: <0fNCV_IpOOQtQp25IFoQRsxS-fiCBsKgxxlUW0kYmdQ=.375f6531-4a50-4851-97df-2428f075a93a@github.com> On Fri, 29 Oct 2021 15:35:50 GMT, Roger Riggs wrote: >> The ObjectInputStream.GetField method `get(String name, Object val)` should have been throwing >> a ClassNotFoundException if the class was not found. Instead the implementation was returning null. >> A design error does not allow the `get(String name, Object val)` method to throw CNFE as it should. >> However, an exception must be thrown to prevent invalid data from being returned. >> Wrapping the CNFE in IOException allows it to be thrown and the exception handled. >> The call to `get(String name, Object val)` is always from within a `readObject` method >> so the deserialization logic can catch the IOException and unwrap it to handle the CNFE. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Correct comment on the handling of ClassNotFoundException Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6053 From michaelm at openjdk.java.net Fri Oct 29 16:18:11 2021 From: michaelm at openjdk.java.net (Michael McMahon) Date: Fri, 29 Oct 2021 16:18:11 GMT Subject: RFR: 8273660: De-Serialization Stack is suppressing ClassNotFoundException [v2] In-Reply-To: References: Message-ID: On Fri, 29 Oct 2021 15:35:50 GMT, Roger Riggs wrote: >> The ObjectInputStream.GetField method `get(String name, Object val)` should have been throwing >> a ClassNotFoundException if the class was not found. Instead the implementation was returning null. >> A design error does not allow the `get(String name, Object val)` method to throw CNFE as it should. >> However, an exception must be thrown to prevent invalid data from being returned. >> Wrapping the CNFE in IOException allows it to be thrown and the exception handled. >> The call to `get(String name, Object val)` is always from within a `readObject` method >> so the deserialization logic can catch the IOException and unwrap it to handle the CNFE. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Correct comment on the handling of ClassNotFoundException How likely is it that existing code is using ObjectInputStream::getFields and is already handling class not found by checking for null return from the returned GetField? ------------- PR: https://git.openjdk.java.net/jdk/pull/6053 From dfuchs at openjdk.java.net Fri Oct 29 16:28:16 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 29 Oct 2021 16:28:16 GMT Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v10] In-Reply-To: References: Message-ID: On Fri, 29 Oct 2021 16:17:46 GMT, Aleksei Efimov wrote: >> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver. >> >> The following API classes are added to `java.net.spi` package to facilitate this: >> - `InetAddressResolverProvider` - abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers. >> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations. >> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations. >> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation. >> >> More details in [JEP-418](https://openjdk.java.net/jeps/418). >> >> Testing: new and existing `tier1:tier3` tests > > Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision: > > Replace 'system' with 'the system-wide', move comment section Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5822 From rriggs at openjdk.java.net Fri Oct 29 16:29:13 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 29 Oct 2021 16:29:13 GMT Subject: RFR: 8273660: De-Serialization Stack is suppressing ClassNotFoundException [v2] In-Reply-To: References: Message-ID: On Fri, 29 Oct 2021 16:14:57 GMT, Michael McMahon wrote: > How likely is it that existing code is using ObjectInputStream::getFields and is already handling class not found by checking for null return from the returned GetField? Very unlikely, a field value may be null for because it really is null or it is a field for which there is no value in the stream (supporting evolution). Class not found is supposed to show up as an exception. ------------- PR: https://git.openjdk.java.net/jdk/pull/6053 From mchung at openjdk.java.net Fri Oct 29 16:35:23 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 29 Oct 2021 16:35:23 GMT Subject: RFR: 8273101: Eliminate the usage of threadgroup sandboxing in the java.util.logging In-Reply-To: References: Message-ID: On Wed, 1 Sep 2021 06:31:16 GMT, Sergey Bylokhov wrote: > At the time Java supported applets and webstart, a special mechanism for launching various applications in one JVM was used to reduce memory usage and each application was isolated from each other. > > This isolation was implemented via ThreadGroups where each application created its own thread group and all data for the application was stored in the context of its own group. > > Some parts of the JDK used ThreadGroups directly, others used special classes like sun.awt.AppContext. > > Such sandboxing became useless since the plugin and webstart are no longer supported and were removed in jdk11. > > Note that this is just a first step for the overall cleanup, here is my plan: > 1. Cleanup the usage of AppContext in the ?java.util.logging.LogManager" class in the java.base module. > 2. Cleanup the usage of TheadGroup in the JavaSound > 3. Cleanup the usage of TheadGroup in the JavaBeans > 4. Cleanup the usage of AppContext in the Swing > 5. Cleanup the usage of AppContext in the AWT > 6. Delete the AppContext class. > > The current PR is for the first step. So this is the request to delete the usage of AppContext in the LogManager and related tests. > > Tested by tier1/tier2/tier3 and jdk_desktop tests. The change looks okay. My suggestion is to get 1-6 all ready to push around the same time. It's okay to have separate JBS issues and PRs. ------------- PR: https://git.openjdk.java.net/jdk/pull/5326 From powers.anirvan at gmail.com Sun Oct 31 10:38:48 2021 From: powers.anirvan at gmail.com (Anirvan Sarkar) Date: Sun, 31 Oct 2021 19:38:48 +0900 Subject: 8276207: Properties.loadFromXML/storeToXML works incorrectly for supplementary characters Message-ID: Hi, Properties.loadFromXML/storeToXML works incorrectly for supplementary characters after JDK-8042889[1] was integrated in JDK 9. Properties.storeToXML now generates incorrect character references for supplementary characters. This is similar to JDK-8145974[2] which was fixed in the java.xml module in JDK 9. Properties.loadFromXML now fails to parse character references for supplementary characters and throws InvalidPropertiesFormatException. Sample program which demonstrates these issues is in the JBS[3]. Proposed patch to fix this issue is attached. JDK Tier 1 tests are all green. If it looks fine then I will create a pull request based on this. [1] : https://bugs.openjdk.java.net/browse/JDK-8042889 [2] : https://bugs.openjdk.java.net/browse/JDK-8145974 [3] : https://bugs.openjdk.java.net/browse/JDK-8276207 -- Anirvan From powers.anirvan at gmail.com Sun Oct 31 10:56:56 2021 From: powers.anirvan at gmail.com (Anirvan Sarkar) Date: Sun, 31 Oct 2021 19:56:56 +0900 Subject: 8276207: Properties.loadFromXML/storeToXML works incorrectly for supplementary characters In-Reply-To: References: Message-ID: Hi, Since it seems that the mailing list is scrubbing attachments, patch is mentioned inline below. diff a/src/java.base/share/classes/jdk/internal/util/xml/impl/Parser.java b/src/java.base/share/classes/jdk/internal/util/xml/impl/Parser.java --- a/src/java.base/share/classes/jdk/internal/util/xml/impl/Parser.java +++ b/src/java.base/share/classes/jdk/internal/util/xml/impl/Parser.java @@ -1,7 +1,7 @@ /* - * Copyright (c) 2012, 2020, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2012, 2021, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License version 2 only, as * published by the Free Software Foundation. Oracle designates this @@ -1991,24 +1991,22 @@ case ';': // Convert the character entity to a character try { int i = Integer.parseInt( new String(mBuff, idx + 1, mBuffIdx - idx), 10); - if (i >= 0xffff) { - panic(FAULT); + // Restore the buffer offset + mBuffIdx = idx - 1; + for(char character : Character.toChars(i)) { + if (character == ' ' || mInp.next != null) { + bappend(character, flag); + } else { + bappend(character); + } } - ch = (char) i; } catch (NumberFormatException nfe) { panic(FAULT); } - // Restore the buffer offset - mBuffIdx = idx - 1; - if (ch == ' ' || mInp.next != null) { - bappend(ch, flag); - } else { - bappend(ch); - } st = -1; break; case 'a': // If the entity buffer is empty and ch == 'x' @@ -2032,24 +2030,22 @@ case ';': // Convert the character entity to a character try { int i = Integer.parseInt( new String(mBuff, idx + 1, mBuffIdx - idx), 16); - if (i >= 0xffff) { - panic(FAULT); + // Restore the buffer offset + mBuffIdx = idx - 1; + for(char character : Character.toChars(i)) { + if (character == ' ' || mInp.next != null) { + bappend(character, flag); + } else { + bappend(character); + } } - ch = (char) i; } catch (NumberFormatException nfe) { panic(FAULT); } - // Restore the buffer offset - mBuffIdx = idx - 1; - if (ch == ' ' || mInp.next != null) { - bappend(ch, flag); - } else { - bappend(ch); - } st = -1; break; default: panic(FAULT); diff a/src/java.base/share/classes/jdk/internal/util/xml/impl/XMLStreamWriterImpl.java b/src/java.base/share/classes/jdk/internal/util/xml/impl/XMLStreamWriterImpl.java --- a/src/java.base/share/classes/jdk/internal/util/xml/impl/XMLStreamWriterImpl.java +++ b/src/java.base/share/classes/jdk/internal/util/xml/impl/XMLStreamWriterImpl.java @@ -1,7 +1,7 @@ /* - * Copyright (c) 2012, 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2012, 2021, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License version 2 only, as * published by the Free Software Foundation. Oracle designates this @@ -358,10 +358,19 @@ */ public void setDoIndent(boolean doIndent) { _doIndent = doIndent; } + /** + * Writes character reference in hex format. + */ + private void writeCharRef(int codePoint) throws XMLStreamException { + _writer.write(ENCODING_PREFIX); + _writer.write(Integer.toHexString(codePoint)); + _writer.write(SEMICOLON); + } + /** * Writes XML content to underlying writer. Escapes characters unless * escaping character feature is turned off. */ private void writeXMLContent(char[] content, int start, int length, boolean escapeChars) @@ -381,14 +390,19 @@ char ch = content[index]; if (!_writer.canEncode(ch)) { _writer.write(content, startWritePos, index - startWritePos); - // Escape this char as underlying encoder cannot handle it - _writer.write(ENCODING_PREFIX); - _writer.write(Integer.toHexString(ch)); - _writer.write(SEMICOLON); + // Check if current and next characters forms a surrogate pair + // and escape it to avoid generation of invalid xml content + if ( index != end - 1 && Character.isSurrogatePair(ch, content[index+1])) { + writeCharRef(Character.toCodePoint(ch, content[index+1])); + index++; + } else { + writeCharRef(ch); + } + startWritePos = index + 1; continue; } switch (ch) { @@ -453,14 +467,19 @@ char ch = content.charAt(index); if (!_writer.canEncode(ch)) { _writer.write(content, startWritePos, index - startWritePos); - // Escape this char as underlying encoder cannot handle it - _writer.write(ENCODING_PREFIX); - _writer.write(Integer.toHexString(ch)); - _writer.write(SEMICOLON); + // Check if current and next characters forms a surrogate pair + // and escape it to avoid generation of invalid xml content + if ( index != end - 1 && Character.isSurrogatePair(ch, content.charAt(index+1))) { + writeCharRef(Character.toCodePoint(ch, content.charAt(index+1))); + index++; + } else { + writeCharRef(ch); + } + startWritePos = index + 1; continue; } switch (ch) { diff a/test/jdk/java/util/Properties/LoadAndStoreXML.java b/test/jdk/java/util/Properties/LoadAndStoreXML.java --- a/test/jdk/java/util/Properties/LoadAndStoreXML.java +++ b/test/jdk/java/util/Properties/LoadAndStoreXML.java @@ -1,7 +1,7 @@ /* - * Copyright (c) 2012, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2012, 2021, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License version 2 only, as * published by the Free Software Foundation. @@ -21,11 +21,11 @@ * questions. */ /* * @test - * @bug 8000354 8000685 8004371 8043119 + * @bug 8000354 8000685 8004371 8043119 8276207 * @summary Basic test of storeToXML and loadToXML * @run main/othervm -Djava.security.manager=allow LoadAndStoreXML */ import java.io.ByteArrayInputStream; @@ -136,10 +136,11 @@ props.put("k1", "foo"); props.put("k2", "bar"); props.put("k3", "\u0020\u0391\u0392\u0393\u0394\u0395\u0396\u0397"); props.put("k4", "\u7532\u9aa8\u6587"); props.put("k5", "/conf/jaxp.properties"); + props.put("k6", "\uD834\uDD1E"); TestOutputStream out = new TestOutputStream(); props.storeToXML(out, null, encoding); if (!out.isOpen()) throw new RuntimeException("OutputStream closed by storeToXML"); @@ -241,10 +242,60 @@ } } } } + /** + * Test loadFromXML with supplementary characters + */ + static void testLoadWithSupplementaryCharacters() throws IOException { + System.out.println("testLoadWithSupplementaryCharacters"); + + Properties expected = new Properties(); + expected.put("\uD834\uDD1E", "\uD834\uDD1E"); + + String s = "" + + "" + + "" + + "𝄞" + + ""; + + ByteArrayInputStream in = new ByteArrayInputStream(s.getBytes("UTF-8")); + Properties props = new Properties(); + props.loadFromXML(in); + + if (!props.equals(expected)) { + System.err.println("loaded: " + props + ", expected: " + expected); + throw new RuntimeException("Test failed"); + } + } + + /** + * Test storeToXML with supplementary characters + */ + static void testStoreWithSupplementaryCharacters() throws IOException { + System.out.println("testStoreWithSupplementaryCharacters"); + + String s = "" + System.lineSeparator() + + "" + System.lineSeparator() + + "" + System.lineSeparator() + + "𝄞" + System.lineSeparator() + + "" + System.lineSeparator(); + + Properties props = new Properties(); + props.put("Musical Symbols", "\uD834\uDD1E"); + ByteArrayOutputStream out = new ByteArrayOutputStream(); + props.storeToXML(out, null, "UTF-8"); + + String outXml = out.toString("UTF-8"); + + if (!outXml.equals(s)) { + System.err.println("stored: " + outXml + ", expected: " + s); + throw new RuntimeException("Test failed"); + } + } + public static void main(String[] args) throws IOException { testLoadAndStore("UTF-8", false); testLoadAndStore("UTF-16", false); testLoadAndStore("UTF-16BE", false); @@ -252,10 +303,12 @@ testLoadAndStore("UTF-16BE", true); testLoadAndStore("UTF-16LE", true); testLoadWithoutEncoding(); testLoadWithBadEncoding(); testStoreWithBadEncoding(); + testLoadWithSupplementaryCharacters(); + testStoreWithSupplementaryCharacters(); // malformed documents String src = System.getProperty("test.src"); String subdir = "invalidxml"; Path dir = (src == null) ? Paths.get(subdir) : Paths.get(src, subdir); On Sun, 31 Oct 2021 at 19:38, Anirvan Sarkar wrote: > Hi, > > Properties.loadFromXML/storeToXML works incorrectly for supplementary > characters after JDK-8042889[1] was integrated in JDK 9. > > Properties.storeToXML now generates incorrect character references for > supplementary characters. This is similar to JDK-8145974[2] which was fixed > in the java.xml module in JDK 9. > > Properties.loadFromXML now fails to parse character references for > supplementary characters and throws InvalidPropertiesFormatException. > > Sample program which demonstrates these issues is in the JBS[3]. > > Proposed patch to fix this issue is attached. > JDK Tier 1 tests are all green. > If it looks fine then I will create a pull request based on this. > > [1] : https://bugs.openjdk.java.net/browse/JDK-8042889 > [2] : https://bugs.openjdk.java.net/browse/JDK-8145974 > [3] : https://bugs.openjdk.java.net/browse/JDK-8276207 > > -- > Anirvan > -- Anirvan From alanb at openjdk.java.net Sun Oct 31 19:33:11 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 31 Oct 2021 19:33:11 GMT Subject: RFR: 8275509: ModuleDescriptor.hashCode isn't reproducible across builds [v4] In-Reply-To: References: Message-ID: <5nUzNzFcMmClZouHAjvsgwN69scR0WDCOKPz9cusB_c=.22c51219-22dc-4f8b-aef8-a6487a94669d@github.com> On Fri, 29 Oct 2021 04:19:21 GMT, Jaikiran Pai wrote: > Do you mean the jtreg `driver` style this test is using? I used it because it was necessary to compare output (the hashCode value) between multiple JVM runs. I use the `driver` along with the `ProcessBuilder` to capture the output between multiple JVM runs and compare those. No, I mean the test needs cleanup so it can easily be maintained. For starters I think the main method can take a parameter to indicate its the child process. HashCodeChecker.main becomes a method in ModuleDescriptorHashCodeTest. You'll see several examples of this in the test suite. assertTestPrerequisite tests if the modules requires has modifiers so let's rename the method to make this clearer. Also "requirements" should be "requires". fromBootLayer returns the "java.sql" module so should be renamed to something clearer, or changed to take a parameter with the module name. The dependency on the java.sql module means the test needs "@modules java.sql" Style wise, the over-use of the "final" modifier is annoying, most/all of them aren't needed. ------------- PR: https://git.openjdk.java.net/jdk/pull/6078