Integrated: 8274523: java/lang/management/MemoryMXBean/MemoryTest.java test should handle Shenandoah

2021-09-29 Thread Aleksey Shipilev
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 > expecte

Re: RFR: 8274523: java/lang/management/MemoryMXBean/MemoryTest.java test should handle Shenandoah

2021-09-29 Thread Aleksey Shipilev
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 > expecte

Re: RFR: 8274464: Remove redundant stream() call before forEach in java.* modules

2021-09-29 Thread Vyom Tewari
On Wed, 15 Sep 2021 07:12:25 GMT, Andrey Turbanov wrote: > 8274464: Remove redundant stream() call before forEach in java.* modules Looks good to me. - Marked as reviewed by vtewari (Committer). PR: https://git.openjdk.java.net/jdk/pull/5520

Integrated: 8273435: Remove redundant zero-length check in ClassDesc.of

2021-09-29 Thread Andrey Turbanov
On Wed, 18 Aug 2021 07:28:57 GMT, Andrey Turbanov wrote: > After [JDK-8215510](https://bugs.openjdk.java.net/browse/JDK-8215510) > (eed3a536c0) this condition is always `false`. Empty package name is handled > separately. > Found by IntelliJ inspection. This pull request has now been integrat

RFR: 8274525: Replace uses of StringBuffer with StringBuilder in java.xml

2021-09-29 Thread Andrey Turbanov
StringBuffer is a legacy synchronized class. There are more modern alternatives which perform better: 1. Plain String concatenation should be preferred 2. StringBuilder is a direct replacement to StringBuffer which generally have better performance - Commit messages: - [PATCH] Clea

Re: RFR: 8273101: Eliminate the usage of threadgroup sandboxing in the java.util.logging

2021-09-29 Thread Sergey Bylokhov
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

Re: RFR: 8274464: Remove redundant stream() call before forEach in java.* modules

2021-09-29 Thread Alex Menkov
On Wed, 15 Sep 2021 07:12:25 GMT, Andrey Turbanov wrote: > 8274464: Remove redundant stream() call before forEach in java.* modules Marked as reviewed by amenkov (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/5520

Re: RFR: 8274523: java/lang/management/MemoryMXBean/MemoryTest.java test should handle Shenandoah

2021-09-29 Thread Chris Plummer
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 > expecte

RFR: 8274523: java/lang/management/MemoryMXBean/MemoryTest.java test should handle Shenandoah

2021-09-29 Thread Aleksey Shipilev
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, Shenandoa

Re: RFR: 8274506: TestPids.java and TestPidsLimit.java fail with podman run as root

2021-09-29 Thread Chris Plummer
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 cont

Re: RFR: 8274523: java/lang/management/MemoryMXBean/MemoryTest.java test should handle Shenandoah

2021-09-29 Thread Mandy Chung
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 > expecte

RFR: 8274522: java/lang/management/ManagementFactory/MXBeanException.java test fails with Shenandoah

2021-09-29 Thread Aleksey Shipilev
Fails like this: $ CONF=linux-x86_64-server-fastdebug make run-test TEST=java/lang/management/ManagementFactory/MXBeanException.java TEST_VM_OPTS="-XX:+UseShenandoahGC" ... java.lang.NullPointerException: Cannot invoke "java.lang.management.MemoryPoolMXBean.setUsageThreshold(long)" because

Re: RFR: 8274506: TestPids.java and TestPidsLimit.java fail with podman run as root

2021-09-29 Thread Severin Gehwolf
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 cont

Re: RFR: 8193682: Infinite loop in ZipOutputStream.close()

2021-09-29 Thread Ravi Reddy
On Fri, 17 Sep 2021 12:45:29 GMT, Alan Bateman wrote: >> Hi all, >> >> Please review this fix for Infinite loop in ZipOutputStream.close(). >> The main issue here is when ever there is an exception during close >> operations on GZip we are not setting the deflator to a finished state which >>

Integrated: 8274242: Implement fast-path for ASCII-compatible CharsetEncoders on x86

2021-09-29 Thread Claes Redestad
On Tue, 21 Sep 2021 21:58:48 GMT, Claes Redestad wrote: > This patch extends the `ISO_8859_1.implEncodeISOArray` intrinsic on x86 to > work also for ASCII encoding, which makes for example the `UTF_8$Encoder` > perform on par with (or outperform) similarly getting charset encoded bytes > from

Re: RFR: 8274506: TestPids.java and TestPidsLimit.java fail with podman run as root

2021-09-29 Thread Matthias Baesken
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 cont

RFR: 8274506: TestPids.java and TestPidsLimit.java fail with podman run as root

2021-09-29 Thread Severin Gehwolf
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

Re: RFR: 8274242: Implement fast-path for ASCII-compatible CharsetEncoders on x86 [v7]

2021-09-29 Thread Claes Redestad
On Tue, 28 Sep 2021 11:49:28 GMT, Volker Simonis wrote: >> Does the changes in 9800a99 resolve your concerns? > > In principle yes, but shouldn't the condition read: > > if (!Matcher::match_rule_supported(Op_EncodeISOArray) || > !Matcher::supports_encode_ascii_array) return false; > > I.e. the

Re: RFR: 8274242: Implement fast-path for ASCII-compatible CharsetEncoders on x86 [v7]

2021-09-29 Thread Claes Redestad
> This patch extends the `ISO_8859_1.implEncodeISOArray` intrinsic on x86 to > work also for ASCII encoding, which makes for example the `UTF_8$Encoder` > perform on par with (or outperform) similarly getting charset encoded bytes > from a String. The former took a small performance hit in JDK 9

Re: RFR: 8274242: Implement fast-path for ASCII-compatible CharsetEncoders on x86 [v6]

2021-09-29 Thread Tobias Hartmann
On Wed, 29 Sep 2021 12:36:23 GMT, Claes Redestad wrote: >> This patch extends the `ISO_8859_1.implEncodeISOArray` intrinsic on x86 to >> work also for ASCII encoding, which makes for example the `UTF_8$Encoder` >> perform on par with (or outperform) similarly getting charset encoded bytes >> f

Re: RFR: 8274242: Implement fast-path for ASCII-compatible CharsetEncoders on x86 [v6]

2021-09-29 Thread Claes Redestad
On Mon, 27 Sep 2021 12:27:32 GMT, Tobias Hartmann wrote: >>> Should we remove the "iso" part from the method/class names? >> >> I'm open to suggestions, but I've not been able to think of anything better. >> `encodeISOOrASCII` doesn't seem helpful and since ASCII is a subset of the >> ISO-8859

Re: RFR: 8274242: Implement fast-path for ASCII-compatible CharsetEncoders on x86 [v6]

2021-09-29 Thread Claes Redestad
> This patch extends the `ISO_8859_1.implEncodeISOArray` intrinsic on x86 to > work also for ASCII encoding, which makes for example the `UTF_8$Encoder` > perform on par with (or outperform) similarly getting charset encoded bytes > from a String. The former took a small performance hit in JDK 9

Re: RFR: 8273435: Remove redundant zero-length check in ClassDesc.of

2021-09-29 Thread Andrey Turbanov
On Wed, 18 Aug 2021 07:28:57 GMT, Andrey Turbanov wrote: > After [JDK-8215510](https://bugs.openjdk.java.net/browse/JDK-8215510) > (eed3a536c0) this condition is always `false`. Empty package name is handled > separately. > Found by IntelliJ inspection. Can someone sponsor changes, please? -

Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v8]

2021-09-29 Thread Daniel Fuchs
On Wed, 29 Sep 2021 11:02:05 GMT, Julia Boes wrote: >> This change implements a simple web server that can be run on the >> command-line with `java -m jdk.httpserver`. >> >> This is facilitated by adding an entry point for the `jdk.httpserver` >> module, an implementation class whose main meth

Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v8]

2021-09-29 Thread Julia Boes
> 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 th

Re: RFR: 8274464: Remove redundant stream() call before forEach in java.* modules

2021-09-29 Thread Daniel Fuchs
On Wed, 15 Sep 2021 07:12:25 GMT, Andrey Turbanov wrote: > 8274464: Remove redundant stream() call before forEach in java.* modules LGTM - Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5520

Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server

2021-09-29 Thread Julia Boes
On Tue, 28 Sep 2021 10:30:21 GMT, Bernd Eckenfels wrote: > * For all interfaces use "-b 0.0.0.0" (IPv4) or "-b ::" (IPv6) > > Instead of: > > * For 0.0.0.0 (all interfaces) use -b 0.0.0.0 or -b ::0 > > In the usage? > > (I think ?::? is canon?) Good point, "::" is recommended, e.g. in RFC59

Re: RFR: 4890732: GZIPOutputStream doesn't support optional GZIP fields [v12]

2021-09-29 Thread Lin Zang
On Mon, 6 Sep 2021 07:20:11 GMT, Lin Zang wrote: >> 4890732: GZIPOutputStream doesn't support optional GZIP fields > > Lin Zang has updated the pull request with a new target base due to a merge > or a rebase. The pull request now contains 17 commits: > > - Merge branch 'master' into gzip-fiel

Re: RFR: 4890732: GZIPOutputStream doesn't support optional GZIP fields [v13]

2021-09-29 Thread Lin Zang
> 4890732: GZIPOutputStream doesn't support optional GZIP fields Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: - remove trailing whitespaces - fix build warnings - Merge branch 'master' into gzip-field - cod