Re: RFR: 8274349: ForkJoinPool.commonPool() does not work with 1 CPU [v2]
> 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=5784=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=5784=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
Re: RFR: 8274544: Langtools command's usage were grabled on Japanese Windows
On Thu, 30 Sep 2021 21:45:15 GMT, Naoto Sato wrote:
>> Screenshot
>> 
>>
>> 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
RFR: 8274349: ForkJoinPool.commonPool() does not work with 1 CPU
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=5784=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
Re: RFR: 8274525: Replace uses of StringBuffer with StringBuilder in java.xml
On Wed, 29 Sep 2021 17:56:49 GMT, Andrey Turbanov wrote: > StringBuffer is a legacy synchronized class. There are more modern > alternatives which perform better: > 1. Plain String concatenation should be preferred > 2. StringBuilder is a direct replacement to StringBuffer which generally have > better performance > > Similar cleanups: > 1. [JDK-8264029](https://bugs.openjdk.java.net/browse/JDK-8264029) java.base > 2. [JDK-8264428](https://bugs.openjdk.java.net/browse/JDK-8264428) > java.desktop > 3. [JDK-8264484](https://bugs.openjdk.java.net/browse/JDK-8264484) > jdk.hotspot.agent Marked as reviewed by naoto (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/5759
Re: RFR: 8274525: Replace uses of StringBuffer with StringBuilder in java.xml
On Wed, 29 Sep 2021 17:56:49 GMT, Andrey Turbanov wrote: > StringBuffer is a legacy synchronized class. There are more modern > alternatives which perform better: > 1. Plain String concatenation should be preferred > 2. StringBuilder is a direct replacement to StringBuffer which generally have > better performance > > Similar cleanups: > 1. [JDK-8264029](https://bugs.openjdk.java.net/browse/JDK-8264029) java.base > 2. [JDK-8264428](https://bugs.openjdk.java.net/browse/JDK-8264428) > java.desktop > 3. [JDK-8264484](https://bugs.openjdk.java.net/browse/JDK-8264484) > jdk.hotspot.agent Marked as reviewed by iris (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/5759
Re: RFR: 8274544: Langtools command's usage were grabled on Japanese Windows
On Thu, 30 Sep 2021 10:10:31 GMT, Ichiroh Takiguchi
wrote:
> * Using native.encoding system property. But
> test/langtools/tools/javac/diags/CheckResourceKeys.java was failed.
What was the cause of the failure?
> * Use java.io.Console, like Console cons = System.console() and
> cons.charset(), but "javac 2>&1 | more" does not work as expected because
> System.console() returns null.
>
> So I added -Dfile.encoding=COMPAT expect java and javaw commands on launcher.
I think we should fix the root cause of this, instead of specifying
`file.encoding=COMPAT`
>
> jshell does not work as expected on b12
Do you mean `b13`?
>
> ```
> >jdk-18-b12\bin\jshell.exe
> | JShellへようこそ -- バージョン18-ea
> | 概要については、次を入力してください: /help intro
>
> jshell> "\u3042".getBytes()
> $1 ==> byte[2] { -126, -96 }
> ```
>
> on b13
>
> ```
> >jdk-18-b13\bin\jshell.exe
> | JShellへようこそ -- バージョン18-ea
> | 概要については、次を入力してください: /help intro
>
> jshell> "\u3042".getBytes()
> $1 ==> byte[3] { -29, -127, -126 }
> ```
>
> It's UTF-8, not native encoding. I think backend java process should use same
> fine.encoding system property setting.
No it should not. `file.encoding` should not be inherited.
Naoto
-
PR: https://git.openjdk.java.net/jdk/pull/5771
Re: RFR: 8274606: Fix jaxp/javax/xml/jaxp/unittest/transform/SurrogateTest.java test
On Thu, 30 Sep 2021 18:32:17 GMT, Alex Kasko wrote: > I was working on backporting JDK-8268457 and found minor problems with the > test introduced there: > > 1. `compareWith*` helper methods are used without `Assert.assertTrue()` > wrapping, so they are effectively ignored > > 2. `this.getClass().getResourceAsStream()` is used to load test input data, > it actually returns null in test run, so transformation is done without input > data > > Note, that SurrogateTest.zip reproducer attached to JDK-8268457 is valid and > fully functional, problems likely were introduced when it was adapted into > test. > > The change is to the test only, it wraps `compareWith*` helpers and loads > data the same way as XSL is loaded. Additionally `compareStringWithGold` was > changed to `compareLinesWithGold` to exclude possible line endings problems. > > Testing: checked that the test fails when JDK-8268457 code fix is reverted, > checked that is passes on master. Marked as reviewed by joehw (Reviewer). Good catch! Thanks. - PR: https://git.openjdk.java.net/jdk/pull/5779
Re: RFR: 8274525: Replace uses of StringBuffer with StringBuilder in java.xml
On Wed, 29 Sep 2021 17:56:49 GMT, Andrey Turbanov wrote: > StringBuffer is a legacy synchronized class. There are more modern > alternatives which perform better: > 1. Plain String concatenation should be preferred > 2. StringBuilder is a direct replacement to StringBuffer which generally have > better performance > > Similar cleanups: > 1. [JDK-8264029](https://bugs.openjdk.java.net/browse/JDK-8264029) java.base > 2. [JDK-8264428](https://bugs.openjdk.java.net/browse/JDK-8264428) > java.desktop > 3. [JDK-8264484](https://bugs.openjdk.java.net/browse/JDK-8264484) > jdk.hotspot.agent Marked as reviewed by joehw (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/5759
Re: RFR: 4890732: GZIPOutputStream doesn't support optional GZIP fields [v12]
On Tue, 28 Sep 2021 03:10:33 GMT, Lin Zang wrote: > Dear All， This PR has been pending there for quite a long time. I am > wondering maybe this PR is not so interesting? I would like to leave this PR > open for a while more, and if no new update, I would let it close > automatically by timeout. Thanks! > > Lin Hi Lin, Thank you for your continued work on this. I think we need to flush out the API more. Alan made a great point in his [comment regarding the mutability of GZIPHeaderData](https://github.com/openjdk/jdk/pull/3072#issuecomment-887629007 ): due to the inclusion of an array element within a record definition. This still needs to be addressed. We should also decide the best location for the header flag constants. I will try to spend a bit more time on this next week. - PR: https://git.openjdk.java.net/jdk/pull/3072
RFR: 8274606: Fix jaxp/javax/xml/jaxp/unittest/transform/SurrogateTest.java test
I was working on backporting JDK-8268457 and found minor problems with the test introduced there: 1. `compareWith*` helper methods are used without `Assert.assertTrue()` wrapping, so they are effectively ignored 2. `this.getClass().getResourceAsStream()` is used to load test input data, it actually returns null in test run, so transformation is done without input data Note, that SurrogateTest.zip reproducer attached to JDK-8268457 is valid and fully functional, problems likely were introduced when it was adapted into test. The change is to the test only, it wraps `compareWith*` helpers and loads data the same way as XSL is loaded. Additionally `compareStringWithGold` was changed to `compareLinesWithGold` to exclude possible line endings problems. Testing: checked that the test fails when JDK-8268457 code fix is reverted, checked that is passes on master. - Commit messages: - 8274606: Fix jaxp/javax/xml/jaxp/unittest/transform/SurrogateTest.java test Changes: https://git.openjdk.java.net/jdk/pull/5779/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5779=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274606 Stats: 10 lines in 1 file changed: 3 ins; 1 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/5779.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5779/head:pull/5779 PR: https://git.openjdk.java.net/jdk/pull/5779
Re: RFR: 8250678: ModuleDescriptor.Version parsing treats empty segments inconsistently
On Fri, 24 Sep 2021 11:28:09 GMT, Masanori Yano wrote: > Could you please review the 8250678 bug fixes? > > The `parse` method of ModuleDescriptor.Version class behaves incorrectly when > the input string contains consecutive delimiters. > > The `parse` method treats strings as three sections, but the parsing method > differs between the method for the version sections and the ones for others. > In version sections, the `parse` method takes a single character in a loop > and determines whether it is a delimiter. In pre and build sections, the > parse method takes two characters in a loop and determines whether the second > character is the delimiter. Therefore, if the string contains a sequence of > delimiters in pre or build section, the `parse` method treats character at > the odd-numbered position as a token and the one at even-numbered as a > delimiter. > > A string containing consecutive delimiters is an incorrect version string, > but this behavior does not follow the API specification. > https://download.java.net/java/early_access/jdk18/docs/api/java.base/java/lang/module/ModuleDescriptor.Version.html > > Therefore, I propose to fix the parsing method of pre and build section in > the same way as the version. @mbreinhold Could you comment on this pull request? - PR: https://git.openjdk.java.net/jdk/pull/5679
Re: RFR: 8269559: AArch64: Implement string_compare intrinsic in SVE [v2]
On Mon, 23 Aug 2021 21:48:01 GMT, TatWai Chong wrote: >> This patch implements string_compare intrinsic in SVE. >> It supports all LL, LU, UL and UU comparisons. >> >> As we haven't found an existing benchmark to measure performance impact, >> we created a benchmark derived from the test [1] for this evaluation. >> This benchmark is attached to this patch. >> >> Besides, remove the unused temporary register `vtmp3` from the existing >> match rules for StrCmp. >> >> The result below shows all varients can be benefited largely. >> Command: make exploded-test TEST="micro:StringCompareToDifferentLength" >> >> Benchmark(size) Mode Cnt Score Speedup Units >> compareToLL 24 avgt 10 1.0x ms/op >> compareToLL 36 avgt 10 1.0x ms/op >> compareToLL 72 avgt 10 1.0x ms/op >> compareToLL 128 avgt 10 1.4x ms/op >> compareToLL 256 avgt 10 1.8x ms/op >> compareToLL 512 avgt 10 2.7x ms/op >> compareToLU 24 avgt 10 1.6x ms/op >> compareToLU 36 avgt 10 1.8x ms/op >> compareToLU 72 avgt 10 2.3x ms/op >> compareToLU 128 avgt 10 3.8x ms/op >> compareToLU 256 avgt 10 4.7x ms/op >> compareToLU 512 avgt 10 6.3x ms/op >> compareToUL 24 avgt 10 1.6x ms/op >> compareToUL 36 avgt 10 1.7x ms/op >> compareToUL 72 avgt 10 2.2x ms/op >> compareToUL 128 avgt 10 3.3x ms/op >> compareToUL 256 avgt 10 4.4x ms/op >> compareToUL 512 avgt 10 6.1x ms/op >> compareToUU 24 avgt 10 1.0x ms/op >> compareToUU 36 avgt 10 1.0x ms/op >> compareToUU 72 avgt 10 1.4x ms/op >> compareToUU 128 avgt 10 2.2x ms/op >> compareToUU 256 avgt 10 2.6x ms/op >> compareToUU 512 avgt 10 3.7x ms/op >> >> [1] >> https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/compiler/intrinsics/string/TestStringCompareToDifferentLength.java > > TatWai Chong has updated the pull request incrementally with one additional > commit since the last revision: > > Restore the removal of vtmp3 (=V2) as it is still used by the non-SVE > compare-long-strings stub. > > And remove the assertion in `string_compare` since it won't help as the > registers > used in the stub are fixed. Marked as reviewed by aph (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/5129
Re: RFR: 8274544: Langtools command's usage were grabled on Japanese Windows
On Thu, 30 Sep 2021 09:36:34 GMT, Ichiroh Takiguchi
wrote:
> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13.
> After JDK18-b13, javac and some other langtool command's usage were garbled
> on Japanese Windows.
> These commands use PrintWriter instead of standard out/err with PrintStream.
Screenshot
javac does not use PrintStream for standard out/err, it uses PrintWriter.
I put some codes on
src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java
* Using native.encoding system property. But
test/langtools/tools/javac/diags/CheckResourceKeys.java was failed.
* Use java.io.Console, like Console cons = System.console() and cons.charset(),
but "javac 2>&1 | more" does not work as expected because System.console()
returns null.
So I added -Dfile.encoding=COMPAT expect java and javaw commands on launcher.
jshell does not work as expected on b12
>jdk-18-b12\bin\jshell.exe
| JShellへようこそ -- バージョン18-ea
| 概要については、次を入力してください: /help intro
jshell> "\u3042".getBytes()
$1 ==> byte[2] { -126, -96 }
on b13
>jdk-18-b13\bin\jshell.exe
| JShellへようこそ -- バージョン18-ea
| 概要については、次を入力してください: /help intro
jshell> "\u3042".getBytes()
$1 ==> byte[3] { -29, -127, -126 }
It's UTF-8, not native encoding.
I think backend java process should use same fine.encoding system property
setting.
I don't think it's good fix, so please give me some advices.
-
PR: https://git.openjdk.java.net/jdk/pull/5771
RFR: 8274544: Langtools command's usage were grabled on Japanese Windows
JEP-400 (UTF-8 by Default) was eabled on JDK18-b13. After JDK18-b13, javac and some other langtool command's usage were garbled on Japanese Windows. These commands use PrintWriter instead of standard out/err with PrintStream. - Commit messages: - Langtools command's usage were grabled on Japanese Windows Changes: https://git.openjdk.java.net/jdk/pull/5771/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5771=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274544 Stats: 35 lines in 2 files changed: 34 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5771.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5771/head:pull/5771 PR: https://git.openjdk.java.net/jdk/pull/5771
Integrated: 8274506: TestPids.java and TestPidsLimit.java fail with podman run as root
On Wed, 29 Sep 2021 12:51:00 GMT, Severin Gehwolf wrote: > Please review this test fix to work around a podman issue[1]. `podman` > expects for the "unlimited" option of `--pids-limit` to be `0` whereas > `docker` wants `-1`. See the JBS bug for details. Thoughts? > > Testing: hotspot/jdk container tests with docker and podman. Two pids tests > used to fail and pass with the patch. > > [1] https://github.com/containers/podman/issues/11782 This pull request has now been integrated. Changeset: 94e31e5c Author:Severin Gehwolf URL: https://git.openjdk.java.net/jdk/commit/94e31e5ca51d1c4c253cf7ac5acd950d10c22267 Stats: 12 lines in 2 files changed: 10 ins; 0 del; 2 mod 8274506: TestPids.java and TestPidsLimit.java fail with podman run as root Reviewed-by: mbaesken, cjplummer - PR: https://git.openjdk.java.net/jdk/pull/5750
Integrated: 8274523: java/lang/management/MemoryMXBean/MemoryTest.java test should handle Shenandoah
On Wed, 29 Sep 2021 17:56:00 GMT, Aleksey Shipilev wrote: > Currently it fails with: > > > $ CONF=linux-x86_64-server-fastdebug make run-test > TEST=java/lang/management/MemoryMXBean/MemoryTest.java > > STDERR: > java.lang.RuntimeException: TEST FAILED: Number of heap pools = 1 but > expected <= 3 and >= 3 > > > Z already handles it with a special configuration, Shenandoah should do the > same. > > Additional testing: > - [x] Affected test now works for Shenandoah > - [x] Affected test still works for Z > - [x] Affected test still works for G1 This pull request has now been integrated. Changeset: f8415a9b Author:Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/f8415a9b2f610ed431e6948c8174f6d982e5b31f Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8274523: java/lang/management/MemoryMXBean/MemoryTest.java test should handle Shenandoah Reviewed-by: mchung, cjplummer - PR: https://git.openjdk.java.net/jdk/pull/5758
Re: RFR: 8274523: java/lang/management/MemoryMXBean/MemoryTest.java test should handle Shenandoah
On Wed, 29 Sep 2021 17:56:00 GMT, Aleksey Shipilev wrote: > Currently it fails with: > > > $ CONF=linux-x86_64-server-fastdebug make run-test > TEST=java/lang/management/MemoryMXBean/MemoryTest.java > > STDERR: > java.lang.RuntimeException: TEST FAILED: Number of heap pools = 1 but > expected <= 3 and >= 3 > > > Z already handles it with a special configuration, Shenandoah should do the > same. > > Additional testing: > - [x] Affected test now works for Shenandoah > - [x] Affected test still works for Z > - [x] Affected test still works for G1 Thanks! - PR: https://git.openjdk.java.net/jdk/pull/5758
