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
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
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]
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
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
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
>
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,
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
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
>
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
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
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
>>
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
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
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
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.
> 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
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
>>
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
>>
> 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
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?
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
> 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
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
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
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
> 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
-
27 matches
Mail list logo
