On Wed, 20 Jul 2022 11:19:07 GMT, Andrey Turbanov wrote:
>> Instead of separate ConcurrentHashMap.get call, we can use result of
>> previous putIfAbsent call.
>
> Andrey Turbanov has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8288723: Avo
On Wed, 20 Jul 2022 11:19:07 GMT, Andrey Turbanov wrote:
>> Instead of separate ConcurrentHashMap.get call, we can use result of
>> previous putIfAbsent call.
>
> Andrey Turbanov has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8288723: Avo
On Wed, 20 Jul 2022 11:19:11 GMT, Andrey Turbanov wrote:
>> The comment was about WeekFields.of(), I misplaced the comment.
>>
>> @szegedi All good points about modernizing code...
>> One of the reasons to ask about specific performance data is to validate the
>> general performance impact of u
On Wed, 20 Jul 2022 11:19:07 GMT, Andrey Turbanov wrote:
>> Instead of separate ConcurrentHashMap.get call, we can use result of
>> previous putIfAbsent call.
>
> Andrey Turbanov has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8288723: Avo
On Wed, 6 Jul 2022 14:11:39 GMT, Roger Riggs wrote:
>> @RogerRiggs in my view, it's not about performance per se… I'll sometimes
>> help along these kinds of small fix PRs (that are more likely than not
>> driven by IntelliJ code refactoring suggestions) if I think they lead to
>> more idiomat
> Instead of separate ConcurrentHashMap.get call, we can use result of previous
> putIfAbsent call.
Andrey Turbanov has updated the pull request incrementally with one additional
commit since the last revision:
8288723: Avoid redundant ConcurrentHashMap.get call in java.time
revert 'comp
On Mon, 4 Jul 2022 07:06:30 GMT, Andrey Turbanov wrote:
>> Instead of separate ConcurrentHashMap.get call, we can use result of
>> previous putIfAbsent call.
>
> Andrey Turbanov has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8288723: Avoi
On Tue, 5 Jul 2022 21:27:16 GMT, Attila Szegedi wrote:
>> Can there be some JMH tests to confirm the performance?
>> The value domain of the keys is pretty limited (7 * 7) max; and I'm not sure
>> that the combination of creating a new record and the hashcode and equals
>> methods would be fast
On Tue, 5 Jul 2022 15:26:06 GMT, Roger Riggs wrote:
>> Well, if you _really_ want to noodle this for performance, you can also
>> store a `this`-bound lambda in a `private final` instance field, so then
>> it's only created once too. I wouldn't put it past `javac` to do this, but
>> I'd have
On Sun, 3 Jul 2022 22:06:58 GMT, Attila Szegedi wrote:
>> src/java.base/share/classes/java/time/format/DateTimeTextProvider.java line
>> 312:
>>
>>> 310: private Object findStore(TemporalField field, Locale locale) {
>>> 311: Entry key = createEntry(field, locale);
>>> 312:
On Tue, 5 Jul 2022 15:26:06 GMT, Roger Riggs wrote:
>> Well, if you _really_ want to noodle this for performance, you can also
>> store a `this`-bound lambda in a `private final` instance field, so then
>> it's only created once too. I wouldn't put it past `javac` to do this, but
>> I'd have
On Sun, 3 Jul 2022 19:47:16 GMT, Attila Szegedi wrote:
>> Andrey Turbanov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8288723: Avoid redundant ConcurrentHashMap.get call in java.time
>> use computeIfAbsent where lambda could be sho
On Sun, 3 Jul 2022 19:44:55 GMT, Attila Szegedi wrote:
>> But it will generate garbage: non-static lambda.
>
> It already generates some garbage as it does string concatenation for the
> key. Here's an idea: declare a record class for the key, `record
> CacheKey(DayOfWeek firstDayOfWeek, int mi
On Tue, 21 Jun 2022 17:08:17 GMT, liach wrote:
>> @liach advance apologies for nitpicking: `ConcurrentHashMap` doesn't in
>> general block while the mapping function runs. It can block _some_
>> concurrent updates, namely those that [hash to the same
>> bin](https://github.com/openjdk/jdk/blob
> Instead of separate ConcurrentHashMap.get call, we can use result of previous
> putIfAbsent call.
Andrey Turbanov has updated the pull request incrementally with one additional
commit since the last revision:
8288723: Avoid redundant ConcurrentHashMap.get call in java.time
-
C
On Sun, 3 Jul 2022 20:42:53 GMT, liach wrote:
>> Andrey Turbanov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8288723: Avoid redundant ConcurrentHashMap.get call in java.time
>> use computeIfAbsent where lambda could be short and st
On Wed, 22 Jun 2022 21:29:50 GMT, Andrey Turbanov wrote:
>> Instead of separate ConcurrentHashMap.get call, we can use result of
>> previous putIfAbsent call.
>
> Andrey Turbanov has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8288723: Avo
On Tue, 28 Jun 2022 07:27:30 GMT, Andrey Turbanov wrote:
>> src/java.base/share/classes/java/time/temporal/WeekFields.java line 331:
>>
>>> 329: String key = firstDayOfWeek.toString() +
>>> minimalDaysInFirstWeek;
>>> 330: WeekFields rules = CACHE.get(key);
>>> 331: if (
On Wed, 22 Jun 2022 21:29:50 GMT, Andrey Turbanov wrote:
>> Instead of separate ConcurrentHashMap.get call, we can use result of
>> previous putIfAbsent call.
>
> Andrey Turbanov has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8288723: Avo
On Fri, 24 Jun 2022 07:22:05 GMT, Jaikiran Pai wrote:
>> Andrey Turbanov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8288723: Avoid redundant ConcurrentHashMap.get call in java.time
>> use computeIfAbsent where lambda could be shor
On Wed, 22 Jun 2022 21:29:50 GMT, Andrey Turbanov wrote:
>> Instead of separate ConcurrentHashMap.get call, we can use result of
>> previous putIfAbsent call.
>
> Andrey Turbanov has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8288723: Avo
> Instead of separate ConcurrentHashMap.get call, we can use result of previous
> putIfAbsent call.
Andrey Turbanov has updated the pull request incrementally with one additional
commit since the last revision:
8288723: Avoid redundant ConcurrentHashMap.get call in java.time
use computeIfAb
On Tue, 21 Jun 2022 09:35:34 GMT, Attila Szegedi wrote:
>> This behaves slightly different from the old initialization; the concurrent
>> hash map blocks when the mapping function is run, just in case if
>> non-blocking instantiation is what we want. If that's not a problem, I would
>> prefer
On Mon, 20 Jun 2022 15:01:55 GMT, liach wrote:
>> src/java.base/share/classes/java/time/format/DateTimeTextProvider.java line
>> 319:
>>
>>> 317: store = prev;
>>> 318: }
>>> 319: }
>>
>> You could do better here and use `computeIfAbsent` with `createStore`
On Mon, 20 Jun 2022 09:11:31 GMT, Attila Szegedi wrote:
>> Instead of separate ConcurrentHashMap.get call, we can use result of
>> previous putIfAbsent call.
>
> src/java.base/share/classes/java/time/format/DateTimeTextProvider.java line
> 319:
>
>> 317: store = prev;
>> 318:
On Sat, 18 Jun 2022 10:43:08 GMT, Andrey Turbanov wrote:
> Instead of separate ConcurrentHashMap.get call, we can use result of previous
> putIfAbsent call.
src/java.base/share/classes/java/time/format/DateTimeTextProvider.java line 319:
> 317: store = prev;
> 318:
Instead of separate ConcurrentHashMap.get call, we can use result of previous
putIfAbsent call.
-
Commit messages:
- [PATCH] Avoid redundant ConcurrentHashMap.get call in java.time
Changes: https://git.openjdk.org/jdk/pull/9208/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&p
27 matches
Mail list logo
