On Tue, 16 Jan 2024 16:31:32 GMT, Henry Jen wrote:
> CPU24_01 fixes.
This pull request has now been integrated.
Changeset: b2cc1890
Author:Henry Jen
URL:
https://git.openjdk.org/jdk22/commit/b2cc1890ff4d2e5404e153ecba5e83f1bcdd6fa7
Stats: 736 lines in 16 files changed: 476 ins;
> CPU24_01 fixes.
Henry Jen has updated the pull request with a new target base due to a merge or
a rebase. The incremental webrev excludes the unrelated changes brought in by
the merge/rebase.
-
Changes:
- all: https://git.openjdk.org/jdk22/pull/83/files
- new: https://git.ope
On Tue, 16 Jan 2024 16:32:27 GMT, Henry Jen wrote:
> CPU24_01 fixes.
This pull request has now been integrated.
Changeset: 2063bb8f
Author:Henry Jen
URL:
https://git.openjdk.org/jdk/commit/2063bb8ffabd6096f547ec6da979cfcf68a56ba3
Stats: 736 lines in 16 files changed: 476 ins; 65
On Tue, 16 Jan 2024 16:31:32 GMT, Henry Jen wrote:
> CPU24_01 fixes.
Marked as reviewed by erikj (Reviewer).
-
PR Review: https://git.openjdk.org/jdk22/pull/83#pullrequestreview-1826185706
On Tue, 16 Jan 2024 19:05:44 GMT, Henry Jen wrote:
>> CPU24_01 fixes.
>
> Henry Jen has updated the pull request with a new target base due to a merge
> or a rebase. The incremental webrev excludes the unrelated changes brought in
> by the merge/rebase. The pull request contains eight additiona
> There's an unused concept of a pluginConfig that is passed into the jlink
> compress plugins, however we always pass null here and the code seems broken
> (the pluginConfig wouldn't have been stored properly). This seem to be a
> left-over from a more generic plugin design that never came to f
On Tue, 16 Jan 2024 23:51:15 GMT, Scott Gibbons wrote:
>> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 4111:
>>
>>> 4109: if ((UseAVX == 2) && EnableX86ECoreOpts &&
>>> VM_Version::supports_avx2()) {
>>> 4110: StubRoutines::_string_indexof = generate_string_indexof();
>>> 4111: }
>
On Tue, 16 Jan 2024 09:11:01 GMT, Chris Hegarty wrote:
>> Update LinkedTransferQueue add and put methods to not call overridable offer.
>
> Chris Hegarty has updated the pull request with a new target base due to a
> merge or a rebase. The incremental webrev excludes the unrelated changes
> bro
On Tue, 16 Jan 2024 12:23:43 GMT, Chris Hegarty wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [ee4d9aa4](https://github.com/openjdk/jdk/commit/ee4d9aa4c11c47e7cf15f2742919ac20311f9ea7)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
> The commit be
On Tue, 16 Jan 2024 22:27:52 GMT, Vladimir Kozlov wrote:
>> Scott Gibbons has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 22 commits:
>>
>> - Merge branch 'openjdk:master' into indexof
>> - Merge branch 'openjdk:master' into ind
On Thu, 11 Jan 2024 23:06:32 GMT, Scott Gibbons wrote:
>> Re-write the IndexOf code without the use of the pcmpestri instruction, only
>> using AVX2 instructions. This change accelerates String.IndexOf on average
>> 1.3x for AVX2. The benchmark numbers:
>>
>>
>> Benchmark
On Fri, 12 Jan 2024 18:25:25 GMT, Justin Lu wrote:
> Please review this PR which is a backport of commit
> [4ea7b364](https://github.com/openjdk/jdk/commit/4ea7b36447ea96d62b1ca164c34e2b2b74a16579)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
> The original commit was a
On Sun, 14 Jan 2024 15:32:12 GMT, Archie Cobbs wrote:
> Please consider this fix to ensure that going from `MessageFormat` to pattern
> string via `toPattern()` and then back via `new MessageFormat()` results in a
> format that is equivalent to the original.
>
> The quoting and escaping rules
On Tue, 16 Jan 2024 18:42:59 GMT, Claes Redestad wrote:
>> There's an unused concept of a pluginConfig that is passed into the jlink
>> compress plugins, however we always pass null here and the code seems broken
>> (the pluginConfig wouldn't have been stored properly). This seem to be a
>> le
On Tue, 16 Jan 2024 18:47:43 GMT, Joe Darcy wrote:
> We can and have run retroactive CSRs in cases like this before; I recommend
> we do one now.
Yes although the issue will be mute once JDK-8323659 is integrated into jdk22.
-
PR Comment: https://git.openjdk.org/jdk/pull/17393#iss
> CPU24_01 fixes.
Henry Jen has updated the pull request with a new target base due to a merge or
a rebase. The incremental webrev excludes the unrelated changes brought in by
the merge/rebase. The pull request contains eight additional commits since the
last revision:
- Merge branch 'openjdk
On Mon, 15 Jan 2024 09:49:53 GMT, Alan Bateman wrote:
> > With my CSR hat on, JDK-8301341 should never have made the changes it did
> > without going through a CSR request. We have been bitten by this kind of
> > problem many times. Unless a public method is specified to utilise another
> > pu
> There's an unused concept of a pluginConfig that is passed into the jlink
> compress plugins, however we always pass null here and the code seems broken
> (the pluginConfig wouldn't have been stored properly). This seem to be a
> left-over from a more generic plugin design that never came to f
On Mon, 15 Jan 2024 10:26:53 GMT, Eirik Bjørsnøs wrote:
>> Please consider this PR which makes `DeflaterOutputStream.close()` always
>> close its wrapped output stream exactly once.
>>
>> Currently, closing of the wrapped output stream happens outside the finally
>> block where `finish()` is c
On Tue, 16 Jan 2024 18:03:34 GMT, Claes Redestad wrote:
>> There's an unused concept of a pluginConfig that is passed into the jlink
>> compress plugins, however we always pass null here and the code seems broken
>> (the pluginConfig wouldn't have been stored properly). This seem to be a
>> le
CPU24_01 fixes.
-
Commit messages:
- 8317547: Enhance TLS connection support
- 8314307: Improve loop handling
- 8318588: Windows build failure after JDK-8314468 due to ambiguous call
- 8314468: Improve Compiler loops
- 8317331: Solaris build failed with "declaration can not follo
On Tue, 16 Jan 2024 18:03:34 GMT, Claes Redestad wrote:
>> There's an unused concept of a pluginConfig that is passed into the jlink
>> compress plugins, however we always pass null here and the code seems broken
>> (the pluginConfig wouldn't have been stored properly). This seem to be a
>> le
> There's an unused concept of a pluginConfig that is passed into the jlink
> compress plugins, however we always pass null here and the code seems broken
> (the pluginConfig wouldn't have been stored properly). This seem to be a
> left-over from a more generic plugin design that never came to f
CPU24_01 fixes.
-
Commit messages:
- 8317547: Enhance TLS connection support
- 8314307: Improve loop handling
- 8318588: Windows build failure after JDK-8314468 due to ambiguous call
- 8314468: Improve Compiler loops
- 8317331: Solaris build failed with "declaration can not follo
On Tue, 16 Jan 2024 08:47:47 GMT, Per Minborg wrote:
>> 8323159: Consider adding some text re. memory zeroing in Arena::allocate
>
> Per Minborg has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Add missing comma in TestScope.java
Marked as
> `GZIPInputStream`, when looking for a concatenated stream, relies on what the
> underlying `InputStream` says is how many bytes are `available()`. But this
> is inappropriate because `InputStream.available()` is just an estimate and is
> allowed (for example) to always return zero.
>
> The fi
On Tue, 16 Jan 2024 08:47:47 GMT, Per Minborg wrote:
>> 8323159: Consider adding some text re. memory zeroing in Arena::allocate
>
> Per Minborg has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Add missing comma in TestScope.java
Looks good
On Tue, 16 Jan 2024 16:38:34 GMT, Glavo wrote:
>> Using `ByteArrayLittleEndian` is simpler and faster.
>>
>> `make test TEST="micro:java.util.zip.ZipFileOpen"`:
>>
>>
>> Benchmark (size) Mode Cnt Score Error
>> Units
>> - ZipFileOpen.openCloseZipFile 512
> Using `ByteArrayLittleEndian` is simpler and faster.
>
> `make test TEST="micro:java.util.zip.ZipFileOpen"`:
>
>
> Benchmark (size) Mode Cnt Score Error Units
> - ZipFileOpen.openCloseZipFile 512 avgt 15 39052.832 ± 107.496 ns/op
> + ZipFileOpen.ope
On Tue, 16 Jan 2024 10:55:07 GMT, Claes Redestad wrote:
> There's an unused concept of a pluginConfig that is passed into the jlink
> compress plugins, however we always pass null here and the code seems broken
> (the pluginConfig wouldn't have been stored properly). This seem to be a
> left-o
On Mon, 20 Nov 2023 16:24:31 GMT, Glavo wrote:
>> Using `ByteArrayLittleEndian` is simpler and faster.
>>
>> `make test TEST="micro:java.util.zip.ZipFileOpen"`:
>>
>>
>> Benchmark (size) Mode Cnt Score Error
>> Units
>> - ZipFileOpen.openCloseZipFile 512
On Mon, 20 Nov 2023 16:24:31 GMT, Glavo wrote:
>> Using `ByteArrayLittleEndian` is simpler and faster.
>>
>> `make test TEST="micro:java.util.zip.ZipFileOpen"`:
>>
>>
>> Benchmark (size) Mode Cnt Score Error
>> Units
>> - ZipFileOpen.openCloseZipFile 512
On Mon, 15 Jan 2024 10:26:53 GMT, Eirik Bjørsnøs wrote:
>> Please consider this PR which makes `DeflaterOutputStream.close()` always
>> close its wrapped output stream exactly once.
>>
>> Currently, closing of the wrapped output stream happens outside the finally
>> block where `finish()` is c
On Tue, 16 Jan 2024 14:41:06 GMT, Eirik Bjørsnøs wrote:
> The spec isn't terribly helpful in spelling out what should happen in the
> case where an entry combines the uses of data descriptors (mandating that
> CRC, size and compressed size must be zero) with Zip64 (mandating that size
> and co
> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
> number of compressed or uncompressed bytes read from the inflater is larger
> than the Zip64 magic value.
>
> While the ZIP format mandates that the data descriptor `SHOULD be stored in
> ZIP64 format (as 8 byte values
On Tue, 16 Jan 2024 13:54:06 GMT, Jaikiran Pai wrote:
>> Eirik Bjørsnøs has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Remove trailing whitespace
>> - Remove trailing whitespace
>
> src/java.base/share/classes/java/util/zip/ZipInputS
On Tue, 16 Jan 2024 14:34:29 GMT, Eirik Bjørsnøs wrote:
>(These reads are from a temp buffer, not the stream)
Ah! you are right indeed. I didn't correctly read that part of that code. It's
reading from a temp buffer which has been fully initialized with a LOC and
these reads happens with speci
On Tue, 16 Jan 2024 14:32:51 GMT, Eirik Bjørsnøs wrote:
>> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
>> number of compressed or uncompressed bytes read from the inflater is larger
>> than the Zip64 magic value.
>>
>> While the ZIP format mandates that the data de
On Tue, 16 Jan 2024 13:42:30 GMT, Jaikiran Pai wrote:
>> src/java.base/share/classes/java/util/zip/ZipInputStream.java line 534:
>>
>>> 532:
>>> 533: long csize = get32(tmpbuf, LOCSIZ);
>>> 534: long size = get32(tmpbuf, LOCLEN);
>>
>> Hello Eirik, I suspect this part of the ch
> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
> number of compressed or uncompressed bytes read from the inflater is larger
> than the Zip64 magic value.
>
> While the ZIP format mandates that the data descriptor `SHOULD be stored in
> ZIP64 format (as 8 byte values
On Wed, 10 Jan 2024 13:39:52 GMT, Eirik Bjørsnøs wrote:
>> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
>> number of compressed or uncompressed bytes read from the inflater is larger
>> than the Zip64 magic value.
>>
>> While the ZIP format mandates that the data de
On Wed, 10 Jan 2024 13:39:52 GMT, Eirik Bjørsnøs wrote:
>> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
>> number of compressed or uncompressed bytes read from the inflater is larger
>> than the Zip64 magic value.
>>
>> While the ZIP format mandates that the data de
On Wed, 10 Jan 2024 13:39:52 GMT, Eirik Bjørsnøs wrote:
>> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
>> number of compressed or uncompressed bytes read from the inflater is larger
>> than the Zip64 magic value.
>>
>> While the ZIP format mandates that the data de
On Tue, 16 Jan 2024 13:40:18 GMT, Jaikiran Pai wrote:
>> Eirik Bjørsnøs has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Remove trailing whitespace
>> - Remove trailing whitespace
>
> src/java.base/share/classes/java/util/zip/ZipInputS
On Thu, 11 Jan 2024 23:06:32 GMT, Scott Gibbons wrote:
>> Re-write the IndexOf code without the use of the pcmpestri instruction, only
>> using AVX2 instructions. This change accelerates String.IndexOf on average
>> 1.3x for AVX2. The benchmark numbers:
>>
>>
>> Benchmark
On Tue, 16 Jan 2024 11:03:28 GMT, John Hendrikx wrote:
>> src/java.base/share/classes/java/util/Map.java line 820:
>>
>>> 818: * @param key key with which the specified value is to be
>>> associated
>>> 819: * @param value value to be associated with the specified key
>>> 820: *
On Thu, 11 Jan 2024 23:06:32 GMT, Scott Gibbons wrote:
>> Re-write the IndexOf code without the use of the pcmpestri instruction, only
>> using AVX2 instructions. This change accelerates String.IndexOf on average
>> 1.3x for AVX2. The benchmark numbers:
>>
>>
>> Benchmark
On Tue, 16 Jan 2024 12:23:43 GMT, Chris Hegarty wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [ee4d9aa4](https://github.com/openjdk/jdk/commit/ee4d9aa4c11c47e7cf15f2742919ac20311f9ea7)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
> The commit be
Hi all,
This pull request contains a backport of commit
[ee4d9aa4](https://github.com/openjdk/jdk/commit/ee4d9aa4c11c47e7cf15f2742919ac20311f9ea7)
from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
The commit being backported was authored by Chris Hegarty on 16 Jan 2024 and
was re
On Fri, 12 Jan 2024 10:38:40 GMT, Chris Hegarty wrote:
> Update LinkedTransferQueue add and put methods to not call overridable offer.
This pull request has now been integrated.
Changeset: ee4d9aa4
Author:Chris Hegarty
URL:
https://git.openjdk.org/jdk/commit/ee4d9aa4c11c47e7cf15f274
On Thu, 11 Jan 2024 23:06:32 GMT, Scott Gibbons wrote:
>> Re-write the IndexOf code without the use of the pcmpestri instruction, only
>> using AVX2 instructions. This change accelerates String.IndexOf on average
>> 1.3x for AVX2. The benchmark numbers:
>>
>>
>> Benchmark
On Thu, 11 Jan 2024 23:06:32 GMT, Scott Gibbons wrote:
>> Re-write the IndexOf code without the use of the pcmpestri instruction, only
>> using AVX2 instructions. This change accelerates String.IndexOf on average
>> 1.3x for AVX2. The benchmark numbers:
>>
>>
>> Benchmark
On Thu, 11 Jan 2024 23:06:32 GMT, Scott Gibbons wrote:
>> Re-write the IndexOf code without the use of the pcmpestri instruction, only
>> using AVX2 instructions. This change accelerates String.IndexOf on average
>> 1.3x for AVX2. The benchmark numbers:
>>
>>
>> Benchmark
On Tue, 16 Jan 2024 10:19:44 GMT, Andrey Turbanov wrote:
> 8291027: Some of TimeZone methods marked 'synchronized' unnecessarily
src/java.base/share/classes/java/util/TimeZone.java line 629:
> 627: */
> 628: public static String[] getAvailableIDs(int rawOffset) {
> 629: return
On Tue, 16 Jan 2024 10:41:04 GMT, Pavel Rappo wrote:
>> Update the documentation for `@return` tag of `putIfAbsent` to match the
>> main description. `putIfAbsent` uses the same wording as `put` for its
>> `@return` tag, but that is incorrect. `putIfAbsent` never returns the
>> **previous** v
There's an unused concept of a pluginConfig that is passed into the jlink
compress plugins, however we always pass null here and the code seems broken
(the pluginConfig wouldn't have been stored properly). This seem to be a
left-over from a more generic plugin design that never came to fruition.
On Tue, 16 Jan 2024 07:40:44 GMT, John Hendrikx wrote:
> Update the documentation for `@return` tag of `putIfAbsent` to match the main
> description. `putIfAbsent` uses the same wording as `put` for its `@return`
> tag, but that is incorrect. `putIfAbsent` never returns the **previous**
> val
On Thu, 11 Jan 2024 23:06:32 GMT, Scott Gibbons wrote:
>> Re-write the IndexOf code without the use of the pcmpestri instruction, only
>> using AVX2 instructions. This change accelerates String.IndexOf on average
>> 1.3x for AVX2. The benchmark numbers:
>>
>>
>> Benchmark
8291027: Some of TimeZone methods marked 'synchronized' unnecessarily
-
Commit messages:
- 8291027: Some of TimeZone methods marked 'synchronized' unnecessarily
Changes: https://git.openjdk.org/jdk/pull/17441/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17441&range=00
I
On Tue, 16 Jan 2024 09:01:35 GMT, Aleksey Shipilev wrote:
>> Since recent work to improve `tier4` performance, we actually test
>> `tier{1,2,3,4}` often, which includes all the tests in current tree. It
>> would be more convenient to just have the `all` test group/alias, so that we
>> can do `
> Update LinkedTransferQueue add and put methods to not call overridable offer.
Chris Hegarty has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev excludes the unrelated changes
brought in by the merge/rebase. The pull request contains eight addi
On Mon, 15 Jan 2024 17:10:47 GMT, Jorn Vernee wrote:
>> Per Minborg has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Rework PathElement:toString
>
> src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 958:
>
>> 956:
On Mon, 15 Jan 2024 16:23:34 GMT, Alan Bateman wrote:
>> Per Minborg has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add missing comma in TestScope.java
>
> test/jdk/java/foreign/TestScope.java line 2:
>
>> 1: /*
>> 2: * Copyright (c)
On Tue, 16 Jan 2024 08:52:03 GMT, Alan Bateman wrote:
>> Tried not to introduce new `*_all` groups here. `jdk_all` would be the same
>> as `jdk:all`, TBH. But we still can do it for symmetry reasons, see new
>> commit.
>
> "all" looks okay but the comment "Catch-all" suggests something else,
>
> Since recent work to improve `tier4` performance, we actually test
> `tier{1,2,3,4}` often, which includes all the tests in current tree. It would
> be more convenient to just have the `all` test group/alias, so that we can do
> `make test TEST=all`. This also gives a parallelism / run time be
On Tue, 16 Jan 2024 08:47:38 GMT, Aleksey Shipilev wrote:
>> test/jdk/TEST.groups line 28:
>>
>>> 26: #
>>> 27:
>>> 28: all = \
>>
>> Why no `jdk_all` definition in this case?
>
> Tried not to introduce new `*_all` groups here. `jdk_all` would be the same
> as `jdk:all`, TBH. But we still can
On Mon, 15 Jan 2024 22:37:36 GMT, David Holmes wrote:
>> Aleksey Shipilev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> jdk_all and lib_test_all groups
>
> test/jdk/TEST.groups line 28:
>
>> 26: #
>> 27:
>> 28: all = \
>
> Why no `j
> Since recent work to improve `tier4` performance, we actually test
> `tier{1,2,3,4}` often, which includes all the tests in current tree. It would
> be more convenient to just have the `all` test group/alias, so that we can do
> `make test TEST=all`. This also gives a parallelism / run time be
> 8323159: Consider adding some text re. memory zeroing in Arena::allocate
Per Minborg has updated the pull request incrementally with one additional
commit since the last revision:
Add missing comma in TestScope.java
-
Changes:
- all: https://git.openjdk.org/jdk22/pull/77/file
On Sat, 13 Jan 2024 18:06:11 GMT, Alan Bateman wrote:
> Clean backport of P3 issue JDK-8322846.
This pull request has now been integrated.
Changeset: 30172819
Author:Alan Bateman
URL:
https://git.openjdk.org/jdk22/commit/3017281956f3c8b50f064a75444c74a18d59e96d
Stats: 128 lines
On Sat, 13 Jan 2024 18:08:03 GMT, Alan Bateman wrote:
> Clean backport of P3 issue JDK-8322818. The test was initially problematic so
> I have to include the test-only fixes JDK-8323002 and JDK-8323296 (doing
> these as follow-on or dependent PRs wouldn't guarantee that would integrate
> at th
71 matches
Mail list logo
