On Sun, 24 Nov 2024 12:51:28 GMT, Attila Szegedi wrote:
>> Roger Riggs has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Apply review comments:
>> Retain public static constants for permission names to avoi
On Sun, 24 Nov 2024 15:03:43 GMT, Alan Bateman wrote:
> What is this nit? We added the API note to SecureLookupSupplier as part of
> the JEP 486, follow-on work could deprecate it.
Oh you mean, the entire class has an API note so it is not needed on the member
field? Right, I overlooked that.
On Mon, 18 Nov 2024 16:13:27 GMT, Roger Riggs wrote:
>> Refactor to remove use of SecurityManager
>
> Roger Riggs has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Apply review comments:
> Retain public static constants for permission names
On Fri, 15 Nov 2024 16:38:53 GMT, Roger Riggs wrote:
> Refactor to remove use of SecurityManager
Hey Roger, thanks for doing this no doubt unglamorous maintenance task. I
reviewed it, and it mostly looks good, there's few things I thought about maybe
taking a step further (and one thing I'd pr
On Wed, 30 Oct 2024 19:28:32 GMT, Sean Mullan wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> main ch
On Sun, 29 Sep 2024 17:44:30 GMT, Attila Szegedi wrote:
> Fixes a regression with #17818 where `ArrayList.subList(…).sort()` started
> incrementing `ArrayList.modCount` resulting in some cases throwing a
> `ConcurrentModificationException` where none was thrown before.
>
> Th
On Tue, 1 Oct 2024 03:26:26 GMT, Stuart Marks wrote:
>> @dholmes-ora and @dfuch both your observations are quite valid and I agree
>> with them. If you look at the [JBS
>> issue](https://bugs.openjdk.org/browse/JDK-8340572), we discussed this topic
>> there.
>>
>> Clarifying the collections'
es the behavior
> where only sorting the `ArrayList` changes the mod count, but sorting its
> sublists does not.
Attila Szegedi has updated the pull request incrementally with one additional
commit since the last revision:
- Rename test to more descriptive
- Add a test case f
On Sun, 29 Sep 2024 21:50:21 GMT, David Holmes wrote:
>> Fixes a regression with #17818 where `ArrayList.subList(…).sort()` started
>> incrementing `ArrayList.modCount` resulting in some cases throwing a
>> `ConcurrentModificationException` where none was thrown before.
>>
>> This change keeps
Fixes a regression with #17818 where `ArrayList.subList(…).sort()` started
incrementing `ArrayList.modCount` resulting in some cases throwing a
`ConcurrentModificationException` where none was thrown before.
This change keeps the optimization from #17818 but restores the behavior where
only sor
On Mon, 12 Feb 2024 22:52:51 GMT, Attila Szegedi wrote:
> Somewhat surprisingly, `ArrayList$Sublist.sort()` is not specialized and will
> thus fall back to slower default method of `List.sort()` instead of sorting a
> range of the array in-place in its backing root `ArrayList`.
haven't added tests, and `tier1`
> tests still all pass except for
> `test/jdk/java/util/Locale/LocaleProvidersFormat.java` which also currently
> fails on master too on the machine I tested on.
Attila Szegedi has updated the pull request incrementally with one additional
commit s
On Mon, 19 Feb 2024 10:05:24 GMT, Attila Szegedi wrote:
>> Somewhat surprisingly, `ArrayList$Sublist.sort()` is not specialized and
>> will thus fall back to slower default method of `List.sort()` instead of
>> sorting a range of the array in-place in its backing root `ArrayL
On Mon, 19 Feb 2024 10:05:24 GMT, Attila Szegedi wrote:
>> Somewhat surprisingly, `ArrayList$Sublist.sort()` is not specialized and
>> will thus fall back to slower default method of `List.sort()` instead of
>> sorting a range of the array in-place in its backing root `ArrayL
On Wed, 14 Feb 2024 23:37:03 GMT, Stuart Marks wrote:
>> Somewhat surprisingly, `ArrayList$Sublist.sort()` is not specialized and
>> will thus fall back to slower default method of `List.sort()` instead of
>> sorting a range of the array in-place in its backing root `ArrayList`.
>>
>> This do
haven't added tests, and `tier1`
> tests still all pass except for
> `test/jdk/java/util/Locale/LocaleProvidersFormat.java` which also currently
> fails on master too on the machine I tested on.
Attila Szegedi has updated the pull request incrementally with one additional
commit
haven't added tests, and `tier1`
> tests still all pass except for
> `test/jdk/java/util/Locale/LocaleProvidersFormat.java` which also currently
> fails on master too on the machine I tested on.
Attila Szegedi has refreshed the contents of this pull request, and previous
commits
On Wed, 14 Feb 2024 23:37:03 GMT, Stuart Marks wrote:
>> Somewhat surprisingly, `ArrayList$Sublist.sort()` is not specialized and
>> will thus fall back to slower default method of `List.sort()` instead of
>> sorting a range of the array in-place in its backing root `ArrayList`.
>>
>> This do
haven't added tests, and `tier1`
> tests still all pass except for
> `test/jdk/java/util/Locale/LocaleProvidersFormat.java` which also currently
> fails on master too on the machine I tested on.
Attila Szegedi has updated the pull request incrementally with one additional
commit sinc
On Tue, 13 Feb 2024 03:55:37 GMT, Stuart Marks wrote:
>> Somewhat surprisingly, `ArrayList$Sublist.sort()` is not specialized and
>> will thus fall back to slower default method of `List.sort()` instead of
>> sorting a range of the array in-place in its backing root `ArrayList`.
>>
>> This do
Somewhat surprisingly, `ArrayList$Sublist.sort()` is not specialized and will
thus fall back to slower default method of `List.sort()` instead of sorting a
range of the array in-place in its backing root `ArrayList`.
This doesn't change observable behavior, so haven't added tests, and `tier1`
On Mon, 8 Jan 2024 13:24:55 GMT, Athijegannathan Sundararajan
wrote:
> Adding missing "@ since 9" in javadoc comment of the public classes,
> interfaces and packages of the jdk.dynalink module.
Marked as reviewed by attila (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull
On Mon, 9 Jan 2023 08:33:09 GMT, Viktor Klang wrote:
>> Currently Set.copyOf allocates both a HashSet and a new empty array when the
>> input collection is empty.
>>
>> This patch avoids allocating anything for the case where the parameter
>> collection's isEmpty returns true.
>
> Viktor Klang
On Thu, 12 Jan 2023 09:28:46 GMT, Per Minborg wrote:
>> `java.util.concurrent.ConcurrentHashMap` is relatively old and has not been
>> updated to reflect the current state of Java and can be modernized:
>>
>> * Add `@Serial` annotations
>> * Seal classes and restrict subclassing for internal
Hey folks,
I’ve been looking at some performance bottlenecks in a system recently, and
found that we have some that stem from synchronizing on a SimpleDateFormat
(which, as we know, isn’t thread safe.) This got me thinking about switching to
a ThreadLocal of them, but I realized that I don’t ne
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 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 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 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, 29 Jun 2022 08:20:31 GMT, Andrey Turbanov wrote:
>> There is overload method HashMap.remove(key,value) which also checks value
>> equality.
>> It's shorter and faster than pair get+remove.
>
> Andrey Turbanov has updated the pull request incrementally with one
> additional commit since
On Wed, 29 Jun 2022 21:11:09 GMT, Andrey Turbanov wrote:
> Update code checks both non-null and instance of a class in jdk.hotspot.agent
> module classes.
> The checks and explicit casts could also be replaced with pattern matching
> for the instanceof operator.
>
> For example, the following
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 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 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:
36 matches
Mail list logo
