> 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
> 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 `equa
> 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 `equa
> 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
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 d
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 `Splitera
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 s
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 char
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 learn
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 whe
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.
>
> test/jdk/java/lan
> 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`.
Ro
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 replac
> `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 r
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 char
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 issu
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`:
>>
>> Character.toUpperCase/
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 equal
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 f
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.
> test/jdk/java/lang/
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 poin
> 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 `equa
> 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 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 the
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 g
> 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 `equa
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 `Set.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 `equa
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: https:
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 ignori
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`,
>> `Collections.syn
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 case.
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 case.
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 `equalsIgnoreCase
> 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 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 t
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':
https://github.com/openjdk/jdk/pul
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 strings
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`,
> `Collections.synchron
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`,
> `Collections.synchron
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 e
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`,
> `Collections.synchron
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`
metho
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 char
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
>> non-ASC
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 neede
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 char
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
in
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
>> `java.lang.
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 th
> 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 incremental
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
>
> src/java.base/share/classes/java/util/stream/
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
test/jdk/java/lang/
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 `ConcurrentH
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 a
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 A
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
> priva
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 unloade
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
it
> `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 r
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
