> This PR suggests we speed up Character.toUpperCase and Character.toLowerCase
> for latin1 code points by applying the 'oldest ASCII trick in the book'.
>
> This takes advantage of the fact that latin1 uppercase code points are always
> 0x20 lower than their lowercase (with the exception of
> This PR suggests we can speed up `StringLatin1.regionMatchesCI` by applying
> 'the oldest ASCII trick in the book'.
>
> The new static method `CharacterDataLatin1.equalsIgnoreCase` compares two
> latin1 bytes for equality ignoring case. `StringLatin1.regionMatchesCI` is
> updated to use
> This PR suggests we can speed up `StringLatin1.regionMatchesCI` by applying
> 'the oldest ASCII trick in the book'.
>
> The new static method `CharacterDataLatin1.equalsIgnoreCase` compares two
> latin1 bytes for equality ignoring case. `StringLatin1.regionMatchesCI` is
> updated to use
> Currently, the two subclasses of `java.util.EnumSet` optimize bulk operations
> when the argument is also a `EnumSet`, but there is no such optimization for
> wrapper sets (returned by `Collections.unmodifiableSet`,
> `Collections.synchronizedSet`, etc.) and immutable sets (returned by
Hi, can I have a review for this patch? I noticed a strange field
Integer.sizeTable, after digging into its history, I think it could be replaced
by an in-place array allocation and initialization.
Thanks.
-
Commit messages:
- 8143900 OptimizeStringConcat has an opaque dependency
> This bug relates to the "potentially ambiguous overload" warning which is
> enabled by `-Xlint:overloads`.
>
> The warning detects certain ambiguities that can cause problems for lambdas.
> For example, consider the interface `Spliterator.OfInt`, which declares these
> two methods:
>
> void
On Mon, 20 Feb 2023 23:53:05 GMT, SWinxy wrote:
> In the `AWTEventMulticaster` class(es), which interfaces are causing the
> ambiguity?
Ah - my apologies. Those got added during development but were not needed once
all the bugs were worked out.
I've removed them and that will also eliminate
On Sat, 18 Feb 2023 06:43:27 GMT, Eirik Bjorsnos wrote:
>> test/jdk/java/lang/Character/Latin1CaseFolding.java line 31:
>>
>>> 29: /**
>>> 30: * @test
>>> 31: * @summary Provides exchaustive verification of Character.toUpperCase
>>> and Character.toLowerCase
>>
>> typo: "exhaustive"?
>
> I
On Sun, 19 Feb 2023 23:52:52 GMT, Archie L. Cobbs wrote:
> This bug relates to the "potentially ambiguous overload" warning which is
> enabled by `-Xlint:overloads`.
>
> The warning detects certain ambiguities that can cause problems for lambdas.
> For example, consider the interface
On Mon, 20 Feb 2023 17:03:33 GMT, Peter Levart wrote:
>> We don't fear calling the factory twice for benign races, as the distinct
>> constructor factory instances are behaviorally the same.
>>
>> The true issue lies in the double getfield operations: Java memory model
>> doesn't require the
On Sat, 18 Feb 2023 23:26:08 GMT, Claes Redestad wrote:
> When encoding Strings to US-ASCII we can speed up the happy path
> significantly by using `StringCoding.countPositives` as a speculative check
> for whether there are any chars that needs to be replaced by `'?'`. Once a
> non-ASCII
Found this answer from smarks:
https://stackoverflow.com/questions/26549659/built-in-java-8-predicate-that-always-returns-true/26553481#26553481
Certainly there is some value in something that has a name vs. a
> written-out lambda, but this value is quite small. We expect that people
> will
Hi,
So I found myself writing some code which sets up a j.u.s.Stream processing
pipeline where the stream can optionally be traced/logged via a peeking
Consumer.
The default should be not to trace, in which case I initially set the
Consumer to null. But then I need to check that trace != null
On Mon, 20 Feb 2023 10:22:48 GMT, Raffaello Giulietti
wrote:
>> Augment NaN-handling tests to include exotic NaN bit patterns. Assuming this
>> changeset goes back first, I'll update
>> https://github.com/openjdk/jdk/pull/12608 to follow the same convention
>> afterward.
>
>
> It can be difficult to find the cause of calls to
> `java.lang.System.exit(status)` and `Runtime.exit(status)` because the Java
> runtime exits.
> The status value and stack trace are logged using the System Logger named
> `java.lang.Runtime` with message level `System.Logger.Level.DEBUG`.
On Sat, 18 Feb 2023 21:40:08 GMT, Tagir F. Valeev wrote:
>> For cleanup and dogfooding the new method, it would be nice to use
>> Math.clamp where possible in java.base. See PR #12428.
>>
>> As Math.clamp performs an additional check that min is not greater than max,
>> I conservatively
> `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 classes
> * Use pattern matching for instance
> * Remove
On Sat, 18 Feb 2023 23:26:08 GMT, Claes Redestad wrote:
> When encoding Strings to US-ASCII we can speed up the happy path
> significantly by using `StringCoding.countPositives` as a speculative check
> for whether there are any chars that needs to be replaced by `'?'`. Once a
> non-ASCII
On Mon, 20 Feb 2023 13:09:50 GMT, liach wrote:
>> 8302822: Method/Field/Constructor/RecordComponent::getGenericInfo() is not
>> thread safe
>
> We don't fear calling the factory twice for benign races, as the distinct
> constructor factory instances are behaviorally the same.
>
> The true
On Mon, 20 Feb 2023 16:23:32 GMT, Claes Redestad wrote:
>> Is it not already in CharacterDataLatin1?
>>
>> Here is a comparison of relying on improvements in
>> `CharacterDataLatin1.toUpperCase/toLowerCase` only vs. using
>> `CharacterDataLatin1.equalsIgnoreCase`:
>>
>>
On Mon, 20 Feb 2023 16:16:45 GMT, Eirik Bjorsnos wrote:
>> src/java.base/share/classes/java/lang/CharacterDataLatin1.java.template line
>> 170:
>>
>>> 168: * @return true if the two bytes are considered equals ignoring
>>> case in latin1
>>> 169: */
>>> 170: static boolean
On Mon, 20 Feb 2023 15:40:09 GMT, Claes Redestad wrote:
>> Eirik Bjorsnos has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Add @bug tag to EqualsIgnoreCase test for correct issue JDK-8302871
>> - Add @bug tag to EqualsIgnoreCase test
On Mon, 20 Feb 2023 14:45:09 GMT, Eirik Bjorsnos wrote:
>> This PR suggests we can speed up `StringLatin1.regionMatchesCI` by applying
>> 'the oldest ASCII trick in the book'.
>>
>> The new static method `CharacterDataLatin1.equalsIgnoreCase` compares two
>> latin1 bytes for equality ignoring
On Sat, 18 Feb 2023 00:57:14 GMT, Naoto Sato wrote:
> I'd rather not use "case folding", as to me it implies "normalizing" but
> this is simply lowercasing/uppercasing.
I guess I was looking for a generic term for uppercase/lowercase. I picked
"case conversion" instead.
>
On Fri, 17 Feb 2023 17:31:09 GMT, Eirik Bjorsnos wrote:
> This PR suggests we speed up Character.toUpperCase and Character.toLowerCase
> for latin1 code points by applying the 'oldest ASCII trick in the book'.
>
> This takes advantage of the fact that latin1 uppercase code points are always
>
On Fri, 17 Feb 2023 17:31:09 GMT, Eirik Bjorsnos wrote:
> This PR suggests we speed up Character.toUpperCase and Character.toLowerCase
> for latin1 code points by applying the 'oldest ASCII trick in the book'.
>
> This takes advantage of the fact that latin1 uppercase code points are always
>
This PR suggests we speed up Character.toUpperCase and Character.toLowerCase
for latin1 code points by applying the 'oldest ASCII trick in the book'.
This takes advantage of the fact that latin1 uppercase code points are always
0x20 lower than their lowercase (with the exception of two code
> This PR suggests we can speed up `StringLatin1.regionMatchesCI` by applying
> 'the oldest ASCII trick in the book'.
>
> The new static method `CharacterDataLatin1.equalsIgnoreCase` compares two
> latin1 bytes for equality ignoring case. `StringLatin1.regionMatchesCI` is
> updated to use
> Currently, the two subclasses of `java.util.EnumSet` optimize bulk operations
> when the argument is also a `EnumSet`, but there is no such optimization for
> wrapper sets (returned by `Collections.unmodifiableSet`,
> `Collections.synchronizedSet`, etc.) and immutable sets (returned by
On Mon, 20 Feb 2023 13:58:01 GMT, liach wrote:
> no, Set.copyOf explicitly allows duplications, unlike Set.of. You need to
> read the specs so you know what you are doing.
Sorry, my bad. I've fixed that.
-
PR: https://git.openjdk.org/jdk/pull/12498
RFE filed: https://bugs.openjdk.org/browse/JDK-8302877
/Claes
17 feb. 2023 kl. 18:38 skrev Eirik Bjørsnøs
mailto:eir...@gmail.com>>:
Hi,
The following PR suggests we can speed up Character.toUpperCase and
Character.toLowerCase for latin1 code points by applying 'the oldest ASCII
trick in
On Mon, 20 Feb 2023 13:24:27 GMT, Tingjun Yuan wrote:
>> src/java.base/share/classes/java/util/Set.java line 742:
>>
>>> 740: E e1 = it.next();
>>> 741: if (!it.hasNext()) {
>>> 742: return Set.of(e0, e1);
>>
>> Bad change, doesn't handle e0.equals(e1), and this is
> This PR suggests we can speed up `StringLatin1.regionMatchesCI` by applying
> 'the oldest ASCII trick in the book'.
>
> The new static method `CharacterDataLatin1.equalsIgnoreCase` compares two
> latin1 bytes for equality ignoring case. `StringLatin1.regionMatchesCI` is
> updated to use
On Mon, 20 Feb 2023 13:29:52 GMT, Tingjun Yuan wrote:
> I wonder why the original code didn't use `addAll`, so I didn't change it.
It seems to be okay to use `addAll` in all cases. Do we need extra test cases
for this?
-
PR: https://git.openjdk.org/jdk/pull/12498
> Currently, the two subclasses of `java.util.EnumSet` optimize bulk operations
> when the argument is also a `EnumSet`, but there is no such optimization for
> wrapper sets (returned by `Collections.unmodifiableSet`,
> `Collections.synchronizedSet`, etc.) and immutable sets (returned by
> This PR suggests we can speed up `StringLatin1.regionMatchesCI` by applying
> 'the oldest ASCII trick in the book'.
>
> The new static method `CharacterDataLatin1.equalsIgnoreCase` compares two
> latin1 bytes for equality ignoring case. `StringLatin1.regionMatchesCI` is
> updated to use
On Mon, 20 Feb 2023 13:16:09 GMT, liach wrote:
>> Tingjun Yuan has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Optimize `EnumSet.copyOf` and `Set.copyOf`
>
> src/java.base/share/classes/java/util/EnumSet.java line 186:
>
>> 184:
On Mon, 20 Feb 2023 13:15:20 GMT, liach wrote:
> Bad change, doesn't handle e0.equals(e1), and this is getting beyond the
> original issue
`Set.of(E, E)` handles duplication. If `coll` is
`{Jumbo,Regular}EnumSetCompatible`, then we don't have to create the `HashSet`.
-
PR:
On Sat, 18 Feb 2023 19:45:34 GMT, Eirik Bjorsnos wrote:
>> src/java.base/share/classes/java/lang/CharacterDataLatin1.java.template line
>> 181:
>>
>>> 179: return ( U <= 'Z' // In range A-Z
>>> 180: || (U >= 0xC0 && U <= 0XDE && U != 0xD7)) // ..or
>>> A-grave-Thorn,
On Sat, 18 Feb 2023 19:04:24 GMT, David Schlosnagle wrote:
>> This PR suggests we can speed up `StringLatin1.regionMatchesCI` by applying
>> 'the oldest ASCII trick in the book'.
>>
>> The new static method `CharacterDataLatin1.equalsIgnoreCase` compares two
>> latin1 bytes for equality
On Mon, 20 Feb 2023 13:15:03 GMT, Tingjun Yuan wrote:
>> Currently, the two subclasses of `java.util.EnumSet` optimize bulk
>> operations when the argument is also a `EnumSet`, but there is no such
>> optimization for wrapper sets (returned by `Collections.unmodifiableSet`,
>>
On Sat, 18 Feb 2023 09:21:25 GMT, Eirik Bjorsnos wrote:
> This PR suggests we can speed up `StringLatin1.regionMatchesCI` by applying
> 'the oldest ASCII trick in the book'.
>
> The new static method `CharacterDataLatin1.equalsIgnoreCase` compares two
> latin1 bytes for equality ignoring
On Sat, 18 Feb 2023 09:21:25 GMT, Eirik Bjorsnos wrote:
> This PR suggests we can speed up `StringLatin1.regionMatchesCI` by applying
> 'the oldest ASCII trick in the book'.
>
> The new static method `CharacterDataLatin1.equalsIgnoreCase` compares two
> latin1 bytes for equality ignoring
This PR suggests we can speed up `StringLatin1.regionMatchesCI` by applying
'the oldest ASCII trick in the book'.
The new static method `CharacterDataLatin1.equalsIgnoreCase` compares two
latin1 bytes for equality ignoring case. `StringLatin1.regionMatchesCI` is
updated to use
> Currently, the two subclasses of `java.util.EnumSet` optimize bulk operations
> when the argument is also a `EnumSet`, but there is no such optimization for
> wrapper sets (returned by `Collections.unmodifiableSet`,
> `Collections.synchronizedSet`, etc.) and immutable sets (returned by
On Sun, 19 Feb 2023 18:41:18 GMT, liach wrote:
> 8302822: Method/Field/Constructor/RecordComponent::getGenericInfo() is not
> thread safe
We don't fear calling the factory twice for benign races, as the distinct
constructor factory instances are behaviorally the same.
The true issue lies in
RFE filed: https://bugs.openjdk.org/browse/JDK-8302871
/Claes
18 feb. 2023 kl. 10:28 skrev Eirik Bjørsnøs
mailto:eir...@gmail.com>>:
Hi,
The following PR suggests we can speed up StringLatin1.regionMatchesCI by
applying 'the oldest ASCII trick in the book':
RFE filed: https://bugs.openjdk.org/browse/JDK-8302872
/Claes
18 feb. 2023 kl. 19:58 skrev Eirik Bjørsnøs
mailto:eir...@gmail.com>>:
Hi,
This PR continues the effort to speed up case-insensitive string comparisons,
this time tackling comparison of latin1-coded strings with utf16-coded
On Thu, 9 Feb 2023 16:20:31 GMT, Tingjun Yuan wrote:
> Currently, the two subclasses of `java.util.EnumSet` optimize bulk operations
> when the argument is also a `EnumSet`, but there is no such optimization for
> wrapper sets (returned by `Collections.unmodifiableSet`,
>
On Thu, 9 Feb 2023 16:20:31 GMT, Tingjun Yuan wrote:
> Currently, the two subclasses of `java.util.EnumSet` optimize bulk operations
> when the argument is also a `EnumSet`, but there is no such optimization for
> wrapper sets (returned by `Collections.unmodifiableSet`,
>
On Thu, 9 Feb 2023 19:37:03 GMT, liach wrote:
> Just curious, how does this enum set change affect the performance of
> construction of regular sets via Set.of calls?
See `ImmutableCollections.setFromArray`, it relies on the fact that
`EnumSet.copyOf` will throw a `ClassCastException` if the
On Thu, 9 Feb 2023 16:20:31 GMT, Tingjun Yuan wrote:
> Currently, the two subclasses of `java.util.EnumSet` optimize bulk operations
> when the argument is also a `EnumSet`, but there is no such optimization for
> wrapper sets (returned by `Collections.unmodifiableSet`,
>
Currently, the two subclasses of `java.util.EnumSet` optimize bulk operations
when the argument is also a `EnumSet`, but there is no such optimization for
wrapper sets (returned by `Collections.unmodifiableSet`,
`Collections.synchronizedSet`, etc.) and immutable sets (returned by `Set.of`
On Sat, 18 Feb 2023 23:26:08 GMT, Claes Redestad wrote:
> When encoding Strings to US-ASCII we can speed up the happy path
> significantly by using `StringCoding.countPositives` as a speculative check
> for whether there are any chars that needs to be replaced by `'?'`. Once a
> non-ASCII
On Sun, 19 Feb 2023 07:24:30 GMT, David Schlosnagle wrote:
>> When encoding Strings to US-ASCII we can speed up the happy path
>> significantly by using `StringCoding.countPositives` as a speculative check
>> for whether there are any chars that needs to be replaced by `'?'`. Once a
>>
When encoding Strings to US-ASCII we can speed up the happy path significantly
by using `StringCoding.countPositives` as a speculative check for whether there
are any chars that needs to be replaced by `'?'`. Once a non-ASCII char is
encountered we fall back to the slow loop and replace as
On Sat, 18 Feb 2023 23:26:08 GMT, Claes Redestad wrote:
> When encoding Strings to US-ASCII we can speed up the happy path
> significantly by using `StringCoding.countPositives` as a speculative check
> for whether there are any chars that needs to be replaced by `'?'`. Once a
> non-ASCII
Unsafe might be similarly tricky dependency-wise, but perhaps less so. Either
solution might work fine if we extract the code for encoding to a utility class
that isn’t initialized eagerly with String.class itself.
I’ll file an RFE and get the ”trivial” fix to use StringCoding.countPositives
On Fri, 17 Feb 2023 17:27:50 GMT, Roger Riggs wrote:
>> It can be difficult to find the cause of calls to
>> `java.lang.System.exit(status)` and `Runtime.exit(status)` because the Java
>> runtime exits.
>> The status value and stack trace are logged using the System Logger named
>>
On Fri, 17 Feb 2023 16:48:27 GMT, Paul Sandoz wrote:
>> Viktor Klang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Write the initial value of the next reference without using the VarHandle
>
> That's a nice find, looks good. (Update
> I noticed when looking at the code that there was no real need to use a CHM
> to perform the tracking of activation in an ordered fashion on
> ForEachOrderedTask, but instead a VarHandle can be used, reducing allocations
> and indirection.
Viktor Klang has updated the pull request
On Sat, 18 Feb 2023 02:40:01 GMT, ExE Boss wrote:
>> Viktor Klang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Write the initial value of the next reference without using the VarHandle
>
>
On Sun, 19 Feb 2023 21:30:19 GMT, Joe Darcy wrote:
> Augment NaN-handling tests to include exotic NaN bit patterns. Assuming this
> changeset goes back first, I'll update
> https://github.com/openjdk/jdk/pull/12608 to follow the same convention
> afterward.
Otherwise LGTM
On Thu, 9 Feb 2023 13:46:14 GMT, Per Minborg wrote:
>> `ZoneOffset` instances are cached by the `ZoneOffset` class itself for
>> values in the range [-18h, 18h] for each second that is on an even quarter
>> of an hour (i.e. at most 2*18*4+1 = 145 values).
>>
>> Instead of using a
On Sun, 19 Feb 2023 18:41:18 GMT, liach wrote:
> 8302822: Method/Field/Constructor/RecordComponent::getGenericInfo() is not
> thread safe
The field needs to be volatile for these construction races to be thread-safe,
otherwise no guarantee that seeing a non-null genericInfo will mean you see
On Mon, 20 Feb 2023 09:34:17 GMT, David Holmes wrote:
> You can't introduce a new public API and then blame people for using it! If
> the API is really only intended to support the internal implementation of a
> language feature than make it private and don't export it.
There are a number of
On Mon, 20 Feb 2023 08:49:38 GMT, Volker Simonis wrote:
> Sorry, but that's a really weird argument. You can't introduce a new public
> API and then blame people for using it! If the API is really only intended to
> support the internal implementation of a language feature than make it
>
On Sat, 18 Feb 2023 01:55:52 GMT, Mandy Chung wrote:
> > Finally, the PR fixes a regression compared to the JDK 11 behavior.
>
> This is an intended change that improves the C heap memory usage. In
> addition, the spec of `LambdaMetafactory` has no guarantee of the spinned
> classes be
On Fri, 17 Feb 2023 21:21:56 GMT, Jorn Vernee wrote:
> > (because they are all not referenced from the program any more).
>
> So, it sounds like this is testing a case where
> `LambdaMetafactory.metafactory` is being called directly?
>
> I'd like to point out that, while I buy that people are
On Sun, 19 Feb 2023 18:41:18 GMT, liach wrote:
> 8302822: Method/Field/Constructor/RecordComponent::getGenericInfo() is not
> thread safe
I think of this pattern of reading a to-be-lazily-initialized value into a
local as simple hygiene, `volatile` or not. The code might seem solid without
> `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 classes
> * Use pattern matching for instance
> * Remove
On Sun, 19 Feb 2023 18:41:18 GMT, liach wrote:
> 8302822: Method/Field/Constructor/RecordComponent::getGenericInfo() is not
> thread safe
Hello @liach, I don't follow what this change is achieving. I think I might be
missing something though. I read through the linked JIRA which states:
> In
On Sun, 19 Feb 2023 18:41:18 GMT, liach wrote:
> 8302822: Method/Field/Constructor/RecordComponent::getGenericInfo() is not
> thread safe
Marked as reviewed by redestad (Reviewer).
-
PR: https://git.openjdk.org/jdk/pull/12643
On Sun, 19 Feb 2023 18:41:18 GMT, liach wrote:
> 8302822: Method/Field/Constructor/RecordComponent::getGenericInfo() is not
> thread safe
Marked as reviewed by stsypanov (Author).
-
PR: https://git.openjdk.org/jdk/pull/12643
74 matches
Mail list logo
