On Tue, 20 Feb 2024 20:46:47 GMT, Joe Darcy wrote:
>> This provides a slightly more accurate bounding limit for
>> `computeNextExponentialSoftCapped` when the computed bound is greater than
>> `(1.0p53 - 1.0) * DoubleZigguratTables.exponentialX0`. This could cause the
>> `while
> This provides a slightly more accurate bounding limit for
> `computeNextExponentialSoftCapped` when the computed bound is greater than
> `(1.0p53 - 1.0) * DoubleZigguratTables.exponentialX0`. This could cause the
> `while (computeNextExponentialSoftCapped(rng, limit) < limit)` check in
>
On Wed, 21 Feb 2024 01:20:24 GMT, Brent Christian wrote:
>> Classes in the `java.lang.ref` package would benefit from an update to bring
>> the spec in line with how the VM already behaves. The changes would focus on
>> _happens-before_ edges at some key points during reference processing.
>>
On Tue, 20 Feb 2024 19:56:53 GMT, Lance Andersen wrote:
> Please review the updates to open/src/java.base/share/legal/zlib.md to update
> the file from zlib 1.2.13 to zlib 1.3.1 which was missed as part of the PR
> for [JDK-8324632](https://bugs.openjdk.org/browse/JDK-8324632)
The change
> This provides a slightly more accurate bounding limit for
> `computeNextExponentialSoftCapped` when the computed bound is greater than
> `(1.0p53 - 1.0) * DoubleZigguratTables.exponentialX0`. This could cause the
> `while (computeNextExponentialSoftCapped(rng, limit) < limit)` check in
>
> Classes in the `java.lang.ref` package would benefit from an update to bring
> the spec in line with how the VM already behaves. The changes would focus on
> _happens-before_ edges at some key points during reference processing.
>
> A couple key things we want to be able to say are:
> -
Vote: Yes
On 2/19/24 3:40 PM, Stuart Marks wrote:
I hereby nominate Viktor Klang [6] to Membership in the Core Libraries Group
[4].
On Thu, 15 Feb 2024 19:44:42 GMT, Justin Lu wrote:
> Please review this PR which handles an edge case pattern bug with
> ChoiceFormat.
>
>
> var d = new ChoiceFormat("0#foo|1#bar|baz|") // creates cFmt equivalent to
> "0.0#foo|1.0#bar|1.0#"
> d.format(1) // unexpectedly returns ""
>
>
>
Vote: yes
Joe (joehw)
On 2/19/24 3:40 PM, Stuart Marks wrote:
I hereby nominate Viktor Klang [6] to Membership in the Core Libraries
Group [4].
Some microbenchmarks in org.openjdk.bench.java.lang.StringBuffers seem
out-of-place (not testing `StringBuffer`), redundant (covered by other tests
like StringSubstring or the various String concatenation tests), or both. This
cleans them out.
My apologies to Sigurd.
-
Commit
On Tue, 20 Feb 2024 19:56:53 GMT, Lance Andersen wrote:
> Please review the updates to open/src/java.base/share/legal/zlib.md to update
> the file from zlib 1.2.13 to zlib 1.3.1 which was missed as part of the PR
> for [JDK-8324632](https://bugs.openjdk.org/browse/JDK-8324632)
Marked as
On Mon, 5 Feb 2024 04:25:16 GMT, Chris Hennick wrote:
> This provides a slightly more accurate bounding limit for
> `computeNextExponentialSoftCapped` when the computed bound is greater than
> `(1.0p53 - 1.0) * DoubleZigguratTables.exponentialX0`. This could cause the
> `while
Vote: yes
-Joe
On 2/19/2024 3:40 PM, Stuart Marks wrote:
I hereby nominate Viktor Klang [6] to Membership in the Core Libraries
Group [4].
Viktor has been a member of the Java team in Oracle since 2022, and he
is currently a Committer on the JDK project. Viktor has led JEP 461
[1], an
On Tue, 20 Feb 2024 18:42:16 GMT, Claes Redestad wrote:
>> JDK-8282429 accidentally removed an optimization (JDK-8240094) that ensured
>> StringBuilder/StringBuffer::toString returns `""` when the builders are
>> empty.
>>
>>
>> Name Cnt Base Error Test
On Tue, 20 Feb 2024 16:32:54 GMT, Claes Redestad wrote:
> JDK-8282429 accidentally removed an optimization (JDK-8240094) that ensured
> StringBuilder/StringBuffer::toString returns `""` when the builders are empty.
>
>
> Name Cnt Base Error Test Error
On Mon, 5 Feb 2024 04:25:16 GMT, Chris Hennick wrote:
> This provides a slightly more accurate bounding limit for
> `computeNextExponentialSoftCapped` when the computed bound is greater than
> `(1.0p53 - 1.0) * DoubleZigguratTables.exponentialX0`. This could cause the
> `while
On Mon, 5 Feb 2024 04:25:16 GMT, Chris Hennick wrote:
> This provides a slightly more accurate bounding limit for
> `computeNextExponentialSoftCapped` when the computed bound is greater than
> `(1.0p53 - 1.0) * DoubleZigguratTables.exponentialX0`. This could cause the
> `while
This provides a slightly more accurate bounding limit for
`computeNextExponentialSoftCapped` when the computed bound is greater than
`(1.0p53 - 1.0) * DoubleZigguratTables.exponentialX0`. This could cause the
`while (computeNextExponentialSoftCapped(rng, limit) < limit)` check in
On Tue, 20 Feb 2024 19:56:53 GMT, Lance Andersen wrote:
> Please review the updates to open/src/java.base/share/legal/zlib.md to update
> the file from zlib 1.2.13 to zlib 1.3.1 which was missed as part of the PR
> for [JDK-8324632](https://bugs.openjdk.org/browse/JDK-8324632)
Marked as
Please review the updates to open/src/java.base/share/legal/zlib.md to update
the file from zlib 1.2.13 to zlib 1.3.1 which was missed as part of the PR for
[JDK-8324632](https://bugs.openjdk.org/browse/JDK-8324632)
-
Commit messages:
- Update zlib.md for zlib 1.3.1
Changes:
Vote: yes
On Tue, 20 Feb 2024 18:34:59 GMT, Naoto Sato wrote:
> Fixing a typo in the said method.
Marked as reviewed by lancea (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/17933#pullrequestreview-1891265805
On Tue, 20 Feb 2024 18:34:59 GMT, Naoto Sato wrote:
> Fixing a typo in the said method.
Marked as reviewed by iris (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/17933#pullrequestreview-1891250872
On Tue, 20 Feb 2024 18:38:48 GMT, Claes Redestad wrote:
>> JDK-8282429 accidentally removed an optimization (JDK-8240094) that ensured
>> StringBuilder/StringBuffer::toString returns `""` when the builders are
>> empty.
>>
>>
>> Name Cnt Base Error Test
> JDK-8282429 accidentally removed an optimization (JDK-8240094) that ensured
> StringBuilder/StringBuffer::toString returns `""` when the builders are empty.
>
>
> Name Cnt Base Error Test Error Unit
> Change
> StringBuffers.emptyToString5 12,289
On Tue, 20 Feb 2024 18:30:25 GMT, Aleksey Shipilev wrote:
>> It's needed again now that I reverted the code removals.. :-)
>
> Mhm. I don't see any new `@Setup` methods anywhere. Just checked out the PR
> locally, removed this import and benchmarks still build, and
> `StringBuilderToString`
Fixing a typo in the said method.
-
Commit messages:
- initial commit
Changes: https://git.openjdk.org/jdk/pull/17933/files
Webrev: https://webrevs.openjdk.org/?repo=jdk=17933=00
Issue: https://bugs.openjdk.org/browse/JDK-8326158
Stats: 2 lines in 1 file changed: 0 ins; 0 del;
On Tue, 20 Feb 2024 18:04:18 GMT, Claes Redestad wrote:
>> src/java.base/share/classes/java/lang/StringBuilder.java line 478:
>>
>>> 476: }
>>> 477: // Create a copy, don't share the array
>>> 478: return new String(this, null);
>>
>> Ok, this got me a bit confused, but
Vote: yes
best regards,
-- daniel
On 19/02/2024 23:40, Stuart Marks wrote:
I hereby nominate Viktor Klang [6] to Membership in the Core Libraries
Group [4].
Vote: yes
On 2/19/24 3:40 PM, Stuart Marks wrote:
> I hereby nominate Viktor Klang [6] to Membership in the Core Libraries Group
> [4].
> Viktor has been a member of the Java team in Oracle since 2022, and he is
> currently a Committer on the JDK project. Viktor has led JEP 461 [1], an
>
On Tue, 20 Feb 2024 18:08:11 GMT, Aleksey Shipilev wrote:
>> I couldn't figure out why we'd want to have `String::substring` micros in a
>> test `StringBuffers` (there's also a `StringSubstring` micro), though I
>> could deal with that as an explicit cleanup RFE.
>
> Yeah, I would like to keep
On Tue, 20 Feb 2024 18:00:42 GMT, Claes Redestad wrote:
>> test/micro/org/openjdk/bench/java/lang/StringBuffers.java line 49:
>>
>>> 47:
>>> 48: @Benchmark
>>> 49: public String emptyToString() {
>>
>> Do we actually need to remove the `substring` test here?
>
> I couldn't figure out
On Tue, 20 Feb 2024 17:02:40 GMT, Aleksey Shipilev wrote:
>> Claes Redestad has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Revert StringBuffers removals
>> - Update from review comments by @shipilev
>
>
> JDK-8282429 accidentally removed an optimization (JDK-8240094) that ensured
> StringBuilder/StringBuffer::toString returns `""` when the builders are empty.
>
>
> Name Cnt Base Error Test Error Unit
> Change
> StringBuffers.emptyToString5 12,289
On Tue, 20 Feb 2024 17:00:14 GMT, Aleksey Shipilev wrote:
>> JDK-8282429 accidentally removed an optimization (JDK-8240094) that ensured
>> StringBuilder/StringBuffer::toString returns `""` when the builders are
>> empty.
>>
>>
>> Name Cnt Base Error Test
Vote: yes
Naoto
On 2/19/24 3:40 PM, Stuart Marks wrote:
I hereby nominate Viktor Klang [6] to Membership in the Core Libraries
Group [4].
Viktor has been a member of the Java team in Oracle since 2022, and he
is currently a Committer on the JDK project. Viktor has led JEP 461 [1],
an
On Tue, 20 Feb 2024 16:32:54 GMT, Claes Redestad wrote:
> JDK-8282429 accidentally removed an optimization (JDK-8240094) that ensured
> StringBuilder/StringBuffer::toString returns `""` when the builders are empty.
>
>
> Name Cnt Base Error Test Error
On Tue, 20 Feb 2024 16:32:54 GMT, Claes Redestad wrote:
> JDK-8282429 accidentally removed an optimization (JDK-8240094) that ensured
> StringBuilder/StringBuffer::toString returns `""` when the builders are empty.
>
>
> Name Cnt Base Error Test Error
JDK-8282429 accidentally removed an optimization (JDK-8240094) that ensured
StringBuilder/StringBuffer::toString returns `""` when the builders are empty.
Name Cnt Base Error Test Error Unit
Change
StringBuffers.emptyToString5 12,289 ±0,384
On Wed, 31 Jan 2024 15:33:01 GMT, Jan Kratochvil
wrote:
>> It looks like this patch needs a bit more discussion. Generally, it would be
>> good to have the functionality, but I'm unsure about the proposed
>> implementation.
>>
>> Walking the directory hierarchy (**and** interface files) on
> The testcase requires root permissions.
Jan Kratochvil has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains 23 commits:
- Disable cgroup.subtree_control testcase on cgroup1
- Extend the testcase
- Implement cgroup.subtree_control .
On Tue, 30 Jan 2024 09:08:28 GMT, Matthias Baesken wrote:
> On some Windows machines we see sometimes OOM errors because of high resource
> (memory/swap) consumption. This is especially seen when the jtreg runs have
> higher concurrency. A solution is to put the java/lang/StringBuilder tests
On Tue, 20 Feb 2024 13:29:28 GMT, Eirik Bjørsnøs wrote:
> Should these methods specify return values when the number of processed bytes
> exceed Integer.MAX_VALUE?
I think they should, otherwise it's not clear if the return value is clamped at
Integer.MAX_VALUE. The wording can make it clear
On Tue, 20 Feb 2024 11:28:08 GMT, Eirik Bjørsnøs wrote:
>> Please review this PR which proposes that we officially deprecate the
>> following four methods in the `java.util.zip` package:
>>
>> * `Inflater.getTotalIn()`
>> * `Inflater.getTotalOut()`
>> * `Deflater.getTotalIn()`
>> *
On Tue, 20 Feb 2024 07:17:53 GMT, Jaikiran Pai wrote:
>> Eirik Bjørsnøs has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix {@link #getBytesRead}
>
> src/java.base/share/classes/java/util/zip/Inflater.java line 644:
>
>> 642: * to
> Please review this PR which proposes that we officially deprecate the
> following four methods in the `java.util.zip` package:
>
> * `Inflater.getTotalIn()`
> * `Inflater.getTotalOut()`
> * `Deflater.getTotalIn()`
> * `Deflater.getTotalOut()`
>
> Since these legacy methods return `int`, they
Hi Frank,
Thanks for the input—currently I'm contemplating whether it is not the most
efficient to perform the nulling out of the nextWaiter in the else-branch of
the update to firstWaiter and lastWaiter as such:
private void doSignal(ConditionNode first, boolean all) {
while (first !=
On Tue, 20 Feb 2024 07:13:41 GMT, Jaikiran Pai wrote:
>> Eirik Bjørsnøs has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix {@link #getBytesRead}
>
> src/java.base/share/classes/java/util/zip/Inflater.java line 642:
>
>> 640: *
On Mon, 19 Feb 2024 16:46:18 GMT, Aleksei Efimov wrote:
> Currently, it is hard to distinguish what part of the test responsible for
> [JDK-8314063](https://bugs.openjdk.org/browse/JDK-8314063) testing, and which
> part is for [JDK-8325579](https://bugs.openjdk.org/browse/JDK-8325579). I
>
On Mon, 19 Feb 2024 16:57:23 GMT, Aleksei Efimov wrote:
>> Christoph Langer 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
>>
On Mon, 19 Feb 2024 13:17:48 GMT, Goetz Lindenmaier wrote:
>> Christoph Langer 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
On Fri, 16 Feb 2024 16:39:33 GMT, Daniel Fuchs wrote:
>> Christoph Langer 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
>>
On Tue, 20 Feb 2024 09:45:22 GMT, Christoph Langer wrote:
>> During analysing a customer case I figured out that we have an inconsistency
>> between documentation and actual behavior in class
>> com.sun.jndi.ldap.Connection. The [method documentation of
>>
> Please review this PR which proposes that we officially deprecate the
> following four methods in the `java.util.zip` package:
>
> * `Inflater.getTotalIn()`
> * `Inflater.getTotalOut()`
> * `Deflater.getTotalIn()`
> * `Deflater.getTotalOut()`
>
> Since these legacy methods return `int`, they
On Tue, 20 Feb 2024 07:12:41 GMT, Jaikiran Pai wrote:
>> Eirik Bjørsnøs has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix {@link #getBytesRead}
>
> src/java.base/share/classes/java/util/zip/Inflater.java line 651:
>
>> 649: *
On Wed, 14 Feb 2024 14:31:03 GMT, Scott Gibbons wrote:
>> Scott Gibbons has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove gcc lib fn; reduce spacial cases to 10 from 32
>
> Thank you all for the reviews. I have been asked to
> During analysing a customer case I figured out that we have an inconsistency
> between documentation and actual behavior in class
> com.sun.jndi.ldap.Connection. The [method documentation of
>
On Sun, 17 Dec 2023 17:51:37 GMT, Jatin Bhateja wrote:
>> Jatin Bhateja has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix incorrect comment
>
> Refined implementation using integral gather operation for AVX512 targets. As
> per Intel
On Wed, 7 Feb 2024 18:38:29 GMT, Jatin Bhateja wrote:
>> Hi All,
>>
>> This patch optimizes sub-word gather operation for x86 targets with AVX2 and
>> AVX512 features.
>>
>> Following is the summary of changes:-
>>
>> 1) Intrinsify sub-word gather using hybrid algorithm which initially
>>
On Tue, 20 Feb 2024 07:35:28 GMT, Emanuel Peter wrote:
>> Jatin Bhateja has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Review comments resolutions.
>
> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1584:
>
>> 1582: Label
On Mon, 19 Feb 2024 05:52:22 GMT, Varada M wrote:
> DeCapo Benchmark Results (3 runs) :
>
> Before :
> = DaCapo 9.12 h2 PASSED in 281402 msec =
> = DaCapo 9.12 h2 PASSED in 269818 msec =
> = DaCapo 9.12 h2 PASSED in 279279 msec =
>
> After:
> = DaCapo 9.12 h2
On Tue, 20 Feb 2024 07:45:59 GMT, Thomas Stuefe wrote:
>> DeCapo Benchmark Results (3 runs) :
>>
>> Before :
>> = DaCapo 9.12 h2 PASSED in 281402 msec =
>> = DaCapo 9.12 h2 PASSED in 269818 msec =
>> = DaCapo 9.12 h2 PASSED in 279279 msec =
>>
>> After:
>> =
62 matches
Mail list logo
