On Thu, 2 Jan 2025 18:11:53 GMT, Naoto Sato wrote:
>> The change made in
>> [JDK-8288723](https://bugs.openjdk.org/browse/JDK-8288723) seems innocuous,
>> but it caused this performance regression. Partially reverting the change
>> (ones that involve `computeIfAbsent()`) to the original. Provi
On Thu, 2 Jan 2025 19:51:19 GMT, Andrey Turbanov wrote:
>> Naoto Sato 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
>> commits
On Thu, 2 Jan 2025 18:11:53 GMT, Naoto Sato wrote:
>> The change made in
>> [JDK-8288723](https://bugs.openjdk.org/browse/JDK-8288723) seems innocuous,
>> but it caused this performance regression. Partially reverting the change
>> (ones that involve `computeIfAbsent()`) to the original. Provi
On Thu, 2 Jan 2025 18:11:53 GMT, Naoto Sato wrote:
>> The change made in
>> [JDK-8288723](https://bugs.openjdk.org/browse/JDK-8288723) seems innocuous,
>> but it caused this performance regression. Partially reverting the change
>> (ones that involve `computeIfAbsent()`) to the original. Provi
On Thu, 2 Jan 2025 18:11:53 GMT, Naoto Sato wrote:
>> The change made in
>> [JDK-8288723](https://bugs.openjdk.org/browse/JDK-8288723) seems innocuous,
>> but it caused this performance regression. Partially reverting the change
>> (ones that involve `computeIfAbsent()`) to the original. Provi
> The change made in [JDK-8288723](https://bugs.openjdk.org/browse/JDK-8288723)
> seems innocuous, but it caused this performance regression. Partially
> reverting the change (ones that involve `computeIfAbsent()`) to the original.
> Provided a benchmark that iterates the call to `ZoneOffset.ofT
On Mon, 30 Dec 2024 17:44:11 GMT, Brett Okken wrote:
>> Indeed, just noticed that both `computeIfAbsent` and `putIfAbsent` may
>> acquire the lock when the key is present, while `get` never acquires a lock
>> for read-only access.
>>
>> Maybe the implementation was written back when locking wa
On Sat, 21 Dec 2024 00:59:53 GMT, Chen Liang wrote:
>> test/micro/org/openjdk/bench/java/time/ZoneOffsetBench.java line 49:
>>
>>> 47: public void ofTotalSeconds() {
>>> 48: for (int i = 0; i < 1_000; i++) {
>>> 49: ZoneOffset.ofTotalSeconds(0);
>>
>> This benchmark meth
On Fri, 27 Dec 2024 23:24:46 GMT, Chen Liang wrote:
>>> For sure we should use result of `putIfAbsent`
>>
>> Drive-by comment...
>>
>> From what i can infer, the performance regression being addressed here is
>> caused in part by the fact that (for example)
>> `ConcurrentHashMap.computeIfAbse
On Fri, 27 Dec 2024 16:27:10 GMT, Archie Cobbs wrote:
>> For sure we should use result of `putIfAbsent`. Let's do this for all cases.
>> See how it was implemented in my first commit -
>> https://github.com/openjdk/jdk/pull/9208/commits/73a2f6cb1b91f4d7ee374089f35a72ef7b94433b
>
>> For sure we
On Thu, 26 Dec 2024 17:25:55 GMT, Andrey Turbanov wrote:
> For sure we should use result of `putIfAbsent`
Drive-by comment...
>From what i can infer, the performance regression being addressed here is
>caused in part by the fact that (for example)
>`ConcurrentHashMap.computeIfAbsent()` provid
On Thu, 26 Dec 2024 16:39:58 GMT, Brett Okken wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fixed compile error
>
> src/java.base/share/classes/java/time/format/DateTimeTextProvider.java line
> 316:
>
>> 314:
On Fri, 20 Dec 2024 21:06:16 GMT, Naoto Sato wrote:
>> The change made in
>> [JDK-8288723](https://bugs.openjdk.org/browse/JDK-8288723) seems innocuous,
>> but it caused this performance regression. Partially reverting the change
>> (ones that involve `computeIfAbsent()`) to the original. Prov
On Sat, 21 Dec 2024 00:54:34 GMT, Chen Liang wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fixed compile error
>
> test/micro/org/openjdk/bench/java/time/ZoneOffsetBench.java line 49:
>
>> 47: public void ofTo
On Fri, 20 Dec 2024 21:06:16 GMT, Naoto Sato wrote:
>> The change made in
>> [JDK-8288723](https://bugs.openjdk.org/browse/JDK-8288723) seems innocuous,
>> but it caused this performance regression. Partially reverting the change
>> (ones that involve `computeIfAbsent()`) to the original. Prov
On Fri, 20 Dec 2024 23:59:30 GMT, Shaojin Wen wrote:
>> Hi Shaojin,
>> Thanks for the suggestion, but I am not planning to improve the code more
>> than backing out the offending fix at this time. (btw, cache size would be
>> 149 as 18:00 and -18:00 are inclusive)
>
> Can I submit a PR to make
On Fri, 20 Dec 2024 23:46:57 GMT, Naoto Sato wrote:
>> For example:
>>
>> static final AtomicReferenceArray MINUTES_15_CACHE = new
>> AtomicReferenceArray<>(37 * 4);
>>
>> public static ZoneOffset ofTotalSeconds(int totalSeconds) {
>> // ...
>> int minutes15Rem = totalSecon
On Fri, 20 Dec 2024 23:07:47 GMT, Shaojin Wen wrote:
>> src/java.base/share/classes/java/time/ZoneOffset.java line 428:
>>
>>> 426: if (totalSeconds % (15 * SECONDS_PER_MINUTE) == 0) {
>>> 427: Integer totalSecs = totalSeconds;
>>> 428: ZoneOffset result = SECONDS
On Fri, 20 Dec 2024 23:05:06 GMT, Shaojin Wen wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fixed compile error
>
> src/java.base/share/classes/java/time/ZoneOffset.java line 428:
>
>> 426: if (totalSecond
On Fri, 20 Dec 2024 21:06:16 GMT, Naoto Sato wrote:
>> The change made in
>> [JDK-8288723](https://bugs.openjdk.org/browse/JDK-8288723) seems innocuous,
>> but it caused this performance regression. Partially reverting the change
>> (ones that involve `computeIfAbsent()`) to the original. Prov
> The change made in [JDK-8288723](https://bugs.openjdk.org/browse/JDK-8288723)
> seems innocuous, but it caused this performance regression. Partially
> reverting the change (ones that involve `computeIfAbsent()`) to the original.
> Provided a benchmark that iterates the call to `ZoneOffset.ofT
> The change made in [JDK-8288723](https://bugs.openjdk.org/browse/JDK-8288723)
> seems innocuous, but it caused this performance regression. Partially
> reverting the change (ones that involve `computeIfAbsent()`) to the original.
> Provided a benchmark that iterates the call to `ZoneOffset.ofT
On Fri, 20 Dec 2024 20:25:28 GMT, Roger Riggs wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update src/java.base/share/classes/java/time/ZoneOffset.java
>>
>> Co-authored-by: Roger Riggs
>
> src/java.base/sha
On Fri, 20 Dec 2024 19:55:06 GMT, Naoto Sato wrote:
> The change made in [JDK-8288723](https://bugs.openjdk.org/browse/JDK-8288723)
> seems innocuous, but it caused this performance regression. Partially
> reverting the change (ones that involve `computeIfAbsent()`) to the original.
> Provided
The change made in [JDK-8288723](https://bugs.openjdk.org/browse/JDK-8288723)
seems innocuous, but it caused this performance regression. Partially reverting
the change (ones that involve `computeIfAbsent()`) to the original. Provided a
benchmark that iterates the call to `ZoneOffset.ofTotalSeco
25 matches
Mail list logo
